I’m on a roll! I’m using most of my limited free time for this game and writing here. Let’s go over some tech and some game design-ish things that happened today.

Unit Development Environment

You can now fully develop unit code in-game, this morning I finished hooking up the assembler with the editor and then reloading units of that type when assembling. I’ve already gained so much speed trying things up and it definitely paid off when developing the Radio device. The edit-assemble-debug flow is very quick although I’ve already found a couple of places where it could be even better. I’m sort of feeling the need for a small REPL per-unit and I may tackle that tomorrow.

Here is a video from this morning showing a basic modification and assemble flow:

Radio Device

Today I also implemented the Radio device so units can talk between themselves. This is the tentative interface to the radio device:

|20 @Radio 
	&vector $2 
	&packeth $2 
	&packetl $2
	&command $1
	&freq $1
	&strength $1
	&enabled $1

(if you don’t know how to interpret this please check the “runes for labels” section in the Compudanzas Uxn Tutorial)

The .Radio/vector port allows us to tell the Radio which subroutine it should call everytime it has a new message. This is the main way you can react to messages. This vector will only be called if enabled is not 0.

The .Radio/packeth and .Radio/packetl are the high and low part of a 32 bit packet. These 4 bytes are used both as input and as output. When receiving an incoming message and before calling the vector the Radio device sets these to the packet values of the incoming message. When sending data, you first set these two and then you DEO .Radio/command with 00, the command for Send.

.Radio/command is used to give several commands to the Radio device, for now only 00 (Send) is implemented, but I could see other more advanced commands like ways of filtering messages, or customized Send operations that change different parameters. This is still very much open to experimentation.

.Radio/freq sets the frequency of the Radio, this affects both the incoming messages (all messages from other frequencies will not call vector) and sets the frequency of outgoing messages.

.Radio/strength is set by the Radio device when receiving a message. The strength is a number between 255 and 1 and represents the strength of the signal, while this doesn’t immediately have an effect it can potentially be used to triangulate positions of units when taking different datapoints from different units.

.Radio/enabled, when Radio is disabled it does not trigger vector for any incoming packet.

This is the current tentative interface of Radio but it is subject to change.

One thing I want to remark is that the packets are arbitrary and have no meaning by themselves. The Radio system in Kikai is BYOP (Bring Your Own Protocol). Which means you’ll have to design a protocol that solves your problems in the game. If units ever only receive orders from a couple of senders, you are probably fine with the 32 bits being mostly data. However if you organize your army around lots of small messages between units, it’s very much possible you need to replicate some parts of the IP protocol, like dedicating the first two bytes to the origin and destination units so messages can be properly routed between your units. As everything in this game, it all depends on you and what your goal is!

Here is a video of two units communicating between themselves using the radio. Both units are of the same type and send a message when they are issued a move command (by right clicking somewhere on the map). I then setup a breakpoint in the message handler of the other unit and check that the received data matches what was sent. Hope you are as excited as I am by this!

This also shows the multi-unit debugger where you can setup breakpoints in an individual unit and do something elsewhere then come back to the unit and debug it. Very useful!

Bonus!

I spent some time today as well adding some very simple syntax highlighting on the unit editor, you can see it in this last video, what do you think about it?

Next Steps

I’ll probably be overhauling the movement system since I’m not very happy with it at the moment, then I’ll work on implementing the basic movement code for units and start work on the Factory device, the device that allows you to create other units. Stay tuned because that one is very interesting!