Game Interfaces for OneSAF

1
Game Interfaces for OneSAF

• OneSAF Users Conference
• 4/7/2008

2
Project Goals

• Goals
• In General What game technologies are useful for
  OneSAF users
• Specifics VBS2 as a desktop simulator in an
  accurate synthetic environment
• Specifics Generalized approach for games
• Planned Use Case
• Create (MR) M1A1 Platoon in OneSAF
• Create and place a Dismount in VBS2 near the
  platoon
• Maneuver VBS2 dismount to the lead vehicle and
  select the gunner position
• OneSAF deactivates automated control of turret
  and weapon models
• VBS2 controls are used to move the turret around,
  change weapon elevation, and fire weapon.
• The M1A1 platoon is given a move order. OneSAF
  remains in control of the movement of the M1A1.
• The dismount dismounts from the M1A1.
• The M1A1 platoon is given a move order. OneSAF
  resumes control of the weapon and turret models.

3
VBS2 OneSAF Interoperation

• Worked with Bohemia Interactive (VBS2) and
  Calytrix (LVC-Game) directly
• Peter Morrison VBS2 Lead Developer
• Damon Curry Calytrix President
• Mark Dzulko VBS2 Lead Programmer
• Beta testing terrain development tools
• Our folks built correlated databases
• Gave feedback on tool usage
• Accomplishments
• Connected OneSAF and VBS2 together using LVC-Game
• Mapped all VBS2 and OneSAF models
• Tested fire/detonate interaction (SAF can damage
  VBS2, vice versa)
• Mount VBS Infantry on SAF vehicles (cant
  dismount currently)
• Basic correlated terrain developed (elevation and
  shape data only)

4
VBS2 OneSAF Correlated Terrain
Start with the same source data
DTED Data
Imagery Data
Shape Files
Terrex
OneSAF OTF

• VBS2 does not currently support import of 3d
  static and moving models, but has plans to.

• VBS2 Terrex Plugin being considered

LandBuilder
VBS2 Visitor Terrain Editor
VBS2 Terrain Map
5
Additional VBS2 Interoperation Concept

• Use VBS2 to assume control of part of a SAF
  vehicle
• Driver or Gunner
• Will need modifications to LVC-Game, OneSAF and
  possibly VBS2
• Concept can be applied to a DIS entity, including
  a gunner for CDT

Gunner
Driver
Gunner Articulated Part Data
DIS Application
VBS2 Game
LVC-Game
Entity State Events
Fire/Detonate Events
6
Game Engine OneSAF Interoperation

• Provide services to allow game engine to connect
  to OneSAF
• Examined ICE (Internet Communications Engine) for
  the middleware service
• Worked with Delta3d as the game engine, but
  looking at alternatives as well
• Two concepts
• The classic 3d game interface for OneSAF
• 3d client to control entities as part of a OneSAF
  sever farm
• Similar to the MMOG type games
• Why?
• To revisit game technology with newer solutions
  to gage utility

ICE
SORD
Game State Manager
Interop
7
Main Issue

• Two applications controlling different parts of
  the same vehicle
• DIS protocol is for entire entity
• Articulations are not considered separately
• HLA has some notion of attribute ownership, but
  implementations are not common
• And we didnt want complications of HLA in the
  experiment
• There are examples for DIS transfer of ownership
• But for entire object
• Solutions
• DIS standard for attribute ownership (?)
• Separation of articulations from ESPDU (?)
• Specialized protocol to owner of the entity
• Assume OneSAF owns the entity
• VBS2 to communicate elements of the ESPDU back to
  OneSAF
• Use the DIS Set Data PDU to communicate the
  attributes
• OneSAF relinquishes the part control as part of
  its composition
• The VBS2 Game will need to ignore the part data
  that it is controlling, because the data will not
  be consistent with the current state of the game
• Not a very standard way of doing things

8
Examples - While Dismounted

• OneSAF
• Sends out DIS Entity State PDU for the M1A1
  vehicle
• Active SAF agents/controllers on the M1A1
• Mobility, Weapon, Turret, etc
• Listens for DIS Action Request Mount

• VBS/LVC-Game
• Sends out DIS Entity State PDU for the dismount
• Allows mount and position placement of DIS
  platforms
• Sends a DIS Action Request Mount PDU
• Fixed Data includes enum for seat position
• Driver, Gunner, Passenger, Other
• Fixed Data includes vehicle DIS id to mount
• Fixed Data includes own DIS id

9
Examples - While Mounted

• OneSAF
• Deactivate agent(s) based on seat position taken
• Listens for DIS Set Data PDU
• Parses ES info within the Set Data PDU and
  updates internal state data
• For only the data that is being controlled by the
  VBS2.
• Sends out DIS Entity State PDU for the M1A1
  vehicle
• Listens for DIS Action Request Dismount

• VBS/LVC-Game
• Sends a Set Data PDU to inform that the entity
  state data based on the VBS2 state data.
  Basically wrapping ESPDU in a DIS Set Data PDU.
• Transmit rate is TBD
• Ignores some data from the ESPDU. This is
  because the position being modeled by VBS2 needs
  to be consistent, not overwritten by the ESPDU
  from the DIS platform.
• Ex. When in gunner position, LVC-Game ignores
  ESPDU data for the gun and turret. That data
  remains controlled by VBS2 game state data. But
  everyone else on the DIS network will use the
  ESPDU data in full.
• Allows Dismount of DIS platforms
• Sends a DIS Action Request Dismount PDU

10
What Have We Done?

• VBS2 interoperating in a DIS exercise
• Mounts and Dismounts a variety of systems
• OneSAF vehicles
• CDT
• Microsoft ESP RWA
• Limited knowledge of mount/dismount status need
  consolidated protocol
• OneSAF entities mapped into VBS2
• Some issues with VBS2 being able to incorporate
  new models
• They are working on plan
• LVC-Game evolved to support interactions
• Engagements exercised
• Exercised as part of our I/ITSEC scenario last
  year
• OneSAF, VBS2, Microsoft ESP, CDT, Expedition,
  MANTIS, SE Core Long Haul to Ft. Benning
• Currently examining VBS2/OneSAF connection for
  training at Ft. Lewis