Future gaming

WE HAVE SEEN the adventure game for the home computer come a long way since those early heady days when the thought of a full 1,000 bytes of memory spelt unlimited power. No longer do we have to sit still for a castle with only four, very similar, rooms or wonder what the rooms look like; we can explore very detailed dungeons with many sectors. And programs such as the Hobbit and Valhalla bring us a degree of visual display which must seem highly sophisticated to those who sat and thought hard for three or four days in order to save 25 precious bytes in some early ZX80 program.

But no-one really believes that things will stay as they are at present. We can already see the computer hardware market poised to take giant strides with the advent of 16-bit working. This enables us to do away with the current limitation of 64K byte as the largest store which our computer can address, and machines such as the QL will call upon store area which is large enough to be really useful.

With the coming of a more grown-up machine we get two more big advantages - the ability to multi-task and a set of interfaces which will allow us to support a much wider range of peripherals.

What then is the direction in which games machines will progress? This in itself is a very wide-ranging question, and correspondingly difficult to answer. There will be a big increase in the diversity of computer games as the machines grow more sophisticated, but it is unlikely that this will lead to a big variety in computers or their peripherals - the manufacturers will want these to be standard products, after all. It is far more likely that we shall see standard hardware being shaped into specific configurations for particular applications. Thus the hardware for a role-playing game system might be configured differently from the hardware for an advanced arcade-style spaceship simulator, but still use many of the same individual hardware units.

In order to look more deeply into our crystal ball, I will consider the shape which may emerge for a hardware configuration appropriate to advanced role-playing.

In a series of articles earlier this year I suggested that a typical role-playing adventure game can be broken down into a number of distinct interactive phases or stages, with each stage being treated as a separate computer program, complete in its own right. For example:

• creating a party of heroes
• providing the impetus to adventure, in the form of background rumours, hints and clues
• creating a map across which the party can journey to reach the place where the specified adventure is to take place
• dealing with melees and combat situations
• the adventure itself at the specified location
• stock-taking and evaluation at the end of the specified adventure

All this has been dealt with in elementary form in the previous series of articles (April and May issues).

Interaction

At that time it was proposed that the adventure should be text-based, and several suggestions were made for a series of related program modules which could be used in an interactive fashion by resorting to disk-overlay techniques. In these, the characteristics of the party of heroes would be maintained in an array which would be transferred intact from one program module to the next as the action unfolded, thus enabling constant record to be kept of hitpoints, value of goods on hand, weight penalties, spells used to date and so forth. Clearly there would be other variables in the adventure which would have to carry forward from one program module to the next - some examples would be:

• the time of day or night
• record of the location of the party on the map, which must be maintained whilst the party may have stepped out of the map program into (say) the melee program or the stock-taking program
• record of the rumours known to each of the party

[Panel]

Figure 1 - simplified inter-relation of program modules (variables in italics)

The relation between each of the modules is shown in brief, although it will immediately be clear that a considerable amount of interaction will occur between some of the specific modules. For instance, the melee module is one which is certainly long and complicated enough to be a module in its own right, but nevertheless it will be referred to quite frequently in traversing the map module, for instance.

This means that we cannot afford long waiting-times whilst the system down-loads one module, loads another one and boots it up. It is quite inevitable, then, that our thoughts turn to disk-overlay as the only means of storing the overall set of program modules and accessing them during play. Here again, there are at least two alternatives, namely floppy disk and Winchester. Obviously floppies are the cheaper answer, but are still a good deal slower than a hard disk, and in addition cannot cope with more than about 800-1,OOOK bytes at a time.

However, we must be practical, and recognise that floppy disks for PCs will be available long before market demand is strong enough to create a supply of hard disks for PCs, and that floppy disks will remain significantly cheaper than hard disks as long as we are talking of storage requirements significantly below 10 megabyte, as is the case here. In any event, we can probahly live quite well with the modest time, typically 5-10 seconds, which it should take a floppy system to swap one program module out of RAM, store the variables, load and boot up another program module. So it is likely that our first interactive gaming system will use floppy disks as its overlay mechanism.

Displays

It is worth sparing a thought at this stage for the form which our screen display will take. So far, we have talked of the set of program modules as being only text-based - this does not mean that it will always remain so, and my opinion is that it will not. We can already look at the games in professional high-street arcades and see the shape of things to come, in the way that increasing use is being made of the video disk to provide real TV moving pictures which can be accessed fast enough to back up the action of a real-time interactive game.

The video disk machine has not so far caught on in the domestic market, or indeed in business. This is partly because video disk machines tend to be expensive compared with video tape recorders, and there has been no attempt successfully made at producing a standard between manufacturers. Also the disk machine is apparently less versatile, since it can only be used for playback; and many people who buy a video tape recorder intend to do some home recording as well as playing back hired or bought tapes.

