There is time to kill today​

No matter what type of Role-Playing Game (RPG) you are playing, you can be 95% sure it involves killing things. Many so called RPGs provide no gameplay beyond hacking away and leaving swaths of dead monsters, sans any material possessions, and others might allow you to avoid combat situations altogether. However regardless of design philosophies, combat usually comprises the core gameplay, and so it's essential that it is well thought out and executed, but more importantly it has to be enjoyable and challenging for the player.

In this article, we will undertake a journey, through existing combat systems and onward to hypotheticals, and seldom used ideas. Our journey begins, back before CRPGs or even computer games were commonplace. In fact we're going back so far that even mathematical devices like the abacus weren't around. And I hope you've brought your attention span with you because this article isn't short. If not, here's some Bright Flashy text! (Insert link to summary section of article here)

We start with the origins of the most well known combat simulation, in Asia about 1500 years ago. Chess can be traced back to it's precursors, such as Chaturanga and Chatrang and shares many common elements with modern RPG combat systems.

The first and most obvious similarity is the concept of Turn-Based (TB) play. TB combat is the first abstraction we will deal with, and serves to greatly simplify the game system. In the context of chess, forcing players to move sequentially provides several benefits. The focus of the game becomes making the most of the one action you can perform before your opponent can act, rather than merely a matter of who has more manual dexterity. Sequential moves also eliminate any need for deciding an outcome of simultaneous actions. It can be assumed that all opposition pieces are stationary during your turn. However one of the most important and oft overlooked dynamics is the way all actions are measured. A player at any given time can anticipate the actions of his opponents next move, and can plan his/her own move with consideration to subsequent moves due to the very measured nature of taking turns.

When we look at TB and how it relates to CRPGs, we first start with the roots. Most, if not all CRPGs have inherited ideas and design philosophies from Pen and Paper (P&P) RPGs, which due to their nature, are TB. With many more players and a system of greater complexity, it becomes a necessity to provide the Game Master/Dungeon Master (GM/DM) with a simple means of tracking game actions. Due to TB and it's sequential nature, it becomes possible for the GM to control the game, and for all players to perform the simple arithmetic inherent in most P&P games without any time limit. Since we're dealing with RPGs here, it also allows all participants to behave according to their character. A TB system places no demand on reactions, and as such, all actions can be calculated and thought out, and performed according to the role the player has assumed.

Moving back to somewhat more relevant material, ie how all of that relates to CRPGs, we see that some of the benefits of TB are made redundant by the fact that a computer can calculate simple arithmetic almost instantly, and that generally there is only a single player interfacing with it at any one time. Stepping into the GM's shoes, the computer never has any trouble keeping up with the action, and any characters under it's control have behaviour according to pre-defined scripts, so it doesn't need to do much "thought" in order to control the game.

However, we now have another major hurdle when it comes to implementing more rapid systems. The Human Machine Interface (HMI) becomes a limiting factor due to the fact that while the computer can execute moves and behaviours without latency, the player must manipulate various input devices to interact with the game. TB combat is now allowing the player to keep up with the GM as opposed to the opposite situation in P&P RPing.

Of course, there are other solutions to allow a player to interact effectively with a game aside from TB, and we'll start doing some comparisons, involving various Real Time (RT) approaches.

When dealing with action games, one of the most effective challenges a game can offer a player is a challenge to the player's manual dexterity. Both speed and timing come into play with most action games, and most are reliant on the player's ability to react to the game. Rather than carefully considered options, and any large degree of anticipation, most action games involve the player honing their own behaviour to react to certain events and situations within the game world. Even though most of these reactions are largely repetitive, the player tends not to notice, as the reactions become automatic. However repetitive they may be, they still remain a challenge to the player.

However, it's a fairly common philosophy, and a logical one, that if a character in an RPG has some measure of reflexes and dexterity, then the player should not be advantaged or disadvantaged by a game that is reliant on their reflexes. When thinking about RT systems there are a couple of ways you can go with this philosophy in mind.

The first thought that springs to mind is to greatly simplify the interface and in turn, the combat system itself. If the player is only controlling a single avatar, then quite reasonable demands can be placed on the players' manual dexterity, provided there isn't much depth to the system, which in most cases becomes a fairly simple point and click affair with a small selection of hotkeyed actions. However, if we throw back to the initial paragraph of this article, it's very questionable if this is indeed enjoyable and challenging for the player. In most cases this combat in itself isn't, and so it tends to be compensated for with many progression rewards, and needless to say this doesn't capture the imagination of many players.

