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.

Conclusion

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.

Advertisements

Postmortem – Creature Feature

Overview

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.

Planning

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.

Implementation

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.

Conclusion

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.

Postmortem – A Thief’s Way

Introduction

This project has been the most productive project in terms of physical work, and output. The project suffered from rigidity and setbacks, but overall has come to a successful project conclusion. The communication dynamic experienced in this project is something that I will push for in future projects. And the implementation problems are something that I can learn from to better focus the efforts of teams that I work with in the future.

Communal work sessions.

Working at the same time as my teammate resulted in efficient communication, production, problem solving, and problem management. This communication worked mostly through discord. Allowing me to ask direct task and goal based questions.  We quickly fell into similar work patterns, with a cooperative attitude on both sides of the communication. This was highly motivating for me personally, and I feel like I got a lot of good work done on our project. Moving forward I would like to make an effort to find one or more people in the group too work closely with, in a way that has a similar dynamic as this project. To do this I will be more directed in the initial stages of the project to express the way I work best and asses the most appropriate person to use as my lead. Outlining what I need to stay productive while also making an effort to respect the way they work best. If I cannot find this dynamic I will talk to facilitators about finding a solution. On top of this I plan to work on my problem solving ability to make sure that I can independently find solutions when needed. To do this I plan to work on more solo projects and implement day sprints.

Implementation failure

The core interaction mechanic did not work the way we had initially wanted it too. This was caused in part by a break down in planning, and time management, not allowing for overflow time with the level loader. Partly more complicated than initially expected. And Partly because I was hit with a depression low that drained the three days set aside to write and develop the movement mechanic. This then resulted in a mad rush to cobble something together with the physics system. This rushed and overworked attempt to get something working for playtest resulted in a burnout that lasted most of the following week, this severely reduced the amount of effort I was able to put into the hours that I was putting in.This was then compounded by focusing on non key areas in order to attempt to have a stronger output. When the problems with the core interaction were brought up during playtesting, we still opted to focus on making the project feature complete before attempting to fix the core mechanic. We did not really attempt to leverage the rushed movement system as we always intended on fixing it, but we never put planing into fixing it, as other smaller things felt more urgent. We made the ultimate decision to leave it as it was in order to get the project to a completed state. In the future, I would I plan to focus on outcome over output. Make a rule that core mechanics come first. Learn some new things to leverage in future projects that I would have benefited from knowing to develop the two core systems in this project, these being; abstract and concrete types, delegates and events, and unity Scriptable objects. To mitigate these problems in the future, I will be making sure that the core mechanics have a more defined and outline plan of implementation. And during production I would like to make a per milestone checklist, to assess the development and direction of the core mechanics.

Postmortem – Clutter Tool

Introduction

In the Clutter Tool project we were tasked with making a tool that could be used by us and others to improve the productivity and workflow of future projects. I was initially excited as Tool development has been something that has interested me since I got into programing. But after the idea had been settled on it quickly became apparent that the team was leaderless, unmotivated and unwilling to communicate. This resulted in production conflicts and the project simply grinding to a halt, and being abandoned shortly afterwards.

Team Communication

This is probably one of the least communicative teams that I have ever worked with. At the beginning of the project when deciding what we wanted to do as a team, there was minimal input from one of the team members and borderline nothing from the other. I believe this was caused by the desire from both of the other two members for their to be a dedicated team leader, combined with my reluctance to be team lead. I was recovering from personal issues so I was on the back foot and not as willing to drive the project as I normally would but that does not excuse the complete lack of communication from the other team members. Moving forward I plan to implement a contact standard for projects. Each team and project is different, but if I push the team to work together to agree on; Contact method. Weekly team cowork hours. Daily check ins. This will hopefully avoid the pit of failure to communicate that this project fell into.

Documentation

There was only a single document to attempt to organise this project. Not only was this ineffective but directly hampering, as no one updated their sections as they worked, this combined with the communication issues resulted in confronting work, this negatively impacted everyone. I believe this was caused by a combination of no direct team lead, and no one actually caring enough to try, myself included. This is not a work environment where team members actively want to work in a team or keep their jobs. In my experience with student projects, students will not work unless they are motivated to do so, this also includes myself. Moving forward I would like to make sure that everyone in the team is onboard and motivated to work on projects before we commence the division of work. To do this I will actively work towards making sure team projects have at least one exiting element for each member involved. This combined with a agreed upon contact standard should hopefully build a strong foundation for future group projects.

Postmortem – Banksy Patrol

Introduction

Banksy Patrol is a 2d side-scrolling reimaging of the Game moon patrol, inspired by the street artist Banksy. This was a solo project. Overall I feel the project was successful, as it completed all core requirements, and my goals for the project. However if the tasking, time management, and documentation processes where better the project would have had a smoother development and more polished finish.

Scope

The scope on Banksy Patrol was the most well managed scope that I have ever had in any project that I have worked on. I was timid in working on a solo project in the sight line of others; being my teachers and my peers, as I did not want to make a fool of myself. This resulted in taking a very stripped back approach to the project, limiting everything to the bare minimal before moving forward. This helped the project to have something close to a successful outcome. The reasons for my scope management were not the best reasons to have successful scope management, but in the end had a positive effect. Moving forward I will work harder to be more considerate with about my workload in regards to deadlines and my personal situation. To do this I will put more focus into the project planning so that it has a stronger direction. This plan will include break points to allow for discarding of unnecessary work to lighten the load when needed.

Slow Productivity

The project was not completed to the desired degree regardless of the scope. The minimal and ineffective documentation really hampered productivity. The documentation was not well thought out or kept up to date as well as it should have been. This is a recurring problem that is just going to take personal effort to improve. To move forward with this problem I plan to keep a notes document open while working to dot-point with progress as I go. Than after a work session is completed I will have a log of my work and thought process. I can use this for updating tasking, and updating documentation, and writing Dev Logs while I work. To avoid any negative impacts this new process may have on my development process and productivity for the remainder of the tiremaster I will be starting this new process over the 3 week break.