Student Postmortem: DigiPenís Toblo

By Steve Chiavelli [03.01.07]

 Introduction


Going into junior year at DigiPen Institute of Technology, our team was looking to make a game that was both light-hearted and easy to pick up and play. Knowing we wouldn’t be working with any artists, we also wanted to craft a physics-based engine and keep our art asset requirements to a minimum. With these things in mind, the team sat down one night and hashed out our master plan over some burritos.


That original meeting spawned a game design which eventually turned into Toblo. Our game consists of two teams battling each other for control of a completely destructible world made of blocks. The game places a strong emphasis on destroying your opponent’s base in order to capture all three of their flags. Players are essentially limited to two ways of interacting with the world: picking up blocks and throwing them. In order to attack other players, the blocks which make up the world must be used as weapons. This concept of the world as your ammo leads to tearing apart the level’s structures, such as walls and trees. At the end of a match, the level is left in a state of complete disarray. Several large piles of rubble mark where the two bases used to be.

 

 


 

This destructive gameplay is completely different from our original design. Toblo was originally about two teams racing to build a tower to the heavens. Players would have to meticulously place individual blocks in their tower, growing it piece by piece. They would be responsible for venturing out to attack the other team’s tower and defending their own as well. Combining all of these things turned out to be too complex for us to maintain our original goals. During our play-tests we discovered that players couldn’t figure out the game within the first couple minutes. Even worse, we could tell they weren’t having much fun.


We decided to grasp onto the one aspect of our game which we knew was enjoyable: knocking things down. Our game design underwent a complete overhaul, and our tower building game turned into destructive CTF mayhem. This move made the game easier to understand, and also allowed us to showcase our physics engine.

 


 What Went Right


Working together. One the most significant factors in our success was the dedication to work together as a team as often as possible. We chose a central location to meet every day and code on Toblo. This ensured that there were no misunderstandings or lack of communication, since we could consult any member of the team at any point in time.


Engine Design. The main game engine design incorporated in Toblo was heavily inspired by the book Game Coding Complete by Mike McShaffry. All aspects of our code base were crafted with the model/view, event-driven standard described by McShaffry. Striving towards this criterion kept our code extremely modular and ensured that we never had to go into other people’s code to accomplish our tasks.

 

 


 

Project Management Software. We used software called Trac to assist the team with bug tracking and task management. This was vital to keeping the game bug free and on schedule. Any member of the team could create a ticket and assign it to another member. This ensured that small bugs didn’t slip through the cracks and were addressed immediately.


Play-testing. Play-testing (discussed further in a past article) began as soon as it became practical. We were collecting tester data from the moment a playable version of the game was up and running. This exposed some major flaws in our game design and mechanics, and allowed us to go through several iterations before settling on a final product.


Game Design Change. As a result of our play-testing, we were able to assess that our original game design was not working out as we had hoped. Instead of trying to salvage it, we scrapped the design entirely and came up with a new one tailored to our existing technology. Luckily we acted on this early enough that we were able to get our new gameplay features implemented and sufficiently polished.

 

 


 



 What Went Wrong


People Get Sick. It seems like most of the things that went wrong during Toblo’s development have a common origin. Early on in the project a team member fell ill and was more or less unable to do a significant amount of work. He didn’t fully recover until the second semester of the project. The team adapted as best it could, but we probably should have reevaluated our project timeline and rescheduled accordingly.


Lack of Tools. We had originally planned on having level and object editor tools. Unfortunately this was a major feature that got cut due to time constraints. We ended up using Photoshop as our level editing tool. As you might imagine, creating levels this way was limited and extremely tedious. Object creation was also quite difficult without the proper tools. In Toblo, all objects in the game are made up of blocks. The creation of these entities required tweaking the size and placement of each block individually in a text file. We simply did not have enough time to create many interesting objects in this fashion. As a result, the only prominent objects in the final version of the game are trees.

 

 

Too Long to Implement Gameplay. We didn’t have a testable version of our game until just over halfway into development. Once we started our play-tests it was immediately obvious we needed to make some changes to our original design. If the gameplay had been present sooner, we could have had more time to make the necessary changes and flesh them out.


Game Design Change. Due to the complete redesign of Toblo, we had to throw away a huge amount of gameplay and AI code. This sort of thing happens all the time when features are cut, but I think that we were hit especially hard. Roughly half of the existing gameplay code was salvageable after the shift, but unfortunately almost all of the AI code had to be scrapped.


Menus Implemented Too Late. There wasn’t any sort of menu flow implemented until the last couple months of full time development. Up until that point the engine was structured only to start the game and shut everything down on exit. Once menus were introduced it was a nightmare getting everything stable enough to continue.

 

 

 

Conclusion


While there were certainly bumps in the road, I think that Toblo’s development was a resounding success. We faced some immediate setbacks when a team member became ill, and had to juggle our schedule around. As a result some features were dropped, but nobody panicked. We focused on getting the game to a playable state so that we could begin harvesting tester feedback. Once that feedback started coming in, the team managed to overcome a complete design overhaul and pump out a polished product that we all love to play.


Getting recognition for our hard work is just icing on the cake. We have won a number of awards including the audience award at the 2006 Northwest Games Festival, and the $30,000 grand prize in Intel’s game demo competition for Best Game on the Go. We have also been nominated for Design Innovation and Best Student Game at the 2007 Independent Games Festival. The best thing about these awards is that more people are finding out about Toblo and as a result are playing it. As up-and-coming game developers, that is our dream come true.


Return to the web version of this article
Copyright © UBM TechWeb