|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
What Went Right There’s no doubt Drakan had an ambitious design, so the graphics had to be top-notch in order to make the game world believable. The amount of art and animation content we would need mandated careful planning, lest our schedule slip. The solution to the problem was what I call “flexible reuse.” In addition to the sharing of texture and geometry data between objects, Drakan’s engine (code-named the Riot engine) was programmed to allow arbitrary scaling and rotation of art content. By assigning different behaviors and combining multiple art components, we were also able to create totally new structures with minimal effort.
Though the artists created the objects and buildings in the game, the designers were responsible for placing the objects into the game and gave immediate aesthetic and game-play feedback to the artists. They also were responsible for building the landscapes and caves, which defined the overall level flow. This process evened out the workload between artists and designers, but it required the designers to have a good artistic sense. This can be seen in the very fantastical landscape architectures that the designers constructed and then painted with tileable textures. The textures were drawn by the artists to have many variations and transitions, which added to the organic nature of the terrain. Drakan had an advantage that many large game development companies sometimes overlook. It had a young team, highly motivated, bursting with ideas, and ready to take risks. The ideas were unique and motivated by the desire to set Drakan apart from the shooters and Tomb Raider clones (although this was still difficult given the tendency of the gaming press to compare games to one another). The most original idea in Drakan was the combination of dragon flight with sword and bow combat on the ground. This fundamental idea formed a developer’s carnival for more innovative ideas and forced the player to strategize in a way not often seen in action games. The relative vulnerability of the female rider contrasted with the powerful dragon required careful thinking by the designers. Levels were created with restrictions on the dragon’s ability to go places. Rynn could enter caves, but would come across areas where the dragon’s flying abilities or strength would be necessary to proceed. The player (as Rynn) would then have to find a large door or other method to get the dragon inside the cave system. In this world of magic, creative ideas for special effects are very important, and these tasks were ideally suited to people who were not afraid to do things “outside the box.” 3. Engine and tools Many recent games have shipped with engines that simply cannot handle the target platforms and the breadth of 3D hardware that they claim to support. I believe this is primarily due to a lack of planning and preparation for current and future technologies (not having scalability, for example), and a rush to focus on the game’s design and art. No time is given to solidify the underlying technology, which should ideally be done before the designers and artists even start constructing content. If the designers spend half their time waiting for the game to load, or dealing with unplayable frame rates, the final game will only be half as good as it could have been.
The engine is broken up into many classes that handle various engine tasks and are the interfaces by which the game code accesses the engine. For instance, there is a sound class for playing sounds, a texture class for working with textures, a sequencing class for playback of scripted cutscenes, and numerous others. These also form a framework for future porting of the system-specific functions to other platforms. The stability of this system can be validated; we are currently creating additional games based on the Drakan engine with little or no code changes to the engine project. To further reduce the debugging time, we put coding guidelines in place to ensure the consistency of code between programmers, and created classes to catch array boundary violations and memory allocation problems. The system meant designers could tweak parameters and combine modules in ways that the programmers never intended. One particularly nice example was an effect that was originally created for the “ice sword.” The effect was made up of a number of particles (originally snowflakes) that would collect for a certain amount of time on the mesh of an affected object. After a time, the particles would fall to the ground and stick for a bit. All these properties, from the timings to the particle texture, are configurable. With this feature at their disposal, the designers created glowing auras around ghosts by increasing the particle size and making the stick-time infinite. They created snow that landed on invisible platforms to guide players across them. The snow effect was attached to arrows to drop ice behind them as they flew. All this from a small bit of programming.
A good design will not only sell a game — it can also help smooth the
development process. The Drakan world has immense possibilities,
so new ideas were born easily within its scope. This kept the team highly
motivated, as there were always innovative things to do with the genre.
The varied environments gave a wealth of new things to work on for the
art and design team, and were an ideal canvas for programmer invention.
The
design also kept Psygnosis very interested. Drakan became its
top PC product, and it was comforting to us as developers to know that
our publisher was behind the product. Psygnosis saw the marketing potential
in a beautiful female character combined with a fearsome, fire-breathing
dragon and the press latched on to the concept with excitement. They
could market it to Tomb Raider fans, AD&D fanatics, and even
3D shooter addicts. Even the most brilliant design would be difficult to implement lacking a proper design document. The 175-page Drakan design document contained outlines for the entire game, including all AI behaviors, weapons, and level flows. It served its initial purpose well, and was a blueprint for our lead designer’s vision. The document was vital to the development team, especially when it came to scheduling, creating tasks, and communicating with the publisher. But as you will read in the following “What Went Wrong” section, feature creep overtook the project halfway through, and the document never kept up with the changes. A design document should always be maintained throughout development to preserve it as a useful resource for the team. Fortunately, the team could always rely on Alan to explain anything or to fill in any holes in the design document. 5. Indoor/outdoor environments
One of the major technologies that set the Riot engine apart from the other landscape engines was its ability to render both indoor and outdoor environments using the same engine. The benefits to game play were huge because we could do arbitrary cave systems, arches, overhangs, and other structures that were perfect for a fantasy game. The “layer” system that the landscape was created with was ideal for massive outdoor environments and allowed the designers to create very organic-looking worlds. Rectilinear structures such as buildings and objects were created using arbitrary models imported from external 3D modeling programs. Although these models were not included in the visibility calculations, the layers were included and were nicely suited for use in the visibility culling of large environments. Because the layers were small height fields that made up the ceilings and floors of the surroundings, they took up very little space in memory. This meant that the levels could be vast, and it helped give the player a sense that there was a living world around them. |
|||||||||||||||||||||
|
|
Features
