Congratulations! You’ve just released a successful Early Access game and are looking forward to receiving player feedback! After all, one of the reasons you did Early Access was because you wanted to let the community shape the game right? What’s that? You have a firehose of suggestions pointed in your direction and you don’t know what to do?

Don’t worry, you’re not alone. The dirty secret of player feedback is that it’s not easy to parse what is good, actionable feedback versus the impossible task of trying to cater to the whims of every single player. There’s also the real risk that you lose the soul of your game by simply agreeing to all the suggestions sent your way. Learning to navigate player feedback to figure out what works for you is a skill learned through time, and it can be overwhelming. At Squeaky Wheel, I developed a process to help our team figure what mechanics and feedback to focus on. This is only one out of millions of ways to manage this process, but I hope it gives you all some ideas.

Make a List and Check it Twice

Our design director Tristan Angeles takes the lead on checking on and responding to player feedback since he’s the lead designer and it’s most important for him to know this information. If there’s anything we need to know about what the players want, the buck stops at Tristan.

So I ask Tristan to make a spreadsheet of common feedback/requests from players for new mechanics and to weigh them by the number of common requests. This can be tricky since players will ask for the same mechanic but they will phrase it in wildly different ways. It’s important to try to discern what it is the player wants to do, versus simply reading their request and assuming that’s what they want (figuring out context is tricky, but key! It’s like being a detective!)

Organize and Categorize

I then created a Trello board to help us organize and hash out which mechanics we want to keep. I think Trello is very limited when it comes to serious project management, but for short term tasks like this and to simply organize your thoughts it is an incredibly useful tool. However it’s a tool that you need to design!

For example, this this Trello board I organized the mechanics into three lists : Aesthetic, Quality of Life, and Gameplay. I would then simply drag the mechanics into the appropriate list so we know what kind of mechanic we’re looking at right away.

Next, I ask team members to take a week to think about and pitch mechanics. This activity is also designed. It keeps anyone on the team from simply acting like a player and saying “I want this mechanic” without thinking about the implications to gameplay. So I made a template for them to follow when adding a mechanic. Once that’s done, we go on to the next step, voting for mechanics!

Fighting/Voting for Mechanics

I would reserve a day, or possibly 2 days for this part of the process, as it can be very tiring. I first ask team members on the team to vote for the mechanics that they want to keep by assigning themselves to it. This gives the subliminal message of “you’re now assigned to this task, do you REALLY want to add it to the game?”

Any tasks that don’t have votes on them are quickly added to another list of tasks that have been “denied”

We then argue about the mechanics that have multiple votes, asking those that voted for it more specific questions and opening the floor for those against it. We also categorize label the mechanics based on length of time to complete. This helps us when we start to budget out our schedule.

Are you Willing to Die for This?

For mechanics where only ONE team member is interested in the mechanic, we ask them to sell the mechanic to us as if their life depended on it. This further winnows out mechanics. If you can’t bring yourself to explain why the mechanic is important to you or the game, then it’s probably not worth adding. Obviously this runs into the issue where a team member may simply not be capable to selling well or may be too shy to speak out to the team and defend the mechanic. In these cases it relies on the project lead to coax it out of the team member, and to make sure that generally speaking they have created an atmosphere that is open to communication and free flowing ideas.

However, bottom line for me is that a good game designer needs to know how to sell their mechancis. As a designer you have to sell your ideas to the team. It may well be that your idea is brilliant, but you need to be able to show your fellow devs why it is a good idea so that they also get on board and are eager to implement it.

Themed Updates

After a day of fighting over the mechanics and settling on what we can reasonably add to the game in time, I then take the final step of organizing the mechanics in a way where they reasonably work well together and can come together in a certain theme (eg our law and order update featured the lawyer, goons, and changes to school monitors).

Organizing by theme is a great way to split up the design tasks in a way that makes them manageable and also makes it easier for your players to understand what they’re getting with each update. It’s a win-win!

Conclusion

This is but one way of organizing your mechanics and figuring out a roadmap for your Early Access or Live Ops/GaaS type of game. This is a problem we had to face before, and there weren’t many resources online about how to manage player feedback. I hope that you find this article useful!

Thanks for reading, and hope you found this interesting! If you want to support us, you can buy Academia: School Simulator or Political Animals, or Ruinarch.