Guildhall at Gamasutra 2012

Benjamin, Dustin, Navin and Trevor are Production track candidates for the Master of Interactive Technology degree in The Guildhall at SMU’s video game design program. With the guidance of Guildhall lecturer and noted game producer and developer Elizabeth Stringer, they are blogging about their experiences for the influential gaming site Gamasutra.

Read more from Guildhall at Gamasutra 2012

The Sprint Retrospective Process in Practice: Iterating on Salvage Runner’s Successes and Mitigating Its Risks (Part One)

An update from Ben, a member of The Guildhall at SMU team blogging for Gamasutra, and assistant producer of:

  • Revenge of the Dragon King
  • Raging Sushi: Enter the Roll
  • Salvage Runner

I am pleased to work currently as an assistant producer for three 2D student-created games at The Guildhall at Southern Methodist University. Each team consists of four underclassmen and I. The underclassmen are working on their first games at the Guildhall.

At the Guildhall, the faculty teaches use of agile development processes such as daily scrum meetings, creating and maintaining scrum boards and product and sprint backlogs, and participating in sprint retrospectives. These three game projects serve as the first time that many of the team members have been exposed to sprint retrospectives. Sprint retrospectives are extremely useful tools because they allow a team to iterate the game, building on the successes and mitigating the risks of the previous sprint.

Salvage Runner is a game that looks like Galaga in an asteroid field, controls like SkiFree, and plays like a “bullet-hell” game. In Salvage Runner, players try to dodge asteroids and debris while outrunning an oversized antagonist who constantly pursues the player.

For the purposes of demonstrating the sprint retrospective process as we do it at the Guildhall, I will focus on the Salvage Runner team because their development highlights good iterative processes. The retrospective report also demonstrates that some team members are learning processes for the first time and do not yet wholly appreciate the importance of documentation or the healthiness of iterating quickly.

Milestone Day Kleenex Test
At the culmination of every sprint, a free faculty member who has never before seen the game comes to the team’s break-out-room and participates in a kleenex test for the game. During this kleenex test, the team cannot talk to the faculty tester. They cannot ask questions when the tester has finished testing the build. The tester gives all feedback that they can think of and then moves on to test another game. Below, I have compiled all of the tester’s feedback into a kleenex report.

Proof of Concept Gameplay Kleenex Report
Salvage Runner
Assistant Producer: Ben Roye
Level Designer: Marc S.
Level Designer: Hakan B.
Artist: Nathan M.
Programmer: Trevin L.

11/2/2012: E. Clune

Overview of Kleenex Tester Reactions and Comments in order of Priority/Severity

  1. Tester never looked at the HUD on the top right of the screen because he was so intently focused on the ship and dodging obstacles
  2. Tester never used barrel rolls
  3. Tester felt that the mines were not aggressive enough
  4. Tester could not gauge well when the indestructible power-up was about to run out. This often hurt him (i.e. he would become vulnerable as he was passing through an asteroid)
  5. Tester thought that while boosting while at the top of the screen, he became stuck

List of Recommendations from Kleenex Tester and Team Action

  • Tester never looked at the HUD
    • Resolution: The team changed their design. Now, the HUD displays on the player’s ship
  • Tester never used barrel rolls
    • Resolution: The team felt as if this tester just did not prefer to use the ability. The team is not changing anything about the barrel roll mechanically
  • Tester felt that mines were not aggressive enough
    • Resolution: The team put mines into the POCG to prove that they had implemented the technology. They plan to improve and polish the mine functionality for Alpha
  • Tester could not gauge well when the invincibility power-up was about to run out
    • Resolution: The artist and programmer design and implement a flash animation and mechanic that occurs when the power-up is about to run out

Appendix: Detailed timeline of Kleenex Testers Reactions and Comments while Playing Game

Time: Description:
5 secs Tester doesn’t understand controls
26 secs “Ah!”
35 secs “Shields are down.”
49 secs Tester experiences slight lag upon respawn
1 min 15 secs Tester died for the first time
1 min 23 secs Tester starting the build over to reread the controls screen
1 min 35 secs Tester understands the controls now
1 min 49 secs Tester not sure about barrel roll
2 min Tester still doing pretty good
2 min 20 secs Tester is doing really well avoiding obstacles
2 min 37 secs Tester died again
2 min 38 secs “No phasers?”
3 min 18 secs Tester dodging obstacles and having fun
3 min 37 secs Tester improving
4 min 10 secs “Only 2 more tries.”
4 min 36 secs Tester only moving left and right
4 min 50 secs Tester starting over. He learned he could move up and down
5 min 50 secs Tester not talking; very into the game
6 min 4 secs Tester not sure how much further to go. He cannot make it past the final field of asteroids to win the level.
6 min 57 secs Tester not sure backing up [towards the Juggernaut] is a good idea
7 min 17 secs Tester has gone past “Last 2 tries.” He is hooked
9 min Tester not clear as to how much life he has remaining
11 min 12 secs Tester still focusing hard
11 min 20 secs Tester mentions he now sees additional health on HUD but would have been more helpful if it was on the ship
11 min 40 secs “Indestructible is dangerous.”
14 min 30 secs Tester beat the level

 

Sprint Retrospective Immediately After the Kleenex Test
After the kleenex test, I lead the team through a sprint retrospective. I facilitate the team in articulating what the kleenex tester said. The most important information gleaned from kleenex tests is often that the tester misunderstood or had no knowledge of a feature. The biggest concern during this test was that the tester hardly ever looked at the Heads Up Display because it was located in the top right corner of the screen. The frenetic gameplay ensured that the tester did not have time to look away from the player ship or else they would collide with an asteroid and die.

Read part two of the post to see the Retrospective Report

Share this story:

    About Kelsey Reynolds

    STU UnGrad
    This entry was posted in Guildhall at Gamasutra 2012 and tagged , , . Bookmark the permalink.