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:

• Create a standard OS for all your units with a live repl, memory debugging and a live visualization of what the unit sees.
• Display radio data (thanks Aslogd!) in order for the player to attempt to decypher the radio stream of the enemy.
• Have a coordinating unit display a live map of all swarm units in their vicinity. (Maybe by having two antenas and triangulating the time it takes to arrive?
• Have buildings display menus to assemble custom units on the fly.

Limitations and Concerns

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!)