The whole truth about Games Programming Part 7: The Guardian

Here it is — the last instalment of Menace, the game! This month's source contains the addition of the guardian graphics and code.

The guardian is simply made up of a few normal aliens, as described last month. It is not normally feasible to have a huge animated end guardian as it would require vast amounts of memory. The usual sacrifice is to have the main bulk of the guardian as a single bitmap, with bobs or sprites overlayed on top for the animating sections.

The classic R-Type did this in the end of Level One guardian where only the tail and a small part of the stomach were actually animated, but it was still pretty impressive. Menace is not that impressive, but it does demonstrate the usual technique.

Big Bad Boys

The pictures show the guardians from Levels One and Five respectively. These are the DPaint screens. All guardians are 256 x 192 pixels in size. They are drawn on the right-hand edge of the screen in strips of 16 pixels, just as the map was. Rather than store them as a simple bitmap image (3 planes x 192 high x 32 bytes wide = 18432 bytes) a simple compression was used in order to save memory.

Level 1 guardian.

Level 5 guardian.

Each strip of 16 pixels was compressed by noting where all the zero words occurred and only storing the actual non-zero data. This was done by looking at the words from each plane of the image in succession from the top of a strip down to the bottom. If all three planes held no data (this happens a lot, as you can see from the figures) a single bit was stored to flag this, and no data was stored in the compressed file.

If any of the planes did contain data then this was flagged by a single bit, and the three words of data were copied to the compressed file. At the end of the strip (192 lines high) we will have only copied the non-zero data to the compressed file, and will have 192 bits of data (24 bytes) to signify which line of the bitmap this particular data came from. This is a very simple but relatively quick compression method (known as a 'bitmap header', as we produce a map of bits to represent the data). It usually halves the size of the guardian data for each level.

Eye Holes

You can see in the picture above the 'hole' for the eye in the Level One guardian. The eye is simply a normal alien following a standard path. The game knows when a level has been completed when this alien is destroyed. All aliens have a unique number so this is very easy to check.

The guardian bitmap image is drawn in the front playfield so all the aliens appear behind the image as with the foreground scenery. This allows aliens to 'appear' anywhere on the screen, but as long as they are behind the guardian it will not be noticeable. This is how the small 'tadpoles' on the Level One guardian are repeated. Their path data simply makes them appear under one of the guardian tentacles, then swim left till they are offscreen, then go back to the tentacle; and so on. Nice and simple, but it works.

The guardian path is repeated for about 30 seconds, which should be enough time to kill the guardian. If it has not been killed in this time then the 'death' path is initiated in which case all the aliens are substituted for homing mines that cannot be destroyed. This ensures nobody takes a leisurely attitude when dealing with the guardian!

Death by Explosion

When you finally kill the guardian another alien path is started. This one, though, is not deadly, but is simply a collection of explosions all around the guardian body to give the effect of it exploding. This is no different from any other path data and shows that a flexible routine can be used in many places in a game, saving the task of writing more code for some effects.

And that is basically all the game ingredients covered. I have not presented the code for the 'extras' that go into a game as many are quite simple and others have been the result of many months' work and cannot be published, but I'll run over some of the main ones.

Disk Routines

Hmmm, the main reason for many sleepless nights for Amiga programmers! There are three basic levels to using the disk drives on the Amiga for reading/writing your data, AmigaDOS is by far the simplest, and is frequently used for development tools.

To use the DOS routines for a game requires that the operating system is fully intact. This causes severe performance and memory loss. The performance loss can be solved by using the framework given in the first article to disable then re-enable the system when you wish to use a DOS routine.

The memory loss due to the operating system, though, cannot be solved. You will typically lose 100 KBytes if you want to use DOS. This is a lot of memory to a programmer so the DOS route is not usually taken.

The trackdisk device is a set of Amiga system routines that allow you to access the disk as individual sectors, it is quite fast and can run with the minimum of the operating system being intact. Memory loss is still a problem, though, at around 50 KBytes, and once again you have to enable the system to use the trackdisk routines. Providing you can work with this it is a usable alternative to the real hardware nitty gritty.

Getting right down to hardware register level is the lowest we can go. Come down to this level and you have complete control of the system and ALL the memory. Be warned though, MFM encoding, Precomp, SYNC words etc. are all tricky issues. In their individual ways they are quite straightforward, but the difficulty is in testing them all together.

You cannot use a monitor such as Monam2 to debug, as this would require the system to be running, which would interfere with the code you are trying to test. The ideal situation is remote debugging (connecting two Amigas via the parallel port, as Devpac Professional allows) but this is quite expensive.

The method I used when first writing the disk routines was simple trial and error and many late nights. Luckily they only have to be written once. Once they are working simple refinements are all that is required. The Abacus book 'Amiga Disk Drives Inside and Out' has recently appeared on the market, which should prove to be a big help.

This is the only method to use if you want the full memory and complete control so it is well worth spending time writing some reliable disk routines for your game.

Music and Sound Effects

The music and sound effects for Menace were written by Dave Whittaker. His name is fairly well known for Amiga game music (other titles include Shadow Of The Beast and Xenon II). The ideal situation is to get the music written by someone like Dave, who does this for a living.

