Contents
Making Better Games Through Iteration
 
 
Printer-Friendly VersionPrinter-Friendly Version
 
Latest News
spacer View All spacer
 
February 10, 2010
 
Analysts: EA On The Right Track At Last
 
GamesBeat@GDC Confirms OnLive, GameStop, PlayStation Home Speakers
 
Ubisoft Q3 Sales Edge Down, As It Ramps Up Big Franchises
spacer
Latest Jobs
spacer View All     Post a Job     RSS spacer
 
February 10, 2010
 
THQ
Animator - Motion Builder (contract)
 
LucasArts
Senior Systems Designer
 
Trion Redwood City
<b>Sr. Brand Manager</b>
 
Telltale Games
Game Designer
 
Telltale Games
Senior Software Engineer - Core Technology
 
Airtight Games
IT System Administrator
 
Roblox
Apple Game Engineer - Kids' Virtual World
 
Roblox
Senior Web Engineer (front-end)
spacer
Latest Features
spacer View All spacer
 
February 10, 2010
 
arrow Television, Meet Games
 
arrow Two Halves, Together: Patrick Gilmore On Double Helix [1]
 
arrow The Road To Hell: The Creative Direction of Dante's Inferno [20]
 
arrow The Sensible Side of Immersion [11]
 
arrow Jumpstarting Your Creativity [6]
 
arrow Truth in Game Design [49]
 
arrow Postmortem: Vicious Cycle's Matt Hazard: Blood Bath and Beyond [4]
 
arrow Developers React: The iPad's Future [16]
spacer
Latest Blogs
spacer View All     Post     RSS spacer
 
February 10, 2010
 
Lineage 2 Interview - 'Freya Update Is Just a Beginning' - Pt.2
 
Fixing the GDC 2010 Schedule Builder [3]
 
Swashbuckling for Landlubbers: Why you may already be encouraging piracy! [19]
spacer
About
spacer News Director:
Leigh Alexander
Features Director:
Christian Nutt
Editor At Large:
Chris Remo
Advertising:
John 'Malik' Watson
Recruitment/Education:
Gina Gross
 
Feature Submissions
Features
  Making Better Games Through Iteration
by Will Luton
5 comments
Share RSS
 
 
October 15, 2009 Article Start Previous Page 5 of 5
 

Once the initial prototype is created, then the iterative design process may begin with the Prototype Refinement Phase; each cycle of this process can be considered in a similar manner as a SCRUM Sprint, where the Product Backlog taken in to a Sprint is, in this instance, a list of Proposed Solutions i.e. alternatives to elements perverting the experience which have been isolated via the interpretation of a test.

The test process and the extraction of feedback from it is very key to producing a meaningful interaction. You may choose to focus group test the product or to pass it around between peers or others you know casually.

Advertisement

It is important not to have strongly defined metrics heading in, but instead to observe the user and their actions, as well as what they say. This is because metrics suggest a predetermined idea of issues within the functionality of system, but, from my experience, you are, as the builder of the system, unable to predict what elements within it which may hinder the desired interaction.

The interpretation of feedback from play testing is a skill which could be covered as an article in itself; however, the ability to listen, common sense, and an understanding of the functionality of video games are all invaluable skills.

Once the team has agreed that the prototype functions as it should with placeholder content, or delivered a vertical slice (a complete playable section of game indicative of final quality), the team must move on to the design and implementation of additional content. The length and complexity of this phase is dependent on the type of project.

Once the content has been designed and implemented then begins the Content Refinement Phase. Dependent on the project this may take more or less time than the Prototype Refinement Phase, but uses the same principals focused purely on how the content functions within the parameters of the core mechanics, as defined during the Prototype Refinement Phase. Large changes to the gameplay should not be made unless absolutely necessary.

After this phase the product is in a strong Beta state and should enter QA with a focus on bug fixing only, after which it is suitable for release.

Project Managing the Iterative Design Process

This methodology focuses on producing a product of high quality, however due to its particular efficiencies it can, when correctly project managed, do so within a controlled time and cost.

The main risk when attempting to scope a project using the proposed methodology is that the time each refinement phase will take is an unknown. In an unrestricted implementation each cycle within a refinement phase is of an indeterminate length and there are an unknown number of iterations.

However, to stop both the time and financial costs of production from spiraling out of control it is suggested that the number and length of cycles with a refinement phase are agreed and fixed prior to the start. Therefore, it is important that before a new build in a refinement cycle is started that all Proposed Solutions are prioritized and then completed in that order so as the most important functional changes are fulfilled first.

However, all other phases, such as content development, can be managed using a traditional waterfall model. By defining strict time frames for each refinement phase (as described above) the project manager is able to give a very defined timeframe and cost for the project.

Scope and Suitability of the Iterative Design Process

