The Future of Real-Time Strategy
http://rtsconcept.wordpress.com
‘The Future of Strategy Games, focused on RTS design concepts and the upcoming Supreme Commander 2.’

Total Annihilation: The X-Pack

http://totalannihilation.wordpress.com

‘The X-Pack: The Unofficial TA “3.2″ Patch. All you’ll ever need to play multiplayer Total Annihilation online.’

[EDIT: The incredible all-in-one multi-player pack (TA:X-Pack) can still be downloaded here. Or visit the website above for more. Get in touch via that site to play with others online. Enjoy!]

I’m still in two minds about Demigod. I can’t quite get my head around the mix of RTS, RPG and tactical fighting game yet. Clearly it’s an entirely different beast strategically or perhaps philosophically to Supcom, but it will likely display many similarities in the gameplay mechanics and overall ‘feel’. Such characteristics will be interesting for thinking about how they might be able to push the Supcom engine to its max as PC hardware rapidly evolves and gaming potential enlarges.

I often wonder how far the Total Annihilation engine might have been pushed nearly a decade ago, were it not lost in a quagmire of failing companies and legal red tape. TA: Kingdoms was a new engine altogether and an attempt to take TA in a  fresh direction for a new era. It failed commercially. Will Supcom 2 build upon the successes of its predecessor and possibly of Demigod? Or will it be an entirely different project?

They might attempt a more commercial angle and neglect the hardcore base, or vica versa. It is tricky for GPG and Chris Taylor, as Supreme Commander and Forged Alliance where never the commercial gargantuans as other similar PC games were, those such as Starcraft, Spore, WoW, Sid Meier’s X Y or Z, Rome, etc.

For me, Supcom was an homage – a tribute, a conceptual wonderment, a breathtaking, astounding engineering accomplishment. Forged Alliance was like an injection of new fuel into a blistering rocket ship. Yet I think it is actually still very early days for this project. I think there are gaps needing to be filled, things which didn’t quite ‘feel’ right to us. Like a beautifully complex and epic symphony, but played by a musical robot automaton; missing all the subtleties and nuances which we relate to at an emotional level. Therefore, Demigod might try to dazzle us with an entirely different emotional spectrum. The gameplay, for example, might feel much more personal and immediate, the look, style and general art direction seems indeed to be be pulling at certain aesthetic heart strings and the overall intensity of the Supcom exprience reduced and refined to a calmly manageable level.

I would ideally like Demigod to be sophisticated, to display character and perhaps even entertain a more commercial ethos – provided that no depth or gameplay is sacrficed. I’d like it to contain the elements of things which might emerge in a few years’ time inside the gameplay universe of Supreme Commander 2.

What are your thoughts about Demigod and Supreme Commander 2? Do you think Demigod is a perfect chance to try out the Supcom engine, to test its structure and potential, to stretch it in new ways? What do you think might be learned or taken from Demigod which could be implemented in Supcom 2?

Upon reflection, what most strikes me and sort of disappoints me about units in Supcom, as opposed to say, TA, is how ‘light’ and unsubstantial they feel. They appear to slide about the terrain as if skating across ice (yes, especially the hover units but not only those) and don’t bump into one another in the manner you’d expect giant metal tanks and robots to do – it’s all soft and bouncy and well… it just doesn’t feel right.

Total Annihilation felt adequately clunky, mechanical, heavy and powerful and industrial and all those wonderful adjectives I’d associate with futuristic intergalactic robotic warfare! There is something about the physics and unit behavior in Supcom which leaves me feeling a bit empty after a long battle. Which is a shame, because the graphics, concepts and overall gameplay is quite superb. I think wreckage piles play a large role, too. For obvious pathfinding/CPU reasons the wreckage piles in Supcom do not interfere with the movement of live units. There are no epic ‘pile ups’ and consequent tactical changes as a field of battle becomes clogged and units struggle to move between and shoot over their fallen metal brethren. Supcom units also seem to slide right through eachother once in a while, like mechanised ghosts, and when coming into contact there is no solid abrupt halt or ‘bang!’ – only a gentle ‘bounce’, as if they were made of cheap plastic parts!

When I discussed this at length in my previous post about this, I mentioned the term ‘deconstructible units’ and, in short, my idea was to dispense of health bars and arbitrary unrealistic ‘hit/damage points’ altogether – and have units contain actual physics, via component parts (or ‘modules’) which had certain features or properties and were physically ‘malleable’ or ‘breakable’ in battle.

I’d like to talk this time about the ‘modules’: what they are, how they might work – and the possible types, their properties and affect upon gameplay at large. I’ll also hint at a more recent idea I’ve had about unit AI or behavior and how this could be tied not to a generic unit/class AI, but instead to the individual module components themeselves. Thus, in effect you’d not only design, research or build your units but also shape their individual or group behavior – how aggressive they are, the way they react to other units or components, their special properties under certain cicumstances, etc etc.

If the AI were tied to components, then one could create very specialised, or just very simplistic units designed for a certain purpose. They may only react to certain things, or be pre-programmed to follow a ‘command’ unit, or have a specialised role, to repair battle-worn units… etc. It’s really open to endless possibility. Of course the opposite is true also, they may have a great many layers to them and react any number of possible ways. The reason for doing this though, is more subtle. I have a wider goal in mind. By linking AI routines to components/modules, you basically create module types for the game with a specific ‘behaviour’ or general effect in mind. So a module – rather than having certain technical specifications (which it also has – more on this later) it simply has a name such as ‘defensive porcupine spikes!’ with certain physics and AI parameters attached.

So …

More to follow… stay tuned… (having to type this up via scribbled notes!)

http://www.custompc.co.uk/news/605175/supreme-commander-2-announced-by-square-enix.html

http://www.supcomuniverse.com/forum/showthread.php?p=56162#post56162

Perhaps Chris (“RTS God”) Taylor has been stopping in looking at my world-famous RTS Concept? *Ahem*. OK maybe not. This is good news though. I can’t wait.

Ideas?

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.

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.

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 – a battle ‘simulation’ almost.
• Adds certain character and depth to individual units.
• Provides intuitive realism and deep tactical and strategic considerations.

The main problems are those around the 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’ – it could be cut clean through by lasers, or impacted by a rocket blast leaving a small crater-shaped ‘scar’ 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 ‘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 game 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, proportionally. Supreme Commander uses a simple 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. Large units especially might have certain parts targetted. 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. Or, what I had in mind was simply to shape the game and story around this idea, so units were in fact circular, like cells or tiny virus-like beings from alien worlds etc.

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 more efficiently 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

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’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!!!