This classic Gamasutra article grabbed my attention again recently whilst pondering some UI issues with my RTS concept. The article is entitled “Too Many Clicks! Unit-Based Interfaces Considered Harmful“.

From the introduction:

“Computer games traditionally have a player control one or more units on the screen. In early games, each player controlled one unit. As CPU power grew, players controlled more and more units. Today, a player might have hundreds of units, each one of which they must control individually. The unit-based user interface (UI) is no longer sufficient. This article will suggest a different way of thinking about UIs, and will discuss how to compare one UI to another, or one UI to the theoretical maximally efficient UI, to tell if your game can be improved. I’ll use examples primarily from strategy games, but it applies to UIs for programs of all kinds.”

Enjoy.

Well it has been some time since I last posted something on this blog. My time has been spent on my OU studies, work and various hobbies. RTS and game/UI design never really leaves my mind for more than a day or two at a time, however.

One of the issues surrounding around RTS games as they rapidly evolve is how to deal with their ever increasing complexity and scale. Many RTS’ have chosen simply to stick to old tried and tested formulas, tweaking the graphics and interface here and there but generally sticking to the same old boring micromanagement formulae. Supreme Commander is certainly different in this regard but there have been other attempts to reshape RTS gaming. Homeworld was one of the first to attempt to forge a totally new direction, for example.

In my opinion, the barriers to really scaling RTS are three-fold. The first is one of basic computational restrictions, added burden to the CPU as we add more units, better physics, depth and complexity. This is something beyond the topic of this blog.

The second is the bridge between the casual and hardcore gamer. RTS games are notoriously ‘hardcore’. Is there room for an RTS which caters to the more casual player, or can even reach out to both equally well? The generally steep learning curve is one aspect to this but the other critical one is GUI…

…Lastly, the user interface has become burdened by the sheer number of game options and the in-game variables have increased along side jumps in the hardware which allows this. So, we have seen wonderful advances such as strategic zoom, multicore threading, macros, templates, dual-screen, mouse/key press efficiency, UI customisation & add-ons etc.

These are all great but I feel we are approaching a critical juncture. The relentless build-order or unit-stat memorising, hyper-clicking and so on, these things cannot continue to evolve past a certain level of optimum design efficiency. I think what we need is a total reassessment of the way RTS is played, especially how top-down orders are assigned to and then carried out by the AI.

I shall continue with an analysis of some possible solutions during the course of the next few posts, so stay tuned.

Traditionally, RTS units are non de-constructible. What I mean is that the actual units themselves, in almost all RTS games I’ve played, live a short ‘0 / 1′ alive/dead existence, with a certain amount of damage points (shown as health-bars) to represent damage in a fairly abstract way. Most RTS games display diminishing health/damage of a given unit with some kind of cute preset animation. For example, in Total Annihilation the units billow an ever greater amount of smoke. Upon actual death they possess a variety of explosion animations to represent their demise, such as breaking apart or full blown explosions with flying debris!

In Supreme Commander we see pretty much the same system but with fancier deaths or damage animations. The experimental units in particular go out with a real bang. I’m going to propose a more modern and importantly, more fun system in terms of actual gameplay mechanics. It is also, I think, a more realistic way of doing things and fits in with my RTS concept.

De-constructible Units.

The case for de-constructible units is such;

• Contributes to gameplay and emergent dynamics of a warfare ’simulation’.
• Adds certain character and depth to individual units.
• Provides intuitive realism and deep tactical and strategic considerations.

The main problems are those of implementation of the concept in a way which is balanced and intuitive to the player. For example, if units are de-constructible, wouldn’t the different shape or form of units’ chassis or body parts play an unfair role in their defense? This is certainly a concern. One would simply build only the unit with the most appropriate physical design, a giant walking shell for example!

Before I propose some possible technical solutions I’d like to talk more about the advantages of such a system (of course at the end of the day gameplay comes down to personal preference and so forth.) The first point I made in favour was that it should contribute significantly to gameplay dynamics and warfare realism. Now, let us suppose we take our army battalion or fleet of ships into battle. In my system each unit could take actual damage. For those perhaps unfamiliar with my RTS concept you might want to look into the way I propose custom units are created in the first place (via re/attachable ‘modules’) and how they ‘grow’ and acquire veterancy over time.

