What Went Wrong
1. Submission Process to Nintendo
It's Murphy's law: for a project that had run so smoothly, our biggest problem came in the final hour, after the game was "complete" and we were awaiting approval from Nintendo. We were all ready to kick back and congratulate each other on a job well done, but our title still needed approval from Nintendo, both in Japan and in the U.S. The ensuing delays caused us to miss our ideal release date, which in the U.S. was Halloween.
While it would be easy simply to complain about how terrible big publishers are, there are things you can do to mitigate the bureaucracy. The thing to keep in mind is that at some point there are decision makers involved with approving your game. Anyone who has shipped a game, especially for Nintendo, knows that even the most minor misbehavior can hold up the process. So what to do now that your game is being sent into the hands of who knows how many random individuals? Simple: realize that there is a process.
Someone at your company will hand the game to someone at your publisher. Someone at your publisher will hand the game to your console maker for approval. That person will subsequently hand the game (and associated materials) to someone else at his company, possibly overseas. At some point the process will reverse itself with either a "yes," or a "no" and a reason. You must involve yourself in this chain so you can respond to mandated changes rapidly. Glue a cell phone to your ear, and send a copy of your contact information to as many persons in the approval process as possible. Get to know them personally if you can. Ultimately you'll find that these people would actually like to publish your game and it is equally frustrating to them to have to knock it back over a minor detail.
If you can talk to the people directly you can fix things much faster and literally save days. You will also know where your game is at any given moment. Instead of imagining it simmering inside the convoluted bowels of some demonic company, you will know that Sam said he passed it to Bob and you will be able to call Sam and please ask him to go over to Bob and request that he do something with your game. This is often overlooked in a small team that has been very internally focused for an extended period of time. Suddenly having to rely on someone else, or a great many someone elses does not come naturally. Force yourself to ride the phones and know your status at any given time -- you deserve it. It was a joyous moment for Chris when he got a call from someone at Nintendo whom he'd never met before, changed a single bit in a few moments' time, and sent the game back on its merry way in 30 minutes. He'd simply heard incorrectly through the grapevine what the actual status bit was supposed to be.
Screenshots from Resident Evil 2 for Nintendo 64.
2. Insufficient Testing
Never underestimate your testing requirements and, more importantly, never let your publisher underestimate your testing requirements. Almost obvious to anyone who has developed a game should be the testing phase, especially for projects with shorter deadlines. Make sure that the level of testing support you expect is written into the contract with your publisher.
As an aside, programmers and artists are not testers. Such a practice reduces their effectiveness when they are called upon and at the time when the utmost care must be taken to ensure their changes do not have ripple effects elsewhere in the code. Having them on call 24 hours a day is fine, but have them be on call, not sleeping on the floor.
Exact definitions of what developers expect from the publisher and what the publisher expects from the developer are crucial to ensuring expectations are met on both sides. Our testing operation suffered because we expected the publisher to test the game, while they expected us to test it. A testing plan was not mentioned in the contract or the porting plan -- an oversight by both the team and Angel Studios. In the future, we will be sure to have a testing plan explicitly stated in both the contract and the development schedule.
While we achieved a tour-de-force of compression overall, we didn't anticipate all the assets that would need to be compressed. Audio and video received most of the attention and were pushed and squeezed until they fit. Our focus on these assets, however, caused us to neglect other areas such as the animation data. We did manage to cage these beasts, too, but on our final burn we had to shave another megabyte off the video. This last megabyte took us under the critical point where the video suddenly went from very pretty to just a bit too obviously compressed. Not all the game's movies were affected, but it was disappointing that we had to sacrifice some quality because we assumed the other assets would fit, rather than adhere to the apothegm "assume nothing." Next time, we won't leave anything to afterthought. We'll examine everything, to the point where we can make informed estimates (in this case, an asset's uncompressed size and its expected compression ratio derived from some sample tests) for everything.
Lack of Follow-up by Leads
Everyone has a certain set of things that they hold dear. For some of us our work integrity is very important to us, for others it is not. As I mentioned before (and will mention again), when you show that you understand the word "milestone" you set yourself apart in the game industry. This is truer in a game where your current progress can be held up against a completed yardstick. Not everyone, and certainly not everyone on your team, will necessarily share this understanding.
In a perfect
world, everyone works hard, everything works together, and no one needs
supervision. However, it is the lead's responsibility to identify those
tasks and people that do and to get a commitment from them stipulating
what they will do in writing. Remind them of these commitments as often
as necessary. It is equally important that the individual and the team
as a whole understands that "done" means "complete, meets
quality standards, requires no future adjustments or tuning, and is
ready to ship." When you do this you set up both the team and that
individual for success.
5. Not Making Audio a High Enough Priority
At the beginning of the project, this was the most underestimated and underbudgeted task. We quickly realized the scope: at least 200 pieces of music, many short, but there nonetheless with each MIDI piece having its own unique samples -- a nightmare for conversion to cartridge. Angel Studios simply did not have the know-how to execute this area of the project.
The tool we had developed internally required a ten-minute compilation process between the alteration of a sequence or sample and hearing that sequence. Obviously, when you are going to be attempting to refine more than a thousand individual samples not only for correctness but also to make them as small as possible, this system simply would not work. Fortunately, we had a connection on our team in the German development community that used to play videogames in his basement with Chris Huelsbeck from Factor 5.
Factor 5 is developing Nintendo's next-generation sound tools. They have a system that reproduces on a PC development system exactly what you would hear on the Nintendo. Any change could be heard in an instant and samples could be continuously refined until they met size and quality constraints. They jump-started the conversion process for us and trained our people on their tools, while converting half of the MIDI files and all of the instrument samples. Notes that sounded exactly the same that were scattered across multiple MIDI files became collated and used repeatedly in the sound bank. Each looping sample (such as a reverberating piano note) was shaved and shaved again by Factor 5's Rudi Stember, while Chris Huelsbeck was involved in the MIDI conversion process. The result was better than anyone expected. Finally, using their sound driver on the N64 allowed us to use Dolby Surround Sound to place sounds in true 3D space, making the in-game sound far superior to its PSX predecessor.