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
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
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.
4 player local cooperative play
Psuedo-Random dungeon layout
Unique user identities
Hot swappable character class
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.
Fig. 3. Screen Layout Diagram of Pixel Dungeon.
What Went Right
- 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).
- 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.
- 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.
- 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
- 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.
- 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).
- 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?
- 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.
Fig. 4. Concept art of Pixel Dungeon.
Fig. 5. Screenshot of Pixel Dungeon.