Student Postmortem: DigiPen Institute of Technology-Produced Psychosteamion

Introduction

Students in their second year of the Real Time Interactive Simulation (RTIS) program at DigiPen Institute of Technology are required to design and implement a 2D scrolling game engine over the course of two semesters. Fortunately, this project is not left to each individual to complete by themselves – teams are formed among students, usually consisting of four or fewer members but never more than five. Each member of the team wears a particular ‘hat’ for the life of the project and assumes all responsibilities for their respective position. The roles include Producer, Designer, Technical Director, Product Manager, and occasionally a Tester, if there are five people on the team.

For my Sophomore year, I was fortunate enough to work as the Designer with four other very talented, hard-working individuals on Team Infinite Sound. The roles were assigned as follows:

Joseph Tkach – Producer
Zach Aikman – Designer
Paul Marden – Technical Director
Steve Bjore – Product Manager
Andy Plummer – Tester

Since the middle of our first year at DigiPen, we had been tossing around various ideas for a second year project. We all belong to that strange group of individuals who believe that the 16-bit era was the “Golden Age” of the video game industry. Consequently, we wanted to capture that timeless feeling of playing an old Super Nintendo game as best we could. The graphics, controls and gameplay were all designed with this concept in mind. In the end, we opted to create an action/adventure game, similar in style to The Legend of Zelda: A Link to the Past. The trick for us was to keep our game as original as possible while still capturing all of the essential elements that made the Zelda games so much fun to play.

In the end, the high concept for our game ended up looking something like this:
A 2D, top-down action/adventure game set in a steampunk/magic hybrid world, with an emphasis on puzzle-solving and dungeon-crawling elements.

The basic premise of our core gameplay revolved around the idea that as the player progressed through various rooms in each dungeon, he/she would find a new item to help them solve puzzles that showed up later in the dungeon, or in another dungeon altogether. These items included a sword, a gun, a magnet, rockets, boots and a lightning spell. The puzzle widgets included objects such as a spring, generator, conveyor belt, stone blocks, oscillating targets and several other various items.
Each widget would respond differently to items the player obtained. For example, the generator would turn on or off whenever it was targeted by the lightning spell. By combining these puzzle widgets, we could construct elaborate puzzles out of relatively simple pieces.

What Went Wrong

Overly ambitious game design. Like many Sophomores at DigiPen are prone to do, we took it upon ourselves to make the fanciest, most elaborate fantasy world we could conjure within the eight months we had to finish this project. It didn’t take long at all to realize how wrong we were. Once we determined what we were actually capable of producing in that timeframe, we ended up scaling back on the number of dungeons and the amount of puzzle widgets the player could interact with. The original game design document called for two separate ‘worlds’, one built upon magic and the other built upon steam-powered technology. Each world would contain eight dungeons that the player would have to traverse. This ended up being far, far too complicated for us to finish during the eight months we were given.

After talking with some of the instructors at DigiPen and some of our fellow students, it was proposed that we cut down the total number of dungeons to six, with only one overworld containing them all. The design was further simplified to two slightly larger dungeons with no overworld whatsoever. Needless to say, this cut out a huge amount of content. Dungeons being removed meant that items obtained in those dungeons had to be cut, which affected which puzzles we could implement in other dungeons. It was more than slightly humbling to watch our fantastic vision of an elaborate fantasy world reduced to a measly two dungeons.

Time constraints. One would think that the true challenge in a project like this would come from content creation, balancing issues or even just writing the code itself. While each of those tasks was difficult in its own right, the hardest part of Psychosteamion was finding time to work on it between classes. Three of the five members of our team were taking twenty credits for the fall semester and twenty-two credits for the spring semester. Much of the time that was to be spent working on the game got shoved towards the end of each week in order to accommodate our other class projects. We would sometimes find ourselves frantically coding over the weekend so that we were caught up to the past week’s milestone.

No one wants to find themselves in crunch mode the night before a major milestone is due, but in certain conditions it is inevitable. Fortunately, we managed to avoid situations such as that most of the time, but there was the occasional slip that threw us a couple days off schedule.

Miscommunication between team members. Despite having a well-managed team, there were still a couple of occurrences where our communication fell apart. Specifically, for a short period of time there were some discrepancies as to how collision detection and resolution would be managed. Which entities would check for collisions, and which would ignore it altogether? Once it was detected, which entity would handle the collision? Would it be both? What about multiple collisions per frame? Would those need to be handled as well?

As it turned out, three different people on the team had three different impressions as to how collisions should be managed. It is obvious now that the specifics of such mechanisms should be hammered out beforehand and recorded in some sort of document accessible by everyone. Unfortunately, we never outlined those finer details in any of the design documents, so the implementation was based on what we had discussed, not what we had written down, leaving it open to interpretation.

This ties in closely with the next ‘What Went Wrong’ point:

Lack of detailed planning. At the beginning of the fall semester, we tried to frontload all of our core engine work so that we would have a solid game engine within a few weeks after starting. While we managed to have the essential components in place a few weeks after starting – the graphics, input and sound engines – there was still quite a bit of work left that we had not accounted for. Consequently, we did a bit of scrambling in the middle of the first semester to get ourselves caught up to where were supposed to be. We were never so far off schedule that it was a major issue, but we were never quite on schedule either.

