Chapter 2 - Early Planning

It's a great shame that people's rush of enthusiasm for an idea rapidly dissipates when they are told that they will have to plan it out to make use of it. The unfortunate consequence of failing to do so almost always results in disaster as unexpected problems arise. Often a basically sound idea is then abandoned.

With this in mind I've drawn up the planning ideas in this chapter. As with most of this book the suggestions are not rules etched in stone but rather a starting point which you can build on and alter to suit your needs. I dislike planning ahead as much as anyone so I try to keep any paperwork, or documentation if you prefer, to the bare minimum without losing any important information. Probably the most important point to keep in mind for both game design and programming in general is to be consistent in your approach.

2.1 Finding Ideas

For a lucky few ideas come fully formed; for the rest of us, generating ideas involves quite a bit of effort. It is important to be clear at the outset whether you intend to write for your own satisfaction or whether you hope to write games for commercial distribution.

In the former case you only need to follow up comments from your friends and can get ideas for a game quite easily from them. The standard of gameplay could be lower, as much of the attraction of the game will be that it is a 'home brew'. However you will probably get little satisfaction from writing a game you know is below standard, no matter how much some of your friends might like it.

If you are determined to get your name in the charts then I'm afraid you'll have to forget the games you personally think are the best and be a bit more commercially minded. Have a good look at the ones that seem to be selling. As well as playing them yourself, if you get the chance, watch other people playing them. If you have the opportunity go to some computer exhibitions. You will get a look at some of the best games on the market, and with larger shows you can see what the competition is like on non-Acorn machines. Another point is that at these shows you can chat with a wide cross-section of the computer using public.

What you should be looking for is the things that are most disliked. These are the features you want to avoid in your games. Human nature is perverse enough to ensure that, out of a dozen game features, people will discuss the one point they find objectionable in preference to the eleven they approve of.

After looking at a number of existing games you may find that there is a gap in what's available. Obviously the more games you see the better your chance of finding such a gap. If you're lucky you could be on the track of a new idea.

It is easy to get discouraged by the slick presentations of some software houses. Keep in mind that most of these have teams of professional programmers with years of experience, but all the professional expertise in the world will not overshadow a really good idea. Once you start writing games you will develop your own tricks and, hopefully, will have other people envying your work.

2.2 Targeting

When forming the outline of your game you need to consider who it is aimed at. You need to know what degree of complexity you can reasonably expect your players to cope with. With this in mind, when writing games that have a large number of dynamic controls such as flight simulators it is advisable to provide an auto option for as many of them as possible. In this way your player can slowly take over control of the whole game as he or she gains experience. I have frequently discarded games that looked promising simply because they demanded too much too quickly and became a chore instead of fun.

You also need to take into account the of age of your potential players. In general the peak age for Alien Zappers is about 14, and for Adventurers it's nearer 18. Very young players need games that are brightly coloured with little detail, low player accuracy, and short concentration times. People in their 20's are more likely to be interested in simulations and strategy games, and beyond 30 are probably looking for long term games that can be put aside for a while. These may be sophisticated versions of all types but requiring many hours or even weeks of concentration. Detail will be extremely important. Financial simulations, for example, are usually played by middle-aged lower management people, or those who think they should be! Your player is likely to be picky about simulations that refer to long term loans, international exchange rates, interest, etc.

Having said all that, I don't think anybody can resist the occasional session of a few minutes of pure, mindless destruction! I expect there will always be a market for games that simply involve mass annihilation of hoards of beasties.

2.3 Types of Game

It is important to work realistically within your limitations, and to chose the type of game that you best understand. Although possible, you will have an enormous struggle if you try to write, say, a flight simulator but know nothing at all about 3D projection. However, you can gain a great deal of knowledge and satisfaction from developing a game idea where you only understand the basic principles. As you gain experience you can take on progressively more sophisticated ideas.

In the later chapters of this book I give descriptions and a breakdown of the main game types. The list is not exhaustive and other people may give a different list. Also most modern games contain elements of several basic types. For example, the so-called Graphic Adventures, which are part zappem, part story.

