Home Postmortem

The Home project was a experimental game about a feeling that connects you to home.

After two weeks of development for the home project, right before our first play test session I suffered a nasty leg injury, throwing the project into a tailspin, as the other team members were relying on me for technical implementation. The problem itself was not the injury, it was how it affected the project.

The project from a technical perspective was behind compared to the other areas of design. This was mostly due to personal motivation issues.

No risk plan, as well as lacking in comprehensive technical documentation. On such a small team with such a short time frame, I do not think that any of us thought for their to be any need for a risk plan. And without a full tech document. It make sense that the project had to be scaled back as hard as it had to be.

My only real recommendation as how to mitigate this kind of problem is to actually put together a comprehensive risk plan, that covers leaving team members, or major project stalls.

The really positive thing was the team response to the previously mentioned injury. The team managed to pivot to the new angle quickly, and effectively.

The pivot was managed by down scoping the the focus of the interaction. Due to the unavailable physical development time, and technical help that I would have possibly been able to provide.

The result was a deeper focus on two areas of the original narrative, instead of having more independent sequences. Giving two distinct experiences, instead of the one main experience with multiple separate dreamlike experiences set between narrative beats.

The best solution I can think of for this kind of situation; Having a project with areas that could be expanded into in more detail, enabled a focused and effective pivot. So in future having a modularised progression seems like an effective plan.

One of my favorite aspects of the project, that was unfortunately heavily affected by the required pivot, was the designed narrative drive of the original project design.

The Home project was meant to be about a feeling of home. Outside of that the brief was very flexible.

So this enabled a narrative approach to the project, that I personally never would have considered.

My take away from this would be to work with anyone and everyone.(within reason.) To best take advantage of the differences of ideas and drive that we all have. Game development is most often a very creative driven experience, and this change of drive from my normally mechanically driven style of game development, was very inspirational, and I look forward to work with people who approach games in a way that I do not.


The biggest takeaways from this project is that you can still make something great even when required to hard pivot by unforeseen situations. To try and forward plan for situations that would cause you to make a hard pivot, such as losing a team member or having a major part of the project change. And to design around the idea of change, by sectioning the project in its development.

Postmortem – Creature Feature


Creature feature was a project focused on learning how to plan, implement, and utilize; Spatial Graphs, Pathfinding, and AI. Unfortunately my project fell apart in the first two areas, but I learned a lot about my own personal processes from it, leading to better project development down the line.


The project suffered from over complication of systems caused by planning issues.

Context: My overconfidence with the concepts that where core to the project. I tend to pick up on concepts quickly as they are described, allowing me to fall into the the pitfalls in my knowledge. This caused issues during the implementation phase, most of the systems required checks and direct references to other systems, that I did not asses. There was not enough attention to detail of how and why systems would need to communicate.

I would like to blame this problem on inexperience. It is true that this did play a role in the problem but the largest cause was negligence. I enjoy the act of writing code, it is exciting and interesting. Leading me to abandon documentation earlier than would be beneficial in most situations.

To better manage these in the future; I need to lean into the excitement of design, and stay my hand until I have a plan.(he he I did not even plan for that to rhyme..) Also need to plan better communication between my systems, as that is an area that I want to be a keystone of my personal skill set. Abstraction is such a powerful thing in OOP. It is like negative space in an image, one class not knowing about another should be a deliberate decision, not a side effect other parts of the design.


The code suffered from trying to patch what would have been quicker and better if refactored. These issues extend from the planning issues but are not inherently caused by it.

The context: The time for this project felt more limited than it actually was and the Project was covering new complicated areas that I am inexperienced in.

A lot of the systems being implemented were things that I had not personally a tried before. As a result a lot of it was key for key tutorial copy. This is one thing I feel justified in blaming my inexperience. Spacial Graph Generation and Pathfinding are two very complicated subjects.

Things to be aware of moving forward; These systems specifically are things that will take some time to learn properly, and even then I know are areas that I do not natively “get” requiring a more rigorous play by play planning for reliable implementation in the future. Additionally, If I want to learn something quicker and better I should make multiple quick passes at its implementation, testing as I go.


