Gaming and HLA 1516 Interoperability within the Swedish ... - CiteSeerX

4 downloads 329917 Views 90KB Size Report
game network. ▫. Client-Server. In this case one node acts as a server. It can either be a dedicated server or a participating machine. This type of setup usually.
Gaming and HLA 1516 Interoperability within the Swedish Defense Björn Möller Björn Löfstrand Pitch Technologies Linköping, Sweden +46 (0)13 13 45 45 [email protected], [email protected] Jouni Lindqvist Calisto Data AB Stockholm, Sweden +46 (0)8 459 58 8 [email protected]

Adam Backlund Björn Waller Swedish Air Force Combat Simulation Center (FLSC) Swedish Defence Research Agency (FOI) Stockholm, Sweden +46 (0)8 555 030 00 [email protected], [email protected] Robert Virding Swedish Defence Materiel Administration (FMV) Stockholm, Sweden +46 (0)8 782 40 00 [email protected]

Keywords: HLA, IEEE 1516, Computer Games, Gaming, Flight simulator ABSTRACT: Today’s commercial gaming industry offers a wide range of defense related titles targeted at a consumer mass-market. Several organizations within the Swedish defense have recently studied the opportunities for reusing them in a defense M&S context. Although the technical functionality found in commercial games are already available in high-end defense simulators the price/performance is drastically better and the hardware requirements are usually lower. Using commercial game technologies may at first seem to bring new possibilities to the M&S domain but further studies reveal both potentials and limitations. Several of the limitations are caused by differences in business model between game publishers and the defense M&S business. In many cases true interoperability between different games is not necessarily in the interest of game publishers or even gamers. In this paper experiences from using games in defense M&S are presented from the perspective of two Swedish organizations: At GameStudio at the Swedish Defense Materiel Administration (FMV) work has been carried out to connect flight simulator games with simulation models using the HLA 1516 standard. Major challenges include problems with temporal/spatial representation and resolution, sharing of algorithms such as dead reckoning and lack of model transparency. An architecture that provides flexibility and extensibility has been designed and implemented. At the Swedish Air Force Air Combat Simulation Center (part of the Swedish Defense Research Agency) flight simulator games with HLA 1516 bridges are used together with state-of-the-art defense flight simulators. Current applications include simulation of air logistics and of airborne radar surveillance for Peace Support Operations. This paper summarizes some practical experiences from making gaming software and defense based HLA 1516 trainers interoperable. It also provides some general observations about the potential of gaming and defense simulation interoperability.

1. Introduction Modeling and simulation has been used for both civilian and defense applications for decades. Starting with SIMNET in the late 1980s, a growing interest for simulation interoperability has been a key issue in the defense M&S domain. The major driving factor has been the requirement for different types of defense units to operate effectively together which in turn requires corresponding simulation capabilities for analysis and training to be able to interoperate. An important goal for defense M&S systems is to be able to produce realistic and operationally valid training experiences or analysis metrics. Defense M&S systems are generally procured by a central organization for use by a limited number of customers. These customers have well-specified operational, functional and technical requirements, including the ability to interoperate with other systems. These M&S systems may have life-cycles of decades and be subject to regular maintenance and upgrades. The commercial computer gaming industry provides products aimed at giving an entertaining experience to the end-user. Defense-related titles are one of the best selling types of games. These titles as sold through consumer mass-market channels where the buyer selects from available titles based on taste and recommendations. The customer has little or no direct influence on the functionality of any specific title. Generally, interoperability other than compatibility with available hardware is not considered by the buyer. Both legal and technical actions are sometimes taken to create customer lock-in. This is especially true for console games. A game title will seldom remain a bestseller for more than a few months. Only a small fraction of the titles reach break-even, however, bestsellers may provide tremendous return on investment. Many nations are now considering using commercial game technology and techniques for defense training and analysis. Greater accessibility and lower cost compared to current defense simulators are some of the expected advantages of using games in defense M&S. 1.1 An overview of gaming technology A game title is a complex product based on several levels of technology as described in Figure 1. Opportunities for reuse in M&S applications exist on all levels.

