home 

homeproductscompanytechnology   
real-time 3dinternet kioskfuture projects
    
Overview    
Video     
Screen Shots     
Design     
Plan     
History     
Team       

Development Plan 
Table of Contents  
Introduction   
Editor   
Graphics   
Hardware  
Architecture   
Data  
Code  
Demo  
Motion Capture   
Networking 
Scoring   
Tools   
Team   
Behavior   
3D 

       
real-time 3dVertigo PC Plan 
Introduction   

This document is the companion to the Vertigo Game Design document. It specifies how the project is being implemented. The main body of this Technical Design document is divided into the broadest categories for easy reference: Architecture, Code Components, Data Structures, and Development Plan. This introduction provides information useful primarily to newcomers to the project.    

Data Structures and function names are underlined. Ex.: elementInfo  
 

This document is divided so that each sub-topic appears on its own page. This makes markup and manual insertion of clippings and hand-drawings easier.    
  

Development Plan   

This development plan serves as a guide for the Vertigo Team’s efforts to implement the architecture, code and data structures outlined in the previous sections of this document. Our design philosophy is outlined in this section. Procedures for performing revision control, archiving and other tasks are defined. Development considerations like limited VRAM and CPU time are noted.   

Development Philosophy   

The Vertigo team development philosophy consists of a few simple tenets. When decisions need to be made trading one goal for another, these principles serve as a guide.    

Build a Good Game   

Quality of game play is of primary importance. Early and frequent play testing of the game will ensure that Vertigo is a superior game rather than a technical or artistic achievement. If limited time is available to allocate to refining game play or building more levels, refining game play will prevail.   

Build an Immersive Action Game   

We are building a game which must immerse and hold the attention of players within the first few seconds of play. Frame rate and Interactivity are key design goals. If a decision must be made between graphic detail and frame rate, frame rate will prevail. If a decision must be made between a beautiful elaborate motion capture segment and responsive control of the player’s avatar, responsive control will prevail.   

Make No Excuses   

Vertigo is playable at every stage of the project, from initial prototype to master disk.    
 

Development Procedures   

To lessen the burden of project management, development procedures are clearly defined in this document. Revision control, archiving, testing and other procedures are described along with their requisite tools, purposes and other implementation details.   

Revision Control   

Tools: Microsoft SourceSafe -or- PVCS   

Purpose: To provide a consistent framework for all source code and other changing game components.   

Frequency: Ongoing - Revision control is always being used.   

Description: To coordinate multiple programmers in a rapid development environment, it is necessary to institute some form of source code control. Source code control is essential to keep all programmers in sync, to provide a means for noticing conflicting code changes and to keep a record of all changes and who has made the changes.   

Microsoft’s SourceSafe has been selected for use. If there is some incompatibility between the Microsoft tool and the development environment on the PlayStation, we will use PVCS, which works on simple DOS files as well as with Microsoft Visual C/C++.    

Typical Scenario: A programmer is tasked to work on a new area of the code. He first checks out from the Source Code Repository and current version of the source code and builds the project. He then works locally adding the new functionality and, when it works, checks it back into the Repository. This provides the new functionality to the next programmer who checks code out from the Repository   
 

Archiving   

Tools: Off the shelf, backup tool: Microsoft Backup.   

Purpose: To avoid unnecessary delays due to equipment failure   

Frequency: Weekly full backups, daily incremental backups.   

Description: The project uses an off-the-shelf network backup tool to archive the project files and users’ personal work files. Full backups occur once a week and incremental backups occur each weeknight. Monthly full backups are kept off-site to provide some limited form of recovery from fire, flood and earthquakes   

Typical Scenario: The backup tools is scheduled to run nightly so the only user interaction in the normal case is to change the tape every day. If there is a hardware failure, such as a disk crash, the most recent tapes are used to recreate the lost information.   
 

Testing   

Tools: Video Camera, Microsoft Word, Microsoft Excel.   

Purpose: To provide a fun, bug-free game.   

Frequency: Developers test changes whenever they check in code. The local testers are always testing the most recent version which includes all checked in changes. Periodic focus groups (once a month?) are held to provide reactions of first-time users and to provide the developers with some sense of how the game will be used. Testing by local testers and focus groups is video taped.   

Description: Final testing will be performed by the publisher. However, extensive testing will be performed throughout the life of the project by development team and through developer organized user tests. In addition to periodic tests of the gameplay by the team and other test subjects, several testers are assigned to explore every inch of the game world and to try every bizarre combination of moves possible. While the publisher will perform many of these specific tests, it is important to the development team to have at least one local tester who can give quick specific feedback.   

Typical Scenario: When a developer finishes a change, he tests it. After he checks it in the next full build will provide the new code to the local testers. At the next focus group, new users will get to play a version of the game which includes the new code. And finally, this new code will be tested as part of the next work-in-progress sent to the Publisher.    
 

Task Assignment   

Tools: Microsoft Schedule+   

