|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Things That Went Right 1. Power in numbers. When we started designing SIN, one of the first things we did was to form a tribal team approach. This is the way the company is run as well. There are two main camps of project management. In the classical Roman Empire approach, decisions are trickled down through a rigid pyramid-shaped line of designers, managers, and finally the implementers. Conversely, in the Attila the Hun approach, the entire group is given equal input and has equal weight in most decisions. We opted for the tribal approach because it offers the greatest pool of ideas from which to dip and it adds a certain synergy to the whole of the game’s design. Often a project can become myopic and narrow-minded in the hands of only one or two grand designers. We’ve noticed that the number three is magical. The greatest game designs have resulted from one person’s initial idea somehow supplemented by a second person and then finally finessed by a third. It’s that third derivative that usually ends as an ultimate idea. For example, the oil rig level originally started out as a cinematic boat ride up to the rig. Someone came up with the idea of letting players circle around the rig until they sniped off all the guards walking around. This version was pretty good, but players could ride around the rig 20 times before they managed to get all the guards. So we decided to have the boat wait on each side of the rig until the player had killed the two guards walking around that side. 2. Licensing the Quake engine. Licensing the Quake engine gave us a very stable base from which to begin. We were able to add new features and effects and then try them out pretty quickly. We also rewrote entire parts of the engine and heavily modified other parts. We wanted a higher level of interactivity than was available in the Quake game code, so we completely rewrote the game event system and AI code. We also built a character rendering system from scratch. The character system we used is a single-mesh hierarchical system. Finally, we added a bone-definition system so we could attach things such as guns or spears or spew out bubbles from any particular point. Even though we wrote a lot of the game code from scratch, the Quake II code was useful as an educational tool for game programming. 3. Animation system. The animation system was tied into our .DEF file system. The .DEF file is the extension we ended up using for all of our model text files. A .DEF file defines each character’s animations and event triggers for specific frames of animation. The .DEF file is in plain text, so an artist can make updates to the file when he changes an animation. For example, if an artist changes the rocket launcher’s firing animation, he can redefine in which frame the rocket would be fired in the game. Later, we discovered that we could develop a lot of special effects with the .DEF file system. We were able to create muzzle flashes, smoke, rocket trails, and various particle effects on the client without having to send over temporary entities with the networking system. We made the networking architecture so streamlined that firing a bullet only sent over one byte of information in the network packet. 4. Artist control. The artists had total control over the integration of the art into the game. Any artist had the capability to place a character in the game with a set of basic animations and AI. The artist could test the character (examine its skin, invoke its animation, and so on) within in the game very easily. We were able to attach any item or weapon to a bone location with one command. This flexibility allowed for a lot of tweaking to take place at the artist level. Artists tend to be much more critical of details, so giving them the ability to fix minor glitches without bugging a programmer was welcome. Furthermore, most of our artists were able to cross over into other disciplines, whether building models, skins, animations, or textures, or any number of other related tasks. This sharing of duties was important because of the large volume of art we had to complete. 5. Our scripting system increased level designers’ control. We added a flexible scripting system so the level designers could create interactivity on their own. Previously, implementing most of the more interesting characteristics of levels was in the hands of the programmers. With our extensive scripting system in place, however, the programmers could focus on other areas rather than spending time writing specific pieces of game code for every level designer. As I mentioned previously, the final version of our scripting language comprised over 400 commands. Level designers had intricate control over every aspect of level geometry, character animations, paths, and player interactions with the characters. Level designers could go far beyond the simple whizzing gizmos and script entire scenes of characters and machinery and gunfights. And, because we integrated the AI with the scripting system, the level designers were able to create a lot of specialized content. In the SIN world, bums will chat with you and give you clues, and civilians will cower in fear or run away. SIN’s scripting system was actually a full-blown multithreaded language — the level designers became programmers on their levels as well as architects. Besides, making these modifications was the most fun and rewarding aspect of level design. Level designers gained a lot of freedom, but only at the expense of time and effort on their part. To borrow terms from the movie industry, level designers have become the set designers, casting directors, directors, lighting engineers, gaffers… they have control over it all.
|
|
|
Features
