In this Gamasutra-exclusive postmortem, the creators of American McGee's Grimm honestly analyze the creation of the Chinese-developed episodic PC adventure series.
[In this Gamasutra-exclusive postmortem, the creators of American McGee's Grimm honestly analyze the creation of the Chinese-developed episodic PC adventure series.]
American McGee's Grimm is a casual action-adventure game, consisting of 23 episodes, each designed to offer 30 to 60 minutes of play.
The goal of the game is to convert the shiny, happy versions of some well-known fairy tales into darker versions more closely related to the originals. Players take control of Grimm, an angry, filthy dwarf, and venture into the world of these happy tales to corrupt them with his own dark aura.
Going into production, we knew we had a lot on our hands: we were going to develop the world's first weekly episodic game, and we had exactly one year before the first episodes were scheduled to air.
Since nobody had done a project with these variables, we had to create most of our scheduling and pipelines from scratch, based on the team's instincts and varied experience.
Now, a year and a half after starting development of our prototype, eight episodes of Grimm have been released; sixteen more episodes will be distributed in the next several months.
The game has been very well received: it has become the best-selling game on the GameTap service, and with plans to bring it to other digital distribution platforms, the future looks very bright for Grimm (however much he hates bright things himself!)
1. The episodic structure
Production
Grimm is the first game to be released in a weekly episodic format. In fact, we did not see Grimm as one big game; we saw it as one big season of 23 short video games.
Moreover, the first of these 23 episodes would be released halfway through the development schedule, so applying a typical production cycle (where all episodes would be made at the same time, going through prototype, alpha and beta stages at the same time) was out of the question from day one.
Instead, we came up with a schedule of 30-workday "cycles". This was based on the time one level designer needed to take one episode through one production phase. Every episode would go through three main phases (prototype-alpha, alpha-beta, beta-final). After reaching the final stage, an episode would go through a final clean-up stage in the month before its release.
At the peak of our production, we had nine level designers working on nine different episodes, with the art, animation and programming departments dividing up their time to make sure every level got the attention it needed.
Religious adherence to the production plan was all-important: a delay in one episode could very easily delay production for all successive episodes. But, through a well-defined project schedule, a weekly meeting schedule and good overall communication, we managed to pull it off without ever missing our milestones.
Also, with the 30-day work cycles as a base of the planning, everybody always knew when their tasks were due and when new ones would be assigned, adding to the overall efficiency of the team. We essentially developed a production plan that has a lot in common with Scrum, and with good success.
Art pipeline for Grimm. All 3D production was outsourced
Development
The story-telling in Grimm can be compared to the storytelling in South Park or the Simpsons: every episode is a stand-alone game, and does not require the player to have played previous episodes. Since every episode can be treated as one game rather than one level in a big game, we were able to change up a lot of things every time we started up a new episode.
The biggest change we made was after our prototype episode (based on Little Red Riding Hood) had been delivered to our publisher. Back then, Grimm was able to pick up words from the world (like the word "fire" on top of a campfire, or "rot" from a corpse) and use them as weapons.
This would really make the player feel he was editing the story, we thought. It did not. It felt really unresponsive and just was no fun to play, so we got rid of it and focused on the one thing that did work really well: transforming the environment.
Although we did not make changes as big as that to the gameplay after the actual production kicked off, we kept adding little extras every time we started working on new episodes, effectively making the Grimm experience more and more fun to play.
People playing the game have already noticed these updates -- the public thinks every new episode is better than any of the last -- and now that we know what issues players still have with the game, we can pretty easily adjust the upcoming episodes to be even better!
2. Working in China
Starting up Spicy Horse in Shanghai, China, has played a major role in its success as an independent developer. As one of the biggest game-development zones in China -- especially when it comes to foreign development studios -- Shanghai is a very interesting location to start up a studio.
For one, it is easier to find experienced employees, while the vast numbers of university and college-trained people in China also provide a steady source for junior level designers, artists or programmers. And although Shanghai is a much more expensive city than most other Chinese cities, salaries and overall costs are still much lower than in Europe or North America.
The success of game developers in Shanghai (both Chinese and foreign studios) has spawned a lot of outsourcing studios in and around Shanghai. This enabled us to outsource all of our 3D asset production, while still maintaining a hands-on approach to asset production: our outsourcing studio being around the corner, we could go and check up on them and give them feedback whenever we wanted to.
About half our animation and concept art team were outsourced as well, but (again) because of our favorable location, we were able to have them work on-site, basically working as if they were a part of Spicy Horse.
This close relationship with our outsourcing partner enabled us to keep our goal of maintaining a relatively small core team of permanent workers, while outsourcing as much of the art production as possible.
What truly makes Spicy Horse stand apart from the rest of the studios in Shanghai -- and probably also makes it work better than most foreign studios in Shanghai and the rest of China -- is its balance.
Spicy Horse has become a delightful mix of Chinese and foreign employees, of industry veterans and young and inexperienced people who are eager to learn. On top of that, an overall sense of egalitarianism throughout the whole team makes for a very tight-knit group of equals working together to get Grimm out to the public.
Main room of Spicy Horse Offices
3. Creativity is paramount
Creativity and encouraging creativity is extremely important when developing a video game and Spicy Horse has done a great job at keeping creative thinking alive throughout the whole project. The episodic nature of Grimm actually encouraged creativity in itself: every time an episode is in its last stages of development, the team looks for ways to make the next one even better.
Although the team is divided into departments with their own leads, we encouraged everybody to actively take part in any discussion. This made for a democratic approach to making decisions: it was impossible for any one person to call the shots without the support of their team. This push for creativity really paid off in art and design.
Establishing a unique art design can prove to be pretty difficult, but Ken (the art director) and American (the creative director) quickly came up with the rough outlines for what would eventually be the distinct art style of Grimm.
The cartoonish looks of the game are a far cry from most of the other Unreal Engine 3-based games, and enabled us to be much more creative with the content than we could have been, had we chosen a more realistic feel. On top of that, since the art style does not try to emulate photorealism, it will still look good in five or 10 years.
Thanks to the episodic nature of Grimm, the overall design of the game could change in between two different episodes. Every episode had its own design meeting and its own design documents.
These design documents were always the result of a conversation between different people and were never dictated by the creative director or another single person. And even then, after a design document was finalized, it would not be an untouchable dictate, but a 'living document' so that the level designers themselves could add new ideas to it.
Grimm concept image. Every asset in Grimm has a light and a dark version.
4. Good use of middleware
Throughout the development of Grimm, we were able to make good use of middleware solutions. Without those middleware solutions, Grimm would never have been as much fun as it is now.
The most important middleware program we used was, of course, Unreal Engine 3. UE3 was one of the biggest reasons why we succeeded with Grimm. It allowed us to prototype quickly, focus on core game mechanic issues, and accomplish some graphically interesting visual ideas.
Two other middleware solutions we made good use of were Bugzilla and AI Implant. Best of all, both of these solutions were free!
AI implant proved to be essential to getting the AI of our NPCs right. All the NPCs in Grimm have very specific behaviors, and using AI Implant enabled Marwin, our Technical Level Designer, to make those NPCs behave the way they should.
He could do this without having to bug the programming team to code new behaviors every time we came up with new requests for NPC AI. This greatly improved both speed and efficiency, and allowed the programmers to focus on all the other tasks at hand.
Through the many ways Bugzilla can be adjusted, we managed to make the application much more than just a bug reporting device. By the time production on the first episodes ended, we were using Bugzilla not only to report bugs, but also as a tool for feature requests and we had set up a bug verification tool to ensure bugs were being fixed.
It also became the main tool used to generate task lists for the programming team. Bugzilla, although a little rough on the edges and sometimes not quite as user-friendly as we would have liked, turned out to be an indispensable tool for the project.
The Spicy Horse Team
5. GameTap, our publisher
If it had not been for GameTap, Spicy Horse would never have existed. GameTap approached American looking for an episodic game set in a twisted fairytale world. Anybody who has spent time looking for a publisher knows how difficult that can be for a new studio, so Spicy Horse has been very fortunate to have been approached by GameTap.
In spite of a couple of hiccups (I cannot imagine a publisher-developer relationship where everything always goes right), GameTap turned out to be the perfect publisher for a game like Grimm.
They understood the reasons why we wanted to change up the gameplay so much after the prototype, they trusted our vision of what we wanted the game to look like and they always treated us correctly.
We have all heard horrifying stories about some executive at a publisher wanting a certain gameplay mechanic implemented two weeks before shipping the game, or publishers not paying because they wanted a certain feature in the milestone built first... but GameTap did none of that.
They have given us creative freedom and support, and it is wonderful to be in business with a publisher that sincerely wants to change the way games are financed, developed and distributed. We have been fortunate to have GameTap as our publisher and are thankful for the opportunity they have given us as a studio.
1. Defining production roles
Although we hired a game designer during the pre-production phase of development, he functioned primarily as a technical level designer, responsible for game AI. Most important game design tasks fell to the creative director and the producer.
We didn't have a truly dedicated person documenting design features and creating guidelines.
Initially, this did not seem to hurt production. But as the production team on Grimm grew, we realized not documenting rules, standards, naming conventions, designs and not updating production pipeline documents negatively impacted production of Grimm.
Likewise, we did have a lead level designer, but we never compelled him to take the lead.
He was not responsible for the overall quality of the level design; level reviews were always headed by the creative director, not the lead level designer.
Because of these missing and ill-defined roles in the production process, testers sometimes had difficulty explaining to level designers why some things were considered bugs because they didn't have a rulebook; animators were never given a default bone system and the art team never had a UI design document.
Level designers did get episode design documents, but these documents were not always detailed enough and a lot was left to the level designers to figure out as they went along. Grimm turned out fine, but if we had put more time in defining everybody's role in the grand scheme of things, things might have gone a lot smoother.
2. Pre-production team
A good pre-production team is focused, hard-working and committed to spending countless hours prototyping the main features of what will become their game. By those terms, the pre-production team at Spicy Horse was pretty inadequate. In fact, until we actually started building a prototype, we did not have any programmers, sound designers, producers or level artists!
The lack of programmers, especially, had a negative impact on preproduction. Not having a programmer meant that ideas could not really be tested, or that new features could not be implemented, so until we actually started building our prototype level, we never really knew if our core mechanics would work well (which they didn't).
It proved to be pretty difficult to start up a new studio, find employees to start up a new development team and start pre-production on a game that was supposed to be released just a year later. Still, this is a problem that is difficult to avoid if you are making your first game as an independent studio, and in the end, everybody at Spicy Horse did a really good job working with the means that were available to us.
3. Working in China
Although setting up shop in China has been a good experience overall, there are still many annoyances about living and working in the People's Republic. There's continuous honking right next to our windows; extremely hot weather and broken air conditioners; annoying security guards and stolen bikes.
These are all minor annoyances that people have to learn to live within China, but which obviously had no big impact on the production of Grimm. The two things that did have quite a large impact on Grimm were language and culture.
Although most of the expatriates already knew Chinese or were studying it, there was still a language barrier when talking about very technical things. Add in the differences in culture to that, and you get a pretty powerful combo of confusion. To avoid loss of face, a Chinese employee will not say that he only understood half of what his expat colleague tells him. This leads to misunderstandings, and ultimately to a lot of time lost.
We encountered a lot of these problems working with the outsourcing team that made all our 3D models. The same mistakes would be made over and over again because the modeling team didn't understand the comments we made on their work, package names would have spelling errors in them, etc.
Towards the end of the project, these problems gradually became smaller, as Chinese artists started to understand English better and expatriates became more proficient in the Chinese language. More bilingual support, both at Spicy Horse and at the outsourcing studio, would have helped a lot in the beginning, though.
4. Transformation tech too expensive
If you look at how we split up gameplay areas in Grimm, you'll notice that we have extremely small levels, most of them containing not more than 400 actors in total.
On top of that, poly count on our models is very low, especially when compared to other UE3 games. Yet, you need a relatively beefy computer to run the game at a consistent frame rate of 30 FPS. So why doesn't it run much faster?
The answer lies in the technology we used for the transformation feature in our game. We worked with a team of programmers in the U.S. to get the transformation gameplay to work correctly in UE3.
They worked it out pretty quickly, but the tech had one major weak point: it could only work with skeletal meshes. So, instead of using mostly static meshes like other games would, we could only use skeletal meshes. Needless to say, this had a huge impact on our frame rate.
There was talk about further optimizing this feature by assigning a team of programmers to it, but this never happened. That is why our game runs slower than Unreal Tournament 3, which is quite bad for a game that is supposed to be "casual".
Five different ways of morphing were used, depending on size, type and importance of a given model.
5. Offsite Business and Finance
While we assembled highly-skilled production teams in Shanghai, we were less confident that we could recognize and secure comparable local talent for managing business development and finance.
Placing these functions offshore, however, turned out to be a poor decision. For a small, emerging, committed team, there is no effective substitute for sympathetic, face-to-face interaction with company principals.
Discovering a competent, local colleague and placing these critical functions in his/her hands from the outset would have been better. Way better.
It's not really possible to discuss all the good and bad things about the production of a game in a couple of pages. In the "good" side, I might have mentioned the digital distribution formula that gives our game a much longer shelf life than it would have as a boxed product, or how much more streamlined and coherent our team has become throughout the development.
On the "bad" side, the misconceptions the press (especially the hardcore gamer press) had about the game weren't mentioned either: a lot of people complained about the game's modest degree of difficulty and lack of significant challenge (even though the game had always been described as "casual"). Our lazy camera design could have been mentioned here, also.
In the end, though, the most important thing is that we managed to finish what we set out to do: we introduced the gaming world to a new formula of a game 'season' consisting of 23 episodes.
We created an interesting game, with a unique vision, fun storylines and engaging gameplay. By always keeping to our well-defined communication channels and creative pipelines, we managed to hit all our milestones and avoid all but two days of mandated crunch.
Developer: Spicy Horse Games
Publisher: GameTap
Release: July 31, 2008
Platform: PC
Development time: 1.5 years from initial concept to release of first episode, with another 10 months until release of final episode.
Hardware: Pentium Dual Core 2.2 GHz, with 2GB RAM and Geforce 7900/8600.
Software: Alienbrain, Bugzilla, MS Project, Soundforge 9, 3DS Max, Photoshop CS2, Google Documents
Technology: Unreal 3, AI Implant
Number of employees at Spicy Horse Shanghai: 45
Number of external modelers: 13
Lines of code: approximately 45,000
Concept images: 2000+
Textures: 7000+ individual textures
Normal maps: one
Production time for one episode: about six months
Number of episode review meetings: approximately 271 for the whole project.
You May Also Like
