Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 31, 2014
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
How We Test Our iOS Games
by Matthew Burns on 05/30/13 10:45:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

​This blog was originally posted on the Choo Parr Productions website on May 29, 2013.

Ah yes, I have started to test 'Kick The Kitties' as each of its sixteen levels are being hammered out. I know testing can be tedious, but it can be fun and more importantly it is essential to development of a great game. Essential!

I established a simple testing system when developing 'Goats R Delicious' last year and it seems to be very effective. Before I continue, remember this is an iOS game and I am utilizing TestFlight on the appropriate mobile devices.

If levels are in the process of being developed, I always start with the latest level and then work my way down to the very beginning of the game. Once all levels are built, upon receiving the latest version, I start from the very beginning of the game. Remember, before installing the latest build via TestFlight, restart your mobile device.

It has been my experience to be clear and concise when communicating with your programmer (or at least I try). Even if you are the programmer, you will not remember every situation and will appreciate a standard format that is easy to decipher.

I use my iPad to do the mundane testing because of its interactive ease in capturing images and placing them in your gallery. This is what I do:

  1. I play the entire level (I probably die several times) and take images of situations were errors, concerns, questions or suggestions appear.
  2. Upon completing a level, I enter my gallery where these images are located.
  3. Each image becomes the basis of one email which is to be sent to the programmer (or self).
  4. Each email has the following in the subject header; TestFlight Versions #, Level # and a number or letter so one can keep track of the many emails from a particular level. For example, "Version #56, Level 8 p.3" tells me this is the third image from my walk through the eight level on the 56th build upload. Everything I send has to be documented.
  5. Finally, each email has to have a comment about the image because things are just not always obvious.

Here is some advise I have about actual testing:

  1. Test every wall section or boundary to make sure you character cannot penetrate anywhere outside of game play. Having your character falling into the "blue" or being "stuck" can be demoralizing and players will notice!
  2. Die on every spot where you have designated the character's possible death and make sure the dying sequence and images are consistent. You do not want your images to bleed.
  3. If you character can jump, jump everywhere! You never know where a hidden collider is.
  4. Walk or run on every surface available. There is nothing worse than having your character fall through the floor and into the "blue."
  5. Make sure your spawning points are spawning consistently.
  6. Stand in front of or behind every object/item available.
  7. Make sure there are not any unplanned "dead" areas that give the players unintended refuge.
  8. Are the mathematics behind health, score, item collections and et cetera working properly?
  9. Kill every "opponent" you have placed in your game. Verify that every "opponent" functions correctly.
  10. Destroy every "item" you have designed as destructible. Verify that every "item" functions correctly.
  11. Use every "facilitating object." Verify that every "facilitating object" functions correctly.
  12. If possible, do numbers 6 thru 8 in a different order or created other possible progression situations within a level. Not everybody plays a level the same way you do.
  13. Make sure your music is looping correctly.
  14. Finally test your UI extensively.

I know many of you could add things to the list, but hopefully I covered the basics.

Remember, game play memorization is your enemy and therefore try and approach every new upload a little differently than the previous one. Best of luck!


Related Jobs

Next Games
Next Games — Helsinki, Finland
[10.31.14]

Senior Level Designer
Activision Publishing
Activision Publishing — Santa Monica, California, United States
[10.31.14]

Tools Programmer-Central Team
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States
[10.31.14]

VFX Artist-Vicarious Visions
Magic Leap, Inc.
Magic Leap, Inc. — Wellington, New Zealand
[10.30.14]

Level Designer






Comments


Katy Smith
profile image
Hello Matthew!

I got my start testing games and haven't really ever given it up completely over my career. Here are a couple comments. First, I highly recommend getting a bug database. It's so much easier than trying to deal with e-mail. There are a ton out there but I like Jira and DevTrack. Mantis is also very good for small projects (and it's free!) Also, don't forget your menus. I've seen some games that play fairly well, but you can't save them properly because the menus are busted. Good luck with your game!

Matthew Burns
profile image
Thank you Katy for the feedback! I will look into Jira and DevTrack.

You are absolutely right about the menus. They must be thoroughly tested.

Luis Guimaraes
profile image
We have a few "cheat gestures" enabled in test versions to aid, speeding up stuff, jumping to the necessary parts and creating the needed situations when testing.

Matthew Burns
profile image
Those are great features to have!


none
 
Comment: