Test ecto

Test

update

Over the last week we have made many forward steps in our project. Everyday for the last forthnight Dave has been building new buildings and objects and I have been creating new npcs and animations. We have now build up a very healthy library of Difs and Dts's.
We have not included any of theses Difs as of yet in our mission file as we want to keep it a fast as possible as we continue to add to the code.
The animations have proved difficult to make but now they are working they add alot of life to the simulator. Another aspect Dave has been working on is the lighting within the game. As it is meant to be based at night time he has been building a new night time sky and coding up the fog and ambience settings to make the scene look correct.
The Examination section has hit a snag as there will be too many options to portay as buttons on the screen. We are now trying to combat this with multiple layer drop down menu boxes. As of now this is still a work in progress.
Over the last few nights I have been working on adding different types of npcs. Before we could have many of the same model doing many different things and now we need to have different models doing different thing. This proved a little bit tricky as I had previously coded it up for only one model. I over came the possibly of having to write a new .cs file for every Model with inheritance. As all the models would need to have the ability to call the same animaitons and the same functions, inheritance made it possible to code this for one model and have the rest call off this code.

update

Over the last week we have made many forward steps in our project. Everyday for the last forthnight Dave has been building new buildings and objects and I have been creating new npcs and animations. We have now build up a very healthy library of Difs and Dts's.
We have not included any of theses Difs as of yet in our mission file as we want to keep it a fast as possible as we continue to add to the code.
The animations have proved difficult to make but now they are working they add alot of life to the simulator. Another aspect Dave has been working on is the lighting within the game. As it is meant to be based at night time he has been building a new night time sky and coding up the fog and ambience settings to make the scene look correct.
The Examination section has hit a snag as there will be too many options to portay as buttons on the screen. We are now trying to combat this with multiple layer drop down menu boxes. As of now this is still a work in progress.
Over the last few nights I have been working on adding different types of npcs. Before we could have many of the same model doing many different things and now we need to have different models doing different thing. This proved a little bit tricky as I had previously coded it up for only one model. I over came the possibly of having to write a new .cs file for every Model with inheritance. As all the models would need to have the ability to call the same animaitons and the same functions, inheritance made it possible to code this for one model and have the rest call off this code.

update

Giving the user the choice of sex has worked perfectly for us after a few hours of tinkering. By combining the selected option in the startmenugui with server side commands we have this option fully functional. One problem we had with this was attaching a variable to each of the options. This worked perfectly with tick boxes as these returned yes or no (0 or 1) but for the useability factor we decided we needed to implement radio buttons so the user could only choose one or the other. The problem with this is variables cannot be attached to the radio button as they are grouped so for each option(radio button) we had to write a command attaching the same variable to each option. This variable would then change dependant on the button selected.We have a male Doctor built and nearly ready but for now we are using the test model as our female.
Another aspect we are bringing into our simulator is makinmg it dynamic through choice of user standard. We have added this to or GUI also with radio buttons as above. For now the selection of a standard button only edits a varialbe but the variable as of yet causes any action. Our hope is for this variable to add or remove timers and buttons to vary the difficulty within the simulator.
Our Main character is finally getting closer to where we want him/her. As I said before we fixed the animation errors and the character is fully programmed into the torque world but the problem we have now is torque is built for fps where the characters run from place to place so when we move our doctor he runs along. We can slow the doctor down by programming him to slow dowen but this will only slow the aniation down so it looks like he is runnig slowly. To fix this problem we are going to have to make our own walk animation. This is a very difficult process and has to be done in max.
To make the animation we had to load up our doctor remove his skin only leaving the bones and create the animation. This process will be shown in the documentation.
Again after alot of tinkering with frames and a basic piece of coding we have our doctor using our walk animation.
We then attempted to get our npc's to also use this aniamtion, unfortuneatly
this does not seen to work for now.
All the time we are working on our decision tree which is slowly coming together.

