“Going Live in 3, 2, 1…”

16th September 2014 Kurt Reiner

Hello and welcome to the Demiurge Engineering Blog!

Two years ago we started working on a game called Marvel Puzzle Quest. It’s a free-to-play slugfest plus match-3 puzzle game set in the Marvel Comics universe. There’s a lot of design brilliance that drives the gameplay progression, the character ability systems, and the overall economy. The super cool Marvel characters provide a phenomenal launch pad.

But there are also super cool engineering efforts which bring all of that to life. Over 4 million players from around the world have engaged with the game on iOS, Android and PC. There’s a client-side engine that’s been evolving for years via Shoot Many Robots and other Demiurge projects**.  There’s a server-side environment too. MPQ has servers...a lot of servers. And we’ve got a stack and databases and a deployment infrasture and unit tests and QA processes and on and on.

After talking with other Boston area developers we realized that we were pulling off a development effort which isn’t trivial and is riddled with pitfalls. We’ve mashed up traditional client-side app development, web service infrastructure, lean processes, agile processes, server mediated gameplay, free-to-play game mechanics, daily content updates, multi-platform support, multi-OS support, PvP gameplay, PvE gameplay, matchmaking, leaderboards, and live events...all for a globally-distributed playerbase.

There have been near misses.

There have been direct hits.

There have been feats of pure luck.

There have been feats of pure genius.

We’d like to open source this whole effort, share what we’ve learned, and hear your thoughts!

**

P.S. I just searched the code base for “walter” or “robot” and came up empty. Dr.JZ knows how to keep it real and abstracted at the same time!

P.P.S. I also searched for curse words in MPQ’s codebase. There are only two shits in there and no other naughty bits except for [middleware product name redacted by management]. The “curse word search” used to be a part of our standard codebase evaluation back when we did contracting work for larger studios. You can learn a lot about an engineering team’s mindset and the potential for nasty, tangled bugs from the variable names or the color of the language used in comments.

P.P.P.S. There are, however, nearly one thousand TODOs in the MPQ codebase. Which is worse? 1,000 shits or 1,000 TODOs?