User interface design is, honestly, one of the most difficult parts of creating a game. Every button has a profound impact on how people will be motivated to play (or not play) a game. I suspect this is why so many games seem to almost consciously decide not to experiment too radically with UI. It’s so much easier to just build it the way people are used to rather than building it the way that perhaps it should be. We’re no different; Dredmor’s UI has a lot of flaws that we didn’t see at the time of development. For instance, it turns out that Inventory Management isn’t actually a super fun mini-game. Even then, we completely overhauled the Dredmor gameplay UI some 4 or 5 times before we settled on a system which is still flawed, and to this day leads people to play the game in a way that detracts from the experience. Such is game development.
We are doing our best to apply the lessons learned from Dredmor to Clockwork Empires. Not all of these lessons are applicable, of course, as CE isn’t a Roguelike — and there are a lot more moving parts to control. Granted, there are also a lot more strategy/management style games with real-time mouse-based UIs to draw from, and we have played a ton of them; however, by virtue of making a game that crosses the genre-streams a bit, none of these systems perfectly fit the needs of CE. For instance, dropping a Starcraft control scheme on the game would be inappropriate because Starcraft is (arguably) about competitive micro-managing, optimized build orders, and a bit of gambling on the current “meta”. In contrast, CE is ideally about creating stories within its simulation.
To do that, we try to draw almost all of the systems somehow into the personalities of the people. You don’t order a person to go make a house as in Starcraft; Rather, you let them know that you’d like one and if they’re not drunk, or busy fighting capybaras in the swamp, maybe they’ll do it. We decided early on that we were going to try to make all interaction with the characters a step removed from the characters themselves to allow their personalities to be demonstrated through their actions. So rather than directly controlling units, CE will have players create orders as distinct objects which will be carried out to the best of the simulated population’s ability. These orders are generally tied to the world itself in the form of buildings and points on the landscape (“Chop down that forest”, “Build a Brick Factory with three chimneys here”).
Tying orders to geography has its limits though. If you need to select a barracks to tell a military unit where they need to be, but the barracks is on one end of the map and the soldiers tied to that barracks are on the other end, you’re going to have a bad time. So there are situations when it is necessary to break the purely map-based scheme by introducing abstract UI constructs – in this case, a globally accessible control frame that allows you to select different squads, load them out with available gear (more on that later), and give them orders regardless of where they are on the map.
The decision to split UI metaphors can be a dangerous one and requires careful consideration. If we’ve got a building-tied interface and a global floating interface, people now have to guess which of the two places they are likely to find the controls to do what they need to do unless we find a very clear line to differentiate what kinds of orders go where. Power users can learn to use any system we design, but I want my mom to be able to play Clockwork Empires.
So let’s talk a bit about this global control frame: think of it as your settlement’s RPG character sheet, but instead of skills, stats, and equipment you’ve got different people with their individual qualities who, when organized differently, affect how your settlement works in different ways.
Within the scope of the military side of the system, people who enlist or are enlisted in the military will form themselves into groups. Lower class military will just form squads of soldiers, middle-class characters will act as NCOs who supervise a squad, and if you eventually assign an upper-class individual to a military position, they will become an officer in charge of organizing platoon-sized groups. What’s more, the personality traits of the officers in the chain of command will impact how your squads undertake various tasks (and if you have really poorly trained units, their own whims will have a stronger priority).
We also need to consider things like vehicles and special equipment. Specifically steam-armor, artillery pieces, perhaps some sort of mechanized steam transport, et cetera. Having to equip these to individual soldiers would muddy the interface like crazy. Every character will have equipment, but if you could actually optimize loadout for a military of 25 or so guys – that might just throw their musket in a ravine anyway because they’re mostly autonomous and/or mad – would be an infuriating optimization problem.
So, you ask, how do we give out that lovely steam-armor?
Our current solution is to give every squad it’s own “inventory”, of sorts, which consists of just one slot. You can choose one special piece of equipment they can use, be it a Gatling gun or a steam-armor suit, and they figure out how the squad is going to use it best. This collapses a problem of potentially hundreds of inventory slots to maybe 10 at most, while giving your military the ability to specialize squad roles.
Civilians use the same system, but instead of combat squads, they form work crews for the various job assignments (making beer, building walls, chopping wood). Their equipment slot items will be a bit different: things like an auroch-drawn cart or a steam powerloader.
So now we have one UI scheme to in-the-darkness-bind-them and allow players some control over which units are assigned which tasks that’s mostly opt-in, has a few choices for customization, and can be accessed from anywhere. Buildings are now the place where you go to designate which commodities you wish to turn into which other commodities (and other behaviors for things like fixed artillery turrets), and jobs that have no specific building for their functions, such as an order to collect lumber from a forest, will be tied to “flags” on the map which will have all of their direct functions attached to a menu specific to each flag. The buildings menu and the flag menu will both have some version of a hyperlink to the global unit control frame that shows the characters actively working on that task.
We’re running with this until we hate it, as always, this is very subject to testing and ruthless iteration. If it’s something we’re happy with it, we’ll make some prettier pictures for you guys.