Ramblings about hobbyist game development
Add job queues (per object) and wire everything up so that objects work through a work queue
This brings a lot of pieces together, finally not only are single jobs executed, but an arbitrary number of jobs can be queued up and executed in order, the interface in the ObjectManager looks like this for the time being:
What is still missing here is cancelling jobs, but one step at a time. 🙂
If you look carefully at the console output you can see the job queue in action:
Add job wrapper class
This adds what is in essence just a container for job that is currently being executed, it is made up of
This was added in preparation for the job queues which will be implemented next. As always the python mappings (and scripts) had to be adapted to support this change.
Move the (controllable) object by running the “walk” job instead of manually setting a target
Building on the previous commits, this finally means that an objects executes a job. This means that a the mappings were extended considerable and a fair amount of helper and convenience logic was written on the C++ side as well. The resulting piece of Python is pretty straightforward:
– Flesh out job concepts
– Extend job step class
– Introduce job context class
Next to adding a whole lot of getters and setters, this commit also adds some class members to the Object and JobStep classes that keep track of the current job progress.
It further adds the concept of a job context, meaning that a job that is being executed needs to keep track of a different object it needs to interact with in order to complete a job or a coordinate it needs to move to in order to do so.
As always that also means the Python mappings get extended:
Some refactoring in the job definitions. Add new job related icons.
The most noteworthy thing about this change is the move of the actions from the individual job steps to the job itself:
Fully load job information into object types
This adds some classes that stores the information about the jobs and their steps, as so far we only had classes that would load and validate the configuration. Also add some logic to copy the data from the configuration classes to the classes in which we are actually going to use them.
Extend the object configuration by adding job and job step information to it (2)
Once again some files forgotten in the first commit. On a more positive note, this also gives a good example of where the idea behind the job system is going by also adding a fridge object (which is currently sporting the old chair model since there is no fridge model yet):
The new fridge object is advertising some three different jobs that can be executed by objects that support these actions. Each step may have a price that only gets subtracted one we actually reach that specific step, but the same information needs to be available as well for the job itself, as otherwise we would not know what to offer to the user in the first place (as the funds might be insufficient). All these new definitions will see some use soon. 🙂
Extend the object configuration by adding job and job step information to it
This is the first in a line of commits to introduce a job system to OLives.
The goal is to enable (Controllable)Objects to work through a list of tasks as requested by the user. This requires the introduction of quit a few new concepts, but this commit is just about adding configuration data for the jobs that can be broken down the jobs themselves, which have a name, and individual steps that a that need to be executed in order to consider the job to be complete.
The configuration of the human object has been extended to define the most basic of jobs: walk
As mentioned before, right now this has no effect whatsoever, it is just about defining and validating the new information.
Extend the python mapping and port the quote hunger unquote behaviour to python
Much like in a previous commit more of the existing behaviour is ported to Python, this time that means the logic that lets the “hunger” (read: the object’s satiety level) drop passively and more quickly when the object is moving. If it hits zero it will start removing hit points from the object. Check out the clumsily written Python script doing that:
In order to make this possible the mappings had to be considerably extended.
Make the python script object based instead of calling plain functions in it
As could be seen in a previous commit, so far the python modules for objects were simple modules without any class information, as calling into Python from C++ is resolved at run-time anyway. In order to clean things up a bit and enforce a bit of structure, that has been changed now:
