Taking Over

From SRASWiki

Jump to: navigation, search

Dear Continuing Developer,

Welcome to the Southampton Research Allocation Simulation (SRAS) project.

The basic premise of the simulation is a relationship between resources, consumers, events and time. An event happens to a consumer, and the user responsds by allocating a resource to that consumer. The level (rank) of the resource determines the completion-status (hereafter refered to as completion) of that event. Depending on the completion of the event, one or more events may be spawned later in that actors timeline.



The project has been running on and off for 2 years (at the point of writing). I'll briefly introduce the players as the (informal) documentation makes frequent mention of them.

Gary Wills : The boss, customer and funder Lester Gilbert : Project Manager Joe Price : Graphic Designer, ded the original graphics.

Chris McLean (aka Nursing Chris): Originai spec author. Mary Gobi, Sue Faulds : Nursing tutors. Mary is Chris' PhD supervisor.

Sebastian Skuse : Access team. Owns the redmine installation that SRAS war projfct managed and svn'd on. Russell Newman : Access team. Teresa's partner. Rewrote php code for the project.

Teresa Binks : Co-investigator in 2009, Project lead in 2010. Author of final edits to this guide. Chris Burns (aka Ginger Chris) : Co-investigator in 2009. Due to other commitments, spent very little time on the project. Phillip Applegate : Dev in 2010, did the engine rewrite. Chris Wills : Dev in 2010, did the front end. Novice programmer, so code may be a little non standard. :)


SRAS is a proof of concept project demonstrating the use of a simple turn based game engine in a learning context. The specification was originally given from the School of Nursing to replace a board game they used to train nurses. The idea has been adapted to allow the generic game engine to be used in a variety of different contexts with a redesign of the front end.

A more detailed spec can be found here.


We structured the project in several parts:

  • The scenario (written in xml)
  • The scenario editor (the user friendly bit that outputs the xml for the scenario)
  • The engine (written by Phil Applegate reads xml from the scenario, and from the user interface. Outputs xml for the user interface to render)
  • The UI (written by Teresa Binks and Chris Wills. Outputs xml for the engine to read and draws the output from the engine)

So, it is important to know that there are no method calls between the scenario editor and the engine. The scenario editor outputs the xml, the engine reads it. Asynchronously.

Project Structure Details

The project consists of three (or four) programs and three (or four) xml files.

The first xml file is the scenario. It is mechanism by which the user (lecturer) configures the engine. The first piece of software therefore, is the scenario author. We did a demo java version and then a php version, but it was pretty rubbish and didn't let you edit. One mistake and you had to start again. We triaged the author as a less important.

The second bit of software is the engine. After initialising with the scenario, the engine outputs the second xml file, toDraw, which lists all the actors on stage, where they are and what they are doing. The third bit of software, the front-end, picks up that xml file and draws the corresponding image. The user then manipulates that set up. Once the user confirms, the front end outputs an xml file reflecting the state of the stage. This is the third xml file, toProcess. It is delivered to the engine and the engine processes it and produces a new toDraw.

The forth (potential) xml file is the log, showing all of the actions the player performed. The forth (potential) bit of software is the log analyser. We did not start either of these components.


Scenario Editor:

  • There is currently a working version of this written in Javascript and PHP.
  • The editor stores the data in a PHP session and then when the user presses write scenario the scenario XML is written.
  • The editor does not currently allow you to edit or delete data, which presents a problem if the user makes a mistake on input.
  • The editor does not take into account clashing events.


  • Phase 1 is done.
  • Trumps are not done. These are harder than first thought.


  • Phase 1 is done.
  • Staff breaks are not working, the staff room is not functional at present


Okay, there are tons versions of files. I apolopise. In summer 2009, I was pretty much the only dev working on the project. I built the first version of the engine in java and then in bad, beginners php. Russell reworked the code into OO php.

The next year, Phil rewrote the engine, based on the code from the previous summer. Teresa and Chris did the front end. In the last cople of weeks, the plan was to refactor the code. A new version of the engine was made, but the front end refactor didn't get past the planning phase before time ran out. So, there are versions all over the place.

The working versions are at:

The bits you might get stuck on

  • Event Completions
    • An event can complete in one of three ways. Capably, Incapably and Expirey.
      • If an event window reaches zero (runs out if time, see below) before the duration of that event reaches zero, the event EXPIRES
      • If an event duration reaches zero and the allocated resources are equal to or higher than the required resources, then the event is COMPETENT
      • If an event duration reaches zero and the allocated resources are lower than the required resources, then the event is INCOMPETENT
  • Duration vs Window
    • Duration is how many turns it takes to complete an event once the required number of resources (regardless of rank) are allocated. An event will not start until the right number of resources are there, but it will start if those resources are underqualified.
    • Window is how long a person will wait. Once the window is zero, the event expires, regardless of wether a staff member has been allocated and regardless of when that staff member was allocated. If that patient will die within 6 mins if they don't get cpr that takes 3 mins, and if a resource is allocated 4 mins in, that patient will die.
  • Trump cards
    • Trump cards are the idea that the user can have "phone a friend" style oppourtunities. This might result in an additional nurse appearing on ward, a patient washing themselves rather than needing assistance etc. Trump cards may have conditions about when or to what they can be applied.

Responsibility modeling

  • Front end
    • Allocation validity
      • Who/what can be allocated to who. It might be the case that equipment can be allocated to an event, or that a patient can make another patient a cup of coffee. Also, a "sort it out yourself" trump card shouldn't be applied on a heart attack patient. The front end is in charge of enforcing any constraints.
  • Engine
    • As a general rule, the engine should present as much information as possible to the front end. The front end can choose how much info to disregard.

The new paradigm

After the v1.0 was created, we evaluated the model and came up with an improved model. We never really implimented it, though there was a version of the engine that outputted newToDraw. Ignore it and start again.

The following are ideas for a better model

  • Consider not having explicit resources and consumers. Have everyone (and everything) be an actor with a type and a rank. That way, patients can get each other coffees and the phone can have an incoming call event.
  • Put in anchor text. This would be a feild that the front end associates with a space or coordinate. The anchor would initially be presented to the front end along with a patient. The front end would output the anchor with the actor it recieved. The engine would not process the anchor, but would simply mirror it back to the front end. With this abstract location awareness, the front end would better be able to handle a patient going off ward etc.

The end?

The end of this summer's work, and the beginning of your involvement :)

Teresa Binks tb2@ecs tb1206@ecs

teresa at teresabinks .co.uk <-- personal email, but likely the one that will last longest. Use if the others don't work

Personal tools