Introduction

Peculiar title you got over here – how can something be both turn-based and real-time? I shall start with a short introduction showcasing the mechanics and ideas which brought me here.

We’ll start with the fact that I use the Game Maker Studio engine. Some year ago I was trying to make online multiplayer work for a hack’n’slash game. I tried around 7 methods of varying degrees between sharing input data (right button, left click etc.) and sharing raw data regarding each character (its location, its health, its state etc.).

All did fail because of latency. There was this one moment, I was testing the game with someone, in which I died both on my server and on his client. You can imagine the hype. We were so very excited – until I asked about where I died and it turned out that I died on different locations on my server-side than his client-side.

Latency is a buzz-killer, no less. Instead of trying to find some work-arounds, I decided to shelf it.

Later-on I found myself working on a simple AI for a creature in an action-RPG. It was able to follow me (or the location I was last seen at), they collided with each other, all nice and fine. As of recent, I experimented a bit with card games (call it Hearthstone-hype).

One thing I wanted to try was having troops come out of cards. Sort of like Duelyst, or Battleforge. Turn-based multiplayer doesn’t suffer from latency, thus making an online card game to duel with my friends was viable. Then, somehow, it hit me. It must’ve been perhaps that previously that day I troubled my mind with philosophies regarding determinism and free will.

The Idea

Both players (or the player and the computer) play cards from a deck. Each card is either a troop or a spell. Troops are placed on the battlefield at the desired location, spells are cast, and once both players are ready, the round starts. Once the round starts, both player have absolutely no control over it. The AI runs wild.

Since the algorithm doesn’t include any kind of randomness, the results of the battle will always be the same. Whenever you run all these characters at their exact stats and exact positions, the outcome will be the same. This means two important things: simulations are doomed, bound to determinism; and, more importantly, both the server and the client (or both clients, in the case of peer-to-peer) will get to the same result, through the same processes, if given the same input.

This, for me, was a revelation, nothing less.

Given that this is a complex system, even the smallest input change can chain into a great result discrepancy. If we were to move one of the archers forward, you shall see that the outcome is different.

Balancing

I must have toyed at least an hour, just with the archers and the warriors. I am sure that fun will come through the little guys interacting in the finished game as well. However, since even the smallest change of positioning can change results greatly, it is obvious that heavy balancing has to be included.

One obvious limit to positioning that can be implemented is having the creatures be placed only in a line. The more bi-dimensionality it is offered, the harder it might be to predict the outcome.

Given that the troops will vary so much, and that their abilities might benefit certain positioning, the wild element of the butterfly-effect (the one seen in the videos) might not play an effective role.

All that’s there for me now is to start working on balance, drawing graphs, opening Excel sheets after Excel sheets – just the way I like it. Given that I will have bards that sing songs which increase the movement speed of nearby allies and mages casting explosive fireballs, it will go pretty wild.

Conclusion

Thank you a lot for reading! This is a rather short article in comparison with previous ones, and it might not be as informative, but I do hope you found some inspiration in my thought process and progress.