Postmortem: ShadowMaster through the Lenses of Steve McConnell's 36 Classic Mistakes

Postmortem: ShadowMaster through the Lenses of Steve McConnell's 36 Classic Mistakes

Puzzle Example

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?

Puzzle Example 2

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 kleenex 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?

Score Screen

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”.

 

Conclusion

Level Select

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 collectables. 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 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 Southern Methodist University. The game was peer-voted to be the best game overall out of five candidates.

Trailer
Full Game Download (~486 MB)