Making online battles take time

Question

Let's say I have an account on an MMORTS and I send my 10,000 strong army to a location on the map. I then shut off my computer.

Another player gives orders to his 10,000 strong army to walk to the same location and attack anyone located there. He then turn off his computer.

After 30 minutes when his 10,000 guys arrive at the scene the battle begins. Now killing 10,000 guys where both armies are using the same skill and weapon might take several hours.

Let's say I turn my computer on again and find the raging battle and that I only have 4500 soldiers left, so I decide to pull my army back.

This type of ongoing battle happens on the server. How could this be accomplished? I'm thinking JavaScript / PHP technologies. I'm thinking that there should be some sort of dice system to each attack so it could end with one side winning with 1500 men left even if they started with equal amount. Is there some sort of clever logic that would not require 20,000 calculations per frame to calculate each hit and and parry for every unit?

Answer 1

It looks like you might be asking two different questions, so I'll answer them each separately (though one may influence the other).

Taking Time: What you want is that the battle actually executes over a longer period of time, rather than just as quickly as can be calculated. This gives the user the impression that something is actually hapenning and allows them to change their orders during the battle. Here a timeslicing approach makes sense. Presumable you will be hosting several battles on the same server, so you'd probably need to do this anyway.

In this approach each of your active games represents an object on the server. Now your server will poll each active game at a fixed interval. Say every 30s: you can adjust upward to lower total load and downward to improve user real-time feedback. Each interval you will simply step each active game by 30s (scaled to the world time).

Calculations: Trying to represent 10000 units as 10000 objects is simply not going to be possible. Perhaps if you write in C++ and have a very optmized algorithm you could do it, but you still wouldn't be able to support many active games on one server. Instead what strategy games tend to do is lump together units into groups. So you have 500 rifleman, 2500 infinitry, 20 artillery, etc. That is, reduce your battle to a small number of actual objectds. These cumulative objects can then fight each other in turn.

In the simplest model, say for infinitry, you could simply multiple per unit HP times the number of units to get one virtual infinity unit with a really high HP, and also a really high firing power. This is perhaps not ideal, but it is a decent logical starting point. Here you don't really do pure die roling anymore, you'll be using statistical projections (easier than it sounds). So if each unit has only a 10% chance to hit, the logical group will simply do 10% of its total damage each round. Again, simplified, but gives you the basic idea.

Answer 2

I see two problems here - optimizing the battle on the server and allowing the player to view and change the battle before it is finished.

First things first - optimizing the battles. You need to design combat in rounds, and roll dices for each unit separately within each round, giving you 20000 computations per round - each unit attacks one other unit and defends from one attack. You can design the combat system so that it will last a small amount of rounds, for instance a 100 for 10000-unit armies. If you find your battles take longer, you could make them more 'bloody' using various techniques - make combat between opponents more random (higher standard deviation), penalize fighting between the same 2 units for more than 2 rounds etc. This should give you a required total number of 'computations' in the millions per one battle of 10000 units, which seems sensible. Moreover, it is easily breakable down into smaller chunks or parallelizable from the other server work.

A different approach you could try is using Lancherster's laws for mathematically modelling battles.

Once you have that, you can look at your second problem differently. You can precompute battles and store them as a series of states, each state corresponding to a combat round. Displaying battles is, like many things in games, interpolation - you know in what timeframe each round should occur, so when displaying the battle at any given time you can choose the two nearest precalculated rounds and show to the player a dynamically-changing state that is somewhere in-between. You don't have to be precise; nobody is interested in exact numbers. If the player decides to retreat, you can confirm the action instantly and send it to the server, which will recalculate part of the battle - from the current (or next) frame onwards. If you give the player instant feedback, he will accept that the action is non-instantious and that there might be more casualties that the last displayed number (it's believable that receiving an order and retreating take time). Other events - reinforcements, change of tactics, spells/abilities etc - can all be handled in the same way, by recalculating the battle from the given moment onwards.

In essence, what I'm saying is discretize the battle, store it, interpolate for the purposes of showing it to the player and recalculate when a player decision is made.