Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
1. IDENTIFICATION AND SIGNIFICANCE OF THE PROBLEM OR
OPPORTUNITY
1.1. The Problem
A web-based serious medical game will address challenges inherent to conventional training.
The quality of conventional training is directly dependent upon the skill of the instructor.
Objective performance metrics are usually not established, and are difficult to track or archive.
Student feedback is variable and not standardized. Live training cannot occur frequently enough
due to the constraints of assembling students and instructors in real world facilities. Live
training takes students away from their normal duties resulting in lost productivity. A high
student-to-instructor ratio limits the amount of decision making sessions and individual
instruction. Problems are exacerbated by there being an insufficient number of skilled
instructors, program managers and subject matter experts.
It is impossible for conventional training to replicate the vast quantity and complexity of
interrelated scenarios and events that can and do occur in the real world. Conventional training
settings are unable to reproduce variable and dynamic landscapes, patient profiles, battlefield
chaos, care under fire, and the interaction of many personnel who may not even be physically
present. Conventional training has few options for simulating surgical and invasive procedures.
It is difficult for delivery of conventional training to be standardized or reproducible.
1.2. Advantages of a Web-Based Serious Medical Game
Gaming technology will allow training to be delivered 24x7 to anyone who needs it wherever
they are located. Since the proposed system will have huge capacity the amount of training will
be limited only by the number of scenarios and training content that are created. This will be a
large-scale multiplayer gaming system for an entire squad and their supporting staff all along the
continuum of care. The system will allow trainers and subject matter experts to virtually
“reproduce themselves” to deliver standardized medical training curriculum to far more people
and supervise their progress.
An inherent advantage of gaming technology is that program managers and training
administrators will be able to create a multitude of game challenges with any combination and
permutation of scenarios, circumstances, facts, missions, and obstacles. Even highly complex
scenarios can be exactly reproduced so the student can practice repeatedly, to measure student
achievement, and to objectively compare results among competing students. Instructors will be
able to act within the game to dynamically introduce challenges to individuals or groups.
The proposed serious medical game will be engaging, playable and fun to entice students to play
the game. Students will be working through various situations and challenges while immersed
into realistic virtual environments. They will have fun competing with other players as in
recreational online games while meeting explicit training objectives. The online game will be a
de facto social networking site among players. Players will be required to communicate, share
information and cooperate among each other to meet objectives within the context of winning the
game and achieving higher levels.
Page - 3 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
1.3. Gunwale LLC's Innovative Approach
Gunwale LLC proposes to develop a 3D immersive software simulation and serious multiuser
game for training tactical combat casualty care, including advanced scenarios with multiple
levels of progressive difficulty. Scenarios will include environmental and situational stressors to
the medic and non-permissive environments, including care under fire, unplanned events, and
equipment simulation. Special attention will be placed on simulating auditory and tactile
experience in the digital medium to increase the overall immersive quality of the training
exercise.
The gaming system will review and assess the medical skills of the player to build the game
difficulty level based on his or her current skill level. For example, a medic with no combat
experience may not handle a mass casualty situation as well as a combat experience medic.
Conversely, all medics must have a basic level of competence on the simulation.
The simulator engine will be designed to handle simulations of high stress including combat area
risks at point of injury, simulation of patient delivery, and simulation of forward deployed
hospitals. A variety of medical packages can be simulated, including small rapid response such
as SPEARR, Forward Surgical Teams, and more definitive care packages, including EMEDS
packages and Air Force Theatre Hospitals, including simulation of medical equipment, tents,
beds, and non-player character representation of medical personnel.
The training interface will include a graphical user interface that represents life signs and
feedback from simulated medical equipment, including the ability to check for life signs,
checking for pulse, listening for lung flow, etc. The training experience will include scripted
events while measuring response times. When the player avatar takes actions, the game will
have a decision tree that observes a specific care item being accomplished or not. For example,
the game will cause a problem to get better or worse depending on the player avatar taking a
correct or incorrect medical action. The training interface will also include simulated tactile
effects, including simulated stressors while administering care under fire and in general will
include real-world dirt, grime, and confusion at the point of injury.
The simulator engine will also have the ability to simulate care during transport, including
transport by land or air, and in particular will include simulation of CCATT in flight. This
scenario can be seamlessly tied to aero-medical evacuation from a forward operating hospital
such as EMEDS. In particular, the simulator engine will support seamless transition between
these zones. A student could begin a scenario at any point, and training could cover any range of
experience, from point of injury to delivery to a level-1 trauma hospital.
Once the student logs into the system and begins a scenario, their avatar will spawn in a starting
location and a timer will begin. Events can be scripted to occur at specific times, or in response
to the trainee reaching a preset waypoint.
1.4. Medical Gaming Scenario Examples
Defined medical scenarios can be placed into one or more virtual “rooms”. The game system
will support a variety of medical scenarios that training administrators will be able to combine in
Page - 4 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
creative ways to simulate real world situations. Initial scenario building will focus on the top ten
or twenty "real world" issues. Examples are as follows:
1.4.1. Care Under Fire – Example #1
The primary objectives are stopping the bleeding and limiting exposure to the rescuer. Imagine
an RPG explosion during a foot patrol resulting in one wounded. Meanwhile, stressors are added
with the area coming under sniper fire. The patient is suffering from extremity hemorrhage and
will bleed to death if a CAT tourniquet not placed. The tourniquet must be placed before onset
of shock or the patient will have much higher chance of death. Bleeding must be controlled.
Distal pulse remains after placement of first tourniquet, so a second one must be placed just
proximal to the first (increasing the effective width of the tourniquet). In administering care
under fire, the concern is stopping bleeding using a tourniquet. There is also the goal is limited
exposure to the rescuer. Exposure will cause the rescuer to be wounded or killed by sniper fire.
1.4.2. Care Under Fire – Example #2
This scenario includes IED detonation during a Humvee patrol with several casualties
characterized with blast and blunt force trauma type injuries. The situation is made more
complex with a secondary IED explosion or hazard, configurable with ground-assault after
initiation of the IED. Options can also include high traffic street and a gathering crowd. The
casualty can have blunt trauma, penetrating trauma, blast, and burns. The scenario can include
spinal fracture (thoracic) where the rescuer must maintain spinal alignment for a patient.
1.4.3. Stopping Bleeding of an Extremity – Example #1
This scenario has a soldier with a gunshot wound to his left leg and an open fracture of the left
femur. Condition is made more severe with an injury to the popliteal artery and vein. Three
CAT tourniquets are required to save the patient.
1.4.4. Stopping Bleeding of an Extremity – Example #2
The scenario features a tourniquet malfunction. The velcro band must be tightened as tight as
possible before starting to use windlass. A loose velcro band contributes to tourniquet
malfunction.
1.4.5. Stopping Bleeding of an Extremity – Example #3
A fake CAT tourniquet shows up in theatre which does not have the proper NSN number and is
prone to failure.
1.4.6. Penetrating Eye Trauma
The scenario requires the placement of rigid eye shield. If eye shield not in IFAK then the
medic's own tactical eyewear is required to save the patient’s eye.
Page - 5 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
1.4.7. Airway Management
In this scenario the concern is not CPR, but using airway assisted devices such as nasal airways
or Combi-Tubes or surgical trachs.
1.4.8. “Sucking” Chest Wounds
Here the medic is required to deal with open chest injuries that must be treated by sealing the
chest and performing a needle decompression (which is where a large bore needle is inserted into
the chest) in an effort to decrease the build-up of air pressure in the chest.
1.4.9. Surgical Airway
The situation is that the field crics has been done incorrectly, either through the thyroid cartilage
or vocal cords. The scenario for casualty care can include nighttime non-permissive
environment where the medic can be influenced by injury sustained on infiltration (damaged
night vision goggles as well). The patient has a gunshot wound to jaw. The medic is not called
to scene for 10 minutes due to ongoing firefight. The jaw has been shattered with heavy
maxillofacial bleeding. The casualty refused to take the "sit up lean forward" recovery position.
Anxiolysis is attempted with Versed to facilitate maintaining the airway position fails. The
casualty becomes increasingly combative. All landmarks have disappeared due to soft tissue
swelling of the neck. By performing a cric, a definitive airway is established under extremely
difficult conditions. If no cric, the airway is lost during evacuation.
1.4.10.Endotracheal Tube is Cut
In this scenario the endotracheal tube is cut and must be taped securely, otherwise the tube will
slip into the trachea, cease to function correctly, and must be surgically removed.
1.4.11.Other Scenarios
Additional scenarios can be created with non-threat injuries such as motor vehicle crashes and
falls from height (such as falling down stairs or off a wall). Some scenarios will use night vision
goggles, but many scenarios will require night operations especially if the situation includes a
fire fight or IED explosions. Environments will include desert, mountain and urban warfare,
light and dark, and snow, rain and heat.
1.5. Extended Gaming Platforms
The system can eventually be ported to mobile platforms (such as iPad, etc). The primary user
interface for Phase-I will be a normal computer browser and computer speakers to provide visual
and audio stimuli to the student user. It will not be difficult to add mobile learning capabilities
with mobile devices since the existing Gunwale, LLC gaming engine supports mobile locationbased game interaction.
Page - 6 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
2. PHASE I TECHNICAL OBJECTIVES
The two primary objectives during Phase I will be to (1) implement one medical scenario where
the game can be played and demonstrated; and (2) to develop universal gaming system
components that provide the underlying technologies of all scenarios.
2.1. Prototype One Medical Scenario for Care-Under-Fire
During Phase I, a single medical scenario will be developed as described in this section.
Physical Situation
You and your squad receive incoming fire from a small enemy squad located from a fixed
location. While under fire, an assistant rifleman is struck in the thigh, just above his left knee.
He screams and drops his weapon and tries to stop the bleeding with his hands.
Medical Situation
A 28 year old male wearing full combat gear is struck in the left leg proximal to the patella. It is
a single penetrating round with no open fracture noted. Patient is alert and trying to help.
Required Actions
A tourniquet must be placed within minutes of being struck and can be performed by either the
patient or the rescuer. If done by the rescuer he must utilize cover and concealment to get to the
patient. The rescuer must also assist in returning fire and getting the patient to do the same and
move him to proper cover. Since this is in a large area of the body, consideration must be made
to apply a second tourniquet above the previous one.
Secondary Actions
Once the scene is safe the following actions must be taken:
 Assess the patient (see next section)
 Expose the wound to evaluate extent of damage
 Consider applying “hemostatic” (blood stopping) gauze pads to wound with pressure
