Monthly Archives: February 2012

As the topic says. Multiplayer is hard. If you are a games developer who has only ever made single player games before then you have absolutely no idea the headaches that are involved when you try to make a multiplayer one. They are many and painful.

I am of course talking about my new project “Blue Fire Dawn” and you would be forgiven for thinking that making a Turn Based game multiplayer would be easier than a real time one. It isn’t. With a real time game you can be quite sloppy - it doesn’t matter if you drop a couple of packets because there are so many small updates being sent every second that another one will be along any moment now. Turn based games on the other hand are all about synchronization. When a player tells the server that they want to do something they are usually sending a big long list of commands all at once which have the potential to arrive out of order at the server which has to put them into the right order. Then the server has to make sure what the client sent it is even legal before executing it, rolling dice and sending the results back to all the clients. There is a lot of waiting and validating going on that real time games don’t need to care about.

During an interview with Rock Paper Shotgun the Firaxis guy said that making XCOM was a huge scary project. This is a sentiment recently shared by the makers of Xenonauts. Now consider this: With what I’m working on now I could potentially make either of those games and I’m trying to make it work in Multiplayer. I’m clearly insane.

Here is the thing: It is working in multiplayer. About 3 weeks ago I had a rubbish prototype that worked in single player. Since then I have a rubbish prototype that works in multiplayer (with the exception of the revamped abilities system which I’ll get to). I’ve had to do lots of very boring things like login procedures, replication, lobbies and handling reconnecting clients (If you drop from a game and reconnect within 5 minutes then it’s as if nothing happened. Take longer than 5 minutes and your characters will disappear and everybody can continue playing) but the important thing is that it works. Levels are procedurally generated and match up between clients and everything updates correctly as things move around the world. It’s awesome.

I clearly haven’t hit the actual hard part of this game yet then. In fact I think I’ve just now run face first into it.

Firaxis and I have managed to independently come up with the same ability system for our games. Alternatively we have both managed to independently “borrow” ideas from 4th edition DnD (it’s this one - shhh). Your characters get a number of Action Points to spend each turn on abilities. Moving normally is an ability and costs 1AP. Shooting at a target is an ability and costs 1AP. Going on Overwatch is an ability and costs 1AP etc. You can do these in any order you want and so long as the ability doesn’t have a cooldown or use limit you can do them multiple times in the same turn.

It’s a bit like time units in UFO but instead of an ability being something tiny like turning 45 degrees or moving a grenade from your belt to your hand they encompass a goal or idea rather than the minutiae of how to achieve it. You’d think this would be easier to implement than Time Units but in reality it really isn’t. Time Units are probably the easiest method to make a Turn Based game entirely because they are so discrete.

Take my current head scratcher: The Charge ability.

Charging is conceptually simple - You can make a move for your full movement speed but it must end adjacent to an enemy who you will then attack in melee combat. In comparison to a regular Move or Melee Attack ability this is a tough one because it combines both of them into one. Add to this the fact that I don’t want to have to code every single ability in the game and have a lofty ideal of being able to assemble them as data and things become so very complicated.

I am also trying to decide whether to let players execute abilities one move at a time or if they have to send the entire plan in one go to the server. I know some people will really want to be able to agonise over each square moved just in case the next move reveals an enemy but there is a lot to be said for having to commit to a plan up front (with seeing an enemy allowing you to abort mid-move or continue - either way your action point is gone) and whatever I decide here can have a significant impact on how I design the abilities system and how it works in multiplayer.

In conclusion: Multiplayer is hard but not as hard as having to design an infinitely flexible system that has to account for an infinite number of unknown variables.