Initially games types can be subdivided as below.

• Arcade
  • Alien Zapping
    
  • Rebounds
    
  • Platforms
    
• Role Play
  • RPGs
    
  • Adventures
    
  • Combat
    
  • Simulations
    
• Strategy
  • Cards
    
  • Board/Parlour Games

The first group consists principally of fast response games, hence their attractiveness in games arcades. For these you must be able to produce really 'tight' programs. You need to be able to see the action very clearly in your mind from a programming point of view, and be able to circumvent speed bottlenecks. However, you generally won't need a knowledge of mathematics beyond middle school level, and your game will only require cartoon type realism.

The second group require more of an understanding of relationships and trigonometry rather than absolute speed. Here you will be mainly thinking from the point of view of how a change in one piece of data will affect its neighbours. At the same time most of these games have a background map structure of some form, which may also interact with other data types. Any graphics are likely to be more detailed and require greater realism.

In the last group observed speed of execution is generally relatively unimportant. Understanding algorithms and rule systems is more important. You can expect to have to develop quite complex routines for computer generated moves, most of them probably recursive in nature. Presentation is very important. The player will be gazing for long periods at essentially static displays. Tiny details can develop an irritation factor quite out of proportion to their size.

2.4 Originality

It is pointless writing a game that is a copy of an existing one, unless the one already available is very poorly executed or you intend to produce a budget version to compete with an expensive one. In the latter case you will have to be careful about copyright. What you need is a game idea that is different from anything else on the market, but not so different that it is hard to understand.

One possibility is to add a new twist to an old game. A good example of this kind of development is the breakout game. From a simple bouncing ball knocking out bricks this has expanded to multiple balls, varying wall shapes and construction, extra bonus bricks, two player options and even a circular bat movement instead of just side to side. So far, I've not seen a breakout game that is genuinely three dimensional, so there's one possible opening.

Old parlour games give other possibilities. After all, the basic idea behind most modern platform games has a great deal in common with a game that almost everybody knows - Snakes and Ladders! As well as the familiar games like Chess, others such as Backgammon, Draughts, Ludo, Reversi, and Solitaire have all been successfully transferred to computer environments.

It is also worth looking over real-life sporting events for ideas. Football, snooker and golf simulations are now well developed, but there is plenty of scope for improvement, and for new computer versions of other games, ranging from grouse shooting in Scotland to white-water canoeing in the grand canyon. I remember that an incredibly primitive fishing game on the eight bit BBC used to attract players away from far more sophisticated commercial games, probably because fishing is something that almost everyone can identify with.

Finally there are the real-life situations that you can draw on for game ideas. This, of course, is where flight simulators have their origins. A few examples for game ideas are rail transport system management, sea defence maintenance, sheep or cattle droving, fire fighting, and even deep space asteroid mining.

2.5 Addictiveness

The ideal game is one that people want to play indefinitely. The psychology of this is quite complex, but hinges around two basic concepts. The player must always get a reward. The player must feel that at each attempt he or she has achieved something better than on the previous attempt.

A reward is not necessarily a successful completion of a level or game section. It could also be a well worded failure message or display. Whatever it is, it should be relevant, it should be encouraging, it should represent progress in either direction, and if at all possible, it should not be repeated.

Varying the way each level ends goes a long way to giving the player the feeling of progress, but simple random variations will quickly be recognised as that and may actually serve to reduce player interest. One of the best indicators of progress is time. As players become familiar with a game they react faster. Therefore, on the first completion of a level store the time taken, even if it isn't part of your scoring system. On the next completion of the same level, compare the times. If you have say, a five percent improvement then give a more up-beat end message.

Try to avoid absolute time references. You want to mark improvements against a players own capabilities, not against those of some lighting fast games freak.

2.6 Desktop Games

