Studio One Post Mortem

Yet another Trimester down, and what a better time to reflect on my work.

I enjoyed Studio One. I learned a lot of things about the process of creating games that are really going to help me be the best game developer I possibly could be. That being said, I don’t think I was the best I could be. The following will be things I think I did well, and where I failed.

The Good

I’m very proud of the last two projects I did. I found both Darkest Depths and Transmutation to be games I thoroughly enjoyed both making and playing. I definitely felt like I improved as a developer over the course of these creating these games. During the creation of Darkest Depths I put myself outside of my comfort zone in regards to game design, and I confident that I’m a better designer because of it. I’m a lot more aware of design decisions that need to be made and a lot more confident in my ability to make them.

Being better at design will, ideally, result in better games and at the very least help me ask the right questions when faced with a design issue.

In Transmutation, as I mentioned in that post mortem, I became a lot more confident in my abilities as a leader, and my abilities to keep a team organized (although there is still room for improvement).

Continuing to improve my leadership abilities and group organization skills will be very hand in the future, whenever I am working on a team that doesn’t seem to have any project leader I will be confident in my abilities to step up to the mantle.


The Bad

As I mentioned, I feel like I let myself down. I didn’t achieve all of the learning outcomes required of me, such as the audio and 2D assets. Sure, I did lose a bit of time due to “life getting in the way” but that won’t stop and working in the industry life getting in the way isn’t going to change impending deadlines.

In the future, if and when something disrupts my workflow I need to make up for lost time. By using google calendar I will allocate time to update my schedule every Sunday and Wednesday so that if something does disrupt my schedule, I can re evaluate my current schedule if need be. I will also make sure to allocate extra time for project work throughout the week, making using of my nights (as that’s when I seem to be the most productive), so that if at any point throughout the week I’m not as productive as I usually am,  I have a chance to still get done an amount of work I am happy with.


What I Should Have Done

Below is a list of learning outcomes I did not meet, and what I should have done to meet them.


To meet this criteria I should have done more tools development.

I was given the opportunity to work on a 3rd person camera, which I didn’t utilize. I’m sure if I asked, I could have also helped contribute on the clutter generator or the sound controller or at the very least tried to think of another major thing every game uses that I could have developed a tool for.

Specific Skills

To meet this criteria I should have been more conscious of how I am scripting.

Knowing I have these learning outcomes, I should have been more aware of finding ways to do the functionality I am trying to achieve, and designating time in a projects creation to evaluate and improve on existing functionality to make it less hard coded and easier to use.

2D & 3D assets

To meet this criteria I should have contributed more to the creation of visual assets.

This would largely have been a factor of not scheduling my time properly. Again knowing that I have these learning outcomes I should have planned out how I could have achieved these in a way that’s relevant to the creation of one of my current projects.

Audio: Iteration

Although I did achieve the LO for the design and placeholder sections of audio creation, I didn’t achieve the iteration part. I should have iterated on placer holder audio, so that even if a team I was on didn’t end up achieving the audio we wanted from outside sources, we still have have had audio of a decent quality.

Process: Iteration and Post Mortem

This is most likely an example of not recording my work properly. I was apart of every team session in all of my projects where the idea of the project was altered, but I guess I never recorded them in my progress reports. The problem most likely extends from the method I used to report tasks for the majority of the trimester, where I would report all my tasks throughout the week at one time. In the future I will be more cautious with how I report my tasks and report them as the tasks are finished.

As for post mortems, I need to improve on how I wright them. Instead of talking about what went wrong or right, I need to cover why it was good or bad, what was the cause of the issue and how I can attempt to replicate or prevent it from happening in the future.


As mentioned above, I need to iterate on documentation a lot more, making sure that any changes that happen to the idea, happen to the documentation so that it always stays relevant. I also need to include an art bible in future documentation so that the game looks the same way as the team collectively imagines it and so its easier to communicate with animators on exactly what we want them to create.


and last but not least, I need to blog more. On my weekly schedule I will allocate at least an hour per week just for blogging. If any extra events happen (such as future exhibitions) I will allocate an hour per blog at some-point within the fortnight at the latest. This will make sure that I have time within my schedule to blog, rather than the generic tag of “uni work” and making sure that I do it at least once a week should stop them from piling up and if they do, I will have time to separate the blogging sessions to make the workload more appealing.


What I Will Do

The major difference between this trimester and main trimester is going to be the severe increase in planning. This extends past just scheduling, but figuring out what LOs I need, how I can achieve them and deciding what LOs I will work towards achieving in the current and future projects in regards to A) What I would like to achieve during the project and B) The minimum LO progress that I want to earn during the project (In an attempt to apply how I deal with the scope of a project, to the scope of the entire trimester)



