The ups and downs of doing online multiplayer as an indie | Hacker News Reader

The ups and downs of doing online multiplayer as an indie

gamasutra.com

37 pointscpeterso17 comments

A big issue for indie games is critical mass.

In order for online matchmaking to work, you need a pool of players that are waiting to play; especially for game modes that need many players.

Once there are time periods where people can't get a game for, say, 5+ minutes, then they'll quit. This will mean less people also in times where previously there were enough players, causing even more gaps where it's unfun with long matchmaking times, and cause even more people to quit until your online gaming is gone.

If you're safely above the critical mass, you can stay there for years; but once your numbers drop slightly below the limit, they'll go right down to near-zero.

QuizUp (I think that was the name) had a really interesting way of solving this - they pretended the users are online. Is this lying? Maybe, but for anyone not aware of this fact the experience was great. Now, QuizUp is probably a more unique case because the action on the users' part is very simple (simply choosing an answer). They simulated a real user by varying the response time (presumably based on the real user's results... hopefully anyway.)

Forza Motorsport 5 also does an excellent job of this, albeit they tell the users that they're not playing real people. Users play matchmaking, career mode and free play (career mode and free play being the game modes that include simulated players). As you play, Xbox Live services used by Forza become more aware of how you drive and your "drivatar" (that is, the fake player you become when other people play non-multiplayer game modes) becomes more accurate.

I think over all it's a great experience in both QuizUp and Forza 5, and I don't necessarily see a problem with faking users with simulations when the online populations are low.

I wonder if it would help to have the match-making server track and display online stats to players looking for other players, so they would know at which times they'd have to log in to have the biggest chance of having lots of other people to play with.

This is an useful feature that may help your remaining hardcore fans continue playing after all the "normal people" have left.

I.e., this will make playing 'below critical mass' somewhat bearable, but it's just mitigating a failure - the goal should be so that players don't have to think about this. A new player trying out the game won't wait until the "right time", especially one that might be suboptimal for his time zone; they'll just pick another game instead.

The key factors for short waiting times are :

1. lots of players (obviously)

2. high uniformity (low variation) of gameplay modes - if you don't have huge numbers, you don't want 30 separate tiny pools each waiting for players of somewhat different games, you want a single (or a few) common pool, so you can match anyone against anyone else. Nuanced matchmaking is for cases when you can afford it w/o sacrificing waiting time.

3. Quick round length, so that other players often return to matchmaking, giving a freshly logged-in player more chances to join-in.

4. If the game allows for it, ability to join already running games helps a lot.

5. Global reach - if your game is used in many timezones, then the peak/offpeak hours even out, and a player will be able to play at 5am on a thursday because it's prime time on the other side of the world.

An example on how NOT to do this is World of Tanks historical battle mode. WoT does have a significant number of players (I see ~50k online players in the middle of the night), but they have made a new mode that is useless, as it (1) has separate queues, where each is below the critical mass to actually run any games in a reasonable time; (2) requires a high number of players to start (20+), so if the pool has a dozen players, then nothing will happen, ever; (3) there are restriction on what players may join which side, which reduce the matchmaking pool even further. On the other hand, if you optimize for ease of access, then you can have a healthy community with much, much smaller number of users.

That's a neat idea, but as someone who has played a few niche online games before, players tend to figure out on their own what the most active hours are (e.g. evening to a bit past midnight EST for English speakers).

I remember when I was younger I would play games where the game would designate a "host" player. If that player quit the game would pause and it would show a message like "searching for new host" and in a few seconds the game would resume from there. I am guessing this player acted as the central server for that particular game. I don't see this very often any more. In fact, I can't think of a single game that does this off the top of my head.

Anyone know why this isn't a viable solution now-a-days? I know MMOs wouldn't be able to do this, but something like League of Legends where there are only a set number of players (smaller is better). This frees the developers from a lot the responsibility of maintaining servers. They would probably still need some to actually hook up the players in the beginning, but that's about it. That could be as "simple" as a web app (like Battlefield's "Battlelog").

IIRC almost every online game for the Xbox 360 uses the P2P strategy (which is funny, given that Microsoft charges for online), so I wouldn't say that it isn't common or viable. You don't see it as much in PC games because PC gamers are more capable of running their own dedicated servers, which provides a superior experience while still shifting the burden from the developers to the players. P2P is still the norm for genres with small numbers of players per game (1-on-1 fighting games, co-op games with small parties).

EDIT: I'd assume the reason that games like LoL don't use P2P hosting is that the games are competitive and ranked, and having players host in any fashion would make it all too easy to cheat your way up the leaderboards.

Some games do still allow players to host. Team Fortress 2, for example, and it's quite common with friendly games of Minecraft. I honestly can't recall any games that can switch the host player on the fly, though. Even then, the new host's hardware and connectivity may not be up to the task.

