This sprint certainly was interesting and proved the strengths of our team. We were thrown plenty of obstacles during this sprint and every team member bound together to exercise a sense of comprehension, compatibility, and capability against setbacks.
I'll discuss what went wrong first and how we can avoid these things in the past.
Firstly, our GitHub broke early on in the sprint. It was a slow decent into a completely dysfunctional web of branches and builds. We chose to abandon this and send work through Unity's packages for a bit. This was unconventional however it allowed us to solve and diagnose a lot of the GitHub issues. We were lucky in the compartmentalizing we had established for each role so that this was possible, but this won't always be the case. Instead of simply starting a new GitHub, we got our programmer, Pablo (who runs our GitHub) to look into this and attempt fixing things. I won't go into detail on what was going wrong, but there were multiple things that we not only managed to improve upon but also take note of for the future. Part of this successful diagnosis was seeking out help from peers in other classes. It can't be said enough how much building a network of talented and smart developers is critical to your success when building games. There is no possible way any one developer can understand every element that goes into building games, so being friendly, social, and helping peers out through transactional favors of help and wisdom can go a long way to solve your problems.
On this topic of networking, I also used one of my friends from San Francisco for advise on a lot scripting. I understand how to throw together documentation and dig through forums to solve problems, but there is a limit to how much you can solve when you don't specifically take programming classes. Once again, I won't go in detail, but I learned lots of helpful tools through this friend to make better systems for our game that allowed our conglomerate of scripts to communicate. This help was directed at another issue we had where I had not communicated the design of our claw tool enough to our programmer. It wasn't Pablo's fault our claw tool wasn't how I had wanted it, it was mine, as I am the lead designer. I took it upon myself to polish and bugfix the perfectly functional scripts Pablo had built. However, that being said, there was a lot for me to polish. I had not realized how complex emerging bugs and issues would be, and while I always assume this is the case with programming, I never would have thought my polish on the claw would take upwards of four full days of work on this project to reach a somewhat functional tool. This is the product of miscommunication from a designer. If I had properly laid out my expectations for our claw tool, I wouldn't have had to spend so much time in something that wasn't my lane. I have every intention to avoid this in the future so that I can work more on my role-related tasks for the future.
Luckily I made the time for this added work, at the expense of some sleep, but my team was there with me online to look over my shoulder as I solved issues. This isn't something I asked for, but the comradery and sense of not being alone was absolutely what pulled me through this. The claw tool wasn't the only work where this was the case. I had lots of interesting math issues when plugging in our goober health system. Once again, I was lucky to have my groupmates with me to push my "mathematically-unpracticed" mind to the finish line. And yes, I just used the term mathematically-unpracticed to describe my skillset.
Some additional bug-fixing and work I completed went towards our goobers, which were fun to save, but had some features that made them far too fragile. Goobers would break and fly around the map like a balloon, or hit themselves and the helicopter when you grabbed and moved them too violently. I spent a lot of time building barriers between what things should and shouldn't damage goobers and at what times. Luckily, no one has complained about goober taking damage from something I didn't account for in our playtests. While some said the goobers were too easy to kill, these variables are exposed and ready to be tweaked by us, so balancing these things shouldn't take long at all.
This is becoming a reoccurring theme within our group, during difficulties we band together and combine our skills to make things work well. I can't express enough how refreshing this is and how lucky I feel to have my game made with this team. All of us take and give feedback respectfully and honestly, all of us offer over the shoulder help, and if there is a problem, everyone considers it as their own. While this sprint required some crunching, I know we saved ourselves hours of sleep by working together. A synergized team truly is more than the sum of its parts.
Another aspect that went wrong this sprint was a few cards that can be considered "wasted work". Some members got off task when excited about certain mechanics and ended up building things that couldn't be used in the future or weren't assigned. The entire team discussed this and I hope our members avoid this, but personally I believe this is also a sign of a "wasted creative drive". This is more of a personal ideology, but I find members that are excited about building mechanics, even if they aren't directed in our goals for a sprint, is a positive sign. We want to harness the creative power of each member. I talked with Jonathan, our producer, and we both agreed that we can do better utilizing our member's interests and skills by asking what people want to do during kickoff. If Jonathan can manage some sort of compromise where we complete necessary work but also hand out cards that were already written, but not necessarily for this sprint, I hope our members will be more excited to produce work. I find when members are directly put on things that excite them they produce some of the most quality work. While not all cards can be something fun or exciting, Jonathan and I have devised a strategy to test for our next sprint so that we all have some cards to look forward to.
I decided to build on this as well as a designer. I really want to harness the creativity of all of our team rather than just myself being this "idea guy". While I love the game we're making, my ideas certainly aren't the only ones for it. While I have final say on how things go in our game, I think its clear that "finding fun" and "failing fast" is much easier with four people than one, and so far it has only been me. I wanted to push our team to do some exploration in our existing sandbox and write five ideas to improve on each pillar of our game. This would total to twenty new ideas from each member, giving us eighty things to discuss. While I am far aware that we cannot simply add eighty entirely new things to our game when we're more than a third through development, I want to at least brainstorm one in-scope idea for each pillar. The team will see if we can't manage to fit these things in before our final build. I feel this is important because this next sprint really is the last sprint I am comfortable pursuing entirely new features. Beyond this point I want most of our backlog set in stone for us to gauge how long things will take, establish a consistent art pipeline, complete as many levels as possible, finish features, and polish with QOL, UX improvements, and audio. I want to try our best as a team to avoid crunch entirely, I think our best work will be produced when we are physically healthy and happy. I am attempting to predict our patterns and see where this team will end up in several weeks, and I know we will need plenty of time to polish, as we've all experienced this so many times before.
Finally, we are excited to announce that only a day after releasing our first build we already have 12 responses in our feedback form. I am specifically so excited about this, and lots of the responses have been critical and extremely helpful. I can't wait to formulate this data into a direction for us to head into our next sprint, I plan to discuss it more in the next sprint review and blog post. We will take this data into account when we discuss our new ideas for our game, and I will make tweaks, major adjustments, removals, and additions (personally) to our existing build to make sure the majority of our most valuable players (our target audience) is satisfied. To boast a little more on our data, we have achieved a really diverse range of play testers, from 31+ year old females to 18 and under physics-based puzzle enjoyers! While this is great, I need to be sure I parse our data into what is most useful. Some of our younger play testers don't give the most useful feedback, and players that specifically said they didn't play physics-based puzzle games should be taken lightly in comparison to those who do enjoy them. This would be helpful because there is lots of feedback that conflicts with itself, and it can be difficult to find a unanimously liked or disliked feature.
Additionally, next playtest I want to make a better feedback form. I think we had too many questions which spread the attention of our play testers too thin. Answers towards the end of the form are much shorter and less detailed. I also want to ask indirect questions, unlike our "Do you play physics-based puzzle games?", to draw some lines in the sand between player archetypes.
Overall, I am happy with this sprint. I hope to communicate ideas better as a designer, and for that I will need to annoyingly spy on what every member is currently doing, as well as likely overexplain things. While I'm sure I will get better at this, I am new to game design and will allow myself to make these mistakes if it means improved communication. I need to most importantly communicate with our producer on what work should be verified and what shouldn't be. I also hope to incorporate our teammates voices more into our design, and I really hope to channel their excitement for our game directly into their work so that we can achieve an even higher quality of work.
Comments