Modifications & Tools Game Engines Middleware Low-Level APIs Hardware Figure 1: Game Technology

Hardware: This is the most obvious area where the game industry is the driving force. It includes wide aspects of hardware technology ranging from programmable 3D graphics accelerators, audio equipment to PCI architectures, broadband infrastructure and more. API: There are several low level API:s like OpenGL and MS DirectX constantly under development to support gaming and other applications. Middleware: An industry providing game middleware products has evolved. The middleware ranges from physics engines and AI to audio and multiplayer support. The main purpose is to enable game producers to shorten the development time of game titles. Some of the middleware cover several aspects and may almost be considered as a complete game engine. Others have a stronger focus on a specific task, like physics, graphics or networking. Game Engines: The central software component is called the game engine. It handles a number of tasks like 3D graphics rendering, AI, data and object management, UI and networking. Since the late 1990’s there has been a trend to develop reusable game engines separated from the content of the game title. Some game engines only handle 3D graphics rendering and thus are called 3D engines. A large number of game engines are available today [6] [7]. They range from free open source engines to commercial high-end game engines. It is common that a commercial engine can be licensed under different conditions (and corresponding pricing), from linkable binaries with API/SDK to the full source code. Titles: It is usually not possible to reuse a game directly of the shelf for defence M&S purposes. Exceptions may exist when a game has been designed from the start for a specific M&S purpose. Today a branch of game titles aiming towards Serious Gaming

[8] is under strong development. These are games that are designed for use outside the entertainment business. Several game titles have received funding from the US DoD [9]. Some of them have been designed with interoperability in mind from the start. Modifications & Tools – In many cases a game title is shipped with tools and documentation to alter and modify the creative content of the game. The latter can be divided into three parts; art, game level design and scripting. Tools like terrain editors, level editors, API’s, scripting and file conversion tools makes it possible to create new game content. DARWARS Ambush [17] which uses the Operation Flashpoint [18] engine is an example of this. The evolution, development and usage of commercial computer games have increased in the last five years. They may now be considered to be an influencing factor in such different areas as technology skill to social norms and values. This may also affect the M&S domain.

2. Interoperability 2.1 Gaming perspective Extensive interoperability between different computer games is very rare. Interoperability can mainly be found between several instances of the same game, so called multiplayer gaming. Although multiplayer gaming has existed for almost 30 years, starting with text based adventure games like Multi-User-Dungeon (MUD) [1], it was not until the mid 1990’s that it gained commercial momentum, mainly through the popularity of the First-PersonShooter (FPS) [2] genre. Later on the Massively Multiplayer Online (MMO) games have become an important business model which can be expected to push the multiplayer technology further.

ƒ

Within the game industry there is a wide range of products that can be used for adding multiplayer functionality to a game. They range from API’s like Microsoft DirectPlay [12] to complete middleware solutions aiming at different genres like FPS, RTS (Real Time Strategy games) or MMO’s. Since they have been developed with gaming as primary focus they may not fully match the requirements of the defense M&S domain. Some efforts have been made to use DIS or HLA to achieve game titles that are interoperable (Spearhead II[3]). The driving forces behind these efforts are defense users, not the gaming communities or vendors. For various reasons the computer game industry has not been interested in using DIS or HLA as a base for multiplayer games or for adding making interoperability to games. Some reasons are: ƒ

Performance. The type of performance versus realism required differs in many cases. The game developer needs to optimize the application to allow the game to run on as many systems as possible even if they just meet the minimum HW requirements. Realism, validity and accuracy may be traded for an improved game experience.

ƒ

Game play. Game play is a very fine tuned experience. Even within the same genre games may be different enough not too make interoperability interesting or possible to implement.

ƒ

Complexity. Challenges include merging different multiplayer architectures and protocols, sharing virtual environments, terrain fidelity and spatial resolution, persistence, massiveness, shared simulation state with 1:st and 2:nd order events taking place over time etc.

ƒ

Standards. Lack of de-facto standard for interoperability in the game industry.

