Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
February 17, 2020
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Iterating Quality

by Jon Brown on 12/20/10 09:01:00 pm   Expert Blogs   Featured Blogs

4 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


I have a friend who’s a concept artist, and he has observed a trap that other concept artists frequently fall into when working to a deadline, which is always, of course. The trap is that they focus on making one part of the image perfect, working it up to the level of quality they want, rather than doing multiple passes across the whole piece. Left unchecked this process results in some really great detail amongst an unfinished whole, which is great if you’re only interested in the gears in the robot’s leg joint, but not so good if you want to see the bigger picture.

Game designers also fall into this trap but their problem is more complicated. Games are a web of interactions, change one and a bad game can become good, and vice versa. If you take the approach of trying to elevate the whole by tweaking a variety of things for the build then you can end up turning a game that’s going in the right direction into a game that looks like it’s going down the toilet. And you can be sure it’s the toilet destined version you have to show to the client. Sometimes it’s obvious which of your many changes created the problem; sometimes it’s as clear as mud.

The problem can be alleviated if you only have to focus on one aspect of a game, or if the game is small enough to only have one aspect. Recently I was working on a version of tri peak solitaire (Christmas Tripeaks), and my only focus was on the card layouts. The ship date for the game was “as soon as possible”, which pretty much meant when the code was finished. This meant I had no specific timeline for creating the layouts, they just had to be ready to ship whenever the code was ready.

Creating and iterating card layouts is not as simple as you might assume; small changes can turn an easy layout into one that’s virtually impossible, which isn’t great for the casual market. All the layouts in Christmas Tripeaks were meant to look like festive items, so small changes were utterly necessary to refine the “look” of them, because there’s nothing more humiliating than your play-testers asking what the hell something is meant to be.

Clearly, it was important that I didn’t fall into the trap of noodling away on one or two card layouts when there was 30 to get right, but it was a simple task to do this, because there wasn’t anything else I could change anyway. I could change something in every layout with each build and not worry too much about wrecking the game. I could basically elevate the whole with each pass, and I needed to, because the layouts always needed to be ready to ship and I could always find something to improve.

But when you’re the lead designer on a large project, and there’s a whole bunch of things you can change in your quest for perfection, then changing as few things in each build as possible is the best approach. But this approach requires time.

Sadly, time is often a luxury that designers don’t have, many games are made in timelines that make the higher echelons of quality incredibly hard to reach, simply because it’s hard to work through enough iterations of the game to actually refine and balance the whole experience. But do not believe this to be solely the fault of those dictating the production schedule, this is also a technology problem.

If you run a studio and do not give your designers the ability to make changes and see those changes in a build as rapidly as possible then you are failing yourself and you are failing them. You’re failing yourself because you’re not getting as much value from their skills as you could and you’re failing them because you probably throw them to the wolves every time the build is reviewed. This lupine feeding might be fair enough, design is a discipline that finds its way via its mistakes, but if the problem is that you haven’t let them make enough mistakes to get to where they need to be then it’s your fault, as a studio, not theirs. If you are a designer and you’re not getting the tools you require then it might be time to consider finding yourself somewhere to work that actually cares about leveraging your mad skills to the fullest.

I once had the privilege of talking to Noah Falstein, and he told me about a conversation he had with Will Wright, which went something like this:

NF: Hey Will, how did you make the interface on The Sims so good?
WW: We tried 13 versions of it.

That is game design in a nutshell, most things take time and iteration to get right. Now, you’re probably thinking “but the Sims took forever to make, I don’t have that long!” Well, a few years ago I was working on a game that was made in just 6 months, and we still found time to do at least 6 versions of the control scheme. Granted, the coder responsible tore his hair out, but the first casualty of game development is follicular prosperity, or maybe its your waistline. Either way, the results were worth his sacrifice. If you want to try that many iterations but can’t then that’s an impediment, and you should take every opportunity to say so.

Make. Play. Modify. If you’re not prepared to put that kind of effort into your game then you shouldn’t expect any player to either.

Related Jobs

None —


Loading Comments

loader image