Our student project, Subsonic, was due for the First Playable Milestone Friday night. The last week has been pretty grueling, but the team pulled through and we had a fantastic game. Subsonic received an excellent score during our game presentation (these scores are not official, but should be pretty close to our actual grades) from both the course instructors and students. Looking back, there are plenty of things we as a team did right and more than a few things we did not so right.
To help put things in perspective, let me go over what Subsonic is. Subsonic is a two-dimensional action/puzzler with a 60’s spy-tech theme. Your goal as a player is navigate a series of enemy bases, avoiding guards and security cameras, in order to sneak into restricted areas and steal enemy intelligence or sabotage equipment. To aid in your missions, you have been equipped with the Subsonic Incorporated Sound Vision Goggles, which allow you to see sound. What that means in practice is that every noise has visible soundwaves flowing across the tactical display, allowing you to use and manipulate sound waves to distract guards or interact with the environment. You are also equipped with the Subsonic Incorporated Sound Gun, which can fire bursts of concentrated directional sound, either at a loud-but-harmless volume or as a powerful and dangerous shockwave.
Our First Playable has all of the core gameplay elements intact. The player can play through a series of levels, see sound waves, fire the sound gun, and attempt to trick and outsmart guards. We have an in-game tutorial, a basic in-game level editor, win and lose conditions, basic options menus, and a small set of fun levels. The goal of a First Playable is to have a product that – if the team was forced to ship right then – could actually make for a fun game. We succeeded quite well.
There are four things that went very well for our team and which contributed directly to our successful First Playable. These are things that all teams – student or otherwise – should aim for.
First, we had a very clear idea of where we wanted to the game to go and how we wanted it to play. Many of the specific details have changed since the initial concept, of course, but the core game is exactly what we envisioned it to be. Unlike many of the other student teams, we therefor wasted little to no time investing in unnecessary technology, nor did we waste much time experimenting with dead-end game mechanics. This fact was by far the most important part of our success. With only four months of development time, avoiding waste is absolutely critical.
Second, we had a strong focus on polish. Many student game teams have the idea that polish is only for the Alpha release and later. This idea is a disease that can easily kill any project. At every possible stage of development, polish should be a priority for any features and mechanics that are implemented. The primary reason that polish is important so early is that it actually helps development and testing. Testing an incomplete or buggy game mechanic to see if it’s fun or not is very difficult compared to testing out a game mechanic that has been refined and honed as much as possible. In the end, the mechanic is likely going to need further changes and refinements, but determining what those are is simply way easier when testers aren’t getting hung up on a poor implementation of an idea. The second reason polish is so important – for students especially but for commercial developers even more so – is that a project is graded on what it is, not what it will be. If an instructor, or a real publisher, is looking at your First Playable, and its obviously unpolished and hacky, they are far less likely to be impressed. In the corporate world, that can actually mean that your project does not receive funding or gets canned.
Our third success was in technology. I will admit that there are many aspects of the code in Subsonic that are not up to my standards. Overall, however, Subsonic’s technology has allowed us to develop at a rapid pace and with a minimum of bugs. Crashes are relatively rare. A large part for that is that a crash – or any bug, for that matter – has been treated as Priority Number One until fixed. For an example, when I was first made aware that our game logic developer was having occasional crashes with the ActionList infrastructure, I immediately put in a few hours to review and revise not only the implementation for it but also revised the API and expanded the documentation on which methods were safe to call and when they were not. The crashes in that section of the code were rare to begin with, but they literally disappeared entirely afterwards. A second large reason that our stability is so high is due to pro-active practices. Where possible, any APIs and frameworks put into the engine were designed with ease of use by other developers first and foremost. Especially in the game industry, performance concerns often seem to trump good development practices. For Subsonic, we gladly took performance hits if it meant making the code more stable and easier to use. After all, a frame rate over 60 is essentially pointless (most LCDs can’t even display anything higher than that) and the extra 2% performance boost from using an unsafe API has no impact on the game at all, but having a game that doesn’t crash and doesn’t frustrate the player (or embarrass the team in front of instructors or publishers) is pretty important.
The fourth and final success we had was in utilizing as much outside help as we needed. For example, we had a number of gameplay ideas that we thought would be pretty cool (and most of us still do), but when other experienced game designers gave us the advice to drop those features, we do so. Likewise, we have changed parts of the design several times due to external suggestions and feedback. This can actually be really hard, and it’s something I’ve seen more than a few of the other game teams this semester fail at. It tends to be hard – especially for many developers – to accept that one’s own idea is inferior to someone else’s. I myself have run into that more than a few times this semester. One of the lessons our instructors have taught us is that a game is only as good as its worst feature. If a game has 5 great elements and one okay element, the game as a whole is only okay. Our team had a lot of good ideas, but in the grand scheme of things, only a small handful of those were really fantastic ideas. In the end, those are the ideas that went into the actual Subsonic First Playable, while the others were left out. The result is that our game is full of fantastic ideas and, as a result, is all around fantastic – especially for a single semester’s worth of work by two Sophomores and two Freshmen.
Things did not go perfectly all around the board, however. We did have a few setbacks, and our First Playable game could have been even better had we been prepared to identify and overcome those obstacles earlier in the semester. Many of these mistakes are common student hangups that were unsurprising, at least to more experienced developers. I am not too concerned about many of these, as encountering them and learning from them is why we’re in school and are a team of students and not a team of professionals.
Our team’s biggest hangup by far was a slow start in development. Most of our team suffered from what I’m calling “student development anxiety.” There is a common fear by many good programmers that their code must be really good code from the very first line they write to the very last. This anxiety in turn leads to a lot of time invested in thinking about how to solve a problem or how to architect a solution rather than just getting things done. Note that I said that this is a problem for good programmers; most bad programmers don’t have this issue, because code quality isn’t something they concern themselves with. Of course, really great programmers don’t have this problem either because they have already learned that action speaks louder than words and that code accomplishes more than endless revisions to design documents.
The result of this initial glacial pace is that our last few weeks have been very, very hectic. I’m very pleased with our much our team accomplished in such a short period. It’s really quite amazing. However, we could have been where we are now back at our Engine Proof demonstration. We should have been there at Engine Proof. We inadvertently made the same mistake that many other student teams made intentionally, in that our Engine Proof was really only a partial engine proof; we had no AI, no sound, no level transitions. Subsonic was nothing more than an icon moving around a simple tile map with a couple of enemies that did nothing interesting. That’s not an Engine Proof, because we in no way managed to illustrate that we could pull off all the necessary technology for our game. Subsonic did not gain some of the core featured necessary to make the game possible to play at all until the weeks just before First Playable. While we managed to pull it off, we should not have left ourselves in the position where we had to work overtime just to get a proper First Playable out the door. Many other teams seemed to be perfectly content being at a similar point of development as we were, which is a mistake. Taking your time to do things right when you don’t know what “right” is will not achieve anything other than wasting time.
This initial hesitancy in development was not a complete disaster because of our team’s excellence in defining our game’s goals and sticking to them (which I listed as our first team strength for a good reason). Together, these two facts pretty much canceled each other out. In the future, I think the team has learned the importance of coding first and then revising the code – if that’s even necessary! – once the basic mechanics are up and running. That combined with a clear goal would have allowed us to be far ahead of the curve by now, and hopefully that knowledge will allow our Alpha and Final releases next semester to be absolutely fantastic in every way.
For those interested, the Subsonic First Playable should be available for download in the near future.</div>