Postmortem: Pixel Dungeon

Here's the postmortem of a 4-player 2D RPG-platformer intended to be published on the last year edition of Dream-Build-Play contest. Unfortunately, there's more story than that.

Here's the postmortem of an unfinished game. Sometimes, you just learn more from failures than from successes. So I decided to share my lessons on that project, even if the game didn't ended well.


Some Data About the Game

Project Name: Pixel Dungeon

Version: 0.43

Release Date: Unreleased

Platform: XBOX 360

Number of Developers: 2

Length of Development: 2 months

Lines of Code: 8168

Development Tools: Microsoft Visual C# Express, Microsoft XNA Game Studio 3.1, Photoshop


Pixel Dungeon lines of code

Fig. 1. Pixel Dungeon lines of code.


Pixel Dungeon game development story

January 2010. After some time nurturing an interesting game idea, I decided to post a collaboration request in the XNA forums. I got many answers, but I finally teamed up with a talented and experienced programmer (for the sake of anonymity, we'll call him J). 

January 2010. Some days after. We signed in for Dream-Build-Play contest (hereafter DBP), and started planning development. I was in charge of game design and pixelart. J was in charge of programming. We crafted the main game features really soon, brainstorming together most of the game ideas. Soon became obvious that I was also going to help with programming.

January 2010. The rest of the month passed really quickly. Our game was growing quickly too. We spent many nights coding together, hand to hand. We became friends.

February 2010. Some days before DBP deadline. Our game was buggy, mostly incomplete, and totally untested (see What Went Wrong 1). I gathered 4 friends for a local multiplayer playtesting session on the XBOX 360. They played and laughed for half an hour. I wrote many pages of bugs, improvements and suggestions.

February 2010. Two days before DBP deadline. J had some personal problems that forced him to leave the project. I was alone and too close to deadline to make significant changes. I decided to enter the contest at any cost. The requisites were some screenshots and a gameplay video. I quickly obtained the screenshots. But the video was a bit more difficult (see What Went Wrong 2). With so many bugs, so many unfinished features, such a poor playtesting and the lack of a gameplay video... I resigned myself not to enter DBP.

Sadly, I have no heard from J since then. 


Key Features: 
  • 4 player local cooperative play
  • Psuedo-Random dungeon layout
  • Unique user identities
  • Hot swappable character class
  • Drop-In/Drop-Out play
  • Leveling of individual characters
  • Dynamic zoom allows players to spread out 
  • 4 character classes with unique primary/secondary skills

Fig. 2. Pixel Dungeon key features extracted from the game design document.


Screen Layout Diagram of Pixel Dungeon

Fig. 3. Screen Layout Diagram of Pixel Dungeon.


What Went Right

  1. Local cooperative multiplayer + 2D platform + RPG. The main idea behind the game was making a cooperative 4 player RPG-platformer. There's much debate around local multiplayer issues, and I'm happy to say our choices were proven right in our small playtesting session. We made all players share the same screen space, with no split screen at all. That gave them a lot of screen space to play in. When players wanted to explore the dungeon in different directions, the camera zooms out to keep them all visible. The mix between platformer and RPG feels totally natural (let's not forget Zelda II explored it many years before us). 
  2. Random-generated levels. In such a tight deadline (2 months), implementing a level editor was not a viable approach. Random-generated levels offered us a quick way to go with a high replayability value. Playtesting showed that going from random dungeon to random dungeon was great the first couple of times. Then, the dungeon patterns showed themselves and make players lose their sense of exploration. 
  3. Quick and dirty code for prototyping.  I can't emphasize it enough: make your game quickly, playtest it often, and learn from it. Then, you can start the game from scratch with good software engineering techniques. We started the game prototype with a clear game design document, and my initial intention was to keep the code clean and simple as possible. It was not possible, and I'm happy the game turned out so dirty: we tested everything. 
  4. Retro-styled low-res pixelart. Working with such a retro-styled pixelart was a total success (let's not forget that I'm not pixelartist). There was no difference between concept and final art. I could draw an orc in 5 minutes and directly throw it in the game. Also, animations were really fast to develop (most animations have 1 to 3 frames). 

What Went Wrong

  1. Playtesting. In general terms, local multiplayer game development is a bit of an uncharted land. Games are typically single player, online multiplayer or MMO. We learnt a hard lesson about local multiplayer: playtesting a n local multiplayer game means playtesing with 1 to n players. In our case, playtesting a 4-player local multiplayer = playtesting the game with 1, 2, 3 and 4 players. It seems obvious, but the game feels different in each case. Also, you have to playtest the effect of different inactive players (players physically playing, but not affecting the game), like 2 players playing but 1 being inactive, 3 playing 1-2 inactive, 4 playing 1-3 inactive. Let's face it: it's a lot of cases and all are important. We solved this problem allowing players to play all the time. Player character death allowed players to continue playing in ghost mode, which can be considered an intermediate step between active and inactive playing. They can play, but they can't gather loot and experience.
  2. Recording a video for DBP. Here's another unspoken problem of local multiplayer games in XBOX 360. If you want to record gameplay in your XBOX 360, the best option is to run the PC version with a wired controller and a screen-recording program. It's great for single player games, but not so great for local multiplayer games. First, you need a bunch of controllers. Then, you need a bunch of friends to come over and play again and again. That's something you certainly need to plan in advance. After DBP, however, I managed to record some gameplay. Here's a video of some of my latest indie games (featuring a brief snapshot of Pixel Dungeon at play).
  3. Feature creep. The game was designed to be small enough to be reacheable in 2 months. However, sometimes you are so passionate about your implementation that you just let in everything your implementation can do. We added a merchant and weapon upgrades in just a few hours. However, these features were not well designed and playtesters didn't like them at all. Why do they always know exactly what was intended and what was improvised, anyways?
  4. Sound design. Last things are never well implemented. In our case, sound design was the last thing to do. And we didn't. The resulting sound was so awful I turned out the TV volume  in the playtesting session. 


Pixel Dungeon concept art

Fig. 4. Concept art of Pixel Dungeon.


Pixel Dungeon screenshot

Fig. 5. Screenshot of Pixel Dungeon.

Latest Jobs


Vancouver, BC, Canada

Bladework games

Remote (United States)
Senior Gameplay Engineer

University of Canterbury

Christchurch, Canterbury, New Zealand
Academic in Game Arts and Animation

Fred Rogers Productions

Hybrid (424 South 27th Street, Pittsburgh, PA, USA
Producer - Games & Websites
More Jobs   


Explore the
Advertise with
Follow us

Game Developer Job Board

Game Developer


Explore the

Game Developer Job Board

Browse open positions across the game industry or recruit new talent for your studio

Advertise with

Game Developer

Engage game professionals and drive sales using an array of Game Developer media solutions to meet your objectives.

Learn More
Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more