In several previous portions of Building A Better RTS I’ve talked about templates. But what, exactly, is a template. In short, they’re a pre-stored collection of buildings (or units, in which case they’re a group) which can be saved in a library. You could save them either from battle (perhaps with a shortcut key), but the primary editing would be done in a “sandbox” mode, with no enemies. They can be shared between players (they would be XML files), and have a very simple UI –
You have the list of things you can place into the area on the left, a map area in the upper section and the ability to set orders (i.e. fire at will, or a waypoint for a factory). On the right, there’s a build order which can be dragged and dropped to re-order it, this order will be followed by construction units. There will also be an option for the default number of construction units – up to, perhaps, five – that the template “wants” to build it.
This thus ties into the distributed building system discussed in the first week. You can drag and drop your template or group from their tab on the build system onto the battlefield (as long as you can, of course, build all the units or buildings, otherwise they’d be greyed out). This template, dropped on the battlefield, will then automatically be built in the given order by builder units, or for units the factories will build the units in a group and send them to the target location all without needing to give direct orders to the builders or factories. You would also be able to rotate them like a single building – any units or buildings over an invalid spot would simply not be built!
As discussed last week, week four, AI creators would also be able to use these – and they would perhaps be even more useful as long as they are not overused – template and groups embedded into an AI are not available to players unless they manually copy them out – and the AI can assign a build chance to a given template or group, as if it was a “unit”. Map-specific AI’s could even have notations that they were limited to certain areas of the map – those with the AI-zones placed – to ensure that some specific templates (for example, an artillaty battery) would only be build where suitable (on top of a hill).
There is also another reason to use templates in they create custom formations – a template will automatically position it’s units in the positions given, ensuring that exact formations can be created. On the other hand, while it would be technically possible to mix buildings and units, I would discourage that being available for player (but not AI) usage – you would be mixing factory output and builders in a single template, which complicates things and probably is somewhat too powerful a tool for players.
Templates are thus very powerful tools, for both the player and for AI’s, to skip routine placements of say, a firebase, at every spot at which you want one and it saves time better spent on the actual game strategy. Equally, groups of units can be ordered up, and placed in jump-off areas, ready to be sent into battle. All of this also assumes that the enemy isn’t interfering, of course…
Moving on from templates, let’s talk about building units, and indeed how units would be built from factories. The core of the distributed build system, as we talked about in the first week is that we no longer need to select a building unit before we place buildings or units down on the map. We simply place the building or units onto the map from the list, and the game AI will then send the builders out to build those buildings, and construct those units and move them into place – this is similar to the system used in Dungeon Keeper, as mentioned in week one. The player should be able to see, at a glance, how many building units of each type he has – and how utilised they are. That is, the number of units active, idle, set to patrolling and indeed the number of units set to manual orders, and by clicking on each you can jump the camera and selection between those units. This system also has a number of consequences, which must be handled.
So, first, let’s talk about build assistance. There are several ways in which this can work. In some games, assisting building by using additional construction units is not possible, or is only possible for buildings and not units. This model, while simple, does not really suit a strategic game such as that which we’re building.
On the other hand, if you look at Total Annihilation or Supreme Commander, there is a certain degree of inefficiency in using multiple building units, above the travel time for sending them there – you get less build time and some resource waste by using additional building units. The problem there is that we are using a distributed building system, and we might waste resources without knowing it. Hence, let’s talk about a compromise – while additional building units will add progressively less to the build speed, they don’t consume additional resources to do so! We can also ramp the loss up a little faster than it occurs in games like TA and Supreme Commander – perhaps more than a half-dozen builders is not worthwhile – this helps keep build speeds in the reasonable range even with build assistance (which is why some games disallow build assistance for factories) and helps prevent over-focus on a single factory or even big building, for the overall strategic game.
We could also give the AI a little bit of smarts – unless something is designated as a priority (as described below), then if the player runs short of resources, additional builder units should pause themselves, rather than have building stop and start – or rather, slow down overall, since we can do better than Total Annihilation in that regard, and give you a big warning on the distributed building control panel about the resource shortage.
In any case, for the UI this could work, in a distributed building interface, as follows. Unit-creation buildings could have a slider setting for how many builders should assist them, while building units would be affected by how many times you left-clicked to place a unit – with a marker appearing signifying an additional building unit for each additional click. Right clicking on the area would remove one.
Second, we need to look at how priorities for building will work in a system of divorced direct building control. While we can jump in and take individual units or factories out of the central control if we, say, want to have something built now, this is less than ideal as we have this nifty system to avoid the player needing to do that in the first place! Instead, let’s look at how we can add some advanced control modifiers. If we want a building or set of units built now, ahead of everything else, then we should be able to set a priority. This would be when the player holds down control when setting a building, and it should be marked (with some kind of glow) on the UI.
Nearby building unit(s) will drop whatever they are doing in the distributed system – including building or patrolling – and come and build the building. They will ignore resource shortages and keep building, as described above, even when the player is in a resource shortage situation, and as described below they’ll keep trying even under enemy fire. It’s design for things you absolutely need to have built now. As a note, it’s entirely intended that overuse of this could lead to the player wasting a lot of build units or time. Things which are less urgent, but which you want inserted at the top rather than the bottom of the build queue could use a different modifier – perhaps alt – and it would then simply then be the next building on the list. In fact, existing designated building sites could be ctrl or alt-clicked to change their priorities.
Thirdly, we also have to look at how builders will behave when they are being destroyed under a distributed system. Rather than sending endless building units to their doom, a distinct possibility – some situations in Dungeon Keeper can lead to this – there should be an area which builders under the distributed control system avoid after a building unit is destroyed. The area avoided could be some kind of mix between a circular area and based on the areas/“zones” discussed in week three, and last for perhaps a minute – it would show up on the map in command view, or if necessary an additional filter over command view (left control as well as shift?). If necessary you could override this with manually commanding a builder to create whatever you needed, or priority builds would override this and keep sending building units – which again, yes, could easily lose you the game if you’re not paying proper attention and that’s quite intentional!
Finally, with this sort of build system, we would also have to keep the player informed of how many factory or build units of each level he had, and how long each type of them will take to finish their build queue. For that matter, the player could be warned if there is excessive travel time in some areas (again, left control as well as shift, but showing up as a blue zone rather than the red of destroyed builders). The player could then order additional builders direct from the panel by clicking on their icons.
The overall UI for this would not again need to be complex, perhaps something like this; (to the upper right of the screen?)
And that’s all for this section of Building a Better RTS. I hope you have some idea of how both templates and the distributed building system would work, and some idea of the challenges which would need to be overcome from a UI perspective for the player to use this, as well as the powerful tool which is gives AI designers.