What I Learned from My First Software Development Sprint
A Retrospective Look at the Development of Galaxy Blaster Z
Over the course of the last week I was furiously engaged in producing an entire gaming experience in a single sprint. The goal was a Minimum Viable Product — everything I would need to determine if the game could catch an audience and be a success. The project was a 2.5D space shooter — very similar to my first project — complete with an array of weapon types of each of variable strength, 12 waves of enemies flying in unique formations, two boss encounters, with sound and visual effects for everything, all to an 80’s synthwave jazz soundtrack.
Oh, and to top it all off, a beautiful UI with options for changing the difficulty of the game, and adjusting the volume and brightness.
But this experience was not without significant challenges. I went from being very confident on day 3 to nerve-wracked on day 5 wondering HOW MANY MORE BUGS CAN THERE POSSIBLY BE? for the nth time as I tested yet another “final” build.
When I turned it in, I was completely burnt out. I slept for a day. And then I came back this afternoon to find two more critical bugs that I thought I’d already fixed. But they turned out to be easy fixes, so there’s that.
So, what did I learn?
Don’t Rely Too Much on the Unity Editor
To keep things “quick and easy” I decided to just serialize everything and keep track of all the interactions in the editor. This turned out to be a not great idea. Mostly because it wasn’t how I usually worked, but also because things can get messy quickly if you’re not careful.
On one hand, having everything assigned in the inspector is easier to read assuming I’m able to stay organized in the process. I was worried about wasting too much time fiddling with details, but I was also worried about missing some details in the disorganized pile of variables. I wasn’t able to find a happy medium here, and toward the end I was just tossing each new variable at the bottom of the list, regardless of whether it went well with its neighbors.
Also, some things shouldn’t be serialized and can cause problems if they are. If you find you need to use a ‘magic number’ in a variable (hah!), the Editor may reassign it to some other number (usually 0) for you when you’re not looking.
I also used serialized fields to store component and object references that I could have made by leveraging better information handling practices in C# — which also has better null value checking than the Unity Editor does. There were a few times where the game apparently chugged merrily along, while some aspect of the code remained fixated on an empty spot, and couldn’t execute past it.
It’s a mixed bag, but I think after this experience it’d be better to spend the time typing a few more extra lines of code. I’m not sure I actually saved myself any time by leaning on the editor.
Pace Yourself
It’s called a “sprint” but it’s not about speed so much as about meeting the interval required. I started out at a steady pace, but I grew more and more unsure about whether I could complete the task. By the middle of day 4 I was sure day 5 would be a nightmare, so I put in an extra 4 hours I hadn’t planned on to make sure I had some slack.
This actually wore me out, and made the 5th day much harder than it had to be. If I’d stepped away when I should have, I am willing to bet my rested mind would have handled my final round of bug smashing much more nimbly.
Keep Your Eye On Your Goals
I feel like I handled this one pretty well. There were numerous occasions where, struck by inspiration, I was tempted to veer off the MVP list and add some cool extras. I made a small list of those, and then set it aside and refocused on the MVP details in my design documents. Had I entertained even one of those side paths I’d probably not have successfully completed this sprint.
I still plan to get back to those neat ideas some day. If not in this game, then the next. I’m glad I kept them, but I’m also glad I kept them at a distance.
So, that’s what I learned in my first software development sprint. It was quite a journey, and I’m looking forward to future sprints with a team at my side. Sprinting by myself was challenging and rewarding, but I think I’d enjoy it a lot more if I had others to share in the success.
If you’d like to play Galaxy Blaster Z, you’ll find it on itch.io.
Tomorrow I’ll be getting back into the usual spirit of these articles: tackling new coding challenges. I hope you’ll join me.
