Hi,

while developing our game, we came across a design issue which we ignorantly we didn't give much thought during the concept phase and which is now blocking further progress. Hope the post isn't too long to become boring; please bear with me.

Game Environment Background
The game is a web-based fantasy RPG. While the focus is on single-player adventures, there is also a multi-player component, allowing players to compete in daily arena combats or duels. The player has little control over what goes on on the multi-player part, aside from deciding whether he wants to participate or not (that's to say multi-player combat is NOT interactive).

Technology
Javascript (jQuery actually) is used for most in-browser actions - we don't use any flash. On the webserver side things are written in PHP, but combat is handled by a different engine written in C++ using Squirrel as an embedded scripting language. At the initial design phase it was decided that running most combat logic in a native environment with pre-compiled scripts would offer the best performance. Embedded scripting engines are used in all major real-time games for performance reasons, so calling on this from the webserver code would add little overhead compared to implementing everything in PHP. For all purposes, very complex logic can be built into the combat system if needed - presumably/hopefully with less of a performance trade-off (we have no large scale tests to confirm this yet).

Gameworld
The design of the world relies on freeing the player from the concept of classes. That is to say the system lets the player get better at something the more he does/uses it (not an orginal concept, but we like this). On a wider note, this encourages players to mix combat tactics and spells from varying magic schools in order to develop their own strategy. For instance, a melee player could choose learning fire auras and imbuing spells coupled with chaos magic spells designed to weaken his opponent. A ranged fighter could rely heavily on nature magic spells to strengthen his attacks and protect himself from other harmful magic.

Combat System Design
The combat is turn based. During each turn, depending on various factors (dexterity, stamina, etc.) the player has a certain number of action points (APs) which he can use to move, cast a spell or perform a physical attack. We do not let the player access his inventory or use any non-equipped items during combat. Various actions take different amounts of APs, so during a turn a player may actually do several things if he is quick/good enough at it. Just to make things clear, the number of APs depends on the avatar's stats, NOT how fast the player can click his mouse or press a key - just like in any normal turn-based game.

The Problem
Obviously, this produces complex tactics which the player has no trouble using on his quests, but it makes things troublesome when developing the automated multi-player combat.
In short, we can't find an easy, intuitive and reliable way for the player to translate his tactics into some sort of capsulated logic which can then be processed by the engine.

Avenues Already Considered
1) Simplifying multi-player combat
The easiest of all options, simply ignore the complexity from the single-player side and just compute how players bludgeon/incinerate/freeze each other to death. This would allow a player just to select what he would use to attack during his combat turn and be done with it.
Con: it makes the multi-player VERY dumbed down and look extremely different from the exploring/questing part of the game. Also, we put a lot of effort in designing various spells and effects which would be useless in multi-player, removing a large part of the game's immersiveness.

2) A complicated spreadsheet-like combat template
This would let each player specify what his avatar is to do, given manually specified conditions. E. g. if the health drops below a certain value, cast this healing spell, otherwise move 10 APs closer to the opponent, cast freeze and do a melee attack. The player would specify such logic for a given number of turns which would then repeat itself.
Con: it makes defining this "combat logic" a VERY tedious. Any regular (that is non-power) gamer will easily be turned off by the complexity of having to configure something like this. Even with pre-defined templates that he would only need to adjust, the overhead is just too big.

3) A goal/weight based, simplified template
The idea behind this is to allow the player to define a general strategy (such as keep shooting arrows and cast ice bolts as much as possible) and couple it with a predefined (script implemented) AI. This would allow the AI to make decisions such as when to cast healing spells, when to cast portection spells, etc.
Con: it gives little control to the player over what is happening, even though it seems to be much more flexible on the surface. In reality this is just like option 2) with all the complexity hidden away in scripts.

4) Allow interactive multiplayer
Remove the difference between the two types of combat, and allow the player to fight other players the same way he fights monsters in dungeons.
Con: this essentially makes the idea of an arena impossible, as automated combat simulation doesn't exist. The second problem is that we want to allow players to duel other players more like a sparring exercise, unlike action MMORPGs. That is to say, the "assaulted" player might not even be online at the moment of combat. Implementing this option would require battles to take place only between on-line players, and with both players actively fighting at the same time - not really suited for a browser based environment.

I'd really appreciate any constructive suggestions on this. I understand that most likely we'll have to compromise on some features in order to reconcile the two combat systems, but I'm not sure on what. Any ideas on how a similar challenge got solved in other games? I'm aware that most turn-based games have an "auto-combat" button, but I'm not sure how this is implemented and what strategy trade-offs are made...

