Design And Simulation Of Interactive 3D Computer Games pdf

  Technical Section

DESIGN AND SIMULATION OF INTERACTIVE 3D

COMPUTER GAMES

  KAMEN KANEV ¹ { and TOMOYUKI SUGIYAMA ² ₁ Visual Science Laboratory, Inc., Ochanomizu-Kyoun Building, 2-2 Kanda-Surugadai, Chiyoda-ku,

  

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

₂ Digital Hollywood Corp., Ochanomizu-Kyoun Building, 2-2 Kanda-Surugadai, Chiyoda-ku, Tokyo,

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 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).

  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 net- 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-

  Comput. & Graphics, Vol. 22, No. 2±3, pp. 281±300, 1998 # 1998 Elsevier Science Ltd. All rights reserved Printed in Great Britain 0097-8493/98 $19.00 + 0.00

  PII: S0097-8493(98)00038-7

1. INTRODUCTION

  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 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 simu- 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

  K. Kanev and T. Sugiyama 282

2. GAME DESIGN AND SIMULATION STAGES

  We would like to secure a high level of re-use of these simulation components in the latter platform speci®c game implementation.

  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.

  Design and simulation of interactive 3D computer games 283

  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

  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.

  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.

  VE.

  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

  4. VIRTUAL ENVIRONMENTS AND GAME SIMULATIONS

  IRIS Performer, which is a vehicle to extract maximum performance from the SGI graphics hardware at all levels.

  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.

  VR applications. Convenient graphically-oriented tools and APIs are available including

  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

  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

  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.

  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.

  IMPLICATIONS

  In any case, while direct re-use of code might be limited, modeling and behavior data should be freely accessible and reusable.

  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.

3. SIMULATION COMPUTER PLATFORM AND ITS

  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 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-

  K. Kanev and T. Sugiyama 284 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 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 current 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-

  Design and simulation of interactive 3D computer games 285

  286 K. Kanev and T. Sugiyama

Fig. 1. Internal organization of the game client application.

  built, either when geometry data is brought in or recorder/player which can record or disburse pre- when reassembled later. recorded sequences on demand.

  The game user interface application (Fig. 3) is re- sponsible for collecting and processing the players

  5.2. The GDS software components motion data which is then put on the network.

  As mentioned before, GDS consists of a number Game clients and game servers use the players of tasks executed in parallel and communicating motion data provided by this interface task. through the network. While all of the tasks could

  Alternative input streams from joysticks and game be executed on a single, powerful enough computer console controllers are also supported. system, it would be more practical to distribute

  The sound server application (Fig. 4) plays pre- them over several workstations. The types of tasks recorded sound ®les on demand. Its functionality is currently included in the GDS are game clients, described in more detail in Section 6.3. game servers , game interfaces, control interfaces and

  The simulation control interface is used for con- sound servers . Each such task is a separate appli- trolling the entire simulation. It is implemented as a cation which is replicated and executed on all or menu script with several underlying executables and some of the networked hosts participating in the other scripts. game simulation.

  The game client application (Fig. 1) is responsible for maintaining an internal game world model and

  6. PILOT IMPLEMENTATION OF THE GDS

  visualizing it with respect to speci®ed views. Both independent and player-related views are supported. The client application also maintains local and

  6.1. Game world prototyping remote entities.

  6.1.1. Components. At the general game design The game server application (Fig. 2) is responsible stage, we are interested in an approximation of the for tracking the player-related views and guiding game world as envisaged by its creator. This should the clients to modify their internal game worlds be done at the lowest acceptable resolution so that 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.

  Design and simulation of interactive 3D computer games 287 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 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

Fig. 4. Internal organization of the sound server application.

  K. Kanev and T. Sugiyama 288 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. 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

  Fig. 5. Game world descriptions, views and underlying data structures.

  Design and simulation of interactive 3D computer games 289 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 interactions. 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-

  . 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

  K. Kanev and T. Sugiyama 290 Ecient description of complex object behaviors might be greatly facilitated if we could identify some simple actions and determine general patterns for building more complex behaviors from them. Basically behaviors of active objects can be divided into two independent categories, namely initial behaviors and action behaviors. Initial behavior is an object behavior which takes place at the section initialization stage. More precisely, when a section is added to the current view or, say, is about to be entered by the player, the initial behavior scripts for all objects in that section will be executed. The object action behavior in contrast is triggered on a proximity basis or by sending messages. When sec- tions are dropped from the current view, we might need to execute some maintenance scripts, but at this time we do not treat them as describing object behaviors.

  Some examples of initial object behaviors that we believe to be suitable for general game simulations follow. Object behaviors in the gaming world might be independent or linked to the position of the player. Maybe the simplest case would be a ®xed position object that is placed somewhere within the currently activated section. The object would not move, although it may spin, change its shape, color etc. Depending on the object, the player may have to hit it and get a reward or may have to avoid it, otherwise risking a penalty. A moving object might be initially placed close to the player and then start moving away from him. Such a behavior could prompt the player to chase it in order to get points etc. (Fig. 14). Alternatively an object could be in- itially placed somewhere far from the player and then start approaching (Fig. 13). Depending on the object, this would prompt the player to try to escape a direct hit, to wait for such a hit or to hurry to hit the object as soon as possible. A mov- ing object could also follow a predetermined path which does not fall in the previous two categories. When combined with carefully chosen timing and other parameters, initial object behaviors of the above described types could signi®cantly enhance the gaming experience. For example, active objects may be set up to disappear after a given time inter- val elapses. This way, delayed player reactions would result in losing chances to collect points etc. Objects incurring a penalty when being hit may e€ectively act as obstacles in narrow passages thus slowing the player down and making him wait until objects move or disappear (Fig. 15).

  Similarly to the initial behaviors objects could be also assigned action behaviors which take place when an object is activated. In contrast to the single initial behavior, each object could have more than one action behavior associated with it. Here we will discuss some examples of possible action behaviors. Quite often, small prizes like coins, ¯owers etc. are scattered around in the game world and the player behavior of such objects when picked up or just approached is to disappear. Such a behavior could be implemented by a regular object action script containing an instant object position change e.g. a jump to a distant place, unreachable by the player. Alternatively the new object position could be elected to be in the vicinity of the player. If it lies on the player's projected movement path, he will have a chance to get more and more points. Depending on the speci®c positioning algorithm, the object might prompt not only for forward, but also for backward, movements of the player, thus e€ectively slowing down the pace of the game (Fig. 16). Generic object behaviors could also be based on simple Newtonian object models repre- senting kicking a ball (Fig. 13) or escaping from cannon-®re. Object behaviors could be further diversi®ed by introducing pseudo-random par- ameters that control the ultimate displacements, directions, velocities etc. This will ensure that the player never knows what is to happen next time he faces the object. It is also a game design choice if objects should interact or not with the other parts of the model. For example, a ball may be permitted or not to go through the walls in the model.