I still have a lot to learn but I honestly feel that I this project helped me to grasp just how important it is when learning something new and complicated. Do the thing multiple times, in a short period of time. Get familiar with the concept in its implementation. Poke, prod, and test it. Additionally, abstraction and the conscious decision as to why two system do not interact.

Moving Forward

After what feels like weeks of procrastination and struggle, with motivation and depression being punctuated by suffering a rather severe ankle injury. I finally think I am ready to push past the struggle and just get this shit done. So here is my plan to do just that. Good luck me, I guess.

Demonstration of AI – GOAP

My current demonstration of Ai in the creature feature project is lacking in its implementation. The integration of the AI with entities, world generation, and pathfinding are overly interconnected, and poorly planned. Resulting in any changes to one system require full thought to how it will impact the other systems, this is a big mess that is overly complicated to work with. To mitigate this and demonstrate ai without driving myself insane, I have decided to demonstrate through a different project that’s soul focus is the ai itself without any other complicated systems.

High Concept

Cover the idea of the project, the AI system, and the limited supliment systems.

Ai Breakdown

An in depth point to point breakdown and plan of the AI system.

Tech Spec

A breakdown of the supliment systems.

Tech Spec Documents

I need more progress on these in the areas of Writing and Updating. I plan to cover these with the GOAP project and the WOFSM project.


Post Mortems

Up to this point I believe that I have shown that I know how to write a decent post mortem, I just need more examples of that. I will be writing a post mortem for each of the coming projects. These being:

  • Creature feature
  • Home
  • GOAP

Tech User Doc for WorkOrderFSM

This is a small WIP project that I used to focus myself back into work after my injury. It is designed to make moving forward with the GOAP project easier, and also to prove to myself that I knew how to write a useable abstract Object Oriented class.

User Manual

Being I plan to release the WorkOrderFSM project as a public Git that others can download and use in their own projects. It needs a user manual.

Tech Spec

The tech spec will accompany the user manual as breakdown of the abstract class as a how and why.

DD Week(‘s) 3-5

Week 4-5 – Generating a world

This has taken me quite a lot of work to get right. It is still not quite how I would like it as the world is generated from tiles with perlin noise added to give some variation to make it look more organic. But the tile selection is still random, as i would like it to work from a seed so that maps can be reproduced.

The Maps:

true size

This is true size of the maps they are 16×16 pixels using grayscale to store the information.

900 zoom

This is them with 900% zoom.

Black represents 0, this being the floor height. White represents 1, this being the wall height. And grey represents the ability to sway, between wall and floor, this allows the perlin noise to take advantage of this to change the design how the noise sees fit.

How it works:

Because the maps are 16×16 the world is only able to generate square multiples of 16. The map generator takes these 16×16 images, selecting from them and putting them into an image that is 1×1 pixel per position for the final map. Once it has generated this new larger X*16² pixel image. It then uses the pixel information to generate the world, as it reads the pixel data for each position it takes into account the perlin information base on that pixels position. The result is a 0-1 scalar value that is than simply using a bias for wall placement where any value below the bias is floor, and any value equal to or above becomes a wall. I am also using the perlin information with a different bias to place resources, that is why they all clump together. This is hopefully temporary.


I have taken this and the pathing from the weeks before to create drones capable of navigating the world, this still needs quite a lot of work, as they have a lot of issues, that I hope to address in the coming week.

The Remainder

This week we learned how to set up a simple physics interaction, in the form of rope simulation. And how to use Verlet Integration, to make it more performant. The last class of this week we will be looking over spatial partitioning and how it can be used to improve performance.


DD Week 2

This week I have learned: A* & GOAP (and a little bit of D*)


I spent a long time trying to implement a pathNode generation system. That honestly turned into a pile of crap. But that’s how first attempts go. All it all it looked good:

After I had this thing working I begun to try to implement A* base off the class presentation. But quickly realised that the way I had done the grid implementation did not work effectively enough for a good implementation of A* as the two systems generated problems that I did not understand in their entirety. So I decided to make use of a previous tutorial(Sebastian Lague A*), that I have worked through before, this was a good result as I gained a better understanding of each part and its function.

GOAP – Goal Oriented Action Planning

Basically just read this and watch your horizons expand: Three States and a Plan: The A.I. of F.E.A.R. – Jeff Orkin

