Author: by Takayuki Isobe

Solatorobo: Red the Hunter took 10 years of planning and three years of development, which is a very long project for a Nintendo DS title. Because of the long production time, we were able to create a title with a deep and well-detailed world view and storyline; equivalent to an anime series, which no other Nintendo DS title had done before.

In this postmortem we will discuss both the good and bad experiences we had during development, as well as how unique this title is compared to the other games we had developed in the past.

What Went Right

1. Concept and World Settings

Our first title was an action game called Tail Concerto, which we released on PlayStation in 1998. Tail Concerto and Solatorobo are two titles that share the same world view. We call this world "Little Tail Bronx", which we kept refining even after the creation of Tail Concerto and before Solatorobo.

During the conceptual period we considered many directions on how the world should be, hammering out the smallest details like how the society functions, living habits such as toilet shapes, and other aspects that would not be in the game.

As has been the case with every title, when we started on the actual development, there were various designs that needed to be changed due to game specs or level adjustments.

However, since we had an abundance of design assets and world settings from the start, and also shared all the information within the team, we didn't have to start from scratch and give out detailed information on what to do, as we already had a unified understanding of what the world was about. As a result, we were able to be very flexible on changes and giving out ideas on what to do.

2. Staff Assignments and Development Period

We were able to have a long development period by starting the project off with a small team, and when necessary, we assigned more people to the project. In the conceptual phase and beginning of development, there were about three staff assigned to this project, but by the end we had about 20 members. By this method we were able to have a long trial-and-error period that allowed us to hammer out what we really wanted to create.

3. Unified Thinking Using Shared Documents

We created an Excel sheet that allowed any member of the team to input their thoughts whenever they wanted. Topics could be anything from an idea or thought about the game and development process, or general suggestions, and I could then input my thoughts and answers in the comments.

By sharing this information with the team, every team member could see why some suggestions or ideas were prioritized, what type of revisions were made, and which comments were accepted and denied, so that everyone has a unified understanding of the project.

This list was also used when I needed to address new work, adjustments, and revisions to the team.

With this list we were able to understand the project beyond each of our assigned tasks, and gained a feeling that we were all creating this game together as a team.

4. Conducting Focus Groups with Young Children

When finishing the prototype, we decided to conduct a focus group with elementary students to hear their thoughts.

Since the platform was Nintendo DS, our targeted group was between older students in elementary school to junior high/high school students. Our main objective was to hear what the younger children had to say, since we didn't know much about that age group.

From the focus group we learned that things veteran gamers would find obvious were things that younger children needed advice on.

This philosophy is what we based our development on, by constantly indicating the controls in the user interface, having dialogue events during navigation, creating easy-to-understand level designs, and tweaking other various aspects in the game.

5. Perfecting the Game with the Entire Staff

The main programmer (Shinji Soyano) and I can be considered industry veterans and have a long history of developing video games, but the rest of the staff consisted of fairly young members. It was a good combination of young members, full of energy and ambition, with the veterans there to round them up.

As I mentioned before in regards to having a unified mindset, all the team members tried to contribute with ideas and comments for each section of the game.

Even during development we were be chatting away and exchanging ideas, saying, "Oh that sounds good! If that is the case, then we should have this too!" or, "This part is a little hard to understand. How about doing it this way?" As a team, we were able to refine each of the sections to something better. Also, by exchanging ideas and trying to refine the game, we were able to sustain a very high level of motivation all the way to the end.

What Went Wrong

1. Concept Approval

Solatorobo, like Tail Concerto, is game that takes place in a sci-fi world involving anthropomorphic dog and cat people, with robots.

Unfortunately, Tail Concerto, which shares the same world view, came short of expectations for sales figures. This was something that hindered the approval of Solatorobo's concept. To overcome the weak points with Tail Concerto, we created massive amounts of assets, generating multiple concept documents, each time refining the world and settings to create a game with a very deep story and a detailed world view that even a mature audience could enjoy, and eventually were able to get the green light from our client.

2. Game and Art Direction

I, personally, originally started off in the game industry as an illustrator, and often gave direction on gameplay, game designs, stages, and other visually related elements by drawing a picture or giving specific details on how something should look in the game. With these solid viewpoints we were able to create a game with consistency throughout (I also created the concept art for the characters and mech designs).

On the other hand, when there was an issue, the staff needed to ask for my input. This was a problem, especially during the middle part of the development phase, where I was bombarded with questions and inquiries, which made it difficult to give instructions at a timely rate.

3. Game Mechanics for an Action Game

At first the game was centered around a mech that punched its enemies as its main attack. It was based on a concept of making the game easy to understand, as well as giving players the satisfaction of an action game. However, the game became too simplistic, and wasn't unique at all.

After discussing the problem on multiple occasions, we decided to re-build the combat system around the grab, pick-up and throw elements which were already in the game.

However, this new battle system did not quite have the excitement we were looking for at first. After lots of adjusting and fine-tuning, the action, effects, and controls finally got to where they are now.

4. Finding the Right Look on the Nintendo DS

Since the Nintendo DS is not a platform with high processing power for 3D graphics, whether we created a building with polygons or used 2D artwork, the end result was not impressive due to a lack of detail.

After much trial and error, the in-game graphics artist found that mapping an illustration on a 3D model worked best and was something we could pull off well. However, we did not discover this technique until halfway through the production process and had to recreate all of the cutscenes we had created up to that point.

5. Fusing the Game and World View

For this title, we tackled the setting first, then created the story, and then began the game development itself. However, when the prototype was done, our team had some concerns about the game.

The storyline was very dramatic and well-told, but it felt as if it was aimed more towards a mature audience, and lacked action elements and exciting situations that younger age groups would enjoy.

After discussing this through, the team decided to add more surprises, laughter, and emotional aspects to the game, and came up with a lot of new ideas to implement into various scenarios and levels.

Thinking back, we should of have considered the gameplay aspect earlier in the project while creating the settings and scenarios, so that the two would fuse more smoothly.

Also, this being our first Nintendo DS title, we weren't fully sure how much the hardware could perform, which was another reason the original plan had to be modified.

Conclusion

Working on this title made us once again realize the core essence of game development, which is to bring out the staff's creative ability and maximize it. This is especially true for a new and original title like Solatorobo.

I think with modern, large-scale titles, game development is divided up in sections and each staff member's "game development" experience has been changing.

However, when developing a game, I think it's important to have an environment like Solatorobo did. It may be an old game development style, but it certainly has some qualities worth noting.

Managing and providing the design docs, world settings, and creating a system where the development staff can give each other comments and ideas was key to this project, and I think it was really important for us to create that environment for the staff.

Data Box

Developer: Cyber Connect 2 Inc.

Publisher: (JPN) Bandai Namco Games Inc., (EU) Nintendo of Europe GmbH, (US) XSEED Games

Release Date: (JPN) 10/28/2010, (EU) 7/1/2011, (US) 9/27/2011

Platform: Nintendo DS, Nintendo DSi

Dev team number: 10-20 staff

Budget: undisclosed

Code line count: 450,000 lines

Dev. Tool: Legitimate Nintendo tool