Clearly we would set some limits here. The units are NOT actual real-life miniature simulations, down to every last minute detail. They are not scale models of larger real-life constructions, nor should they be. That would be no fun at all. Nor when I say the game should be a warfare ’simulation’ am I talking about simulation in the sense of, say, a flight simulator. So we use abstraction to represent realistic concepts in a way which is fun and realistic ‘enough’.

Energy-cell / ‘nucleus’ concept

The way to best visualise my system is for you to imagine, just for now, perfectly circular (or spherical!) units. At the core of the unit is its ‘nucleus’ or energy cell. Surrounding the small nucleus is the unit body which can take damage, it is physically malleable - could be cut clean through by lasers, or impacted by a rocket blast leaving a small crater-shaped ’scar’ etc etc. I suppose in technical design terms there would be a specific number of tiny pixels representing the units’ mass (think radius for now) which can be destroyed, regrown, added to etc.

The nucleus or what I call the energy cell is just that, it contains the ‘energy resources’ of the given unit. Think of them perhaps like battery operated robots. Once the energy is depleted the unit is ‘dead’ - in game it becomes a wreckage pile available for reclamation etc. When moving, building, firing weaponry or performing almost any task a unit consumes its core energy. If the outer mass of the unit is penetrated through to the energy cell, the energy will quickly leak out (or wildly ignite/explode?!!) and the unit is effectively ‘dead’. Now, the energy cell of units regenerates fairly quickly over time so units are largely automated but follow natural rules to do with energy use so on. If a unit has depleted its energy it will need to recharge by keeping still, or being repaired by other engineer units with spare energy etc. It would also be progressive in keeping with the style of this RTS concept so that perhaps less energy = slower movement or less firepower proportionately. Supreme Commander uses a similar if far more basic system for aircraft, for example, which must refuel by landing once in a while. They also slow down when forced to fly with low fuel. So this isn’t really such an alien concept, I am just extending it further.

During battle, this system might have interesting consequences. A sudden attack from the north, for example, might leave the northern face of ones fleet badly damaged and would be seen as a priority target for the next attack. Damaged units could be quickly recognized on the battlefield without annoying health bars hovering atop each of them. One could maneuver troops a certain way in order to pick off weaker areas in an enemy battalion. Naturally, a system such as this would need to provide a way to best structure units within a group so as to keep their most damaged side in the least vulnerable position. This is also the reason the unit structural physics must perform in a circular/spherical manner. It makes certain that each side is equally vulnerable to attack, no sticking-out edges (squares, triangles etc). This is not to say units themselves in this system would actually look like 2d circles or 3d spheres! One can imagine units that look just like traditional RTS units whilst the underlying physics operates very differently.

As well simulating troop supplies or ‘morale’ (troops get tired~energy cell depletion) - it is also a practical answer to automated repair and maintenance of units. Units (perhaps operating under the same group hierarchy) could maintain each other by ’sharing’ their individual energy cell supplies, or at least those with repair/engineering modules. Individual units would be able to repair themselves at a high energy cost but it should be slow and better achieved by returning to a nearby base, or to other units with engineering modules etc. Overall we can see a system which more accurately mirrors real troop management and command and emphasizes macromanagement, which is less intense and I think more fun than micro-intense RTS games today.

Stay tuned for part II

Those of you brave enough to browse my scrappy notes may have noticed that I was brainstorming a resource system for my futuristic RTS concept. I am still adamant that the more logical option, despite being a HUGE fan of T.A and Supreme Commander, is the single, not dual (energy/metal) resource system. The main reason for this is that it fits in with my ideas for linking the expansion of ones empire very directly to resource income in order to promote (but not insist upon) continuing growth.

