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.