Triage (Project 3) Post Mortem


This project was another group project similar to the last one (the board-video game hybrid), where were tasked with finding an audio track and 5 colour palette. Our findings then had to influence/inspire the game that we were to make. The colour palette had to be the actual colours we used in the game and we had the option of including the audio track as well.

What went right
  • The Patient & GameManager scripts
    The Patient script did everything that was needed for a patient to do. Although looking at it now, it possibly could have been split into multiple scripts but I just never thought of doing so...
GameManager gmManager;  
public enum Type {  

public Type type;  
public bool  
    dead = false,
    dieing = true;

//The lifespan is randomly generated between the min and max values below
[Range(0.0f, 200.0f)] [SerializeField] float lifeSpanMax = 60f;
[Range(0.0f, 200.0f)] [SerializeField] float lifeSpanMin = 20f;
public float  
    currentLife = 0.0f;
[SerializeField] float percentage;

//Generated between min and max values like Lifespan
[Range(0.0f, 20.0f)] [SerializeField] float treatmentTimeMin;
[Range(0.0f, 20.0f)] [SerializeField] float treatmentTimeMax;
public float treatmentTime;  
public bool treatment = false;  
[SerializeField] GameObject healingParticle;

//Patient Timer
[SerializeField] GameObject spotLight;
[SerializeField] GameObject uiObj;
[SerializeField] Image timer;
Dictionary<string, string> colourCodes = new Dictionary<string, string>() {  
    { "Burns", "#FF0000" },
    { "Neurology", "#00FF01" },
    { "Oncology", "#FFF700" },
    { "ICU", "#0041FF" }
float spotlightTimer = 0f;  
float deathFillAmount;  
    deadToggle = true,
    cureToggle = true;

Variable list in the Patient script.

I tried to use [SerializeField] where possible on variables that needed adjustment in the inspector but had no relation to other scripts. Doing this allowed the designers to tweak the values needed which improved their workflow.

In the end the patient script added a lot of logic behind the patients which is exactly what was needed, I would probably re-write it slightly since there's some code there that could really be more helpful in another script if there was more time.

Players had the ability to switch control/possessing other patients that were slowly dying and needed medical attention. All the patients existed in a list which was modified when a new patient spawns and one dies/gets treated, so the list kept getting modified constantly. So as a programmer for this project, I felt like I did my duty in creating effective but possibly tied together scripts for the designers to modify and the game to use.

  • The Documentation
    The Documentation produced mainly by the designers with input and corrections by the whole team, was mostly on point. The documentation explained parts of the game that I was confused on well and guided myself back in the direction of where we were planned to go. It explained parts of the game that were never achieved or looked at probably because of time, but since it was addressed and was thought out allows the project to be picked up again and possibly finished.

The only thing that concerned me about it was that it was updated once according to the change log on the first page throughout the project. So either the other designers and programmers didn't look at it or simply had an exact clear image in their mind of what was expected.

What went wrong
  • Team Communication
    Team Communication was quite a let down for this project. And seems like it's following me from the last project sadly, but while we had a discord. It rarely was used to find out who was working on what. I was Project Manager so I'm going to take the blame of following up people with their work since I practically never did that, it's something I'm not proud of and wish I did so.
    The other team members possibly lost confidence and determination in the project when we kept having hardship after hardship with the damn gurney movement not responding the way we want it to. I definitely didn't feel motivated to work on the project which most likely led to myself not following the other members up with their work because of it.

Discord was used as a, Hey, are you going to come in today? or Hey X, Can you get Y working today?. They'll respond saying they could and the next few days no work had been done. So there was probably a big lack in motivation for this project. We had such a good premise where we could take something so surreal and make fun of it in a humorous way...

  • Gurney movement
    This was the largest problem we had during the project, even everything I've worked on up to this point. The Gurney's were originally moved by clicking, holding the click and then dragging them around the map, the problem was that the script used for it had some ridiculous bounce physics.

During the last week of development, we decided enough was enough and moved over to a control method with a gamepad. I had to implement a switching system between all the patients so players can actually control them which wasn't perfect.
The problem with this was that even though it didn't make it to the final build of the game, it chewed up something like 4 weeks of the 6 week development cycle. Every week was improving the gurney movement since that was the most frequent piece of feedback we received.

If only we noticed it sooner we could have ditched it sooner and gotten that time back...


While we handed in what we had done, I'm personally not all too thrilled of what we did. There were some questionable design choices and project management was in shambles, communication was kind of there but had no real incentive to get going.

The Future

For next time, something like a weekly report/catch up would be perfect for finding out where everyone is up to and working out what needs to be done for the next week before the next weekly report. Something similar to a system like this would help with organisation and management.

The other aspect to learn is to not spend several years working on one thing, constantly fixing a feature after every playtest should be a sign that, that thing is the issue and either needs to be reworked or axed from the game completely. So being aware of the feedback and how that feedback affects the features will give an advantage to find what needs to be reworked rather than fixed.

Tom Lynn

Read more posts by this author.