     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Postmortem: What Went Right 1. Streaming Technology. Eutechnyx has streaming capability on each of the major consoles, but since it was developed initially on PS2, that platform will be the focus of this discussion. Eutechnyx developed streaming technology for its first outing into next generation platforms. The technology streams music, speech and the environment simultaneously during play. Although this technology is relatively commonplace now, at the time of development this technology was sought after, and was truly an attractive feature to publishers. A benefit of the Eutechnyx streaming system is that it's easy to use for programmers. The streaming system was not reserved for music, speech or transitions between the front-end and game but was actually used for all data reading. From a high-level programming point of view, reading data was performed using exactly the same interface, whether reading files across the network when using a PS2 tool, from the HDD on the Xbox, from within a massive WAD-type file on DVD, or across a Firewire connection on a test kit. All the programmer needed to be aware of was that the "read" would take time, and to wait for the data to become ready. Despite this flexibility, near-optimal read rates are regularly achieved and seek times are kept to an absolute minimum. There are four relatively simple ideas applied to the streaming system that enabled this to be possible. Importantly, these ideas are very interlinked and do not work well in isolation.
The majority of available memory on the IOP is reserved for streaming buffers. Separate buffers are devoted to each data type. This means that although the read head can only be in one place at a time, multiple files can be read simultaneously and -- most importantly -- that the contents of these buffers are not invalidated when the head switches from stream to stream. When mastering, all files are concatenated into a single archive file and are grouped and sorted within the archive. Grouping is performed manually by scripting and in the first instance groups each data type into separate areas of the disc. Grouping is used sparingly as it takes precedence over the more powerful sorting method; grouping is reserved mainly for music, speech and videos. The sorting method is semi-automatic, and very simple. Near completion, all areas of the game are visited; a file list is written out as each file is accessed, this file is then fed back into the build process. The low-level streaming code also automatically reads ahead, resulting in many files being read "for free." The game world needed to be divided up into land-blocks. As each block would fit into a pre-determined block of memory to prevent fragmentation, each land-block needed to be approximately the same size in memory, but could be any physical size. A lower limit was set on physical size of 500m in length. The lower limit was "calculated" using both qualitative judgments and mathematical equations. This limit was clearly based on loading speed, but also on manageability from an artist's perspective. The blocks became more like "zones," as each one can have its own unique textures and therefore its own look and feel. In addition to art assets, AI data needed to be streamed too. AI data needed to be divided into global and local categories. Global data needed to be kept to a minimum, as this data would be in memory at all times. The global data consisted of waypoints and routes between them. This data was used so the AI players could be aware of and know how to locate specific places, even if they weren't currently loaded into memory. Local data was loaded with each land-block and contained information that was only needed when the camera was nearby - for example, more accurate path data, physics material properties, point sounds, and so on. Streaming is a feature that is integral to our development and we are using it in our current projects as if it were second nature. 2. Extensive Economy Testing Prior to In-game Implementation. The economic model that powers Big Mutha Truckers is an in-depth system, based predominantly around supply-and-demand models. Although many other games use such a system, the Big Mutha Truckers model has a much more dynamic structure, since it had to be affected not only by the player's actions, but also by those of the non-player character rivals, who don't follow a fixed "trading script" and instead make decisions based upon the same market conditions as the player. One of the designers was an economics graduate, so we called upon his expertise as an economist to ensure it behaved in a realistic and lifelike manner. The result was that each game of Big Mutha Truckers will be different, but in a way that isn't based around simply generating random numbers or "cheating." Instead, there's a viable, fully functioning economic model based on real world behavior. Players can learn the system and exploit it to make millions of dollars in the game, something we felt was key to motivating the player. Because the economy formed the backbone of the game's challenge, it was vital that it functioned in a realistic manner -- and was fun to play. To ensure that the economy functioned in the desired manner, we produced a point and click "desktop toy" version of the game, which we then circulated around the office and encouraged people to play. The trading system within Big Mutha Truckers is essentially turn based, although the turn order depends upon arrival times at different cities each day. The fact that the economy works in this way means that there are well-defined links between it and the driving aspects of the game. This allowed the economy to be fully developed, tuned and tested before the driving sections were implemented. Certain aspects of the driving section do affect the economy, such as fuel usage, truck damage, and police encounters -- and these features were implemented in the trading tool as simple mini-games, where players had a "PASS/FAIL" dexterity test (i.e. two "buttons" appear on screen and flash rapidly on and off, with players able to stop the flashing at the press of a key. Obviously, the aim was to stop on the "PASS" button.) The only additional aspects of the main game that needed to be tuned were related to damage and fuel usage. Using the "desktop toy" we were able to ensure the economy couldn't be "broken" and this was tested extensively whilst the console technology and main game were being developed. The result was that we could immediately "plug in" the trading economy into the game knowing that it would work, thus saving valuable testing time later in the project. In the final game we also added parking and crash-combo bonuses to give the player extra cash, but aside from this the economy remained unchanged from the test tool to the final game. 3. The Asset Build Process. The final game-file archives are created from many hundreds of thousands of source files - textures, models, sound effects, music, scripts, and so on. We noted that it would be extremely beneficial to have a system where strict dependencies were maintained between all assets so that, for example, when a texture was changed, any models that referenced that texture were rebuilt. We created an extremely flexible build process tool with a GUI and a debugger that automatically calculated dependencies and only rebuilt assets when absolutely necessary. This system was written in Python, and the build scripts (lists of assets to be created) themselves are Python source files. This enables very complicated dependencies to be calculated at build time (for example, dependencies that depend on the contents of other assets). Although it initially took considerable effort to identify all dependencies, the fact that we now do not need to worry about whether or not an asset is up-to-date saves an enormous amount of time that used to be spent rebuilding all assets from scratch. We also built a system that automatically kept assets up-to-date on all platforms, code-named "Wanderer", that allowed most programmers to just copy the latest files, avoiding the time previously spend rebuilding themselves. For future projects, we are extending the build tool to a distributed build system that uses unused processor time on machines throughout the company. 4. Cross-Platform Development Philosophy. Big Mutha Truckers was Eutechnyx' first next-generation project and there was significant pressure to keep our existing engine and simply port it to PS2. However, the existing engine was optimized for the PS1 and not geared for cross-platform development. The decision was made to rewrite our game engine. Having evaluated third-party rendering solutions, we opted for the flexibility of writing our own renderer. We knew that this decision would mean that we would be competing with second-generation titles in our first outing. We would it would put as at a disadvantage by having to develop both technology and a game simultaneously. The cross-platform "common-interface" is set at a high level; this allows both general and platform-specific optimizations to take place. It also allows shared functionality across all platforms. The unique feature of the Eutechnyx common interface is that it has "width". For example, the sound-system has shared code (cross-platform) for managing active sounds; this then accesses the common interface to the platform-specific sound system. In this example I consider the common interface layer as "thick": it has a lot of multi-platform code below the common interface. In other cases (for example, in our optimized particle system), the layer is "thin". While developing these interfaces, our philosophy was as follows: 1.
Plan the interface thoroughly. Step 1 doesn't take much time if the correct people are involved. Stage 2, however, is the key. It can be reached quickly and allows features to be built, the game programmers to program, and the technologist to optimize. There may be early complaints of frame-rate problems, but that's nothing new and exactly what stage 3 addresses. We would encourage getting as many areas as possible to stage 2 and worry about stage 3 later. This sounds like a "just in time" development philosophy, but that is exactly what is needed when developing technology simultaneously with a game. As
well as being cross-platform friendly, the Eutechnyx engine is cross-game
friendly, with the core physics and driving code designed to run
any style of driving game. This means we can develop multiple games
on multiple platforms simultaneously. This helped Eutechnyx develop
more cross-platform technology for subsequent development contracts. 5. Use of Detail Mapping To Improve Location Variation. Detail mapping was used mainly to enable us to have more variation on our roads, while simultaneously using relatively little memory. It was also used on the walls of buildings, pavement, grass, and so on, but we found that its main benefit was on the road surfaces, where variations in lane layouts, chevrons, and junctions would have taken up valuable amounts of memory using standard texturing techniques.
The detail in the road surfaces tended to repeat, so it could be captured with tiled textures. On the other hand, the general road variation needed a texture with a much lower resolution, which allowed us to store many variations. This same effect could have been achieved using a repeating road texture with floating polygons for lane and road variations, but this required more polygons. With detail mapping, the detail texture can be mip-mapped to the point where it has no effect, then not drawn at all in the distance. The trickiest part of the processes, therefore, is setting up the mip-mapping of the detail texture so that it doesn't shimmer at certain distances, while maintaining its clarity close up to the camera. Using
this technique, we were able to produce more varied environments
for a minimum amount of effort by using detail mapping to customize
the standard road/building textures within the game. This saved
valuable development time without lowering the standard of the artwork
or requiring more memory.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Features
|
|
|