Commit 6b5d1c47

Implement core room detection: do a flood fill that determines if a given tile is within a room or not

Relates to #22

Hello again! This commit adds the core of what will be the room detection mechanic, the basic algorithm that determines if a given tile is part of a room or not by doing a flood fill: if it hits the outer limits of the game world it is not within a room, as simple as that. 🙂
Currently, there is no management of the resulting data, actually it’s not even saved anywhere, but that will be one of the next steps. 🙂

Commit fc7253a6

Add boilerplate code for new classes/data structures required for room detection

Relates to #22

Hello! Once again, no visual changes or interesting output of any kind, this is really just adding some classes with very basic functionality and jotting down the planned concepts of how to implement in TODO comments in the appropriate files.
I’ve come up with a concept that should be relatively straight-forward and do the room detection in all the cases I could think of. Let’s see about how that will pan out. 🙂

Commit 74711c16

Make sure the navigation does not get stuck when snapping into the next waypoint position

Resolves #40

Hi! Nothing visual to show here, both the short and long version are “it used to get stuck while navigating before, now it does not anymore”.
This endless loop could be broken by aborting the currently running job (it also occurred in navigation triggered by jobs) was a real pain when testing the object-in-object logic, as the bug only really triggered in short distance navigation, which was mostly the case then. So, happy to see this one fixed, time to look at the greener pastures of feature development again!

Commit eb685228

Transition directly from one position status (passive => active) directly without having to leave the containing object

Resolves #35

While this sounds very technical, it boils down to “characters that went to bed just lying down but not sleeping can now start sleeping without having to get up only to lie down again”.
Implementation wise that only meant exposing a bit more functionality to Python and adding yet another library-like function to the main abstract object Python class. Works just fine. 🙂

Commit 81321994

Make the sleep job run as long as necessary, as opposed to the other jobs, which work based on a pre-defined overall progress

Resolves #36

Most jobs (currently) work towards a pre-defined progress, for example the small, medium and large food options. Things are different with the sleep job, which is supposed to go on for however long it takes to fully recharge (or the job gets aborted of course).
This required a new Python function or two, nothing major, but a nice effect nevertheless. I did some test runs to find a more or less reasonable value that seems semi-realistic. So far, so good!

Commit 3166201a

Correct the configuration settings of the bed object and treat internal actions more like the passive entry points in Python

Resolves #37

I was surprised to see that check was not in place yet, but the behaviour until this commit was assuming that as soon as the entry point was reached, it was impossible to fail entering an object through it – even though it may have been occupied already.
This led to some unplanned cuddling session, as more than one character would occupy the same slot this way. Fixed!

Commit b05314de

Correct the configuration settings of the bed object and treat internal actions more like the passive entry points in Python

Resolves #17

This is putting some finishing touches on the sleeping mechanic, which also included some minor fixes to the object-in-object mechanics that went undetected in the first implementation, the shower, as it is only 1×1 in size, as opposed to the bed.
In the video below you see two options, sleeping and lying down, the difference being that “sleeping” is an active job and shows up in the list as it is explicitly configured – also, it will actively regenerate the energy stats. The “lying down” option is the same as above and only shows up implicitly, as this object type is in a category that marks it as an object type on which a character can lie down on and then idle in a different position status.
While doing this I realised two things are still missing:

  1. Simply starting to sleep when lying down (i.e. not getting up only to lie back down again) if possible
  2. Jobs that have the goal to fully finishing charging a certain type and that do not finish before it is reached – and that also do finish once it is and not keep going

Be that as it may, here’s the video 🙂

Commit 3f6a170e

Improve the handling of auto-padding containers and relative sized children

Resolves #34

While working on the sleeping mechanics I stumbled upon a bug in the job context menu, every time the number of child elements was even the calculation of the height went berserk.
This was caused by what can be described as a feedback loop, as the elements are relatively sized depending on the padding of the parent element while the also automatically calculated padding depends on the size of the child elements.. something which happens to work for odd, but not even cases due to some quirks in the implementation.
Needless to say, the approach here was changed and all cases should work now.

A little before and after shot

Commit 10521d24

Add the concept of “energy” and show the current state in the UI

Relates to #17

This commit does the bulk of the work to get the sleeping mechanics going: it adds “energy” as another property that slowly depletes over time (slower than either food or hygiene). Right now there is no way to charge it back up though 🙂
The skeleton of the new “sleep” job is already there, but not quite functional, hopefully all the the foundation work of the last few commits will speed the process up, check out this riveting screenshot of our lovely new meter:

Commit 8c2ff5ce

Do not let different slot types be used at the same coordinates and time

Resolves #32

Hello! This does exactly what the commit messages states, multiple slot types may share the same coordinates, but obviously if one (e.g. sitting slot) is occupied, another object may not use the same coordinate to lie down – it is already occupied.
This is important for the upcoming work on the sleeping mechanics, the player will still be able to just passively let the characters lie down on the bed, but also to let them sleep on it – obviously the two slots (lying down vs. job) for that will overlap. One step closer to make that work. 🙂