In any case, player hosting was always problematic. Running a server for a couple of dozen players is intensive both computationally and network-wise; if the host doesn't have a powerful machine, solid bandwidth, and low latency, everyone's experience suffers. You need a really powerful machine to do all that and deliver a high-framerate 3D experience to the host player at the same time. And if anything gets disrupted on the host's end--they tab out to check email, or a scheduled virus scan kicks in, or their roommate starts watching Netflix--everybody's experience suffers.

And then of course a lot of modern games don't allow player-owned servers at all, dedicated or otherwise. That's an entirely different set of poor decisions, though.

I remember even Warcraft 3 still worked that way, so the mechanism just disappered in the last 5 years or so. I don't know the technical details/reasonings behind that, but from a gamer perspective, here are my guesses:

- The player need to be able to actually "host" the game, that means port forwarding if you're behind a NAT (which is pretty much 100% of the players). I think for Warcraft 3, if you're playing the ranked 1v1 game, both of you connect to the Battle.net host, but in order to create a custom game, you always need to enable port forwarding. The process, needless to say, is not easy for the majority of the users.

- The playing experience greatly depends on the host's connection speed, and his location to the rest of the players.

- Cheating. When a player acts as a central server, it's a lot easier for that player to modify the game state and force it upon everyone else.

Consoles these days don't have a whole lot of left over power. By the time they're done running graphics and physics, there's not a lot of CPU left over to deal with running a server and sending out updates to everyone. That means if you get stuck being the host player, you're going to have a worse experience then everyone else.

Civilization V does this in multiplayer games, only thing is that you can continue without the other player if you'd like - and a computer player takes over instead. The other player can then either join the game you're keeping alive or start hosting again.

Almost every single console multiplayer game runs the server on a consumer console. Most, but not all, support host migration.

Host migration is a bitch. It sucks. You do not want to be the sucker tasked with making it work.

I like Daniel Cook's comment: http://www.gamasutra.com/view/feature/217434/the_ups_and_dow...

I read it as, "Are you aware that the engineering costs of non-local multiplayer can pay out many more rewards than simply designing for local multiplayer?"

I think framing this problem in terms of a design challenge yields a lot of fruit. Can my game be turn-based or only vaguely real time? (see http://triton.ironhelmet.com/ or any number of board game translations) What kind of players are attracted to games that don't demand large simultaneous time commitments? Etc.

I wonder if it's even theoretically possible to create a drop-in netcode solution that gives satisfactory results for all games with minimal effort. Or even for a specific subset of games, e.g. 2D platformers. (Turn-based games, of course, are trivial.)

I'm inclined to think that it's not possible, since netcode always involves compromises, and the "right" compromises are going to vary a lot depending on the game. Over short distances you can achieve ping times good enough that it doesn't matter, but over longer distances the speed of light puts an absolute cap on your pings--13ms for New York to L.A., as much as 67ms for points on opposite sides of the equator.

GGPO (http://ggpo.net/) isn't exactly drop in, but it works well for most games that require low latency and have minimal per frame state changes (most arcade games). Integrating a GGPO like solution into Game Maker or Unity might make it easy to enable netplay for most games in the style of modern local multiplayer indie games (Bari Bari Ball, Hokra, Samurai Gunn, Towerfall, Nidhogg, etc.)

Unity announced a complete rewrite\update of their existing network code (http://blogs.unity3d.com/2014/05/12/announcing-unet-new-unit...), but it seems to be mostly be a fixed implementation of existing functionality rather than a true drag and drop networking solution. In practice there is no solution that works for everything, but it should be possible to build a solution that works reasonably well for a large subset of games.

Online Multiplayer has been hands down the biggest problem I've had to deal with while working on Wyv and Keep (plug: htp://www.wyvandkeep.com). It's still buggy as hell, because I still have no idea what I'm doing, I'm spending plenty more time fixing it before we release on Steam, because the current implementation is Not Good Enough.

I'd estimate it's at least doubled the dev time, if not more, due to the amount of stress and extra work it's caused, having to refactor the codebase in order to support it (arguably resulting in much better code, but that's really irrelevant if the game works well), and added years to the dev time due to having to spend the odd weeknight and weekend trying to remember the complexities of it. And this is for a relatively simple game!

My single best piece of advice to rookie indie devs thinking of adding it, especially when they have no prior experience with, is this: Don't. It's not worth the trouble.

This is something our small team has been faced with over the last few weeks. Creating a great multiplayer experience is certainly one of the more difficult and maddening tasks a game developer will face, especially when it comes time to scale that if you are so lucky as to have success with it.

Reply on news.ycombinator.com