Monday, 23 October 2017
 
  Uziana.com arrow Features and Guides arrow Guides arrow How a Game is Born Part 2: Design
 
Main Menu
Uziana.com
News
Free Games Directory
Reviews
Reviews of Classics
Features and Guides
Interviews
Column
FAQ
Link To Us
Write for Us!
Auctions
Contact Us
Most Read
Login Form





Lost Password?
How a Game is Born Part 2: Design Print E-mail
Written by Daniel Westerstal   
Monday, 20 June 2005
Interested in how a game is designed from the ground up? Read part 2 in our article series to find out.

Designing a computer game is sort of a mixture between making a movie and developing a computer program. The first step of the process is to establish what the player has to achieve when playing the game. Is it saving a princess, defeating evil, running for president or something else? What resources and means does the player need to achieve the goal of the game? How will the means and resources be presented?

As you can see there are a number of main elements that has to be identified in the design process. Examples of main elements are the view of the game, the graphics of the game, the interface, main characters or units, environments and so on.

These days many games are in 3D and depending on the type of the game it will either be in first person or seen in an isometric perspective. Of course it’s always nice to see rule breaking here, for example developing a strategy game in first person. One example of a rule breaking game is Battlezone (the later one). It was presented in a 3D first person perspective and mixed actions and strategy in a good way.

Designing the interface of the game can also be a tedious process. How will the player interact with things in the game? How do you fit in millions of options in a small but manageable interface? I believe that one of the very best at this is Sid Meier who always manages to create good interfaces with millions of options, but the player don’t even notice that there are tons of options.

The rule of thumb when designing the interface is first to get the player to understand instantly how the menus are working and then try to minimize the number of times the user has to click to get what he wants. This is also applies when it comes to other areas of computer software development.

Even more important in the design process are what kind of resources does the player need? For example does he need gold to defeat the evil enemies? Say that you want to implement the element gold in the game you need a couple of sentences to identify the gold:

Gold is a resource that is necessary for the player to build units.
The player finds gold by sending workers to dig holes in the ground.

After that you draft an illustration on and describes what the gold looks like. It’s usually up to the artists later on in the process to make a really nice and appealing image of the gold.

All the design documentation goes into something called a storyboard. The storyboard regulates everything in the game and is meant as help for when actually developing, programming and drawing the game. A real life equalient of a storyboard might be a drawing for when you build a house.

A storyboard contains drawings, flow-charts, text and also something called pseudo code. The pseudo code is for the programmers of the game describing briefly on how different programming will work.

After the storyboard is written the game goes into development, perhaps the longest part of the whole game making process.

 
< Prev   Next >

Copyright Uziana.com and Daniel Westerstal
Protected by Swedish and International Treaties
Terms of Use & Privacy Policy