What Went Wrong
1. Make data and coffee? Some data conversion runs took forever. Since everybody in the team to some extent depended on the data conversion, the impact of long data conversion runs multiplied quickly.
The second major problem had to do with interdependencies between diffrent data types and even program code. Inter-dependencies between data resulted in rebuilding of a lot of data, even if just small amounts of data changed. This could have been avoided with a different setup for the data, and perhaps by the introduction of some kind of linker for the data conversion. All this never happened for this project. Nobody had the time even to plan for something at the point when the problem became obvious. From this we learned one thing: Do not underestimate the amount of data one has to handle in a game for the (now) current generation of game consoles.
A Snow Speeder is busy "cabling" an ATAT. A physics simulation drove the cable's movement.
2. Cutscenes. As we did in our earlier titles, we wanted to avoid
using FMV for cutscenes, to avoid breaking the continuity and style of
the game. The playback of these animations was handled quite elegantly
by our standard run-time animation system, which we used for all types
of animation throughout the game. The internal structure of this system
closely resembles Maya's animation system, which made it very flexible
and straightforward to control from within that tool. It also was really
easy to use at run time. This is where the fun ended, however, and things
started to get ugly.
On the programming side, we had to spend a lot of time organizing the data flow. We wanted to make the amount of data to be loaded or kept in memory for cutscenes minimal, which meant recycling data that was present in the level data currently loaded. This sounds easier - and we fell for it, too - as it is actually was. However, our main problem was that we weren't able to begin implementation of the cutscene playback until pretty late into the project, and the programmers responsible for the task were confronted with a data structure that was pretty much set in stone. This is the one area in which our planning at the beginning of the project did not quite work out.
In addition, the animators could not start until relatively late in the project. This was due to both the unfinished system implementation as well as their simply being occupied with other tasks. This time frame put the animators under a lot of pressure. To make things even worse, they had to suffer quite a bit under the slow data conversion. The cutscene data included so many cross references into other types of data that changing a cutscene frequently meant rebuilding major parts of the data set.
thing that slowed us down was the fact that we could only export part
of a level's data into Maya as a reference for the animators to work with.
In particular, the long cutscenes in the Hoth level, featuring many close-to-ground
camera moves, presented a challenge, since the height-map geometry export
into Maya always used the lowest level of detail and hence didn't represent
enough detail for such tight corner moves.
Previewing music and sound effects for cutscenes proved to be another hassle. The effects and music were triggered from within Maya but could not be previewed there, which meant going through the data conversion step each time we wanted to test things.
More preview capability and a faster data conversion would have solved our problems. It also wouldn't have hurt to have more time, a luxury we simply couldn't afford this time around.
3. What's that engine glow doing on the nose cone? Little things can cause big problems when time is as much a factor as it was with this project. The method we used to add visual effects, like engine glows to the in-game craft models, introduced a high dependency between the code versions used to edit new levels and preview models, and the model data itself. A simple change to the model within Maya could trigger engine glow to appear in the completely wrong spot.
This made it close to impossible for the artists to judge whether they actually did something wrong while exporting the data or whether this was just one of the cases where everything was actually in order and only the code version needed an update. This situation was truly counterproductive in the last weeks of production.
We will have to remove this dependency completely from our next game's data path. To some degree, this will be a side effect of our effort to speed up the general data conversion by removing data interdependencies.
4. "I've got some new songs." While we had pretty good turnaround times getting completely new sound effects into the game - as much as in-game material was concerned - the data path and the way the music was linked into the game did not allow for any fast preview cycles for streamed or MIDI-based pieces of music.
Due to time constraints, we had been unable to implement tools that would have allowed adding or changing pieces of music without rebuilding the program code. Furthermore, most pieces of music are triggered from scripts designed by level designers, which meant we always had to coordinate three people in the process: a programmer, a level designer, and the musician.
In the end we coped with the problem to some extent by simply setting up a schedule defining when a new music update would be done. The musician was able to audit his score without the integration into the game on a prototyping tool at any point in time and with minimal turnaround times. The schedule made the problem somewhat manageable for all parties involved, but it was still a far cry from being a good working environment.
5. L3D: Trusted, proven and, well, a bit rusty. L3D, our in-house level editor, had been around for many years when we started Star Wars: Rogue Leader. The good thing about this was that the level designers knew the tool and it had gone through a lot of iterations of improvements during the development of Star Wars: Rogue Squadron and Star Wars: Battle for Naboo. But we also knew that it wasn't exactly designed to deal with data sizes as they regularly pop up with this new generation of consoles. We simply didn't have the time to program a new tool, since level designers had to start their work early. We just hoped for the best.
The tunnel sequence of the fight for the second Death Star as seen in L3D. The boxes are added to ease the culling process, while the spheres control certain aspects of the gameplay like triggering of events or lights..
Some things got very slow as things got very large in terms of memory. For the most part we could get things to a workable level again by running the tool on relatively high-end systems. Other things just had to be endured by the level designers. The situation was far from perfect. Despite its shortfalls, however, we couldn't have made it without this old, trusted, and slightly outdated tool. Still, a new, streamlined tool would have been much faster and more user-friendly, which in turn would have given the level designers more time to actually design things. As a logical consequence, this is what we are currently working on. With a bit more time on our hands for finalizing our next title, we took the opportunity to take the things we learned from L3D and rewrite a new tool from scratch.