The manufacturers of domestic hifi and video goods are really still waiting to see what public demand is likely to be, and apart from one or two half-hearted promotions there has not been a solid push to reduce the cost of video disk machines by tooling up for quantity production and saturating the market.

Of course, the one great drawback of the tape recorder is that it has very slow access time when compared with a disk system. When you are simply playing back a recording of music or moving pictures in real time, this does not matter in the slightest, but the video disk does come into its own when we start to consider it as part of a computer system. The video disk can hold hundreds, even thousands, of film-snippets a few seconds in length - alternatively it can hold a much greater number of still photographs. And these pictures can be indexed and retrieved with great precision and at great speed, exactly as is the case with computer programs stored on a Winchester or a floppy disk.

Games applications will immediately be quite obvious - for instance, the holding on a video disk of a series of pictures which can be indexed and called up from mapping-type games routines by reference to the current map coordinates and those of the surrounding map cells. Such pictures could, for instance, be overlaid with graphics constructs generated by the games computer to simulate the movement of player-characters around the territory currently being explored.

Pie in the sky? Well, maybe it's not here right now, but some of the manufacturers of true arcade game-machines have already started to use real video pictures as part of the screen display, as I mentioncd above. What's more, we are now just starting to see the advent of video disks for home computers. For example, Adam Computers recently announced that it is aiming to provide a video-disk add-on facility to its Coleco machine; and a 12 inch one-gigabyte optical disk store is nearing completion by Xerox-Thompson CSF.

At present such inventions are not for the amateur computer user - apart from anything else, they are limited by high price and unavailability of application software - but it can only be a matter of time before increasing market demand forces the pace and produces sensibly-priced hardware packages with reasonably friendly user software. At the same time, work in industry towards the so-called electronic office is recognising the value of the video disk as a storage medium for certain incorruptible (read-only), longterm (power-off) or specialist (eg photographic) data; and it may be that office-system development will also provide a spur to the development of low-cost video disk media. Figure 2 shows details of typical video disk capacity.

[Panel]

Figure 2 - details of typical video disk capacity

MODE	MOVING PICTURE	STILL-FRAME
Basic capacity of 1 side of a 12" disk	90,000 frames (=36 minutes play)	54,000 frames
Selection method of any specific frame	By unique 5 unique 5-digit frame number	By unique 5 unique 5-digit frame number
Search time for whole disk	maximum 24 secs, average 12 secs	maximum 24 secs, average 12 secs
Search time within a "sector" of 100-200 picture frames	-	well within 1 second

In a typical adventure, we might have 4 or 5 maps or even more, for instance:-
a) The main terroin map, soy 30x30 squares each 5 miles x 5 miles
b) An expanded map of say 2 of the 5-mile squares which happen to have large towns or cities within them, and also an expanded map of fhe square in which is the aim of our quest, say a region of gloomy mountains and forests
c) A detailed map of the castle, cave network or suchlike which is the heart of the quest (we may need 2 or more of such maps)

Of course, (c) is a sub-set of (b), which in turn is a sub-set of (a).

The map in (a) has 900 separate sectors, each requiring one video picture. However, in practice each picture should really be 9 pictures, since we have to cater for typically 3 different states of the weathher and 3 conditions of daylight-darkness. This leads to a minimum of 8,100 picture frames for the map in (a) - and if we had chosen 4 weather conditions we should need 10,800 picture frames! The same is true of the maps in (b), although we can cheat a bit on the maps in (c) and dispense with weather and light-dark variations. Hence a total of 54,000 picture frames will soon be used up.

Speech

Speech modules also present tantalising possibilities for sophisticated gaming. There are two basic ways of making the computer speak to you. One is to give it a vocabulary and then instruct it which of the list of words to use in a specific case. The other is to use a proprietary add-on box which builds up any desired word or words from a set of basic sounds, known as allophones. For instance the word "action" would be written and built up as LET a$ = "ac(cc)-(sh)un" or some similar instruction.

The second system looks more unwieldy, because it involves a separate add-on unit with interlink cables, etc, and because it looks more difficult to write down the instructions in your program which will make the box speak. However, this is not really the case. It does not in general take up many more bytes in your program to instruct the allophone box to speak than it does to issue the spoken text as a PRINT or DISPLAY instruction on the screen. And although allophone language is a little unfamiliar at first it is no more difficult than learning to use a helpful new command in Basic. The real advantage of the allophone system is that there is quite literally no limit to the words which you can make the box speak, unlike the other system which is restricted to the 50 or 100 words which you originally bought or put in.

The obvious disadvantage of today's speech boxes - and this applies equally to both systems - is that they sound like robots and you need to get used to the sound before you can accept it without demur. This is obviously a bit of a problem whenever you need to have the computer distinguish between two or more different characters which it may be playing, and it can be a bit offputting if the ruffian who is menacing you talks in exactly the same disembodied voice as the holy cleric at the monastery where you stopped for a meal two hours ago.

