Sprint 7: Post-Mortem (Literally)

This was a long march caused by a cascading series of failures, and in the end I'm not super proud of what I accomplished despite having, what I believe, to be top-notch help and some of the better students within the CAGD program. I was unable to use the resources I had effectively, and that's ultimately on me.



The things we did right were a very, very, strong early start. This was when the game got the vast majority of its work done. Items still didn't work, but we were able to rapidly get down an idle game concept and then use it to improve on the game. We were proud of the unique themes, there were plenty of cards to pull from, and overall everything seemed to be organized. Our team worked strongest when Milo and I could get features in, Bradley and Kyle could get a few models in, and then all of that would be completed and wrapped up at the end of the sprint.



We had a clear vision on what we wanted to do, despite not really having a gameplay document to go off of. Our initial calculations of the idle game were well thought out, and we plotted the player's expected growth out on a spreadsheet which was immensely useful to programmers coming into the project. Overall, despite an early focus on art, we had an idea of what to do, what we needed to do to get things done, and it seemed like the project would be finished and feature complete. This was when I was most on top of cards, ensuring we had a robust backlog and were putting out prototypes that people could play often.



Things started going bad around the fourth or fifth sprint, and that's where my failure to delegate really started to show. Ultimately, we ran out of cards early on, and I couldn't figure out how to properly space the cards so that everybody had the proper amount of work. This resulted in me assigning, for better or for worse, busywork so that I could get people started off early and without issue. This was problematic for many reasons, namely that it kept me from really giving people the time and space they needed to solve the very real problems in the game. I started taking on most of the major problems myself, which, with a growing project and a sensitive codebase, started to be an issue.



I would, essentially, completely screw over Milo by sending him off to focus on things that were ultimately unnecessary for the game, and I failed my modelers by taking too long to provide references and explain close detail what I wanted from them. I wish I ultimately had more time to plan this out, and I wish I ultimately knew what I was doing better so that I could avoid keeping people on their toes.

The final, and worst thing, in my opinion, that went wrong was that I had a personal crisis over Thanksgiving break that completely evaporated my desire to work on anything, and then I found out too late that my hard drive failure removed the keystore that I was using to build our project. This was effectively all me, and I did my team an awful disservice by hitting them with both of these things at once. I've spent the entirety of dead week doing my absolute best to remedy this problem.

An example of the item templating process. Items receive a base model, a template with properties, a generic drag script, and an extended properties script depending on what's needed.

I did, however, learn a lot during this experience. It's a shame that most of them are hard fought lessons, and lessons earned at the expense of my team's mental health. I learned about the importance of getting a basic understanding of the game's needed features down, along with an asset list and classmap of needed features to understand how the codebase and assets should be developed and when. If I was to lead a team again, which I think any professor would be completely insane if they let me do that, I would put in as much time as needed to ensure that the backlog was as fleshed out as possible and put everything into it, to avoid freestyling and causing problems with my team later.



Additionally, I would do my absolute best to make issues with my game and problems that I have immediately solved. Whether it’s nagging doubts like ‘I’m not sure if I’m delegating this well’, or things that eventually resulted in catastrophic failure like the keystore issue, I needed to have been on top of things and asking for help early. In the future, i will do so; my team modeled this behavior excellently to me personally, and I am glad that they did because this project would've gone so much worse if they didn't ask questions, didn't ask how things were doing, and didn't check in with me about the state of the project. They were an invaluable part in making this work, and I owe so much to them for getting this game rolled out.

Comments

Popular posts from this blog

Sprint 5

Sprint 6: I have no mouth and I must devlog