So let's keep walking down the path and leave the mule to chase his carrot. There's got to be a better way. So let us consider for a second why the interface is a hurdle to a RT combat system. While the player navigates the interface, the game continues to play, and the player gets behind. Interface latency is a good a definition as any for this, so now we consider how we can get around that.

One approach is to compensate for the interface latency by extending the timeframe for actions, and enforce timed rounds. If the player has 5+ seconds between actions, that's more than enough time to navigate the interface, even if it's only moderately efficient in design. Sounds pretty neat in theory, but when it's put into practise, all we've really succeeded in doing is making simple and fairly banal combat take longer, especially if the player is only in control of a single character. Not the best solution, and we'll get into the how and why a little later on when we start with RT versus TB arguments/myths.

So let's take a backstep for a minute, back to where the player needs ample time to navigate the interface. The next obvious solution is to provide the player with the ability to pause the game. That interface latency is all but gone, because the player can precede any action with a pause. The pace of the combat is in the hands of the player and they can alter orders on the fly without the limitations of the HMI.

It's a solution, and it seems like a good one until we dig a little deeper. Let's firstly rationalise the pause function. If the pause is intended to be used with regularity, and with the complexity of your average TB system then what advantage does it have over TB, and why does the combat have to play out in RT? If pausing is arbitrary, then any sense of measured progression is lost. It's difficult to anticipate and gauge the actions of other characters, and due to the simultaneous actions, the player can just outright miss many of the things going on during combat.

Let's swing back and think about another rationalisation of the pause. This time, we're expecting the game to play out in RT for the most part, and the pause becomes a safety net for a player who is overwhelmed while operating the interface. Of course, if we're expecting most of the game to be RT, then both the interface and the combat system need to be simplified. Now we're leaning toward Action/RPG again, although we've just successfully removed any challenge that results from twitch gaming, which isn't necessarily a good thing. Sure we're sticking to our character based reflexes philosophy, but now we've got something that doesn't challenge the players dexterity, and due to it's simplicity, doesn't challenge the grey matter either. Enjoyable? Challenging? Nope, we've missed the mark on our initial statement once again.

However, methods somewhere between RT and TB have been used with some success, the one I believe has the most potential is the "WeGo" phase based system, named because rather than the TB paradigm of "I go, you go" instead "We go" together. This system works in two phases, planning and execution, however without a good deal of thought, the execution phase can be easily bugged.

Let's go back to chess for a minute, and imagine both players are moving at the same time. How do we handle two pieces moving into the same square simultaneously? What about check situations? A new set of rules has to be devised to handle such occurrences, and ideally it has to be something the computer can decide on independently of the player, without causing undue frustration. A cheaper solution is to throw an exception back at the player when a character they are controlling cannot complete their action.

So we've touched the surface on a few combat systems and the inherent problems of each, now let's go a bit deeper and see what we can find.

Let's start with interaction. After all, it is the defining point of what sets computer games apart from other entertainment mediums. Interactivity. If we judge a book by the quality of reading it provides, then we should judge a game by the quality of interactivity it provides. One of the problems inherent with the various systems outlined above is that most of them have periods of non-interactivity.

First on the list, TB, obviously has interactive down time while NPCs are moving, and because all actions are happening sequentially, this down time can be considerable, and so measures should be taken to avoid this. One of the most common complaints with TB systems is that it takes too long when a large number of enemies have to move, one after the other. There are two major contributors to this, animation speed, and poor design. If the player has to wait 20 seconds for a swarm of weak critters to move, then they are likely to get frustrated, and given the average attention span of human beings, it doesn't take long for the average player to lose patience.

The remedies to this problem are simple. Provide the player with the ability to scale animation speeds, and avoid scripting situations involving numerous weak enemies. With TB being more of an abstraction than a simulation, arbitrarily altering animation speeds has less impact on suspension of disbelief. Additionally, if the encounter is well designed and sufficiently challenging, then the player should be watching the moves of his/her opponent intently. If the player is lackadaisical during the opponents turn, then obviously there's something wrong. If the player is apathetic about the movement of an opponent because they are distant or out of line of sight, then hiding movement that doesn't concern the player is fairly effective.

While we're dealing with systems that intermittently provide interaction, let's think about phase based systems, and more specifically, WeGo systems. Due to WeGo's simultaneous execution phase, we no longer need to concern ourselves with hiding actions that have no direct relevance to the player, as it's all happening in RT. This can be somewhat detrimental to a strategic overview of opponents' actions, this can easily be over come by allowing the player to replay and review the execution phase at will.

However the biggest advantage with a WeGo system is that you can add post production of sorts to the execution phase. The player can't interact, so you don't have to manipulate the camera in ways conducive to player control, you can use cinematic angles, and also timing effects such as slow motion and bullet-time. You can display repetitions of actions and events from varying angles, or just about any other cinematic effect you could care to name. The sky is the limit.