Everyone on the team had the same idea of what we were going for, and that was part of the problem. If everybody knows what to aim for, why do you need to lay it out in the first place? Even if everyone has the same goal in mind, the steps that need to be taken to arrive there still have to be outlined so that everyone has something to follow. This problem could have been solved with a little more planning beforehand and a more detailed breakdown of what we needed to have from everybody before we could continue on to the next milestone.

What Went Right

Team solidarity. The running joke at DigiPen is that you eat, sleep and breathe your gamedev team. Everyone laughs about it when someone brings it up, but the sad fact is that it’s true. Most of us had the same class schedule so we’d see each other every day during and outside classes. It has become more and more apparent over the past two years that maintaining good relationships with your teammates is critical to your success as a developer.

Fortunately for our team, we all get along quite well and there was seldom an occasion where there would be a full-blown disagreement between any two members. As the year progressed, it felt less and less like I was working on a team and more and more like I was working with good friends, which certainly helped our productivity and kept the creative juices flowing until the very end of the project.

Egalitarian work atmosphere. Partly because of the team solidarity we experienced, we found it much easier to give everybody equal say in how most of the game was developed. Even though I acted as the designer, everybody had input as to how the game would play and decisions regarding the game design document were not finalized until everyone approved of them. This is one of the many benefits of working in a small team – this type of system tends to fall apart in larger development teams.

Personally, I feel that the equality everyone was assigned was one of the major contributing factors to that feeling of unity. People like feeling that their opinions matter and it is much easier to get excited about a project when your suggestions and ideas are going to be tangible in the final product.

Robust tools. One of the team members, Joseph Tkach, ended up doing very little work on the game itself. Instead, he devoted most of his time to building us a very powerful map editor in C#. The tool was in development for most of the project, but towards the last month or so it was finally in a state where the rest of the team could tinker with it and throw together some puzzles. We had everybody open up the editor and throw together a few rooms just for fun and we ended up with some very interesting and (believe it or not) fun puzzles that were thrown into the game at the last minute. Attempting to build all of the content we needed without the map editor Joe designed for us would have been, at best, an absolute nightmare.

Simplified game design. Starting off with an overly ambitious game design is probably what hurt us the most coming out of the gate. We were fortunate enough to catch our mistake early in the development process so that relatively little time was wasted designing the dungeons and widgets that we would never use. Reducing the number of dungeons to just two allowed us to focus more on the quality of our code and the gameplay dynamics, rather than trying to cram in as many rooms and puzzles as we could.

One lesson that I learned after completing Psychosteamion is that simplicity is often the best design philosophy. The simpler your game is, the more accessible it is to people outside your target audience. Tetris, Bejeweled, Pong, checkers and crossword puzzles are just a few of the games that have captivated millions of people around the world, yet the rules governing these games are ridiculously simple and can be learned in a matter of seconds. I cannot say if Psychosteamion managed to capture that elusive quality we like to call ‘fun’, but I know that reducing the amount of content and trying to work within the bounds of just a few puzzle widgets certainly forced our team to be more creative.

Attention to detail. We decided to take a week or so from the development cycle to add polish and fix up some bugs in our game. The tiny details we added to the game during the last few weeks really gave it a nice touch. Shadows under entities when they are flying through the air, lightning crackling on the generators when they were turned on, light beams coming in through the windows and a simulated fog effect were just a few of the last minute touchups that we tacked on to give the game a little added pizzaz.

During that last week of development, we also added sounds to the game. Everyone was surprised at how much more immersive the game was when there were sounds to accompany the player’s actions. The lightning spell crackled when it was cast, hitting an enemy was accompanied by a very gratifying ‘thunk’ sound and rockets made a cool ‘whooshing’ noise when fired. Once the sound effects had been obtained, it took about five minutes to drop them into the game – a very worthy investment considering how much polish it added to our final product.

Conclusion

I find it hard to look back on anything I have created and not notice all of the glaring problems. Psychosteamion is no exception, and whenever I play through it I can’t help but see all the things I wish we had more time to fix. Even so, I am quite happy with the way our game turned out, considering the time constraints and our lack of previous experience making a 2D action/adventure game.

More than anything else, I think I walked away from the project with a better idea of how to plan ahead. We experienced, through trial and error, a lot of the pitfalls that inexperienced game developers fall into. Fortunately, we learned these lessons at a time when it is not going to cost us our jobs.

Game Data

Title: Psychosteamion
Developer: Team Infinite Sound
Publisher: DigiPen (USA) Corp
Number of full-time developers: 5
Length of development: 8 months
Release date: April 28th, 2006
Target platform: PC
Development hardware: 2-3GHZ PCs running WindowsXP, 2GB of RAM.
Development software: Microsoft Visual Studio .NET 2003, Photoshop, Audacity, TortoiseSVN
Notable technologies: Support for console controllers/gamepads and force feedback
Size of source tree and assets: 98.4MB
Size of final deliverable: 3.25MB

_____________________________________________________