This single resource which could be regarded as ‘energy’ or ‘finances’ etc, then links into two main areas of the game; research and production. Research is centered around the classical turn-based Space Empires-esq ‘tech tree’ system. Production is of course, anything to do with the actual building, maintenance, repair or reclamation of items within ones empire.

As much as I love T.A, I want to get away from its reliance on good eco-management skills and make RTS even more action packed and strategy/movement centered. The building of energy-metal converters and so on is a fine concept but it does detract slightly from the core notion of warfare and expansion of empire.

A general on the battlefield may be concerned with feeding, housing and entertaining troops, but that is a secondary concern to his or her main directive - to win the battle. These tasks would probably be designated further down the chain of command. I wish to simulate this using very simple core concepts. In my mind one can only achieve this with a single resource system, tied directly to the expansion of empire. In this way one is able to control and influence resource management in a less intensive and more strategic manner.

The ‘base’ unit is a core component. The base is a ‘generic’ unit which can be laid in almost any position on the map (according to strategic or economic significance of the terrain) and modified heavily just as mobile units can be - using re/attachable modules (researched/upgraded via the tech tree.) Immediately after placement the generic base unit gathers/harvests resources according to its ‘rate’ and ‘area’ of income. I’m not going to get too much into the mechanics of these base units now but just assume that there are many variables and ways to modify the base unit, as well as to connect them closely or at a distance from the main base/empire to control efficiency, security etc.

So resources begin flowing in. One might begin building defensive units to protect ones empire or patrol the borders of claimed territory. One could also invest in research, such as better engineering suites of bases (in order to ramp up production of resources) or in unit weaponry (to prepare an assault on ones opponent). Both choices would drain global resources. I have deeply considered resource storage. Initially I was in two minds about how to manage the problem (i.e more resources are coming in than available storage, therefore resources are wasted).

My first thought was to think ‘traditionally’ - about storage units, whether as an inherent function of a given unit or via the attachable modules I have proposed (possible upgraded via the tech tree). However I believe a nice way to automate this process in the style of this futuristic RTS concept is to simply integrate it into the game mechanics. The way I have tried to achieve this is through bases which, just as units, actually ‘grow’ and gain power or veterancy over time.

When I say grow, this is in part actual physical growth in the size of the base (a neat way to visualize the relative status of a given base without resorting to UI menus etc.) As it grows it stores more resources accordingly to prevent waste. It also means that over time your base units, if protected, actually spread out slowly like a creeper plant and gather more and more resources for your empire. Their efficiency is gradually improved, as is the efficiency of any attached modules (one may create a fortress of it, or a mass production centre according to need). However this also has a catch, you suddenly place a lot of proverbial eggs into one big basket, so to speak. It makes your nice fat swollen base-fortress a tempting target! What a huge resource blow that would be, to have your #1 production base bombed suddenly out of existence! You’d lose storage capability as well as resource income. So a natural balance is created.

There is also another layer to this, which again I shan’t go into too much detail about here. Your bases can be ‘connected’, via a sort of resource pipeline (think oil, electricity or broadband connections!). This serves several vital functions:

• Distribution of resources during economic growth to all the empire.
• Provides a ‘backup’ of excess resources gathered at a specific (high-value) location.
• Injects enormous depth, realism and strategic potential into the game (i.e cutting off supply lines).
• Adds tactical choice and complexity but in a clear intuitive visual form.

For example, rather than continually expand a certain base, you could choose to redirect the resources back to other bases that may be less productive, which are connected via these ‘pipelines’. Rather than one base grow to 200% of its original size, for example, you have 3 or 4 that each expand just a little bit. Or you could swell a single base to great size, creating a vast fortress or shipyard at the borders of your enemies territory. Being able to drag-and-drop these supply lines from one base to another (at a high initial production cost of course) would be quick and simple. One might draw a line or curved path (see my draw tool concept) to avoid certain areas or let the AI choose the most efficient (straightest?) connection path. Multiple supply lines could be laid and bases interconnected to streamline efficiency through the empire. Protection of these supply lines would be key. They would need to be vulnerable to attack but the very fact that they are basically ‘long thin lines’ which can be broken at any single point along them, clearly adds a nice element of risk to laying them in the first place.

