Posted February 24, 2025 by Dziban
Third post this week, let’s go!
In most games, units (and buildings) have a user interface to present the control options you have for that entity, for example in Age of Empires you have the following UI for units.
You have options for how the units move, how the units behave when presented with an enemy and a patrol system. For building you have the units you can create or the upgrades you can purchase.
With Kikai it’s vital we allow the player to create customized interfaces similar to the ones above for the units they customize but we don’t know in advance what they are gonna want. I want simple interfaces to be simple with the ability to create complex debugging and interactive interfaces when needed.
My current idea is to offer two different devices to output this information. Names are of course not definitive but let’s call these two devices EzGui 3000
and ASPD mkII
(or Advanced Screen and Presentation Device Mark II).
EzGui 3000
This device is perfect for most units, low CPU consumption, quick and simple drawing with some basic primitives. This device would offer a immediate-mode-like GUI experience. A simple coding mockup could look something like this
@on-interface-draw
.Params/stance ;stance-button-str BUTTON ?{ ( code to switch stances ) }
.Params/patrol ;patrol-button-str BUTTON ?{ ( code to setup patrol ) }
BRK
Which basically creates two buttons that control the stance and patrol params and when clicked run what is inside of the ?{}
anonymous block.
Another option is to replace the blocks with vectors as well, for current purposes this doesn’t matter too much.
This would render something like this:
This device would offer some simple, ready-made UI elements that you can mix and match and in a few lines of code have a fully functional UI to control your internal parameters. This UI is limited when offering debug output to outputing a few strings maybe, some checkboxes and buttons and that’s it, but for most needs this should be enough.
For more advanced and customized UIs you could use the
ASDP mkII
This would behave a lot more like a framebuffer, the device would take a color, x, y arguments and paint a framebuffer pixel by pixel. This enables basically infinite possibilities, you could create menus, submenus, even a 2048 clone inside the system to kill the time if you get bored. It woulda allow you to display arbitrary information and systems. This is basically equivalent to the Screen device of the Varvara computer system that runs Uxntal.
Some ideas could be:
My idea is that UI code does not consume the CPU budget of the unit (only a single unit can be represented at a single time in the end). It would still consume RAM though and we’d need to limit the execution time so we don’t get infinite loops. This however makes computing in the UI code a very interesting strategy, so maybe this needs to be limited somehow.
Another problem that would need to be solved is what happens when you have multiple units selected, in the case of the EzGui 3000
and if all the units have the same ROM you could present it and then run the callbacks for every unit selected, for the ASDP mkII
things get more complicated and I believe there is no solution that would allow you to do that and you’d have to inspect each one individually (or have a change in one unit send the change to all the other ones through radio!)