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.

Sprint Retrospectives

An update from Trevor, a member of the Guildhall at SMU team blogging for Gamasutra:

Sprint Retrospectives

Projects that use Agile with Scrum use sprints to promise features to their product owner (customer/manager); sprints usually take place over a 30-day period. At the end of a sprint, teams conduct sprint retrospectives. These meetings discuss what was delivered from the team during the sprint, what processes were effective or ineffective (or could be improved upon), as well as actions to take place during the next sprint. In essence, they are small postmortems during development.

Features Delivered:

This section is simply a list of features the team completed during the sprint that the product owner receives. It is important to note that these are not tasks, but features. In Agile with Scrum, the features are found in the Product Backlog (List of the game’s features).

Examples might include:

  • All main character sound effects
  • Level 1 Whitebox
  • Jump Component

What Processes Were Effective:

This section lists the processes team members found effective during the sprint and would like to see in future sprints. Additionally, a vote is taken to see how many members of the team feel that way about that process.

  • Examples might include:
    • Communication processes were effective – 4 votes
    • Daily backups to external hard drives – 5 votes
    • Daily scrum to gain knowledge of group progress – 4 votes

What Processes Had Negative Effects (Or could be improved):

This section allows members to voice what processes they felt impeded progress due to inefficiencies, or need improvement to be made effective. Team members vote to see how many people in the team feel the same way.

  • Examples might include:
    • Playing music out loud is distracting to the work environment– 4 votes
    • Uploads to source control need to be more frequent – 5 votes
    • Bug reporting needs to be maintained by all members – 4 votes

Sprint retrospectives provide a way for team members to reflect on the past sprint and analyze what they liked and disliked during the sprint. I have seen many great things come out of these meetings and future sprints have truly improved based on members voicing their concerns to the team. I believe sprint retrospectives should be applied to all game developments. Even if the team isn’t using Agile with Scrum, a postmortem at every milestone still provides useful insight.

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on Sprint Retrospectives

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

An update from Ben, a member of the Guildhall at SMU team blogging for Gamasutra:

Retrospective Report
Sprint 2 – Proof of Concept Gameplay
10/29/2012 – 11/2/2012

1. Introduction
The purpose of the Retrospective Report is to describe in detail the specific activities that were most effective and those that need adjustments prior to the sprint.  A goal of the document is to inform future sprint teams of the obstacles encountered during this release. Sprint 2 began on 10/29/2012 and went through 11/2/2012.

2. Release Overview
Sprint 2 was the second and last Proof of Concept sprint before moving to Vertical Slice.   It contains:

  • Voice overs scripts written and outsourced for auditions
  • Implementation of placeholder music and sound effects
  • Salvage pickup functionality and placeholder art
  • Mines enemy functionality and placeholder art
  • Juggernaut enemy shoots at player
  • Overshield and temporary invincibility mechanic functionality with no art
  • POCG asteroids level whiteboxed and tested
  • Placeholder HUD containing shield, juggernaut directional arrow, and player’s score
  • Placeholder controls screen for kleenex tester
  • 7 bug fixes

3. Release Quality Statistics

Below are some statistics from the prior two sprints:

Sprint # Playtest Hours # Defects Found/Fixed
Sprint 1 – Proof of Concept Technology 4 5/5
Sprint 2 – Proof of Concept Gameplay 4 7/7
Total 8 12/12

4. Process Review

  • 4.1 Processes That Were Most Effective for the Sprint
# of Votes  Things Done Well
4 Scrum boards helped the team keep organized and on track for milestone completion.
4 The team feels glad that they are learning scrum processes now so that they can be more effective in later TGPs [Team Game Projects].
4 The team is excellent at making decisions effectively and expediently.
4 The team likes that core hours are productive.

  • 4.2 Processes That Had a Negative Effect on the Sprint
# of Votes Need Improvement
4 The team feels that scrum boards feel like micro-management for a team of four developers.
4 The team feels that locks are hard to stick to and poorly defined.
4 The team felt that adding new milestone requirements in mid-sprint impeded their work.
4 The team feels that administrative assignments such as documents get in the way of development.

5. Action Items