Such things are much more limited in a fully real-time system, as changing playback rates and camera angles interfere with the interface. However this is not necessarily a bad thing, because rather than making the non-interactive portion of gameplay compelling, you simply don't have a non-interactive portion of gameplay, something that is essential to action based gaming.

If the real-time system has some form of pausing or means of player control without the game progressing, then the game dynamic that tends to be adopted is Pause->Interact->Unpause->Watch and throwing back to our two ideas on how pausing should work, then we have either an experience that is largely passive, with simplistic interactions or we have a more complex system that requires constant pausing and interaction, but without the advantages of a measured turn progression, the ability to monitor all relevant opponent actions individually, or any cinematic effect.

So that's interaction. Once again, everything has it's ups and downs, some more than others. And since we've scratched until we've broken skin, let's keep digging. Time to get into the meat of the matter. We've done a little about interaction, let's get into action without it's prefix.

Time for more chess. It's a nice simple system and a good one to start with. Let's rationalise. Each piece has rules applied to its movement, and for the most par they're fairly simple. Bishops can move diagonally, rooks can move along cardinal directions, kings can move one square in any direction, etc. Simple and easily defined rules, with only a few conditions, such as pawns being allowed to move diagonally, while taking on opposing piece. Controlling any single piece is not particularly interesting, and the elegant gameplay of chess is mainly about effectively using a group of pieces, each with strengths and weaknesses, which is analogous to the general model of a party based RPG. Simplicity on an individual level is compensated by tactical control of many individuals.

Let's depart briefly into RPG philosophy. All developers have variations on how they define RPG, however one thing that most, if not all agree on, is that the player is assuming the role of a single character as an alter ego. Using the traditional model of P&P RPGs, where each player is in direct control of a single character fulfills this criteria, however adopting the same philosophy for CRPGs poses some considerable problems to overcome.

With direct control over a single player, the player can focus their attention to actually Role-Playing that character, however when it comes to combat, the elegant simplicity that P&P RPGs provide through necessity, so as to not eclipse the focus of portraying a character, is too little within a CRPG, as there are no other human players to participate in any form of combat driven RP.

If we give the player direct control over a party of characters, the ability for a player to effectively take on a single persona is greatly diluted, as they now have to account for the actions of multiple characters. Additionally, due to the limitations of computer game systems, it's hard to have any sense of intraparty RP, and so the player is left very much feeling that they are an overseer, a commander of a party, and not actually part of it.

Getting back on track again, let's look at how TB accommodates actions, what degree of complexity we can achieve, and how it affects the overall RP of the game. The single biggest advantage TB combat provides is it's abstract nature. With moves happening sequentially, it is possible to allow a wider range of actions comparative to their real life counterparts. Most importantly, moving and attacking. Once the abstraction of Move->Attack->Move in TB is rationalised, it becomes an attack while moving. Similarly, actions such as Move out from cover->Attack->Return to cover can be rationalised as attacking from behind cover without fully exposing the character. Although in their abstract forms these actions may seem unrealistic, they are effective representations of intelligent combat tactics in reality.

The actions that can be performed within a TB system are theoretically limitless, however adding complexity for the sake of it can merely serve to convolute the system and should be discouraged. Providing more depth to the combat, as long as all actions are carefully considered, within context of other actions, usually results in a more compelling game tactically, but also provides limited behavioural RPing opportunities, for instance player characters with a penchant for administering sledgehammer blows to the groin. This method also makes the gameplay more appropriate for providing combat challenges, rather than combat merely being a timesink with experience and loot rewards.

RT systems however, have a great deal more limitations based on actions. Traditionally, due to sprite space limitations, many RPG systems can only accommodate stationary attacks, and as previously mentioned, this poses no problem to TB due to it's abstract nature. However, with RT being analogous to a WYSIWYG, any actions have to be represented in a manner closely resembling it's real life counterpart. But this is only the tip of the iceberg. The biggest hurdle to performing multiple simultaneous actions, such as moving and attacking is the interface. Considering the general point-and-click model that is used to streamline RT control in CRPGs, it's difficult to find any reasonable solution. It is possible to take an approach similar to FPS control where movement and attacking are controlled with two independent input devices, but this cannot account for party based RPGs, and is leaning heavily toward action gaming.

Secondly, due to it's reactive nature, RT systems may be able to provide a large set of actions, but once again, due to interface restrictions, at any one time the set of interactions available to the player is very limited, which encourages repetitive actions, and this tends to dictate simple and banal combat.

