Screenshots of a room I created in around an hour in Just Leap In – visit it at http://www.justleapin.com/shares/9299:7CWxWoP4

It’s as close as I’ve been able to get to a hospital ward with the available furniture and objects. The ability to import your own models is on the list of features to come.

The boxes in the top image appear as the room is loading – rather cute really.

It’s in Beta at the moment and I haven’t taken a huge look around but it is incredibly easy to use and the list of features to come is really impressive. I’ve been in touch with the developers and they seem very switched on and friendly.

I’ll post more about it when I’ve had a chance to play more.

I’ve also been able to embed the world in my other blog (edublogs is a little paranoid about embeddable content) – check it out at http://couchmedia.blogspot.com/2008/12/just-leap-in-diy-virtual-space.html

McGrath and Hill describe the process they went through in developing an emergency response simulator using the Unreal Tournament game engine – from design to development and some of the issues they confronted along the way – something which seems not a million miles away from what I’m trying to do.
(Perhaps less simulationy but there are still a number of commonalities)

“The simulation involves multiple
emergency response players at the scene of
a small airplane crash with 30 casualties.
The player objectives developed thus far
consist of fire suppression and primary
triage. Players must locate and categorize
the casualties into one of four treatment
categories. The victims are tagged as red
(immediate), yellow (urgent), green
(delayed), or black (fatally wounded). For
the game environment, a terrain model
(map) based on a real-world airport was
created from digital elevation data, satellite
imagery, and local engineering data. The
Karma physics engine, which is part of the
Unreal distribution, was used to define
object behaviors such as fire hose
dynamics.”

This is a great example of the usefulness of games in learning – particularly simulations – because they allow you to recreate situations that would either be expensive or dangerous.

“Synthetic environments can
enhance tabletop and command post
exercises by providing an objective,
dynamic, virtual world containingsimulated but adequately realistic people,
objects, and events. Emergency response
technologies can be prototyped and
evaluated using synthetic environments as
well, by providing a safe, virtual “proving
ground” for new technologies. The same
synthetic environments could be used to
develop training systems.”

They discuss the process of using the Unreal Tournament editor and working with APIs and plug-ins for other tools – something I’m avoiding so far for the large part with FPS Creator. There is also a reasonably detailed technical description of the technical process they went through in modelling the actual terrain of a New Hampshire airport for the game.

“First person shooter games are organized
around “levels”, with the idea that a player
will complete the objectives of one level,
and then move on to another level with a
new environment and challenges. In each
level, players move through the
environment “picking up” weapons, health,
and ammunition. Multiple players can
move through levels, interacting with the
environment, objects, other players, and
non-player characters (NPCs).”

It’s interesting to note that they have had to deal with some of the same issues that I have – namely trying to convert a tool/engine designed for making “shooter” games to another purpose.

The assumptions made by the designers of
the game engine tend to dictate the
available choices of mod developers. For
example, the easiest way to represent a fire
hose nozzle is to model it as a weapon that
“destroys” a fire, since the game engine is
based on the assumption that players carry
and fire weapons. It is counter-intuitive to
think of a fire hose as a weapon, but within
the constraints of the game world this
makes perfect sense.

Other unique issues arise in this regard as well:

“However,  the  interaction with  the  nozzle
“weapon”  has  been  problematic.
Specifically,  the  hose  should  be
constrained by  its attach point on  the  fire
truck and by the position of the firefighter
holding  the  nozzle.   Likewise  the
firefighter’s motion  should  be  limited  by
the  length and properties of  the  fire hose.
This  complex  interaction  has  proven
difficult,  in  large  part  because  player
motions  are  not  normally  constrained  by
the “weapon” they carry.”

In looking at further developments of the game, they are considering the need for cooperative play to simulate the process of carrying stretchers – a task sometimes undertaken by 4 people at once. (Good luck with that one They are also mindful of the AI of NonPlayer Characters (NPCs) by using them in a simulation for management of the emergency scene:

Improved NPC intelligence could include
two-way communication between players
and bots. More intelligent NPC behavior
will allow some of the first responder roles
to be performed by “rescue bots” and
allow actual players to act as scene
commanders. This will enable command
post exercises, where scene commanders
observe the scene, interact with rescue
bots, and help incident command build
situational awareness through normal
communication channels

Overall, they seem to have developed a pretty good understanding of what they are working with.

“Benefits include low user
cost, impressive graphics and sound,
accessible networking protocols, and built-
in scorekeeping for after action review.
Limitations include the significant
modeling and AI tasks associated with
character development, and the constraints
of the weapon/shooter paradigm which is
the foundation of most first person shooter
games. A relatively newer gaming
paradigm, the massive multi-player online
game, is founded on the idea of synthetic
economies and more peaceful interactions
between players, and may be a more
promising platform for simulation
development as it matures.“

Go on – guess

I’ve spent a good part of the day battling with the FPS Creator segment editor, a tool that allows you to create your own walls/rooms/floors and so on in FPS Creator. This largely came about because I liked the wall of one pre-made segment and the floor of another and (not properly reading the manual) I floundered about for a few days before discovering that you can’t actually do this.

Fortunately now I can take the mesh (the physical framework of the 3D object, generally a .x file in this instance) from one section (wall, floor, ceiling etc), stick it next to the mesh from another to choose my own textures (the flat part that sits on the outside of the mesh and makes it look like whatever it is that you want it to look like – generally a .tga or .dds file).

Of course,  the provided instructions neglected to mention that for the FPSC Segment Editor to recognise your specially created textures (whipped up in Photoshop and converted using the beautiful DDS2 converter), you need to label your textures blahblah_D2.tga or blahblah_D2.dds – fortunately the FPSC forum came to my aid.

All in all, this was a great practical example of discovery learning – just knowing enough to get started and identifying the new pieces of knowledge that were required in the process of doing it.

I also had another design idea the other day – by placing each separate mission on its own individual level and having the player progress to the next level (which is just a cut/paste of the initial level but with different audio files and resources), it’s possible to make the experience a much deeper one. (The initial problem was having the player going up to an NPC – non-player character – for information and having a limited range of responses, which would have been tied only to a single mission).

Nice to feel like this is getting somewhere.