Archives

All posts by AndrewC

And here we are, seven articles later. As I said, the original articles were written in 2004, but remain fairly startlingly relevant today – the RTT genre has undergone a massive renascence and is more popular than ever, but RTS games have sadly stalled and come up against flawed efforts such as Planetary Annihilation and Grey Goo.

As I also said,” This series is not intended in any way to denigrate other genres, or to insult game developers. It’s about broadening horizons and exploring possibilities”. I hope that the possibilities and concepts discussed in these articles will have given RTS developers ideas – and in fact I know they have, thanks to the TAUniverse.net forums, still a little active after all these years!

Continue Reading

Supreme Commander introduced an extremely useful “strategic zoom”. While it certainly doesn’t replace the minimap, the ability to have a full-screen view, with icons for unit types – both yours and the enemies – adds new dimensions for strategic play.

This isn’t to say that it’s perfect, by any means. It perhaps provides too much information for the enemy – for instance, informing them of the type of ground units you have. It also seems, on many configurations, to display icons rather than units too early as you zoom out. This is also down to the need for distinctive unit shapes and side colours – something Total Annihilation did well – but also to design choices. In addition, it could provide you with more detailed information at some points – for instance, your high-tier structures/superweapons could all have distinctive icons. One area, in fact, I am extremely sceptical about is requiring “zooming” out to the strategic level. Instead of tapping a key, you need to go out with the mouse wheel. Add the use of a key – perhaps tab – to jump instantly to the full-screen, full-battlefield strategic view.

Continue Reading

Be warned that this will be a relatively long and detailed article, looking at weapons and their characteristics, the design philosophy of weapons and considerations of shields, point-defence and a number of other relevant factors.

Let us begin with examining the characteristics of weapons. Weapons in RTS games can quickly be simplified down to three types. These are direct fire – “scan-hit” (lasers and kinetics), ballistic (rockets and artillery) and guided (missiles and torpedoes). In some games, space games, there is also little difference between the first two, but for other games there’s an important difference there. Direct fire weapons can also be either instant-hit (lasers) or merely fast (kinetics), but there is often little difference in practical effect. On the other hand, ballistic and guided weapons may well behave differently, depending on things like point defence systems (discussed later in this article), and considerations such as gravity and wind.

Continue Reading

The concept of supply lines in RTS games has a mixed history. Many of the more popular RTS games abstract away the concept of a supply line, using a numerical “support” figure, which is built up by building “support” buildings. While effective in limiting army sizes, it also removes the chance of using supply lines to influence the actual gameplay. On the other hand, “realistic” attempts at doing supply lines have, like “Hard Vacuum” either simply not been repeated and/or have failed in execution.

babrtsw5n1

Hard Vacuum

Continue Reading

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 –

Continue Reading

Artificial Intelligence is fairly dismal in quite a few RTS games. Instead of trying to play as if it were a Human player, the AI uses “brute force” tactics – in other words, cheating. It gets boosts to productivity, to resources and in some cases even to the damage done and taken by its units!

It is helpful to the AI if units are more “generic”, if there’s lots of overlap, but that has obvious gameplay consequences. On the other hand, choosing the wrong units in R/P/S games, where you need “counters” for the enemy units quickly leads to defeat. This leads to another form of cheating – where the AI knows what you’ve built and works to counter it. This is often mis-sold as some form of “learning” in the game AI.

Continue Reading

RTS user interfaces have stagnated. This is perhaps the main thrust of this article series, and while I won’t discuss all the concepts today – part 3 will deal with AI integration into the user interface, and part 4 with templates and AI and part 7 with strategic zoom. However, the basics if the user interface such as control mode (the mode with visible commands, when you hold down a specific key) will be discussed here.

One particular note here is the usage of vertical and horizontally-orientated UI’s. Not only do vertically orientated UI’s lend themselves to more natural “scrolling”, whereas in the past screen screens were commonly i.e. 1024*768 – which is 4:3 – modern “HD” 1080p screens are 1920*1080, which is 16:9. In other words, between those resolutions you have 78% more width, but only 41% more height! Thus, vertical screen space is “cheaper” than horizontal.

In any case, Total Annihilation’s interface remains an interesting case study. It, while certainly showing its age, is reasonably clean and uses a fairly low amount of real space – while more modern interfaces “float” some UI panels over the main window, they do not actually make a huge difference to the actual view area. You can easily see your resources and resource flow, and you can view and manipulate many things a unit has been previously commanded to do, in a control mode accessed by pressing shift – now a standard in RTS games.

Continue Reading

While working with UDK (Unreal 3) and Kismet, I came up with some solutions to issues I found which are simpler and neater than the “commonly offered” solutions, purely in Kismet visual scripting.

The following is a health regeneration system which is both relatively simple, works smoothly and has a delay in starting health regeneration after taking damage.

Part 1 – “Have I taken Damage”

