Five Years, 20 Lessons, 20 DS Games

[The DS has been around for five years, making right now an opportune time to review some of the platform-specific development lessons Griptonite Games studio head J.C. Connors and his colleagues have learned during that time. So here we go: five years, twenty lessons, twenty games.]

When Nintendo first announced the DS in 2004, me and the rest of the crew at Griptonite Games were incredibly excited – as the leading handheld developer in the States, we felt it offered a huge leap past our then “bread and butter” platform, the GBA.

The DS is probably the most diverse platform in the world – it has the powers of a 3D console (The DS is nearly a PS1 in terms of power), along with two screens, great 2D capabilities,  a touch screen, a D-pad and regular buttons. Heck, you can play it rotated 90 degrees and no one bats an eye – try doing that with your GBA!

That much diversity gives developers a great deal of freedom. With older handhelds like the GBA, the hardware really restricted the kinds of games you could make. We love 2D at Griptonite, and we feel we made some amazing 2D games for GBA; but, game styles hadn’t fundamentally changed since the Z80-driven days of the Game Boy Color.

We were (and are!) incredibly charged up by the freedom and possibilities of the DS, but freedom also includes the ability to make design and implementation errors that just weren’t possible on simpler systems!  We knew there was going to be a lot of experimenting required to maximize the potential of Nintendo’s radical new handheld.

Of course, when the DS first launched, we had no idea if we’d even get to implement the many ideas we had for the system – the PSP was the hot new thing, while the DS looked like the videogame version of a “solution in need of a problem.” We loved the system though, and bet big on its success.

Five years down the road, we’re incredibly pleased to be the most prolific DS developer in the Western Hemisphere, with 20 released titles under our belt, and many more in development.

We’ve learned a ton over the course of those 20 games, and we’re excited to be able to share some of those lessons below. Some directly relate to DS development, and some can be applied to any system.  As you’d expect, we learned the most painful lessons early, so to keep things interesting, we’re not presenting the games list in exact chronological order.

Hopefully we can help the dev community as a whole by sharing some of our experiences. GDC is coming up, and if anyone wants to chat in more depth about DS development, we’ll be at the show, or feel free to drop me a line at [email protected].

Respect The Touchscreen
The Urbz: Sims in the City
EA, 2004
This was not only Griptonite’s first DS game, but also the only North American-developed launch title. What started out as a simple plan (port the GBA game to new hardware) proved to be chock full of lessons that are still useful today. The most significant lesson learned? Don’t treat the touchscreen as an afterthought.

You don’t always have to use touch in gameplay (now there’s a lesson I wish some games would learn!), but you do need to have a plan for touch input from the start, or you’ll be ravaged by gamers and the press.

Much of the Urbz’ development time went into designing touch-enabled menu screens that complimented the game, were intuitive, and felt necessary to the game. We quickly learned how important it is to always build on the DS’s touchscreen, as it’s one of the platform’s key features.

Nail Preproduction
Age of Empires: Mythologies
THQ, 2008
Here was a game that had a big advantage from the start, because it was a direct sequel to Age of Mythologies: Age of Kings, a game developed by a sister studio owned by our parent company, Foundation 9. Our team knew exactly what they wanted to build and how they’d improve upon the previous game; they also had the benefit of conferring with the prior game’s team. The art was going to be superior, the design tighter, the tech more reliable and carefully developed.

But, “make it better” is a goal, not an implementation strategy, and what enabled us to nail this game was the amount of work the leads did during a bang-up preproduction, utilizing every research resource available; detailing everything they needed to do; and meticulously scheduling the development cycle out. This led to a very smooth production and strong alpha candidate. As a result, the game is one of the best reviewed DS titles of that year.

Know The Platform's Limitations
The Chronicles of Narnia: The Lion, the Witch, and the Wardrobe
Disney, 2005
This was Griptonite’s first true DS game. For it, the team went back to its roots, creating an expansive, open world, action-RPG in the same vein as our acclaimed Lord of the Rings GBA games. While the game was gorgeous and has some innovative elements, it was too big for its own good.

The lure of better hardware was too tempting, and we realized that the DS, unlike its predecessors, is powerful enough to make games every bit as deep and large as many console games; but, that doesn’t mean you should: it’s still a handheld and you need to remember your players and the environment they play in. We were reminded that properly scoping a game and focusing on the fun, rather than showing off the technology, was still the key to creating great handheld games.

Old Is Good
Crash of the Titans DS
Sierra, 2007
Crash of the Titans DS was Griptonite’s second traditional 3D-platformer for DS. While the engine was in good shape and could handle the challenges to come, the schedule was tight and the team knew they wouldn’t have much time to iterate on gameplay. With an all-new franchise gameplay element (‘jacking big monsters) to include, this meant that team attention had to be split between critical platforming gameplay and the new ‘jacking mode.