After being at the stage of having a doctor built in max and being able to get him across to torque only as a static object we began working on the naming conventions of of the biped.
In order to understand the naming concepts of the bones we had to try and find a preboned max model that would export correctly.
After finally finding a correctly biped "test" model we focused our time on trying to get him fully functional in torque. So we set up the test model to export and then exported it. Unfortunately the test model would not export correctly so we began thinking the probelm lay outside max. This is when we relised we had problems in our cfg file. We updated the cfg file and finally our test model exported correctly. In order to get our doctor fully compatable with the animation(DSQ) files we stripped our test model just keeping the bone structure and adding our doctor on top of the bone structure. Unfortunatly this would not work as the test model was made from individual limbs (action figure) and our doctor model was made as a single mesh model. The one good thing that came form this attempt was the schematic view of each model became more understandable to use through comparison. The next step was to try and locate a new test dummy with a one mesh figure. This was not possible as any model that was made as one mesh is protected to stop people duplcating them and selling them on. We finally found a resource that enabled us to import a bone structure to max. This helped us greatly as we were then able to attach our model to a bone stucture. This was a slow process as for every bone movement in an animation we had to define how much each corresponding pixel on our model was to move. For example if the character was to swing his arm up in the air all the pixels in the arm would have to follow the arm biped but pixels in the back and the neck would have to move slightly. When our model was ready we exported him expecting him to fully work but he didnt. He exported and would attach to an animation but when he was programmed into torque his animations played 90 degrees to the right and he floated three feet off the ground. Straight away we assumed we had messed up something in torque and began moving nodes and bounding boxes, everytime exporting but to no avail. So we then moved our attentions to the to see if the problem lay in the coding side which brought us to the cfg file. It was here we finally relised that we were exporting a node in our model that was not in our animations. We attempted to delete this node in max but it would not export so we moved back into the cfg and coded in to leave the node in the model but not to export it into the .dts file. Finally we had a fully functional doctor although a bit rough around the edges.
Now we had the ability to create charaters we felt we should attempt to give the user the option of which sex the user wishes to play as. This would be very difficult but we feel there is a need as there is as many female junior doctors in our targeted (people we want to use the game). The problem arises as ingame changes can be done by trigger events etc but this would be a dynamic pregame change. We have a few ideas using the pre start gui to display the user with the option and then use variable selection in initiate which model and animations to use as the main character. This is all still hypothectical and we are going to work on it for the next few days.
The second main section we are working on is the decisoin tree for the treatment of each patient. We have this decision tree on paper from our last meeting with Deborah. We also hope to have different decision trees depending on the difficulty level the user wishes to use.
We have begun building this decision tree within the game using triggers, timers and basic variables to record the user's input. This is a part of the game that we will spend alot of time on as it is the focal point of our training simulator.

Update

The hospital is now fully built. We had a lot of problems with the texturing of the hospital as the textures would appear fine in the Quark but when we opened it up in Torque and relighted the scene some of the textures had disappeared. We eventually figured out that this was because Torque requires all textures to be to a power of 2. We then changed the problem textures to be 256 by 256 inside in Quark and re-loaded the hopital in Torque. We still have to place the light nodes for the hospital correctly but are confident that there will be no major issues with this.
We have also gotten triggered sounds to work in Torque so now when the doctor approaches a patient (inside of the trigger area) or another doctor we can have a soundfile play and we can also have another sound play as he exits the trigger if we need to. We are now trying to implement a timer in the trigger to count how long you spend in the trigger and vary the resulting actions based on this time.
We have now added an option to the start screen of the game where the player will be able to enter his name and this information will be used throughout the game to identify the doctor.
Also, we have finally built our doctor character in 3ds Max and are able to bring him into Torque. However we have not been able to animate him using the .dsq files. We believe this is due to Torque requiring a certain amount of specific bones and nodes in order to match the .dts and .dsq files. Even when we edit the CFG file to bring in the required nodes and bones we are getting an error from Max. We have found a plugin for max that adds the correct bones for Torque but are having trouble getting it to work and we are currently working on this issue.

