Eradicate Week 3: Playtesting Demos

Should I get this playtest?

That is a question I have heard from people before, and I even ask myself often. At times I constantly have a list of new tasks, features, or controls that need to be completed. Might as well keep my head down w/o rolling a build and actually playing the game. Also my vanity doesn't want to show to anyone an unpolished app or game.

But let's all agree. Don't do this!

Remember one form of waste according in software development: a feature built that you never use, or even toss later. When you start actually playing your unpolished game, you will find what is actually working or not working now. I don't mean not working as in crashing or bugs, but the UI failing, or missing information you need to include, or too much information that you can hide. Remember one design principle that Apple tries to live by is to include less not more.

By playing you demo or playtesting your game early, you can truly prioritize what does (or, just importantly, does not) need to be included next. Don't polish or finalize artwork that you might remove later. Keep playing you game and make notes of how you actually use the game. Hand it to a family member, a friend or a stranger at the cafe, and see what their pain points are.

Are they confused because there is too much information? Do you instantly understand what the point of the game is? Are the controls intuitive?

http://www.mmorpg.com/showFeature.cfm/loadFeature/4936 has a great quote towards the end, "… companies still have a lot to learn from their players. It amazes me how much money is spent on games and how many of them fail". One key takeaway is learn from your audience early, and learn from them often.

Here is their montage of MMO fails:

The reason I am bringing this up is that I was just able to get our Outbreak project to a playable demo phase on Thursday. The controls, actions, basic game data, and status updates are all there.

So instead of working on some better animations, fixing UI layout, creating better end game sequences or the message show to the player, I should just be playing the game, and getting others to play it. Now that we have an actual playable game, instead of polishing the below, I am going hand it to a few people and just let them play, form some ideas and listen to them.


(though I should probably get some better color for the different regions, just so eye squinting isn't an issue).

Don't take my word for it. Check out this Gamasutra article, How Many players should you playtest with. Many indie devs will have a hard time setting up a video recorded playlets, but check out some of the helpful hint in the article like, sit next to them, ask specific question and then observe (no talking about the game, let them discover it).

So this dev diary is less about what was made this week, but more about what I need to do to inform what I should be doing next week, and the week after. We are starting to work on the in-game graphics, UI design and even sound effects and music. I can't let my imagination run wild, nor let the game 'as it is' get too much of an emotional hold on me s that I don't want to change it. Also if I am constantly looking at class methods and CCLayers I won't ever see the forest for the trees. Getting outside, detached feedback is critical to success, but early and late in game design and development.

Let me know some of your best or worst experiences, on either side of the playtesting table. Comment below, or with Twitter,

This is a dev diary about our Outbreak project (view all posts here). Also visit Skejo Studios to see all we are doing there.