Zero-K runs on the Spring engine (now Recoil), which is written in C++. This is a great programming language for speed, but a slab of solid C++ is too daunting for the average game developer to dive in and edit. This is especially true with the engine handling so many fundamental systems, such as multiplayer, pathfinding, and physics. Luckily, Lua was added to the engine in late 2006, and as a result, Zero-K itself is written almost entirely in Lua. Lua is a popular language for game scripting and modding. Spring games can include Lua code, which the engine then triggers on a wide range of available events. Once triggered, a Lua script can do things such as modify the game world, or draw things on the screen. For example, the flame-spewing Pyro triggers UnitDamaged to tell Lua to set units on fire. Being on fire is not an engine concept, rather, Lua implements it by drawing flames within a DrawWorld event and applying damage on GameFrame.
Scripting took a bit over a year to add to the engine, and it was a gamechanger. Prior to Lua, new mechanics came from the engine, so they could only be added at the speed of engine development. This was much slower, since the pool of C++ developers is smaller, and engine code is held to a higher standard since it is shared between games. Even worse, engine updates are released periodically, further lengthening the feedback and iteration cycle. The methodical release process of the engine is great for the stability of RTS fundamentals, but not so great for rapidly iterating on new mechanics. Some experimental mechanics were added prior to Lua, although most since fell by the wayside. The problem with engine features is that they are hard to modify or update, so most games evolved past the more obscure ones. Even if you can muster the C++ mana, other games might want the old version of the feature, leading to a proliferation of configuration options that multiply the difficulty of working on the feature. Tweaking the simplest thing can quickly turn into a discussion between multiple games, and everything has performance or maintenance trade offs. Do not take the above to mean that the engine is useless. It supports the complete RTS experience, without scripting, and has robust systems for Lua to interact with, such as the command handling system. Some of the more experimental features are even used by most games, such as bubble shields and area commands (although I heard that COB scripts could technically make area shields in Total Annihilation). There just happen to be many other vestigial mechanics, such as aircraft flares, repulsion shields, seismic detection, and an early form of line move, that are rarely used by Spring games.
Spring supports Lua in essentially two flavours: widgets and gadgets, known collectively as wupgets. Widgets run independently on each player's computer, with their own internal state, and are fair in the sense that they can only see and do the same things as the player. People can even play the same game with a completely different set of widgets installed. Gadgets are completely different, they run as part of the game itself, and implement game mechanics. Most of the flashy new stuff in Zero-K is run by gadgets, such as jumpjets, terraform, overdrive, cloakers, and unit AI, but many "mundane" parts of the game are also managed by a gadget in the background. There was an explosion of widget development in 2007 and 2008, with the creation of many widgets that underpin the basic UI features of most Spring games, including widgets such as custom formations (line move) and command insert (Space + Click). This was mostly being done by players freely sharing code and ideas, rapidly experimenting and discovering what worked. Anyone can install a widget to run on any game, which means you can tweak your widgets from match to match. The iteration speed and direct player involvement has never been greater, and as such, widgets quickly outstripped the engine UI, to the point that engine-side UI development stopped completely.
Widgets were hugely influential on Zero-K, since Complete Annihilation was concurrent with the widget explosion, so we saw firsthand how widgets were upending the design of existing games. For example, Fencer could fire while moving up until I wrote an early version of the autoskirm widget. Players were curating their own UIs, and they were getting more powerful, so the options were to either block it completely or embrace it. We chose the latter, and strove to make a game that survives the pressures of powerful UI, ending up at Fight your opponent, not the UI. Gadgets were also influential, but more on the development side. Complete Annhiliation development was fairly open; once you had commit rights, you could experiment and add almost anything. So people just did stuff. Jumpjets, area cloakers, terraform, overdrive, shield link, construction priority, laser bombers, morph - these were added by people who wanted to add them, without much room for other developers to tell them not to. We attracted people interested in pushing beyond TA, and it paid off.
The initial explosion of creativity lasted perhaps five years, at which point we started consolidating. Most notably, rather than just cram the game full of cool widgets, we started creating sensible defaults, with an eye towards giving new players a functional UI. Widgets moved from something players brought with them, to something the game provided. Gadgets were refined too, and a few, such as experience morph, were removed entirely. Removal was a last resort though, we wanted to retain the creativity. The UI was rewritten in a bespoke Lua-based UI framework called Chili, although some of the most important UI work was not with widgets at all, but with the creation of unit AI gadgets. Unit AIs tend to start as widgets, since it lets players tinker permissionlessly, without any concerns for stability or release cycles. Good widgets come from this system, however, there are two big issues. The first is fairness, since enhanced unit AI confers an advantage. This can be resolved by including all widgets in the game, although this relies on the author being willing to share and polish the widget. Sharing is easy enough, there has never been a problem, but polish is hard. The second issue is also fairness, but at the deeper level of latency, one fundamentally unsolvable by widgets. Widgets suffer from network latency, from ping. This is because players have latency, and widgets effectively run alongside the player. We usually deal with latency as an unavoidable fact of online gaming, and a few 100 milliseconds does not mean much in an RTS, as players can adapt to it. However, widgets are fragile code, that have trouble adapting to delayed commands, causing them to break or have highly varying effectiveness. Essentially, AI widgets are prone to amplifying the inherent unfairness of latency.
Widgets cannot solve latency, so we had to migrate unit AI to gadgets. Gadgets act directly on the state of the game, observing and responding with no delay. This is why there is no autoskirm widget; it is now baked into the game. Unfortunately gadgets are not easily configured, which is why Zero-K now has a large number of unit state toggles, but this is a small price to pay. The gadgets also have to be careful not to cheat, since technically they are omnipotent and omnipresent, but Spring provides ample tools to limit Lua to what a player can see. Gadgets are not just for adding mechanics and polishing widgets; they are also used to polish (replace) the underlying engine. For example, the basic move command, the thing that happens when you right click the world, is a custom command handled by a gadget. The engine offers a basic move command, but it causes units to jam up around waypoints, which is not good enough for the standard of control set by Zero-K. The engine implementation was even worse before Zero-K replaced it, but the engine has improved a bit in response. There are many other examples, such as the engine failing to split resources evenly between constructors. Ideally these things would be in the engine, but until they are, Lua can pick up the slack.
Replacing the engine with Lua is not without its challenges. C++ has much better performance, so we are careful to use as much of the power of the engine as possible. Luckily, large swathes of the engine are exposed to Lua so, for example, the custom move command uses Spring.SetMoveGoal rather than attempt to find paths for 1000s of units on its own. This is a fine division of labour, with the engine handling the resource intensive tasks, leaving lua to stitch together the results. The above barely scratches the surface of Lua. The entire main menu happens to be written in Lua, using the same framework as the ingame UI, but this was more a matter of Lua mana than a technical necessity. Units animate with Lua scripts, and entire opponent AIs were written in Lua. But perhaps the greatest ongoing impact of Lua harkens back to the creative explosion of 2007: Zero-K itself has many mods with many new features that are only made possible by using Lua to delve deep into the engine. So if you want to write some Lua, rather than read about it, consider giving modding a go. Index of Cold Takes