Assembling and Rewriting Units
This is gonna be a short post exploring ideas I have about how to generate unit behavior on the fly. The main objective with Kikai is to give you a whole development environment to achieve whatever crazy ideas you want to implement. As with Zachtronics games (and also Dwarf Fortress and Factorio) I want to give the player a simplified but relatively realistic environment and the rest is up to you. You could consider it a networked microcontroller programming sandbox with some Age of Empires elements.
Buildings as Linkers
One of the crazy ideas I could think about is a way to create units on the fly by programming the buildings. This idea turns Buildings (what in traditional RTS games produces units) into something akin to compilers and linkers in computer parlance. This also has a very nice parallel with the idea of Unit Production Time
, as that is the time that the building code takes to assemble the code for your unit.
The base building code would be very simple, it would take bytes from a source rom and write them into the unit rom using a building-specific (maybe? maybe it could be used in units as well?) “Factory” device. This would be just a simple basic memcpy
. However things start getting interesting when you consider the implications of buildings being just another Uxn machine. What if instead of just memcpy
it could act more like a compiler or a linker. It could take several different behaviors and stitch them up based on user input (I want to talk about custom interfaces next, but the idea is that a unit can expose several knobs and switches to the player to modify behavior at runtime).
In this way you could generate units specific to the match you are playing based on some predefined code you join together. Or even generate dynamic code on the fly. The possibilities are endless!
OTA Updates
The second idea I wanted to explore today is being able to rewrite unit code over Radio updates. Since the Uxn machine allows to change any byte of ram (allowing self-modifying code) you could add a radio message handler that sends code rewrites over the air. I am imagining a building that works as kind of a command center (exposing a custom interface), and one of the possible functions of that command center is to send code updates to small swarm-like units. These units may have very very weak CPUs since you want them very cheap (since they are a Swarm). So you may want to be able to rewrite their behavior instead of containing all possible behaviors from the start. A small radio handler with a memcpy would provide a lot of flexibility allowing for complete code changes on any unit.
Bonus Idea!
Radio by default is unencrypted, the other side can read your messages and it’s up to you to build a way to hide that information so all your units can decode your messages!
That’s it for today!
Kikai
A Programmable RTS
More posts
- Fully Featured Unit Development & Radio Device5 days ago
- In-Game Editor & Unit Persistence6 days ago
- Customizable User Interfaces8 days ago
- Kikai, Uxn & Debugger9 days ago
Comments
Log in with itch.io to leave a comment.
Data sheets would be cool!
What if there were no difference between "units" and "buildings" at all? and the difference is just the components. This could allow for stationary "units" (like defenses) or movable factories. Or crazy stuff like swarm-spawning motherships.
This is very interesting not only to provide code updates (like strategy changes) but to externalize the strategy altogether. This enables strategies like expensive smart units controlling expendable dumb ones. Also: one important thing in RTS games is intel. What if there were some kind of mechanism to read/write the code on the enemy units? (like the engineer in command & conquer).
This is cool. One way I imagine this working is by creating a unit that listens to the radio and exposes a custom UI so the player can see the data. Maybe it's hard to create code that understands the signal, but maybe this could be something the player could figure out in real time.
Data sheets are definitely in the pipeline!
I think this makes a lot of sense and it really goes in the direction of the game. At the end of the day Units are just a mash of different devices + a CPU + some code. You could have a Factory device, that provides the interface to assemble units and you could embed that in anything as you say. The idea of movable factories generating swarm units is very interesting. (Depending on how we model resource gather it may mean a constant stream of resources going to movable factories! I’m still thinking about how I want to model resources and if they should be factory-local, similar to how factorio works)
Exactly! The strategies are endless when you have control over every part of a unit at runtime (except changing devices, although units with a factory device may be able to rewire a unit to have different devices altogether)
This could be very cool but I wonder how to make it work, maybe by salvaging killed units? You send a unit with some particular device that can extract fragments of code from enemy units.
I literally just wrote another post about customizable interfaces that touches on this and I added your example to the advanced UI device. Check it out!