It is worth thinking about arranging your game so that it can multi-task as an application. Games like Patience or Solitaire are particularly amenable to this treatment. Puzzle type games or text adventures are another likely group. Your player will then be able to drop in and out of the game easily whilst, say writing to a friend, or doing the household accounts. However, this idea is hardly practical with a game that uses the whole screen or 256 colours as the player may have the desktop set up for a 16 colour mode. An invaders type zapper typifies this problem, and also makes such heavy demands on processor time that it would be unlikely that effective multi-tasking would be possible. Having said that, I have seen a desktop Space Invaders written entirely in Basic that certainly matches the playability of the earlier 8 bit implementations.

No matter what type they are all your games should be made to run as applications initially. All games should also be made to return cleanly to the desktop with just an Escape key press or mouse click on a suitable icon, allowing other suspended tasks to continue where they left off. I know of at least one distributor who won't even look at a game that can't run this way.

2.7 Teamwork

Usually the best programmers are not the best artists or musicians, so it is worth considering teaming up with a graphic artist or possibly, if you want to improve the sound content of your games, a musician. On the downside, you lose a measure of control over the game, and you need to be far more organised. At the same time you share the workload, and are more likely to spot bugs before they become a real problem. You should also end up with a game that is far better than any of you could produce by yourselves. Most of the best games currently available are produced by two or three people working together.

It is particularly important to have good graphics, so much so that it is worth devoting days or even weeks to getting a single screen just right. The game playing public are very fussy about standards of artwork. Pretty scenery and cute monsters can make a rather ordinary game into a best seller. Sound, at present, is less critical, but will get more so as the public become educated as to what is possible and will therefore expect better sound effects and music from all games.

When, as a team, you have a game that you think worth marketing it is probably best for one of you to take on the role of front man. It can become very confusing for potential distributors if they have several people to deal with, all saying something very slightly different.

2.8 Some Do's

No matter how wonderful you think your title sequence, it is a sad fact that most people will get bored with it sooner or later, so you should always provide a means of getting straight to the heart of the game. Wherever possible use a system that enables either a key press or mouse click to move on. This is also relevant for instructions, as once understood, nobody wants to wade through sheet after sheet of text. However you should always supply quite detailed instructions on (say) a menu click. This is much better than relying on disk inlay cards. These have a habit of becoming lost.

If no keys are pressed it is worth making the title screen 'time out' to a short demo of the main action, then possibly on to a score table, followed by more action in another part of the game, and so on. As soon as anyone touches the mouse or keyboard the game should instantly go back to the title screen, giving an immediate invitation to play. Let your potential distributors know about this, it may help to sell the game. Dealers will be more likely to leave your game running on a spare showroom machine.

Make sure your game has a story line. We all know that in reality it's just a lot of complex calculations and fancy pixel pushing, but playing games is the way most people suspend reality. The sillier your story is the better. Look at these examples.

"Use the mouse to move the spot onto the rectangles to make them disappear."

"While out with your friends, hunting Gronks, you are appalled to see that the Zarks, led by your old adversary Thrid, are building a dam across the Wyde river. Instantly you realise that their plan is to inundate the beautiful city of Crystalfire, home of your true love. One of your friends has taken a flier back to Lonya, to try to muster reinforcements, while the other, sadly, has already succumbed to the deadly fire of a Zark pin blaster. Only the lightning responses of a seasoned fighter like yourself can frustrate the Zarks' evil plan by destroying the dam as fast as they build it. You wonder at the twist of fate that brought you here - the first Lonian to have a flier fitted with the Mk III Brendell portable Laser cannon, a weapon capable of pounding the huge granite mega-bricks into vast, billowing clouds of incandescent dust."

Now, which game would you prefer to play? A point worth mentioning is that the story line, while including the obligatory bit of mushy romance, is completely non-sexist, and non-racist too (unless you happen to know any Zarks).

If possible give your player the choice of keys, mouse, or joystick control. There are a number of joystick add-ons so try to cater for them. The makers will be happy to give you software control information. It is in their interests as much as yours for new games to be able to use their hardware.

