Abstraction: Managing a Large Economy and Large Armies

In my opinion the biggest and most important feature in Ashes of the Singularity is not the number of units that will be in play; it is the command and control system that players will use to manage such large armies.

The devs have publicly announced that they will use a "battlegroup" type system to group units together into larger entities in order to facilitate controlling large numbers of units. This is a huge step forward for RTS games, and its significance cannot be overstated.

However, in some other areas I am left with the distinct impression that Ashes is still locked into a traditional RTS line of thinking when instead the principle that the player is controlling an entire WAR, and not a single battle, should control.

For example, the hotkey system used to produce units. Although a very functional hotkey system, comparable to several other RTS games like Grey Goo, in my opinion Ashes of the Singularity needs something more. In Ashes it is possible to quickly assign unit construction orders using the keyboard, such as QEQ to build a Hyperion. However, in my opinion this approach is fundamentally misguided.

 

Automation

Instead, Ashes should be designed with the assumption that the player's UI should manage the low-level actions. This includes unit AI like moving and shooting primitive commands, but should also include basic economic actions such as issuing individual unit construction orders. 

Under the current Ashes system the player is still manually constructing individual units. Which, even if units are created in squads of three or so, is still a lot of keypresses to build units manually. 

What Ashes needs is automation to save the player from manually executing such basic commands a large number of times. This will free the player's attention to focus on the actual war, and make interesting strategic decisions rather than spend the entire game building units and ensuring resources are being efficiently managed in the small scale.

A simple and familiar way to do this would be a simple "infinite repeat" toggle. That would be functional, but in my opinion is selling the potential of Ashes short.

 

Abstraction

The best way to implement this type of automation is by formally declaring that players should be working with higher level logical entities than individual units and individual structures.

What do I mean by this? In almost every RTS game created to date the player controls individual units, mainly using selection and issuing primitive orders to groups at a time. Control groups make this "group primitive" order system more convenient, but introduces a new requirement that the player add and remove units from those control groups to maintain their usefulness.

Ashes should allow players to create groups which have significance for controlling their behavior, not just making it easier for players to recall group selections. For example, a group of factories would work together to fulfill a large production order, splitting the unit production between member factories.

As a more useful example, a base might be composed of several building sub-groups. This would allow the player to build a complex base somewhere else on the map easily. And it would also allow an existing base to receive more complex orders. Such as instructing the base to increase its production capacity without having to hunt for engineers inside the base. A base might maintain a specified number of engineers and replace them if they are lost, as well as functional modules for production, defenses, logistics, base garrison units, air force interceptor or bomber squadrons, repair units, and anything else the base might need.

 

Player Focus on the War, not Small Scale

Long story short, every time the player has to manually build a unit, that player is performing a chore that a computer could do much more effectively. A hotkey system makes this chore faster, but it remains a chore.

Liberating the player from these chores allows the player to focus on the war, on the strategic scale. I want to be able to specify what I want done, and have the UI implement that decision, like staff officers for a general.

The player should give orders more along the lines of "that army should go there" or "this base should supply reinforcements to that army" or "I want an airbase built here." This is a very different approach from the classical RTS system of issuing orders like "move" and "attack."

 

Conclusion

Ashes intends to have more units than any RTS ever. Without equally advanced command and control systems to allow players to make effective use of so many units, players are going to exercise very little control over their units because they won't have much choice. It's just not feasible to carefully manage ten thousand units. But a single blob of ten thousand? That much, a human can do.

However by using AI to augment the player's management ability, players will be less burdened by tasks like raiding an outpost, performing an air strike, or building a new base. As a result, players' ability to be active and spread out will be greatly enhanced, which is vitally important to avoid players just giving up and making mindless all-out attacks with the largest blobs they can muster.

24,841 views 8 replies
Reply #1 Top

I don't think it is wrong to think about what the UI can do for the player, but I think we need to be careful not to replace the player.

If you have an extensive automation system you remove most of the actions that RTS players are used to, which might not be very popular.

