Sprint 2: Weeks of programming can save you hours of planning

I hope the next time my team lead sees me programming some esoteric bullshit, she tazes me in the neck.

Not to start this sprint recap off with negativity, of course. I feel as if the amount of cards I had to complete were completely disrupted by my need to completely overengineer a solution to a problem that didn't exist. This is entirely on me and something I should've brought up beforehand. When I started discussing this problem with my groupmates, I realized how ridiculous it all sounded in my head, and now I feel like I have a clearer idea of what I need to do.

So let's go into it.

I put myself in charge of me getting a robust physics objects system in the game. This meant, for me, a need to create an elaborate and robust object spawning system, where designers could put values in a spreadsheet and have them instantly transfer over to the game on runtime, with a GPU-friendly batch spawning system that. . .

Yeah, you can see the problems here, can you?

We can count the ways this is wrong but let's start at the beginning; there is no aspect of this game that requires this much over-engineering, period. Second, this was an extremely stilted way of solving this problem that would put too much time into making something the designers don't really need. This ended up taking entirely too much time, keeping me from filling out a card in a timely manner and wasting too much of Sprint 2's time.

This highlighted both a problem with me and a problem with our current workflow. My problem, personally, was my tendency to overengineer problems, and since nobody was around to check what I was working on, I was allowed to develop all by myself with minimal oversight. Once everyone was in on the Unity project, my work started shaping up and I realized how much stuff I was developing was unnecessary. Our workflow problem was that too many cards were vague, focused on cut content, or were entirely redundant, so we took time before kickoff to reconsider what our game was, what we wanted, and removed all cards that didn't fit the game we were designing.  This was an absolutely crucial step to take, and it felt like we moved on from designing three different games to one. 

Now I have more people ready to keep me accountable, and viewing everything I make and updating it every day. Additionally, cards are no longer so vague that I can justify cramming in some insane system or unnecessary design tool to 'fix' issues. Overall, I feel more confident in my ability to do good work in this class than ever before.

This sprint did have some successes, though; the movement controller feels way closer to what the lead intended than ever before, and I got much more comfortable working with the events system. A lot of the stuff I programmed is going away due to the change in scope, but we were only able to figure out that they weren't going to work by implementing them and seeing how it felt in-game. I'm glad I got the chance to work on them, and some of the same code will be used towards systems that actually fit the game we want to make.

This sprint was low in productivity for me, I want to do more than 7 points a sprint on average. Seeing my metrics in the burndown chaart were embarrassing, and I hope to put my best effort and many more hours into this than before.