Author: s20

Add support for showing a colour specturm instead of a plain white progress bar that changes depending on the status
shown

Comes as advertised, adds the ability to the brand-new status bars to now just show their value in plain white. Whether or not to use an interpolated colour value or just a plain white can be set as required.

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: