Gamasutra: The Art & Business of Making Gamesspacer
The ups and downs of doing online multiplayer as an indie
View All     RSS
July 29, 2014
arrowPress Releases
July 29, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
The ups and downs of doing online multiplayer as an indie

May 12, 2014 Article Start Previous Page 4 of 5 Next
 

"Any programmers I have met who had never made a commercial-quality online multiplayer game hugely underestimated this part of building multiplayer," he says, adding, "Anyone who has never made online multiplayer before should only do so if they think it is an essential feature for their game. It is so much work that online multiplayer should never be made as 'just an extra.'"

On the other hand, he notes that Awesomenauts has proven to be a big success for Ronimo thanks to the online multiplayer options, and his studio is very happy that it made the effort to add these options.

"If you manage to make a successful online multiplayer game like Awesomenauts, this can sustain your studio for years," he notes. "Awesomenauts has been out for two years now and is still very much alive, which would normally not happen to a single player game that people just finish and that's it. Having this kind of competitive community is incredibly cool and online multiplayer is a great way to create that."

"Whether we would do it again depends on whether it fits whatever we are making," he says of the future for Ronimo. "It is a huge investment and in some games it would be worth it, while in others it would not."

Awesomenauts

Finally, we turn to another Dutch studio that knows a thing or two about online multiplayer in twitch-based games. When DoubleDutch Games first built SpeedRunners for Xbox 360, the game was local-multiplayer only -- but the move to PC sparked the idea of adding online play into the mix.

Very quickly, DoubleDutch hit a wall, and simply could not get theSpeedrunnersexperience to work in an online capacity. Fortunately, as documented before on Gamasutra, the team at Ronimo was happy to give the team some tips.

"If you manage to make a successful online multiplayer game like Awesomenauts, this can sustain your studio for years."

"Implementing online multiplayer was very difficult," developer Casper van Est tells me. "People always warn you about it, and even with that taken into account, it turned out more difficult than we expected. We're a small two-person development team, so we already knew implementing it was going to take a while, but it ended up taking us several years."

One of the main reasons that it took so long was because the team was being too nitpicky about it, trying to implement online play as perfectly as possible, which resulted in a system that was simply too complex to pass across a network to another player.

"We started out implementing online multiplayer more or less along the lines the way Valve did it, which involves complex things like input prediction and interpolation to compensate for lag," he tells me. "Even for a relatively simple game like SpeedRunners, this turned out to become very complex very fast."

It was after watching a talk from David Aldridge, the lead networking engineer on Halo, that the DoubleDutch team realized the most important thing about implementing online multiplayer: "It's not about creating a world that is the exact same for every player - it's about creating an experience in which each player believes they're operating in the same world as the other players."

"This means that not everything has to work perfectly in-sync on each player's screen," adds van Est. "It's more about creating a consistent experience in which all players agree on the 'bigger' gameplay events (such as who scored a point), while small differences are allowed (such as at which exact location a player or a crate or whatever is at)."

Taking both Ronimo and Aldridge's advice into account, DoubleDutch found online multiplayer development progressing at a far quicker rate.


Article Start Previous Page 4 of 5 Next

Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[07.29.14]

Associate Cinematic Animator (temporary) - Treyarch
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[07.29.14]

Senior Environment Concept Artist - Treyarch (temporary)
Wargaming.net
Wargaming.net — Chicago, Illinois, United States
[07.28.14]

User Experience Lead
University of Oklahoma - Norman
University of Oklahoma - Norman — Norman, Oklahoma, United States
[07.28.14]

Game Art Director






Comments


Julian Toker
profile image
"It's not about creating a world that is the exact same for every player - it's about creating an experience in which each player believes they're operating in the same world as the other players."

Very clever concept.

Phil Maxey
profile image
Online multiplayer is one of the most difficult things to implement in game development, even in a turn-based strategy game such as I'm developing, the issues mount up if you want the player to be able to see a replay or have an Undo option, but having said all of that when I look back on most of the games I've had most fun with over the years they have been multiplayer games both online and local play.

@clankingdom is going to be online multiplayer only to start with, and my next game after that is also going to be online multiplayer. I think some aspect of playing with or against other people is essential in a game these days.

Sally Monet
profile image
I agree, been working on multiplayer HTML5 game for months, was rather difficult, though I gained knowledge and experience :)

Kiran Nair
profile image
The IGF student showcase 2014 winner, Cyber Heist is a good example of a multi player co-op game executed well.