Below are the action items we will immediately put into place to improve our next sprint:

  • Add player feedback for every aspect of the game, including moving the HUD onto the ship itself so that the player does not have to avert his or her eyes from the gameplay.
  • Remove the juggernaut [enemy] directional arrow in the HUD because the juggernaut is always behind the player and at the bottom of the screen.
  • Level 2 needs to be the level that we develop for Vertical Slice because it contains the all of the core features of Salvage Runner.
  • Begin working on level 3.
  • Add warp drive art.
  • Make the end of the level apparent with sounds and art.

6. Variances

Sprint Est Hrs Act Hrs Variance % Variance
Sprint 1 – Proof of Concept Technology 44.5 38 6.5 117%
Sprint 2 – Proof of Concept Gameplay 72.5 60 12.5 121%
Averages 117 98 19 119%
Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on The Sprint Retrospective Process in Practice: Iterating on Salvage Runner’s Successes and Mitigating Its Risks (Part Two)

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

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on The Sprint Retrospective Process in Practice: Iterating on Salvage Runner’s Successes and Mitigating Its Risks (Part One)

Summary of My Sprint Retrospectives at The Guildhall

An update from Navin, a member of The Guildhall at SMU team blogging for Gamasutra:

I am currently the producer on two projects at The Guildhall at SMU. Each of the teams consists of at least one artist, one programmer, and two designers. They are currently working on a new engine created internally by the Guildhall.

The two games consist of:
Miasma – 2D classic platformer
Untethered – 2D gravity shifting platformer

Throughout the ten week project, the team passes through six different milestones (Proof of Concept Technology, Proof of Concept Gameplay, Vertical Slice, Alpha, Beta, and RTM). After each milestone has been successfully completed, each of my teams goes through a sprint retrospective meeting. This meeting allows the team to discuss the effective and ineffective process that occurred throughout the milestone.

The process goes as follows:


This initial part of the meeting discusses the product that was delivered for the milestone. Examples of the product are as follows:

  • Vertical Slice level white-boxed
  • Gravity shift mechanic fully functional
  • All character animations completed

Effective Processes:

This next part of the meeting discusses the effective processes that occurred during the milestone. Examples of these processes are as follows:

  • Team High Product Buy-in
  • Daily Scrum Meetings Were Productive
  • Good/Responsive Communication Between Disciplines

Ineffective Processes

This next part of the meeting discusses the ineffective processes that occurred during the milestone. Examples of these processes are as follows:

  • Personal issues should not be brought into meetings during core hours
  • Bugs need to be reported to Issue Manager
  • Commits/Uploads to source control needs happen more often
  • Communication between the Executive Producer and the Assistant Producer needs to be improved

Future Milestone

This final part of the meeting discusses the plan for next milestone. Examples of this plan are as follows:

  • Complete all animations for environment hazards (lasers, hullbreaches)
  • Menu/HUD functionality
  • Finalize/Polish Vertical Slice Level

Overall, sprint retrospectives allow the team to reflect back on what they have done on the previous milestone sprint. It lets the team speak openly within the group to address effective/ineffective process as well help map out plans for future milestone sprints.

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on Summary of My Sprint Retrospectives at The Guildhall

Guildhall Production Track 3: The Sprint Retrospective

An update from Dustin, a member of the Guildhall at SMU team blogging for Gamasutra:

Last week marked the Proof of Concept Gameplay milestone for Team Game Project (TGP1) teams here at Guildhall.  These teams each consist of four or five student developers from the Guildhall’s newest class of students, Cohort 19. I serve as Associate Producer for two of these teams, and lead them through their Sprint Retrospective after each sprint.

For projects this small, each sprint retrospective looks back at about one week of work for the teams. This is far more frequent than development in a professional environment, of course, but serves as a useful learning tool and puts us in the habit of using good practices. So far, I found these frequent, scheduled half hours of reflection have already allowed the teams a chance to question and address pieces of the process that are and aren’t (yet) working for them, from significant to mundane. For example, one team addressed a growing appreciation for the visibility scrum offers, and another brought up a lack of whiteboard space. More than anything else, the retrospective is an opportunity to discuss the project development and find ourselves all back on the same page. As a producer, it’s a chance to hear our problems. In the easiest circumstances, they’re whiteboard-sized problems that can be rolled out of storage and into the team’s room.

The Sprint Retrospective consists of:

1) A quick overview of the sprint, its place in the project, and the goals of the sprint