At the end of the day what you get for your money is the music and sound effects, for basically any machine you require, along with the code to play them, all supplied in a single module of data.

You simply call one of his routines from within your code, and off goes the music or sound effects etc. This makes life very simple for the game programmer, the music and effects usually only taking one day to be added to the game.

The Amiga, though, is well catered for in the music department. You may decide to write the music yourself with one of the standard packages such as SoundTracker or SoundFX. These popular programs have source code available to play the music that you create. You can therefore save some money by having a friend with a little musical ability, compose a track on one of these packages, then spend a little time on getting the player working in your own code.

These packages do not, however, cater for the playing of sound effects over the top of the music. A simple sample player is all that is really required to generate some effects, so the simple solution is to allow the game to have music or sound effects going, but maybe not both at once.

The main minus point about using a standard Amiga package is simply one of portability of the music, If, for instance, an ST version of the game is required then ideally the music writer and player you use on the Amiga should also be available on the ST. I believe that there is now a SoundTracker file player for the ST so if you use that program this would solve your portability problem.

Memory wise, you should leave aside about 100 Kbytes for a decent soundtrack. It is possible to have a soundtrack that does not use samples, but generated instruments as used on the C64. Soundtracks that use this technique will quite easily fit within 10 Kbytes, but you obviously lose a little of the effect of good Amiga samples.

One point to bear in mind on the music front is one of playback speed. Most of the player routines are patched into the vertical blank routine, so on PAL machines the music is updated 50 times per second. This seems fine, but remember that the NTSC standard, as used in the States, updates 60 times per second. This means that the music will be 20% faster over there than over here. This can turn a good soundtrack into one that sounds a bit naff because it is too fast.

Your game should either use a timer to generate a 1/50th of a second interrupt, which will be the same on any machine, or detect which type of machine you are on (PAL/NTSC) and slow down the music accordingly. This is simply done by not calling the music routine every 6th vertical blank on an NTSC machine. Remember also that you have 20% LESS processor time per frame on an NTSC machine. This can cause havoc if you write a game, designed to run in a single frame, that has not taken into account this loss of processor time.

All new Amigas with the fatter AGNUS chips now have the capability to be switched into 60 Hz mode. Monitors (and some TVs) can handle this, and ideally you should try to get access to one to test out your code on in 60 Hz mode. All Amiga games should also now start to accommodate this 60 Hz switch capability on a key press in a game.

Running your game in 60 Hz mode will result in the game playing 20% faster, and also filling the entire PAL display (even though the graphics may look a little stretched). ST owners have always had this capability, and it is a nice feature to include into a game.

Intro Sequence

A nice rolling intro for the game can do wonders for its appeal. They add nothing to the game, but add a little variety to the package. A good intro to a game should be a piece of code that is technically and visually excellent, the sort of thing that is not really possible to implement in a game itself, but shows of some of the capabilities of the Amiga.

This sort of effect should also be added to the game should anyone eventually complete the game. It is a real letdown when you spend months playing a game, finally manage to finish it, and up pops a bit of text saying 'Well Done'! Programmers who do this should be shot (there is an animated sequence at the end of Menace and one after Blood Money, by the way, so I'm safe from the assassins for now!)

And finally...

Text routine

Try to design an impressive character set, maybe incorporating some copper tricks to jazz the text screens up a bit. If you are working on a monitor then keep in mind the TV users and don't have a small character set, they will probably not be able read it.

High score table

Most arcade style games need a high score table. They are usually pretty boring to write (this is usually the first routine to get delegated to new programmers!) A 'save to disk' option is usually a must.

Demo mode

Any game that has a self-play demo mode is much more likely to be loaded and displayed in a shop. It will also help when the game is shown at the multitude of computer shows throughout the year.

Serial/Parallel link

Many games are now incorporating these types of link for head-to-head action. Games like Populous and Stunt Car Racer really come into their own in this mode — they have cost us many a day's work! It really depends on if the game is suited to a two-player head-to-head, of course, shoot-em-ups generally are not, but there is always a first time for everything...

Protection

Most programmers tend to implement various protection schemes of their own, although the disk duplicators can often offer their own techniques also. In my belief it is not possible to protect a disk 100% from being copied. The main aim is to DELAY as much as possible the inevitable 'cracked' copy appearing.

Most games tend to sell their strongest in the first month. Over a period of two years, 80% of the sales may well have happened in this first month. If you can therefore stall the pirates for as long as possible, people have a much better chance of seeing the game in their local shop, than suddenly appearing in the post from friends.

Adding protection can be a long and tiresome process. It is sad that it has to be done, but that is a topic we are all familiar with...

On that sombre note I'll wrap up this series. I hope many of you have a go at some programming. It is possible to write games in your spare time as a hobby. You never know, it could lead to a full-time job. And as the old saying goes, "A man whose hobby is his job, is a very happy man" (circa. 1990 Dave Jones, DMA Design).

Downloads

Menace source code and coverdisk data files

Series Links

Part 1 / Part 2 / Part 3 / Part 4 / Part 5 / Part 6 / Part 7