Boo
Boo was a project created during my senior year at WPI. Having completed my research-heavy senior project Prince of Pride, I wanted the chance to make a game that was fluid, pretty and elegant rather than experimental or innovative. The result was Boo, a game featuring a ghost waking up in a laboratory and trying to escape in 3D platformer fashion.
Postmortem
What went well:
1. Tutorial system. I came up with the idea of using chalkboards to teach the player how to look around, move, use powers, and evade obstacles. In keeping all tutorials as 2D art without them feeling out of place in the world, we were able to subtly break the 4th wall just enough to help the player. Also, because they were monochrome 2D images, anybody on the team could create them, not just our artists or scripters.
2. Graphics. By tapping into the specular, diffuse and normal maps of our character, we were able to create a shader effect for our invisibility power. When it came time for all the demos, we had the prettiest one.
3. Level design. Because this project was part of a class, the artists progressed from 2D textures to 3D levels, objects and finally animated characters. The problem with this pipeline was that game mechanics weren't polished when the levels were created, they weren't even built at all! Because of this, the team knew early on we'd need to re-do our levels if we were going to be successful. Figuring out when and how to build our game mechanics so that they could be tweaked by our artists was key to us having complete levels.
4. No crunch. Unlike every single other team, we decided early on that we were NOT going to crunch. By keeping track of our progress, being willing to kill our babies, and almost daily communication, the team was able to set the final bar for what would make a complete game low enough that we were able to sleep during finals week. Maybe we could have done some more polish in the additional 20 hours we scraped off, but I believe we would have been too burned out to make quality work.
What went wrong:
1. Team consistency. Our team was composed of members of varying skill levels. Our programmers were divided in their skill levels, and our artists were a year of coursework and projects apart. Failing to recognize that this would create a discrepancy in our work early on set us back when we put the different pieces side-by-side.
2. Presentations. We had weekly presentations of our work, and because we frontloaded so much of it, the last two presentations seemed like more of the same with minor tweaks. It would have been better had we been more 'episodic' release of content.
3. Engine choice. Initially we were told that we needed to use the C4 engine for our game. Somehow everyone else was able to convince the professor that they needed to use Unity for their game. While C4 gave us much better graphics, it also slowed us down a lot when it came to rapidly prototyping a game design. The team's familiarity with C4 from a year before wasn't as useful as we hoped it would be, and we spent a lot of time learning the system again.
1. Tutorial system. I came up with the idea of using chalkboards to teach the player how to look around, move, use powers, and evade obstacles. In keeping all tutorials as 2D art without them feeling out of place in the world, we were able to subtly break the 4th wall just enough to help the player. Also, because they were monochrome 2D images, anybody on the team could create them, not just our artists or scripters.
2. Graphics. By tapping into the specular, diffuse and normal maps of our character, we were able to create a shader effect for our invisibility power. When it came time for all the demos, we had the prettiest one.
3. Level design. Because this project was part of a class, the artists progressed from 2D textures to 3D levels, objects and finally animated characters. The problem with this pipeline was that game mechanics weren't polished when the levels were created, they weren't even built at all! Because of this, the team knew early on we'd need to re-do our levels if we were going to be successful. Figuring out when and how to build our game mechanics so that they could be tweaked by our artists was key to us having complete levels.
4. No crunch. Unlike every single other team, we decided early on that we were NOT going to crunch. By keeping track of our progress, being willing to kill our babies, and almost daily communication, the team was able to set the final bar for what would make a complete game low enough that we were able to sleep during finals week. Maybe we could have done some more polish in the additional 20 hours we scraped off, but I believe we would have been too burned out to make quality work.
What went wrong:
1. Team consistency. Our team was composed of members of varying skill levels. Our programmers were divided in their skill levels, and our artists were a year of coursework and projects apart. Failing to recognize that this would create a discrepancy in our work early on set us back when we put the different pieces side-by-side.
2. Presentations. We had weekly presentations of our work, and because we frontloaded so much of it, the last two presentations seemed like more of the same with minor tweaks. It would have been better had we been more 'episodic' release of content.
3. Engine choice. Initially we were told that we needed to use the C4 engine for our game. Somehow everyone else was able to convince the professor that they needed to use Unity for their game. While C4 gave us much better graphics, it also slowed us down a lot when it came to rapidly prototyping a game design. The team's familiarity with C4 from a year before wasn't as useful as we hoped it would be, and we spent a lot of time learning the system again.