Tag Archive - playtesting

Playtest Party Aftermath

September 17, 2011 in Dev Journal with 1 Comment

This evening was a small scale playtest party with Randy  O’Connor (who had played Escape Goat) and two of his friends (who had not).  Huge props to them for sticking through and playing the WHOLE game start to finish, trading off levels among the three of them.  Things got started around 8 and ended around midnight, with some breaks in there, so we’re still at about 3 hours of gameplay give or take.

I’ve got tons of notes, so it’s a matter of determining what’s possible to do for this game while still keeping control of scope.

I can also proudly say that for the first time, there’s no placeholder music in the build anymore.  Not all songs are complete, so a couple levels shared the same background music, but it was all mine.  I’m digging the sound so far and I hope you will too.

This morning was lost to computer issues, but I recovered and came back strong.  Inspired by the awesome Bastion soundtrack, I got pumped up to make some Escape Goat music.  As of this evening, I’ve got drafts and sketches for 14 songs, and only need about 9 final pieces to complete the soundtrack.

Tomorrow night is a playtest with an all new crew, and this should be the first time it’s got all the placeholder music stripped out.  Exciting!  It’s coming together.

 

link

Escape Goat Week 2 Mini Testing Party

September 5, 2011 in Dev Journal with 0 Comments

Week 2 of 3 in the final escape from project Escape Goat is complete.  I held a small testing party with some friends tonight, and am holding 3.5 pages of valuable insight into where the game needs to go from here.  Most of it is small fixes per level, or things I need to keep in mind when designing levels.  There are a few small glitches in there as well, the type of thing that’s bound to surface when people play your game in unexpected ways.  Though not all games ship glitch free, and physics and collision are hard to get right, even for the pros.

Overall, one of the biggest problems is that there are too many levels.  Depending on the player’s skill at puzzle solving, there are probably 2-4 hours of gameplay here, and I need to get that down to 1-2 hours.  Some of the puzzles devolved into joyless trial-and-error, and other ones were just too time consuming during the non-interactive parts, like waiting for a machine to operate and pressing a switch at the right moment.

So there’s tweaking some levels and removing some levels.  Not so bad… but…

There are some scary things staring me in the face for this week:

  1. A crash bug during regular gameplay
  2. The player actor got destroyed but the game wasn’t detecting the player being gone, so it let the level play and couldn’t restart itself
  3. The new linear level layout is an improvement over the exploration model I had before, but there are two problems with it.  First, the player doesn’t know you can exit the level and return to the hub, retaining progress on that level.  And second, getting stuck on a single level sucks.  Ideally the player can skip tough levels and come back to complete them later.  This would require another rework of the world layout, to a gallery-style stage select, and I don’t know if this is worthwhile, even to experiment with in the next week.
Tomorrow: bug fixing, level fixing, brainstorming improving the world layout, and music composition.

The Playtesting Party – Some Quick Tips

July 16, 2011 in Articles with 2 Comments

Tomorrow is another Escape Goat Alpha Playtest Party!   That means tonight is a blog post on playtesting, lightweight, indie-style. In other words: you’ve got friends, some of them play lots of games and others don’t, and you want both types to try out your game and give you their valuable feedback.

Throwing a party is a great way to get this free labor from your friends and family without feeling too guilty about it. Just provide them with enough food and drinks to ease your conscience. And it’s not such bad work either, playtesting games.

Now I’m not the master of testing, and a lot of these tips probably come straight from Jesse Schell’s The Art of Game Design. For Soulcaster I, II, and Escape Goat I’ve probably hosted about ten proper playtesting parties, and here’s what I’ve picked up from them.

First question: When to start playtesting? There’s a point during development where you think things have come together enough that you have what could, in some stretch of the imagination, be described as a “game.” Maybe it doesn’t have a beginning/middle/end, maybe the graphics are placeholder and there’s no audio yet, but there’s something there and you can put it in someone’s hands to be judged.  This thing that has until now been called a prototype has now somehow become a game.  If you’re there, let’s get started.

1. Test it yourself beforehand. If you’re making tons of last minute changes like I do on the day of the party, just be sure you’ve given it one full run-through to make sure you didn’t accidentally delete the switch that opens the door to level 3.

2. Have a cohost. A significant other or close friend will be needed to greet guests, cook food, send out for more beer, talk to the cops, etc. You’ll be way too engrossed in the testing to be a proper host, so don’t even try.

3. Fresh meat first. Anyone who hasn’t seen the game yet gets first dibs, lest they catch a glimpse of someone else’s session and have their first impression become corrupted. If someone else is testing while a newbie arrives, have your cohost distract him or her for a bit. “Have you seen the new patch changes in HON?” for example.

4. Tell your tester to speak their mind while playing.   Anything that’s running through their head. Here are some direct quotes from the last playtest:

  • “Wait, did that do anything?” (after skull activation)
  • “That’s the same message that I read earlier.” (story tablet at region 1 entrance)
  • “Did that guy just hit something?” (reaper in level 3 third room)
  • “I like that he looks really, really scared” (idle edge sprite for goat)
  • “Why do the blocks have color on them?”

This way, when a player is wandering back and forth in the opening area, you can get an idea of why. Can they not find the exit, or do they just like the walk animation? Personally I hope it’s the latter, because the two-frame goat run visual took me freaking forever.

5. Remain silent. No hints or explanations of how things work.  You’re a fly on the wall. (The exception would be a known glitch that hides information and could cost time, for example a tutorial notification that isn’t showing up in this version for some reason, but will be in the final version.)

6. Take notes.

 

About four testers in one evening generated this many written notes.

7. Have a roundtable discussion afterwards. If you’re making games, odds are you have friends who have strong opinions on games. This is one of my favorite parts of the testing party. I’m surprised to hear what people liked and didn’t like, what they would like to see in the next version.

8. Process your notes and thoughts the next day.  I personally love using BlueMind for this, but maybe that’s because I’m a recovering organization software junkie.  The point is to get a nice list of bugs to be fixed, major remaining design issues, principles on designing levels going forward, etc.

This is a branch of the mindmap I made based on last week's playtest.

So that’s it, hope this has been somewhat helpful, and if you’ve got additional tips, please post them in the comments!