OLives Dev Blog

Expose the game state to the python interface. Various fixes. First step towards implementing the eating mechanics on the python side.

While I wanted to avoid to pass in the entire GameState to Python this proved to be impractical. On a more positive note, only very specific parts of the class are exposed to Python. In the video you can see the object already moving to the context object:

Add new jobs using the job context list (WiP)

Adds the bulk of the logic for starting to enqueuing new jobs through the context lists.

Improve behaviour of the job context list

Even though it definitely does not say so, this means that the job context list can now be hidden again without having to actually push one of the buttons.
This is also the beginning of adding new jobs when clicking one of the buttons, this is very much work in progress however.

Restructure the job context list and make it more dynamic

This is mostly simplifying some code and making the list draw in a more presentable way:

Now the price is also added to give the user some feedback as to why some options might be disabled.

Show available jobs when selecting a context object after selecting a primary object. Introduce the JobContextList to the Interface Manager

This is a big one. This extends the interface manager to show a list of possible jobs that fulfil the following criteria:

• the object being clicked on (“context object”) exposes a list of actions
• the currently selected (“primary”) object supports the action required by a job
• if the job requires funds, make sure the user’s funds are sufficient

This also meant extending the whole click handling logic for objects had to be re-done and the concept of the “context object” selection had to be introduced.
On top of that the JobContextList widget was added, it still looks a little wonky and does not do much except being shown, but here it is:

– add new “parameter” property on job types
– add new “supported actions” property to object types
pass both on to the appropriate python functions and change their signature accordingly

This is properly implementing the aforementioned concept of “supported actions” instead of just hard-coding it. It also adds parameters to the job definitions in order to minimise code duplication. To give a practical example here, look at the definition of the “eat” job in order to see the difference:

Make the job definition more generic and move actual job handlers to separate files

So far all (not like all that much exists yet) the job logic and general object logic were stored in the same file, the implementations for specific tasks no move to separate files. This is realised by iterating over the specified supported actions when instantiating an object (in Python) and dynamically adding the respective functions to the class: