When you hear the words “video game development,” most probably imagine a vertically oriented team with the Director and Producer at the center, and other positions around them, including planners (name depending on what the company is), programmers, designers and other positions.
However, for RE7’s development team, a unique so-called “Line Structure” was employed. They did not divide the team into groups of programmers and designers; for example, at a certain point, a team would be divided into three lines: the “Level Design Line,” the “Background Asset Production Line” and the “Character Production Line.” The “Character Production Line” was in charge of characters and creature models, motion, sound for those motions and everything otherwise needed for those. The “Level Design Line” was in charge of creature, item and gimmick placement, as well as all other aspects related to gameplay.
No line could function if it only had programmers, or only had designers. A character is designed by the designer, but another member was responsible for giving that character motion and sound effects. Therefore, each line had planners, programmers and designers mixed together. For RE7’s development phase, these lines, groups or whatever they were called, and of course the members belonging to them, went through various flexible mergers, separations and other changes as the need arose.
To understand what makes this style so interesting and meaningful, we must first know about “the transformation of the game development environment.” There will be an increase in the use of game development technical language, but in addition to the importance of knowing about the actual environment of game development, I personally found this to be very interesting information, so I would like to talk about it.
1. The Producer and Director propose what they want to create
2. Each team leader say what system should be implemented in order to achieve that
3. The planners hone in on the overall game system
4. The programmers, designers and others produce each part
This is probably a departure from the usual image everyone might game of video game development. This is what people call the “Waterfall” development method. In addition to deciding “what to make” and the details of that, as the word “waterfall” indicates, development moves forward smooth like flowing water. It is a traditional and orthodox development method. There is also the benefit of understanding the project’s progress, which helps ensure development progresses in an orderly fashion.
However, this development technique also has drawbacks. If the game’s system is not sufficient early on in development, or large changes in the game’s direction are made mid-development, then under a system that has been developed according to plan in an orderly fashion, a lot of precious work will have been wasted, or too much time is needed to make fixes. For the development of a game in which no one knows whether it will be enjoyable or not until people have tried it out, drastically changing things around mid-development is not a rare occurrence. This is especially for game development that has grown large in scale and more prolonged in timeframe.
Therefore, the larger a game’s scale is, the higher the chance of risk posed by the development using the Waterfall Method for a game whose functionality is determined late and whose flexibility is lost in response to large scale changes in its game system. Therefore, an idea the team devised was an “Agile” development style, with one of its techniques being the “Scram” technique.
“Agile” is generally defined as developing software speedily and appropriately. Most development utilizing the Agile style begins by establishing the general outline of the project without getting into the nitty-gritty details. Then, the parts that do go on to be developed are split up and enter what is called the “Iteration” period, during which they are developed one by one. Also, after a continuous period of iterating, development of the software is finished. It is not a matter of developing the game after its design is complete, but rather it is the collective process of setting deadlines and goals with particular purposes, then designing, implementing, testing and sometimes revising the content that constitutes game development. Under this development method, there is an assumption that there WILL be changes and to the system and design of a game, and allows for the flexibility of dealing with the possibility of new ideas springing up in the middle of development that can spur changes in the game’s direction.
However, compared to the Waterfall method, it is said that the problem with Agile method is that it is difficult to grasp what is going on with the entire project all at once.
“Scram” is one particular form of the Agile method. When you hear the word, you might think of Rugby. When one says “form a scrum,” the team huddles in a circle. For the Scrum method, the person deciding on the direction of the product, the Product Owner (in RE7’s case, it is Director Nakanishi) stands in the middle, and a “list of things that should be implemented” and a “list of things to change about the system.” These lists can take two to four weeks for the team to implement. This process is called “Sprinting” and it is during this time when the team holds short daily morning meetings to report on “what was done yesterday,” “what will be done today” and “current issues.” By repeating this Sprinting, a game’s development is completed.
For the development of RE7, they first implemented this particular flavor of Scrum. As mentioned in File 04, Takeuchi, as the person responsible for the development, placed great emphasis on all team members sharing their concepts and goals. After that concept has permeated deeply within the team, Takeuchi then created an environment where each member of the development team could propose the things they personally wanted to do. It could be argued that Scrum development, which requires team members to always recognize, share and solve issues, was the method most suited for this team. There would be a daily status check, and a swift recognition and sharing of problems that occur. Problems would be handled on a daily and weekly basis, which would lead to new topics and new problems to go with them. There would be designing, implementing, testing and revising in short time cycles, during which the concept would become ingrained, while the team considers and tries new ideas that are proposed.
In the previous paragraph, I said ” they first implemented this particular flavor of Scrum” deliberately using past tense for a reason. This is because the development of RE7 actually changed from Scrum to Waterfall during the middle of development. Indeed, RE7’s development utilized both the Scram and Waterfall methods. From early to mid-development, the team members would figure out the vision and concept of the game, try out things they wanted to do – a degree of trial and error was anticipated, which is why the Agile style, which emphasized flexibility, was used. The period from mid-to-late development was when the content and system were transformed into an actual product, and when the Waterfall method, which emphasized progress management, was employed.
Of course, it is simple to just write about these styles, but the practice itself is not as simple. However, the development team, in just under 2.5 years since the initial planning phase, had managed to reach the completion stages of a Triple-A class product in a surprisingly short timespan without sacrificing quality. There is no doubt that flexibly adjusting development styles produced tremendous results.
Also, as mentioned at the beginning, the Line Structure used for RE7 and described at the beginning of this chapter was born when the team moved over to the Waterfall method. In addition to its importance in this chapter, the Line Structure is directly tied to the characteristics of the RE ENGINE, so an understanding of that is also necessary. I would like to discuss that in an upcoming chapter.
On a side note, I will admit, for better or worse, than when writing about the development of this game and conducting interviews, I wanted there to be highs and lows in the development. That is why I requested interviews with the team right before events like the completion of the Beta version, or around the time a problem was likely to occur. However, on numerous occasions Producer Kawata apologized to me by saying, “I’m sorry, but development is proceeding more smoothly than anticipated.”
