If you’re a serious indie game developer continuously seeking to improve yourself, changes are you’ve contemplated the prospect of creating a multiplayer game. Perhaps you’ve brushed up on your server code or found an API that would make networking a breeze to code. But then, you realize, making a multiplayer game ends up substantially more difficult than it seems. After many failed attempts at making multiplayer gaming work, I’ve decided to write this article, to shed some light on the difficulties of such task, and in hopes that other devs or non-devs can offer some feedback on how to produce a successful multiplayer game.
Why Make a Multiplayer Game?
There are always those “duh” questions nobody really asks me but that I feel like answering anyway.
Once, I heard someone say that all games are multiplayer. Even if a game is single player by design, the player is basically playing against the designer of the game. In my opinion, that’s stretching the definition of multiplayer a bit, but I think the point he was trying to make is that all games are more or less social. Even when you play by yourself with Tetris or Flappy Bird, which only have the outcome of losing, you’re still trying to get further than other competitors.
It’s true that games end up being social eventually, as they end up on YouTube where people put their comments, or you can just talk about them to your friends… just like movies, just like the Kardashians, just like about anything in life.
What we’re really looking for in a multiplayer game is this magic moment where you work alongside your friends or total strangers, either to compete against them or cooperate with them. Personally, I prefer competing.
Why Is It So Difficult for Indie Devs?
There are many technical reasons, but for indie devs, the biggest problems are really not the technical ones. To be more clear, there are actually several types of multiplayer games, each having their own specific design challenges. I’ve categorized those types as follows:
Real time multiplayer games
Turn-based multiplayer games
Asynchronous multiplayer games
Local multiplayer games
Real Time Multiplayer
A typical example of this would be StarCraft. This type of multiplayer game is the one that presents the biggest technical challenge.
I’ll briefly mention the technologies I’ve tried:
Writing my own PHP server: Not scalable and very difficult to manage.
RTMFP + Cirrus: Very low latency, but doesn’t work on any computer with a firewall (public libraries, schools, company networks, some homes).
Player.IO: Very promising so far, but doesn’t have a REST API, so for me it’s only usable in Flash.
Firebase: Very promising as well for JavaScript; I’ve just started using it.
So there are many uncomplicated API’s out there that allow two players to communicate through the internet. But that’s not the end of the problem.
When someone performs an action on one end, it takes a few milliseconds to reach the other side. Let’s say Player A shoots a bullet at t=0ms, and Player B is shooting at t=1ms. It means Player A shot before Player B, but it takes more than a millisecond for the action to propagate from A to B, so from Player B’s point of view, Player B shot first.
One way to resolve this issue is to have one central machine decide who shot first (it could be a separate server, or it could be any of the players’ machines). This causes a latency problem, though. To get the feedback that you shot, the signal has to make a round trip to the central machine. It’s only a few milliseconds, but it’s enough to make the game feel sluggish.
I found that the best way to resolve this is to accept that the world is not completely synchronized. So we have to accept that the position of Player A will be more precise from Player A’s perspective than from Player B’s, whereas the position of B will be more precise from B’s perspective than A’s. When a bullet’s about to hit Player A, the decision whether the bullet collided should be made on Player A’s machine. So while Player B might perceive that the bullet hit his opponent, it could be a miss. That’s less frustrating than having Player A dodge the missile but still get hit, just because the computer on Player B’s machine decided so.
This synchronization issue is easily solved as long as you make sure which machine handles the important decisions (like collision detection or other main events); but actually, the technical aspect is not even the biggest problem for real time multiplayer games.
The real problem is that there are NO PLAYERS! Oftentimes, you’ll find a multiplayer game with nobody to play with, except during the launch day. Most indie games don’t have enough popularity for people to stick around in lobbies long enough to meet other players. In fact, even some AAA games have this problem. When trying out the multiplayer feature of Civilization V, I found myself sitting in a lobby for a very long time, before finding a group of players who just dropped immediately.
While I haven’t really found a good solution to this problem, I have had a few ideas:
Drop the lobby: While the lobby is a nice place to chat, if there’s nothing to do there, it’s really boring. Nobody is going to last more than 10 seconds inside. If possible, just start the game anyway and make it interesting enough for a single player, then the game itself becomes the lobby and people won’t have to wait so long.
Looking for player… with alarm: Create a matchmaking system, but make sure there’s an alarm that lets the player know if a match was found. In this case, players could possibly tab out of the game and do other things while waiting for an opponent. Then the game needs to catch the player’s attention if a match is made.
A lobby for many games: A lobby shared among several games could have some success, I believe. It could be a place where people would chat, and then could just decide to join any multiplayer game. This would require the development of a large community, so it’s not an easy task for a sole game developer.
Secretly multiplayer games: I haven’t found this technique done in other games, but I did apply it to one of my own games (Slimilization). Basically, the game is not meant to be multiplayer. It is not advertised as being multiplayer. However, it is multiplayer, whether you want it to be or not. I found this technique to be the most effective and an interesting one. Basically, while playing, you might encounter an AI that seems strangely humanlike. For this to be useful, you need to provide enough hints to show that the other player is human (otherwise it is pointless). You could simply have a chat system, but of course who’s going to chat thinking they’re the only player in the game? In Slimilization, I used the following hints: First, the mouse cursors of other players would show up on your screen as circles. Also, when you built your wonder, you had the option of giving it a name. As soon as the wonder was built, it sent a message to all players that “A wonder named ???? was built in a faraway land”.
I think this kind of multiplayer trick is the most effective because you don’t expect it. But, for it to work well, the single player aspect of the game needs to be interesting on its own.
Turn Based Multiplayer
Technically, turn based multiplayer is less difficult to implement than real time multiplayer. We don’t have to deal with issues of latency, since waiting up to one or two seconds really doesn’t matter when you’re just waiting for someone to finish their turn. Any system that stores data can be used to handle turn based multiplayer (in fact, Game Jolt’s data API could be used). All you need to do is save the state of the game. One player has read/write access over the data, which lets him or her make moves. Other players can continuously poll for it every 5-10 seconds. Once the turn has ended for the current player, the game state is accessible to the next user.
One feature that might be needed is the ability for any player to skip to the next turn if some time has elapsed. This handles cases where players just quit a game and never come back.
Some good examples of turn base game are Conquer Club and my favorite: Weewar. Civilization is also turn based, but the aggressive timing on each turn makes the multiplayer experience almost feel real-time (you can’t take a break and go AFK). However, I do think that having Civilization use the turn based system of Weewar would make an excellent experience.
One technical challenge with turn based multiplayer games is the fact that you need to store each game session for a long time. Games might last for several hours or days. Technically, it’s not really that difficult, unless the number of sessions gets increasingly large, in which case your game is quite successful so you should be happy!
The major problem indie games face with turn based multiplayer, again, is not technical. Turn based game are even more dependent on having a large community around the game. Even if you don’t necessarily have to be playing at the same time as your opponent, you do need to play with committed players. Nothing is more frustrating than have an excellent match going on, and having the opponent just give up midway.
I personally have not tried to make a turn based multiplayer game (except for Chess). If you do have a good example of a successful turn based indie game, please post it in the comments section below.
Asynchronous Multiplayer
This type of game is, for my own tastes, the least interesting. Still, it has quite its share of success among casual gamers.
A good example of asynchronous multiplayer would be Clash of Clans, or, if I dare to call it a game, Zynga’s Farmville!
I have had my share of working on asynchronous multiplayer games. Back in the day, I was in a startup that made farm games for Facebook. Later, we had tower defense games, a bit similar to Clash of Clans.
Somehow, those types of games never caught on woth me, but there really is some potential here.
The basic idea is that you build up your base, and later on when you’re not playing, another player tries to invade it using their army. (for Farmville, it’s more like you build up your farm, then another player comes and steals from it).
This type of multiplayer game differs from turn based multiplayer because you never have to wait for someone to finish their turn. The concept would be similar to a person designing a level in a game, and then another person trying to beat it.
Wait, so it’s actually a single player game!
It essentially is, but you do have some feeling of multiplayer, perhaps because you have a closer connection with the person who designed the level. It’s not a random game designer you’ve never met, it’s your friend who designed the level and you have to beat it.
Nowadays, the Clash of Clans formula seems to produce clones of basically the same idea, just like Farmville spawned several farm games back in the day. It’s really too bad, because I think the concept of playing a level designed by your friend has great potential, so we might have to wait for that in the future. If you do have an example of such a game, please put it in the comments.
Local Multiplayer
Thankfully for indie game developers, we can always rely on local multiplayer games. While those games are not without their own set of problems, they seem to be the most simple and natural to implement, out of all the types of multiplayer games mentioned in this article.
Local multiplayer means that you basically play the same game on the same screen, with two controllers or two separate areas on the keyboard.
Without worrying about networking, you eliminate a huge area of programming headaches. There’s no problem of synchronization because it’s only one game instance running.
One game jam last year was entirely composed of local multiplayer games. Check out Jupiter Hadley’s coverage of them:
The issue I have with local multiplayer, which incidentally also adds to its charm, is that you are forced to be in the same room with the other person when playing the game. What’s wrong with that, you might ask? It’s great, of course, but it is very situational. With many people viewing your game and most of them being by themselves, it’s likely that those people won’t be able to play. Some might even leave a bad comment just for the fact that they cannot play by themselves. Of course, there are also some people who will judge the game without even actually playing it, but by imagining how it is like to play with two people, which is ok but it’s not real feedback.
To make the game appeal even when you are not with someone, you might consider making it single player as well. This often depends on the design of the game. I was able to do that with My Champion Oliver because the game is essentially single player, while the second player is a bonus on top of it.
For a game that is strictly two players, you might need to implement an AI component. Unfortunately for developers, AI is an area of programming that might be even more difficult than networking. A lot of games solve some of the AI headache by cheating. Basically, it’s too difficult to make a computer play better than a human, so you can give the computer player an advantage: by upgrading their weapon, giving them hidden information, increasing their resources…
Another problem with local multiplayer to keep in mind is the control scheme. Not everyone has Xbox controllers hooked up to their computer. To appeal to the majority of players, you need to allow controls to be crammed onto one keyboard. While the experience is quite cozy, it is not always confortable. One way to avoid bumping into each other’s arms when playing a local multiplayer game is to plug in an extra keyboard. Then each player will essentially have their own controller.
One project that I’m hoping to start soon is a way to turn mobile phones into controllers. Most people carry around their mobile phones, so I think it would work quite nicely: Each phone is a controller, and you have a computer hosting the game and connecting through each phone wirelessly. A problem I foresee here is responsiveness, but I will test to see how it goes.
In the area of local multiplayer, we do see a ray of hope. First of all, the experience is very social, and more and more gamers are open to getting game controllers for their computers. Also, game consoles are becoming more and more open to indie developers. In an ideal world, indie developers would be able to code directly to an Xbox or a PS4. I’m not sure how far that has gotten, but last I heard we are moving towards it.
And don’t forget, there’s always Ouya!.
Have any tips or lessons learned from making (or playing) multiplayer indie games? Share them in the comments!
9 comments