This is a quick blog post being written before Day Job(tm), but I’m going to try to cover what I ended up doing with my rather heavy development day yesterday. Note: I’ve gotten in the habit, for this project, of taking both screen caps (or partial ones), and small videos to illustrate things I had just implemented. I’m hoping this means by the end of the project I will not only have these development logs, but even more detail showing the progress of the game over time.

What Happened?

Yesterday ended up… a big one. I did a lot. Unlike yesterday, a huge amount of the work was in easy-to-see visual additions and changes, too.

The obvious additions there, especially if you see it moving, is that we now have UI widgets – interactable and non-interactable. From top-left-to-right, we have a light (this one is set to go on and off when the battery enters low power), a circular indicator/gauge, a bar indicator/gauge, and a light-up button.

Each object is self-contained, draws itself, and has a pile of settings. I’ve tried to keep them fairly consistent across them. For instance, they all have locations, columns (there are three display columns in the game – on a phone you’d get just one), label (the three-letter description written below the indicators), colours (for the buttons and lights that turn on and off), and also data hooks.

Some of them also have a top/bottom/mid colour and % configuration, which can also be disabled. In the case of the circular indicator, that tells it where to mark the red, yellow and green on the display (if at all). In the case of the bar indicator, it tells the indicator when to light up the bar and with what colour. In this way, the bar could go red when it’s low, white normally, or green when very high.

Data Hooks In Action

I did the guts of these yesterday, but it’s actually pretty simple. What it means is when you configure a widget, you pass it in a data constant, such as C.NUM_BATTERY_AMOUNT_IN_PERCENT. The first bit is just short-hand for what it expects back (others include BOOL or the like), and the rest indicates what information you want. As I implement more of the game mechanics, I will add more of these into the gamedata module.

What they return is standardised, even if in practice not all of it is required. If you have a data request set to return NUM, what it actually returns is a list of three numbers – a minimum, a maximum, and the actual value. This way, with no other information, the widgets know how to display the information they’ve been passed.

User Interface Manager

The other part which took quite a bit of time yesterday was the user interface module. This handles mouse movement, clicks, and every clickable object (whether it needs to be rendered or not).

The main reason this has its own module is that, for instance (as depicted above) if you move your mouse over a clickable button, hold down the primary mouse button to depress it, then move it off, the manager needs to know to un-press the button. In this way you can have tangible, expected behaviour when fiddling by holding down your mouse moving over a complex interface filled with switches.

I’m going to add a lot more to this – notably, I want to ensure that UI elements can be added to individual columns, so that in the case of screens being shifted (especially on smaller-screened platforms) the UI manager will know to just naturally hide the right widgets and cause them to become inactive.

Coming Soon! Future Attractions…

Up next… well, I’ve got a day of work ahead of me then a night out so… hard to say. I may change my mind, but I will likely either go deeper into the UI manager, refactor some of the code now I’ve learnt more about doing OO stuff in Lua, or perhaps for a complete change launch into the long-intended main view screen functionality. That also requires drawing some more coder art…