Applying Gaming Technology to Military Visualization Games Where You Only Live Once

1
Applying Gaming Technology to Military
Visualization - Games Where You Only Live Once!

• Ken Doris
• Mark Larkin
• Ron Szymanski
• Matt Zieniewicz

2
Todays Agenda

• Overview Background
• Rationale for developing the API
• Approach to the Research
• System Requirements Design
• Prototype Development
• Future Work

3
SBIR Topic A03-083

• From the 2003 SBIR Solicitation
• OBJECTIVE Develop a standardized application
  programming interface (API) for a military 3-D
  gaming simulation tool that will facilitate the
  integration of a gaming environment with planned
  military C2 applications (such as the Commanders
  Support Environment, Combined Arms Planning and
  Execution System, DaVinci Toolkit).

4
Current C2 Visualization of Battlefield
Microsoft look and feel
2D/3D tailorable battle view window of current
situation and planned events
Workspace window for Mission, COA and UTO
Timeline Window
5
3-D View of the Battlefield
6
Game Engine View of the Battlefield
7
Game Engine View of the Battlefield
8
Research Goals

• Harness the power of modern PC gaming technology
• Leverage resources of 20B industry
• Take advantage of familiarity of modern
  Commanders with gaming paradigm
• Exploit and Extend the Technology
• Excellent 3D Rendering, continually Improving
• Game subsystems (Physics, Sound, etc.) will be
  adapted to increased Situational Awareness of
  Commanders

9
Research Goals

• Develop an API that Supports Army C2 Requirements
• Compatible with DaVinci Toolkit
• Extensible, Modular design to handle future needs
• Able to integrate with MS systems
• Ensure API will Supports Other Applications
• A flexible framework that can be adapted to other
  military applications (e.g. Asymmetrical
  Warfare).
• A framework that can be adapted to other
  non-military domains (e.g. HLS, Disaster Relief)

10
System Requirements

• The User Interface to be based on the standard
  PC game paradigm
• Keyboard (e.g. a-w-s-d)
• HUD
• The system must handle up to 200 independently
  moving elements (vehicles, squads, etc).
• Relatively high processing power needed
• The 3D viewpoint must provide the Commander with
  a level of Situational Awareness (SA) not
  otherwise available.
• 3D view plus 2525

11
Input Data Requirements

• C2 Data feeds
• DaVinci XML used in MC2
• Possibility of Battle Management Language (BML)
• DIS/HLA may factor in
• Terrain Data
• NIMA (aka NGA), CTDB Other formats
• Multi-tool Transformation paths
• Future improvements likely (e.g. Terrex)
• Equipment Modeling
• Army Model Exchange (Openflight VRML)
• Potential reuse of Americas Army models
• Many other sources

12
Game Engine Requirements

• Open Native API
• Well documented, easy to Mod
• High Degree of Modularity
• Subsystems (Physics, AI, Rendering, etc)
• Ease of Content Creation
• Editors and 3rd Party tools
• Support
• Vendor Forums
• Engine Maturity and Age
• Recent version of an established engine
• Development Environment
• Object-Oriented (e.g. C)
• Scripting a plus

13
Game Engine Research

• Literature analysis of over 15 engines
• Downloaded evaluated Freeware Engines
• Evaluated Garage Games Torque Engine
• Used in Starsiege, Tribes I II
• Source Code License 100
• Downside Insufficient Documentation Support
• Evaluated EPIC UnReal Engine2
• Employed in over 20 games
• Also used in Americas Army
• Extensive Documentation Support
• Selected for Phase I Demo

14
Game Engine Architecture
Input Devices
keyboard
joypad
joystick
...
GAME ENGINE
Special Effects Engine
Device I/O
Network Mgmt
Geometry Assets
Object Geometry
Scene Geometry
Character Geometry
Predefined Animation
Physics
Logic and AI Rules
Memory and
Object and Viewpoint Placement
Engine
Cause and Effect Rules
Rendering
File I/O
Behavior Rules
and Object
Management
Physical Parameters
Control
Graphics Assets
Textures
HUD
Artificial
Audio System
Video
Intelligence
System
Audio Assets
.wav
MIDI
15
Conceptual View of the API
GAME
Native Game Engine API
ENGINE
16
Architectural View of the API
Executive
Executive
Executive
Executive
Unreal
Unreal
Unreal
Unreal
To/From
To/From
Engine
2
Engine
2
Engine
2
Engine2
MC2
MC2
CS
CS
CS
CS
Mission
Mission
Mission
Mission
Mission
Mission
Mission
Mission
UnReal Interface Layer
UnReal Interface Layer
UnReal Interface Layer
UnReal Interface Layer
Collab.
Collab.
Translator
Model
Client
Translator
Model
Client
Translator
Model
Client
Translator
Model
Client
Native API (UnRealScript)
Native API (UnRealScript)
Native API (UnRealScript)
Native API (UnRealScript)
Server
Server
(CS)
(CS)
Game Engine
Game Engine
Game Engine
Game Engine
C2
C2
C2
Specific Layer
Specific Layer
Specific Layer
Specific Layer
Layer
Layer
Layer

17
Phase-I Prototype Development

• Designed Implemented C2 Layer of API
• Created C Version of MC2 Client
• Created Framework for Generic C2 Data Handling
• Modular design for re-use
• Reverse-Engineered MC2 XML
• Documentation is obsolete
• Demo includes only a subset
• Designed Implemented Game Layer of API
• C UnReal Script calls

18
Phase-I Prototype Development

• Input Data Handling
• Reverse-Engineered MC2 XML
• Documentation is obsolete
• Demo includes only a subset
• Built MC2 Vehicle Models
• Obtained from Army Model Exchange
• Converted via 3D Studio Max
• Created Ft. Dix Terrain
• 4 mi by 4 mi piece - From Scratch
• Elevation data only
• Simple roads

19
Terrain Generation Process
NIMA Source Data
NIMA Source Data
ArcView
ArcView
Terrain
Terrain
Spatial Analyst
Spatial Analyst
CTDB
Mapping
Mapping
CTDB
Application
Application
3D Analyst
3D Analyst
Domain
Domain
DART
SiteBuilder 3D
TerraVista
DART
SiteBuilder 3D
NuGraf
NuGraf
3D Graphics
3D Graphics
Application
Application
Domain
Domain
3D Studio Max
3D Studio Max
ActorX
ActorX
UnReal Format
Unreal Format
Unreal Format
20
UnReal Editor Terrain Development
21
UnReal Editor Model Development
22
Elements of Phase I Prototype

• PC Host running MC2 Server normal MC2 Client
• Second PC running 3D MC2 Client

MC2 Server
Prototype 3D Client
MC2 Client
23
Location Browns Mills, NJ
24
Setting Up Routes in MC2
25
Game Engine View
26
Game Engine View
27
In-Game View from Outrider UAV
28
GCM and 2525 Symbology
29
Future Work

• Complete the API
• Complete the feature set
• Provide the API in two forms
• A Specification
• A Reference Implementation
• Build Demonstrate a Fully Functional Prototype
• Complete the GUI GCM
• Explore power of subsystems
• Integrate with other systems
• Participate in FCS Experiments
• Set the Stage for Phase III
• GameLink a full C framework
• Software Services to DoD, HLS, others

30
A Final Note

• The views expressed in this presentation are
  those of the authors and do not reflect the
  official policy or position of the Department of
  the Army, Department of Defense or the U.S.
  Government