Finishing up the Outside for now

Not much time to work today, I have an appointment to get to. With the time I have had this morning so far I set up a few things;

There's less chance of a player seeing the dark void now. The cityscape is still a bit bland but functional.

The pedestrians will (mostly) avoid getting hit by cars, though occasionally one will jump a light and get creamed, which will just make them disappear while the car plays a "Bonk" sound effect.

There's still some things that bother me about how the apartment looks sitting in the building like that, however I think it could be fixed with a few more tiles added to the tileset, will do that when I make my next design pass on the outside area. For now I think it's about time to get started with planning out the care systems in a bit more detail so I can get all that started.

I need to figure out how interactions will happen for one. The player walking up to the slime and pressing a button seems the most intuitive way. I could also have slimes come when you call (click) on them if their trust is high enough.

For now I will keep it simple, walk up to a slime, have the player character cast a ray that is their Interaction ray, if it intersects with a slime display that slime's name over their head so the player is certain of what they are interacting with. Environmental interactions would display an outline around objects in the environment the player can interact... with... yeah.

When the interact button is pressed, Freeze the slime in place via the state machine. Open the interaction UI. Now... what does this even look like? Do I want a full window with tabs showing the slime's data and a picture of their detail sprite?

Probably better to have a circular menu of buttons pop up around the slime, I would think? I could add controller support more easily that way. Then the buttons could be things like...

Pick Up, to carry the slime somewhere. Give, to give the slime an item from the player's inventory. Pet, to simply pat the slime on the head. Play to open the play menu which I am thinking will be a viewport itself with little mini games inside to select from depending on what the player has unlocked. School, to open the school menu/viewport. Train, opens the training submenu. Schedule, which will be later when they become teens and can have a daily schedule of things they do themselves. Info which would open the big menu with all the tabs and stats and stuff. Maybe a couple more? I am not sure exactly what I need at the moment as I am not currently looking at my planning docs. This is more of a brainstorm session than any formal planning.

On the radial menu I should have a way to display some at-a-glance stats so the player doesn't have to open any further menus to check the basic care stats. Maybe a number under each button corresponding to how they are doing in that area? Under the play button could be Fun x/max and under the Give button could have hunger and thirst, etc.

In early development I will keep the interactions simple. Just pressing the button, sending the signal to the server, having the server decide if that signal is alright and then sending back the result. Later on adding animations, more complex interactions, etc.

So how it looks in my head, let's say you have a hungry slime. They will probably be following you around if they are hungry or going and sitting at the refrigerator a lot. (Once I have furniture in.) You walk up to the slime, interact with it, select Give, then choose a food item. For now it will be an infinite rice ball since I have to set up player inventory handling but I wanted to get the base care systems in place before I mess with all that. The command will be sent to the server, saying Feed X to Slime Y. While this is happening the client will lock interactions with the slime until it gets a response from the server.

When the inventory is implemented it will look at the player's inventory and decide if they have the item, if so it will check if the slime is in fact hungry, then it will attempt to feed the item to the slime. If the slime accepts the food it will return true. Then the inventory will decrement the item from the inventory, send back the response that the slime ate the item to the client. Along with this response it will tell the client what has changed on the slime.

The client will decrement the item on it's end then play the slime eating animation, The client will update the slime's stats and then unlock the slime to be interacted with again and refresh the radial menu with the changed data. The player can then interact again or close the menu, releasing the slime back into it's normal UI routines.

Simple on paper. Doubt it will be so simple in execution.

On the server I will need interaction RPCs for each type of interaction, feed, water, bathe, etc. This will need to know the slime ID and what object if any is being used in the interaction. When the RPC is fired it will pass the data along to the slime by way of Player Connection ID -> Player -> Slimes -> Slime_by_id(): Return Slime node.

The slime node will do all the necessary checks for the interaction, like... if it hates the food item trying to be fed to it or if it is already full, then if all checks pass it will perform the interaction, modifying all relevant stats.

Once finished it will send the OK back to the connection Manager by way of Owner(Player) -> Connection Manager -> X_Interaction_OK: RPC to client via Player Connection ID.

If it fails for any reason it will send back a FAIL RPC with any relevant data, e.g.; Full, Dislike Food.(Usually in ENUM form to keep the packet slim.) This data can be used to set specific animations or behaviors in the AI state machine based on personality traits and any other client side slime control scripting.

The next bit is the server Tick. The way this needs to be handled is a little bit complex. I may even want to store ticks in the DB along with the last datetime one occurred. This will allow me to more easily handle restarts, crash recovery, etc. If the server is down for several hours I need to handle all the lost ticks at boot which I can do by subtracting the current datetime from the last tick datetime.

The tick is nothing more than a timer, really. It should fire every hour, in dev I will modify this a lot for debugging... but I think an hour should be fine.

Every tick the server should compute all connected, active slimes stat decrements. This will be handled on the slimes themselves, they will listen for tick signals and run through all their traits and modifiers and apply all changes. If they have a trait that makes them lose more hunger per tick they will apply that now.

To handle the application of all their modifiers they will simply loop through their body parts and traits sub-nodes. Each one has a script attached with a hook called OnTick() anything in this will be run every single tick.

At the end of the slime's tick handling they will send their updated data to the Owner(Player Connection ID) client where it will be stored and UI updated with the changes.

Then the player can interact with the slimes and feed them or whatever else they need again.

This should create a day to day gameplay loop, the player will log in one or more times a day for a little while, check on their slimes and handle anything they need. Though this is only stage one of the gameplay loop development. After that I will add the in game internet and start the sort of... ARGs... then the ability to explore the city, then the island, then dungeons. Then there will be more for players to do when they log in.

On initial release I want to have players hanging out in their apartments with their slimes, chatting with other players on their computers and investigating mysteries on the in-game internet. I want the slime personalities and strange things that happen outside their windows to keep them interested enough to build a community while I work on adding new systems.

Mysteries will be ARGs basically, initially simple ones run by me that will lead to interactions with NPCs at the door or packages showing up with items. Later on they integrate the city and dungeon exploration to find more clues. Some will even lead to the ability to join secret societies run by event staff which for now is just me.

Anyway, before all that I need to get the care system functional. I did the brainstorm, now I need to actually plan it all out in the books. I may not be adding any more to this post as it's near my appointment and it is lunch time. Afterward I may have a lot of things to do regarding the potential move. It depends entirely on what happens at the appointment in question.

So worst case, I'll be back here tomorrow probably getting started on the care code if not still planning it out.