Design and simulation of interactive 3d computer games

Discovering new game ideas and their further development, game world and characters design and modeling, game evaluation and test-ingÐall these are conducted by specialists teamed to wor

Technical Section DESIGN AND SIMULATION OF INTERACTIVE 3D

COMPUTER GAMES KAMEN KANEV1{ and TOMOYUKI SUGIYAMA2

Tokyo, 101 Japan, e-mail: kanev@vsl.co.jp

101 Japan, e-mail: tomo@dhw.co.jp AbstractÐDesign and development of attractive and competitive computer games is no longer a one-man task, but a complex multistage process with one-many participants Discovering new game ideas and their further development, game world and characters design and modeling, game evaluation and test-ingÐall these are conducted by specialists teamed to work together In this paper we discuss tools and facilities supporting the collaborative game design and development process through rapid prototyping and simulation of 3D game worlds, characters, behaviors and other game functionality Single player and multi-player games are addressed in the context of di€erent hardware platforms and software approaches We report our experience in building a Game Design and Simulation testbed environment (GDS) and its usage in location-based entertainment projects Work on GDS has been carried out in the scope of the VirtuaFly project and during the development of the physical motion based commer-cial game VirtuaFly2 # 1998 Elsevier Science Ltd All rights reserved.

Key words: computer game simulations, (VR) virtual reality games, 3D shared game worlds, networked virtual environments (VE), distributed interactive simulation (DIS).

1 INTRODUCTION

Dedicated game hardware, being crafted for playing

games and not for software development, o€ers

very little to facilitate game prototyping,

presen-tation, redesign, testing and gathering experimental

data On the other hand, computer game developers

have always been striving to push the available

game hardware to the limits of its sustainable

per-formance Specialized game development toolkits

and dedicated software and hardware environments

have been utilized for achieving this goal Most of

such available facilities are platform dependent,

but, while very useful at the game implementation

stage, usually o€er little help at the game design

and prototyping stages In contrast, higher level

tools which are good for game design and

prototyp-ing tend to be more platform independent, but with

limited real-time performance

In this work we discuss a game design and

simu-lation testbed environment (GDS) for supporting

3D game design, prototyping and evaluation It

could be used for game prototyping and evaluation

of design ideas for a wide range of computer

games, including single player, multiplayer and

net-worked games We are aiming to facilitate game

de-sign and evaluation not only for dedicated

platforms such as game consoles but also for

per-sonal computers and other general purpose compu-ter systems To ensure adequate game simulation and real-time performance over a wide range of platforms, we need a scalable software which would allow us to bring in as much computing and visual-ization power as needed Design and simulation of games with low computing and/or graphics demands should be possible on a€ordable, low range general purpose computer systems For more demanding game simulations, more powerful com-puter systems would be needed, such as those with multiple CPUs and graphics engines The game simulation software should be capable of making ecient use of both: limited resources of low end computer systems and full computing and graphics power of high end multiprocessor systems

Another important and highly desirable feature is ecient handling and simulation of multiplayer worked games To some extent, multiplayer net-worked games could be simulated on a single, suciently powerful general purpose computer graphics system Such an approach though has many limitations and could hardly compete with networked distributed simulations largely available nowadays Therefore, distributed networking capa-bilities should be incorporated in the game design and simulation testbed environment That should make distributing the simulation computation and visualization tasks on multiple networked compu-ters possible whenever desirable

Printed in Great Britain 0097-8493/98 $19.00 + 0.00

PII: S0097-8493(98)00038-7

{ Corresponding author.

281

2 GAME DESIGN AND SIMULATION STAGES

The game design and simulation environment is

intended to be used throughout the entire game

development process: general game design, game

world and character modeling, game functionality

implementation, game evaluation and gathering

ex-perimental information, and ®nal game

implemen-tation Specialists with di€erent pro®les are

involved in each of the above game development

stages and GDS should provide appropriate,

dis-tinct services to all of them

2.1 General game design

When new games are conceived designers need to

evaluate their ideas Problems of novelty,

orig-inality, public acceptance, feasibility,

implementabil-ity and performance, etc require careful

consideration The creative process could greatly

bene®t if game design ideas are shared and widely

discussed Unfortunately new game concepts are

very dicult to communicate Writing, talking,

using drawings and even animation helps but does

not completely overcome the communication gaps

The most that we could hope to convey by such

traditional means would be a bleak impression of

the newly conceived game Moreover, it is quite

im-possible to experience the excitement that the game

would bring without adequate game simulation

fa-cilities Game designers would like to be able to see

and feel their ideas working at a very early stage,

before the actual game implementation has even

begun At the game design stage, the way the game

feels is much more important than the speci®c

details in the underlying graphics or game character

behaviors The latter two could be simulated in a

quite general way while still conveying the genuine

feeling of the game

2.2 Game world and character modeling

In contrast to game designers, graphics designers

are much more concerned with the models of the

game world and the game characters rather than

with the way the game feels when played

Nowadays game world models are signi®cantly

large and adequate facilities for model partitioning

and concurrent modeling and design are essential

Often, many graphics designers contribute to the

same game, designing di€erent parts of the game

model, sometimes taking over and continuing each

other's work When graphics designers are working

on partitions of a given game world, they would

like to be able to see how their work would

inte-grate with that of their colleagues This means that

the game world should be properly structured for

easy integration and interchange of partitions Such

a structuring would also facilitate reusability of

models and partitions In fact the structuring of the

game world is more a game design decision than a

graphics design one Therefore, an appropriate

game world structuring scheme should be adopted

at the game design stage and then re®ned during the graphics design stage This will enable graphics designers to plug in and see re®ned partitions in the context of the general game world testbed model whenever desired

2.3 Game functionality implementation Another important computer game component is the story and all functionality associated with it This includes game characters and their behaviors, game rules and objectives, etc There are generic types of functionality such as Newtonian objects, point awarding facilities, character controls, etc which could be used in many di€erent game lations Other, speci®c functionality might be simu-lated through some of the available generic types, while more peculiar functionality might need dedi-cated implementation We would like to keep the character behaviors separate from their graphics representations whenever possible That would give

us more freedom to manipulate character appear-ances and their behaviors independently, and even-tually to build up new characters on the ¯y Game developers could implement speci®c game function-ality in the context of the generic game design model, which could be upgraded with re®ned game partitions and character models as they become available Game functionality and game character behaviors could be expressed in terms of actions, simple responses to stimulus and more complex behaviors While dealing with such functionality, general facilities such as multichannel record and play, interpolation and extrapolation etc should also be provided

2.4 Game evaluation and gathering experimental in-formation

Adequate game simulation is important for gath-ering experimental information and successful evaluation of game ideas The previous stages as discussed would help set up an appropriate environ-ment for this simulation stage We are dealing here with an environment approximating and simulating the real game appearance, performance etc The main objective is to let third parties, including po-tential customers, experience the new game ideas in conditions close to a real game play, so that we could gather extensive feedback information During the simulation, facilities to simulate di€erent conditions by changing parts of the game world, replacing game characters and modifying their behaviors, revoking and introducing new game rules, etc will be necessary along with extensive log-ging and analysis options

2.5 Platform speci®c game implementation Some features of the target game world, charac-ters and functionality have to be implemented in the process of building the game evaluation model

We would like to secure a high level of re-use of

these simulation components in the latter platform

speci®c game implementation

First comes the re-use of the world model and

character geometry data To provide ecient use of

the resources of the target game hardware,

geome-try data would need to be converted to appropriate

platform related formats Stand-alone tools should

be used for such conversions

Second comes the re-use of character behaviors

and game functionality Most of the simulated

behaviors and other functionality could be

im-plemented as scripts, with the most complex ones

eventually directly coded Since scripts are generally

platform independent they might be interpreted on

the target game platform too Directly coded

func-tionality would certainly need some platform

speci®c rewriting and adjustments

In any case, while direct re-use of code might be

limited, modeling and behavior data should be

freely accessible and reusable

3 SIMULATION COMPUTER PLATFORM AND ITS

IMPLICATIONS

We would like to achieve real-time performance

of our interactive 3D game simulations It should

be comparable to what we would get from the real

game say running on a dedicated game console with

optimized software and well-tuned geometry

data-base Yet we would like to postpone developing

tar-get platform speci®c software and model tuning

until after the game simulation and evaluation is

complete To achieve this we would most probably

need to bring in more computing and visualization

power than that of the target implementation

plat-form Recent models of Sony PlayStation, Sega,

Nintendo64 are delivering a level of performance at

which no PC-based real-time simulation seems to

be feasible Therefore, considering these game

con-soles as potential targets, we elected to run our

simulations on suciently powerful workstations

with adequate graphics capabilities

While high grade workstations with advanced

graphics capabilities are nowadays available from

many di€erent vendors we have chosen the Silicon

Graphics, Inc line of products, mainly for reasons

of previous in house experience The base of SGI

machines currently installed at our sites is quite

extensive and immediately available There are also

several classrooms equipped with networked SGI

workstations that could be used for multiplayer

game simulations and evaluations Apart from this,

the SGI line of products o€ers a range of speci®c

features that are highly desirable for our GDS

SGI o€ers low range systems like Indy and O2,

going through mid-range like Indigo Impact and

Octane and extending to the high range Onyx2 and

Origin product line Recent models are based on

Uni®ed Memory Architecture (UMA) and Scalable

Shared-memory Multi-Processing (S2MP) architec-ture thus overcoming performance bottlenecks and opening new dimensions for scalability With the combined strength of the Cray and Silicon Graphics technologies the new line of products demonstrates unsurpassed performance SGI sys-tems are executable compatible thus ensuring easy software migration SGI IRIX operating system comes with many additional features as compared

to other UNIX distributions Networked SGI work-stations support multicast as a standard feature and provide a very good environment for distributed

VR applications Convenient graphically-oriented tools and APIs are available including IRIS Performer, which is a vehicle to extract maximum performance from the SGI graphics hardware at all levels

We are also considering bringing systems from other vendors within the scope of our simulations Di€erent approaches for platform independent net-worked simulation and visualization are addressed later in the text

4 VIRTUAL ENVIRONMENTS AND GAME SIMULATIONS

The notion of virtual environment (VE) is often used to denote the speci®c software architecture and the underlying data models used in virtual rea-lity applications [1, 2] In the computer game simu-lations, VE refers to the game world and character models, and the game simulation software architec-ture Networked game simulations incorporate ad-ditional communication model components of the VE

A presentation and discussion of di€erent VE models and their components follow In this discus-sion we will pay special attention to the communi-cation components since they often play crucial role

in shaping the entire simulation environment 4.1 VE data models

Appropriate structuring of the game VE has always played an important role in the game design and development process One classic way of impos-ing a structure over a particular game is to divide it into stages This provides a means to organize the game world, game characters, their behaviors and other functionality in separate groups associated with each stage and to treat them more or less inde-pendently Unfortunately, if no spatial relations exist between the game stages, the feeling of game continuity is easily lost in the game stage tran-sitions

Game stages have been successfully used to enhance the game performance on low-grade com-puter platforms which are not able to process large graphical databases in real-time To achieve this, data is loaded and interpreted on a stage-by-stage basis while text, music and simple animation is

being presented during the stage changes to hide

the loading and initialization delays

For more powerful game hardware, the general

tendency seems to be a rather complex graphical

en-vironment to be selected and then loaded before the

game begins Then, even if game stages are present

the game would still be played in that preloaded,

and thus predetermined, environment Nevertheless,

depending on the player's actions, some games may

load di€erent graphical models during the play and

switch between, say, exterior/interior world,

under-water world etc In most cases that could be done

in the background while the game play still

con-tinues Also spatial relationships play more

import-ant role on advanced game platforms as compared

to the low grade ones

Another level of complexity arises in the

net-worked multiplayer games where players share a

simulated virtual game world by using many

net-worked computers Most game implementations

assume that each player has a copy of the complete

game database on his own computer In the course

of the game, state changes of di€erent entities are

communicated between the players' computers in

order to keep the game VE synchronized

As envisaged, our game simulations might be

per-formed either on a single computer system or on

several networked computer systems We would like

to adopt a VE structuring scheme which would be

equally applicable in both cases In a broader

con-text, di€erent structuring approaches and data

models pertinent to VE have been explored recently

Most prevalent models could be classi®ed as

repli-cated homogenous, shared centralized and shared

distributed peer-to-peer or client±server [2]

The large scale, mainly military related

simu-lations have been adhering to the replicated

hom-ogenous model [2, 3] Providing a local copy of a

large homogenous virtual world database to all the

participants before the simulation starts saves a lot

of network trac latter, since during the simulation

only changes in object states would need to be

com-municated [1] Nevertheless, as complexity and size

of virtual worlds grow, it becomes next to

imposs-ible to maintain local copies at every participating

host Attempts to decrease the trac through

grouping of entities and mobile agents have been

reported in [4±6] Further complications arise with

the increase of discrepancies between the local

world representations over the simulation time

incurred by loss of messages This happens because

replicated homogenous models are usually based on

best-e€ort, non-reliable message delivery protocols

While ensuring better scalability in comparison to

other reliable network protocols [7±9], there is a

clear tradeo€ in regards to replicated database

syn-chronization

Shared centralized models rely on a specialized

server computer which is solely responsible for

maintaining the entire world state and

communicat-ing it to all of the participants as needed The model is simple and easy for implementation and maintenance but has some important limitations First, it does not scale well since all the trac goes through a single server node [1, 10] A second pro-blem is the additional delay that rerouting through

a server would incur as compared to peer-to-peer multicast and broadcast [3]

Despite their limitations, shared centralized models have been widely used in the gaming com-munity Apart from the many MUDs, MOOs, enhanced chatrooms etc., many highly specialized game servers are currently in operation The shared centralized model evolves to new realms as more computing and graphics power becomes largely accessible with the recent Pentium based PC models For example, Ultima on Line, although making use of an underlying centralized data model and a specialized game server, adopted distribution

of the initial generic world and character game database through a retail channel on a CD-ROM Recently, more and more attention has been paid

to distributed models and new mixed approaches The central problem pertinent to the distributed models is ensuring database consistency and syn-chronization Attempts have been made to address the problem by using reliable message delivery pro-tocols [11] Unfortunately, maintaining reliability and consistency incurred signi®cant communication costs and the DIVE system [11] could support very limited number of simultaneous users The Virtual Society Project [9, 10, 12] adopts some ideas from DIVE and attacks the scaling problems by reducing the level of data sharing so that consistency and synchronization protocols would not need to work across the entire system In the VS project, the notion of aura [13] is used which represents a dynamic portion of the virtual space, say a region

of interest Objects can register their auras with an aura manager in order to be noti®ed when other objects enter their region of interest The aura man-ager tracks database partitions, controls spatial in-teractions and maintains di€erent levels of consistency Its functions are based on the caching

of static and some dynamic data, combined with non-reliable, locally ordered and globally ordered reliable message delivery mechanisms A further drop in the network bandwidth is achieved through generalized dead-reckoning techniques, called move-ment behavior [9]

At the Swiss Federal Institute of Technology and University of Geneva, VLNET [14, 15] has been developed The VR world is distributed on several VLNET servers which maintain a constant link between themselves Each server acts as a shared centralized server for all the clients directly con-nected to it But clients are permitted to migrate from server to server which means that users could freely move through the entire VR world A special-ized motor function is suggested, which when

acti-vated would carry out the transition from the

cur-rent server to the new one A similar idea for

tran-sition between di€erent worlds is exploited in

MASSIVE (Model Architecture and System for

Spatial Interaction in Virtual Environments) [16]

MASSIVE also uses aura much alike the Virtual

Society project [9, 10, 12]

At the Stanford Distributed Systems Group, the

PARADISE Project is under development Within

its scope, work is done on reliable logging and

mul-ticast channel directory service [8], advanced entity

aggregation dead reckoning [5, 17] and

object-oriented RPC [18] Another large scale project,

GreenSpace [19], is engaged in developing a new

global communications and information

environ-ment for the 21st century The prototype GSnet

supports networked communications and shared

database among distributed applications

GreenSpace world consists of internal and external

parts, the latter managed by external video, audio

and reliable multicast protocols The internal parts

are managed by a special application called

``Mr.N'' which is responsible for the networked

database synchronization The GreenSpace world

database is based on groups which are represented

as collections of chunks

All the approaches that we have discussed so far

establish some database model which is

sub-sequently used for producing views into the virtual

world An approach which ®rst assumes a view and

then generates a model, only sucient for that view

is described in [20, 21] This approach uses Entity

State Estimator and Network Link processes and

potentially reduces the network load while

provid-ing di€erent levels of resolution

4.2 VE software architecture

Bringing more computing power into the

simu-lation by assigning part of the computations to

some other hosts on the network is obviously less

costly than upgrading to a single, more powerful

computer To potentially facilitate such load

distri-bution, we design our GDS as a set of separate

con-currently executable tasks The intertask

communications could go through network

chan-nels, thus allowing the tasks to be spread over

di€erent workstations connected to a high-speed

LAN

Another level of complexity lies in using a

hetero-geneous, multiplatform computing environment A

widely exploited approach enabling multiplatform

hosts to participate in the same simulation is to run

dedicated, platform dependent simulation software

on each of them For example, in DIS based

simu-lations [1], each host runs its own variant of the

simulation software but with common algorithms

Other promising approaches use platform

indepen-dent scripting languages such as Telescript, Tcl,

Java and JavaScript, etc Mobile Agents and Smart

Networks have been suggested as a method to

enhance DIS simulators [4] The VR-protocol [22] from MAK Technologies provides for platform independent program execution environment and dynamic linking

A new generation of software technology is emer-ging with High Level Architecture (HLA) There is

a hope that HLA would help products from di€er-ent vendors evolve as fully interoperable over the network In Gustavson [23] the Microsoft's multi-player gaming solution for Windows 95/NT DirectPlay is evaluated in the context of HLA Similarly, features of HLA that support the VR-Protocol, as well as complimentary capabilities that VR-Protocol could provide to HLA, are discussed

in Taylor [22]

5 THE GDS AND ITS VE MODEL

5.1 The GDS data model The target environment for GDS is a high speed LAN where we could expect predictable network performance This allows us to focus on game simu-lation problems, rather than to deal with the pro-blems of reliable data distribution and synchronization over large WANs We assume that all the initial geometry data representing the game world and the game characters resides somewhere

on the LAN It can be provided in a number of

®les on di€erent network nodes which are accessed

by the simulation tasks whenever necessary Standard facilities like NFS, HTTP, etc could be used to ensure such an access over the LAN

An internal representation of the game world and the game characters is built by each simulation task from the available on the LAN geometric data Such internal representation is later used for visual-ization of the game world with respect to the di€er-ent aspects of the the currdi€er-ent simulation Many simulation tasks might run in parallel say, each ser-vicing di€erent participants in the game or provid-ing di€erent views in the game world etc Obviously, the internal representations of the game world for all these tasks need not be the same In fact, as in Michael and Brock [20, 21], if a view in the VR world is assumed ®rst, then we only need to build an internal world representation satisfactory for that particular view In GDS we adopt a dynamic internal game world data model which supports similar functionality

The support of multiple internal game world rep-resentations is also in line with the potential di€er-ence in the computing and graphics power of the workstations hosting each simulation This way, we could support internal world models at di€erent res-olutions adjustable to the hosting workstation per-formance level Resolution here refers to the levels

of detail or granularity at which the internal rep-resentation should be maintained Resolution par-ameters could control the way internal model is

built, either when geometry data is brought in or

when reassembled later

5.2 The GDS software components

As mentioned before, GDS consists of a number

of tasks executed in parallel and communicating

through the network While all of the tasks could

be executed on a single, powerful enough computer

system, it would be more practical to distribute

them over several workstations The types of tasks

currently included in the GDS are game clients,

game servers, game interfaces, control interfaces and

sound servers Each such task is a separate

appli-cation which is replicated and executed on all or

some of the networked hosts participating in the

game simulation

The game client application (Fig 1) is responsible

for maintaining an internal game world model and

visualizing it with respect to speci®ed views Both

independent and player-related views are supported

The client application also maintains local and

remote entities

The game server application (Fig 2) is responsible

for tracking the player-related views and guiding

the clients to modify their internal game worlds

appropriately It also functions as a multichannel

recorder/player which can record or disburse pre-recorded sequences on demand

The game user interface application (Fig 3) is re-sponsible for collecting and processing the players motion data which is then put on the network Game clients and game servers use the players motion data provided by this interface task Alternative input streams from joysticks and game console controllers are also supported

The sound server application (Fig 4) plays pre-recorded sound ®les on demand Its functionality is described in more detail in Section 6.3

The simulation control interface is used for con-trolling the entire simulation It is implemented as a menu script with several underlying executables and other scripts

6 PILOT IMPLEMENTATION OF THE GDS

6.1 Game world prototyping 6.1.1 Components At the general game design stage, we are interested in an approximation of the game world as envisaged by its creator This should

be done at the lowest acceptable resolution so that time and e€ort would be saved As our vision of

Fig 1 Internal organization of the game client application.

the game evolves in the course of the game

develop-ment and simulation, we will gradually move to

higher resolution models We would like to convey

the right feeling of space and distance through the

simplest possible geometry with appropriate texture

For example at the lowest level of resolution the

game world could be represented as a texture

mapped extruded shape with the view point placed

close to its center line Appropriate scaling and

tex-turing could make it look either as a narrow tunnel

or as a wide open space For example, in Fig 10,

both the far fog and the sky are represented by

tex-tures mapped on the surrounding extruded shape

Acceptable appearance could be maintained as long

as the view point is suciently far from the texture

mapped walls and remains relatively static The

di€erence between entirely texture mapped and

sculptured walls can be seen by comparing the

images in Fig 8 and Fig 9 The simplicity of the

tunnel model in Fig 8 becomes more apparent

when seen in stereo or from a viewpoint moving in

the vicinity of the walls Better appearance is

achieved by introducing models at higher levels of

resolution One possible way is by re-texturing low-resolution models and adding more geometry In terms of the simple textured extruded shape, this means that some of the objects initially painted on the walls would be established as true geometric entities inside it The resulting higher resolution models approximate the envisaged game world more closely There are standard ways for dealing with resolution adjustments, for example by using LOD [24] In our approach, we chose to handle this

in a di€erent way in order to support the dynamic assembly of internal world models, rather than just di€erent views in a preloaded database In the ®nal game, we may seek true realism and thus we may need sophisticated geometry and LOD For the simulation itself though, less should be sucient since we only need to build a convincing impression

of the simulated game

The dynamic world models are based on atomic objects organized in sections (Fig 5) All simple artefacts which expose no internal structure related

to the game simulation should be considered atomic objects Sections are structural objects which may

Fig 2 Internal organization of the game server applications.

Fig 3 Game user interface for the players.

have geometry and other attributes and can be used

as containers for any number of atomic objects or

sections For example, rooms in a building could be

represented as separate sections while furniture in

the rooms could be considered as atomic objects

Similarly, simple game worlds could be constructed

from sections representing rooms and connecting

corridors

By structuring the game world into sections we

e€ectively introduce levels of hierarchy which can

be kept separate from the actual geometry Then, a

preliminary culling could be done to identify the

sections relevant to a particular view and maintain

a database associated with it It is important to

point out that the structuring into sections does not

have to be spatially related Of course, in most

practical cases spatial organization of sections may

be a good choice But many games nowadays,

although being played in a 3D world, could be rep-resented by one or two dimensional sequences of sections We discuss our experiments with such game worlds late in this paper Nevertheless the world descriptions that we use are more general and allow us to associate lists of sections with n-dimensional coordinate values This way in the one dimensional case one coordinate is used for posi-tioning in the game world while others could be treated as describing section properties, etc Sections may be adjacent so that players could phy-sically move between them But sections may also overlap or contain each other, for example when representing di€erent levels of resolution

The internal game world representation is built

by selecting appropriate elements from the world description This process is controlled by a metric

in n-dimensional space and may be considered as a

Fig 4 Internal organization of the sound server application.

combination of priority ordering and culling which

takes place in the gameserver task This gameserver

(Fig 2) tracks a view, refers to the game world

description and produces a list of sections (Fig 5)

Then, an internal game world representation is built

on the basis of this view by the client application

(Fig 1) Many views can be supported

simul-taneously

In our model, the global game world description

is kept separate from the actual geometry Thus the

game world could be reshaped by changing the

world description ®les which have to be kept

syn-chronized at all the simulation hosts Also this

makes rapid prototyping and reuse of model data

easier as di€erent world descriptions could refer to

the same geometry entities

6.1.2 Importing Game worlds are usually

con-structed using geometric modelers This is an

inter-active process in which designers create and modify

complex geometric shapes Unfortunately the

result-ing geometry could hardly be modi®ed and

restruc-tured outside of the modeling software used to

create it Alternatively, a procedural approach

could be used for creating geometry with minimal

human assistance The problem is that arbitrary

shaped objects are dicult to parametrize using

such a procedural approach

In our approach for the construction of game

worlds we are bringing together the interactive and

procedural ways of construction by interactive

de-sign of components and procedural assembly of

these components into sections In order to

facili-tate approximate representation of game worlds, we

are investigating intermediate levels of complexity

It appears to be advantageous to provide

pro-cedural ways of generating such intermediate com-plexity geometry and still use advanced modelers when needed Procedural modeling could quickly provide a crude substitute for the simulated game world which could be used as an initial testbed Then, more re®ned geometry prepared by human designers is gradually integrated Another reason for adopting such an approach is the fact that sur-prisingly few of the current VR modelers o€er auto-matic LOD generation [24] And when it is done, general polygon reduction algorithms are usually applied o€-line This means that simpler models are generated on the basis of reducing the geometrical complexity of detailed models In contrast, we incrementally build more and more detailed world models at run time

To achieve this, we need full access to the under-lying data structures Since we use the SGI Performer for our simulations we need to access its internal geometry data representations As in most modern visualization systems, the graphical data in Performer is organized as a tree structure contain-ing graphics state information and geometry infor-mation Specialized node types for grouping and geometry, for transformations, level of detail, ani-mation and morphing etc are supported

The task of importing VR world data into Performer consists of building an appropriate tree structure from what is provided in a given graphics

®le This data conversion process is called importing and the software responsible for it is called impor-ter Currently, Performer comes with more than 30 standard importers, most of them provided by geo-metric modeler suppliers The diculty which arises

is in combined use of such models and modelers Although the importers e€ectively convert di€erent graphics ®les into a common internal Performer data structure they do not provide means to inte-grate and blend such structures One solution is to

do the integration by writing speci®c application code and including it into the target Performer ap-plication This is obviously not suitable for our simulations, as we would like to minimize the need for customizing the application code Therefore, we decided to develop some standard integration func-tions and make them available to all performer ap-plications through some standard mechanism We opted to implement these functions as shared objects (DSO) so that they could be accessed by the applications only when needed at run time with no overhead if not accessed Basic or standard inte-gration functions are dicult to identify and in fact would vary depending on the application That is why we decided to de®ne our basic functions not

on the basis of the application needs, but on the basis on the underlying Performer data structures

As all the graphics data is ®nally converted into a tree built from Performer nodes, we developed a generic way of building such trees on a node by node basis Building such internal structures in fact

Fig 5 Game world descriptions, views and underlying

data structures.

becomes part of the support for our dynamic

in-ternal data model Yet the data importing is not

part of the game simulation application because it

is provided as shared data objects and thus could

be dynamically changed during the simulation

Di€erent DSO objects could build internal game

world representations at di€erent resolutions while

still using the same data ®les

The basic importers that we have developed

cor-respond roughly to the types of nodes supported by

SGI Performer and exhibit common general

func-tionality First, when a ®le name with model data is

supplied, it is analyzed and, depending on its

exten-sion, appropriate DSO is loaded and initialized by

the operating system Then, this DSO is executed

with the content of the ®le being supplied as input

data The new importers parse this input for valid

tokens and interpret them while treating everything

else as comments or ®le references in a uniform

way This is a recursive parsing which produces

data structures of arbitrary complexity and depth

while keeping the parsing and interpretation of

indi-vidual ®les quite simple The basic importers

pro-vide for building of internal game world

representations possibly at di€erent resolutions

from predesigned objects But to generate actual

geometry other types of nodes are needed In

Performer, this is done by geode nodes and they

have to be used when geometry data ®les are

loaded We would also like to have specialized

geo-metry nodes to represent di€erent types of

geome-try

We consider the conformance with the defacto

and emerging standards as one of the priorities of

our application The VRML97 proposal for ISO

standard deserves a special mention in this context

VRML1.0 emerged from the SGI OpenInventor

ASCII format In VRML 2.0 or VRML97

import-ant new features have been included in order to

bet-ter support dynamic geometry and inbet-teractions

With the MovingWorlds this is carried further

toward multi-user networked environments The

nodes that we discussed so far could be directly

handled in a VRML 2.0 compliant application We

also experimented with building structures similar

to those supported by the VRML 2.0 extrusion

node which has no analog in Performer

For example in our implementation, ®lenames

such as 3_1_0.tunnel are handled by a dedicated

DSO importer and tunnel-like extruded geometry is

generated as a result The ability to supply

numeri-cal parameters directly in the ®le name is

intro-duced as a convenience tool for easy generation of

regularly shaped tunnels for test purposes A true

®le would have to be created and its content

pro-vided only if parameters other than those in the ®le

name are required Similarly to the VRML 2.0

extruded node, the tunnel can be de®ned by the

fol-lowing parameters:

a 2D crossSection piecewise linear curve, described as a series of connected vertices; a 3D spine piecewise linear curve, also a series of connected vertices;

list of 2D scale parameters;

list of 3D orientation parameters

This de®nition however is rather restrictive In particular, while the intermediate cross-section orientations and scales could be controlled along the spine, it is not possible to adjust the shape in other ways To produce smooth-looking geometry, additional parameters and more sophisticated calcu-lations than those described in the VRML 2.0

speci-®cation are necessary We support a number of such additional global and per vertex parameters, for example the integer values of the shape per-ver-tex parameter control the wall normals at a given vertex in u and v directions Material handling and texture mapping is also enhanced In addition to the automatic generation of texture coordinates as for the VRML 2.0 extrusions, other texture map-pings can be directly speci®ed That makes easier to produce outlooks as in Figs 8, 14 and 15, etc where walls, the ¯oor and the ceiling are mapped with di€erent textures

We also provide a set of ®tting algorithms as alternatives for direct supply of cross-section orien-tations and scales With no speci®c algorithm how-ever, the selected extrusions are generated much in the same way as prescribed in the VRML 2.0

speci-®cation Other VRML 2.0 compliant node types are also under implementation In particular, more in-formation about the sound node type is given in Section 6.3

6.2 Active objects Object behaviors in our implementation are sup-ported by scripts of actions that must be performed over a given time interval Although we support features functionally similar to the event-processing mechanisms as described in the VRML 2.0 speci®-cation, full conformance is beyond the scope of our current implementation

We use the term active object to refer to objects which could be controlled by scripts The lowest level of control is by direct manipulation of object's attributes such as position, orientation, etc This is done by assigning new values to the appropriate nodes in the objects Performer tree At the next level, time dependent parameters such as velocities, accelerations, forces etc could be speci®ed which determine the object behavior These parameters depend on the underlying simulation model Object attributes and simulation parameter changes, when done in a script, are not an instant, but rather a continuous, process Scripts are executed by the gameserver application (Fig 2) and can contain branches and repetitions Scripts could be envisaged

as descriptions of high level object behaviors