Goodbye.

It was nice, getting to know you. Let's wave farewell, our rusted joints squealing.

Produced, packaged, purchased, consumed, and ultimately forgotten; we lived our life and death same as any toy.

Leggy was just created and now we discuss it's untimely end in...

Leggy! the Miraculous Robotic Arm!
Postmortem edition!

Judgement Calls

When I was selected as lead designer I felt I should do my best to rely on the specialists on my team. I chose to emphasize their skills and experience with the expectation that they would help me see the project through to completion. This isn't bad practice, exactly, but it does require that you select the people you're going to work with very carefully. As shown here, there was some absolutely stellar contributions to reward my faith.

I did not get to choose my producer for the project.
I was assured by the executive producers that she was a capable, competent individual and so I consulted with her as we were selecting personnel. At the project's start we were required to review the resumes of our potential team members; this required that we examine 40+ resumes in 30 to 45 minutes. 

That's less than a minute per resume, on average, to determine the best choices for the needs of the project. 

My producer had the advantage of having worked with many of them before and so I decided to accept her recommendations across the board. Choosing to rely on her proved disastrous to the project in both the short and long term. I am not without blame, as will be discussed below, but I put my faith in the wrong person. This producer's influence had massive ramifications for the project, to the point that it lead to her eventual firing.

Slow Start, Tight Timeline

As the project began I immersed myself in the documentation, making it as whole and complete as possible. I attempted to work closely with the producer during this stage in order to discuss what would need to be done when, project priorities, and any extras we might be able to include. Unfortunately, it did not feel as though the producer was able to match my enthusiasm and missed several scheduled meetings. She also repeatedly missed standups which created a very awkward situation for me, having to try and explain the lack of tasks in Jira. 

This pattern continued for nearly a month before the executive producers stepped in and pulled someone from another team to serve as our producer. 

The project wasn't doomed at this point, but we lost a huge amount of critical development time. I shouldn't understate how badly this effected me psychologically as well; I care deeply for any project that I work on and I was watching Leggy be still-born in real time. This set the tone for the remainder of development but, as mentioned, this wasn't the only issue we had.

Null Reference Exception

I made assumptions about the programming requirements for this project based on two things: the advice of an executive producer, and my experience creating the proof-of-concept in Unreal.

This proof-of-concept took two days (about eight total hours) to create. This includes the model blockout, the rig created in Unreal, and the programming to drive its movement. It was exceptionally easy to do and functioned almost exactly as I wanted it, with a few caveats that I knew from experience would not be difficult to overcome. 

What I did not account for were the difficulties Unity would cause for this seemingly-simple process. The physics issues I've mentioned in previous dev logs meant that our primary programmer was overtaxed throughout the project and we did not have a functional prototype until very late in development. While our primary programmer was involved in trying to solve the physics and animation situation with Leggy, our secondary programmer was tasked with nearly everything else that the game would need. This proved to be an issue. The code generated by our secondary programmer was extremely error prone and inflexible. When I raised concerns about the code, one of our executive producers advised me,

"Don't do the generalist multiple-hats thing.
Just focus on design."

Taking this advice and exclusively relying on others when I could have helped more directly turned out to be a huge mistake. That advice prevented me from wading into the code much sooner than I did. 

Towards the end of the project it became clear that we would not have a functional game if something wasn't done; I decided to step in. 

When I began looking into the project's code the full scope of the issues became clear. I immediately instituted a mandatory pull request policy on github and began reviewing everything that was added to the project. I began refactoring or fully rewriting huge swathes of our secondary programmer's code in order to eliminate the constant null-reference errors and massive inefficiencies. Over the course of a couple weeks, I implemented the FMOD audio & adaptive music system for the game as well as the entire objective management system.

The objective tracker accepts goal locations that need to be satisfied with sortable objects. The goals each report a trinary completion state i.e. incomplete, satisfied, and perfect. The Min Num Goals Completed variable determines the number of goals that need to be finished (e.g. in either the satisfied or perfect state) that are required before the player can exit a level without having their happiness penalized.

 The adaptive audio showcased above functions entirely behind the scenes in the game, responding to the amount of time the player has spent in the level as well as their current happiness value. 

I also had to do a massive rework of the level transition code which is still not where I want it to be. 

The reworked transition manager appropriately adjusts the desired font and all of the listed variables work and do what you expect them to do. That might sound obvious but it's a massive change from the non-functional transition manager we previously had. 

I have to ask you to please excuse the extant bugs in the project; there was so much I had to fix in so little time that, unsurprisingly, I could only squash the most game-breaking bugs. I suppose I should feel proud that I managed to bludgeon the codebase into a functional game in such a short amount of time but mostly I just feel... tired. I can't shake the feeling of failure.