ƒ

Cheating. In order to achieve full interoperability between games, game producers would need to open up their in-house protocols or use an open standard. This would make it possible to cheat. There is an active sub-culture who primarily seeks to hack games, that is to find out ways to cheat. A reverse engineered or hacked multiplayer protocol would be a disaster for a

There are basically three types of multiplayer game architectures [13]: ƒ

ƒ

Peer-to-peer. This is the simplest form and usually consists of 2-16 players. There are no central components, databases or servers. All data is exchanged directly between the nodes in the game network. Client-Server. In this case one node acts as a server. It can either be a dedicated server or a participating machine. This type of setup usually allows for 16, 32, 64 or even up to 128 players to play against each other and is used extensively in games without persistent worlds.

Client-Server Clusters. This is an advanced infrastructure which allows more than 100000 users to share a persistent common world. The game is hosted by a cluster of game-, databaseand authentication servers. This type of setup is the backbone for MMO games.

ƒ

multiplayer game title since no gamer would trust their opponents to play fair.

ƒ

It is a well known simulator game which has a great impact as a technical demonstrator.

Business model – Multiplayer games have very different business models, most are free, some require a subscription while other games are funded by advertisement.

ƒ

There is a huge community and model-database. There are models for almost every known aircraft in the world as well as detailed terrain for many parts of the world. A long list of utilities, add-ons and stand-alone freeware/shareware applications are also available. Furthermore the community is very active and helpful and willing to share knowledge and know-how.

ƒ

Microsoft has published a well documented multiplayer SDK which makes it possible to create multiplayer add-ons that can co-exist in an FS2002 multiplayer session. This is not common in the computer game industry.

ƒ

There is a range of third-party commercial products for MS FS2002 including display solutions, distributed rendering systems, avionics and instruments and more.

ƒ

The protocol used for interoperability between FS2002 nodes is straightforward and partially resembles RPR-FOM.

From a defense perspective some points needs to be mentioned about the interoperability commonly used in gaming: There is a great deal of experience and lessons learned about scalability in the MMO community. This could be reused in a defense perspective. Gaming interoperability usually trades validity, correctness and repeatability for an improved gaming experience. This may seriously limit the reuse of gaming technology for defense purposes. There is no major driving factor for developing interoperability between different implementations within the same domain not to speak of interoperability between games from different domains. This means that important issues like semantic and substantive interoperability have not yet been experienced to the full degree.

3. Practical Experiences – GameStudio FMV:GameStudio is an initiative by the Swedish Defence Materiel Administration (FMV), funded by the Swedish Armed Forces, to bridge the gap between computer gaming and defense. GameStudio is a three year program to study gaming and the use of computer games as well as technology. Further collaboration with the Swedish National Defence College (FHS) and the Swedish Defence Research Agency (FOI) in the field of gaming and computer games, the Swedish defence gaming initiative [10], will allow GameStudio to focus more on the technological aspects. 3.1 Developing an HLA bridge to MS Flight Simulator GameStudio has developed a bi-directional gateway called FS2HLA between an HLA 1516 simulation based on RPR-FOM [4] and a Microsoft Flight Simulator 2002 multiplayer session. The original purpose was to develop a prototype to show the benefits of using low-cost COTS simulator games as a part of a “real” HLA-federation. The prototype has been developed together with FLSC as described in section 4. 3.2 Microsoft Flight Simulator Microsoft Flight Simulator 2002 (FS2002) [5] was chosen for several reasons:

3.3 FS2002 multiplayer sessions A FS2002 multiplayer session is based on a peer-topeer architecture built upon Microsoft DirectPlay 7.0 [12]. A session needs to be hosted and this host may either be a dedicated application or a participating player. FS2002 supports up to 16 players although third-party dedicated host applications usually are capable of hosting unlimited number of players. Note that DirectPlay 7 and the FS2002 SDK both use the term player. To avoid confusion we will use the term participator instead of a DirectPlay player. Each participator acts as either a player or observer. A player has a visual representation and can be subject to collision. An observer has no visual representation and cannot be subject to collision. There is a third class known as unknown which is a temporary state until a participator has decided to be a player or an observer. Participators communicate through packets that are identified through a unique ID and name. All packets are sent to all participants in a session. There are 38 different packets which define the FS2002 protocol. They can be classified into session and player control, simulation/entity state and player “chat” packets. A set of packets for optional flight instructor sessions are also available but not covered here. Eleven packets are obsolete and should not be used. This leaves 21 relevant packets. A packet may be send-only, receiveonly or both.

