Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: Tom Clancy's Splinter Cell
View All     RSS
April 22, 2021
arrowPress Releases
April 22, 2021
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: Tom Clancy's Splinter Cell


July 14, 2003 Article Start Previous Page 2 of 2
 

What Went Wrong

1. Cultural barriers within the team. We wouldn't have completely this project on time without the help from other Ubi Soft studios. But the team's diverse composition made working together difficult. Many problems that we encountered stemmed from cultural differences.

The most obvious barrier was language. Three different languages we spoken by our team: Chinese, French and Italian. We had to use English as the working language, but not everybody was fluent in the language, and some people didn't even speak it at all. The first time it became an issue was during staff training. Since all the technical documents were in English and the technical director for the graphics team spoke only Chinese and English, it was very difficult to train developers who didn't speak English.

Before production began, we planned to mix people from different countries into one big team, thinking that it would help people get to know each other quickly. Then we realized that the language problem made that unfeasible. So we created two teams instead: local and foreign. Each team had a team leader who would translate project information to his team. Yet this structure created two other problems:

1. It made the decision-making process more difficult. The two team leaders would sometimes have different opinion on techniques, working arrangements, or requests to other teams. The worst was when these two team leaders gave conflicting information to their respective teams, which naturally caused confusion.
2. It created feelings of competition. People subconsciously - and sometimes consciously -- considered developers on the other team their competitors. While that can be good in a way, generally the situation made conditions uncomfortable, prevented a sense of teamwork and inhibiting the sharing of knowledge.

We didn't realize these problems until some bad situations occurred, at which point we tried to improve the situation. But since the production schedule was so short, we weren't able to completely solve the problems in time.


The power plant level for Splinter Cell (PS2)

There are broader cultural difference between Chinese and Europeans, too. While these variations didn't directly lead to any problems, the differences were noticeable and concerned the project managers. Perhaps the biggest difference was that the local (Chinese) developers generally showed more respect to authority. They were more willing to take time to understand the technology and development process and follow those conventions. In contrast, European developers tended to question authority and try to find a better solution. Sometimes they managed to come up with better ideas, but sometimes they wasted time. On a project with such a compressed schedule, that hurt.

2. Problems with data delivery. To deliver the highest quality game within the time constraints, we had to work on the raw data from the Xbox version of the game. That raw data consisted of 3ds max files, which were exported to the game editor to become game data.

When we started production in October 2002, we discovered that many of these raw data files were missing from the package we received from the Splinter Cell Xbox team. Consequently work on some maps could not start as scheduled, and our art team had to check all the maps to determine the scope of the problem.

We discovered that the problem was caused by the data archiving system. Since the engine only needs the exported data (the game data), the artists weren't obliged to archive the raw data, and sometimes didn't save files using the correct file names. So when the Xbox team packed up their database to send to us, some raw data files were missing and some files were named incorrectly. We had actually seen this problem arise earlier in the project, when we were working on the prototype. We asked the Xbox team to pay attention to the problem, but their team was also under tremendous pressure and sometimes the developers were too busy to adhere to rules that ultimately didn't affect their version of the game.

The missing data caused some bad feelings between the Xbox and PS2 Splinter Cell teams. The PS2 team felt that the Xbox team didn't care about the PS2 version's development, and the Xbox team felt that the PS2 team wasn't searching the package they sent carefully enough. Unfortunately we weren't able to completely solve the problem: some files couldn't even be found in the database managed by the Xbox team. But everything turned out fine, fortunately -- our engineers were able to create a tool that could recover the raw data from the game data files, so we were able solve the problem and extract the missing files.

If we could have foreseen this problem and started work on that file extraction tool before production started, we would have gained some precious development time. The lesson we learned is that when a risk is identified (e.g., not being able to get all the raw data), if one solution is not sufficient (asking Xbox team to be careful about storing data), we should have a backup solution (developing a tool).