Martyn Hughes
profile image
Our game, UnitedFootball, is a 4 v 4 online soccer (football) title. And it has been a nightmare... The multiplayer complexities in both the network model, gameplay and even in terms of getting players into games are an order of magnitude more difficult than if we had done a single player game...

Our dev team absolutely hate the fact it is multiplayer due to the above reasons...

Pedro Fonseca
profile image
Nothing exactly new nor defying common knowledge regarding opinions and advices.

Still, very interesting and somewhat reassuring to read it coming from people with way more experience than me, if not for any other reason, just to give me some peace of mind that I'm not being an old geezer telling them kids to stop playing online and all sit on my couch for some local co-op like in the old days.

Daniel Cook
profile image
One thing is often missed about online multiplayer is that it is as much a design challenge as it is a technical challenge. Screw up a few logistical key concepts and if your concurrency isn't high enough, no one gets to play. Matches that require a fixed number of player and synced start times are deadly. You don't design a game and make it online multiplayer. You design an online multiplayer game.

(An older essay on the topic: http://www.gamasutra.com/blogs/DanielCook/20140104/208021/What_Iv
e_learned_about_designing_multiplayer_games_so_far.php)

Local multiplayer is a tricky fallback. It has been around for ages and has some well known drawbacks.

1) It tends to be played by a handful of people that are able to get together regularly in the same physical space. Kids, college students, roommates. Almost all other groups are rarely in situations that allow for couch play. Developers are prone to testing bias here, because they are one of the few groups that plays games together locally. :-) "Hey, we are having fun! So will everyone else." Nope...because they aren't like you.

2) It isn't actually played that often. Most couch games have play patterns similar to board games. They come out on rare gatherings and gather dust otherwise.

3) Since both retention and engagement are low (for 99% of the audience), it is always a premium product. You need to get money up front for a game that the buyers will almost never play. This limits DLC and IAP if this was a consideration.

4) Because the value proposition isn't that great for most players, you end up making a single player game anyway in order to sell it. So scope increases as do costs. Historically, local multiplayer only games don't sell well (10-20X difference) You may not be in it for the money, but a consideration.

All the best,
Danc.

Brandon Wu
profile image
Couldn't agree more! For us, the design challenge resulted in even more technical challenges!

We wanted to avoid having to have everyone start at the same time for a match so that more people can get into a match quicker, and ended up with a RTS-style match with an authoritative FPS-style setup - matchmaking, server instance headaches... Three networking platform changes and now on the fourth iteration, I can't wait for the day we ship *something*! ;-)

(link to game: http://www.pepwuper.com/portfolio/item/my-giants/)

Iain Howe
profile image
Yup. This post is a great self-check and a reminder to craft solutions for your target market - not for yourself. Since most studios have a/multiple couches in front of console setups, we tend to assume that everyone does.

Curtiss Murphy
profile image
I struggled with multiplayer networking for years, until I eventually compiled my lessons into a chapter in Game Engine Gems 2, "Believable Dead Reckoning for Networked Games" (PM me with your email for a PDF copy).

I loved this article! This quote sums it up: "Online multiplayer is the most complex part of game development there is," says developer Joost van Dongen, bluntly. "Adding online multiplayer roughly doubles the programming time needed to make a game, especially if this is the first time for a developer."

Kevin Fishburne
profile image
My two cents on how I got online multiplayer working in my game:

1) The only player input sent to the server is raw gamepad data or a text string for chatting.
2) The client and server have an incoming transaction queue, outgoing transaction queue and outgoing transaction queue history for resending transactions not acknowledged in time.
3) The server updates different types of world data at different rates so that more important things like player transaction handling take precedence.
4) I use custom UDP transaction/packet handling to enforce transaction ordering and preventing double-execution of inappropriately resent transactions.
5) The server processes all clients each "frame" and concatenates like transactions so they may be sent to a player as a single transaction, reducing overhead when many players are in the same area.
6) Clients receive new data only when it has changed and never at a rate higher than 10 FPS.
7) Clients have "current" and "target" positions/orientations/etc. The current position is what's being rendered and the target position is their true position as sent by the server. The current position is interpolated toward the target position each client render frame. This creates the appearance of inertia and masks latency.

The main things not yet implement that I'll need to watch for are clients sending bad data (too much or too little) that could crash the server and clients flooding the server with a transaction (DoS attack).

Implementing this was my first real experience with network programming, and while I can say it was damned difficult, it wasn't the most difficult thing I'd ever experienced. So if you're going to do it, before you write a line of code, plan it out in detail. You'll save a few burst blood vessels and it will hopefully do what you need it to without being easily exploitable.


none
 
Comment: