Resilience and the Challenge of Feedback

Lessons That Need To Be Felt

Around a year and a half after we had started MVGIE, we had perhaps our worst month as a company, and it only got worse from there. We faced three rejections in the same month. We didn’t get the two grants we had applied for, nor were we able to go to the Game Finance Market, which we had been so focused on. It was very disheartening at the time, as we had been mostly operating part-time on the game, and any one of these things happening would have been a path for us to go full-time.

The months afterwards were tough. I kept implementing features in our prototype, as our demo had seemed quite sparse in the gameplay loop, and I was trying to solve that. Since the team had been busy with life, I had been plugging away at the prototype alone until I could show something substantial. When that fateful testing day came, I looked on as Alex and Allie tested the game and all of the new features that we had dreamt up, that were supposed to give our game its core loop. What we found instead was a buggy, unintuitive, and boring mess of a prototype, which was severely lacking in content, and in spite of focusing on mechanics implementation, it also didn’t have a fraction of the mechanics it needed. This was a wake-up call for us. We had spent almost a year and a half working on the design and prototype of this game, and hadn’t even realised how the scope had crept to this size. I think it’s fair to say that at this stage, we felt somewhat defeated. While Allie kept a cool head, Alex feared we wouldn’t be able to achieve his vision for the game (and we definitely couldn’t at the time), and I was worried about the amount of work we’d need to do to prove to ourselves that we had a chance.

That was almost a year ago now, and we’ve come much further along as a team, as a business, and we’re very excited to be working on our current project. With that said, we internalised some lessons by going through that process that we didn’t know we needed to learn. You often hear advice such as ‘be aware of scope creep’ and ‘be open to feedback’, but you may not know just how those problems might materialise, until it happens to you. Today, we’ll be looking at how to take advice, and share some lessons we learned the hard way, even though we thought we had learned them already.

Learning Without Listening

When you start learning how to develop video games, people will quickly give you valuable beginner advice, such as ‘start small’, ‘test your ideas’, ‘get feedback’, and ‘avoid scope creep’, and these are great pieces of advice. The problem is that you’re not always told how to go about implementing this advice, and it can lead to the opposite outcome of what’s intended.

’Start small’ is a great lesson, as the dream of making games is often followed by ambitions of cool and really big projects, that no single person could make in a reasonable amount of time, let alone a beginner. It’s often followed by ‘test early and often’, which can help find errors, and if you do it right, find out what’s compelling about your game. It naturally leads to ‘get feedback’, as the logical next step in making a small game you’re testing is to ask for people’s advice and see what they like and dislike about it. This can be a recipe for a great agile process where you find something compelling in a small game, and you expand it bit by bit until you have a compelling game. Leaving marketability to the side for a second, it’s a huge success if you can pull off just making a small, compelling game. Steam is littered with fully developed, polished, and released games that have hours of boring content because the developer never bothered to get feedback.

Where one has to be careful is if you allow all feedback to have the same impact on your project and mindset. This is especially important with player feedback. Get as many players to test your game as possible. Note down all of their feedback, and take the time to sort through it, categorising which issues they have and what they liked. You can use this to build insights into your game which can help you develop it. However, don’t assume that your players are the experts on what they like just because they’re playing your game. An important lesson we learned early was that players are good at identifying issues, but bad at finding solutions. As an example, Alex and I both played the same game recently. We both felt that something was off about the movement of the character, and tried to give advice on how to fix it. We’re both designers and feel confident in our abilities, but we gave opposite advice in how the issue should be fixed, and that’s quite normal. Based on 15 minutes of gameplay, no tester is going to be an expert on what you’re going for, however, if you have 10 people testing your game, and 7 people are having issues with one mechanic, then you know that is an area for improvement. At that point, you don’t need their solutions. When you’ve changed the mechanic and have it tested again, see if the response is different, and if fewer people are having issues, you know you’re going in the right direction.

Feedback isn’t just given by players, though, and should you be so lucky as to have industry experts or more seasoned developers to give you advice about your game, their feedback also needs to be handled with care. We recently had dozens of experts offer advice, which at times could be tough to hear and gave us pause, but it was also at times contradictory between people. We like to have many moments of reflection on our game and look critically at what we do, but we make sure not to get too disheartened when we are challenged on our ideas, because it’s only once you give up or take others’ advice blindly that you lose the lessons you’ve learned along the way. In the end, we took all of the advice that we got, and made our own decision from there, and that’s the important part, to make your own decision, but gather as much information as you can until you make it.

Resilience

Scope creep can be really dangerous for indie game projects that have schedules to follow and deadlines to meet. Even if you don’t have strict deadlines to meet from a publisher or a grant application, you still likely want to see progress in a timely manner, so you can realise your game before you get burnt out. Feedback is one tool we can use to keep ourselves in check. People will be able to tell us that we have too much going on, or that our mechanics are too loosely defined or implemented, or that there’s no clear goal. They can tell us that the main loop is boring, and that the surrounding mechanics feel like busy work. They can give us indicators that our attention has been pulled to areas that aren’t important to realise our grand vision. Another tool we should use to combat scope creep is a resilient and adaptive process. I’ve outlined one in a previous post, which can be used in conjunction with feedback, but to summarise: define your north star, work in cycles, test and measure against your north star, and repeat until your game is finished.

The challenge with this process is that every few weeks, you have to face the state of your game, as broken or early as it might be, and receive feedback on everything that makes it bad. Paired with this, you might be learning how to operate a business and struggling to keep up with the challenges it brings. No amount of tools or feedback is going to prevent your project from going off the rails if you don’t have the resilience to bear these challenges and keep improving your game cycle-by-cycle. When the bulk of your learning outcomes from playtests are ‘this feature is missing’ or ‘there’s not enough to do’ then it can be really tempting to pause all other activities until you have something you feel is worth showing. It’s tempting to double down, avoid designing more features, and just implement what you’ve already planned. This is the situation we ended up in with our previous game, which led us to massive scope creep without even realising it, because even if you’re not actively designing more changes, your feature list may not be fully thought out till you try to implement it. Once you’re coding new mechanics and trying them out, a lot of work goes into seeing how every system connects, how every mechanic builds on the loop and expands the game, and if you’re not using your cycles to take stock of what you’ve got and how it works with everything that you’ve already built, you’re just allowing the scope to expand silently. That’s a slow way to iterate and a good way of killing your motivation, where you should be building resilience.

Resilience is the ability to stick with the process and keep navigating towards your grand vision in spite of the harsh realities that present themselves along the way. A resilient team is not going to get everything right the first time, and they may have many disheartening setbacks, but a resilient team will always pick itself up and keep doing what they can. How you find that resilience may be different from how we did, but finding it can be the way you survive the indie business long enough to finish your grand vision.

Thank you for reading along. Resilience and feedback can be difficult to talk about because there are so many voices, and at the same time, not quite enough advice out there, but I hope this might help even just a little in finding your way. Should you have any questions or want to leave a comment, please feel free to drop me a message.

Phillip

phillip@mvgiestudios.com