As a team member this tri, I did pretty well. I made sure that I was available to work at any time, as much as I could, and employed the most optimal solutions possible, to save as much time working as I could. I did spend too much time on myself, though, and while both of my major projects have been successful, i did not put any time into side projects like i should have been doing, nor doing blogs, and for this, my grades have suffered.
While I am very loud, I have behaved reasonably appropriately, done my best to network, and correctly managed the time that I did spend working, not wasting it on less useful systems. I also organised several days of working together as a group with my cohort to ensure that as many of us as possible were able to get the more difficult LO’s done and completed, which was reasonably successful for those who were able to turn up. I have also helped some of my classmates outside of class with their work, helping them to understand it or giving them a point of reference for them to work from
How I did as a programmer
The two main projects I worked on went in different directions. for slime herder, working with another programmer, we did not write up a TDD, and only basically planned out what we needed to do before beginning the programming. The resulting code was a ‘game controller’ script with ~50 functions in it, awful naming conventions and little to no notes explaining what anything actually did. I felt a little too rushed to get the job done which led to this, along with no time (allocated by myself) to actually go back and fix things up before they got too complex and intertwined.
I also worked on the level generation for Incapacitor. I had time to plan out how this would work, and how it would meet the design requirements, and it went through a complete rebuild, meaning it was able to be designed even better. I was able to abstract it as much as possible, pulling out almost everything it does and putting that into its own function. I have put notes in for nearly every function & statement, and I feel very confident that if I need to go in anywhere and change how the generator works, I will be able to.
This second project is not how I always work, but was a goal for my self-improvement from last tri, and proves that I am capable of it. In future, I will endeavour to make this the default way that I work.
My creative goals over the last 3 months have been the following 4 projects:
Killbot tournament
This was the killbot tournament that was laid out to our class at the beginning of the trimester. There were two sections, one focussed on target prediction & accuracy, and one focussed on pathfinding. I came 4th and then 1st, and I am very proud of having done so well.
SuperSprint
This was a side project I pitched near the beginning of the trimester, as a project that was designed to show off an animator’s ability to create models, textures, and animations for use in a game engine. The project would also be set up to allow for as many animators to build for it as were interested, so it became an endless runner, that randomly spawned in sections of road and obstacles, and the animators would only have to create about 7 separate models, one being a skinned character. These would swap all swap out, to show off another animators work. Their goal was to make a model look as good as they could without causing drops in framerate, so a model with a low to medium poly count, but with high quality and detail textures, including maps for the PBR standard shader in unity.
I Remember
In this project, I was 1/2 of the programming team that were ‘contracted’ out to build this game for a team of designers. This was our first experience in having tasks given to us without really understanding how it was meant to all come together, and this project went through many iterations, so we ended up doing our best to make our scripts as modular as possible.
[over]clocked.
This was the CIU project I worked on. Its design was to be an interactive experience describing a possible future incorporating transhumanism and corporate control. I worked on it with and animation student and a film student, we worked out the design as a group and I did the programming for it.
The things I did well
Scope:
I did have plans or desires to work on more things, however, the projects I did work on were completed on my end because they were scoped fairly well, and were easily reduced in size when necessary. I completed my final killbot about a day before it was due, and was able to switch my focus on to my side project, which was scoped with a scalable amount of animators in mind, and very much treated as a side project (read: the first thing to be thrown under the bus). It was still a huge project, being almost half a gig in size from the audio files and models, and there were only a few people who ended up providing work.
Design:
The three projects that I took a design lead in went very well. The killbots were pretty simple, but there were three things I implemented that helped me win. The first was the importance and use of capturing data on the stats given to the bot, to identify the most useful stat build for my bot in particular (this was even useful for the bots of others, increasing their win rate by about 50%). I also chose to cover up my lack of perfect accuracy with a burst fire strategy, to increase the chance of hitting my targets, which increased my win rate immensely. I also chose, in the maze, to have my bot only scan in its cardinal directions, greatly increasing my chance to spot a target, these three things combined brought me victory.
I was able to design a decent game out of the need to display many people’s work in Supersprint, with the ability to have a scaleable amount of animators working on the project (including accounting for any that would drop out half way through).
I worked very hard on the design for overclocked, in helping polish up the main ideas we had for the game, helping figure out how to best use every team members abilities effectively and getting the team to get the work done on time, including rescoping the project and redesigning it to fit the theme still, or create an even more meaningful experience out of it.
Programming:
The most major things I did right in programming was learning how much I already knew about it, like how to reference and dereference in c++, something i was struggling with when we were first learning about it. I was also doing really well with planning out a project and its programming requirements. While not under stress, I was able to plan out a project with Rohan, and we coded together, making our scripts very accessible to each other, full of notes and easy for each other to use.
The ways I have improved
Seeking help when needed:
This was very important during this tri, as there were a few times when my efforts would have failed had I not sought help. Both Greg and Iain helped me out with some very complex scripting, something that only took them around an hour, would have taken me days to work through, something I didn’t quite have the time for. I was also able to receive help from my peers, like Harry for help with design questions, and Rohan and Chris for audio implementation when I started the endless runner project. Chris and Rohan ended up working on the endless runner with me, which was extremely helpful, I would not have had a hope of getting the project done if I had have had to do the audio system for it as well, not to mention I wouldn’t have been able to implement a solution as elegant as his.
Running a project:
I did run the project, though, and it is complete. I would have liked to have been able to get more work time out of more people, and had more model sets completed for it, but that can’t be helped, the animators especially had a lot on their plates this trimester. To have had so much work done by everyone is impressive all the same. While I have successfully worked on projects together with teams before, this was the first project I completely headed myself, I am certain I have grown better at it.
Working with others in code:
Previously, my code has been difficult to decipher or use by others, it has been very ‘thrown together’. While I’m still not very good at avoiding that, especially while stressed, I am getting much better. I have identified the extreme usefulness of planning out a project, like with the use of a TDD to identify how certain processes and functions will interact with each other.
The things I did poorly
Motivation:
I was lacking in motivation for the entirety of this trimester. There were times where I needed to start work but wouldn’t for the entire day, and this would stretch on for a couple of days. I still worked hard enough to get my work done, the essentials, but I wasted time that could have been used to practice, research or create even better things. If I had of had the endless runner completed earlier, it may have convinced some more of the animators to complete their work.
I often feel very tired for little reason, or get distracted by games or facebook easily, and I need to work on finding my focus quicker.
Research:
I barely did any research for anything that wasn’t immediately essential this trimester. I know I can find any information I need as it arises but I have a problem with just looking up things for fun, in my spare time. This means I’m usually not learning much more than what is presented to me in class, and don’t just rock up with brand new information. I am trying to fix this by getting into projects that would require me to do things I don’t already know about, like displaying video streams in unity, and setting up dynamic audio tools or text display systems (in overclocked and I Remember). I will continue this trend over the next trimesters.
I barely touched shaders:
One of the main topics this trimester was to play with shadertoy and create our own shaders, getting used to using the language, and working around there being no switch statements, or it not being able to hold up and wait on other sections of code to complete. I get the idea of how that works, but I didn’t make any shaders and need to spend some of my own time working on them, especially if I ever plan to be a tech artist.
Identification of a failure in project management:
Once again, this trimester I decided to step back and let the designers design and run the project, and this meant that even though I could see that the project was a rolling dumpster fire from the beginning when it came to project management, I failed to do anything about it to ensure the project got back on track, until it was almost too late to do anything about it. The project suffered heavily for it, and although it was completed, it is a shadow of what it was meant to be.
How to avoid those in the future
Be the project manager:
From here on out, I’m going to try to be the project manager whenever I can be, so I can get as much practice in being one, and to force myself into learning how to best manage people while also taking a lead role in programming for projects. The only time I tend to get anything done is when I’m sure I am out of time to, and when I know that people are relying on me to do it, even to help keep them motivated to do their work. Leading by example is a great way to light the fire under your ass.
I previously spoke about ded reckoning in an earlier blog while I was working on the killbot for our tournament. Well, I won the tournament for the pathfinding section and came fourth for the target prediction section, but i would like to talk about the research and implementation of the ded reckoning system itself.
What is ded reckoning?
ded reckoning (or deduced reckoning) is used in navigation systems and is the process of calculating one’s current position by using a previously determined position, or fix, and advancing that position based upon known or estimated speeds over elapsed time and course.
Dead reckoning can give the best available information on position, but is subject to significant errors due to many factors as both speed and direction must be accurately known at all instants for position to be determined accurately.
This sort of system isnt often used for target prediction, because of the cumulative effect that errors will cause over time, however, if you only need to know where a target will be in a second or less, it can be very cost effective.
This is why it is used for dogfighting games, to display to players where they need to aim to accurately hit a target. Here is what they are displayed as in war thunder.
The reason it is needed for this situation, is the bullets have travel time, they will not immediately complete their flight path the second the trigger is pulled, so we must lead the target. However, this can be pretty hard to do, as judging distances from a screen isnt quite what our eyes are designed for. Displaying a simple, predicted flight path target for players to fire at makes the game much more accessable for every player.
What its doing, instead of using hard information to determine current position, it uses assumed information as well. It takes the current speed and direction and acceleration, the distance from the gun, and the bullet speed, and uses that info to decide, based on how long it would take a bullet to get there, how far ahead the player should lead the target to accurately hit them, and displays that position.
How did I use it for my killbot?
As we saw in the last post about my killbots targetting plans, this is what is happening behind the scenes. The killbot gets 2 scans of an enemy in the previous two turns. from this it can assume a speed and direction. (using three scans would have ensured complete accuracy though, which proved to be more useful as that is what won the tournament focussing on prediction). The simplest solution is to then determine how far the target is from my killbot, and how many turns it would take the projectile to travel that distance, and then shoot that many turns of the bots current predicted path ahead of it, however, the bullet’s travel time itself was not being taken into account for the new target. I has assumed that this would be ‘close enough’, but it was throwing my accuracy completely off. I could also not hit anyone who was always moving along a curve, but did not acocunt for this.
The problem with the bullets own travel time was that it kept adding more distance to travel for each turn it needed to travel. This looks a lot like Zeno’s paradox, Achelies and the tortoise:
So to account for this, what we need to do is, using the target prediction that we have, test to see how close the bullet will be to the enemies predicted path, for up to 60 turns, and once we find the closest that the bullet can get, use that angle. This means that the bullets travel time is now taken into acocunt. it still isnt perfect, but by including burst fire into the build, it made my bot a strong contender, coming 4th for the target prediction section.
Below is the block of code i used to converge the bullets path and target path as close as possible.
for (int i = 1; i < 60; i++)
{
tempMagnitude = ((currentPos - input.position) / i) + tempVelocity;
if (GetDistVec2(tempMagnitude, checkVelocity) < GetDistVec2(bestMagnitude,
checkVelocity))
{
bestMagnitude = currentPos + (tempMagnitude*(i - 1)*0.1);
}
}
tempMagnitude = bestMagnitude;
SO, what is juice? well, it’s what puts the ‘spring’ in Springfield. check out these amazing presentations on what it is and why you need it
In Bloom Blossom Saga there is an amazing amount of juice, but before I break down each specific part, I would like to talk about my favorite one, the cascading effect. What I mean by this is when you burst one flower, and that bursts another flower, and so on. This is one of my favorite things to experience, reminding me of stacking the huge LRM40’s onto a longbow from the old mech warrior games.
This ‘reward cascade’ Is why gambling machines don’t pay out all at once, instead slowly spurting out each coin one by one, so that winning 20 bucks feels like the best part of your day. It’s why the game has a chance to give you 20 free consecutive auto rolls, rather than just adding 20 to the amount you have left. It starts up a fanfare, adds in a multiplier. It does all of this to make your small input feel as though it has a huge effect on the game space.
Its some extremely powerful feedback to the player, I think it fits in well with the player feedback loop described by Jan Willem Nijman, the idea that is created in the player is the feeling of a heavy effect from their actions, from the creation of a domino effect, or cascade.
Another reason that I know this is the main goal in the game is their trailer on the google play store (here is an example)
As you can see, it is the main function that is shown when advertising what their game can do, this is the core player experience.
Now, let’s break down all of the juice that can be found in this game
flowers fall down into the scene in rows, this feels like a really quick sand timer, but offers order and pattern.
you make a line of flowers, they make a burst and a sparkle noise, burst into a puff of petals and glitter, each regular flower is replaced except the one you end on, which grows in size, and matures. the new flowers fall into place around it, and each flower that moves also ‘bounces’ while moving
when selecting flowers, there is a nice, slightly punchy sound of (maybe hitting a patch of grass?) to let you know you selected something, but the whole game freezes so you know you are having an effect
if you line up heaps of flowers, the final one grows into a huge flower, through several stages, each one making a punchy (bursting plant) sound, kind of like a wet tree snapping a bit. This flower bursts into heaps of petals, with extra sparkle noises, and a success bling noise (that rises in pitch with each successive flower grown to this state triggered in this chain)
If the player sets up a particularly large combo (not chain) then there is a (bright lights getting sucked inwards) animated image overlayed under the players finger
Oh man, if you combo a bunch of flowers (like 7-8) in one shot it explodes a super bright light outwards, with an even more blingy bling noise, rays of light shoot outwards across the screen and all the flowers around it are brought to full maturity, setting up a huge cascade of flowers bursting, nearly entirely wiping the whole board, all building up the pitch of the bling sounds and covering the screen with bursts of flower petals everywhere! this would be the perfect time to have the phone vibrate, if available.
there is a cavalcade to announce the ‘final flower’, which automatically clears the board for you, and plays a bright and uplifting jingle for completing the board. It scrolls up the screen, tells the player they are awesome, tallies up the score, adding huge points for bonuses, and then tallies it up again dishing out a star rating based on the score (while playing another bling noise for each hundred points as it tallies up)
These are the Audio and Visual feedback systems found in this game. Each one is added to the game to make the player feel as though their actions have an even greater effect on the game, a consequence (though not necessarily a bad one). This makes the player feel as though their actions have weight, this feeling is the ‘idea’ placed into the player and is what makes the game have a lasting effect on them.
Another awesome game by King is Farm Heroes Saga, and I want to talk about some juice they put in here to make the player feel like a super smarty pants. When they tally up your score, instead of adding a couple of zeros on the end of the points you actually get (which in itself is pretty amazing) They actually give you a completion percentage. Which they allow to go over 100%. This means that, given you meet the reasonable target set in each level, your efforts are rewarded, by telling the player exactly how much better they really did. It lets you know where the expectation bar was, and allows you to hit scores like 500%! With a normal scoring system, you either have no way to gauge exactly how well you did or have to do mental backflips to figure out the maths (or worse yet, are pitted against your friends who have no life and play this game 24/7)
animator team comms
A google sheet was created for the animator team, including a milestone based task completion tracking system for all of the objects in the game, with each object assigned to a person. There was also a section for swapping out parts of said task (such as texturing). This was coupled with my overseeing of the team, implementing daily skype meetings and weekly face to faces to account for any setbacks, holdups and to allow showing off of each team members work. This was made possible by some team building exercises, such as working together on drawings, creating in-jokes amongst the team, or staying on the skype call together after a meeting to catch up with each other (only if they were available)
This can be replicated by working on team building exercises, making that a part of the time allocated in the time management, rather than only talking to each other under work conditions. This sort of thing seems to come fairly naturally amongst the games students, as most of our interactions have been online. In the past I have tried to stamp out most of the shenanigans, as they distract from the work at hand, on average taking between 30 minutes to several hours before people got back on task, but making time available for these things could prove very useful for team building. Even better would be to begin research into structured frivolities.
Documentation
While it took us a couple of weeks to get around to doing it, this was the most documentation I have had a part in creating for a project. This was very helpful for defining our project, and just as it should, creating an HCD made a GDD and then a TDD much more possible. It helped to keep people accountable and on track. We found that the team members who took a greater part in working on the documentation also had a greater shared knowledge of what the game was, how it worked and what happened.
In the future, I would like to focus more heavily on setting up documentation, creating the structures around that and getting it all done earlier in the pipeline.
what went wrong
Sickness
Most of our team were struck by sickness throughout our production time. While we had not set up a Gantt chart, it was easy to see that this was blocking others from working. We were unable to set up full group meetings and found this as an easy excuse to put off work like design, documentation, and build. Too much work was being placed on the shoulders of the healthy, who soon became exhausted or overloaded, lowering the quality and quantity of work being done. There were brief moments when we were all able to get together and complete large amounts of work, but this project was scoped for a healthy team who were mostly there the whole time.
Unfortunately this sort of risk, while easy to expect, is hard to accommodate. The result of this sickness is a reduction in available working hours, once you burn through the flex time and reassign tasks onto already overloaded available resources, the only thing you can do is reduce the scope of the project. Our project did receive this treatment, although it was not controlled at all. Tasks were simply not being completed.
A possible way of avoiding this in the future is to have better leadership in the team, and to plan out the scope of the game in a more modular way. The core game loop should either be extremely simple or not wholly rely on every part to be implemented to work. for example, our game was meant to use VR, and one of the goals was to make that optional. This was implemented and when I failed to get the VR working, the project did not fail due to that. It did fail though, as most of the other functionality was unable to be completed. Lack of leadership
This was a huge issue. At the start of the project, we let a team member opt-in to project management, which I chose not to ask for, as I had been the project lead for every project so far. The person who became project manager failed to oversee the project or check up on any of the tasks. they were also in charge of time management. I failed to identify this earlier and take charge of this, despite being hinted into doing this multiple times. What needed to happen was that the project lead needed to complete time management tasks, with the help of the whole team and identify tasks that were behind, properly reassigning them as was needed. When tasks were not being completed, there needed to be follow up and when the project was falling behind the scope needed to be reduced.
Next time, Tasks need to be assigned within the first week of the project and the team lead needs to be reassigned the second the current lead fails. This is a difficult situation, as we all thought, every time, that this would be the last time, and that they would pull through or catch up by tomorrow.
Lack of motivation
With this sickness and lack of leadership came a lack of motivation. As a group, we started thinking, if no one else is doing anything, I don’t want to either. If I turn around and do everyone’s work for them, then they will keep avoiding their work. At least, this is how I felt, with good reason, as this is what happened in my last project. This was one of the main reasons why I did not want to become project lead. We also had KPI feedback during the project, with some bad news adversely affecting some of our team members. I tried to cheer them up, suggesting things they could do to help them achieve their goals, but it still affected their workload. Not much could be done about the general lack of motivation, as it meant that team members would not log into skype, or decide to leave the team early. I have noticed that team members throughout our core team and also collaborators that were not a part in any team building were much more likely to leave early or be affected more by lower moral and motivations. This may be subject to confirmation bias, so I hope to further test this in future projects.
So how do you encourage motivation in your team?
Get your team to feel something about what they are creating. Get them to share a story. Create a focus on the progress of your project. These are the things that went right with the animator team on this project. I described the story, explained to them all of the things that would excite them about the project, showed them the progress of the project, and their effects upon it. I kept them on track, ensuring that they knew about their deadlines, which they set for themselves. If anything was behind, everyone knew about it, but instead of shaming the person who had fallen behind, we instead looked into finding out why it had happened, and what could be done to fix it (this is how the task swapping came to be, as one of the team members had not provided concepts. I found out it was not due to laziness but because they felt they were very bad at it). Time management
While the animator team was managed pretty well, The programmers and designers did a terrible job at it, which was terrible, as everything went wrong and even some simple time management would have given us a chance to reassign tasks and correctly identify when the project needed to be scaled back. This issue with time management is one that I have had with every group project I have worked on. It’s the first thing that needs to get done, yet is often the last, or just never done. It seems to happen because of different reasons each time, this time, it was because of sickness and lack of communication. due to not being able to get the team together in a group, we felt we could not complete the HCD and other documentation in a fashion that would satisfy the whole team, and without that we had no clue on what the actual task breakdown would be. To be honest, the only way I can see this getting done is by locking down the team in a 12-hour face to face meeting during the first day or even week, to knock out all the basic documentation and a crude task breakdown, which would immediately get set up into the rough Gantt chart. From now on, I will not settle for any less in a group that I work in. Lack of skill
I have a problem where I assume that any task that is currently outside of our knowledge is simply solved by adding research time to the task. The issue is that most of these tasks are being completed early in the morning, and the time required to comprehend and solve the issue is much larger than anyone ever applies to the task. I had an issue with trying to find if an object is currently being rendered within the view frustum. I ended up creating planes to visualize where these planes actually were, and they were rotating all over the place as I looked around the scene, so I knew so little about it after hours of working on it that I could not even set up a debug to correctly visualize it. This lack of skill also meant that tasks that were worked on for hours had to be reassigned to someone else, taking up their time too.
In future I would definitely limit the amount of tasks that sit outside our current bounds of knowledge to a minimum, and focus on creating the documentation like a TDD as early as possible, to help identify gaps in our knowledge.
SOMA’s main theme displays Derek Parfit’s argument on personal identity (Parfit, 1987), specifically ‘Relation R’ and to explore his idea that it is necessary for society to protect an individual and an individual’s future self from harm, including self-harm. While he does not explicitly endorse invasive control, this game exhibits that scenario in an extreme. It also questions the morality of euthanasia, specifically quantity of life over quality of life.
This is a problem you are presented with throughout the game, as it works the difficulty of this question up, from “someone is blocking your path and you don’t know they are a human” to “would you kill your previous self?”
This first example is set up to make the player question whether or not they have just killed a human. The player enters the room, understands that to move forward, they must unplug a robot. the robot itself does not respond to the player speaking to it, but instead looks at its own hand, as if it is self-aware. There are two plugs powering the robot, it responds, with a female voice, “no, don’t…”. The player still cannot progress forwards, leaving the only option to pull the final plug. The robot asks “Why? I was okay. I was happy.” and it’s lights fade out.
This is a heavy moment for the player, as they are confronted with the consequence of their actions having taken an innocent life.
The physical representation of this image is a damaged bipedal robot, with only one leg and arm. There are tubes pervading its structure. The text of this image is meant to be interpreted (and represent) a damaged woman, kept alive through invasive life support. The player has essentially stumbled into a room and without understanding what they are doing, ‘pulled the plug’. As the robot woman does not speak to you before you harm her, she reflects a coma patient, in that there is no way to know for sure how they feel.
In this moment, the player has not euthanised this woman. The players choice was not to end suffering, as there is no indication that she was in pain. They blundered in and committed murder to progress towards their own goals.
The next two encounters no longer require you to kill a being to progress, but instead offer a safer future for doing so. There is no reward for taking the difficult path. These encounters also allow the player to find some information about their choice before they make it. These people are not in a comatose state and respond to the player, with their own desires to live.
The first one is the top half of a bipedal robot, with a man inside of it, who is unaware of and unable to realise that he is in a robot body. You find his human body near his location but are unable to tell him about it. He only asks you to find him help, as he is aware that he is hurt. You cannot kill him, to progress forwards you can either turn off his power, causing him immense pain or release a dangerous monster into your current location that you have to sneak around.
This is the second robot person the player speaks directly to, but the first that has any wits about them. He expresses a desire to be saved, asking you to find others. He tells you his name, Carl
The most apparent option available is to turn off the power in Carl’s’ room, which causes immense pain to him. This is displayed through his screams, begging the player to stop, that he can’t take it anymore, and just crying. the room goes dark and electricity arcs across his body, a red light flashing above him. The player thinks that he will eventually die, leaving to complete the process of opening the path ahead of them. This causes the player to move past Carl a few times. Carl is alive and screaming each time, as he does not die in this current state. The player realises that this suffering that they put Carl in is infinite.
While a player may not understand it at this point, the human personalities inside the robots are ‘brain scans’ of the original human and there is a question over whether this could be considered as a soul. If this is true, then Carl’s soul is being forced to endure searing pain, for eternity, through the player’s actions. The player has placed Carl in his own hell. While this hell is a literal one, the player must understand these symbols to realise exactly what they have done.
The next encounter is not with a robot, but with a human, named Amy. You walk into a room to find a woman lying against the wall, with tubes throughout her and plugged into a panel to her left, just like the very first robot you encounter. There is also a set of grey, mechanical lungs perched just behind her, breathing by themselves. They can be defined as lungs, as they have the same general shape, inflate and deflate and a mechanical sound of gas being pumped (very much like a bike pump, sounding slightly plasticky, along with breathing noises, like a lighter Darth Vader). There are also tubes connected directly from the artificial lung into the woman’s chest.
This is where the reality of the player’s situation sets in, where the gravity of their choices should come to the forefront of their mind. There is no ambiguity here, no misinterpretation possible. The choices you make are affecting humans. This is a woman, asking you not to hurt her, kept alive by machines. The player must remove one or both plugs keeping her alive, the first showing the player that she will die if both are removed, but is required to power the ‘safety systems’ on the path ahead.
These three encounters asks the player to question their ideology of euthanasia and their idea of quality of life. Clinton R. Sanders covers the cultural construction of euthanasia, stating that in human medical settings the debate over euthanasia generally focuses around whether the sanctity of life should or should not be valued over the quality of life. Giving primacy to the former value leads to a rejection of “mercy killing” while the quality of life position acts as a foundation for medical personnel allowing or actively assisting death in certain circumstances (Sanders, 1995).
This argument over quality of life is set up with the option of leaving Carl in a state of living hell. When the player is presented with the third situation, they must choose between sanctity of life or quality of life. Near the end of the game, the player is asked again, except the person asks you to end them.
The first thing Amy says to you is “don’t hurt me”, then “it won’t let me die, nothing is allowed to die”.
She is referring you to the WAU, an AI system created to operate and maintain the air and life support systems on the deep sea research facility that you are on. It does not think and its main directive is to preserve the life of humans, but after a cataclysmic event wiped out all life on the surface of the planet, the WAU began to overcompensate by not allowing any of the humans to die on the station, forcing life back into those who have lost it, leaving them as corrupted monstrosities (usually) fused to the floors and walls, or taking brain scans of people and placing them into machines.
These actions are an extreme example of the quantity over quality of life, showing the problem with Derek Parfit’s reasoning that it is morally wrong for one person to harm or interfere with another person and it is incumbent on society to protect individuals from such transgressions. That accepted, it is a short extrapolation to conclude that it is also incumbent on society to protect an individual’s “Future Self” from such transgressions (Parfit, 1987). Instead of society protecting you from choosing to smoke, causing harm to your future self, the WAU protects you from death by not allowing you to die.
It also has no way to comprehend quality of life. most of the monsters you encounter throughout the game are just earlier attempts at placing a human consciousness inside a robot or dead human body. Most of these attempts left the consciousness in an insane or damaged mental state, including dementia (with extreme fits of anger, including intense, desperate screams), addiction (shown with desperate begging for your structure gel, which quickly escalates into violence, and desperate searching if the player is not noticed) and Alzheimer’s (by talking to people who are not there anymore, seemingly stuck in past memories). These are signified as a text, through linguistic, behavioural and aural methods.
These examples are built to set the player’s frame of mind for two of the hardest decisions in the game, euthanizing an active person, who wishes for death rather than succumbing to the WAU and whether or not you should kill your original self. The latter option has you copy your consciousness into another body to progress, when you wake up in it, you are confronted with your previous body. it is unconscious, but will wake up. There is no threat from it, nor is it blocking your path, but it will be stuck there in that room, with no company. There is no risk or reward for either choice.
Parfit explains that a “Relation R”, a psychological connectedness, including memory, personality, and so on (Parfit, 1987) should be treated by yourself as if it were yourself and so, the other you that you stand in front of should be treated as yourself as well. Therefore, the choice you are given is to kill yourself, to avoid your future suffering or allow yourself to live alone forever.
This game shows the worst case scenario for quantity vs quality of life, showing us the problem with each extreme, that in some cases we cannot be aware of the needs or desires of a person, or the horrors that forcing someone to stay alive can produce. The main problem with such difficult issues is ignorance. Unless you have yourself experienced this exact situation, you should be unable to make a decision, or even to form an opinion on the subject, yet people do. This game gives the player the opportunity to gain some insight, enough to understand its message, that “it is complicated”. No encounter offers a morally righteous path, for example, if you do not leave Carl in his own hell, he asks you to find him help, to seek out Amy, who is fused to the wall and those lungs. If you leave her alive, she asks you to find others. You can’t save these people, no matter what you do. They have a terrible quality of life and will be stuck there forever. Your only other option is to kill these people but some of them don’t want to die. That is SOMA’s message.
BIBLIOGRAPHY
Parfit, D. (1987). Reasons and persons. Oxford: Clarendon Press.
Sanders, C. (1995). Killing with kindness: Veterinary euthanasia and the social construction of personhood. Sociol Forum, 10(2), 195-214. http://dx.doi.org/10.1007/bf02095958
Ben Welsh 