2nd Meeting with Deborah

On Monday 5th Febuary we met again with the doctor in CUH following a suggestion of hers that it might be more appropraite to set the game in an on call ward rather than an A&E as this experience would more accurately reflect the type of situation an intern doctor would be faced with and also meant that one person would be responsible for making all of the decisions which suited our game a lot more. This means adding a ward area to the in game hospital we have already designed and built as well as restructuring the procedure for dealing with a patient.

Below is a rough outline as to how we see this new procedure working :

The patient is a 45 year old male, one week post-op, somewhat overweight, driven in by a member of his family. (note that age and physical description of the patient has changed in order to achieve a more realistic case)

The nurse presents the player with the following information:
1. Lower abdominal pain
2. One week post appendicectomi
3. Feeling nauseous
4. Feeling unwell

The nurse may also provide the doctor with the patient's recent vitals and bloods, and if she doesn't the doctor(player) should ask for them:
1. Mild tachycardia
2. Heart rare : 105
3. Blood Pressure, stable, 135/85
4. No temperature

The player will then have the option to look over the patients notes and meds and these should be utilised in order to achieve a good outcome in the game.

If the player chooses these options he will be presented with the following information:

Meds:
On Tranadol (painkiller)

Past Medical History:
High cholesterol - on a high dose of medication for 1t (14mgs)
Past history of alcohol abuse
On a binge the night before
Was on a binge the night before the operation
Attributed some of the pain to the alcohol drank the night before
Smokes 10 - 15 cigarettes a day
Married, one child

Family History:
No major diseases
Uncle died suddenly in his 40s (maybe heart related)

It is now, and not before reviewing the patient's history and meds, that the player should talk to the patient and review his symptoms:
No headaches
Some dizziness
No urinary symptoms
Tachycardic

The player should note on examination:
Pale
Pain, mainly epigastric
Unwell
Sweating
Abdomen mildly distended, not very tender
Bowel signs are present
Respiratory system is clear
Chest is clear
Cardiovascular heart sounds 1 & 2, no murmurs


Following the examination the player will have to access the patient as being "well"(monitor for a while), "unwell" or "very unwell"(call arrest team).

The correct assessment for this scenario is "unwell".

Now the player will be presented with a number of options. Some of these options will have sub-options. The options are:

Get ECG (correct)
Don't get ECG
Get Bloods -> Now (correct) or In The Morning -> What types of bloods?
Get Chest X-Ray -> Normal or Errect
Get PFA
CT Abdomin

If the player makes the right choices he will get teh appropriate feedback. We will be able to return the results of the ECG by displaying a static image of the graph and by looking at this image the player should be able to identify the key information it represents.

The player will then be asked if they are concerned about the results. They can reply:
Yes (correct) or No

If they answer correctly they will be presented with a list of potential treatments for the patient such as:

Afib
ST Elevation Mi
Non ST Elevation Mi (correct)
Pericarditis

If the player chooses correctly the player will win the game but if the player chooses incorrectly the player will lose the game.

If will also be possible for the player to call for assistance at any point throughout the game although this will only be the correct action at key moments in the procedure's timeline.

This is just a rough outline of the things we may or may not include and we will be tightening the overall process as we move forward with the game.

Meeting in C.U.H

We met with Deborah Ryan in CUH on Monday 29th January and she outlined a typical case of a patient. David Murphy also attended this hour meeting. The meeting was very helpful as Deborah was able to give us a better insight into the day to day workings of a junior doctor. When we were happy with the information we received we were given a tour of the A&E by Ger. He showed us each section of the A&E and told us the purpose of each section and what kind of tasks were carried out within.
We were then given a talk by a nurse Paula about the triage area and it purpose. She explained the cycle which each patient goes through in the A&E.
The afternoon gave us much needed information and a better insight layout and atmosphere of a hospital.