2) A review of the playtest hours, and number of bugs logged and resolved

3) A review of the processes that the team felt were effective and ineffective

4) A list of action items for the team to implement immediately. Typically these address the ineffective processes mentioned earlier.

5) A review of the estimated and actual effort required to complete the sprint, and their variances

At the Guildhall, the Sprint Retrospective takes place on each milestone day. I sit down with my teams and go over each topic over the course of a half-hour meeting. We address action items as immediately as possible, and I formalize the meeting into a Sprint Retrospective report later that day. These reports are useful to look back at each milestone to see if the issues have been adequately handled.

At the Austin GDC Online this year, I attended an “Agile: Are We There Yet?” roundtable where the importance of the Sprint Retrospective came up. I regret that I don’t recall the producer who emphasized it, but her point was that she liked seeing the new problems addressed in a retrospective, and saw them as signs of progress. Repeats of old problems mean we aren’t hitting issues as they arise.

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on Guildhall Production Track 3: The Sprint Retrospective

ShadowMaster through the lenses of Steve McConnell’s 36 Classic Mistakes

An update from Benjamin, a member of the Guildhall at SMU team blogging for Gamasutra:

ShadowMaster is a 2D top-down spatial puzzle adventure. A team of four fresh students attending the Guildhall at Southern Methodist University designed, animated, coded, tested and implemented their original game idea in Torque X 2D Builder. The team consisted of an artist, Michael Viscio, a programmer, William Wood, a level designer, Chih Han Yu, and a producer and team lead, Ben Roye. The team developed the game in ten weeks while attempting to stick to forty-eight team-hours per week. The current build of ShadowMaster runs on Windows 7 and can be downloaded for free. Future plans for the game include a likely port to Xbox Live Indie Games Channel.

For ShadowMaster’s postmortem, I will examine the game’s 10-week development cycle under the lenses of Steve McConnell’s 36 classic mistakes from Rapid Development: Taming Wild Software Schedules.

You Live and You Learn – What Went Wrong?

Classic Mistake #36: Lack of Automated Source-code Control

For this project, professors outfitted the development team with Apache Subversion. Subversion, or SVN for short, is a source control software that allows developers to add and commit files to a repository. For a basic project, such as a 10-week game project, it does a decent job of keeping files versioned, organized, and safe from hardware problems. However, for an inexperienced team, using SVN equates to only allowing one person to work in the game editor at a time. In the beginning of the project, this posed a problem:

According to the class’s syllabus that dictated the basic requirements for the game project, producers must demonstrate skill in their minor specialization as well as lead the team. Ben has a specialization in level design. Therefore, he was required to implement a self-designed level in the game editor. Because of SVN’s limitations, the team decided in the beginning of the project that Chih Han Yu would be the sole person to work in the game editor so as not to cause conflicts in the source control repository.

Classic Mistakes #7: Friction Between Developers and Customers and #29: Feature Creep

Much like the source control problem, there was not a whole lot the team could do to avoid classic mistake #7. In the industry, games are graded by Metacritic scores and sales volume. However, in an academic setting, games are quite literally graded. The class’s two professors comprised the team’s customer base. Once a week, a new tester would perform a kleenex test of ShadowMaster while one of the class’s professors graded the kleenex test. A kleenex test is defined as fresh eyes playing a game without any developer feedback. Most testers pointed out flaws in the user interface or gave feedback that the goal was not clear.

As each kleenex test was wrapping up, the professor grading the test gave their commentary on the state of the game. The professor often posited that the team should add new features to make the game more fun. After each week’s kleenex test, the team discussed the tester’s and professor’s comments and changed the schedule accordingly. In a battle between a sure schedule and new features, new features usually won out. The most noticeable feature that the team added to the game late was the collectable pickup system. The team implemented this feature expressly because a professor suggested it.

Classic Mistakes #27: Code-like-hell Programming #30: Developer Gold-plating, and #4: Heroics

