I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the second episode on some issues getting feedback for your games:
Welcome back to The Adventure Mechanics Side Quest and, once again, it's just me, Chandler. I am using this audio format to push myself to complete one of my prototype games and have it ready for a larger release. Last time, I said I would have the prototype ready for you to look at. I made it through most of my pre-production goals, but ran into a few snags along the way. I did make it through the art mockup for both representing the map and player avatar in the overall space. Once I was done with that, I started looking for my previous code base to springboard off of. To my horror, I couldn't find the original source code for The Mapper. I only had my compiled version of my entry. That meant I had to start from scratch on it. I was able to recreate the basic movement of the player quickly. I even added a little bit of polish where the player will shift in the center of the screen a bit as they move around. I even reached feature parity with the jam entry version and added objects that spawn in the tile that the player can collide with.
The map portion of the prototype pushed me into a desert of redesign, however. I realized that in my original jam design, I limited the size of the play area. Meaning, the player started on an edge and eventually hit the other side of the map. This ended up being in direct conflict with the game design I wrote out for pre-production. So, I had to stop looking at the old compiled version of my game jam game and start working towards my planned design. I wrote the map to be able to add to the existing map for an arbitrary amount of time. Moreover, the map that I wrote pulls double duty and handles both the meat space and the map space with no code duplication. I'm particularly proud of that fact. This ended up taking much longer than expected, though. I did end up with a much more flexible design in the end, but it meant that the month I budgeted for this prototype went right out the window. This forced me to decide whether I was comfortable with sacrificing my original timeline I had envisioned and keep moving forward with what I have currently. Since I'm terrible at decision making of this caliber until it's far too late, I ended up just adding features to my prototype.
The other thing that this meant was that I didn't get any of the art assets completed for this prototype. All of it is blocks and text. Sure, I have the mocks that I made, but they are cobbled together from assets pulled from Open Game Art dot org or existing copyrighted games. That won't do if I plan on showing this to anyone. Moreover, I don't want to introduce the possibility of missing those assets later and having them sneak into my final product. That sort of potential is something that will keep me up at night with cold sweats if I put copyrighted assets in. I don't want to even flirt with the potential of getting a Cease and Desist on something I spent so much time on. But enough about my progress, let's get into a topic I want to talk about today: Feedback, specifically issues when getting it.
I have tried getting feedback for my games many times. Over all the games I've shown and tested, I've noticed a few things that reduce the feedback quality: First, and most common, is the audience I'm getting feedback from is not the audience that would get excited about my game. The second issue I run into is vague feedback. And lastly, I end up getting irrelevant feedback to my game in particular. Let's go over these points:
The easiest people to get feedback from are your friends and family. I mean, they're right there, sometimes literally. They tend to give the WORST feedback when it comes to your game, though. My partner really isn't into top down mapping games, so she's not really invested in what I'm showing. My family don't really play video games and they only play a few select board games, so there's they really don't have a point of reference to compare what I'm coming up with. And as much as I trust the opinions of my fellow Mechanics Devon and Tom, they're not going to give me as hard of an opinion on my work as I really need. For better quality feedback, I'm going to have to search outside my social circle. Other developers make decent guinea pigs, since they're familiar with the early jank that prototypes entail. Other good playtesters are groups that enjoy playing games in an early state, or otherwise rougher than normal. Before the pandemic hit, I was going to local Protospiel events. For those who don't know what those are, it's a gathering of playtesters and designers who spend a weekend playing games in various states of readiness. In my case, these were for board games. Another good option is local meetups for game developers, such as an IGDA chapter. I'll throw a link ot them in the show notes.
As for vague feedback, I run into this VERY often. In many cases, the person giving feedback isn't sure what to respond to, so they say, "yeah, it looks good," with little or no additional feedback. Other times, they see something, but don't want to hurt your feelings/insult your work, so they end up sugar coating their feedback. Both of these are supremely unhelpful. If you're going to grow as a developer, you're going to have to get comfortable with prying out the details from these people. Sometimes, when you're asking for feedback, it's worded too broadly. Questions, such as, "how do you like it?" and, "what do you think?" aren't enough for your playtesters to latch onto. You need to ask some probing questions, especially in the areas that you're looking to have them really look at. In the instance of the prototype I have, questions that would be more helpful for me would be about the controls. Since I have not implemented any of the artwork or audio, questions about the feel of the game are not going to get me useful responses. The guiding questions that you want to be asking will put a highlight on certain mechanics but not bias the answers. So, in looking for feedback on controls, I wouldn't want to ask, "were the map controls awesome?" In that question, I'm trying to bias the responses towards a positive comment. That's not going to help me get honest feedback. I'm not going to go over biasing questions, but be aware of it as you craft questions.
The last issue I commonly run into is people giving "advice" on how to improve my game, or worse yet, advice on how to change your design to match an idea they've had. Don't get me wrong, suggestions on how to improve the overall feel or change a mechanic for the better should absolutely be taken. The type of advice I'm talking about here is something like, "Hey, I like your game about mapping, but it would be a lot cooler if it was a game about fighting!" Not only is this not going to help my design, it's actively pulling my design away from the core that I've so painstakingly put together. The most input feedback that this gives is that the person giving it wasn't really interested in the design. This may be useful, especially if that person represents a group you want to appeal to, but more often, it's just not going to be worthwhile to implement their ideas.
This only scratches the surface on the topic of feedback. There is a whole field of study on it and I'm not an expert in it by any means. This is just my experience when I've tried getting it for my games. If you've ran into issues as well and want to either talk about it or have me talk about it in a future podcast, reach out and leave a comment. I'd love to hear your experiences while playtesting.
In the interest of getting feedback as early as possible, I'll be releasing the small mock-up of what I have so far for the map user interface (UI). There won't be anything in terms of gameplay, but I still want input. Hopefully I'm making it obvious that it's almost never too early to get feedback on your design. Yes, the game is your baby, but unless you are planning to never release it, you're going to have to be comfortable with the idea of people looking at it and, occasionally, trashing your idea. Although it may be hard to hear, even those who trash your game are giving you a nugget of truth, even if it's something as simple as, "I'm not your target demographic." The more you have people look at your design, the better the game you're designing will become, even if doesn't feel like it at the time. Who knows, maybe they'll even give you that one tidbit that solves an issue you've dealt with for a while.
Oh, and in that same vein of fast feedback, if you are listening to this podcast around the time of release, OMGJam8 is coming up November 6th through the 9th of 2020. I plan on entering it to scratch my itch for some rapid development. I'm not sure what engine/framework I'm going to be going with, but I'm really looking forward to participating in another jam. I missed out on Ludum Dare 47 and want to push myself with time crunch another time. If you haven't given a game jam a try, join me in the OMGJam. It's a fun way to practice, learn, or just execute on an idea that's been rolling around your head.
Anyway, that's all that I have for this episode of the side quest. As always, you can reach me on twitter as @jcsirron. I'll talk at you next time.
