[Continuing our "Road to the IGF" series with IGF 2012 finalists, Gamasutra speaks with Spry Fox and Wild Shadow Studios about Technical Excellence nominee Realm of the Mad God.] Realm of the Mad God currently sits as the second-highest rated multiplayer game on Kongregate, with almost 2 million plays since it was published mere months ago on October 31, 2011. Where most games revel in heaps of (often forced) customization, players need only click on the mouse once to start playing Realm. With permadeath game rules, the entry and re-entry to play need to be swift for players. To keep players engaged, the browser game's loading needs to be equally swift. The developers deployed a mix of small sprites and simple vectors to keep the game size small, all the while boasting a 4+ million tile map that has no loading time. Spry Fox's David Edery joins Carobus here, speaking on the creation of Realm of the Mad God (RotMG). The two discuss how the game's engine has changed since it began as a small project two years ago, how browsers have benefited and constrained their development, and why there is "no substitute for actual players when designing and building a system." Could you tell me about the teams and their backgrounds? David: Steambirds, Panda Poet and Triple Town are our other most notable titles. Alex: Wild Shadow Studios created some prototypes before RotMG but has not formally released any other games. All of us are ex-Google employees with graduate degrees in Computer Science. None of us have worked at a game company, although Amit wrote the BBS door game Solar Realms Elite. What roles did you both play in the creation of RotMG? David: Wild Shadow started the project and has managed every aspect of it. Spry Fox's involvement is limited to game design, art/UI and business related matters. Alex: RotMG was originally created by Wild Shadow Studios for the second stage of the Assemblee Competition at TIGSource. This competition involved creating a game using only art assets supplied by the first stage. This was a perfect competition for Wild Shadow because, at the time, our studio consisted of two engineers (Rob Shillingsburg and me) with occasional help from another engineer friend (Amit Patel). The game did well in the competition and, more importantly, garnered a small but very loyal following who were asking us to continue to work on the game after the competition. We decided to put our other projects on hold and continue to develop RotMG. We met Daniel Cook and David Edery (Spry Fox) at GDC at a few months later. They saw potential in the game and had a number of skills our team lacked. So we decided to work together to improve the game and make it a success. How long have you actually worked on the game and is that work on-going? David: Wild Shadow began working on the game two years ago. Spry Fox joined in about six months afterwards. And yes, the work is very much ongoing. We make major updates on a regular basis; the latest update added an entirely new dungeon, a guild system, and more. How has creating a browser based game benefited and constrained your programming of RotMG? Alex: Well, creating a browser game does impose a lot of constraints. In some cases, we pushed against those constraints. For example, we did everything we could to squeeze every last bit of rendering performance out of Flash that we could manage. We used trial and error to find which data structures gave the best performance for which operations (something that is mostly predictable in, for example, C++ but is very unpredictable in AS3). We created free lists and removed dynamic allocations to lessen the impact of the garbage collector. We cached everything and anything we could get away with. But in most cases, we worked around the constraints. We used almost exclusively 8x8 and 16x16 pixel sprites and simple vectors to keep the game size small and fast to download and used image processing during the game to give them outlines and shading. We stream world geography as the player moves around the world, which allows us to have a 4+ million tile map and no loading time. We rely on our servers to do anything that doesn't absolutely need to be done in the client. How did you come up with the game's concept? Alex: RotMG was really born out of a love of roguelikes, arcade games and a deep disappointment with MMOs. I have always loved the promise of MMOs but have generally found most of them tedious to play. I wanted to make an MMO that was as fun to play as an old arcade game, as re-playable as NetHack or Spelunky, and didn't rely on grinding for ever decreasing rewards to keep players interested. I think a lot of people assume that MMOs play the way they do because of the constraints of the technology. This just isn't true. MMOs can have fast-paced interactive action. It is just harder to implement than a system where you watch your character fight while you hit number keys for special abilities. Tell us about the technical DNA that make up Realm of the Mad God. What did you create from scratch and what was "store bought"? Alex: The client and server were pretty much written from the ground up in Actionscript and C++, respectively. We use Amazon EC2 to run our servers and Google App Engine as our backend storage. If you were to map the technical DNA of RotMG, it would probably lead back to Google. The game has existed for almost two years as a browser title. What was the original game engine and code like and how have they evolved over the past two years? Alex: The original game code was written for a contest with every intention to throw it away after a month. The goal was to get as much of the vision of the game implemented as quickly as possible before the contest finished. So we took every shortcut and grafted in parts of previous prototypes to achieve this. As you can probably imagine, the code was quite messy. After we decided to switch Wild Shadow's focus to RotMG, we spent the next two years building on, re-designing, improving and replacing the code, all while the game was continuously running and being played by a growing player base. The vision for the game never changed, but we had the time to refine and expand on it. We also had instant feedback (constructive and otherwise) on changes and we could [fix] bugs/hacks as the players discovered them. In general, our players have been awesome, and without their encouragement and feedback, the game would not exist. What technical lessons have you learned while working on this title? Alex: We've learned a thousand lessons but one that stands out is that there is no substitute for actual players when designing and building a system. MMOs are very complex systems and the things that you expect to become a problem and the things actually do become problems are very different. Have you worked on any other browser game code? What errors/pitfalls in other developers' creations have you seen and how would you suggest avoiding those? Alex: We learned a lot from the prototypes we made before RotMG, but I've never really read anyone else's game code. I guess the main pitfall I would suggest avoiding is copying someone else's game (internals or externals) or assuming they know better than you what is the "right" way to do something. Figure it out yourself. What development tools do you think are needed to improve browser games in the future? Alex: Although Flash isn't as bad as its reputation, it isn't good either. It needs to be improved or replaced. What tools do you feel are needed to advance innovation in gaming in general in the next 3 years? Alex: I don't think you can blame our tools for the lack of innovation. I think that innovation just isn't a goal for a lot of game companies. Maybe if photo-realistic graphics became cheap and easy companies would stop competing on better looking mud and focus on better gameplay. That might spark some innovation.