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
A Primer for the Design Process, Part 2: Think
View All     RSS
August 23, 2019
arrowPress Releases
August 23, 2019
Games Press
View All     RSS







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


 

A Primer for the Design Process, Part 2: Think


July 7, 2000 Article Start Previous Page 2 of 3 Next
 

2. Good Habits, A Critical Eye, and the Fun Factor

Merging Design Documents, Schedules, and Budgets.
Time will need to be taken during, or immediately after, the pre-production design phase to come-up with real numbers, times, and dates for the project. The usual problem with those above-mentioned words is that, for each concept mentioned, you have a different group of people crunching the numbers. They also don't tend to be in very close contact with each other. Many companies are fond of saying, "Hey, we need to fill a gap in the quarter here! You guys, do this game in 8 months!" Your response is, "Not on your life, but if we must, we'll need more money and resource to do it." Of course, they don't want to give you more money and resources to do it. That's why it helps to gather all relevant parties to this portion of the development process, bring them together, and hash out the numbers. That's why it helps to have your design broken down into needs, tasks, and features at the start.
There is no better time to examine resource and budget considerations then while you're hammering out design detail, unless of course you have nothing to do with making the schedule or planning the budget. If you're leading the design vision of the product, however, you should very well have a hand in the schedule and budgetary considerations. Get all the relevant people into the room at one time and hammer out the numbers. It's a big pain in the backside, but it's definitely worth doing in the long run. Remember, when the design doc is changed, or features are re-worked, you're going to have to take a look at the impact and figure out if this is going to push you back in the development process.

Updating the design document.
This sounds easy, but in the throes of development long hours and crushing stress from all sides can cause details to slip through the cracks. You might talk about a feature in a late-night impromptu gathering and then implement the change the next morning. You should document that change, especially if you end up doing a sequel a year or so later, so that you remember what you did in the first place.

When anybody on the team decides to round out a feature, change a feature, or add a feature this change should be noted, documented, and brought to everyone's attention. If you've created an on-line style design document not entirely unlike the one mentioned part one of this article, you'll have the mechanism in place to keep the team informed and responsible.

Keeping a Design Journal
This is as straightforward as it sounds; keep a running dialogue of what's gone right and wrong during the project. Week to week will probably do unless you're in the middle of one heck of a crunch time. This will serve a number of purposes. First, it lets you recall, months and months after the fact, lessons you may have learned or not learned early in the project before the press of 15 hour days began to blur one day into the next. Secondly, it allows you to bring up key issues of good or bad work done by people throughout the project during the post-mortem (your company has post-mortems, right?) And lastly, it will help you in publishing a post-mortem article for a relevant publication so your fellow designers out there can learn from your experience, right?

Critical Evaluation
One of the best things you can do for your game when you're looking to implement features is to critically evaluate the competition and I mean look at them. There is a saying, "It's amazing how much you can see if you just look." Don't knock on the competition simply because their title is out before yours hits the shelves, evaluate it. Every title, no matter how heinous, has some lesson to be learned tucked within its folds. The primary lesson here is to avoid making the same mistakes that killed a rival product.

This goes for the whole game, look at things like their front end to see how easy it is to get into the game, check the controller set-ups, examine screen real estate and test in-game timing issues and controller sampling. You don't want to be reinventing the wheel if you don't have to. If some other game is doing something well, borrow that idea or concept. You just have to make sure that you don't outright steal the concept. That would be a no-no. Remember: Good design not only about ideas, but it's also about the implementation of those ideas.

Of course, at some point you are going to need to turn that cruel, cold eye of unswerving criticism on your own title. Testing feedback will help here but ultimately someone's toes are going to get stepped on. When looking at your own product, put your ego in your back pocket. Many a title has crashed-and-burned because someone's ego fought against the tide of popular opinion and washed-out (or in) a feature (or features) that killed game play.

The 'Fun Factor'
Some companies want you to work on the "fun factor." Everyone's looking for that elusive concept that you read so much about in fluffy design treatments and marketing blurbs. The causal gamer and average consumer can't nail down what is really fun. They'll tell you something's fun, but they can't tell you what's happening inside the game and what they're responding to. Fun tends to be a relative concept that revolves around things like pacing, timing, and excitement as specific to that particular title. These are things you can theorize about; tell people "punching this guy is fun!" but you'll never really know until you spend time with the game and work it out. As a designer, you need the ability to critically evaluate the competitions efforts. Look at how they handle certain issues and make note of them.

The fun factor comes from being able to identify exactly what's being done, how it's being done, and you can continue to do it without the game getting boring. This is a touchy part of the implementation of the design. Lots of people are going to have arguments one-way or the other about the details. One thing that will help you with this is filtering proper information and feedback from your QA department, but I'll go into that later.


Article Start Previous Page 2 of 3 Next

Related Jobs

Wargaming Sydney
Wargaming Sydney — Sydney, New South Wales, Australia
[08.23.19]

Lead Game Designer
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[08.22.19]

Senior Content Designer
Cold Iron Studios
Cold Iron Studios — San Jose, California, United States
[08.21.19]

Senior Systems Designer
Street Smarts VR
Street Smarts VR — San Antonio, Texas, United States
[08.21.19]

Senior Producer/Game Designer





Loading Comments

loader image