The team leadership made a very smart decision and carefully analyzed every mechanic, move, and animation from the original Crash Bandicoot games on the PS1, with the intention to mimic them as closely as possible. Since everyone on the team and at the publisher agreed those mechanics were fun, using Crash as a “design doc” and duplicating those mechanics exactly would give the team an enormous time advantage.

This worked brilliantly, and had the added advantage that a lot of reviewers and players found the “old-school” mechanics nostalgic and a perfect complement to the new gameplay.

Innovation Has A Price
Spore Creatures
EA, 2008
Spore was one of Griptonite’s longest productions, beginning even as the PC game was taking shape. With a unique art style, a full-featured creature creator, wi-fi pollination, touchscreen combat, and an open mission structure, the game innovated in dozens of ways, both on the surface and under the hood.

While polishing traditional gameplay elements (like jump metrics, say) is relatively quick, the amount of time it took to polish each of these innovative new features on DS was enormous, each taking five or ten times the amount of time for iteration as it took implementation. In the end, some came out great, others came out so-so, and the game as a whole was more disjointed than it should have been.

The solution is to balance your design elements, maintain a realistic perspective, and not get obsessed with any one aspect of your design. DS games typically call for some sort of innovation, and Spore taught us to treat it the same way we’d treat a hungry bear roaming in the studio: approach with caution and only if you know what you’re doing!
 
Honest Talks With The Client Are Good
Pirates of the Caribbean: At World’s End
Disney, 2007
One of the main criticisms of our first Pirates game was that it was too combat heavy, and got repetitive. At the same time, Disney was trying to broaden the Pirates brand as the DS itself started to become more of a “casual device.” Early on, the client asked us to make the sequel with almost no combat in at all.

The thought was, great platforming could make for a great game, and touchscreen dueling would satisfy the bloodthirsty scalawag player base. While the team didn’t entirely agree with this approach, they went for it, seeing it as a challenge to their game design skills. What became obvious to everyone about midway through development was that great platforming and dueling were extremely time intensive, because those mechanics rely heavily on one-off scripting and art requirements.

Everybody made the call to include combat back into the game, and now the team had to build a solid combat system as an additional tier. If we had all sat down at the table at the beginning of production and honestly discussed the deeper implications of a “no combat” design, I think we all would have found a nice compromise early on.

Bad Tools Make Bad Fun
LEGO Star Wars II: The Original Trilogy
LucasArts, 2006
While the team spent quite a bit of time analyzing the gameplay of the console game and replicating its mechanics as close as possible on the DS, not enough time was spent on the tools needed to provide a great gaming experience. Camera scripting and level construction proved to be incredibly time-intensive to implement, and with a compressed timeline, the end result wasn’t nearly as cohesive as we had hoped.

Consider your team’s tool needs before your project’s critical cycles, not during them. After this project ended, we dramatically improved our scripting and design tools, allowing scripters to make edits in real-time on the DS and making sure that tool fundamentals were nailed down early in preproduction.

Nail The License
The Simpsons Game
EA, 2007
Built very closely with the awesome console version at EA, our DS team was challenged to bring the same level of attention to the handheld game. Early on, the team committed to staying true to the license — prototype 3D characters were discarded in favor of 2D ones, backgrounds were carefully hand-drawn, and tech was developed to utilize a monstrous amount of voiceover from the original cast (over 40 minutes of spoken dialogue in a DS game!).

While the game struggled during development to capture all the gameplay of its console cousin, the look, feel, humor, and audio presentation drew acclaim from Simpsons’ fans and handheld gamers alike, who rarely see such attention paid to a licensed title’s production values. It’s imperative to build on the strengths of the license you’re working with, and pay attention to what makes it unique.

Sometimes Low Risk Isn’t
Eragon DS
Publisher, 2006
Coming off of Superslam, the entire team used what we learned on that title to create a large-scale, 3D action RPG on the DS. Parallel to this game was an “easy” multiplayer, dragon-riding mini-game that was intended to only take a few weeks of development.

This supposedly-simple minigame turned into the project’s Achilles’ heel, with entirely too much time spent on iterating environments and multiplayer coding that took time away from the important combat and spell-casting mechanics of the single-player game. While the design was straightforward, not as much thought went into the tech and pipeline because it never seemed like it should be all that hard to implement.

In the end, Eragon DS was a fun and compelling gameplay experience, but could have been made better had we given equal treatment in preproduction to all of the game’s elements... or made the difficult decision to cut or replace the dragon-riding game with something else.

Prototypes Aren’t Games
Disney Friends
Disney, 2008
Inspired by games like Hey You Pikachu! and Nintendogs, the Disney Friends team knew exactly what they wanted to make, and were very disciplined with figuring out how to build it right. The team rapidly created a compelling and charming prototype, where the player could interact with Stitch using voice commands and touch gestures. Everyone who saw the prototype thought “Wow! This game’s almost done!”

