Ramblings about hobbyist game development
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:
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:
