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:
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:
Add missing files
Always a good idea to add all new files. This commit added the missing bindings that were mentioned before, they look something like this:
Move the call to set a new target for a controllable object to the python script
After maintenance and stability commits, back to feature development!
What this slightly confusing commit message is trying to say is that we are finally not only calling Python code from C++, but also the other way around, calling C++ code from Python.
This is achieved by properly setting up bindings from some classes that are now callable via Python.
This commit was not as big in terms of changes, but the concepts that changed, from now on if the user is clicking somewhere the new movement target is no longer set directly in C++, instead it is going through Python for that:
add the script to the objects themselves and use it in a proof-of-concept type of way when selecting a human
Further integrate the loaded script by moving the script instances from the ObjectType to the actual Objects. This way we can actually interact with the instantiated Python module, meaning we have the first more or less meaningful interaction between the Python and C++ parts:
update .gitignore
It makes sense not to have precompiled Python bytecode in the repository.