Failure To Pivot

There was a point early in the project where I could have pivoted the design hard in order to avoid the headaches we were having with Unity's rigging system. This would have freed up a huge amount of time for our primary programmer to focus on the physics issues. 

Specifically, if I had been less invested in the inverse kinematic system I had created in the Unreal proof-of-concept and was attempting to recreate in Unity, I could have switched Leggy's controls to a forward kinematic system. The forward kinematic system would have fulfilled my overarching design goals perfectly well and would have been much, much easier to program. 

So...Why didn't I? It's simple: it didn't even occur to me. 

Late in the project one of our executive producers suggested the switch and I thought it was brilliant. "Why hadn't I thought of that?" I asked myself. When I proposed this to our primary  programmer, however, he felt that the IK system was very close to working properly and that he did not want to have to create a new system from the ground up with so little time left. I felt this was very reasonable and, to be perfectly honest, I had no faith that switching at that stage would lead to a greater chance of the project succeeding. It was a case of 'too little, too late.' If I had been less wedded to the idea of the inverse kinematic system in the first place I may have happened across the idea myself, soon enough for it to have mattered.

What Went Right?

Reception

The core concept of Leggy was met with a shocking amount of enthusiasm by many of the people I shared it with. Notably, I had many people who were very, very eager to get their hands on the game. It's crushing to know that I wasn't able to deliver the experience I intended. Letting those folks down is an indelible stain on my soul. Still, knowing that the idea was so well-regarded gives me hope that I'm not simply a rubbish game designer. Indeed, some parts of the project did go well.

Workflows

Puzzles

During the project I created several different workflows in order to help our developers accomplish their respective goals. For the level designers I established a puzzle creation workflow that involved several steps:

- Initial Proposal

- Revision & Approval

- Asset Requisition

- Implementation

- Testing, Revision, Testing, Revision,...

The initial proposal is similar to a 'one page' and contains a full breakdown of critical elements for the puzzle. The proposal form allowed level designers to requisition assets for their level as needed. These assets could be models, sound effects, visual effects, or specialized code depending on the puzzle's needs. The revision and approval step is self-explanatory. The asset requisition step is when the required assets for the puzzle would be readied for assignment to the relevant discipline. Implementation, Testing, and Revision are also self-explanatory but this is where we ran into problems. 

Due to the fact that our core systems weren't functional for most of the project's duration, level designers could create and implement new puzzles but they could not test them. I feel that the workflow was successful in allowing for asynchronous development between disciplines given reasonable lag time. If we had not had so many issues on the programming front I feel this workflow would have been a complete success.

Art

I also created a workflow for artists in order to help them hit the target aesthetic. I created a tool suite using Photoshop's automation system that was used to 'crush' textures down to lower resolutions. 

This was designed to create an original Playstation-era pixellated appearance. These tools were very successful but we ran into an issue here as well. Specifically, I did not give our artists sufficient guidance with regards to texel density which meant there was inconsistency across models. Some had the entire 0-1 UV space dedicated to them instead of being packed with other models. This meant that the texture crusher did not have consistent output. Realizing this, I should have implemented a maximum texel density cap in order to guarantee the result I wanted.

Programming

After establishing the mandatory pull request system for the Github repository the project began moving significantly smoother. It meant that our developers were no longer able to stealthily merge their un-updated branch directly into dev. We had an issue, repeatedly, where someone would merge directly to dev causing significant damage to the project by overwriting files with older versions brought in by their branch that they had neglected to update. 

These unintentional reverts were frustrating to resolve prior to requiring PRs. Additionally, developers often did not pay attention to the files that they were committing to a branch. This meant that some commits had massive changes in them that were auto-generated (e.g. during a lighting bake). These huge changes would obscure the actual intent of the commit. This was compounded by how infrequently our developers would properly comment on the contents of their commits. 

This is the second time I've encountered these sorts of issues. Previously, I worked on a large project in Unreal that had many active developers. As part of that project I had to institute a similar sort of system in order to prevent merge conflicts due to the way Unreal works with Git. I felt at the time that this made developers less inclined to contribute to the project and so I was hesitant to institute the same policy again for Leggy. This was a mistake; moving forward I intend to always protect the repository.

Finally

This project is finished, new projects are on the horizon. I do feel a call to return to Leggy, though. Ordinarily I don't return to any finished work; I've always found it more beneficial to my growth to move on to a new project instead. So many people were excited by the core concept, though, and as I've mentioned it hurts to have let them down. So...I'm undecided. Be on the lookout for announcements regarding an Unreal Leggy in the future, just in case.