If you make use of sound, which is almost mandatory, it is essential that players have the option of turning it off or, even better, volume control. Complex sound generation algorithms are probably not a good idea. They tend to be difficult to develop, needing a thorough understanding of the sound system at machine level. Such algorithms may be comparatively slow to execute. It is probably better to use sampled sounds. Most sampler software includes voice module making capabilities and permission to use these modules in your own programs.

There's no reason why your shouldn't use public domain routines, sound samples or pictures in your games, but do make sure they really are PD. Check with the author. Apart from anything else, there may be a better version. As a matter of courtesy give acknowledgements for these routines, and if you have presented your game to distributors make sure they know about these inclusions.

If you want to be really squeaky clean, close and kill any modules that your game has loaded and unset any system variables, File$path, Alias$ and the like. Delete any system sprites that you've defined. All of this gives memory back to the desktop task manager. However, don't kill any modules that you don't own. I was intensely annoyed by a supposedly desktop compatible game that killed the MemAlloc module, causing another application to crash because having RMEnsured its presence earlier it quite reasonably expected to to be still there.

It's doubtful whether anyone is seriously using an unexpanded A305 now, but there will be an enormous number of A310s about and quite a few unexpanded A3000s. Plan your game to work within 1M byte if at all possible. This may mean using text compression or multi-part programs and the like. If you are fortunate enough to have an ARM 3 upgrade be especially careful to ensure that your game won't slow down noticeably in an older ARM 2 machine. Also, if you have the MEMC1A upgrade, bear in mind that the older version runs about 10% slower, and these were fitted to all the older 310s and 440s.

Always build cheat routines into your games. The list below is fairly typical.

   Immortality;
   Jump to location/level;
   Disable baddies;
   Remove baddies;
   Slow motion/single step;
   Walk through walls;
   Undo last move;
   Go to game end.

Not only will this help you debug the game but you can make this information available to reviewers on pre-release copies. If you want to be really nasty, you can always disable them on final release versions!

2.9 Some Don'ts

Don't use any of the system workspace areas if you can possibly avoid it. The sizes can't be guaranteed. If you can lump all your memory requirements together into your application user space you will know if there is enough available with a single Wimpslot test in the !Run file.

Avoid auto-configuring. There is always a way round the problem. The commonest excuse for the need to re-configure is that of screen size. There are three fairly painless solutions to this. Firstly your game can check the screen size, and if it is inadequate, abort with an instruction to the player to set the screen size from the task manager. As an alternative, you can instruct him or her on how to find the MemAlloc module in the !Lander application on the Apps 2 disk, then explain how to move it over to your disk. This will only have to be done once, so is not much of an imposition. Your program can set then the screen size, font size and RMA size as required. Finally, you may be able to get permission from Acorn to put the module on your own game disk, with a suitable acknowledgement. Don't assume that you can though. If in doubt ask.

Note. These references to re-configuring, screensize and MemAlloc are only relevant to RISC OS 2. Such techniques are unnecessary and should never be used with RISC OS 3 or later.

When your game closes down don't leave the sound system locked into your module so that a VDU 7 beep sounds like space invaders gunfire. When your game exits make sure it restores the sound system to its condition when you started. Re-set the voices, and cleanly detach and close down any sound modules belonging to your game.

Avoid topical themes for game storylines unless you can get your game completed and distributed very, very fast. A topical theme will rapidly become dated and could seriously shorten the commercial life of your game.

Don't put the name of any other game title, software house, programmer or distributor anywhere in your game without their written permission. If your game is similar to one commercially available take great care that nothing in it can be taken as a direct comparison with the original. There were a lot of lawsuits in the early 80's due to rip-off copies of well known titles. In particular, be careful of computer implementations of well known board games. Many of these are copyright, and already licensed to a software house.

Don't make last minute changes to a game you are about to send off for consideration to a distributor. Be especially wary of invisible time wasters. I nearly fell foul of this with the star program of Chapter 5. I thought I ought to add a mouse buffer flush inside the main loop just to be tidy. The result was that the loop time became too great for one screen refresh, but only when the star was at the top of the screen. Therefore always check any changes very thoroughly, no matter how simple they may seem.