Transmutation Post Mortem

Last Friday I finished up my final game of the trimester and I am very happy with the results. I worked alongside two of my fellow students to create a game that had three separate player characters that could only be controlled one at a time and was set in a restaurant. Through brainstorming and iteration we finally came to the group of ideas that resulted in Transmutation.

Transmutation is set in the canteen of a nuclear facility that is currently in a meltdown. The player must control three characters and try to survive the onslaught of mutants as they wait for the elevator to reach their floor so they can escape. As each mutant is killed, they leave behind radioactive goop that lights up the otherwise dark room and can/will kill the player characters.


The Good

As mentioned, overall I’m happy with what my team and I got done. I thought we worked well as a team for the must part and achieved something we can all be proud of. Personally, I’m also quite happy with myself for stepping up and taking a leadership position on this project.

Multiple times a week I would set up a list of things that needed to be done by the next class and making sure my team was aware of what needed to be done, why and if they had any suggestions to the schedule. With every idea the team collectively came up with, I also made sure that every team member had their input on the idea.

Having someone to keep track of what tasks were done and what needed to be done was potentially part of the reason the team as a whole managed to get so much done. It would have kept things organized and avoided having anybody sit around wondering what to do, or waiting to be told what to do.

In the future, if a team I am apart of seems to be lacking some kind of leadership, I’ll be much more confident when it comes to stepping up if need be and keeping the group organized when it comes to scheduling and milestones which will greatly contribute to the quality of future projects.


The Bad

Unfortunately, we made the cut off date to receive assets from our collaborators way too late, and so we didn’t manage to get all of their hard work in time for the deadline, which is very unfair to them.

This was likely because there was a lack of communication in the team regarding the collaborators, which lead to the due dates given to the collaborators not being ideal in terms of content lock before a milestone.

To avoid this in the future I will make sure all collaborator conversations are somewhere where they can be seen by the whole team, such as Slack or Discord, so that any team member who wishes to communicate with them can.


Another issue was the lack of updating documentation, in disregarding it for the most part once the team started the project in Unity. Without documentation, we definitely hindered ourselves in regards to how much we could have gotten done.

Looking back, I think the documentation process was rushed. We filled out the HCD, GDD and TDD to a include what we thought we needed at the time and to a level we were happy with, but it was never updated to include things we decided to add after iterating on our design. Once scripting started, by looking at our code its apparent that the TDD was never referred to, which would have contributed to the overall messiness of the code, which made it a lot more inefficient than it could have been, hard to find variables and functions that were needed.

In the future I will personally hold myself accountable to look at the documentation relevant to the tasks I am working on at the time, and constantly remind me team to look at documentation, especially in regards to scripting, to make sure that things are being created as we had already planned them out, which would remove any and all guess work and increase the teams productivity. I will also make sure that relevant documentation is updated as necessary so that any information people need will be in the documentation.


Darkest Depths Post Mortem

A few weeks ago I finished up designing a board game with two of my fellow students called Darkest Depths.

The board game involved 3 players having to work together to beat a boss at the end of the game, however, only the person who beat the boss at the end was considered the winner. Ideally we wanted players to work together to an extent, but still make conscious choices to screw other players over so that they don’t win, but not so bad that the whole team loses.

As a programmer, I was kind of unsure of how I could contribute, but eventually I managed to get pretty good at the design aspect of game development (in my opinion) to the point that one of my team mates would jokingly say “You’re such a designer” whenever I gave feedback on something or presented an idea. I enjoyed the process of designing a game (even though I missed scripting) and I definitely feel like I learned a lot about design that will help me with future games.

What Went Right?

I tried doing things I wasn’t entirely comfortable with. In the past I have had little to noting to do with the design of a game, so this project was initially off-putting, but still tried and eventually I was comfortable with helping design the game. So the first lesson I would take from this project is to try new things. In regards to code, this would mean finding new ways to implement systems I have done before or trying to do functionality that I haven’t done before. In regards to game development in general I will continue to apply myself in the design aspect of the project when I can.

What Went Wrong?

The project was over scoped. To get the desired gameplay we wanted we would have needed a lot more play testing than what we had. I wouldn’t say that it necessarily means we needed more play-testing sessions (as people showing up on their own free will was quite rare and more a case of an entire class being told to go play test during class time), Its more a case of needing to be more aware of what the team would be capable within the time we have and with the resources available to us, especially in regards to player emotions. For future projects I will make sure that projects with a shorter development length have simpler ideal player emotions and behaviour.

Overall Im pretty happy with the project. I think we made something thats was fairly well received during play tests, even though I don’t think we quite reached the level of “Co-opish” that we were trying to achieve.