Tag: vulkan

Add the first semi-working version of the status bar

For the time being this is the most complex widget, the StatusBar.
Next to a text label, one can also set a percentage value, the eponymous status, that it will translate into renderable model data that looks like, well, a status bar.
To make the distinctions between the different widget types work, they can now all return their type, thanks to the introduction of a new WidgetType enum class.
In order to showcase this in action the new status bars are being shown when a ControllableObject is selected, showing the values of health and hunger.
Furthermore, a bit of preliminary game logic is added in order to decrease an object’s food value when it moves. Check out the result:

Add a class that is derived from object which has extra members pertinent to controllable objects. Add names to the dummy objects.

Using the work that was done in the previous commit, we now add some more information to the newly added ControllableObject. For now it primarily just extends the base Object class by a name, hit points (== health) and hunger (== food). The last one being slightly misleading in name.
The two ControllableObjects, now named “Foobert” and “Bart” also get their name rendered in the simulation mode as opposed to just drawing their object id.

Add missing files

Turns out that it’s always a good idea to also add newly created files.

– Store objects as (unique) pointers internally (so that they can be used in class hierarchy)
– Fix bug that meant that some object types would not rotate properly

In preparation of adding more information to some, but not all, objects the ObjectManager now internally only stores (smart) pointers to objects, not the objects themselves as otherwise we cannot cast them easily to the inherited classes that are going to be introduced, which will add extra attributes to the existing base object class.
The rotation bug was in relation to the refactoring of the ObjectCategory enums and how they were evaluated when calculating an object’s rotation.

Make the controllable objects selectable via the UI (by listing them as a default behaviour if nothing is selected)

This brings OLives a lot closer to look something like an actual game, by showing a list of controllable objects (read: “humans”) in the simulation game mode.
Under the bonnet that also forced me to add a convenience function that returns all objects of a certain category, one in the long list of functions that make me scratch my head and wonder “I thought I’d already written something like that”.
Check it out:

Or maybe check it out in motion:

Fix reducing the wall draw height when placing new walls

Fixes this regression that happened.. sometime?

move more UI update code into the passive update() function

Streamlines things and makes things ready for more complicated use-cases

– add prices to wall and floor tiles
– change the way we update the UI (do everything passively in one place now)
– find a somewhat better hashing technique when calculating the UI hashes of containers when taking their children into account (workaround for collisisions)

Not just objects have prices now! The last part was particularly nasty, as containers that had the same type of contents would return the same hash, which was.. less than ideal.

– add the object id to objects
– also remove the texture path mapping when removing a texture
– increase the funds by half the original price when removing an object (“sell it”)

The first two were some background work to make things a) more manageable and b) try to not leak memory.
As for the bit of game play, check out the video:

– redo the way we update the UI from the game state and only have one entry point for it
– add the concept of prices to object types
– show the price when buying an object and only allow for placement if there are sufficient funds

There were multiple ways to update the UI before, some of which would have made it very complicated to update the display of the funds.
We also add prices to the object defintion files and lastly also add a check and subtract funds when the user places the objects, effectively changing it to “buying” them.