Tag: python

Rotate main object towards context object when reaching an action point

To make things look more natural, also make the “main” object rotate towards the object it is interacting with, not just let it move towards to the action point.

Fully implement the eating mechanic as intended. Add some generic job utility functions to the abstract python object.

This finally brings all the pieces together, the biggest change here are the above mentioned generic methods which can be applied to all kinds of job types:

But why don’t you check out the final product (and imagine that chair is actually a refrigerator)

– further implement the food buying mechanic in python (still not complete)
– correct “parameter” parameter passing into python scripts
– add interface to allow python scripts to reduce the funds (buy things)
– fix job type copy constructor (did not initialise all values)
– do not allow values greater than 100 in controllable objects
– add mechanic in the game state/main app that force-refreshes the widgets if the funds changed through a script

Really as it says in the surprisingly in-depth commit message, making good progress!

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: