Multiplayer is Hard
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.
Gnoupi
February 17, 2012 @ 1:44 pm
I think people at Arrowhead discovered that the hard way also with Magicka.
Magicka earned a reputation of a buggy game, mostly because of multiplayer issues. There were other bugs which were not related, but nothing so big or which would have stayed for long.
In Magicka, you can make your own spells by combining 5 from 8 elements. And the effect depends on the combination. There are status effects, physical forces (push), shields, laser rays reflecting on shields… Etc.
The game worked quite ok in single player, or in LAN. But as soon as you hit multiplayer, you realized that not only it was streaming a very large amount of data (the host for a game of 4 players had to have more than 110 kbytes/s in upload), but also they didn’t expect the most common issues with this kind of online multiplayer. Packets get lost. Or are late. Or come in the wrong order. Or you don’t know which you should deal with at which time.
And it lead to a full bucket of null pointer exceptions. Or invalid states for entities. And when you encountered such thing, it was not planned at all, and the exception was simply going up, leading to the game just crashing. People who played the first week of Magicka were actually happy to finish one level without someone getting disconnected (and it was very, very rare).
30+ patches later, the game is more or less stable, but you really see that they had issues. And they didn’t see a thing from it earlier, because all their testing was made on a local network, or on very fast connections.
But indeed, it shows the difficulty of such development (especially when you don’t have the experience).
February 17, 2012 @ 3:30 pm
I’m lucky because the networking framework in Unreal is incredibly robust and has been used heavily over alot of internet games under some of the worst circumstances.