It helps to not take the feedback personally. Someone play-testing your game is doing you a favor, since that helps catch issues you probably wouldn't notice until after release.
In my exp players sometimes dont know what they mean when they give feedback. What i mean is for example they can tell you "make a prodecurally generated map" and what they would actually want would be random places to spawn and randomized loot on a static layout map that they can navigate using memory. Listening to straight feedback without some sort of deciphering what do they really have in mind can actually damage the game.
Frankly any feedback consisting of "Do X" is not to be listened to. It either means that the person loves X in games and wants to everywhere, or that they can't pinpoint the issue and guess randomly from a small subset of things that they know about games and gamedev that they think might potentially improve it.
I was about to comment something similar. It's like their grass outside the garden, for example: the player most likely don't care if there's grass outside and inside, what they want is a clear visual indicator of the playable area. How they go about adressing that is another thing, but the point was not about removing the grass, but identifying what issue the feeback pointed at.
Definitely. Personally, I feel the best way too look at feedback is in term of problems to fix. Trying to understand what was the issue they were trying to fix with their suggestion. Focusing on the problems, ignoring the suggested solutions, cause as the dev, you are the one who knows what are the best solution for your game, but the playtesters are there to point at the problems that you need to fix.
A game-dev buddy of mine has what I think is a valuable saying about playtesters: they're good at identifying problems with your game but bad at identifying solutions.
Remember when your grandma sat down with you and said "Sweetie, if you don't have an idea how to do it better, you should not critize people's work" ? And that was probably grandma's most stupid take, ...maybe second place after her ideas on "how the homosexuals are made". Stick to making pie, grandma, stick to pie. It's kinda assumed that giving an idea on how to make stuff better is part of feedback, but i see it as a source of distress in the feedback process. The basic idea of feedback is to have the developer know what works and what did not. It's a discrepancy between what is and what should be. Usually, the developer has a good understanding, (or should have), what the game is supposed to be and what certain elements are supposed to make and what scenes and momements are supposed to evoke. A player does not necessarily know that. A player does know how they experience the game and what they feel while doing it and what felt good or bad for them. So a feedback like "X does suck and you should do X." even if described more diplomatically, is not useful as it assumed that the player knows the intent, which they don't. For the developer it feel like someone else, maybe some random on the internet comes around saying "i don't like what you did, do it the way i would do". I saw that a lot when amateur devs, especially in places like the RPG-Maker communities, get that, they block it, they don't want to make the game the way someone else does, often justifying "No, it's my game i like it this way." That antagonistic perspective imo comes from the idea that feedback should tell someone how to fix. Feedback needs to be interpreted through the lens of design. Example: "I don't like that there is no shop in the camp of this roguelite, it should have a shop!" is kinda missing the point. Interesting would be the question: Why does the tester feel like the game needs a shop? The answer might be "playing runs felt really unrewarding without persistent upgrades. Other games do have a shop or the mirror in hades". That's something the dev can interpret through lens of design. "Do i want metaprogression. Is that intended? Does that collide with other goals? Do we have systems planned that would serve that purpose? Does another system that was supposed to be that not feel rewarding which leads to this impression?". However, especially in amateur developement, devs are not trained to professionally work with feedback and the players are absolutely most certainly not and will write feedback in a way that almost needs to be decrypted to find the value in it. It absolutely helps to ask questions and get to the bottom of it. I repeat: players are NOT trained on how to give good feedback, it is not a personal attack. The developer is the professional in that conversation and needs to stay calm and make the best out of it. The players don't know the intent, so feedback after interpretation can either help you strenghten your design or not.
Hey there! This guide was seriously gold! Playtesting can be a real wild ride (especially without wanting to throw your phone into a volcano ), but your tips & tricks made it feel SO much less chaotic. This video got me thinking about playtesting at whole, and I have some ideas I'm itching to test out in my own video.... This video was such a great starting point, even though I’ve already covered this topic!
Two problems with using an online playtest crowd: people usually expect an easy to get in casual game, and they will be much more impatient that professional tester. So its much harder to playtest a more niche genre title, in contrast to a classic "mass market" type title. Often (non developers) can also not looks past the prototype graphics and extrapolate to a finished game from there. So if the game looks still rough, they would get distracted by that. All of that kind of throws off the evaluation in what to improve or balance, if your game is still early in development.
Do you use data tracking for quantitative data? For example to track progression, how much time it takes to go from milestone to milestone and if players get stuck at some point?
It is very important to check if you actually do something different. I playtest a lot and I have seen so many survivors clones, where I thought exactly that. Why would I play your game over any other game like this?
Me and my friends are making a game . The idea of game is it is set in stylized toon fantasy openworld where our player can chose with what core magic he/she want to born with option of magic is 5 basic (fire ,water ,earth ,wind , lighting) . Player can learn other magic as there level grows and there ability to control their magic but have core magic can benefits in certain situation like when you are exploring in snow are if your core magic is fire it cold weather will not affect you same goes with water magic you are at some river and the bridge is far so you can walk on water with core water magic And we are gonna also implement magic creation like if you combine you fire and earth magic it will create lava magic but you can one own 2 custom magic type but ypu need to have full mastery over that magic type ypu want to combine Custom spell magic will work like this we will already have 5 magic type , 20 spell type it will aslo have their primaryeffects And 20 secondary effect type so you can create your own combination of spell but it this idea is in very early stage And one more mechanics is that special travel way according to you core magic like if have fire magic you can summon fire phoenix spirit to fly and travel , with earth magic you can summon horse made of rock ,with lighting magic you can throw you wepon with lighting imbune and teleport their in an instant but not literally teleport but flash movement and we are trying to figure out what can we do with water and wind
Focus Testing, to give it its proper name, is also important at the prototype stage, too. You're better off Focus Testing at EVERY stage of development, before you even have the gameplay loop established (AKA pre-Alpha). So: Prototyping Pre-Alpha Alpha Beta Demo Prerelease
![Megan Thee Stallion - Neva Play (feat. RM) [Official Video]](http://i.ytimg.com/vi/TpYTyAaTRts/mqdefault.jpg)
It helps to not take the feedback personally. Someone play-testing your game is doing you a favor, since that helps catch issues you probably wouldn't notice until after release.
In my exp players sometimes dont know what they mean when they give feedback. What i mean is for example they can tell you "make a prodecurally generated map" and what they would actually want would be random places to spawn and randomized loot on a static layout map that they can navigate using memory. Listening to straight feedback without some sort of deciphering what do they really have in mind can actually damage the game.
Frankly any feedback consisting of "Do X" is not to be listened to. It either means that the person loves X in games and wants to everywhere, or that they can't pinpoint the issue and guess randomly from a small subset of things that they know about games and gamedev that they think might potentially improve it.
if lots of people tell you "do X" then it's probably a bad Idea to say that it's "not to be listened to"@@tymondabrowski12
I was about to comment something similar. It's like their grass outside the garden, for example: the player most likely don't care if there's grass outside and inside, what they want is a clear visual indicator of the playable area. How they go about adressing that is another thing, but the point was not about removing the grass, but identifying what issue the feeback pointed at.
Definitely. Personally, I feel the best way too look at feedback is in term of problems to fix. Trying to understand what was the issue they were trying to fix with their suggestion. Focusing on the problems, ignoring the suggested solutions, cause as the dev, you are the one who knows what are the best solution for your game, but the playtesters are there to point at the problems that you need to fix.
A game-dev buddy of mine has what I think is a valuable saying about playtesters: they're good at identifying problems with your game but bad at identifying solutions.
Fits perfectly.
Remember when your grandma sat down with you and said "Sweetie, if you don't have an idea how to do it better, you should not critize people's work" ?
And that was probably grandma's most stupid take, ...maybe second place after her ideas on "how the homosexuals are made". Stick to making pie, grandma, stick to pie.
It's kinda assumed that giving an idea on how to make stuff better is part of feedback, but i see it as a source of distress in the feedback process. The basic idea of feedback is to have the developer know what works and what did not. It's a discrepancy between what is and what should be.
Usually, the developer has a good understanding, (or should have), what the game is supposed to be and what certain elements are supposed to make and what scenes and momements are supposed to evoke. A player does not necessarily know that. A player does know how they experience the game and what they feel while doing it and what felt good or bad for them.
So a feedback like "X does suck and you should do X." even if described more diplomatically, is not useful as it assumed that the player knows the intent, which they don't. For the developer it feel like someone else, maybe some random on the internet comes around saying "i don't like what you did, do it the way i would do". I saw that a lot when amateur devs, especially in places like the RPG-Maker communities, get that, they block it, they don't want to make the game the way someone else does, often justifying "No, it's my game i like it this way." That antagonistic perspective imo comes from the idea that feedback should tell someone how to fix.
Feedback needs to be interpreted through the lens of design. Example: "I don't like that there is no shop in the camp of this roguelite, it should have a shop!" is kinda missing the point. Interesting would be the question: Why does the tester feel like the game needs a shop? The answer might be "playing runs felt really unrewarding without persistent upgrades. Other games do have a shop or the mirror in hades". That's something the dev can interpret through lens of design. "Do i want metaprogression. Is that intended? Does that collide with other goals? Do we have systems planned that would serve that purpose? Does another system that was supposed to be that not feel rewarding which leads to this impression?".
However, especially in amateur developement, devs are not trained to professionally work with feedback and the players are absolutely most certainly not and will write feedback in a way that almost needs to be decrypted to find the value in it. It absolutely helps to ask questions and get to the bottom of it.
I repeat: players are NOT trained on how to give good feedback, it is not a personal attack. The developer is the professional in that conversation and needs to stay calm and make the best out of it. The players don't know the intent, so feedback after interpretation can either help you strenghten your design or not.
your homosexual comment had me going???? but this is a really good explanation
Hey there! This guide was seriously gold! Playtesting can be a real wild ride (especially without wanting to throw your phone into a volcano ), but your tips & tricks made it feel SO much less chaotic.
This video got me thinking about playtesting at whole, and I have some ideas I'm itching to test out in my own video.... This video was such a great starting point, even though I’ve already covered this topic!
I have a play test coming up next week, and I stress about things not looking “pretty” enough. This was a breath of fresh air for me, thanks!
Great video! Thanks for the shoutout too lol
Two problems with using an online playtest crowd: people usually expect an easy to get in casual game, and they will be much more impatient that professional tester. So its much harder to playtest a more niche genre title, in contrast to a classic "mass market" type title.
Often (non developers) can also not looks past the prototype graphics and extrapolate to a finished game from there. So if the game looks still rough, they would get distracted by that. All of that kind of throws off the evaluation in what to improve or balance, if your game is still early in development.
Do you use data tracking for quantitative data? For example to track progression, how much time it takes to go from milestone to milestone and if players get stuck at some point?
It is very important to check if you actually do something different. I playtest a lot and I have seen so many survivors clones, where I thought exactly that. Why would I play your game over any other game like this?
Any advice on multiplayer playtesting? Seems like it's an extreme hassle, especially for every player your game needs to work.
I have a few play testers, I'll see what they say before I throw my game before the court of public opinion. Nothing sounds scarier than that.
Me and my friends are making a game . The idea of game is it is set in stylized toon fantasy openworld where our player can chose with what core magic he/she want to born with option of magic is 5 basic (fire ,water ,earth ,wind , lighting) .
Player can learn other magic as there level grows and there ability to control their magic but have core magic can benefits in certain situation like when you are exploring in snow are if your core magic is fire it cold weather will not affect you same goes with water magic you are at some river and the bridge is far so you can walk on water with core water magic
And we are gonna also implement magic creation like if you combine you fire and earth magic it will create lava magic but you can one own 2 custom magic type but ypu need to have full mastery over that magic type ypu want to combine
Custom spell magic will work like this we will already have 5 magic type , 20 spell type it will aslo have their primaryeffects
And 20 secondary effect type so you can create your own combination of spell but it this idea is in very early stage
And one more mechanics is that special travel way according to you core magic like if have fire magic you can summon fire phoenix spirit to fly and travel , with earth magic you can summon horse made of rock ,with lighting magic you can throw you wepon with lighting imbune and teleport their in an instant but not literally teleport but flash movement and we are trying to figure out what can we do with water and wind
Focus Testing, to give it its proper name, is also important at the prototype stage, too.
You're better off Focus Testing at EVERY stage of development, before you even have the gameplay loop established (AKA pre-Alpha).
So:
Prototyping
Pre-Alpha
Alpha
Beta
Demo
Prerelease
you don't care a lot I can see 😁(just a joke) thanks for a video😊
When are we getting the 'with hating your life' episode though? I'm not interested in your wholesome hacks, sir.