Although this methodology is proposed for small teams developing unique video game experiences, it has the flexibility to improve the quality of the experience of much larger, more mainstream video games too. In a larger project, the emphasis would be change -- perhaps more toward the Content than the Prototype Refinement Phase.

However, this methodology could suitably be applied to the creation of a proof of concept demo by a small team as a precursor to a larger project, with the feedback from testing placeholder content in the Content Refinement Phase, informing the design of future content.

Its implementation is something that is able to improve the quality of a product in a number of scenarios, however it must be done with thought and concern for the type of team and desired outcome.

Conclusion

Iterative Design Development focuses small, talented teams on finding the correct design to realize a unique and innovative product by building fast and failing fast.

It offers a relatively large freedom and flexibility early on in a production cycle, allowing for a quick and reactive approach to design. It also encourages the collaboration of all disciplines from the start, meaning that teams can start producing straight away, as opposed to one being dependent on the other to finish a task.

It is offered as an evolution of processes refined by Mobile Pie following the construction of numerous products and is informed by our successes and failures, before and after the formation of the company, as well as academic design theory and Agile project management methodology.

I hope that this framework is of use to others in our position and that they may refine and discuss its merits and implementation, further evolving and tuning it for more efficient design development.

 
Article Start Previous Page 5 of 5
 
Comments

Jen Grier
profile image
"It is recommended that documentation is kept to a minimum and instead the prototype is built very rapidly by verbal communication between the team, with an even split of creative and technical skill sets having input. Of course, this relies on the team members being committed, reliable and democratic."

This crucial bit is quite understated. Keeping a team's "democratic" dynamics at this stage can really be the sink-or-swim for the prototype.

However, it was great to see all of the usability testing that was done and - more importantly - how you analyzed what the real problems were, even if part of your ideals had to be sacrificed for a better game experience. It's so easy to get caught on a particular mechanic and really _want_ it to work when... well, it just isn't appropriate or good for the game experience.

Tim Carter
profile image
This reminds one of Herman Miller's market tests for the Aeron chair.

All the focus groups *hated* it.

Herman Miller said screw it and released it anyway, according to their original design.

It became a best-seller.

Why?

Because "users" often dislike that which they can't understand. But the problem isn't *it*. It's merely unfamiliarity. Discomfort with something that is new.

This is why sometimes suspension of judgement in the face of a design spec can be just as important as listening to the players.

There isn't a right answer. It's a dilemma.

The group is not always right. Sometimes the individual is.

Dan Dixon
profile image
The process now looks and sounds very much like DSDM (Dynamic Systems Development Methodology). That has 3 iterative phases, Specification/Design, Implementation and Deployment. The QA phase would also probably look quite iterative, and one could timebox that as well.

Jason Avent
profile image
Tim, there is no mention of focus testing in this article. Usability testing is commonly mistaken for focus testing. Usability testing is working out how to make your product better, not to work out whether people like the idea of it or not. That's more what focus testing is for. Usability testing is actually more about watching your customers interact with your product than asking what they think of it.

I'm sitting on an Aeron chair right now and I like it. However when we bought them, the distributor offered a free of charge training session to every user because their operation is not very self evident. To get the best out of them, you need to know how to set them up properly. Usability testing might have made the adjustments of the chair easier to use. Do you see the distinction yet?

I get what you mean though and the best quote for debunking *focus* testing is the Henry Ford one - "If I relied on my customers to tell me what they wanted they'd have asked for a faster horse!" Also, Pixar's leadership are infamous for saying "You need marketing on the bus but sat somewhere near the back". : )

Will Luton
profile image
@Jen Grier: Yes, I totally agree with you here. For this type of development to really work there needs to be an honest, democratic approach from the team. This of course isn't always easy to find. Luckily we do have it at Mobile Pie, but certainly I have worked with teams where ego has gotten in the way and ultimately every iteration becomes a battle at the cost of quality. In that instance the approach needs to be more autocratic, rigid and managerially structured, but ultimately the product will lack refinement.

@Tim Carter and Jason Avent: The focus of our tests was equally about the player's enjoyment as it was their ability to actually use the product. As I mentioned we went in to these tests without any strongly defined metrics and we don't see market appeal and playability as completely exclusive from each other. If someone mentioned they didn't like a certain theme or a style that was as important as them finding a certain move too hard.

We're a small team and don't have a marketing department to do focus groups, so these test have to be as holistic as possible. But we also didn't blindly follow the testers' comments, the approach is really to be reactive. But, certainly, I think you're right Tim to say that it's not that the players wouldn't have enjoyed the first design of BBB, but that they were unfamiliar with its mechanics. However, it was so inaccessible for players, most wouldn't have ever gotten to the point of enjoying it.


none
 
Comment:
 


Submit Comment