Very distant bases can be connected, but the ‘pipeline’ costs would of course be greater and risk of attacks along them higher. In terms of resources and production I think the idea fits well with my higher emphasis on strategy and action, with economic concerns secondary to yet without excluding, the other. It ties them together intuitively. As players we’d spend less time furiously shift-clicking or queuing up intricate lines of wind farms, solar collectors, metal extractors or energy-metal converters, constantly trying to balance the two (all whilst fending off an assault of tanks and artillery from the west!).

Clearly there are questions raised about technical implementation and the gameplay implications of this concept and I intend to address specifics when I have more time and if there is sufficient interest. Please feel free to post comments or leave some (constructive!) criticisms. As I slowly unravel my RTS concept throughout these posts I hope that the pieces of the puzzle will begin to reveal the bigger picture. My next post will probably be regarding the units themselves and how I intend to break from classical (and I think absurd) notions of hit-points and what I call ‘non-deconstructible’ units!

I’ve changed the name and direction of this blog to something more appropriate. The T.A-Bugfix community has once again gone into inactivity/hibernation, although games are occasionally being played so newcomers are still welcome to get in touch for a game and grab the files (top right!).

I’ll be focusing on one of my mental hobbies - thinking about the application of true strategy in video game design, particularly RTS games but not exclusively. At some point soon I *WILL* update the concept page with something readable!!!

I know this article has been floating around the Supcom/TA community for some time but I had to link to this interview with Chris Taylor, for two tantalizing reasons.

We’ll return to the SC universe again, but we’ll just have to see when that day is. Maybe when everybody has 64-bit processors…

and…

I’d like to develop something casual, but a little more sophisticated, not just a one-play session type game, but one that persists online, something where you get a score you can track over time like an MMO.

“The Tangled Concept of Balance” - A superb article over at Gaming’s Alembic about balance, fairness, strategy and style with regards to RTS games. Excerpt:

The first concept generally associated with game balance is what I’m going to call fairness: an equal chance of victory given to all parties. A fair game is one in which no player begins at an inherent advantage or disadvantage, except due to intrinsic qualities of the particular players. Thus, a more experienced or skilled player may be more likely to win than a novice player, but there is no inherent advantage or disadvantage to being assigned a particular player slot (for example, we would say chess is fair if there were no inherent advantage in playing white or black).

Fairness, as I’m [defining] it, allows that players may make choices which are more or less advantageous to themselves, and that the game’s outcome may be affected by random events that favor one player or another. However, before the game starts, there is nothing about the game that will help you to predict the eventual winner…

Highly detailed and well written post if you ask me. Read more…

Also check out “Opportunity Cost” over at the cool Design.Wrong blog. Very interesting delve into how costs affect gameplay and quote “the traditional 3 early game strategies (expand, rush, defend)“.

Posted back in Dec ‘07 this is an interesting post about a real time strategy game concept by the author of the blog “The World Is A Neat Place, Usually”, entitled “Some More RTS Game Concepts…“. So go check it out!

Found this very interesting RTS game in development - ‘Galaxy’s End’ by Tiki Games. It’s designed ground up for the PSP and currently it looks like they are “seeking a publisher”. From the website:

Galaxy’s End, an original science-fiction RTS designed from the ground-up for handhelds and consoles, is the first game being developed by Tiki Games. Compelling 3D visuals complement a streamlined and intuitive control system that allows players to learn the game within a matter of minutes. Galaxy’s End has also received Stage 1 Approval from SCEA. We presently have work-in-progress screenshots and a gameplay movie taken from the Sony PSP version of Galaxy’s End.

Portable Gaming Revolution also published a 3-part article entitled “The Struggles of Tiki Games”:
part 1 | part 2 | part 3

An article from Jan ‘08 by Nathan Toronto over at Gamasutra entitled “The Future Of The Real-Time Strategy Game” made some interesting criticisms about traditional RTS games, particularly micro/macro-management and the difference between tactics and strategy.