3. Engine solutions vs. data solutions. Lighting and shadows are a very important feature in Splinter Cell. While working on the prototype, we encountered a technical problem that affected the accuracy of lighting maps and characters. The engine team thought it would be difficult to solve the problem quickly, but the prototype needed to have this feature working well. So instead of waiting for the engine team to solve the problem, we asked an engineer to create a utility for the artist to adjust parameters manually. It was temporary workaround.

While this was probably the best solution to complete the prototype on time, when production started on the real game, we were still using this solution on all the maps. Everyone on the art team was adjusting these parameters by hand. Later we discovered this created more problems. First, each map had its own set of parameters, making it difficult to control the overall quality. Second, because the quality of the lighting depended so much on the combination of certain parameter settings, small changes made to the tool would radically change all the setting, with disastrous results. The situation caused particularly big risks during the debugging stage.

If we had solved the problem in the engine in the beginning, the situation would probably have been much better. Although an engineer might have devoted more time to making the feature work properly, it would have save the art team lots of time. Above all, it would have been much better for quality control since just one people would have been controlling the quality of this feature for the entire game. This example illustrates that for features widely used throughout a game, an engine solution implemented from the outset is usually a wise choice.


Thermal imaging in Splinter Cell for the PS2

On the flip side, engine solutions are usually more complicated than data solutions. During the later stages of development (e.g. after beta), engine changes can be quite risky as they can break other parts of the game - which we also found out the hard way. During Splinter Cell's debugging stage, as we attempted to fix bugs in some maps, we added new code. But those changes introduced new bugs into the maps, so we ended up going back to the data solution. So the caveat to my earlier rule is that if there's not enough time left to debug new code, a data solution can be a better choice.

Whether to choose an engine solution or data solution really depends on the scope of the problem - whether it's global or specific to a certain part of the game -- and what stage of development you're in. If it's the beginning of a project and the problem is a global one, spending time to fix the engine is worthwhile. If the problem exists only in certain maps and you're already at the debugging stage, patching with a data-oriented solution is safer. (Although these solutions can make a perfectionist programmer uncomfortable.)

4. The risk of AI debugging. Splinter Cell provides the player with so much freedom that it is difficult to hide problems, especially problems related to AI behavior. Sam Fisher, the player's character, is equipped with a wide range of gadgets that players can use to observe and interact with NPCs.

One major risk we constantly discussed during the making of Splinter Cell was how to debug the AI. As early as the Alpha stage we foresaw risks in debugging the AI system, and it remained risky up until the end of project. In fact we had to delay the first focus-group playtesting session because the game was full of AI-related problems.

There were many reasons why we had faced so many AI bugs in Splinter Cell for the PS2. The most important ones were the following:

1. We started development on the PS2 version using the Xbox version's pre-beta code, which was still quite buggy.
2. AI bugs are usually harder to spot than other bugs. Testing this aspect of a game is more complicated and requires better communication between testers and developers.
3. The programmers on the PS2 team were not the one who coded the original AI, so they were not familiar enough with the code to solve the AI problems.
4. The optimizations we made for the PS2 version introduced more bugs, which were quite difficult to track.

There's no obvious solution to problem 1, as we didn't have much choice if we were to adhere to our schedule.

For problem 2, we made some efforts to improve the communication between the programmers and testers. For instance, we arranged training for the testers in which the AI programmer explained how to identify NPC behavioral bugs. We also equipped the testers with video capture cards so that when they reported AI bugs, they were able to attach an AVI file which made it easier to explain and demonstrate the bug.

To address problem 3, we managed to get two of the engineers who coded the AI engine for the Xbox version to join our team. They were instrumental in debugging the AI.

We should have done better in relation to problem 4. Level designers made some of the optimizations, but not all the level designers knew the AI well enough to ensure bug-free scripts. They needed programmers to tell them what was wrong in their scripts and how to correct the problems. This led to a bottleneck in the engine team during the debugging stage. If we had provided sufficient training for our level designers about the AI scripts, we would have prevented plenty of bugs in the AI, and made the debugging process more efficient.

