|
CRASH - The Online Edition
- Issue 29 Contents | |
|
Previous article: Alien Highway |
Next article: Realtime Software |
Seeing as the chaps at DESIGN DESIGN are the people who are actually going to have to write the game designed by the winner of the GENESIS: BIRTH OF A GAME competition, it seemed only fair and sensible to ask a Design Design teamster to come up with some guidelines. Graham Stafford drew the short straw...
Designing a game can be a very complex task, and this piece can only give a rough outline of the task involved. Don't take what I say as gospel, I'm just showing you one way of approaching the task. There are a number of things to bear in mind when tackling the problem. Don't be narrow minded in your thoughts - just because it hasn't been done doesn't mean it can't be done. Remember, across the whole spectrum of decisions you must make: a good original idea is usually much better than an old one.
Sorry, but there are two major restrictions to game design that apply when dealing with any computer: available memory size and speed (or, to put it in Des Des lingo, Space and Waft). Be realistic in your estimations of the memory required by your game. A brief ferret around the games currently available should give you some notion of the amount of memory you can allow yourself for sprite storage and map layouts. As for waft, sorry SPEED, the speed of a game is largely dependent on the amount of memory you have to wang about the place (oops! WANG: Des Desonian for 'move'), as detection of collisions and such stuff doesn't take up that much time. When I say moving memory this includes drawing sprites and/or lines, scrolling and all such activities.
Bear in mind that masking sprites uses up at least twice as much time, usually far more in the case of 3D games, and also the technique uses twice as much memory to store the pictures. Again, have a quick look at the games around at the moment to get some idea. Remember, try not to limit your horizons too much, but don't go silly. There is no way on Earth you can move a pink banana half the size of the screen about without flicker, nor could it be done at any great speed on the likes of the Spectrum. The problem is not pink bananas, it's BIG pink bananas that cause trouble.
Okay, now we know the restrictions within which we are working, I shall pontificate about the main decisions you will have to make.
By this I mean Arcade or Adventure. These are not as black and white as they used to be, but you must decide whether the game relies mainly on reflexes (arcade), or the old grey cells working overtime (adventure). A careful mix of both seems to be the most popular, especially if the adventure side of things is very subtle, tactics being the name of the game, not puzzles.
Way of the Exploding Fist is a good example of a game where tactics play an important part. At the other end of the grey scale, the Gargoyle (Hello Ted, Hi Greg !) Tir Na Nog type games are good examples of arcadish (very 'ish') games wot require much thinking about.
The game type is probably the first decision you will make, and will greatly influence the other decisions you have to get involved in during the design process.
KNIGHT LORE - lots of masked sprites here, folks! |
Big bit of jargon meaning 'Wots it going to look like?'. A very important part of a game these days, some would say unfortunately big, so time spent here is worthwhile. You must decide whether to Sprite or not to Sprite, to Mask or not to Mask and finally to 3D or not to 3D. Of course there's more to it than that, and things will be swayed by the rest of your game definition. Quite often it is the graphic technique used which detennines the rest of the game. I mean, can you imagine trying to play Knight Lore without the 'Filmation' (really trendy name that!)
The graphic technique used can also vastly improve what would otherwise be a dull game. For example, take Highway Encounter, a favourite of mine for quite a while, and imagine it done without the 3D mesking graphics. Seen from above the game would lose much of its appeal. To help you decide I shall outline the pros and cons of each system used so far:
FOR: Done Brattelesque they are very fast indeed.
AGAINST: Some say the representation of the objects is a bit vague. (I can't because Simon would do something violent to me.)
FOR: Fast and can be reasonably pretty.
AGAINST: Difficult to gain perspective (may not apply), overlapping objects are usually messy.
FOR: By far the most realistic way of representing a solid object.
AGAINST: Usually slow compared to other fonns of graphics.
TAPPER - frantic action involving Planar Sprites |
Here are a few examples of games that incorporate the above type of graphics:
The Tir Na Nog series is an interesting example of combining a couple of graphic techniques. Remember, there are various ways to approach each of the above techniques and they are only given as guidelines, not rules.
Do you want text windows, possibly scrolling, icons (good one that, well in with reviewing types), pretty pictures and/or backdrops? In this category the memory, not the speed is the limiting factor. A decent sketch of the screen layout(s) is almost essential for the purposes of judging the competition and should form the basis of your entry.
The real killer! The plot can really make or break a game, as it is the bit that ties all the things your game does together. Included in the plot is the overall aim of the game, and all those strange and intricate puzzles (if you want them).
Things such as NOISES (never our strong point that, Simon doesn't like them,
and I object to spending more than an evening on them!) and the front-end are
best left till last as they are time consuming and far less important than
screen layouts and so on. So there you have it. Noddy's Guide to Game Design.
All that remains now is to wish you luck and ask you to remember that the Z80
has only got 40 legs.
best wishes, Graham
Hello ? Finished Graham? Yes? O.K. all want to say is good
luck, and ask why I always end up typing Graham's letters to CRASH into my
Word-Pro!
Best wishes you lot, Psi