The Power of Public Media

Published: 4 years ago

Making a Game Fast? Don’t Skimp on User Testing and the Iterative Process

Pumpkin Boo!

Pumpkin Boo! is a top-down adventure-style web game we created for Curious George. Over the course of our approximately seven-week production period (Sept. and Oct. 2013), I (Bharat Battu) was the game’s developer, Fran Dias and Dan Nolan were its designers, Laura Nooney and Gentry Menzel were the producers, and Belinda Arredondo assisted on production. Sam and Mourvi were our amazing interns, who helped with many aspects of the game’s production. First, a big pat on the back and THANK YOU to everyone on the team!

Our team was tasked with creating a fall-themed game for Curious George that targeted the young viewers of the show (ages 3-5). We set out to build the game using “HTML 5”, which generally speaking, is a broad category of modern web technologies that allow rich interactive content to run in contemporary web browsers without requiring users to download and install external plug-ins. HTML 5 is continuing to gain traction as a popular means to produce and deliver web game content. It’s been around for a few years, but its assortment of standards and technologies are still being modified and updated today. This, and the fact that content renders differently across platforms, operating systems, and browsers (including different versions of the same browser), mean that there are an ever-growing number of tools and methods to go about creating rich web content in HTML 5, and any resulting output must be checked for consistency across all intended use cases. A seamless, plug-in free user experience is a huge plus for going with HTML 5, but it is a fledgling and at times finicky set of technologies that require testing and experimentation to get just right.

Tiled Map Editor

Considering we had just under two months to produce the game and the fact that we were intending to create an open exploration-style game for especially young players, we anticipated that the majority of our available production time should focus on nailing the appeal, gameplay, and mechanics of the game. Those are the key reasons why we leveraged two free, open-source tools that did a lot of heavy lifting in terms of building the game. The CreateJS suite of Javascript frameworks was used to render and animate our game assets using HTML 5 canvas. Tiled is a graphical map editor, which allows levels for 2D games to be drafted as layers in a simple WYSIWYG interface. The resulting levels can be exported in several different formats, making Tiled work with a large variety of programming languages and game frameworks. An additional plus of using Tiled is that it allowed our game to remain lean, in terms of the number of required image files. A single “spritesheet” image contained the majority of graphical assets that comprised our game levels. This single image was used to draw levels in Tiled, and also to render the HTML 5 game’s graphics via CreateJS (it only had to be loaded once to be used throughout the game). Ultimately, only the first week or so of our production schedule was used to implement these technologies into a working game “engine” that allowed us to create and export game levels from Tiled, and then play them directly in the game without having to modify code.

With the underlying technology taken care of early in the process, we had the remainder of our short production schedule to focus on the game itself. And now reflecting on the game’s overall production, I’d say the importance and value of dedicating time to play-test with kids was the biggest take-away of my experience working on Pumpkin Boo!. We tested a series of iterative prototypes during our production: “officially” a total of three times with children at a local preschool (ages 3-5) and after-school club (ages 5-9), but also informally with friends, family, and colleagues. Our team paid keen attention to the experience our young play-testers were having with the game prototypes. We asked them specific questions about the various pieces of the game we needed feedback on, and we also paid attention to their expressions and moods during and after their playthroughs. Things like whimsy and glee, frustration or confusion, and players’ overall impressions of the game were gathered from both directed discussion and from unspoken signals.

Another meaningful and productive aspect of our play-testing was how, although we always took thorough and detailed notes of our testing observations for documentation’s sake, our team also always met together immediately after a testing session to recap our individual findings. We compared if things one pair of testers found amongst their players were consistent with what other testers saw. We visited each key takeaway and finding from that test session in detail, while the impact and impressions of our observations were still fresh. Our findings from each testing session directly led to action across development, design, and editorial- from slowing enemies’ movement speeds and simplifying their paths, to altering George’s movement so he walks in perceivable “space-at-a-time” steps, to enlarging the size of all game assets and updating the display of indicators for collected pumpkins to be numbered ribbons, to finalizing the wording and frequency of instructional audio read aloud by the Man with the Yellow Hat. For a project completed in such a relatively short timespan, I believe Pumpkin Boo! is a great case study for the usefulness and value of user testing and the iterative process.

Below are examples of experimental gameplay from our earliest prototype, followed by revised gameplay and design from the final game.


before_proto_full

Prototype 1: Final design was not in place at this point, but we saw in our testing that our placeholder assets were rendered far too small for young players to easily keep up with what was happening on screen. Our enemies patrolled back and forth far too quickly, players didn’t seem to notice or care for the optional bunny collectables (which ran around quickly just like enemies), and our level layouts were too windy, tight, and maze-like, which made pumpkins and the level exit difficult to spot and reach. We also implemented mouse controls in the bottom right of the game window, and noticed how it was difficult for our youngest players to use mice or trackpads to interact with the controls while also attending to the action happening in-game.


before

Prototype 1: Our initial game mechanics had George moving continuously while directional keys or the mouse button were held down. This left many young players unable to preceive where George lined up when attempting to grab pumpkins or avoid enemies- they often overshot George’s alignment. George’s movement speed was also faster than what we settled on in the final game. Enemy obstacles were also a bit too tricky, with a great deal of precise movement and timing necessary to grab a pumpkin successfully and tightly enclosed pumpkins seeming like unbeatable traps.

After updating the game through multiple iterations, revised mechanics in the final game:

after_movement

A deliberate-pacing to George’s movement (one space at a time, with slight pause between moves) made controlling George and lining him up easier for our young players. George is always framed in the center of the game window, and the game world pans as the player moves to keep him in center. Persistent on-screen arrows now surround George, so players using a mouse to play are able to focus on one area for the game action and control interface. Specific directional arrows are also hidden when George is at an impassable wall in each direction, eliminating confusion about where he can and cannot move.


after_enemy

More age-appropriate obstacles and challenges. Enemies acting as obstacles before a collectable pumpkin move at a slower rate with simpler paths and discernible, repeating patterns. Players have more time and space to navigate challenges, and get in and out without getting trapped. The directional arrows also change to display an indicator when George is adjacent to a grabbable pumpkin or bunny.


after_offscreen_final

Additionally, we addressed the issue of players not knowing what to do when there are no pumpkins visible on screen in larger levels that span beyond the size of the viewable game area. At times when pumpkins remain but are beyond George’s view, directional arrows appear at the edges of the game window to point players towards the closest pumpkin. Upon collecting all pumpkins, similar directional arrows indicate where the fairground (level exit) is, if it’s offscreen.

  1. By Making a Game Fast? Don’t Skimp on User T... on November 12, 2013 at 8:21 pm

    […]   […]

Have a Comment?

Some HTML is OK