As teenagers, we spent delightful moments playing the Dune 2 and X-COM TFTD campaign modes. At that time, we regretted the lack of a multiplayer campaign to let us challenge or cooperate with our friends.

Years later, we decided to develop an MMO RTS game that would remind us of these classics: in our game, Win That War!, three opposing mega-corporations are battling over the dominion of planets, which are divided into territories, each to be individually conquered in order to dominate the whole map.

Unlike the planetary gameplay in Planetary Annihilation, the concept is not to manipulate planetoids in real-time during battle, but to use a spherical map as the higher level of tactical view in the strategic planning and decision-making process.

When we were just starting out, we had no idea of the actual feasibility of the project, and have met with a mountain of hardships. This article depicts the problems and concerns that we have had so far, and the solutions that we have implemented up to now. 

Latency saves the day

Firstly, creating a global-scale simulation usable by thousands of simultaneous users, divided into hundreds of territories harboring thousands of units, is easier said than done. We made it a point to avoid using a centralized EVE-like system, which would have brought several more difficulties including:

In order to avoid these problems, we attempted to create a distributed simulation, relying on a peer-to-peer based architecture. 
Peer-to-peer systems also come with their inherent drawbacks:

Relative levels of latency do not impact RTS gameplay as much as other types of gameplay. When a player inputs a command, the UI immediately returns feedback that the order has been taken into account. In fact, though, up to 400 milliseconds can pass between the input and the order's actual execution. The player's experience is not affected, because what he needs to know is that the input has been understood. His or her attention is already focused on the next task.

This inherent property of RTS games also enables us to spare considerable amounts of bandwidth. For that, we use the concept of lock-stepping, as explained in this fascinating post-mortem of Age Of Empire, by Mark Terran and Paul Bettner: http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php

Long story short, the simulation is sliced into steps, as if we were programming a turn-based game, with each step lasting around 100 milliseconds. Executing at the start of each step the inputs gathered during the previous one, allows us to guarantee perfectly synchronous simulation on all peer machines.

As a consequence, processing information about the state of simulation through the network becomes pointless, since only the information about player inputs matters. The bandwidth cost saved is such that even a poor connection suffices to maintain fluid gameplay.

But what about cheating?

The third and last matter of concern is cheating. The absence of a common intermediary (the server) renders the simulation more vulnerable to malicious behaviors.

Using numeric signatures in the .NET assemblies, protecting against client modification, is not a sufficient measure: it still allows modification and forging of network packets, which has the same practical results. Thus, we are considering various techniques to remedy this.

Firstly, each client is detecting abnormal behaviors in other clients, and reporting to the server. This, of course, only works if a majority of players are not cheating. Introducing a group of malicious modified clients into the network, that would wrongly report the innocent clients, would make a mess in the system.

That is why we need to complement the client-side checks with a server-side analysis of replay data. This analysis method also gives us interesting metrics about use stats and game balance.

Thus, the goal is not to completely break free from using any servers, but to limit their role to connecting players together and performing security checks.

What's the business model?

RTS games essentially have a lot of replay value without necessarily adding content continuously. This is why we thought it preferable to offer a full-premium model with no subscription, lest we be frowned upon by the player community. We also kept in mind the somewhat mitigated success of AoEO, in which case the premium model seemed to meet very negative reception among users.

This is why we're trying to launch a “pay once, play forever” MMO game. According to our benchmarks, our network stack should allow us to reach very low upkeep costs, and will allow us to focus on content releases and to costlessly maintain the servers for a very long time after the game's release.

But do RTS fans want an MMO game?

Going to gaming-related events, we realized that, although many players are very excited at the idea of playing an RTS in a massive persistent universe, many RTS players are much more into solo campaigns than PvP gameplay.

Even competitive players who play ranked matches tend to appreciate a didactic and immersive solo campaign that lets the universe and mechanics of the game sink in. It lets them train on their own and fail without punishment enough times to feel ready to confront other players online.

This is why we modified our initial plan to incorporate the development time and resources for a solo campaign, that would be more than a tutorial, and actually have a great deal of narrative elements and traditional level design.

Now about the MMO campaign itself, in spite of the very positive echoes that we collected when we playtested our first planetary gameplay prototypes, it's still probably a lot too soon to know if this game mode will find a lovinguser community. It's the bet we are taking by making Win That War!.