Ramblings about hobbyist game development
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:
Fix some clang-tidy warnings
A newer Clion version brings more clang-tidy, fix most of these.
Simplify code to remove unused widget data from the ui pipeline somewhat
This reads: use std::none_of instead of manually iterating over some things.
Do not use invalidated iterators
Another maintenance commit, this time meant to remedy some seemingly random renderer crashes. Some iterators would implicitly move even if the element they might point to next might have been invalidated already.
– make things compatible with current libglm releases
– make olives compile and run with recent libvulkan releases (WiP, breakage occurring still)
– fewer magic numbers
Maintenance changes, before that I was forced to downgrade to older versions of both in order to make OLives compile. Not a fun change, at all. 🙁
This is the first in a series of maintenance commits before going back to more feature driven development.
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.
– add a (one way) binding from C++ to python for the time being
– automatically load scripts on a per object type basis
– add the ability to have optional configuration settings
This marks the introduction of Python by using pybind.
At this point it is not doing much except for laying groundwork for what is to come: adding new properties to the Object and ObjectType classes and extending the ObjectType configuration to define a script file that needs to be loaded when an Object is added to the GameState.
Right now, a script file is being loaded and a script interpreter instance is being instantiated when an object is being created and this is where the integration ends: no Python code is actually executed at this point.
The single Python file currently loaded looks like this:
It is relatively easy to tell where this is going by looking at the function names, but as mentioned before, so far the only important thing is that this is a syntactically correct Python file.