     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: Monolith's TRON 2.0 What Went Wrong 1. Short on initial resources. TRON 2.0 got off to a pretty good start. A lot of enthusiasm, ideas, and excitement flowed through the office. However, the majority of the team was still busy wrapping up other projects, and only a core team of about four or five actually began preproduction work on TRON 2.0. This is a pretty common scenario for most developers. The pacing of production usually has a small team jump-starting the next project by writing documentation, doing concept art, prototyping, and so on. Unfortunately, we failed to recognize a few issues that caused ripples later on in the production. These are lessons that we definitely plan to implement into future projects.
The most obvious was the lack of ramp-up time - not just in skills needed to use the new tools, but also in the mentality and spirit of the project. Past Monolith projects have been founded in more easily understood worlds. TRON 2.0 was different. It actually took some time and effort just to wrap our brains around what was TRON 2.0's reality. When production officially started and the entire team was in place, there were quite a few months where output was minimal. Also, the team's understanding of the game design was affected. Scads of design documents were written up in an effort to explain the concept of the game to the team. This worked to some degree, but was not ideal. Simply telling the team what to do not only failed to tap into the wealth of talent they had to offer, but also created a division in their perception of investment. Being involved during the inception of an idea, or actually being the one who spearheads the idea itself, fully invests a person into that idea. It's key to have the entire team feel personally attached to the project and not just see it as a series of tasks to be completed. We did have team meetings throughout the preproduction period, and it's not as if the design was written in a vacuum, but communication could have been better. The ownership of the design should have been more team oriented from the beginning rather than something they had to grow to accept over time. 2. Levels unplayable until later in project. It wasn't until very late in the schedule that the team was able to experience a full, playable level. Fortunately, the gameplay came together nicely and in some cases exceeded our expectations, but it would have been a disastrous situation had it not. Why it took so long for the game to hit its stride may again be attributed to our underutilized preproduction period. As I mentioned in the previous section, it took the team a considerable amount of time to "find" TRON - to collectively drive toward a unified vision. We had the necessary talent, and there was no shortage of ideas or inspiration, but the caliber of game we wanted to make was elusive at the beginning. In addition, TRON 2.0 pre-production did not include a fleshed-out prototype. Light cycle racing, disc combat, and the functionality of the subroutine system all loomed as unknowns for too long. To benefit fully from a good idea is to learn how to exploit it. Having key components of our game remain unknown generated trepidation when it came to linking time and resources. When the game finally did come together and we could see firsthand what worked well, we had very little time to build and expand confidently on those successful game mechanics. 3. Linking projects. Under "What Went Right," I mentioned that TRON 2.0 benefited greatly from the fact that we used the Jupiter system, which was developed and tested during the production of NOLF 2. This was true, but there were a few hurdles that also had negative impact on production. Although the Jupiter systems were extremely flexible, and even more so now, at the time they were tailored for a more realistic game like NOLF 2. To alter or add functionality for the TRON 2.0 project meant lots of tweaking. In addition, the team preferred to limit changes to game code, rather than rewriting core engine components unless absolutely necessary. 4. Loose review process. During our internal postproject evaluation, one topic that consistently cropped up was the inadequacy of our internal review process. Multiple elements drive the production of any project: an individual's task schedule, the milestone schedule with the publisher, the E3 demo and press schedule, and finally the team's internal progress evaluation. In a lot of ways the team's own evaluations can be the most critical, and it is here that TRON 2.0 suffered some bumpy times. In the beginning, we had in place a rather loose review system. It served the purpose of keeping the team on schedule to meet the necessary publisher milestones. What it failed to do was verify the project's overall quality and playability in a timely fashion. It was a strange sensation knowing that we were progressing according to the schedule but worrying deep down that we may not be hitting the mark. We eventually started to evaluate closely the work done by each team member at regular intervals, creating priority lists of subtasks that we felt were necessary to complete before the scheduled task could be crossed off. Toward the final third of the project, we had in place a very comprehensive review process that included weekly and sometimes daily reviews, a cross feedback system from all disciplines on the team, and an aggressive commitment not to falter, regardless of everyone's tight schedules.
Establishing a strong internal review system was so beneficial during the final stretch of TRON 2.0 that it is now one of our primary management goals for our next project. 5. Commercial 3D software woes. Level design reached a crossroads during the production of TRON 2.0 when we began using a commercial 3D package to construct our levels. The increased power and flexibility allowed us to model and texture the unique environments found in the game. However, abandoning our game editor during this phase of construction presented gameplay-related issues later in the project. In the past, constructing the world in our proprietary game editor allowed us to bounce back and forth easily between building and testing. When working strictly in a commercial package, the testing of work required the designer to jump through a few hoops to test work. While not overly complicated, it did require time, and therefore testing was done less frequently. Consequently, levels had problems regarding scale, flow, polygon counts, and delayed functionality - all things that could have been easily checked and verified in the game editor. A great deal of time was lost reworking levels to make them playable. Fortunately, now that our designers are more in tune with the workflow between commercial tools and our game editor, this issue is mostly a thing of the past. End of Line One of the more remarkable things about TRON 2.0 is how an eclectic group of individuals came together and weathered many storms to prevail, not with just a finished product, but one of which we can be proud. The dedication and talent the team displayed excites uslooking ahead to our next project.
As
far as the game itself in concerned, TRON 2.0 was truly the
opportunity of a lifetime. I was personally unprepared for the amount
of enthusiasm TRON 2.0 garnered from fans and from the press,
both in North America and in Europe. We knew all along it was going
to be a huge responsibility bringing the TRON franchise into
the 21st century. Now that all the hard work is behind us, it's
a thrill to know that what we've accomplished can potentially be
the seeds from which future projects can grow. And as a huge fan
of TRON, I can't wait to see the next tale told inside the
world of computers.
[back to] Introduction |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|