Unfortunately, so much work was hacked in for the prototype that much of it had to be redone and rebuilt for the actual game, resulting in virtually no time savings for having built a prototype in the first place. Now, teams have solid discussions with themselves and our clients as to what exactly should be in a prototype, and how much throwaway work will get done for it.

Humor Is Free
Madagascar: Escape 2 Africa
Activision, 2008
Built on the same fundamentals as Crash of the Titans, the team set out to “sequel” that game with the cast of Dreamworks’ new Madagascar movie. About halfway through development, the team realized that the game’s large cast of characters meant that not all of them would get the same attention, and struggled to come up with ways to keep the game fresh and exciting.

In the last couple of months, the team added humorous moments to the game, including funny AI idle animations, lots of voiceover from the cast, and just small, goofy moments throughout the game. These moments really thrilled the kids who played the game, and added immensely to the game at comparatively little development cost (thanks, in part, to our established engine and well-developed content integration pipeline).

Still, I think everyone realized we should have done more and could have done more if humor had been one of our gameplay pillars early on. Now, we make sure to ask ourselves at the beginning of a project, “should it be funny?” and, if so, plan how to make it funnier from day one.

Plan To Throw Stuff Out
The Sims 2
EA, 2005
Our handheld Sims series have always featured handfuls of engaging minigames—quickplay activities designed to make the Sim some money, and to take a break from the motive gameplay constantly beckoning your Sim to the toilet. Minigames never look scary to anyone on our teams—some moderate code time, some minor art and sound needs, and little scripting—the team made a plethora of them for Sims 2.

What’s not in the game development manual is that at least half of your minigames won’t be fun on the outset, and half of those likely won’t be salvageable no matter what you do. A minigame either works and is fun, or it isn’t. If it’s not working, kill it, quickly. Nothing can go from “trivial” to “disaster” as fast as a mini-game you don’t let go of… (See Eragon!) Accept that not all of your content will make the cut, and plan for this from the start, so your publisher and your team aren’t counting on every minigame “working” and shipping.

Everyone Needs To Study The Competition
Bionicle Heroes
Eidos, 2006
Shortly after development began on this first-person shooter, Metroid Prime: Hunters shipped to great acclaim on the DS. Though there were only a few months left in development, the entire team—not just the designers—ripped this game apart, studying its controls, level designs, and enemy AI.

Every single feature was studied by every member of the team… and ultimately improved upon. Smaller, faster levels meant that Heroes was more suited to handheld play experiences, more attention to set pieces made the levels not as repetitive, and enormous focus on touchscreen responsiveness meant that Bionicle Heroes controlled every bit as great as Metroid.

Too often we found that just the designers were studying the competition, but Bionicle Heroes proved that you can get great results when the entire team focuses on dissecting a triple A game.

Know Your Audience
Shrek Superslam
Activision, 2005
This was one of Griptonite’s first fully 3D titles for the Nintendo DS, and it was a challenge, as a lot of tech and tools were developed simultaneously with the project. The complexity of this project was compounded by the fact that the entire team was very ambitious and the decided to include too many unique minigames that took focus away from the main, multi-character brawling mechanics.

When the game came out, we quickly discovered that while we were trying to cram in as much content as possible, we missed out on what reviewers and players really wanted on a game like this – the (then-new) single-cart multiplayer.

We quickly learned the lesson that multiplayer features, especially single-cart, was the way of the future on the DS, and that it had to be planned for from day one in development. Now, whenever we work with publishers, we ask these questions up front – to make sure we’re innovating in the same direction as our players want!

Empower Your Junior Staff
Pirates of the Caribbean: Dead Man’s Chest
Buena Vista Games, 2006
Dead Man’s Chest was a fairly straightforward production. It was going to be a straight-up brawler that could be played cooperatively with a friend. Key risks were developing a good combat system, the wireless code, and building enough good content to make it all fun. Most of our staff on this project was fairly senior, and they quickly took over all of the major components, leaving the junior guys to some menu work and graphical polish.

Unfortunately, this backfired when the game ran into some surprises. Designing single player levels that play nicely with multiplayer ones was a real problem; the combat system needed constant iteration and tweaks; the multiplayer minigames took time away from everything else; the levels were difficult and slow to assemble.

Suddenly, our junior staff was needed to work on major systems, but they had no experience in them. Since this game, we’ve made sure to embed anyone junior deep into the project and also make sure our tools and tech are extremely friendly and easy to jump into.

A New Understanding Of Polish
Mystery Case Files: MillionHeir
Nintendo, 2008
Published by both Big Fish Games and Nintendo, Mystery Case Files was Griptonite’s entry into “first party development.” It gave our team a fascinating look at how much time it takes to really, truly polish a game. Months and months were spent agonizing over every last detail of the game, every sprite, every background, and every line of text.