"I want an airbase there" is a nice abstract task, but how do you define the exact definition of "airbase"? Will the AI just make some standard template? A customized one that the player defined outside the current game? If it is just a standard template you lose a lot of the gameplay aspects of planning out your exact base layout and other details. These details are what make out the largest part of RTS up until now. If you allow the player to define the templates outside of the game you risk that in the most extreme version you will end up with a game where players just queue up their predefined win-templates and then go afk while the AI wins the game for them.

So it's a good thing to think about, but it is very hard to get right. My first though is that the UI should provide tools to automate tasks, but the exact definition of the tasks needs to be still in the hands of the player and not in the hands of an AI programmer.

+1 Loading…
Reply #2 Top

I am absolutely in agreement with your assessment of wanting to augment the player's execution ability without impinging on the realm of the player's strategic decision-making. But I think that's relatively easy to do.

 

For example, regarding building units. Construction is something the player is likely going to be doing constantly in every game. The actual decision the player makes in construction largely consists of two major decisions: placement of production facilities, and enqueueing units.

However the amount of player activity necessary to implement these relatively compact decisions is actually quite large. Deciding which units to construct could, in theory, be done fairly abstractly. Then, the AI would encapsulate the actual assignment of build queues to factories.

 

As a very simple way this might work, suppose you were to replace all busywork of selecting factories, fiddling with build panels/hotkeys and enqueueing units with a flat inventory of the player declaring generally to the UI "this is the list of things I want."

For starters, the obvious case, the player says "Factories: 2" and your engineer, or team of engineers, sets about building the factories themselves. This is trivial. It also doesn't help that much except it saves the player from finding an Engineer or using a control group for a team of engineers, and allows dynamic assignment.

On to the more interesting case. So the player says they want 50 Brutes, 25 Archers, 2 Aegis, 4 Energizer, and a Hyperion. The UI sets about enqueueing all your factories with orders necessary to bring your total unit count up to those levels in each type. If you have 2 factories this is a pretty simple task of handing a unit from the list off to a factory when it completes a unit.

But, and this is important, when one of your units is destroyed, that unit no longer counts towards the list of units you actually have for purposes of determining which unit a factory should build. That unit's "slot" is now vacant. Therefore, the factories will get around to automatically building its replacement without any player involvement at all.

 

Now, I am not suggesting a big window that lets the player set a number for every unit type in the game. Although functional, that would be pretty unwieldy. But once you implement the ability for the AI to take a list, break it up into factory tasks, and get it built, you can create that list by other means.

For example, the UI might add together every battlegroup's missing units and reinforcement requests to compile a single, large list of your side's "desired production" and do the same logic to get those units built.

If you have three battlegroups which you have defined as being the same as the group of units above, then as they take losses, your factories will dynamically build reinforcements matching the units that were destroyed.

And, the same system would work flawlessly if the player decided to expand one of the battlegroups. Say you specify you want one of the battlegroups to have 100 Brutes and 37 Archers instead of 50 and 24. There are now 50 Brute production jobs available and 13 Archer production jobs available for factories to begin once they finish their current job.

Reply #3 Top

The big question that that creates in my mind is: "where?"

If you just say "give me 50 x and 25 y" where do you want them? You'll need to create at least some waypoints such that the AI then can place the units in the queue of appropiate factories.

The same holds true for factory placement. "I want 2 factories". Where? At the frontline? At your base? If you have to mark the location you just as well could do an area build command, basically placing the factories by yourself.

 

Additionally I am somewhat wondering about the real use of a "the AI reinforces my army to always have exactly 50 of x and 25 of y".

Why would I want that? I want to make as many units as possible in the ratio 2:1. No need to stop production usually just because I reached some specific number.

The more units the have the better.

 

 

Reply #4 Top

The simplest approach would be to design the system so that it can supply an appropriate "where." For example, have each battlegroup request units for itself. Those units would rally to the group's location (which may be moving). Those reinforcements might even use transports automatically, if they are available.

Likewise, a base would be a group of structures that would also supply a "where" regarding building those factories- where the base is. The assumption is that the player does not care exactly where, as long as it gets built in that base.

 

