# How can I design a battle algorithm for my MMORTS?

So I am actually developing a MMORTS myself, and this is getting me stuck a bit. So lets say you have two opposing armies who just started their battle. How should the code determine who is the winner? Obviously you have to take into consideration such things as...

• How many troops does the army have?
• What level are the troops? (tier 1, tier 2, etc)
• What buffs and bonuses do they have? (increased attack and defense through research perhaps)

There are more I could list but you get the idea. There is a bit of math involved of course. Calculating all the stats and incorporating any buffs. But how should the actual fighting work? I have tried finding out via research on google, but most games keep their battle algorithms close to the table. You have all of this input from the armies, and then you put them into these mysterious algorithms and the code spits out a result. I must be missing something. I have had small glimpses of ideas.

It is weird because you are not actually controlling some character with hitboxes and a weapon. You are commanding armies of NPC units that are physically controlled by AI. Which side should attack first? Should they attack each other at the same time? How do you incorporate troops with different damage amounts and health and defense? And what about support units?

How can I make this such a battle algorithm for my game?

• That's part of the secret sauce of each game. There is no "right" answer, and the exact combination of mechanics that you use is what will make your game unique, and will likely be what makes some people like it and others to dislike it. – Panda Pajama Mar 15 at 7:54
• The first step would be to figure out how you want the outcomes of your battles to be. Can you give us a couple examples from your game and what outcome the player should expect? Then we can maybe come up with an algorithm which gives you those outcomes. – Philipp Mar 15 at 11:46
• I recommend checking the tag guidance for the game-design tag —we've shared some tips there about how to ask a focused and constructive game-design question, by giving background to how your game works currently, and clearly articulating your target experience with examples, as Philipp says. – DMGregory Mar 15 at 13:24
• Do you mean battles which you can see play out in "real-time", where you can see the units attacking each other on a map? Would you be able to give commands to individual units? This would be how most of the big RTS's like StarCraft or Age of Empires work, and in that case there isn't some magic algorithm to determine the winner, but it's determined by the battle actually playing out. Or do you mean you something more like simply clicking "start battle" and then you're told whether you win or lose a few seconds later? That happens in Facebook-type games, and isn't usually too complex. – Bernhard Barker Mar 15 at 13:56

As game designer, that is up to you.

The End.

Alright, alright... Ask yourself how do you want the game to be played. Ask yourself how should the player react with the results of combat. Then, for each aspect of your combat mechanic consider how it supports those play styles and whatever or not it justifies reactions you do not want.

It can be helpful to reduce the mechanic to its minimum. In this case, it would be whoever attacks wins. Is that good for your game? Maybe, but probably not. You seem to want troops, you probably want the players to make them... however, if they don't affect the result of combat, this design does not support any play style that involve making troops.

So, we want a design that encourages to make troops. That means that the more troops the better. Then the simplest design is that whoever has more troops wins. So the player will want to send more troops than the enemy. That is viable.

How about types of troops? You could have some troops have more weight than others. You could have some troops be better when attacking than defending.

Do you want players to pick the best troop possible and then just do a bunch of that one? If not, then you need to give incentive to create different kinds of troops. Perhaps some troops have synergies and count as more when they are together. Or perhaps some troops have diminishing returns, so at some point it does not make sense to add more of the same kind.

Now, we are getting somewhere. You need a function that takes the army and gives it a score for attack, and a score for defense. And you can put there whatever. Yes, the number of troops of each kind, but also buffs, terrain, time of the day, etc.

Oh, I forgot, a common trope is to have some kinds troops have advantage over other kinds of troops. In a rock-paper-scissors fashion. Which can be the foundation of rotating meta. If you want to do that, then the score needs to consider the both armies... so, yeah.

I do not know what buffs exist in your game, or what terrains, or even if there is a day cycle... you know, so you have to make up this function. You, as game designer, tweak it for your needs. It is art and engineering, not science.

Ah, something else you need to decide: are the result just win or lose, or can you have results like they loss x amount of troops, or even they earned experience. Do troops have levels? In some games yes, in some games no.

Here is an idea: you could have hero units, they could be the only ones with experience, and gain levels. They could even have equipment. Now it is an strategy game and an RPG.

And one more thing: are the results deterministic? You can, for example, use the score of the army as a mean metric for a bell curve, with some (hand tweaked by you, the designer) standard deviation, so that the army sometimes performs a little better, some times a little worse. And why should it be a bell curve? It can be whatever.

Should a single unit be able to defeat a large army just by chance? Ern... probably not. Unless that is what you are going for, players are likely to want to feel in control.

What I describe above is output randomness (the player set all the thing the best they can, and then RNGesus comes and messes with the result).

You can convert that into input randomness. That is, the game tells the player that if they attack they will have x random buff. Now, the random happens before the player decides.

You can go further. Perhaps the player has a deck of card, and each attack one is pulled at random. Now it is an strategy game and a deck building game.

OK, so you come up with some model, how do you know if it is right? YOU TEST!

If it does not work, if player react in ways you don't want (be that as evident as rage quit or in more subtle ways), or if the play styles you want are not viable or do not make sense with the given mechanic... well, you go back and tweak it.

Which reminds me. You do not need to have final art to test the mechanic. Heck, you do not need to put the mechanic into the game to test it, you can do an isolated prototype. In fact, some mechanics can be tested with pen and paper, which could make sense in early stages when you yet don't know if it worth the trouble to program the mechanic.

There is another aspect of this, and that is conveying the mechanic to the player. In general, the player does not need to know the details of how these mechanics work in a particular game. However, the game should teach how to play it. And that means that the game got to convey how it works to some degree. The game does not have to tell the player that the army attack score is such and such function of the troops. Yet, convey that more troops means better.

It could be useful for you to play those games with the intent of analyzing them from the point of view of game design. In particular see what are they doing to convey their mechanics. Not only to have a hint of how they work, which is directly applicable to your problem. But also to see what play styles are they encouraging.

All in all, remember that I do not know what is in your game. Furthermore, I cannot tell you what should be in your game. I cannot design the game for you. If you just wanted games designed by other people, you would not be doing this, right? Perhaps, what your game needs is precisely to not do it like everyone else.

As game designer, that is up to you.

The End.

• Thanks for the input. I think I may have what I need from you you have told me. Not a definitive answer, but then again there is no definitive answer to this question. I did not realize just how much the algorithm may vary between games. Nevertheless, your answer has helped me, thanks again! :) – HaiBoy Mar 15 at 16:42