Gamasutra: The Art & Business of Making Gamesspacer
The ups and downs of doing online multiplayer as an indie
View All     RSS
July 31, 2014
arrowPress Releases
July 31, 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 2 of 5 Next
 

So when it came to making the decision about whether or not to add online multiplayer to their game, Woodrow and his partner in crime Sarah Woodrow asked themselves whether doubling the game's development time to add online multiplayer was worth it.

"With the Xbox version we felt that it was important that we at least offered it," he says. "There were only two of us and it was only a six month development overall. We felt it was worth it, but whatever time you think it will take, add lots more to make sure that you have enough time to polish and test the online experience."

Notably, Chompy Chomp Chomp was designed to be a local multiplayer game, with online added later on -- and as such, it turned out that playing the game locally was more fun than online.

"If you want to deliver a solid online multiplayer game, I think it would be best to focus on that context and experience," Woodrow muses. "You need to make design decisions around delivering the best online experience that you can, and take that into account throughout the whole design process. If you add it as an after thought it will be a lot harder to implement and deliver a good experience to your players."

"We had a hypothesis that people would get their friends to buy the game so they could play it online together. We haven't found any evidence that this happened."

So was adding online multiplayer to Chompy Chomp Chomp worth the three months of development time? Says Woodrow, he's glad he added online multiplayer to the game, but that doesn't mean it's had a great effect on sales.

"We had a hypothesis that people would get their friends to buy the game so they could play it online together," he explains. "We haven't found any evidence that this happened. From what we can see it was more people evangelizing the local multiplayer experience that got their friends to buy it."

Going into the Wii U version, the team has taken these lessons learned about the popular local multiplayer aspects, and are applying them to an enhanced version for the Nintendo console.

But on the flipside: "We also wanted to deliver a game that showed what we could do, as it was our very first game," Woodrow notes. "It was a good achievement, and we've had some amazing feedback based on it. Some of our players are incredibly happy that we added online and we made it for them."

As for Utopian's future games, the team plans to always focus more on local multiplayer than online play.

Chompy Chomp Chomp

"Online play will never be perfect for everyone," he concludes, "so make the decision based on whether or not it matters to your players. We decided to give our players a choice. It may not always be a good thing to offer that choice."

Dan Marshall of Sive Five Games dabbled in online multiplayer for the first time last year, when he released Gun Monkeys, a one-on-one monkey-based shooter where players grab big, silly weapons and attempt to blast each other to pieces in compact arenas.

For Marshall, adding online multiplayer to a game is not an experience he plans to have again any time soon, and while he feels like it was a great lesson in video game design, he kinda wishes he hadn't bothered in the first place.

"Multiplayer's a constant pain," he tells me. "Even something simple, like testing a new chunk of code to see if it's working, means setting up a couple of instances of the game. It might not sound like much, but it just slows everything right down. Building the game, getting it set up, and then recreating a bug across two instances by yourself can take forever."

"There are just so many balls to juggle at the same time, and if it crashes and burns it's instantly more problematic."

As with my other interviewees, the main problem was the twitch-based action in Gun Monkeys. Marshall ended up having to essentially predict where objects were going to be and funneling that data through to each player, rather than using information on exactly where objects were.

"If you're got a huge amount of money it's possibly something you can circumnavigate," Marshall reasons, "but by-and-large I think the best way to get around all these issues is to just focus on single player."

But it's not just the twitch-based issues that make online implement difficult, says the dev, as he notes that even the best-selling online multiplayer games are going to struggle to have loads of players online, looking for online games, all at the same time.

"Gun Monkeys was designed with the intention of avoiding the playerbase problem," he says. "It wasn't supposed to be a game where you logged on looking for a stranger to play."

"The trouble is, that's not the mindset people have," he continues. "People ignored the messages, and just got angry when they couldn't instantly find a game with someone at 3 a.m. That's the issue indie devs need to take away and think about - the mindset of gamers seems to be largely one of expecting everything to come to you, not to go to any effort organizing things yourself. I designed Gun Monkeys around that principle, and sadly it still didn't really work."


Article Start Previous Page 2 of 5 Next

Related Jobs

Firaxis Games
Firaxis Games — Sparks, Baltimore, Maryland, United States
[07.30.14]

Senior Visual Effects Artist
Nordeus
Nordeus — Belgrade, Serbia
[07.30.14]

Senior Game Designer
2K
2K — Novato, California, United States
[07.29.14]

Level Architect
Respawn Entertainment
Respawn Entertainment — San Fernando Valley, California, United States
[07.29.14]

Senior Systems Designer






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: