itch.io

I posted this elsewhere, but a something that might help people who are trying to playtest their own game:

Generally those too closely involved in the creation of something are either too critical or not critical enough.

When playtesting something you've worked on, there are a few things to consider, including:

• Having worked on the project, you are:
  • Better informed about your project than others. What seems obvious to you might not be obvious to others.
  • More used to the project than others. What might seem obvious to others might not stand out to you.
  • More prone to ignoring mistakes, errors, etc..
  • Able to work around mechanics and puzzles more easily due to knowing the intended solutions.
  • Have a hard time seeing alternative solutions due to already knowing an intended solution.
• For effective testing, you want to:
  • Be able to step back from the game. No longer see the game as 'your' game, but as 'some stranger's" game.
  • See the project from the perspective of a player: 
    • With no preconceptions.
    • With preconceptions from similar games.
    • That has just beaten the game.
    • That has spend a long time away from the game.
    • Doing a new run/from a previous game of a series.
  • Be able to consider playstyles different from your own/what you expect.
  • Really want to try to break the game. Look for ways that you can break the game.
  • Try the consider how the game might behave under different conditions. If you have a really powerful rig and a cheap rig, you can do a test on both rigs. If you have just a powerful rig, you can use emulators or other methods to simulate a weaker or different rig. (Like Windows 10 and Windows 7 and Windows XP might all handle the same game differently and have different bugs). One very common issue is the game behaving differently at different FPS values. So like a game might be fine at 30, 60, 120, 144, then break at 146 and higher. A game might also be fine at 300,144,120,60,30, then completely break at 28.
    • Test the game's deployed version. One way to do this is to upload to itch.io as a developer branch (mark it for your system) and use the Itch App. This will allow you to use a mode that should somewhat isolate the game so that you can test it. The benefit of this is that you are testing it in a way that lets you see how the final product will react because the game can act differently under different environments (test vs deployed vs actual environment).
  • Ignore your own personal feelings, but also consider in feelings. 
    • Example of why to consider in feelings: How is a scene supposed to make you feel? How does it actually make you feel? If your MC's father dying is supposed to be a sad scene, but you feel happy about it because the father was a jerk, then the scene isn't working as intended, as an example. 
    • You don't want your personal emotions to cloud your judgement. (Having emotions affect your judgement is normal.)
• For effective fixing of issues, you need to:
  • Understand how bugs and issues happen. The better you understand the problems (and solutions), the faster and more thoroughly you can fix problems.
  • Be able to understand what problems your fixes might cause and avoid those problems.
  • Be able to prioritize what is important and what can wait.
    • There is a development side to this choice: Budget, Time, etc. can affect that side of the decision.
    • You also want to consider in the user/player side of this choice: What issues are the players going to see? What will a player be willing to deal with and what will a player find frustrating to the point of quitting?
    • Balance what the players will want with what makes sense from a developer standpoint.
      • For example, players see new UI as being most important, then sound, then a few minor graphical errors.  Your budget provides enough to fix one UI issue, or two sound issues and one minor graphical error. Your time left allows you to fix two issues. Which do you choose? You could fix just the UI, which the players want most, or Sound and sound or sound and some graphic error. 
        • This is actually more complicated than just that as what will the players find most annoying. When they just started, what will make them quit before giving the game a chance vs what will make them quit over a longer period of time? Which is more important to prioritize? There are many more factors to consider and you also have the issue that you can't spend a lot of time making that decision because that is spending time and possibly money.

That isn't an exhaustive list, but those are some things to consider. I put some of the ones that are harder to do in italics.