dressing, if appropriate
 Splint the wound to prevent further damage
 Start saline lock or intravenous solution to maintain hydration or blood product
replacement
 Prepare the patient for transport either via “9-line” medical evacuation or ground
transportation
 Conduct CASEVAC (casualty evacuation care) to include completion of medical transfer
card
Assess the Patient
Medical personnel should assess the following:
 Airway. Breathing is expected to be between 24 to 30 breaths per minute.
 Bleeding. The game will show blood that is bright and flowing. Heart rate is expected to
be 100 to 130 beats per minute.
Page - 7 -
Maximus Prime, LLC

Topic # OSD10-H08
Proposal # XXXXXXX
Alert assessment – AVPU. Patient is expected to be alert, screaming and possibly
confused.
Reassess the Patient after Tourniquet is Applied
 Airway. Breathing may still be around 24 breaths per minute but patient will be calming
slightly.
 Bleeding. No bright red blood should be present, but there will be oozing to trickling of
blood which must be controlled using pressure dressing or hemostatic dressings. The
heart rate will stabilize once bleeding is controlled.
 Pain management will be managed either with stopping the bleeding and a splint or
possible injection of Morphine. Care should be considered using MSO4 since it will
decrease respiratory rate and delay the patient’s ability to think and react, in large
amounts.
 Alert Assessment – AVPU. If bleeding is controlled the patient will maintain their