First, we need to know when we’ve taken damage, and hence should not be regenerating health in the first place!

Create the following;

  • Player Spawned (New Event / Player / Player Spawned)
  • Take Damage (New Event/ Actor / Take Damage)
  • Attach to Event (New Action / Event / Attach to Event)

For the Take Damage’s options, now set;

  • Damage threshold to 1
  • Max trigger count to zero
  • ReTrigger delay to 0.01
  • Player only to off (yes, off)

Right click on the “Instigator” output of Player Spawned and select “Create New Object Variable”

Let’s then connect them, as follows;

hr1

We can now detect when the player has been damaged – every time he does so, “Take Damage” will now fire. With that done, we need to now set up the system will will use for delaying regeneration based on damage taken, and this will be done by declaring a boolean variable, “Taken Damage”, and set up a delay in regenerating health.

Create the following;

  • Bool (variable) (New Variable, Bool)
  • Bool (action) (New Action, Set Variable, Bool) – two of these (remember, you can copy/paste Kismet objects!)
  • Delay (New Action, Misc, Delay)

Name the Bool’s (variable) as “TakenDamage”, and leave it as false – this declares the Boolean name. We now want to add two instances of checks on this which you can do via – New Variable / Named Variables in Persistent Level / TakenDamage.

  • For each of the Bool (variable)’s, right click on “value”, then “Create New Bool Variable”. Change one of those to False.
  • Again for each of the Bool (variable)’s, right click on “Target”
  • In the option of the Delay, set it to five seconds, and turn on “Start will restart”

Now, the logic we want to set is this – when the player takes damage, it triggers a 10s period when the “Taken Damage” boolean is true. The logic for is connected as follows;

hr2

(Note the green checkmark on “TakenDamage” – if this is a red cross instead, you have not properly declared the boolean variable!)

Let’s examine this – again, when the player takes damage it triggers “take damage”. This uses the first Bool (variable) to set “TakenDamage” to “True”. It also stops the timer delay. 0.1s later, the timer is now restarted (To create the delay, right click on the “out” node and select “Set Activation Delay”). If the Delay is allowed to finish – by not taking damage for those five seconds – the second bool is now triggered, and “TakenDamage” is now set as “False”.

Part 2 – “Regenerate Health”

Now we have set up a system to tell us when we should be regenerating health, let’s make that happen.

Create the following;

  • Player Spawned (New Event / Player / Player Spawned)
  • Delay (New Action, Misc, Delay)
  • Modify Health (New Action / Actor / Modify Health)
  • Compare Bool (New Condition / Comparison / Compare Bool)
  • TakenDamage Bool (New Variable / Named Variables in Persistent Level / TakenDamage)
  • Player Variable (New Variable / Player / Player)

Now;

  • In the Delay, set it to 1 second
  • The Modify Health needs to have it’s Amount set to 5 and “Heal” checked.
  • For the Player Variable, uncheck “All Players”

And we can then connect them as follows;

hr3

We begin the logic looping when the player is spawned. We check with the Compare Bool to see if “TakenDamage”  is false, if it is then we add 1 to the Player’s health with the Modify Health. Regardless if it is true or false, we trigger a delay of 1 second after which the Compare Bool is checked again, etc.

This now works! You can use other values – a shorter delay and a smaller heal amount, for instance, to create a smoother regeneration, if you wish.

(If it is not working, set your World Properties to “utgame”)

Part 3 – Test trigger

Let’s set up a simple trigger to test this with;

Make a Trigger in the main UDK window (Add Actor / Add Trigger), and edit it’s properties (F4), unchecking “Hidden”. Now place it near to the player spawn. With it selected, in Kismet right click and select New Event using Trigger_(x) / Used. Then create;

  • Modify Health (New Action / Actor / Modify Health)
  • Player Variable (New Variable / Player / Player)

Now set the Modify Health to, say, 10 damage per press, and set the Max Trigger Count of the Trigger to zero! If we then connect these up;

hr4

…We then have a trigger which damages the player when we trigger it, and which we can use to test the health regeneration!

I hope this was helpful!

//AndrewC

The original article series was written for a long-defunct Total Annihilation fansite in 2004. Ten years on, the article series is being mildly updated for the current era, when computer games are more popular than ever, and there is a variety of highly interesting RTS games not thought of in 2004 are on the market – among others, AI Fleet Command, R.U.S.E., Creeper World, Sword of The Stars and Eufloria – although I note most of these are primarily 2D. It still retains at it’s core, however, the concepts which it was originally built on.

The primary focus of this series was and remains on a field which unfortunately still lags, isometric-view 3d RTS games. One recent example is “Grey Goo”, which while it has some interesting unit and side concepts is still tied to much the same paradigm as the RTS games of 1997, when Total Annihilation was new and the C&C series current game was Red Alert and it’s expansions – and it has little to offer in terms of advancing the genre.

 

grey gooGrey Goo

Continue Reading