Also, with the introduction of simultaneous actions, we begin to see a disparity between melee and ranged attacks. It becomes next to impossible for a ranged attacker to disengage from a melee attack, and so the most effective means of combat becomes standing toe-to-toe, which means ranged combat becomes focused on resolving combat before a melee attacker can close the distance. This may not sound like a problem until you consider both sides of the story.

If a ranged character must bring down melee attackers before they get close as a result of the game dynamic, then melee characters are greatly disadvantage by the inability to effective use terrain and cover in RT. It also severely limits both character choices and tactical choices, as there becomes decisions with compulsory choices if the player wants to succeed.

Moving on to RT systems with provision to pause, and we gain the ability to issue a larger set of orders without as much hindrance from the interface, however simultaneous actions are still near to impossible, and utilising terrain and cover is not worth attempting, as the tactical choices are once again funneled in a similar manner to pure RT, with the disparity between ranged and melee still evident.

Since that ended up being a fairly lengthy rant with little direction, let's begin to summarise.

One of my Turns - Turn Based​

Strengths - Turn-Based combat provides the player with ample control over their players, with no reliance on player reflexes and allows for many more tactical options and choices to be incorporated into gameplay. It progressed in a measured manner, which allows better planning and anticipation from the player's perspective, but also serves to reinforce the idea of discrete progression through a game, a typical RPG trait that is being adopted across the whole spectrum of gaming genres due to it's effective nature as a player hook. Tracking of enemy actions is much easier in a TB system due to it's sequential nature.

Weaknesses - Poor design becomes glaringly obvious in TB combat. Sprites animating too slowly can drag combat out needlessly, as can viewing of movement that is hidden/irrelevant to the player. However, the biggest downfall of TB systems is providing combat that offers no challenge, as this ends up being a timesink that generally isn't worthwhile to players. Some of the more dubious TB weaknesses include the fact that it isn't trendy, and that it generally requires an attention span of some kind. Finally, TB will always be an abstraction of reality, and as such fails to appeal to a realism obsessed market, even if it provides a more accurate portrayal of reality once all sequential abstractions are rationalised as simultaneous actions.

Myths -

"TB is rendered obsolete by RT" - This is something I've heard spouted quite often, and there's not a great deal of truth to it. There are plenty of things in a decent RPG combat system that cannot be incorporated into a RT system. TB systems can incorporate more complex systems without compromising the interface in any way.

"TB isn't realistic" - Agreed, if you're taking it at face value, however for those who look below the surface, TB is much more effective when it comes to emulating realistic combat behaviour. Secondly, something a lot of people seem to have forgotten when it comes to game development philosophy is that the game must be fun, first and foremost. Reality comes later.

"TB is boring/TB takes too long" - Boring combat is boring combat regardless of what kind of system it utilises. The merciful factor of RT systems is that the boring combat is generally over and done with sooner, unless the "RT" combat is enforcing some kind of timed rounds, which is always going to take longer than a well designed TB system. However sppeding up boring combat is a workaround, not a genuine solution to the problem. A more acceptable approach would be to adopt a design philosophy of "Combat should never be boring" and to make sure all aspects of your game are enjoyable. Time sinks are important for some games, but not RPGs.

Keep it real, repr'sent what? - Real Time​

Strengths - Real Time combat usually demands the player be constantly interacting with the game, which greatly aids immersion, and keeps the player involved in a game, even if it only provides simple systems. In the context of action games, it also provides a challenge to the players reflexes and dexterity, and while that doesn't really suit the philosophy behind most RPGs, at least it is offering a challenge, which is important.

Weaknesses - RT tends to get in the way of RPing, because a large number of the players' actions become reactionary. Without time to contemplate how the player character would approach ny given situation, the action tends to become repetitive. Also, if the game provides some kind of measure of the player character's dexterity or reflexes, then providing the player with an overriding ability, for better or for worse, lessens the importance of that character stat. As we've said many times earlier, RT dictates that the system must be simplistic, and this is usually accompanied by many progression awards to try and make the player forget they aren't doing something particularly interesting. The mule who figures out the carrot is tied to a string and will always remain out of their reach is no longer compelled to pull anything, and the same goes for gamers who become aware of level treadmilling.

Myths -

"RT is more realistic!" - Is it? How many gun fights do you see where the two combatants stand toe to toe and trade shots? What about people who can move or attack but can't do both at the same time? The representations involved may look slightly more realistic, but that is akin to judging the realism of a driving sim by the vehicle models instead of the physics engine underlying it all.