awareness. The patient must be treated for shock by either keeping them warm or
cooling them off.
Outcomes
The game will cause the patient avatar to react negatively if the rescuer avatar does not
 If tourniquet is not applied in time or becomes dislodged
 Patient will become more and more confused or may loose consciousness
 There is only tow to four minutes of useful consciousness for the patient
 There will be an increase in heart rate, respiratory rate and anxiety on the part of the
patient
 After four minutes, the patient will become critical and after six minutes, will probably
bleed to death
Air Transport to Level 1 Trauma Hospital
 Prepare the patient for transport using either a make shift litter or a commercially
available one (Talon)
 Contact leadership on the situation and request medical evacuation using the “9-line”
format or in theater approved system
 Continue to provide direct patient care and reassess every three to five minutes as mission
allows
 Once patient arrives at FST (forward surgical team) location, immediate reassessment is
done to evaluate patient’s overall status
Page - 8 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
3. PHASE I WORK PLAN
3.1. Game Engine Development
The medical simulation game will be based on a client/server model. Multiple players can log
into a shared scenario, similar to a multiplayer game. A server backend will be used that can
support up to 1,000 simultaneous users. Players will be able to save their avatars and statistics
on the server. The server will include an SQL database on the back end to store any persistent
data required by the game world. The client software will be an immersive 3D rendering
environment with heads up display, camera control, and graphical user interface.
Figure 1 - Concept drawings for client-side interface, point of injury care
Illustrated in Figure 1 are multiple camera views of the same point of injury scene with a heads
up display overlaid. This mockup illustrates that the player will be able to zoom out (point B)
and zoom in (point C), as well as rotate angle of the camera. In the mockup, server controlled
NPC soldiers take up guard positions around a vehicle (point A). NPC soldiers also assist with
the patient (point C, etc). The medic makes choices via the GUI and can apply treatment (point
D). The client will support overlay rendering of objects, such as a timer (point F) and a vital
Page - 9 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
signs display (point E). The rendering surface will be mouse and keyboard driven (see figure
XX for a more detailed view of the heads up display).
3.1.1. Heads up display and player interaction
The heads up display allows the player to take action(s), perform procedures, and use equipment.
The available actions may change depending on where the player is in the scenario decision tree.
For example, after taking a specific action, the set of available actions can be changed, some
actions can be "greyed out" as they are no longer available. If equipment is used up, then it will
no longer be available as an action. Some actions can become available only after certain
equipment is used. Once certain equipment is used, new actions become available. For example,
after oxygen mask is applied, the trainee can set oxygen rate.
Some actions are designed to take patient vital signs. For example:
- Action: Get Heart Rate
- Action: Check Skin - result Clammy, Cold, Warm, Dry, Pale, Ashen
- Action: Get Resp. Rate
- Action: Check lung flow
- Action: Check for active bleeding
- Action: Ask Patient - result alert, oriented, describes pain level 1-10, confused, combative,
nauseated
The above list would be extended to a large number of options based on the scenario.
Furthermore, these options will be configurable via the scenario template and decision tree.
Figure XX illustrates the action bar (point A) and how actions are represented. In the illustration
the CAT tourniquet action is shown (point B) and an option to take blood pressure is shown
(point C). Choosing these actions initiates an animation sequence showing the medic taking this
action, and the scenario action/decision tree is then traversed.
3.1.2. Scenario Configuration
The game client will support the trainee with selection of an avatar. The trainee can select a
scenario, or the scenario can be driven from a SCORM compliant LMS. The scenario may offer
options such as load-out (equipment profile). Scenarios can operate as templates with many
configurable options (see section XX below). In most cases, the scenario will be preprogrammed but may offer the trainee a menu with multiple settings. The Phase-I scenario will
include a point of injury environment, including an option for hostile sniper fire. Optional
settings can be made to this scenario such as day and night, equipment damage such as broken
night vision goggles, hostility of zone, etc. The configuration choices made by the trainee can be
saved as a pre-set profile along with the trainee avatar.
Page - 10 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
3.1.3. Multi-user environment
The system will be designed to support multiple players in a shared scenario. However, the
focus of the Phase I scenario is for an individual medic. As a technology demo, additional
players will be able to log into the Phase I scenario space and interact, but the scenario itself is
not a 'squad' scenario. That said, a squad scenario could be developed and would be a potential
Phase II task. The system will be designed to support up to 1,000 simultaneous players in a
single scenario, which should be sufficient to cover any multiplayer training scenarios.
3.1.4. Protocol and Development Language
The 3D client will be decoupled from the server using a communications protocol that will be
fully documented, so that the client could, in theory, be replaced by any new client technology
without causing any changes on the server (for example, if a client for mobile devices were
developed). The client will be delivered via a web page, but will offer full screen mode so that it
won't be hindered by a web browser frame. Both the client and server are written in high speed
C++, and any game engine modifications will be in C++ and added as extension libraries.
3.1.4.1. HTTP / HTTPS compliant protocol
The communications protocol will be packaged so that it's compliant with HTTP/HTTPS, would
work over proxies, and would not require any special firewall exceptions for the client
environment.
3.1.5. Cross Platform Rendering Library
The game client will leverage a cross-platform rendering library called Ogre3D. The initial
client will be developed for a windows client platform, but the library has been ported to other
platforms including the iPad (mobile platform) and Xbox 360 (console platform), proving that
portability will not be an issue down the road, either for mobile platforms or console platforms.
The library has also been ported to Mac & Linux, proving that operating systems will not be an
issue down the road.
3.1.6. Seamless zone transitions
The client / server design will avoid loading screens so gameplay continues seamlessly between
zones. Avatars can move between environments without a loading screen. For example, there
will be no need for a loading screen between point of injury and helicopter evac and subsequent
field hospital.
Page - 11 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
3.1.7. AI behavior
Non player characters can have behaviors and pathfinding driven by an AI system which is
hosted on the server. For Phase-I, the AI defined behavior will be rather simple. The basis of
the AI behavior will be either a C++ module on the server, or a scripted interface on the server either of which will provide the required behavior. More complex AI behavior can be addressed
in a Phase-II.
3.1.8. Server Design
The server itself will run on windows server 2003 by design and will utilize platform specific
communications features offered by that kernel. The server will connect to a back end SQL
database. A schema will be designed that is appropriate to the training simulation and data
integration requirements (see next section). A single server would likely be able to handle
training scenario instances for up to 1,000 simultaneous users. The server scales linearly with
the addition of server hardware, and all servers can draw from the same database in that case.
3.1.8.1. Integration points with external virtual worlds
Status of player avatars, performance, simulation variables, and more can all be accessed by the
data stored in the SQL database. As such, the medical simulator can be integrated with other
virtual-world components or systems that exist outside of the simulator. For example, if other
applications exist within the greater AFMMST website, these could share data with the game
server via the SQL database. If the AFMMST website has a single sign-on, this could translate
to the game login as well to preserve single sign-on. The options are numerous in terms of data
integration.
Figure 2 - SQL database is a data integration point with other applications in the AFMS virtual space
Page - 12 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
3.1.9. Architecture Summary
Figure 3 - High level architecture
Game Client: a 3D rendering client with HUD, Camera Control, and GUI. Using Ogre3D.
Written in C++. Deliverable via web interface. Portable to many platforms, including operating
systems, mobile devices, and console gaming platforms. Phase I delivery will be a windows
client.
TCP Sockets based communication: Communication will be high speed and optimized and
made compliant with HTTP/HTTPS so that no special firewall rules need to be considered, and
existing proxy settings will pass the traffic in a proxied environment.
Protocol Spec: the communications will be over a well documented protocol, designed to be
compliant within HTTP/HTTPS specification, but otherwise a complete application-layer
protocol.
Server platform: The server will be optimized for speed and capacity using a windows 2003
platform, including optimization for multi-threaded and multi-CPU hardware platform. Multiple
servers can use the same SQL database and serve the same game world.
3.2. Scenario and Content Development
The game engine itself will be decoupled from the training scenarios and content being delivered
via the platform. The training scenarios will require art and model development, terrain
development, texturing, graphical user interface components, icons, and audio work.
Page - 13 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
Phase I terrain development will be fairly simple, and represent a typical location in Afghanistan.
Model development will include soldier character models, in full gear. A wounded soldier will
also be developed. A medic avatar will be developed as well. A Humvee vehicle will be
developed, and a Blackhawk helicopter will be developed. An internal view of the Blackhawk
helicopter will also be developed for simulating patient care during evacuation.
3.2.1. Integration with SCORM
Being a rich environment, the game will have many factors that are controlled from within the
game server and client. Some of these variables can be integrated with a SCORM compliant
LMS, such as choice of scenario, scenario difficulty settings, decision points and branch options,
and events in the game scenario. Optionally, entire game assets and scenario's can be packaged
as a sharable content object. The SCORM compliant web-page that launches the game engine
can perform all javascript-related SCORM compliant communications prior to launching the
game client, and provide the SCO from the LMS to the game client. In effect, there will be no
conflicts between the LMS and the game simulator. The LMS can be used to acquire and set
variables within the game client, and can also be used to deliver results of the simulation. The
game server will also store the results of the simulation, and this can be used for secondary
validation of the results provided to the LMS or can provide an alternative data integration path
when desired.
3.2.2. Training Content Development for Medical Administrators
Medical Administration staff is not going to be technical in the ways of game development,
placement of 3D models, or construction of simulation environment. That said, they will be able
to create decision trees and event trees for patient care. The game engine will allow a scenario
template to be modified via an XML document that includes decision trees, branches, and setting
of predefined variables. This will allow some flexibility to control a scenario template.
However, entirely new scenarios with new models or environments would be beyond the
capabilities of such staff. As such, the game scenario templates should be developed with
configuration in mind. Examples of configurable options can include:
-
time of day
number of casualties
types of wounds
options available for treatment of a patient
setting NPC behaviors (from a preset selection)
setting patient behavior (from a preset selection)
altering the state of the patient
equipment available
There are many variations possible, assuming that the scenario is developed in the beginning to
account for so many options. These options can be made compliant with SCORM so that the
entire scenario can be specified by a SCORM complaint LMS.
Page - 14 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
3.2.3. Summary of art assets to be created
What follows are the building block assets required for Phase I.
3.2.3.1. NPC Soliders (3)
The NPC soldiers will be server-controlled and have AI behavior. The soldiers can be textured
in different ways to create many NPC instances from the basic models. Equipment will be
mountable so that further variations are possible from the basic models. These will be animated
for movement around a vehicle, crouching, taking a firing position, prone, and various poses for
assistance with the wounded soldier, including carrying the soldier.
3.2.3.2. Wounded Soldier (1)
The wounded soldier will be a straightforward model for a gunshot wound above the right knee.
3.2.3.3. Medic Avatar (2, male & female)
A male and female version of the training avatar. Mountable equipment will include a heavy
configuration with backpack and a drop bag on the leg.
3.2.3.4. Humvee (1)
A basic vehicle.
3.2.3.5. Blackhawk Helicopter (1)
A basic vehicle.
3.2.3.6. Blackhawk Helicopter, internal view (1)
A basic vehicle but with top removed so that player can interact with patient while in evacuation.
3.3. Project Management
3.3.1. Phase I Tasks and Deliverables
The tasks and subtasks to be completed during Phase I are listed below in the order that they will
be developed.
Task
Task Description
BASE
T1
Game Client
Page - 15 -
Completion
Month
Maximus Prime, LLC
T1.1
T1.2
Topic # OSD10-H08
Proposal # XXXXXXX
T1.3
T1.4
T1.5
T1.6
GUI functional with test models
GUI functional with point of injury environment
GUI interface development for heads up display
Patient movement and vehicle interaction
Trauma Bag Simulation (configured heavy or light)
Equipment Simulation
Bugfixes and Modifications as needed for Phase-I
1
1
2
2
2
2
3-6
T2
T2.1
T2.2
T2.3
TCP Sockets Based Communication
Player Login & Authentication
Avatar Selection & Scenario Selection
Multiple players in same scenario
1
1
4
T3
Protocol Spec
Documentation of Spec
5-6
T4
T4.1
T4.2
Server Platform
Server load testing to 1,000 simulated players
Bugfixes and Modifications as needed for Phase-I
5
1-6
T5
T5.1
T5.2
T5.3
Art Asset Creation
Concept art & models for point of injury
Environment complete point of injury
Models for evacuation via Blackhawk Helicopter
1-2
2
3
T6
T6.1
T6.2
T6.3
T6.4
Scenario Development
Testing point of injury critical care scenario
Multiplayer scenario demo point of injury
Extending testing of both POI and evac scenarios
Extensions to scenario, addition of helicopter evac (option)
4
4
5
4-5
T7
T7.1
T7.2
Website Hosting
Hosting on web-site with login credentials
Extended web-based testing of application, hosted
3
4-5
T8
T8.1
Demos
Technical demo's of the system to appropriate parties
4-5
T9
T9.1
T9.2
Reporting
Final Report Writing and Phase I Deliverable Packaging
Write Monthly and Final Reports
6
1 thru 6
Page - 16 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
3.3.2. Phase I Development Details
Below is a detailed description of the development details for each development task listed above
in Section 3.6.1.
T5
Demonstrate the Working Prototype
4. RELATED WORK
4.1. Prior work on game engine development
Gunwale, LLC has already developed a game engine and client/server that can support a training
game such as the one requested in this SBIR. This work will be drawn upon to develop the
training simulation. Many hard problems have already been solved by Gunwale, LLC and this
significantly reduces project risk. Problems already solved by Gunwale, LLC:
-
Creation of a 3D rendering client and library using Ogre3D and additional C++ libraries
Creation of a specialized game server using IO Completion Ports (IOCP) and capable of
sustaining 50,000+ socket connections on a single server
Server-side integration to SQL database
Action / Notify Architecture
Decoupling between server and client
Server-side hosting of AI behavior
Seamless playfield system, allowing infinite movement in any direction without loading
screens
Single integrated terrain surface, using tiles & tile welding and procedural modification
Level of Detail (LOD) on terrain
AI control for any object
Thousands of server-controlled mobs
Art pipeline fully established and tooled, including bones and skinned models, Autodesk
3D studio output, and animation
Full login and authentication
Client camera control and user interface / HUD / GUI
Z clamping to simulate gravity
Procedural creation of environments, urban environments, buildings, etc.
4.2. Past Government Contracts
HBGary
RELATIONSHIP WITH FUTURE RESEARCH OR RESEARCH AND DEVELOPMENT
Page - 17 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
4.3. Measuring Phase I Success
HBGary will consider Phase I a success if you can demonstrate an end-to-end working prototype
of all the tasks laid out in the Work Plan.
4.4. Foundation for Phase II Work
Listed below are tasks we would expect to complete during Phase II:
-
Evaluation and certification efforts regarding DoD DIACAP and IM/T.
Integration with a SCORM compliant LMS
Multi-user squad scenarios.
Significant content development in the way of scenarios, including CCATT and Field
Hospital scenarios.
Significant content development in types of injury, including airway management,
sucking chest wounds, and triage scenarios.
5. COMMERCIALIZATION STRATEGY
Our key personnel, Greg Hoglund and Bob Slapnik, have a successful track record of developing
new software and commercializing it, including verifiable success with commercializing
software developed via three (3) SBIR/STTR Phase II projects (see Key Personnel and Related
Work sections of this proposal). Our past successes have hinged upon developing a usable
prototype that addresses one or more valued use cases. We have had past Government customers
add task orders and funding to a Phase II contract. Perhaps more importantly, we worked hard to
identify early adaptor customers willing to pay for software licenses. These early sales provide
critical customer feedback on how to improve the system and cash flow to pay for continued
development. With enough effort, time and good decision making the prototype evolves into a
mature product that becomes much easier to sell and at higher average sale prices.
We envision the possibility of a very large user base for the medical gaming system. All military
units down to the squad level face medical emergencies, so they must receive basic training to
deal with life and death situations. The web-based serious medical gaming system will be a cost
effective and productive way to train large numbers of military personnel. There are many
military emergency response units across the DoD that are potential customers. Furthermore,
military medical training organizations could buy the system. It would not take much to change
settings and scenarios to make the system applicable to federal, state and local emergency
medical response teams. Civilian medical universities and teaching hospitals will be candidates.
Medical equipment manufacturers and suppliers could use the gaming system to teach their
customers how to use their equipment. All of the above medical use cases would apply to the
export market as well. And when we expand our focus to include other types of training then the
market potential grows exponentially. Another revenue source will be to market our underlying
simulation system to other companies or organizations who wish to develop serious training
games, but lack our advanced software development capabilities.
6. KEY PERSONNEL
Page - 18 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
Greg Hoglund, Principal Investigator and Chief Executive Officer, Company Name
Delivered many training programs.
Exploiting Online Games.
Robert Slapnik, President, Company Name
Mr. Slapnik will serve as program manager and will lead the product commercialization efforts.
As Co-Founder and Vice President at HBGary, Inc. he led revenue producing activities to fund
early software development to early prototypes all the way through the evolution to mature,
widely accepted commercial products. Revenues came from competed and sole source Federal
contracts, business partner transactions and many software license sales to the private and
government organizations. Mr. Slapnik is formerly the President of Network Test Solutions,
LLC and President of Chesapeake Capital Corp. He has been marketing and selling complex
software solutions since 1982 and has held marketing and sales positions with Hewlett Packard
Company, Sequent Computer Systems, and NetIQ (formerly Ganymede Software). Mr. Slapnik
has an MBA and BS in Mathematics, both from Kent State University.
Kenneth L. Craft, Jr., Subject Matter Expert.
7. FACILITIES AND EQUIPMENT
The work will be performed at Company name facility at 3604 Fair Oaks Blvd., Suite 250,
Sacramento, CA 95864. Existing computers and development software will be used, thus no
equipment purchases are required. The facilities meet environmental laws and regulations of
federal, California, and local Governments for, but not limited to, the following groupings:
airborne emissions, waterborne effluents, external radiation levels, outdoor noise, solid and bulk
waste disposal practices, and handling and storage of toxic and hazardous materials.
8. SUBCONTRACTORS AND CONSULTANTS
HBGary does not anticipate using any subcontractors or consultants on this project.
9. PRIOR, CURRENT OR PENDING SUPPORT OF SIMILAR
PROPOSALS OR AWARDS
No prior, current, or pending support for proposed work.
9.1. Extra content
Page - 19 -
Maximus Prime, LLC
Topic # OSD10-H08
Proposal # XXXXXXX
Currently there are two good schools that both the Air Force and the Army go through. One is
for PHTLS, Pre Hospital Trauma Life Support and the other is the Special Operations Medical
Course. Also there are several "off the shelf" games that we have used that helps build "critical
thinking" skills as a medic.
When trying to incorporate the above into a "computer model" the hardest to design is the
tactical feel of what you are doing. On the video game model, it is "point and click" but there is
no "tactile" sensation of it. The user would have to have a 3D visor/glasses as well as a palm or
hand wired system that allows the user to make movement with his hands as if he is picking
something up or putting on a medical device (such as a traction or tourniquet). An example of
this could be electro sensing hand wear (gloves) that allows for 3D involvement in the
simulation.
Brooks Army Hospital has a "virtual surgery" program that allows students to work on "patients"
using real instruments but in a virtual environment. The other tool we use is the Sim Man which
is a mannequin based , controller operated tool that allows for many patient scenarios. An idea
could be to "marry" those two technologies to remove the controller and use the virtual
environment for the medic. Using goggle or a visor, you could provide light and input control to
the mannequin.
Page - 20 -