How to Credit Playtesters (and Other Expectations)

This article is the first in a series of questions Moesh will be answering over the coming weeks.

MapMakingMag‏ @MapMakingMag  Mar 4
How should testers be credited? In the map? Do we test with people we know or anyone who asks? What expectations are on testers?

How should testers be credited? In the map?

Credits for play testers have shown up in various locations:

  • Readme file
  • In the lobby of a map
    • …on signs
    • …floating text
    • …posed Armour Stands using the skins of the players
    • …tellraw text
  • Website

The International Game Developers Association (IGDA) published Game Crediting Guide 9.2 in August 2014. Under usage, the document says game credits must appear in the actual game, and must not be hidden or locked in the game.

Give all members of your team and your playtesters a chance to review and sign off on the credits. Establish a sign-off sheet and give a two-week period.

The IDGA guide covers crediting procedures in greater detail.

Do we test with people we know or anyone who asks? What expectations are on the testers?

When asking others to test maps, I explain:

  • The objective of the game, and the first steps they will take to complete it
  • How long the test will take
  • What my expectations are from this session

By piling this into my introduction, I prepare my testers for what kind of experience my game will give. They will understand how to position their feedback, based on their experiences (or lack thereof) with similar games. At this point, if the testers do not have enough time, they have a chance to excuse themselves.

These are my expectations of playtesters:

  • Remember, the goal of play testing is not to win, but to improve the game.
  • Try to play the game as designed.
  • They give honest and transparent feedback.
  • Avoid disrupting the flow of gameplay to have philosophical discussions.

By focusing on finding flaws in the gameplay design, instead of bugs in the code, play testers can help strengthen the core of the gameplay first. Finding bugs can happen in specific play sessions, which are much more efficient and focused.

Finally, when listening to feedback from my playtesters, I build cases for and against their piece of feedback. If the game is too difficult for one player but easy for another, I first figure out if they are my target player.

Feedback is most useful to me when it can be used to create action items to improve my project.

Leave a Reply

Your email address will not be published. Required fields are marked *