In the same vein, it would make sense to have default standing orders as well as dynamic orders. Like having a default list of units on infinite repeat, globally. Like a ratio of 2:1 of two unit types. When there are no special jobs to do, factories would default to whatever the player has specified is the global default. You would only need to set this one time to apply to all your factories, and if you change it, then it updates all your factories simultaneously.

 

Reply #5 Top

Great thoughts everyone.  

Here's my two sense for what they're worth.  I think automating base/factory construction would be tough.  My feeling is that people like mucking around in their bases and setting them up the way they want them.  It may be that you've just blown my mind, but I'll give it some more thought.  I do like the concept of being able to queue up structures to be created by constructors rather than having to instruct each individual constructor what to build.  There may already be a way to create such a queue that I may not have paid enough attention to see yet, but it's a feature I'd really like to have. 

A simpler approach might be for players to maintain control of base building, but put a "meta group designer" in players' hands.  The concept would be along the lines of the ship builder in GalCivIII.  The way I see it in my head is that players could play around offline with assembling meta groups of various unit combinations, see what the buffs would be, and then set the group.  In-game you could build your various factories and then task those factories with building Meta Group 1, Meta Group 2, Meta Group 3, etc..  Once you set the build orders the factories would pump out your pre-selected unit numbers.  This doe snot like it would require much AI horsepower, but it would let players customize their builds, focus on more strategic issues than unit building, and maybe make me care about building a bunch of metal/reactive storehouses everywhere so that I could build up resources during battle to make my killer Meta Group build #5 or w/e.  This approach would also add a new level of strategy to the game and give people something to play around with offline.  My sense is that a lot of strategy would go into optimal builds, since you are weighing manufacturing time, resources, buffs, etc.  People might even customize their builds to specific maps based on the resources available and/or their opponent.   

Quoting tatsujb, reply 2

that repeat queue button is desperately needed. but then again so is pause and cancel so I imagine it's only a question of time.

You can already cancel by right or left clicking (one of those) on a unit in the manufacturing queue.  Pause would be nice.

 

 

Reply #6 Top

Just to clarify, I am not suggesting that players should lose control over their units or bases. If a player manually selects a unit and gives it an express order, that order should supersede all commands from the UI.

However, the ability to effectively manage large groups of units and entire bases without having to select individual units allows the player to implement their decisions without necessarily needing to always rely on finding, selecting, and manually ordering the specific units to do the task. Without a unit selected, the player would gain the ability to generally order that a certain task should get done, and the UI will make it happen.

 

So far the unit production UI logic has three bins for unit production. At the lowest level, a "global policy" queue for a default mix, which will presumably always be an infinite repeat. Above that will be "normal build" orders, where a dynamically generated list of specific units to be requested by rally points, battlegroups, and other sources compiles a list of production jobs that need doing. And then the third bin is a "special order" list which allows the player to expressly command specific production right away, with the highest priority, and no ability to repeat infinitely.

In this way the UI logic layer would sit on top of the existing "primitive order" layer. It can give primitive orders too, but it won't override more specific orders. 

 

To express this principle more abstractly, more specific orders will have priority over more general orders. If you set a global policy (like "idle factories build 2 Brute:1 Archer ratio) then that is the most general type of order. If you have a more specific order it will override- such as giving a direct order to a base to build a battlegroup composed of 50 Brutes, 30 Archers, 5 Energizer, 2 Aegis, 1 Hyperion. The more specific order supersedes the more general order.

This also applies to primitive commands, which are the most specific orders possible. If the player issues an express order to a unit to do something, it will ignore its UI logic and do it, if legal. Such as selecting a factory and expressly ordering it to build 10 Brutes. Even if the base is currently ordered to build 100 Archers, that factory has orders directly from you to build Brutes instead. The other factories in the base will continue without that factory until it finishes your special Brute order.

Reply #7 Top

Good posts!  We're actually planning on implementing a fair amount of what's been discussed; just haven't gotten that far yet. :)