Loopycube is all about creating multiplayer games for your iPhone. We knew when we started that multiplayer games are somewhat more complex than single player games but I don’t believe we realized exactly how big “somewhat” was!
The biggest difference is having the game connect to several different devices and share the same information with each device at the same time. Well, in Go Native!’s case, pseudo same time. Every generation device has different speeds; often my poor little 3G needs to play catch up to everyone else’s 3GS, 4G and iPad. With a multiplayer game, the slight differences of speeds add up over time, so much that after a round or 2 of Go Native! my 3G would be so far behind that Princess Mango would have to be renamed to Queen Mango and my coconuts would all be rotten. So what did we do to solve this?
What we ended up with is a checkpoint system. In Go Native! we set up the server so that a few times each round it asks everyone in the game ‘Are you ready for the next part?’ then waits for a reply. Once everyone’s device has replied ‘My player wants more coconuts, please proceed’ then the server sends the go ahead to continue with the next part of the round.
But this solution introduces more problems. What about the faster devices? What do they see? Do their players think the game has stalled for the potentially few seconds that the other devices need to catch up? We needed to perform these checkpoints while something else was going on to distract their user from the simple fact that we’re making them wait for the tortoises in the group. This is where having a great artist creating some crazy animations come in handy. We couldn’t give the faster players something to read or something related to the game play if we wanted the game to be fair to all players, because my slower device would prevent me from keeping up with the rest.
After figuring out how to keep everyone at the same state in the game, other issues arose. We played around with a few ideas regarding logging into the game and saving your username. “What do we require a player to do to log into Go Native!” we asked each other. The initial thought was just “Sign in with a user name or password”. That’s fine, but what happens if a player forgets either of them. So we added an email field.
Great right? Well hang on. Do we require the email field to be filled in or is it optional? If it’s required then how can we be sure that the email address provided is real and not just email@example.com; or how about if some player (either on purpose or otherwise) If it’s not, then how do we get passwords to those who didn’t supply their email address. Our decision was to make our players provide an email, fake or real, and afterwards we will provide them an added incentive to confirm that email address by clicking on a link. That way the player will be happy (Woot! Achievement!) and we won’t be getting as many service emails for lost passwords.
There are plenty of other decisions that need to be made for a multiplayer game that you don’t need to consider for single player games. I could write many pages that would probably put you to sleep, but the end of story is thus: Even with the extra work, a multiplayer game is more entertaining, more dynamic and all-in-all a more rewarding experience for the developers.
Look for Go Native! on the App Store in September to see the solutions we’ve come up with for our multiplayer game. I assure you it will be some of the most casual multiplayer fun you can have on the iPhone, iPod and iPad!