There is no sign at present that manufacturers are going to tackle this problem, much less overcome it. Getting the computer to speak to you like HAL in 2001 is in fact a big job in all senses of the word. It requires very sophisticated software and enormous processing capacity and speed as a minimum, so it looks as though this will stay beyond the limits of small and medium-sized games systems for, quite a long time to come.

However, the allophone add-on box is quite a versatile substitute to have in the meantime, providing that we realise its shortcomings and learn to program our games structures to live within them. A worthwhile step in the short term might be for computer manufacturers to develop a plug-in ROM chip for allophone speech which can be fitted inside the case of the computer so as to reduce the clutter of desk-top hardware.

Of course, since we have now dealt with the generation of proper TV screen pictures and at least a rudimentary form of spoken commentary, it is only natural to think of adding background sounds and special audio effects. For instance, if the screen picture shows a busy marketplace we ought to hear crowd noises, whilst a forest scene should be backed up by rustling sounds from the undergrowth, and so on. Furthermore, the sudden arrival during the game of a hideous foe should be accompanied by a suitable scream, groan, roar, whilst the sound of echoing footsteps should be heard when we have decided to look around the corner in the dungeon which we are currently exploring.

Sound

In both cases, what we need is a "library" of special effects noises, typically containing 5- or 10-second recordings of about 100-200 different sounds, each of which is capable of being:

• brought on-line within 1 or 2 seconds
• played once only or alternatively looped to run continuously
• added to so as to create "specials" for those who want to develop their own programs
• accessed from two different software routines which may reside in different hardware sources

At first the problem seems simpler than I have suggested above - it ought to be possible to get the background sound from the same video disk machine as is already producing the background picures. However, this is not such a simple matter; the reason being that we shall want the disk machine to store upwards of 50,000 separate background pictures. The only way to achieve this density is by accepting that the background pictures will be still-frame and not moving. As you will appreciate, we cannot get what I might term "moving-picture sound" from a machine which is being used to give single-frame displays.

All this is getting a bit technical and involved. What it boils down to is that we shall probably need a dedicated audio-disk system quite separate from the video-disk system which produces the picture. Put this simply, it is clear that the addition of background sounds and effects could cost a lot of cash in return for the benefit that we are likely to get. For this reason, it seems likely that they will be considered an unnecessary frill by any manufacturer planning commercial development of a games system of this type.

If back-up disks, speech modules, audio units and video disks represent the components of a sophisticated gaming system, how should they be configured? One always regrets asking questions like this, but it would be a real anticlimax if I didn't give an "artist's impression" to round this brief survey off. I have attempted in figure 3 to picture the sort of system which might evolve over the next 5 years or more. It has some pretty basic essentials, and a host of what I feel are very optional fringe add-ons for the wealthy.

[Panel]

Figure 3 - typical games system of the future, complete with optional fringe add-ons for the wealthy

The important thing to realise is that nothing in the system represents new technology - it is all here already in one or other usable form. All that is lacking is that some parts have not yet come down sufficiently in price; that the market has not yet emerged sufficiently to convince manufacturers that development of standard interfaces will be a profitable venture; and that, of course, a host of gaming software standards will need to emerge if this sort of activity ever takes off seriously.

Networking

There is one aspect of the future which I have not explored in this article, and that is the possibility of linked multi-terminal role-playing game systems. This doesn't mean that I don't see it coming, for I am sure that it will arrive before much longer. What isn't so clear is how such systems will obtain their software, and how they will be interfaced. The black art of networking PC systems is still in its infancy, as anyone will tell you who is currently into office automation, and little thought has yet been given to the question of large-scale use of domestic telephone lines for handling PC modem links. After all, there are only two alternatives - either you bring all the PCs which you want to link into a single house (which will probably be difficult for more than 2 or 3 players) or you have to invest in the cost of telphone links. It's not so much the technical difficulty which will hold this back as the fact that telephone lines cost a small fortune when you start tying them up for hours on end on a regular basis.

However, some of our universities have already started exploring the possibilities of this type of gaming, and of course it's custom-built for research establishments with quantities of dumb terminals linked to an enormous mainframe machine with hundreds, even thousands, of megabytes going spare. Perhaps some reviewer in ten years' time will pour scorn on my views, but I don't see networked systems except as the next stage, when most of the things I have described in this article have already happened.

And, finally, an ethical footnote: it's not at all the purpose of this article to foresee either doom or salvation in the possible coming of more grown-up and realistic games systems for the home. Some feel that tomorrow's youth will retreat into a catatonic withdrawal from the world to a game-world where they can be king or queen, whilst others see possible therapeutic value in the intelligent use of such toys. For my part, I reckon that it's all round the corner and will come soon in any case: it's up to us to make sure that we welcome it as a mind-broadening relaxant rather than coming to depend on it as a drug.