But in case you are to lazy to read it(Seriously, take the time to read it!) The gist of it is: Their are goals and actions. Entities have their own internal understanding of the world, and how it can effect that state to complete a goal. To do this goals are generalized to a desired world state. This means that any entity in the game can be given the same goal. And it must use its own abilities to attempt to shift the current world state to the goal state. To do this it has a range of actions that it is able to take. These actions can be anything that is relevant to the entity, the actions have prerequisites, and effects. And the system calculates the cosings of each action to stack them in an order that will hopefully result in goal state.

The little bit of D*

D star is a path originally based off A* pathing, it is designed to be able to handle the possibility of unknown path data. And to be able to improve the efficiency of repathingas the pathData is updated. To do this it makes use of propagation waves that are used on repathing as the propagation waves make it less likely or more likely to plan paths through areas based on the result of the previous pathing attempts. This alongside the fact that It plots its from target to current location make it able to update the path from a position up the chain allowing the entity to continue to Navigate along the old path while a new path is planned from the updated PathData. This can then be spliced into the current Path, allowing a continuous flow.

Post Mortem – Bytesize

This project was not the best way to start, but I can say that I learned a lot about my work ethic coming out of a break.

Case 1

Lack of work hours resulted in lack of total work.

For the first two weeks(the timeframe of the Bytesize project) Outside of class I only completed about 3.5h outside of class. I believe this was caused by a combination of two main factors. The first being that I still feel like I do not have the necessary skills to be where I am today. A feeling that I have lucked my way through and have no right to be here. This is frustrating as I know that it is not true. As I have a lot of respect for my past and current facilitators. And I do not believe they would have let me progress to this point if they did not think I was capable. The second factor. Is that I did not feel that I entirely knew what to do with the project, but did not make more of an effort to reach out to my facilitator for guidance. That is on me, and requires me to be more proactive.

I have already begun to mitigate some of these. In that I have gotten some feedback for research tasks to motivate me to work. As researching is something that in the past has helped me get into a work mindset. Might be worthwhile for me to plan the start of each day to cover a short research topic. And to do with the skills garbage, I just need to have more faith in myself. And break things down until I feel that I am able to complete them. In the 5 minutes to midnight class, the facilitator covered a great way to approach tasks. By breaking them down, the same way that I have done in the past but in a more aggressively systematic way. This is something I feel will be beneficial and easy to implement upfront.

Case 2

Learning through Implementation.

One big thing that I have really clued into during this project is that I learn best through implementation. But it’s not that simple. I need to understand what I am implementing at least in its most basic form. This is not really a revolutionary revelation. As it is the basis for how this course is structured. In the past lots of my work has been a result of “just get it done” this has not been the best way to actually learn from my work. As a lot of the implementation has been other peoples solutions hacked together, to make it work. Now these solutions have worked but the real issue is that I have not truly understood as to why the solutions have worked. So I plan to make a stronger effort to dive in further to how all the little bits and pieces work.

Take Away’s

Short term: Start the day with some quick research for motivation. Systematically dismantle the task at hand until it is in its smallest parts. Make an effort to understand each of the parts.

Long term: I plan to keep tracking my progress and reflect after each project on how I went about implementing the solutions to the problems of past projects.

Dev Diary – Week 1

This week I have learned:

Some great tricks for storing data, using enumeration, and dictionary’s in unity. Great work on that btw Ethan. I have also learned about C# extension methods, and how awesome they can be. In short they allow you to be able to add on functionality to inaccessible classes, this can be great for wrapping non project standard workflow from external classes in project relevant functionality without having to specifically write a wrapper class. I have also learned about some pathing methods, some of their use cases, shortfalls, and common elements. These being;

  • Spatial Graphs
    • That use discrete points to manage their pathdata.
  • Navigation Meshes
    • That use mesh information such as polygons or polyhedron’s. So they are able to store path data, in points and edges, allowing for an efficient and flexible method of generating pathable areas.
  • Potential Fields
    • That use vector data to determine directional force inside of an area, allowing the path to effectively “roll down hill”.

Also learning about all of the things that you can do with Path data to take advantage of preprocessed data stored in memory to reduce runtime processing is quite extraordinary.


I look forward to the coming week to learn more about these systems and how we can take advantage of them for our own purposes.