Session/Player controll

Simulation/Entity state (players only)

LEAVE_SESSION (RO)

CHANGE_PLAYER_PLANE (SR)

ADD_PLAYER_REQUEST (SO)

QUERY_PLAYER_PLANE (SR)

ADD_OBSERVER_REQUEST (SO)

PLAYER_CRASH (SR)

CHANGE_TO_PLAYER (SR)

POSITION_LLAPBH (SR)

CHANGE_TO_OBSERVER (SR)

POSITION_VELOCITY (SR)

ƒ

Position is represented as WGS 84 longitude, latitude, altitude. Speed is represented as WGS84 longitude, latitude and altitude units per second. No acceleration is available.

ƒ

FS2002 does dead-reckoning at a level similar to DRM-FPS(2) in RPR-FOM 2.0.

ƒ

The FS2002 SDK does not state any required refresh rate for sending entity spatial data such as position updates.

ADD_PLAYER_REFUSED (RO) ADD_OBSERVER_REFUSED (RO)

Chat

3.4 FS2HLA

QUERY_PLAYER_TYPE (SR)

CHAT_TEXT_SEND (SO)

FS2HLA is a Win32 application developed in C++ and has a simple Windows GUI and a console window.

RETRANSMIT_JOIN_PLAYER (SR) RETRANSMIT_JOIN_OBSERVER (SR)

RETRANSMIT_GO_OBSERVER (SR)

A configuration file (XML) is used to define mapping tables between FS2002 entity strings (names) and RPR-FOM 2.0 entity numerations.

OBSERVER_CHANGE_OK (RO)

The main application consists of three modules:

OBSERVER_CHANGE_REFUSED (RO)

ƒ

One module that handles DirectPlay/FS2002 and creates an internal object database over FS2002 objects. It performs entity mapping, transforms and exchanges data with the bridge component. It uses the Microsoft DirectPlay 7.0 SDK and the Microsoft FlightSim 2002 Multiplayer SDK. FS2002 participates in a FS2002 session as an observer and bridges all players. Observers are ignored.

ƒ

One module that handles HLA. The module uses pRTI 1516 version 3.0 [17] and RPR-FOM 2.0.

ƒ

A bridge component which in turns receives and forwards data between the above modules at a refresh rate of 30Hz.

REQUEST_OBSERVER (SR)

Figure 2: FS 2002 Multiplayer Protocol Packets Note that entity state packets only affect players, never observers. Some packets have additional data attached to them, such as positions. Compared to RPR-FOM there are some important similarities and differences; ƒ

ƒ

ƒ

An FS2002 player or observer needs to have a unique name/identifier. This name and ID will be the same as the participators name which is managed by DirectPlay. An FS2002 player needs to define what plane (entity) it represents which in turn is identified by a single string. There are no force, site or application identifiers.

Entity-level information shared between FS2002/RPRFOM entities are; spatial (position/velocity), entity type, object name and time stamps.

There are no fire or detonation packets in FS2002. It may however be possible to use the PLAYER_CRASH packet to indicate a hit though.

The Simulation Object Model for the FS2HLA federate (Figure 4) is a subset of the RPR-FOM version 2.0. The federate publishes BaseEnitity Aircrafts and subscribes to Platforms. This makes it possible to visualize land and surface vessels in FS2002.

DirectPlay

FSIM 2002 Session

HLA 1516 RTI

FS2HLA

FSIM 2002 Objects and actions

B r i d g e

RPR-FOM Objects and interactions

Figure 3: FS2HLA Architecture