Purpose: To provide a central repository for necessary tasks and to avoid duplication of effort.   

Frequency: Ongoing, especially when a task is started, redefined and completed.   

Description: Tasks are collected, sequenced and grouped in Microsoft Schedule+. Tasks from this schedule are then assigned to programmers and artists. The assigned task is then associated with the team member who will perform that task and the estimated completion date is entered. When the task is completed, the schedule is updated to reflect the new status. If the estimated completion date passes without the task being completed, the team will come together to either assign more resources to the task, transfer the task to another team member or adjust future tasks to compensate for the lost time.   

This task method provides a continuous window into the current state of the project as well as the projected work remaining.    

Typical Scenario: A programmer finishes work on a code component then checks the task list for an unavailable task whose components are completed which the programmer is qualified to perform. The programmer grabs this task by assigning it to himself and creating an estimated completion date. He then starts finds the design of the subsystem in the design document and begins working.   
 

Creation of Texture Maps   

Tools: Digital Camera, 35mm Camera, Drawing Tablet, Photoshop, scanner, Animator-Pro, Painter.   

Purpose: To create realistic textures to map onto 3D meshes. Specific formats and textures are required.   

Frequency: Whenever creating 3D objects, each object must have a library of textures. Textures may be shared by objects, however.   

Description: Texture is captured through a camera, digital camera or video camera. Texture is then adjusted to suit in RGB mode. The final image is adjusted to the required resolution (square texture whose side length is an even power of two) and saved as an 8-bit indexed TIF file. The final texture is then mapped on the assigned faces of the mesh.    

Typical Scenario: Artist needs a texture which doesn’t yet exist in the texture library. He takes a picture of it with a 35mm camera, scans the photograph and imports it into Photoshop. In Photoshop, the image is adjusted and scaled to an even power of two, ex., 16x16. Once adjusted, the image is saved as a TIF file which can then be used in the game editor and in the game itself.   

    

Journaling   

Tools: email, fax, video cassette for reports. Tape backup for archive.   

Purpose: To provide a history of the project and to provide visibility into the project’s progress for the publisher.   

Frequency: Vertigo Report Email - daily; Vertigo Status Report - faxed weekly; Vertigo Video - occasionally, but not more frequently than semi-monthly; Completed Milestone Packages, including Playable Game - monthly, as determined by the schedule. Archive data is not sent to the publisher but is available for historical interest - and to save files which are inadvertently lost.   

Description: Vertigo Report Email - simple daily list of important happenings.   

Vertigo Status Report - Detailed status including issues which are critical and those which are poised to become critical.    

Vertigo Video - Captured gameplay and talking heads, includes artists and programmers discussing work in progress. This is not a regular Virtigo output document, but will be provided sporadically during the project. No fancy editing or effects will be in these videos; our task is to create a video game not video tapes.   

Completed Milestone Package - Package which contains all documentation and game features to complete a milestone. The game features are present in a playable version of the game. New art assets for a milestone are included on paper as well as in the playable game.   

Archive Data is collected by the Vertigo Archive procedures documented elsewhere in this document. Archive data provides a full, excessively detailed picture of the development process. This information will not be sent out, but is available for historical queries and, of course, restoration of lost data.   

    

Risk Management   

Tools: None   

Purpose: To avoid being blindsided by an avoidable risk.   

Frequency: Continuous.   

Description: Risk management in Vertigo is accomplished by keeping a detailed schedule and noting when and where the actual development deviates from the schedule. In addition, especially risky sections of the design are recognized as such from the onset and are provided with alternatives in case the risky code cannot be developed quickly or efficiently enough.   

Awareness is the primary tool of responsible risk management.   

Typical Scenario: A task is noted as risky while developing the schedule. This inspires efforts to attack the problem early. If it is determined that the risky solution cannot be created in a reasonable period of time, the backup solution replaces the risky solution. If the more challenging code can be implemented in a reasonable amount of time, it is left in the game.    

    

Creation and Documentation of Art Assets   

Tools: Scene description form and object creation form.   

Purpose: To clarify environments and define objects and use this information for scheduling and memory management.   

Frequency: Once at the beginning of the design process. Updates as needed.   

Description: Designer fills out scene form with very general descriptions of the included objects and object definition forms with description of scale, 3D definition, and suggestions for use. In addition, a texture form is needed for each object which includes a description of all involved textures, size of the textures and faces on which the textures should be mapped.   

Typical Scenario: The artist will fill out scene form and include the objects which populate the scene as well as a brief description of the scene. Included in the scene form is a thumbnail sketch of each object and a short text description, including how the object will be used and estimated face count. For each included object, the artist fills out an object form which includes a simple architectural sketch with a simple human form to indicate scale. Also included in the object form is the exact measurements needed for object creation and a short text description of textures to be applied. Finally, the artist attaches a texture catalogue document which describes the textures in detail and the faces they adorn. This catalogue includes a sketch and the suggested resolution of the textures.