Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Maxims for Multiplayer Games

Yetizen ( was a gaming incubator that existed in San Francisco, roughly between 2011 and 2015. I thought it was an interesting experiment, and was happy to give a series of talks there, and advise the portfolio companies.

This talk, from 2012, is an intro to "How to think about Vendor Management" -- most gaming startups rely on dozens of vendors, but don't really know what's involved. At the end of the day, if your game relies on a third-party service, it's important to ask the right questions, and it's very important to have a contract in place that has specific representations and specific liabilities in the case of breach.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Login to see the comments

  • Be the first to like this

Maxims for Multiplayer Games

  1. 1. Maxims for Multiplayer Games Bill Grosso (
  2. 2. So … You’re Building a Cloud-Based Multiplayer Game
  3. 3. Let’s talk about …. People who play games
  4. 4. People Like to Be Social • If you build chat, people will use it • If you build voice communications, people will use it • If you build places for people to hangout together, they will use them • Not entirely a positive thing – Done well, game is stickier – Done badly, you look bad – Easy for people to get sidetracked – High visibility
  5. 5. People Like to Be Offensive
  6. 6. People Remember Bad Things More Than Good Things • “You land a million planes safely, then you have one little mid-air and you never hear the end of it ...”
  7. 7. Good Service Matters • Even if the question is stupid, be polite • Even if it’s not your fault, be polite • Even if you’ve been having a bad day, be polite
  8. 8. Giving People Free Stuff Makes them Happier • One of the first things people do is move their wallet and entitlement management to the cloud – Lots of reasons for doing this • When a pissed off customer calls or writes? Give them some a big bag of currency.
  9. 9. People Lie, Especially When Its In Their Interest to Do So
  10. 10. Let’s talk about …. Vendors who give you cloud- based APIs to deliver services.
  11. 11. Actively Use Vendors • Life is short • Time to market matters • You’re building a game; focus on the gameplay • Vendors are the way you share development costs with your competitors – For the stuff you don’t want to compete on
  12. 12. Vendors Lie • Vendors are (mostly) reliable. • But they don't have your best interests in mind – And the guy on the phone will (sometimes subtly) misinform you
  13. 13. Keep Vendors Out of the Game Loop • Local caches • Messages in background threads • If the service fails, the game shouldn’t – And it shouldn’t slow down
  14. 14. The Mythical 4 Hour Integration • Vendors rarely tell the truth about time to integrate • “It takes 4 to 8 hours” means – It will take at least 8 hours – It will only take 8 hours if • You’ve already read all the documentation • You understand the underlying conceptual model completely • You’ve integrated to the service, or a service like it, before • Your code is already architected in such a way that the places to hook in the integration are already built • Your data model is completely compatible with their data model • You only want have the “easy half” of the benefits • You’ve had a red bull or two already • Bottom line: if they don’t have a demo game, and the competition does, use the competition • Backdoor customer references are good
  15. 15. Failure is Hard to Define • What does “down” mean for a web service? • What if …. – What if you iframe them in and that works but displays a “fail whale” – 5% of calls fail with a 400 error, but succeed on the retry – Calls were taking 100 milliseconds yesterday but are taking 500 milliseconds today
  16. 16. The Concept of Nested Failure
  17. 17. Read the SLA • Most SLA’s don’t define “up” or “down” • Most SLA’s don’t have a third- party validation process for downtime – “You’re down” – “No we’re not” • Most SLAs have carveouts for maintenance windows • Most SLA’s don’t define remedies for downtime – Common practice is to either not mention it or to offer a time- based refund – Is refunding for the two hours the service was down really enough of a remedy? Really?
  18. 18. Let’s talk about …. The performance of your cloud-based systems
  19. 19. You Are Your Own Worst Vendor • Seriously • Everything I said about vendors applies to you
  20. 20. The Internet is Always in a State of Partial Failure
  21. 21. The Mobile Internet is Always Slow and in a State of Partial Failure + + =
  22. 22. Server Performance Isn’t What Matters • What matters is the total roundtrip from the game client to the cloud and back • If it costs 200 milliseconds to do a roundtrip from the phone, 10 extra milliseconds in the server farm doesn’t matter – What matters is making the call in the background – Or doing predictive fetching – Or performing the operation locally and then storing the results in the server
  23. 23. Data is Easy, the Right Questions Are Hard • “Data Driven” is the wrong idea – “Curious” is the right idea • The process is – Good Question! – What would an answer to the question look like – What data, if we had it, would give us the answer on a silver platter? – How do we get that data?
  24. 24. Sometimes, Things Click • “Wow, that advertising campaign really worked and we tripled our user base” • “Really? How’d the servers handle it?” • “They melted down. But … the advertising really worked!”
  25. 25. Let’s talk about …. Legal Stuff
  26. 26. The Legal System is Getting More Behinder With Each Minute • Lawsuits are expensive • Terms are ill-defined • Most legislation is from decades or centuries ago • Impact of existing statues is unclear • Controlling legal authority is ambiguous • Get things in writing, clearly, and always have a backup plan