Sounds Interesting

Introduction

Sound effects add a whole extra dimension to a game. That was easy to hear in my C64 game development days. I usually waited until most of the game was written, play-testing in silence, before commissioning the sound effects. This also kept the peace in the development "office" (Steve's dining room). We didn't have a sound system in the room either, we worked in silence most of the time. Some days we didn't speak at all, we were so deep in concentration.

 

I say "commissioning the sound effects" because I didn't really take to sound at all, it was too mysterious. In return for my play-testing time of Steve Turner's Spectrum games, he wrote the sound routine, the music, the music player, and designed the sound effects of most of my early games.  

 

Dragon 32

My first games were on the Dragon 32, and whilst I can't remember anything about the sound routine itself, I do remember that Steve Turner designed it, and may have written it too, based on his ZX Spectrum routine experience. Our early Seiddab Trilogy games mostly required only firing and explosion sound effects, fortunately. In order to keep the music and effects running smoothly; you need to have an interrupt routine running every 50th of a second and on the Dragon 32 and Spectrum we would loop for a while sending values to be output to the speaker. You might regard these as very crude sound samples, only 8-bits, but they were algorithmically generated rather than recorded. To get the best quality you would need to use all of the CPU time to continue to play sound data. Clearly for a video game this was not possible: the graphics were taking most of the time. The sounds were therefore compromised by only playing data for a short time every 50th of a second.   

 

Both the Spectrum and Dragon had rather rudimentary sound capabilities then, intended more for simple beeps and boops, but the C64 had SID.

 

SID

The Commodore 64 SID chip was a new type of sound generator for us. It had 3 sound channels so could produce 3 separate sounds at the same time. It also produced its own waveforms: square pulse waves, sawtooth waves, triangle waves and noise. In its simplest form then, the SID chip can also produce the beeps and boops of yore with ease. To get better sound effects you have to algorithmically sculpt the frequencies produced over time, and also sculpt the volume over time, called the Attack, Decay, Sustain and Release, or ADSR.

 

Steve chipped in (pun intended) again and wrote the sound routine, Each sound effect would consist of a few bytes of control data. You would initially set the waveform type, the Attack, Decay and Sustain figures and the frequency, and then every 50th of a second the sound routine would run and modify the frequency and trigger the Release phase at the required time. We had an inner and outer loop counter, and frequency changes to apply in each loop. 

 

We found that you need to think about how you use your 3 channels for sound. Do you want sounds to interrupt each other? Do you want some to take priority over others? Typically a sound effect was assigned a channel to run on, and a priority, so that less significant sounds would not be sounded if the channel was playing something important. You can use the sound effect number as the priority if you're happy to shuffle the sounds around to get it right.

 

For explosion type sound effects you would select the noise waveform, and quickly ramp up the volume to full and then let it slowly die away. For firing sounds we worked out that the player firing sound will be used a lot, so it mustn't be too irritating. We tended to go for softer triangle wave effects rather than noises. I also had another agenda for SID: it could produce random numbers, generated on the 3rd channel only, we could set it to noise mode and read the produced value. I therefore made sure that only noise waveform effects would be sent to the 3rd channel, and when it wasn't busy it silently played high frequency white noise to itself. This caused a good fast turnover of un-reproduceable random numbers. 

 

I did try to come up with some sounds for Gribbly's Day Out, but I found it difficult to visualise how sounds are produced from the few numbers we were feeding in. Even the simple bubbling sound, I knew what I wanted, but couldn't see how to get it. We didn't have a sound editor, we just used a C64 running the sound routine and used to set up the numbers for sound effect #1 with my ABMON debugger, and trigger the sound with the joystick button. When we got it how we wanted it, just write the sound parameters down and key them into the source code table for the next assemble.

 

In despair then, I asked Steve to create the sound effects for me, which he did in very little time, probably a couple of hours. Typically we might have 20 to 30 sound effects in a game. The game was almost complete, which allowed me to determine where I wanted the sound effects, and what sort of sound effects I wanted. The sound effects should all fit together, so creating them all at the same time is a good idea. You can then set up the effects in the game and see what it's like. You can quickly tell if any are irritating or there's too much going on, or not enough. Less so if you are playing music as well, of course. Suddenly the game comes to life.

When coding the sound routine, you will need to know what effect, if any, is currently running on each channel, and this will need to be cleared when the effect finishes. Likely your pause mode then will need to switch all the sounds off immediately. It shouldn't be necessary to restart them when you continue, more sound requests will be coming in pretty soon. If you have a master volume control in either the hardware chip or coded into your software then you could nicely fade the effects out.
 

People have told me that the snapping sound that SEON made was particularly menacing.  

 

Paradroid

Every game got a clean slate for the sound and the music. Generally our sound routine itself was the same, since the hardware was the same, doing the same job. Occasionally something clever turned up in other games, such as Impossible Mission, which had speech. We suspected that quite a lot of memory and processor power went into that, so we didn't feel a need to investigate.

 

As Paradroid developed, I was realising that my use of the available RAM space was going to be tight. I had implemented a dictionary system for the text, which might or might not have been as economical as just writing all the text out long-hand, but programmers don't necessarily think like that, we want to write some new code. There were a lot of sprites for the robot pictures. I had tried to save space with a routine to generate reflected multi-colour sprites on the fly. The deck maps were also done in a new way and were quite expensive.

 

Now us programmers don't like to take working code out, so when it came to writing some music for the title page I only had 150 bytes of RAM left. That's just not enough for a decent tune. The game was almost complete and I wasn't going to remove anything.

 

At this point so people might say: "Get in there and optimise something then." We tended to optimise the code for performance already, not so much for space considerations, and since we didn't want to detrimentally affect the performance, we would not want to alter existing working code. I've never followed the philosophy of just getting something working and optimise it later if necessary. Everything has to be top notch all the time. If that makes me an idealist and a perfectionist, then I'll take that. 

 

Steve had done most of the sound effects with his usual efficiency. I felt that I also wanted some lower key sounds for the backgrounds. If you watch Star Trek and listen when they're on the bridge or in engineering there are sounds going on all the time. It helps to make the place sound functional. You don't need a full factory production line belting out all the time, just something gentle in the background. Similarly when the Daleks are on Doctor Who there's always a pulsing heartbeat going on.

 

I decided to have another go at creating some sounds. Once more I struggled, and in any case creating a lot of little sounds would require quite a bit of memory, which I didn't have, and likely a control routine to manage the sounds. I started messing about with some of the loop and frequency change counters, putting much bigger values in than I should. This started causing the frequencies to wrap around, and the effects lasted much longer. It was producing some lovely gurgling sounds. I started taking notes of the values and then almost randomly altering them and getting more nice sounds, some like chattering robots. I then had my sound effects for the title screen instead of music.

 

The background deck sounds in the game are low priority. Once a firefight starts, the louder firing and explosion effects take over, and you don't notice that the background effect has stopped. As soon as the firing stops, the background effect comes back in.

 

When the deck is cleared, the lights go out and the deck sound effect stops, giving an eerie cold and empty feel to the place.

 

The 16-bit Sound

When the Atari ST and Amiga came along, they were playing sound samples. Suddenly then, you need a way of creating these samples, and capturing them. They simplified the sound routine somewhat because you no longer had to control the ADSR, nor the frequency alterations, that's all included in the sample. You just tell the chip to play the sample at a given frequency, which you probably would fix for all the effects anyway, and shut it off when you run out of sample. I believe we had the option to control the ADSR still,, in case you wanted to loop a shorter sample, and frequency alterations for a bit of tremolo on the music instruments.

 

The Atari had 3 sound channels, and the Amiga 4, split into 2 left and 2 right. This made for slightly different sound channel assignments in each version of Rainbow Islands, Paradroid 90, and Fire and Ice. I believe I did include the option to trigger sounds to left or right channel based on the screen position of the object making the sound on the Amiga. It would have been nice to have a left-right pan register for each channel.

Jason Page would likely have written our sound and music routine, which runs every 50th of a second on an interrupt. You don't want that running inside the main game loop in case there's an overrun, and the music might repeatedly stall. The sound routine was playing back samples rather than relying on fixed waveforms, so the effects were more created up-front on a separate sound editor, though I suspect that we also still had all of the C64 loop and frequency change controls, and maybe the ADSR volume envelope controls, so that we could get multiple sound effects from the same sample, which could have been just a short simple waveform.

 

Once again, the priority of the sounds effects becomes important. You don't want to interrupt loud or long sound effects with shorter ones as it becomes obvious and shows up the limitation of channels. Everything should run cleanly and smoothly. It's better for a low priority sound to not come out at all while, for example, the Rainbow Islands "the water's coming - Hurry Up" siren sounds. Therefore, when you make a call to request a sound effect, the routine you call should check what is running on the selected channel already, if anything, and gracefully decline if something more important is happening.

 

While on the subject of Rainbow Islands: if you've played it, the game displays "GOAL IN!" when Bub completes a level. This has 7 letters in it, and they are coloured the same as the gems, in rainbow colours, red to violet across the screen. It's a little hint to how the different coloured gems are produced. When we got to do the U.S. release of the game, the publisher didn't think much of the slightly quirky Japanese phrase and insisted it be changed to "GOAL !". I did try to point out that 2 colours would be missing then and the timing would all be messed up, but they insisted some more, so we dropped the "IN". I am disappointed that I didn't think to at least change the "IN" to "!!" so there were still 7 characters.

 

Here's the code we had to put in:

 

  SetGoalIn               ; Select a set of delays for pattern

If NTSC=No                ; If NOT the American version...
  Activate InitN          ;   Give me an N
  Activate InitI          ;   Give me an I
EndC                      ; End If

  Activate InitL          ; Give me an L
  Activate InitA          ; Give me an A
  Activate InitO          ; Give me an O
  Activate InitG          ; Give me a  G
  Delay                   ; Finished for this game cycle
  Repeat   6*Second       ; Wait for 6 seconds

  Activate InitX          ; Give me an X for eXclamation mark
  Delay

 

The I and the N only get created if it's not the NTSC American version. The letters are generated in reverse because they are each inserted into the object linked list directly after this object, and that restores the sequence to the correct order. There are other places I had to alter to move the 5 remaining letters together too. Was it really that important to de-quirk the Japanese game?

 

It still irritates me that publishers think they know best. I'll need to do another blog page sometime about all the things they asked us to remove and whether we did, or just hid them.

 

I seem to have digressed from the sounds. Let's move on.

 

Fire and Ice

We wanted to have the Coyote playing the piano on the title screen, and Jason had built some barking into the music. Philip Williams, who was lead graphics artist, asked whether he could make the Coyote bark in time to the barks in the music. The short answer was no, but the longer answer was, have it done in a few minutes. We wrote a little control routine to trigger some barking frames of animation when a certain "instrument", the bark, appeared on one of the sound channels. We also had to monitor the music player to check the tune was still playing, so that we could stop the piano from rocking when the tune finished.

 

I was playing Super Mario Bros.U and liked the way the little meanies did a shuffle in time to the music. I thought, why didn't we ever do that? Then I remembered that we had, just not in the game itself, only on the titles page. 

 

The CD32 version of Fire and Ice (anyone got that and a CD32?) had CD tunes that Jason went away and recorded. There's at least one tune for each world. In this case, our Coyote has no idea when the barking sounds might be playing on the CD. I don't think we got into figuring out the timings and coding them in. 

 

Virocop

After I finished Uridium 2 on the Amiga, and had my soul crushed by the cancellation of the in-progress CD32 version, I stopped working on my own games. I assisted with some of the Virocop features, mainly the big-boss sections. Incidentally, Virocop had a last-minute crash bug to find, right in the last big-boss screen. We spent ages hunting that one down, and it turned out to be a sound request call for a sound effect that didn't exist, so it threw random data at the sound routine, which was enough to kill it in an interrupt call.
 

 

PC Sounds

Graftgold moved on to PC and PlayStation development. We had successfully converted Rainbow Islands to the PC, PlayStation and Sega Saturn, written in C.  We then set about writing a tank game. Everyone in the company was working on the same game for a while, in an attempt to produce something bigger than before. We were using the MotoX 3D landscape engine that Steve had developed, and had also migrated from DOS to Windows, and seen the introduction of the first hardware accelerated graphics cards. It was truly a time of change.

 

I worked on a number of system routines during that time, including the sound routine. A 3D game called for a more sophisticated sound routine, I felt. The PC by this time seemed to be able to cope with mixing as many sound effect samples together as we cared to throw at it. We could also assign a stereo position to the sound effect (5.1 hadn't quite arrived!) so we supplied the horizontal screen relative position of the effect and the distance from the camera to the sounds to reduce the volume, plus I added a delay at the start of the sound based on distance: "If you hear the bullet, you're already dead!"

 

I also felt that a lot of games suffered from identical samples going off repeatedly and starting to sound very mechanical. I chose to optionally add a small amount of frequency change to bullets and explosions effects to give some variation. This had to be optional because the music player drove the sound routine, and you don't want the bass guitar to get randomly de-tuned, trust me. For aircraft I also calculated and stored the distance to the camera so that I could effect some Doppler shift on the engine sounds based on speed relative to the camera. I expect everyone's doing that kind of thing now.

By this time, Jason had moved on, and Lee Banyard was doing our sound effects and music. He also did our Empire Soccer effects and music. I have no idea how he was doing the effects, he just used to disappear into his room for a while and come out with the effects. Remember, this pre-dated the popular interweb as we know it, which might be a good place to start and end these days. 

 

For sounds effects in my next venture I shall just the get computer to say: "Alexa, what does an AK47 sound like?"