If something wasn’t fun or rewarding, it was done again until it worked just right. While this process was sometimes frustrating, and required amazing collaboration on every single person’s part on the team, the end result speaks for itself.

While it’s not always realistic to be able to apply this level of polish (or time) to a DS game, this project firmly confirmed our philosophy that the best way to build a game is to really “finish it” halfway through development, and spend the rest of the time polishing, tweaking, and crafting it.

Accessibility, Accessibility, Accessibility!
Looney Tunes: Cartoon Conductor
Eidos, 2008
The team set out to make a really compelling music rhythm game for DS, and created a fun and furious game that appealed to a wide demographic of gamers (and a game that was actually different than Elite Beat Agents, to boot).

Here we hit on a conundrum with the hardware and the license – the DS appeals to 20-somethings (and up) who fondly remember Bugs and Yosemite Sam. But it also appeals to six year olds, whose grandparents fondly remember Bugs and Daffy… And those groups have differing gameplay needs, to put it mildly!

Our internal focus testing helped us develop the solution; some good changes we made during development enable “no fail” gameplay for the kids, as well as a crazy-hard difficulty mode for rhythm savant. Ensuring we broaden the appeal when needed is something we try and take into account on every handheld game.

Control Is King
Spider-Man: Web of Shadows
Activision, 2008
Other developers have done a great job making solid Spider-Man games for almost a decade, so the challenge of delivering a top-quality handheld Spidey game on a short timeline last year was daunting. The team carefully prioritized their features, moving controls and handling to the front of the list, while actually bumping off big bosses and challenge levels entirely out of the game design.

While this initially seemed like a risky move, by first playable, Spidey was able to swing, climb, and leap with amazing fluidity and ease, and the team knew that the end result was going to be fun. First-class controls, solid AI, spooky backgrounds, and good mission flow made up for the game’s lack of over-the-top boss encounters and sprawling content. This philosophy of “controls first” carried on to several of Griptonite’s other titles, including the forthcoming X-Men Origins: Wolverine DS.

Reality Is Good
NeoPets: Puzzle Adventure
Capcom, 2008
NeoPets was Griptonite’s shortest schedule game ever. It was so short that we joked with the lead programmer, who returned from an extended vacation, that his new project was already halfway done! We had full support from our publisher, who knew just how crazy the schedule was, and was willing to help us out in any way to get it done.

It honestly felt a little like that scene from Apollo 13… “Ok, we have this code, these people, this many weeks (yes, weeks), and we need to ship a game that does A, B and C.” There was just no way to ship the game with our standard “producers manual, ” so while we normally organize teams in a hierarchal structure, for this project the producers on the project reorganized the team into small groups of strike teams with clear goals, who could work in parallel.

Each owned a chunk of the game, and each had daily meetings to review progress and assess the fun level of each minigame or activity. This serious, reality-based method of running a project turned out to be very flexible, and in the end produced a game we were proud of with virtually no crunch time. If a project seems unrealistic, developers need to step back and determine how to make it work.

Pipeline Is Critical
High School Musical 3: Senior Year
Disney, 2008
With our rhythm title High School Musical 3, our team faced an enormous challenge: they learned they wouldn’t be provided with the super-secret final songs for the game until as late as Beta! (Such is the world of licensed development, sometimes!)

Without knowing the music, the team had to invent a bulletproof pipeline that could quickly incorporate music, attach music nodes, and be tested in just a couple of (nerve-wracking) weeks. This attention to the technical and design pipeline paid off, and the game easily shipped on time.

We deal with license dependencies all the time, and HSM3 showed that asking the hard questions right away and road-testing our pipeline solutions helps ease the pain of the parts of development that are out of your hands. Focusing on what you can control (the pipeline) can turn what would normally be a crisis (not getting assets) into a beatable challenge.

<!--[endif]-->

Conclusion

The lessons we’ve learned in the past five years are now in the books. But DS development, like game design for any platform, is a process only hindered by the scope of our creativity. While there will always be a platform’s  technical limitations within which we operate, it’s up to us as developers to determine how far we can stretch them. At Griptonite, this is a task we gladly undertake every day.

Undoubtedly, the handheld market is about to change again. The DSi is out with new functionality, and no doubt both Sony and Nintendo are hard at work at future handhelds that will both approach console games in their technical capabilities and provide new, unique experiences to gamers on the go.

What’s clear is that handheld gaming is going to become more complex, evolving in connectivity, customization, and social gameplay that is going to especially challenge our designers and programmers. When Nintendo announced their two-screen device all those years ago, Griptonite shrugged and thought“well, that’s not much different.” We were – happily – wrong. We’re determined to not relearn the same lessons when Nintendo surprises us again.