RPR-FOM Simulation

S HLAObjectRoot

BaseEntity

PhysicalEntity

Platform

P Aircraft

Spatial EntityType Figure 4: FS2HLA SOM Some of the challenges during development of the ƒ ARGUS (FSR 890) bridge involved coordinate handling. Converting ƒ Huey helicopter (UH1) positions between WGS84 Long/Lat/Alt and RPRFOM Geocentric coordinates is fairly straightforward ƒ Generic UAV using position handling routines available from FMV The bridge has also been useful as a test/debug tool [16]. The challenge consisted of the data representation during other federation development. One example is of the coordinates as well as how speed was to verify coordinate handling in other federates. represented. FS2HLA also acts as a low-cost federation The representation of coordinates and velocities in visualization tool. Since FS2002 comes with a global FS2002 was unfortunately not documented [11] which low-resolution terrain model can be used as a 3D made it impossible to pack/unpack positional data. This stealth viewer. information was however found in the documentation for FSUIPC [14] which is an add-on product for FS2002. Velocities are represented as lat/lon units (decimal) per second while the altitude speed is expressed as feet per second. Transforming Lat/Lon velocities to WGS84 XYZ proved to be a challenge. The solution used was to use timestamps and previous positions to estimate the XYZ-velocities of the aircrafts. Another coordinate handling issue is that there is no information on how dead-reckoning is performed in FS2002 or what spatial resolution geo datum is used. This may be a potential source for visual anomalies. So far such anomalies have been observed when performing rapid turns in high speeds, which was expected. 3.5 Federations The bridge has been tested against complex federations for studies on future C2 prototypes like LedsystT Federation 1 [16] and within a SE/US SNR PA (FMV / CERDEC) demonstration. During the CERDEC demonstration the bridge was able to handle 62 HLA objects without any noticeable performance problem. FS2002 on the other hand had difficulties rendering all of these objects simultaneously. Within these federations FS2002 together with the bridge has been used as low-cost/low-fidelity generic aircraft human-in-the-loop simulation for the following aircraft types: ƒ

JAS 39 Gripen

ƒ

Hercules (C130/TP84)

Figure 5: Screenshot from FS2002

4 Applications at FLSC The Swedish Air Force Air Combat Simulation Centre (FLSC) which is part of the Swedish Defense Research Agency provides operational simulation services mainly for the Swedish Air Force but also for international customers. This includes pilot, air traffic controller, weapons controllers and fighter allocators training as well as other services. These include for example simulation based acquisition (SBA) support in order to design and evaluate the capabilities of future airplane systems. The centre provides a combination of manned simulators and computer-generated forces that is unique within Europe. Additional resources include powerful visualization equipment and interoperability capabilities for large-scale distributed simulations.

4.1 Configuration of FS2HLA at FLSC The development of FS2HLA at FLSC has been carried out in cooperation between GameStudio and FLSC. The FLSC version is slightly different. It also has dedicated hardware controllers similar to a “TP84”, a logistic platform based on Hercules C130.

expected both to enrich existing training and extend the type of training that can be given, all at a very modest cost.

References [1]

Multi-User-Dungeon (MUD), http://www.lysator.liu.se/mud/faq/faq1.html

[2]

First Person Shooter (FPS), http://en.wikipedia.org/wiki/Firstperson_shooter

[3]

Spearhead II, http://www.tec.army.mil/TD/tvd/survey/Spear head_II.html

[4]

RPR FOM 2.0 (draft 7) http://www.sisostds.org

[5]

FlightSimulator 2002, www.microsoft.com

[6]

http://www.devmaster.net/engines

[7]

http://www.3dengines.de

[8]

http://www.seriousgames.org

[9]

http://www.dodgamecommunity.org

[10]

http://www.defencegaming.org

[11]

Microsoft Flight Simulator 2002, The FS2002 Multiplayer/Flight Instructor SDK, http://www.microsoft.com/games/flightsimula tor/fs2002_downloads_sdk.asp#addons

[12]

MicroSoft DirectPlay 7.0, www.microsoft.com

