Rogue podcasters Ryan, Obinna, and Andrew were feeling a bit brazen and decided to record an episode without the other two co-hosts. In this episode we answer the “How”, “Why,” and “What” when playtesting your game.
The guys channel their inner Fido in this episode in referencing a somewhat common phrase, “Eat your own dog food.” The guys explore the phrasing and its many interpretations, highlighting a few ‘gotchas’ when approaching playtesting, such as modular tests versus holistic play testing.
Thanks again for tuning in this week and we hope you enjoyed the show! We are still receiving an overwhelmingly positive response and sincerely appreciate all of the listens, downloads, and ratings and reviews we’ve received on iTunes! Every review helps us immensely.
Game of the Week
The Room - Fireproof Games
TL;DL — “Too long, didn’t listen"
“Eat your own Dog Food” is a software term used to reference a scenario in which a company uses its own product to validate the quality and capabilities of the product.
When play testing, ask yourself, “Is this game system/scene/NPC in alignment with what the game designer/producer/engineer had in mind? Does the functionality match the design?”
Typically, developers are drawn to testing their game modularly (system by system). However, there can be pitfalls when testing things so modularly and you can find yourself missing things that would otherwise not show up until you test the game in it’s entirety.
Testing in Game Development isn’t quite the same as other development domains (i.e. Web development) in so that you can typically test a whole website automatically with things like Continuous Integration testing. This doesn’t quite work in games as there are several other aspects and influences in a game (think, colliders, game objects in a scene, physics) that can’t quite be as well controlled. So, physically testing your game is absolutely essential.
Remember, "small changes can have huge casualties” in your game. Do not assume that moving a game object in a scene one pixel to the left will not cause any problems… playtest, playtest, playtest!
In most games, “fun” is the name of the game. Testing for fun is critically important.
“Fail early and often.” Get your game out there and in the hands of potential consumers (friends, family, etc) and get their feedback on ‘fun’ and ‘functionality.’
Playtesting is something that you should be doing from the very beginning of a project, not something that happens after you’re ‘done’ with the game. Play testing can start as early as the prototype phase of a project.
Check out the Halo 5: The Sprint documentary about how they hired several Halo experts to playtest their latest game.
Playtesting Pro Tip: “Put music/SFx in your game as a final polish step” — or mute your speakers as it can, and probably will, become annoying.
We recommend visiting the Unity Forums to request for feedback on your game in progress. Share it. Test it!
There are key advantages of “blind testing” as opposed to “guided tests”. Blind testing is giving your game to someone without being there to facilitate the user’s interaction with your game. This ‘blind test’ helps with honest and unrestricted reviews on your game by the tester. You can learn what you’re doing right, what you’re doing wrong, and maybe even get new ideas by play testing with others.
The Debug Log Facebook group (“The Debug Lounge”) opens up their doors, inviting members to share their games with the community for play testing and feedback.
Other interpretations of “Eat your own Dog Food” is that you should build robust systems so that they can be reused in your current project and/or other/future projects. Emphasis on code reuse and object-oriented design.
Image: Toine Rooijmans
Our TOPPODCAST Picks 
Stay Connected
