Imagine: Soccer Captain
In Imagine: Soccer Captain for Nintendo DS, you can be a part of a winning soccer team with Olympic gold-medalist Mia Hamm as your coach! Interact with teammates on and off the field to build camaraderie and become a better team. Run, kick, pass, and dribble as your team competes in local tournaments, and work your way up from beginner to pro levels!
|
|||||||||||||||
This is my favorite of all the Nintendo DS games I've ever worked on. The gameplay is fun, the characters are great (and completely customizable), the story is entertaining, and the overall level of polish is very high. Why do I feel this game was so successful? And conversely, what do I think we could have done better? Come join me on an adventure into the depths of the video game postmortem, and we shall see, and perhaps become enlightened.
What Went Right
1. Animation System
I'll start right off with the animation system—I'm extremely happy with how it came out, and it became the basis for animation systems for many of Powerhead's DS games afterwards. It was built on the animation system used for our Catz DS titles, and if you've seen how fluid and lifelike the adorable those little kittens can be, you know it can handle animating a few 40-pixel-tall low-poly soccer players.
The animation system manages a collection of animation states, each containing a main animation and optional transitions. Animation states can have triggers that run when the animations reach certain points, which can perform things like capturing or releasing the ball, tackling other players, starting minigames, playing sound effects, or queueing additional animations.
The final game contained almost 250 animations, my favorite of which were a collection of "juke" animations. When the player triggers this special move (which differs depending on the character's skill), the camera moves in, the action slows down for a moment, and the game really highlights how cool these animations can be.
A subset of the animation system was used for the high-poly versions of the characters in the dialog system, which leads us right into...
2. Story and Characters
Imagine: Soccer Captain is two things: a 5-on-5 soccer game, and a simulation of being the captain of a girls' soccer team. The various storylines of your main character, your teammates, their relationships, and their subplots are funny and entertaining, and the game's story wouldn't work nearly as well as it does without a number of factors all working together.
First, the dialog system. I originally developed this for Trollz: Hair Affair for Game Boy Advance, and brought it over to the Nintendo DS in Winx Club: Quest for the Codex. It allows the entire story dialog for the game to be specified in an Excel file, with scenes containing localized lines of dialog broken up in to pages, along with characters on either side of the screen, triggered animations, sound effects, camera angles, etc. It works especially well with localized text (this game was released in EFIGS) because the dialog system doesn't care how long the lines of dialog are, so it doesn't matter if the German text (it's always the German text) is twice as long; the dialog still works fine.
The other aspect of the story that worked really well was the fact that it was written at all! This was one of the first times we had an outside writer working on our game, and the quality really shows.
Finally, the characters. You could edit your own character and all of your teammates completely, changing their body shape, hair, skin, eyes, and accessories. You could edit the team as well, changing the team name, drawing a new logo, changing color schemes, and choosing or drawing a new jersey pattern. All of these tools were well-designed and well-implemented, and really let you create a team that you could enjoy using throughout the story.
3. Multiplayer
This game supported 2-player gameplay over DS Wireless Communications, a first for Powerhead, and we wouldn't have been able to get it done if we didn't plan ahead.
When researching the DS wireless capabilities, I learned that in most cases you would have lag of less than one frame between two systems—but you can only send about 256 bytes of data per frame. I realized that the easiest way to implement things would be to have the first player be the master, and the second player simply a dumb terminal that would receive a dump of the game state each frame and send back button presses and screen touches to the first player.
The key here came with the realization that the "dump of the game state" would be virtually the same thing that the instant replay feature was already using to store the previous few seconds of gameplay in a ring buffer. Trimming down the size of this data to 200-some-odd bytes was not too difficult, and the system could be reused for multiplayer with a minimum of new code.
Oh, and we artificially delayed Player 1's button presses for a frame or two to make up for the latency that Player 2 would experience, just to keep things fair. That was something we learned years earlier on Mary-Kate and Ashley: Sweet 16 for Game Boy Advance, which had a 4-player multiplayer bug that the 4th player would move more slowly than the others.
4. Gameplay and Physics
In addition to all the story and characters, I'm really happy with how the game plays. The character state machines worked well, the ball physics is fun, and we really took the time to refine the controls and make the game easy to play.
This was the key here: iteration. We had the basics of the game up and running fairly quickly, and we were able to move around characters and pass the ball to really get a feel for how it would play. We were able make small tweaks like adjusting the camera, changing collision bounds, and dialing in the physics simulation until things felt right, even though many parts of the game, such as animations and AI, were nowhere near complete. Just getting a feel for how the game played allowed us to tweak things in a very positive way. Which leads to...
5. Late Stage Design Changes
Usually, design changes late in the project are a bad thing. While that is still true to some extent here (as you'll see the next section), the reality is that these late design changes made the game much, much better.
As a project lead, when I'm asked to make sweeping design changes late in development, my instinct had usually been to puff up, raise my shoulders, and resist wholeheartedly. In this case, the suggestions—some of which which came from the publisher, some of which came from our own designers—had merit, and were backed up with enough evidence that taking on the risk was worth it. Thus, we got some great things in the game, core things to the game like the Mood system, better controls, helpful on-screen indicators, and other stuff so crucial to the finished product that I can barely remember it being a late feature. I definitely learned my lesson there...
What Went Wrong
1. Late Stage Design Changes
...and yet, the changes late in development sucked. The schedule was extended a bit to offset the difficulty, but nowhere near enough, and the new testing requirements caused us a slew of headaches. Resources that had become unavailable to us needed to be pulled from their new projects, and long hours and weekends filled those months. Finishing the game was extremely draining, though the result is something I am extremely, extremely proud of.
(On the plus side, while I was implementing these new features, the AI programmer was able to spend more time on the teammate and opponent AI, which also made for a better game. So I guess it's not all that bad after all?)
2. Multiplayer
Hey look, another thing that's in both categories. DS Wireless multiplayer, the bane of many a Nintendo DS developer's existence. Since our previous wireless multiplayer titles had limited their multiplayer functionality to a simple trading of data, we basically had to throw out all the previous multiplayer code we had written and create a new library. But that wasn't the tough part.
No, the tough part was passing Nintendo Lot Check. As soon as your game supports multiplayer, you open yourself up for a slew of esoteric tests, some of which can't even be tested on our development hardware (but require code inspection).
There was more than one discussion about pulling the multiplayer feature altogether. We were also having memory problems, as loading two customized teams was more memory-intensive than one customized team and one lower-poly CPU team, especially in the more complex 3D stadiums. But we soldiered through all the bugs and Lot Check requirements, and at the end of all things we came out of it with two rewards: a better game, and a Lot Check compliant multiplayer library that we would use in many other games to come.
3. Asset Management
As I've said above, we had some 250 in-game animations, each of which needed to be associated with one or more animation states, each of which was associated with one or more function callbacks, etc.
We also had over 100 in-game character models, close to 400 high poly models (for the story and character customization), a slew of texture animations, and a whole bunch of story animations.
These numbers may not seem high in the next-gen console world, but for us, this was a lot of assets, and it caused us a couple of problems during development:
First, the sheer difficulty of making that many assets. Since animations would drive gameplay, a gameplay feature was never completely implemented until the final animation for it went in. We could run the game with a placeholder version, but some things—animation duration, the timing of the ball release, even the amount the character moves during the animation—would affect gameplay in subtle but significant ways, which were not finalized until the animation was. With our limited animation resources, some moves, like the "juke", went in well after the game hit alpha.
Second, the memory footprint of loading the assets. The initial version of our animation system (from Catz, remember) used a smart cache to keep the most-often-used animations in memory. Once we had hundreds of animations loading, this system failed miserably. We ended up disabling the animation cache, loading files on the fly (not too difficult on the DS), and just caching a few really common animations manually.
4. Engine Re-use
The soccer engine was conceived, planned, and even initially implemented as a generic sports engine. But at some point in development, the harsh realities of the universe slipped in, and we had to start making tough decisions that resulted in a blurring of the line separating engine code and game code. Making games is often an exercise in practicality; the greatest code architecture in the world is worthless if it doesn't do what you need. All excuses aside, I would have liked if the engine could have been completely sports-agnostic, but many parts of it ended up not reusable (unless we had wanted to make another 5-on-5 soccer game, or maybe basketball, or...hockey, I guess?).
5. Testing
It was Friday. We had just built our first release candidate candidate (yes, you read that right). I decided to take the game home with me and play it over the weekend.
The game consists of you taking your team from the Junior League into the Pro League, then playing through five seasons of storyline, finally retiring after the fifth season. After you retired, you could still play matches, there would just be no more story.
I played the entire weekend. Customized my team completely, started playing through the story, and was really enjoying it. I was excited for the game to come out. Finally, at the end of the fifth season, as I was entering my final championship match, the game locked up. Power cycled, loaded my game, and it locked up again. Uh oh.
Turns out that the testers (ours and our publisher's) never actually played through the entire game from start to finish. They would use our cheat menu to test each season individually, and never encountered the crash—apparently the cheat menu did something else that caused the crash to not occur. I couldn't believe that I, the lead programmer and technical director, was the first person to play the entire game from start to finish. But I was glad I did.
The bug fix was trivial, and we had our new release candidate candidate the following week.
Conclusion
Just before writing this page, a year and a half after the release of Imagine: Soccer Captain, I started it up again and played a few matches. It's still fun, and I'm still really proud of it. I really feel this game was a turning point in my career and in the quality of my games, and I strive to keep that level of quality in every game I've worked on (and will work on) since.