[13]

Sandeep Singhal, Michael Zyda : “Networked Virtual Environments, Design and Implementation”, ISBN 0201325578, Addison-Wesley Professional, September 1999

Picture 6: TP84 Controllers 4.2 Sample use case: PSO The FS2HLA bridge was initially developed as a proof of concept to demonstrate the potential of mixing gaming and defense M&S technology. As of summer 2005 it is under further development and testing. It is now seen as an inexpensive and general way to be able to introduce a variety of different plane types. One anticipated use case is for Peace Support Operations (PSO). Pilots and AWACS staff from different countries comes to FLSC to carry out combined exercises. Major topics include practicing international terminology and methodology during operations, typically patrolling non-flying zones. By adding FS2HLA it will be possible to also bring in logistics pilots to these exercises at very modest additional cost.

5. Conclusions Commercial game technology is subject to large investments and rapid development. Many technologies, like graphics adapters, are directly reusable for defense purposes. Others, like game titles, can be reused as long as the limitations with respect to realism, fidelity and verification & validation are properly understood. We have shown that it is possible to make a commercial game like Microsoft Flight Simulator 2002 interoperate with HLA 1516. The bridge allows the number of participating system be expanded both on the MS Flight Simulator side as well as on the HLA 1516 side. Using interoperability with games in Swedish Air Force Air Combat Simulation Centre will give an opportunity to extend the existing, proven set of simulators with a variety of plane types. This can be

[14]

FSUIPC for Programmers (and Adventure Writers), Pete Dawson http://www.schiratti.com/dowson.html

[15]

Pitch Technologies: pRTI 1516 version 3.0. http://www.pitch.se

[16]

Swedish Defence Materiel Administration (FMV), http://www.fmv.se

[17]

DARWARS:Ambush! Lessons Learning Game (DARPA), http://ambush.darwars.net/

[18]

Operation Flashpoint, Bohemia Interactive, http://www.bistudio.com

federation development and tool support since 1996. Recent work includes developing design patterns for HLA based simulation in the future Swedish Networked Based Defense.

BJÖRN MÖLLER is the Vice President and cofounder of Pitch, the leading supplier of tools for HLA 1516 and HLA 1.3. He leads the strategic development of Pitch HLA products. He serves on several HLA standards and working groups and has a wide international contact network in simulation interoperability. He has twenty years of experience in high-tech R&D companies with an international profile in areas such as modeling and simulation, artificial intelligence and Web based collaboration. Björn Möller holds an MSc in Computer Science and Technology after studies at Linköping University, Sweden and Imperial College, London.

Author Biographies ADAM BACKLUND is research engineer at the Swedish Air Force Combat Simulation Center. He has experience in software design and developing HLA based applications used in military simulation. Adam holds a BSc in Computer Science from the Royal Institute of Technology, Sweden.

JOUNI LINDQVIST is an experienced developer within the areas of Visual and Distributed Simulation and has been working as a consultant for the Swedish Defense Material Administration (FMV), Swedish Defence Research Agency (FOI) and several Swedish defence contractors over the last 13 years. He studied computer science at the Royal Institute of Technology (KTH) in Stockholm and is also co-founder of Calisto Data AB.

BJÖRN LÖFSTRAND is Manager of Modeling and Simulation Services at Pitch Technologies. He holds an M.Sc. in Computer Science from Linköping Institute of Technology and has been working as with HLA

ROBERT VIRDING is in charge of the GameStudio project at the Swedish Defence Material Administration (FMV). He has also been the Swedish representative to the WEAG Panel II group CEPA 11 (Defence Modelling and Simulation). He studied Physics and Theoretical Physics at Uppsala University and Stockholm University and Computer Science at the Royal Institute of Technology (KTH) in Stockholm.

BJÖRN WALLER is a research engineer at Swedish Air Force Combat Simulation Centre (FLSC). He has more than six years of experience of developing air combat simulation tools including HLA-based software. Björn Waller holds an MSc in Aeronautical Engineering from the Royal Institute of Technology, Sweden.