The team’s programmer is brilliant. Albeit, he likes to work at his own pace. During the first few weeks of production, the team’s programmer performed scheduled tasks and estimated his times reasonably well. (The team comprised of completely new students, after all!) However, as the team progressed from the Proof of Concept Gameplay milestone into the Vertical Slice milestone, the programmer began to shirk his scheduled tasks in favor of self-appointed tasks and work on tasks for longer than he had estimated. The reasons are three-fold: he enjoyed the task of finishing code the night before a milestone (#27) and he liked to write solid code that supported additional future functionality (#30). Due to his extra code gold-plating, he underestimated his task times (#4). Since the project was small in nature, the net effect to the schedule was minimal if there was an effect at all.

But Wait, There’s More…What Went Right?

Besting Classic Mistake #21: Inadequate Design

The team spent considerable time outside of class iterating the game’s design on whiteboards and on paper. The design of ShadowMaster is deceptively simple: the player can move the onscreen character in four directions and press a single button to interact with the environment. Whenever the player pushes the character into a grated object such as jail bars, the character stays in place while the character’s shadow progresses to the space the player pressed. Now, the game becomes a puzzle of desynchronizing the shadow away from the character, synchronizing the shadow back to the character, and executing both of these mechanics while interacting with the environment to solve puzzles and proceed to the next level. At this point, the game becomes almost infinitely scalable. Developers can add character and shadow interactions with the environment and interactions with each other to create an increasingly exponential number of spatial puzzles for players to solve. In the end, we designed the game to be narrow yet deep, minimalist, and open to building features on top of the simple base design.

Besting Classic Mistakes #17: Insufficient Planning and #25: Omitting Necessary Tasks from Estimates

Once the team decided on the basics of the game design, they deconstructed the game. The destruction showed a complete list of tasks and task dependencies all the way from the game’s inception to its ship date. The team made sure not to omit necessary tasks. For instance, every time the artist completed a piece of art, the level designer had a task to test that art piece specifically. The level designer had mostly testing tasks as he was always testing new art and components. The team also made sure to include tasks for daily meetings, kleenex test writing and reporting, post-sprint design meetings, etc.

The deconstruction served as a great tool in setting up for Agile’s scrum methodology of software project management. The team taped up several large white sheets of paper to the wall. The team labeled each paper with the appropriate milestone names: Pre-production, Proof of Concept Technology, Proof of Concept Gameplay, Vertical Slice, Alpha, Beta, and Retail to Manufacturer.

Professors distributed sticky pads each colored in accordance with a student’s specialization: production tasks were blue, level design tasks were orange, programming tasks were green, and art tasks were yellow. The team continued with the scrum process by writing all the tasks from the game’s deconstruction on the stickies (one task per sticky). Stickies included a task’s name, its estimated time for completion, the date it was created, the date it was completed (if applicable), and the assigned person’s name. Since the team only had one team member in each discipline, each team member had their own sticky pad color which made things easier.

Once the team wrote all of the stickies, they organized them into milestones based on task dependencies shown in the deconstruction and placed them onto the large white sheets of paper under the appropriate milestone headers. With the basics of scheduling set up well, it was easy to see exactly how much time the team had to complete certain features. Right away, the team cut conveyor belts out of the game. The team also realized if they worked efficiently and completed tasks ahead of time, cut features like the conveyor belt be reinstated into the schedule.

During production, the team held daily scrum meetings. Scrum meetings are short meetings with the intent of finding out what individuals have done since the last meeting, what they plan on doing until the next meeting, and if they have any blockers such as hardware or software issues impeding their progress with certain tasks. During scrum meetings, team members moved task stickes from the planning boards to the “Checked Out” board to indicate they were currently working on those tasks. Developers would move completed stickies to a board with the moniker “Tasks Completed”.


The ShadowMaster team did experience a few of Steve McConnell’s classic mistakes during the course of game production. There was nothing the team could do to avoid using Apache Subversion. It was a project requirement set by the school. The only thing that SVN prevented was letting the producer work in the editor at the same time as the level designer. However, this allowed the producer to focus on writing and maintain documentation and filling in other gaps like finding sounds and music. The team circumvented the problem by leaving the level design tasks to the level design expert. The team also encountered the classic mistakes of friction between developers and customers and feature creep. After kleenex tests, the professor suggested ways in which to improve ShadowMaster’s design. Since the team was new, they added features almost weekly thereby increasing the schedule as well.

The professor’s suggestions also fed the programmer ideas for gold-plating the game with his own ideas including a score screen and levels that can be unlocked only after collecting all of a stage’s collectibles. Developer gold-plating intertwined, fed off of and propagated more code-like-hell programming and programmer heroics ensuring long nights of programming before milestone day.

The ShadowMaster team did employ some moves that bested the classic mistakes of insufficient planning and inadequate design. The team spent sufficient time in the pre-production milestone designing the game and scheduling future milestones. The team also embedded Agile’s scrum practices straight into the heart of the project planning and execution methodology. Spending sufficient time on ShadowMaster’s deconstruction proved invaluable to setting up scrum practices. Scrum ensured the project was tracked daily and tracked well. Moreover, besting these two classic mistakes seemed to pave the way for success from the beginning.

ShadowMaster “shipped” with 17 regular levels and 3 bonus levels that players had to unlock. The game was well received by the faculty as well as the student body of The Guildhall at SMU. The game was peer-voted to be the best game overall out of five candidates.

Full Game Download (~486 MB) 

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on ShadowMaster through the lenses of Steve McConnell’s 36 Classic Mistakes

Cyborg Ninjas on Fire 2: Reloaded

An update from Navin, a member of the Guildhall at SMU team blogging for Gamasutra:

Cyborg Ninjas on Fire 2: Reloaded (CNOF2R) is a fast-paced, over-the-top, first person-shooter mod for UDK. The players take on the role of futuristic cyborg ninjas fighting over control of a legendary suit of armor called the Yoroi. The total development time for CNOF2R was ten weeks (thirty person-hours per week), and was developed for both the Xbox 360 and PC platforms. This postmortem analyzes the obstacles and challengers our team encountered during the production phase.

What Went Well

1. Functional Working Environment

At our workplace, other development teams have already occupied all of the breakout rooms in the building. Fortunately, we found a small pit area downstairs and decided to make it our group’s working space. We had all seven of us sitting merely a few feet away from each other, which made comments and critiques communicated easier. This process drew us closer together creating a work culture that was very enjoyable to work in.

2. Motivation

From the beginning of the preproduction phase, the one thing that remained constant throughout the whole development cycle was the high level of morale. Every member of the team had a huge buy-in for the game which created a positive working environment with highly motivated developers. This environment encouraged all team members to bring up their thoughts, ideas, and opinions regarding the game.

What Went Wrong

1. Lack of User Input

One particular thing that didn’t go as well was the lack of play testing during each sprint. This was primarily due to the time constraint given for the whole project. The amount of content that was created during each milestone created almost no opportunity for play-testing. As a result of this, we had to spend valuable time during the later stages of development to resolve issues that we had.

2. Omitting Necessary Tasks from Estimates

This classic mistake has happened to me on every game development project. Management, research, technical, or unrelated development tasks were unaccounted for during each sprint. These tasks are as simple as having short one hour meetings to importing assets into the engine. The process of getting an asset to look the way it should in the engine consumes enough time for it to go up on the backlogs. These additional tasks pushed back initial tasks, forcing us to cut certain aesthetic features initially planned for the game.

3. Feature Creep

As we progressed through each milestone, the team became more and more excited about the game we were creating. Mid-project changes started to occur because the team obtained a better understanding of the game created. The team went through about a 40% feature change in ten week period during the production phase.

It seemed like a great idea at the time because the majority of the team had buy-in for the game. However, towards the final phases of development, many of the developers had to pull several heroics to reach sprint goals.


Overall, CNOF2R was a fun and great learning experience for the team. This opportunity has given the team valuable learning lessons in game development, and we will carry these lessons forward throughout all of our development careers. Overall, we felt that by creating a positive working environment accompanied by highly motivated developers, we were able to create a game that our team was extremely proud of.

Development Team

Alejandro Daza

Mike Direnzo

Sara Fillman

Elizabeth Labelle

Ravish Nair

Navin Supphapholsiri

Matthew Wingler

Game Download

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on Cyborg Ninjas on Fire 2: Reloaded

The Day Ice Cream Stood Still

An update from Trevor, a member of the Guildhall at SMU team blogging for Gamasutra:

The Day Ice Cream Stood Still is a 2D platforming puzzle game that was designed using the TorqueX 2D editor by a five-student team from The Guildhall at SMU. The game took ten weeks, using 60-hour man weeks from concept to completion and was developed for the PC using a console controller.

This following is the post-mortem for The Day Ice Cream Stood Still. The Classic Mistakes in reference to Rapid Development by Steve McConnell describe what went well, what went wrong, and what we as a team learned from the development.

What Went Well:

1. Avoiding Classic Mistake #1: Undermined Motivation

If one thing was true of the development team, from the very beginning they acted as a team and not as individuals, always motivating each other to better the game. The team often times inspected the work of others, while giving constructive criticism, the team always remained very positive towards each other and always working to uplift one another.

Communication between team members was very efficient between everyone. All members knew how the game was progressing in all disciplines. This is in part due to using Daily Scrums at every meeting, but even when the team was not gathered, emails informing the team of current progress were very common.

2. Avoiding Classic Mistake #20: Shortchanged Upstream Activities

This team was new to video game design, and shortchanging upstream activities was very tempting to all the developers. It would have been much easier to not worry about the design of how pieces of the game were going to come together. The “cross that bridge when we get there” mentality was always lingering. However, the team followed protocol and did not cut anything that was necessary which was essential to the game’s development.

3. Avoiding Classic Mistake #29: Feature Creep

In the beginning of development many features and mechanics were discussed and most of which the team wanted to put into the game but we stuck with a specific set of features and mechanics to implement. As progress continued, other features came about that some wanted to implement but as a team we discussed the possible ramifications of adding such features, most were mutually rejected but through these discussions, important features we decided were necessary for gameplay were added.

What Went Wrong:

1. Encountering  Classic Mistake #22: Shortchanged Quality Assurance

Through all the team’s attempts to make as best a game they could. Too much time was spent on developing and not enough time was spent on actually testing the game with anyone who would be willing. This mean the game was essentially built in a sort of vacuum. While the team did their best to gain feedback, especially near the end of development where they began testing with anyone, not enough testing was spent in the early stages of development.

2. Encountering Classic Mistake #4: Heroics

As discussed earlier the team was highly motivated making this game and wanted to see many features in the game while meeting required deadlines. To appease ourselves with our work, the team pulled many heroics to achieve the kind of quality The Day Ice Cream Stood Still had. This not only affected our ability to hold the project together at times as well as our overall productivity decreasedas team members became tired and easily distracted through lack of sleep.

3. Encountering Classic Mistake #14: Overly Optimistic Schedules

The team through sheer positivity hurt itself in the end by being overly optimistic during the planning phase. The team was determined that all the tasks listed were going to be completed, which led to the previous “What Went Wrong” topics.


Overall, making The Day Ice Cream Stood Still was a fantastic experience that I would not trade for anything. The team accomplished precisely what it set out to do that is, build a fun 2D game for the masses.

Additionally we learned many important lessons from the development. Communication is incredibly important in development projects. The importance of motivation between team members for the project to complete, The Day Ice Cream Stood Still would not be what it is without the motivation from team members.

The Day Ice Cream Stood Still is a completed demo of a 2D platformer with three fully fleshed out levels that are all incredibly fun and challenging. The game was voted Best Original Art out of five other great candidates and was shown at exhibition at The Guildhall at SMU!

Developed by: Team One Scoop

Trevor Hilz – Assistant Producer

Hieu Vu – Lead Level Designer

Natan Golynskiy – Level Designer

Anthony Stogner – Lead Artist

Chatchai Wangwiwattana – Lead Programmer

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on The Day Ice Cream Stood Still

Revisiting TGP1

An update from Dustin, a member of the Guildhall at SMU team blogging for Gamasutra:

Time moves strangely at the Guildhall. We’re off in Plano, miles away from the SMU campus proper, in our own little video game world. Not that we’ve learned much about Plano. I’m familiar with the two streets between my house and the Guildhall.

Generally, a quarter of your coursework is intended to be dedicated to team game projects (TGP). But as you might imagine, when you give a group of gamers the chance to work on their (usually) first group video game to completion, the effort they’re willing to put in is sometimes beyond the project requirements. Our schedule is almost universally considered relentless, but a lot of it is a self-imposed workload. I played a lot more video games before I was in video game school.

About five months ago, my first team game project (TGP1), FrankenFrenzy, ended. In less than a month, I’ll be tasked as the producer for three new TGP1 projects in the newest group of Guildhall students. The Producer specialization track is new to Guildhall, and my class of producers will be the first group to revisit TGP1 in a changed role.

As such, it’s come time for me to look back at FrankenFrenzy. I get to pretend to give sage Yoda-like wisdom as someone who’s a whole semester ahead of the newest Guildhall class. Honestly, read this as, “I still have no idea what I’m doing, but here’s what I’ve got.”

The scoop on FrankenFrenzy

At Guildhall, TGP1 is a 7-8 week 2D game project for 4-5 cross-discipline students, making up a quarter of their class schedule. The content of the game is limited only by reasonable subject and scope. For FrankenFrenzy, we used Garage Games’ Torque 2D. The new students will use GuildEd, the Guildhall’s new internal engine. FrankenFrenzy is a bare-bones real-time strategy game reminiscent of Plants vs. Zombies. The player acts as Dr. Frankenstein by building monsters, deploying them, and giving them custom upgrades made out of the body parts of attacking villagers.

FrankenFrenzy’s development was a humbling, frenetic, learning-to-doggy-paddle experience that I really enjoyed. The whole team ended up happy with their experience, and the result. I may be as excited to do TGP1 again as I am to move on to our Capstone game (TP3).

So now I’ll run by a few bullet points of my FrankenFrenzy postmortem, with comments.

What went right:

  • Kept well-defined roles.

True enough, in retrospect. My team started out with an artist, a level designer, a programmer, and myself, a producer (A second programmer joined our team during development). I say that we kept our roles, but even in the real industry, a producer’s role isn’t always well-defined.  In this tiny project, the producer role meant I did whatever extra work was there, wherever we were a bit behind. On FrankenFrenzy I’d guess my time was about a quarter management, a quarter test and balance, and a half artist. Generally, FrankenFrenzy’s art schedule was overloaded and I was comfortable enough with 2D drawing to help.

  • SCRUM kept us productive

I’m a believer. I find SCRUM to be simple, intuitive, and useful – for visibility, for accountability, adaptability, as a dependable line of help. Guildhall teaches SCRUM early, so I’ve not experienced many alternative formal methods. At first, it was almost natural to dismiss SCRUM as a mild inconvenience, and some of the TGP teams honestly didn’t bother. My team practiced SCRUM regularly, even if half-jokingly at first. It didn’t take long for my appreciation to sink in. I can’t say definitively that the SCRUMming teams benefited over those that didn’t, but it seemed evident, even on projects that small.

  • Team stayed motivated; high attendance and productivity
  • Clear product vision and priorities
  • Ease and speed of conflict resolution

I’ll not air out ever-so-slightly-dirty laundry, other than to say at one point I stepped on some toes, was kindly told I was wrong, so apologized and stopped the toe-stepping. Nothing special about any of that, except that it all happened in a 48-hour period without drama. I still privately contend that I was only mostly wrong.

What went wrong:

  • Changing scope during development, and
  • Scope required work outside scheduled hours

It was inevitable. As first-time developers, our eyes were bigger than our stomachs. Oh sure, it will be easy to start out with a modest ten monster abilities, three bad guys, and five different pieces of equipment. Wait, how long did that animation take? Wait, how many icon variations does that mean? You mean we have to do a five-minute task for each permutation of xyz? It adds up.

  • Didn’t keep up with quality control regularly enough, and
  • Unstable build during open beta

We had precious few testing hours scheduled, and even fewer completed. We can’t say we weren’t warned. Testing often, testing early, it’s drilled into us. It’s really more valuable than I realized, even when I’ve been taught the lesson before, even when I’ve learned it first-hand and promise myself I’ll test more next time. It’s hard to imagine ever saying that I tested a game too much. So when we had a big day set aside with dozens of testers available, and our build crashed before the players could win in five games out of ten, we had to make the best of it.

What I learned:

  • Make vision/direction/quality requirements clear early.
  • Test often. No, more often than you’re thinking.
  • Individuals need spheres of responsibility.
  • Respond to small issues quickly before they grow, personal and technical.
  • Set the pace and work ethic for the team.

So there you have it, my first blog post. Thanks for reading. I’m meeting my new TGP1 teams, so wish me luck.

Posted in Guildhall at Gamasutra 2012 | Tagged , , | Comments Off on Revisiting TGP1