"RT is cool" - As defined by who? Don't believe the hype kiddies, and besides, as an avid RPGer, I know we have nothing to do with cool. While we're sitting in a basement rolling dice, swilling Mountain Dew and other snacks while pretending to be mighty warriors in an alternate universe, cool people are out doing lines off naked women because they can. It still puzzles me why certain RPG developers seem so intent on following trends, when their consumer base couldn't be trendy, even with a +10 Bag of Conforming to the Social Norm.

And I pause for a while by a country stile - Real Time with Pause​

Strengths - The addition of pausing to a RT combat system greatly reduces the reliance on any kind of manual dexterity on the players' behalf, and also is less limited by a need to streamline the HMI. Poor design is also more forgivable, due to the simultaneous actions allowing players to get through encounters that offer no challenge at a faster rate, as long as there aren't enforced round times.

Weaknesses - The very philosophy of adding a pause to a RT system is akin to whittling away the corners of a square peg so it fits in a round hole. It addresses the problem of difficulty interfacing in RT, but doesn't get to the root of the problem. In taking away a reliance on player dexterity, a challenge that is vital to RT systems is now gone. In order to effectively compensate for this, there needs to be a challenge in the tactical play, however, that too is compromised by the inability to effectively utilise terrain and cover, or attack while moving, which greatly limits many actions that would commonly take place within a real world tactical simulation. Also the nature of pausing to issue orders and then watching those orders get carried out seems entirely too passive, while on the flipside of the coin, you are constantly pausing which serves to eliminate most of the advantages of a RT system. So basically, taking a real-time system and adding pause comes with all the weaknesses of RT systems, few of the strengths, and is far outweighed by both TB and purely RT systems.

Myths -

"RT with pause has just as much underlying complexity as TB" - Sure, if both systems are exceedingly simple. TB permits the integration of many more features, and has less limiting factors. While RT systems with or without pause have many limitations imposed by their very nature, TB is limited only by the ability to maintain player interest.

"RT with pause is better because the player has control of it's pacing" - The player does get to control the pace of the combat, however the players ability to effectively judge and weigh up their own actions against those of their opponent is no longer carefully measured. If a similar system were introduced to the another essential RPG element that relies on discrete progression, ie levelling, the whole game would be worse off for it. If the player were able to develop their character at any time, without any measurement of level, the character system would seem diluted, and the reward/achievement of reaching the next level has gone by the wayside. There's no reason to view combat any differently. Surviving to the next turn can be an achievement in a difficult encounter, and most players derive a great deal of satisfaction from the knowledge that that all important next step of the way has been taken.

This is just a passing phase, one of my bad days - Phase Based​

Strengths - Phase-Based combat, like its close relation TB, provides tangible phases which can be carefully measured, anticipated and progressed through. The difference lies in the fact that rather than taking turns, combat is rationalised into two phases - planning and execution. Sequential phase based provides very little advantage over standard TB, however a simultaneous execution phase can provide all of the advantages of real time, sidestep most of the flaws in TB, but does come with it's share of problems. More on that a little later, first the advantages. All of the TB advantages apply here, but with the addition of simultaneous actions, which greatly speeds up the TB process, and also helps to satisfy the naysayers who believe TB is unrealistic. "WeGo" PB effectively takes away the abstraction of TB.

Weaknesses - However, as we said before, it's not without problems. The most glaring one is the fact that you are locking in a sequence of actions with no way of altering it on the fly, which can have effects ranging from frustrating to catastrophic. There are solutions, such as allowing the player to explicitly specify interrupts explicitly when they anticipate unforeseeable circumstances or by providing fairly short phases that don't allow the player to dig a hole too deep. This also works to keep the game interesting and interactive, as lengthy execution phases can be harmful to interactivity especially if all actions are predefined and unalterable. The second major problem is how the game handles invalid moves, such as two characters trying to move to the same location simultaneously. However, problematic as PB may sound, it boils down to being more of a challenge to the developer, and with proper design attention most bad points can be addressed effectively.

Myths -

"PB is just the same as TB" - Yes and no. The major differences lie in the execution stage. Firstly, actions are planned simultaneously, whereas a TB system provides some quarter to slower characters who get to see what faster characters have done. Secondly, while a fast character in a TB system might get an extra turn every now and then, PB is rigid with it's "one for you, one for me" rules. A couple of subtle differences, but they do have some fairly profound effects.

The time is gone, the song is over​

Thought I'd something more to say, but it's about time to wrap up this monster. There are a whole bunch of other factors I didn't discuss here, such as drama, because they tend to be fairly subjective, and I've been trying to keep this fairly factual and impartial. Now that the story is told, I guess it's time to sit around the fireplace and get into some discussion so get posting, I like to hear other peoples' take on RPG combat. If you're still here, thanks for reading.