Thanks for the time reading this!

Play the board game called RoboRally, it may give you some ideas about asynchronous competitive play.

You should probably always have the option for players to play a live multiplayer match against each other if both are online. Just because that's more fun. So you can 'challenge' any player, if they're offline then you simply get the automated battle, and if they're online you get the real thing.

If this was my project and I had to make the decision about how to proceed, I would say, build solution 2 first, playtest and see what bits need to be abstracted for the player to find it accessible, so you find the right middle ground between 2 and 3.

Also, consider the replays from RTSs like starcraft. If an automated battle takes place, I want to be able to scrutinize it to see exactly what my character did so that I can adjust my program

Finally, the best thing to do is have the game learn from how the player plays his character. Then try to emulate that in the decision matrix (solution 2), so the player at least has a starting point.

Hi, and thanks for the time taken to chew on this.

We more or less came to the same conclusion, in that we started working on a derivative of point number 2 as well. However we simplified it a bit and changed the logic of the "spreadsheet".

In this new vision, the "spreadsheet" represents the entire, capsulated logic for only one turn - any turn, a finite state machine, if we can call it that.

The player has three predefined sections he can modify: a main combat section ( a ), a personal boosting section ( b ) and opponent affecting section ( c )

In ( a ) the player selects his "main" attack, specifically whether he either wants to use physical attacks (with fallback to magic if his weapon breaks down) or magic attack (with fallback to physical in case he runs out of mana). For magic attacks he can also select the spell.
In ( b ) he can set up to 5 "entries" each represinting a combat option made up of several elements:
- a condition when this entry should apply (when a certain stat/skill reaches a certain level, when an opponents stat reaches a certain level, if a spell is currently (in)active or has expired, etc - we have about 7 such conditions)
- an argument to the condition (e.g. which stat)
- a numerical value field
- a percent indicator (to mark whether the value should be interpreted absolutely or as a percent)
- a weight value to help distinguish between similar conditions or to produce random actions in case the player specifies the same conditions with the same weight
- an action field, where the user can specify an action to be taken (cast a certain spell, do a physical attack, etc.)
In ( c ) he can specify just about the same things as in ( b ) but these will be interpreted in the context of being applied towards the opponent (there are some differences, justifying the need for separate sections).
These sets are then saved as templates (each player can have about 3 of them), but only one (which the player sets as default) will be used in actual combat.
Each turn the scripting engine analyzes all sections and tries to execute as much as it can from each.

It may sound complicated on paper, but it looks really straightforward in the UI; the part that we like is that it is deceptively simple looking... In reality you can specify complex scenarios such as:
> if the opponent's ranged skill is above a certain level and he casts "Speed" on himself, then cast "Curse X" which slows him down and heavily modifies ranged chance to hit

Of course it takes a bit of practice to understand exactly how to configure this, but ultimately this is what separates the good players from the poor ones; we don't warn the player if he makes non-sensical combinations and hope he'll find out on his own... After all that's what the combat log is for, detailing each turn and letting him know that what he set up isn't working as expected.

So you can 'challenge' any player, if they're offline then you simply get the automated battle, and if they're online you get the real thing.[/quote]

Arghh... this really stings! This was one of my orginal ideas, back when we were writing the design specs; it got left out because it was deemed too complicated to implement (it would require syncing actions between the back-end engines which could potentially be located on physically different machines). This really restirred some of the old discussions we were having back then...

It sounds good, sorry you had your idea torpedoed! Happens to the best of us

My only afterthought is that as a programmer, it would appeal to me if this was the combat mechanism for the entire game (including PvE), that helps reduce the potentially massive difference in player experience between the single player and multi player aspects.

OR

you should make it an option for players to use their automated combat program when PvEing so they can see how it performs and tweak it.

It sounds good, sorry you had your idea torpedoed! Happens to the best of us

They had a valid point nevertheless; in time as coding took off, I realized that such seemingly minor changes can have a dramatic impact over the whole project, so I rested my case.

My only afterthought is that as a programmer, it would appeal to me if this was the combat mechanism for the entire game (including PvE), that helps reduce the potentially massive difference in player experience between the single player and multi player aspects.

OR

you should make it an option for players to use their automated combat program when PvEing so they can see how it performs and tweak it.

In a regular rpg, where characters "see" each other this seems pretty straightforward; in a web based game, where players have less of an idea what others are doing, it may be tricky... Imagine you just want to arrange your inventory or look at what ingredients you still need to gather for a recipe, while being constantly interrupted by other players attacking you or challenging you to a duel. Even if you can deny their requests, it still becomes very annoying, VERY fast!