5. Some regrets. After Splinter Cell for the PS2 was released on March 27, 2003, I collected player feedback from the Internet. The general feedback has been quite positive; many players like the game - especially the "power-plant mission" which is exclusive to the PS2 version. Players also like "snow-suit mission". The graphic quality has been complimented, as has the game play in general. However, there have also been some negative comments from players:

  • Player comment: "It's too easy."
    Some players think the PS2 version is too easy and too short, especially compared to the Xbox version. Some people also find the difference between the "normal" and "hard" mode too subtle.

    The fact is that we reduced the difficulty of PS2 version on purpose, since almost all of the playtesting of the Xbox version indicated that people felt that game was too hard. We keep in mind that there are more "casual" PS2 gamers than there are in the Xbox market. So in order to adjust the game to this market, we adjusted gameplay in Splinter Cell for the PS2 in a few respects, including player control, AI and level design. However, it's possible we might have gone too far, as some players seem to find the game not challenging enough.

    We didn't have much time to fine tune the game play for the "Hard' mode. Only some parameters are affected in that setting, like the damage dealt by NPCs, the quantity of Sam's ammo, and tolerance for triggering alerts. Also, there's no extra reward to player who play the "Hard" mode.
  • Player comment: "It has a poor ending."
    Most players don't like the ending of the game. There's no really challenge in the last level, and no big reward either. This is partially due to the Tom Clancy-style, which is not adaptable to a "boss fight" concept. But it also comes from the fact that we didn't have much time to create something really special. We didn't even have time to make any secrets/bonuses for the game, as the final debug was so tight and we couldn't afford to add any new features, lest we break something or introduce new bugs. We actually did make a secret mode for the game, but ultimately we had to ditch it because there was no time to debug it.
  • Player comment: "There's too much loading."
    I saw some players complain that the PS2 version's loading happens too frequently. This is due to the hardware constraints - the PS2 has less memory than the Xbox and PC. We knew about this problem from the beginning. We considered making the loading process more interesting for players by displaying special effects as it occurred (some animation or sounds, etc.), but we weren't able to come up with any good ideas. We used just one such "effect" in the game, and many people probably haven't even noticed it.

Summary

In Splinter Cell for the PS2, we succeeded with our strategy of applying a large amount of resources to meet a short production schedule. This strategy works for the porting projects which already have clear vision, based on the original version of the game. I don't think the same strategy would work for a game developed from the ground up, however.

Although we had very big production team, the team's size needed to be adjusted at different stages. In the early stages, a small but efficient team was a good choice. The team that built the prototype created solid base for the main production stage. Likewise, at the end of project, the team size needed to be reduced to efficiently control our debugging efforts.

It's very important but sometimes quite difficult (especially with lots of people) to ensure efficiency in your production team. I've found that the work done during the prototyping and pre-production stages is the key. A thorough assessment of potential problems and risks will identify impending issues you face, and with that information, you can construct plans to solve them before production begins.



Splinter Cell (PS2)

Publisher: Ubi Soft
Number of full-time developers: 76
Number of contractors:18
Length of development: 5 months
Release date: March 28, 2003
Target platform: PlayStation 2
Development hardware: PS2 dev tools, PCs avg. Athlon dual 1800+
Development software used: Unreal Warfare, Code Warrior, 3D Max, Photoshop, Ubi's animation tools, Optpix, Microsoft Visual SourceSafe
Project size: 3.47GB

 

 


Article Start Previous Page 2 of 2

Related Jobs

Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[04.22.21]

Studio Production Director
Remedy Entertainment
Remedy Entertainment — Espoo, Finland
[04.22.21]

Head of Project Management
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[04.21.21]

Mission Designer
Immutable
Immutable — Sydney, New South Wales, Australia
[04.21.21]

Game Producer





Loading Comments

loader image