17 Bit Software 2: Collection B

home *** CD-ROM | disk | FTP | other *** search

/ 17 Bit Software 2: Collection B / 17Bit_Collection_B.iso / files / 2061.dms / in.adf / FRAC.doc.pp / FRAC.doc

Wrap

Text File | 1992-06-23 | 243.0 KB | 6,236 lines

INTRODUCTION ============ It is now many moons since work on FRAC began; spanning a period of about a year and a half in total - although understandably the work was often sporadic, with variable gaps which I used to formulate new ideas and also test what I had already written. Even so I have been contemplating the concept of an adventure game creator for some five years now - originally designing it to run on a ZX Spectrum in BASIC. At this point I had solved the problem of text manipulation: a text pool was reserved so that sets amount of memory were not allocated for specific tasks, rather it was allocated whenever and wherever it was needed (this allowed you to decide how you wished the memory to be managed). The system lives on in the form of a datalist - but this is the only part that resembles my original concepts, since I progressed little further than the menu system and memory allocation techniques - I was overwhelmed by the prospect of writing a language and so moved on to other, more elementary projects. But ever after my mind strayed to this very task, and I often found myself scribbling down ideas for a program I had not even begun. I have learnt much since those early flounderings - my study of Pascal had produced a new unheard of programming tool - `recursion`. With this I now saw that the fundamental problem of evaluating expressions and conditions could be overcome very efficiently indeed. The mandatory A-Level project provided the ultimate opportunity to see if my ideas for FRAC could be realised - even though there was of course the possibility that if my ability failed me the consequences could be disastrous. But a year later I am glad to say that they didn`t, and so after a number of hours which I dread to contemplate, FRAC was brought into existence. For my part it exceeds all of my expectations and solves a problem which has tormented me for some time - even though during its creation I have found several more to occupy my thoughts. As with any major work there are people who contributed to its creation and therefore need at the very least a mention. Firstly I would like to thank Robert Pike, Richard Uttley and Peter Nicholson who gave me many ideas, criticisms, and several adventures to play when I was so sick of the sight of FRAC that I found I could not bear to use it to write my own adventures on. Hopefully this will pass with time so that I can also have some fun, but until then its back to the program flowcharts....... I must also thank Pat Quaid who wrote the compiler which `saved my life` - and for extremely helpful tips on how to get it working again when it died. Although enjoyment is gained during the creation of a program, this is insignificant when compared to seeing the results of your work put to good use. Consequently I would like to see any adventures written using FRAC, as this would substantially repay any toil on my part. All that`s left to say is `happy adventuring`, and I hope you enjoy using FRAC more than I did writing it! BACKGROUND ANALYSIS =================== The aim of this project is quite complex and relies on the reader / user having some knowledge of the class of computer game often referred to as `adventure`. Since people reading it purely to assess its programming content are unlikely to have such knowledge, it is my task to provide information regarding `adventure` games even before the problem is explained or attempted. The history and development of adventure games to their present and most efficient form, is a long and arduous journey, but one which I feel is worth making if games of this genre are to be completely understood. Let us start this tale `ere the dawn of the computer age captured and changed this world, for eternity` that is, before about 1982. Fantasy games during this period were quite widespread but lacking any great commercial backing, small home-made companies ruled. Their games were made up mainly as a pastime which might perhaps earn them a small sum of money, if they were lucky. Such games were rarely well produced but the quality formed by the enthusiasm and dedication of the early designers made up for such shortcomings. But the horizon looked bright, and popularity was growing. Soon larger companies became interested in the commercial potential of such games and it was at this time that the birth of the home computer provided many households with a cheap and easily useable means of computation. But this story is already known to you, and is already well documented. Hence I will not dwell long at its wonders, suffice to say that this had a great impact on the fantasy game industry. At this point I would like to digress and describe the types of games that were played in this era. There are basically three main categories of games which are inter-related. These are, in order of popularity: Fantasy Roleplaying, Fantasy Boardgaming and Table-Top Wargaming. Out of these three the most influential to the development of computerised adventure games is roleplaying games, so only these will be examined here. Basically, roleplaying games are interactive stories where the players take the role of the leading characters. The action takes place in the players imagination, aided by the narrative of the GM (meaning Games Master or story-teller) and a set of guidelines laid out in the form of a book. The story itself is defined by what is called in gaming terms `a scenario`, and these can be bought or written by the GM. The GM is the person who controls the game and knows the entire scenario i.e. how certain characters in the game will react if the players meet them and then `controls` them accordingly. The players themselves know much less about the adventure and guessing how they should react to a certain situation is part of the fun. To give each character a unique background and skills, they each posses statistics which define how good they are at certain things e.g. Ballistic skill tells you how well you can shoot weapons - thus their personalities are built up from these building blocks. Characters start with randomly rolled statistics which are generally quite low, so as to allow room for improvement. The ultimate aim of the player is to improve their statistics as far as possible, producing a much more powerful adventurer. This is achieved through the use of experience points which can be `traded in` for better characteristics. Experience points are gained through the course of adventure games - at the end the GM will issue out experience points based on how well he thinks they have done. The only real way to see how roleplaying games are played is to either play one or examine the dialogue which takes place during one. A sample of the latter will now be presented below, with the characters taking part described initially. *********************** Name: BILL Hawksworth Previous occupation: Hunter Religious Beliefs:none Age: 24 Homeland: The city of Dirkholm Experience: 212 Weapon Skill: 43 Ballistic Skill: 64 Strength: 38 Agility: 42 Stamina: 52 Health: 84 Weapons: Crossbow,Dagger Armour: Plate Possessions: Pouch,20 gold pieces,food,water,backpack,golden ring *********************** Name: BEN Virag Previous occupation: Outrider Religious Beliefs:Thorak, the god of war Age: 22 Homeland: The plains of Utarg Experience: 226 Weapon Skill: 62 Ballistic Skill: 45 Strength: 39 Agility: 51 Stamina: 48 Health: 73 Weapons: Broadsword Armour: Leather Possessions: Pouch,12 gold pieces,food,water,backpack,rope *********************** Name: JAKE Elderstar Previous occupation: Ranger Religious Beliefs:Elra, goddess of nature Age: 27 Homeland: The northern Forests Experience: 413 Weapon Skill: 72 Ballistic Skill: 61 Strength: 63 Agility: 67 Stamina: 58 Health: 96 Weapons: Bow / arrow,Broadsword Armour: Mail Possessions: Pouch,56 gold pieces,backpack,water,magical cloak *********************** GM: After leaving the forest, a vast grassy plain stretches in front of you. The flatness is broken by a range of foothills which veer northward. Beyond, in the distance, a mountain range can be seen, but the view is partially obscured by a haze which seems to stem from the the foothills. BEN: Okay, we`ll travel towards the foothills. GM: The distance is quite large and it takes you some time to reach the base of the foothills. Your path is blocked by a fast flowing river which runs from the hills. The banking is soft and muddy. BILL: Are there any foot-prints in the mud? GM: No, only yours. BEN: Could we swim across? Is it wide? GM: Yes, the other side is some distance, and you could not swim well in your armour! BILL: Are there any trees near? GM: None in the immediate vicinity. BEN: AH, I could use my rope if we found one. BILL: How? Someone would have to tie it to the other side if you wanted to make a bridge. BEN: Oh Yeah. Okay we`ll walk downstream and look for a bridge then. GM: You walk for almost an hour without finding a bridge. You eventually come to a wide stony area where the river is slower and it is possible to wade. In the distance the haze seems to be growing, but the summer birds still sing happily. On the other side of the water, on a small rounded hill stands a building of some kind, it appears to be in a state of disrepair. BILL: OK. I`ll wade across and approach the building cautiously. BEN: Yeah, I`ll draw my sword and follow. JAKE: So will I. GM: As you get nearer you see that the building appears to be a house of some kind and you are actually approaching it`s front porch. It is a single storey structure with large timber support joints. To the right of the door is a window. All is silent. BILL: OK. I`ll jump through the window and Ben, you burst through the door. BEN: OK. GM: If you really want to(!). Ben you charge toward the door which looks quite solid. I`ll make a roll against your strength (his strength is 39% and the GM rolls 68% - which means he`s failed by 29%) you hurtle into the door but it proves too solid and you rebound crashing over the wooden porch railings. You drop your sword. Bill? BILL: No, I`ve changed my mind. I`ll draw my crossbow and shoot through the window. GM: OK. I`ll roll against your Ballistic skill (Bill`s Ballistic skill is 64% and the GM rolls 34%) - the bolt crashes through the window scattering glass everywhere. BILL: Were there any screams? GM: NO. JAKE: This is sad. I`ll open the door. GM: Inside it is almost empty. Floorboards constitute the floor (they are now scattered with glass) and the only item of furniture is a wooden table which is at the centre of the room. The walls are unadorned except for a crossbow bolt which is embedded in the one opposite to the window. This door is the only exit and the broken window is the only window. JAKE: Is there anything else of note - any objects? GM: No, as you enter the room dust flies up, so it seems no one has been here for some time. Outside the sun is setting. BILL: OK. I`ll enter the room. We should spend the night here and move on at dawn. JAKE: Yes, but no longer, else our quest prove to be in vain........ *********************** GM: You all settle down to sleep after a hasty meal. Are you going to set a watch? It is dark now, and below the river can be heard. JAKE: Yeah. I`ll go first watch, Bill second and Ben last. GM: Jake, during your watch you hear nothing and are relieved by Bill who is not so fortunate. Your companions are fast asleep when you think you hear a kind of splashing in the river - it may be nothing and it is soon gone. BILL: I`m not taking any chances. I`ll rearm my crossbow and creep to the window. GM: It is hard to be quiet and the glass underfoot makes a seemingly deafening crunch. Outside you can see the vague shadows of the hillside the countless stars illuminate the river, which glistens. You can see nothing unusual. BILL: ERR, I creep to the door, open it slowly, and peak out. GM: You have a better view now and the starlit river trails off into the distance. There is nothing unusual. Then you hear a loud metallic chink somewhere behind you as something scrapes the side of the building. BILL: I`ll wake up the others as quietly as possible, and tell them what`s happened. JAKE: At last! I`ll draw my sword. BEN: Me too. GM: Something seems to be on the roof. It creaks and there is a scraping sound. Again you hear a splashing at the river - louder this time, and again. JAKE: I`ll wedge the door closed with the table and Bill, you guard the window with your crossbow. GM: Suddenly a dark shape drops from the roof right in front of the window. BILL: I`ll fire! GM: (After Testing). You shoot your crossbow which appears to hit as the shape flitters from view. BILL: I`ll reload. GM: Something heavy crashes against the door which opens a fraction as the table is pushed back. JAKE: I`ll force myself against the door and try and keep it closed. GM: (After a strength test). You manage to keep it closed with some effort. But suddenly something jumps through the window and lands in front of Bill who is still reloading. BEN: I`ll hit it with my sword! GM: (After testing against weapon skill). You manage to wound the creature and it cries out. It has fiery red eyes and a roughly made sword. BILL: I`ll kick it away from me and shoot right at it. GM: Your bolt impales the creature which gasps and goes still. Outside all is silent. BILL: I`ll reload and look through the window. GM: All is still. JAKE: Right, I`ll open the door and run for it, across the river. BEN: Hey, wait for us! So this is basically how roleplaying games are played. If after reading this you wish to start gaming, I would personally recommend Warhammer Fantasy Roleplay created by Games Workshop - but now back to computer adventure games. Through the use of computers roleplayers (as they were called) could now produce programs to suit their needs after only a few hours of pondering over a BASIC manual - no more endless dice throwing to test if that cavalry unit could rally this turn, no more brain eating mental arithmetic half-way through a campaign, and for the roleplayer: no more tedious `rolling up` of characters (i.e. the random production of a game character by rolling dice to determine the percentage of certain characteristics). It could all be done with the press of a button and a few RND statements. But although this was a turning point for fantasy gamers, it is still a long way from what today`s adventure games came from. A Change in Attitude -------------------- Previously gamers had seen the computer as an automated `character roller-upper`, nothing more than a calculator with a few extra buttons that could save them a few minutes work. But attitudes were changing - what if this `calculator` could be made to describe where you were (as happens in roleplaying games), and could allow a player to type in what he wished to do (rather than explain it to the GM) - thus the computer GM was born - perfect in every way: he could throw dice at close to the speed of light, he didn`t spill coffee over the character sheets (a common fault among GM`s), he didn`t forget where you were and then try and make up lame excuses, but finally, his kid brother Jimi didn`t seem to end up with all the gold, magic weapons, clues, keys to secret entrances and all the luck. But there was one slight problem...... Using a computer to describe the location and then allowing the player to try and explain to the computer what he wanted to do using a limited vocabulary (very limited with the early games) there was no need for a GM, so he became redundant. Also with this simple type of system other players could not interact so they also were made redundant. All that was left was you and the computer - a solo game. This of course went against most roleplayers principles and here they parted from `computer adventures` which were held in contempt, and any who played them were not true roleplayers and treated as traitors accordingly (although most secretly played them when no-one was looking!). But this was not the first appearance of solo adventure games. In fact they had been around for some time in the form of adventure gamebooks (made popular in Britain through the work of Steve Jackson and Ian Livingstone) and fans of such gamebooks were eager to transfer their adventuring to the computer since it was far more flexible than the usual `you`ve got 3 options` method which was employed by gamebooks (should I: Verbally assault the fifty foot man- eating tree which is lumbering towards me, sit down and hope it will go away, or run like the wind?). Thus was born a new type of game into the rather speculative leisure industry. But the critics were soon disproved as early games such as The Hobbit were just as, if not more popular than their `action` type rivals. Software houses were eager to produce such games and soon everyone was writing them. But adventure games require a lot more thought and design than most other game types and many were simply cheaply produced `trash`. So the boom ended and most turned back to mainstream games which guaranteed them money. But not all was gloomy for the would-be adventurer. Out of this popularity boom grew a number of specialised `adventure writing` software houses which solely produced this type of game, and had a large following (Magnetic Scrolls and Level 9 are still producing top selling games today - almost ten years on). By the dedicated work of these specialised software producers, many quality games were now available and the adventure game became an established medium which seems set to stay. This is all very well for the history of adventure games, but what about their development? Well, the very first were nothing more than basic programs with simple subroutines which were executed if the player typed a certain command e.g. North would move the character to a new location and hence print up a new description. Variables were used to remember if a character had performed a specific feat (e.g. Door=1, if the character had opened the door) and tests on such variables were made to see if certain actions were possible (e.g. if Door=1 then they may walk through the open doorway). The next step was to develop these games in machine code so that operations could be performed far more quickly and on a greater range of data. The use of machine code allowed designers to include graphics which greatly improved the products presentation and also added to the atmosphere. Storing graphics in memory for many location proved to be a problem, especially for smaller capacity computers such as the Spectrum and BBC, so a new way of drawing graphics was developed solely for use with these type of games. Rather than store the colour value for every pixel, which would be needed in a complex picture, the graphic could be `generated` by telling the computer where to draw lines, circles and fills. This saves vast amounts of memory, although obviously the pictures are far less detailed - but adequate for adventure games where amazing graphics or lightning speed are not necessary. The next development was extremely important. Since all adventure programs are basically very similar in structure (i.e. print up a set location description, input the players command and then act on it) a program could be written which allowed people to create adventure games without ever having to touch BASIC, or any other language for that matter. These `adventure creating utilities` were very popular among adventurers for the obvious reason that it allowed them to write their own adventures rather than having to play pre-prepared ones. Using such utilities they could write adventures for their friends, or if they were more talented, even have their works published - a few software houses specialised in this. The author simply defined each location by describing it, told the program where the exits were, placed a few objects and, hey presto, the program did the rest. As ever, there was a complication - almost everything could be automated except for the raw and logical processing which is necessary to define an adventure, and since this is formed from the human imagination, it is not subject to `computerization`. For example, say you pull a lever on a certain wall, how is the computer supposed to know what will happen? Obviously there must be some way of letting the computer know what it should do if such an event should occur. There have been many solutions to address this problem but by far the most elegant is the ability of allowing the user to enter the actions that should be performed, if a certain condition is met. This is achieved through the use of a very powerful, but simplified command set. Thus all the user need know is a few IF type statements and all other programming needs will be met. These `pseudo languages` vary in complexity from the very simple `Condition Action` type system (if condition x is met then perform action y - e.g. if gold=1000 then print `you have won`), to the more sophisticated which allow complex parser handling. Enter, FRAC....... EVALUATION AND DOCUMENTATION OF THE PROBLEM AREA ================================================ Now that we have studied the origins and history of adventure games, we must now look at the computer implementations in greater detail, since this will elucidate the problems with existing software and hence provide a basis for my own work in this field. Initially this piece will describe the format of modern computer adventures, progressing onto how they are created, and finally summarise the problems encountered when existing methods are used. THE FORMAT OF MODERN COMPUTER ADVENTURES ---------------------------------------- Unlike most other branches of game, computer adventures are all very similar in format and could be summarised quite easily. This is perhaps why some people find them `boring` since nothing new appears to be happening - of course they are wrong, and many new ideas are conveyed in this medium. (But since I have no wish to transform this essay into a justification of such ideals, I will not argue the point, but continue). Text adventure games (as you can probably deduce from the title) are primarily concerned with text manipulation and are the closest relation to the original roleplaying games. Here, the player reads a brief description of his location and its surroundings (thus the computer plays the part of the games master), while the person types in what he wishes to do at the keyboard. (Obviously there must be guidelines to govern what is typed since, as you are no doubt aware, computers have difficulty in functioning when there are infinite possibilities - perhaps a task for `knowledge based machines`!). The computer will then interpret what was typed through a process called parser analysis (or `word recognition`). The ability of the program to cope with this is the main criteria by which it is judged, hence a good program will allow for a vast range of inputs, so that the computer could accept almost any combination of words that the player has entered. For example, in a poorly programmed adventure game you may have to type the word `get` to pick up an object you can see, while in a well programmed game `get`,`take`,`grab`,`remove` and `pick up` might be accepted. To make the players life a lot easier, the most common commands are usually reproduced in the manual - since the aim of the game is not to try and guess which words the programmer has decided to use to perform certain actions, but to perform these actions in a specific order necessary to solve a logical problem. As you can see, language recognition is the primary element of any adventure program, and consequently many different systems have been developed over the years (in fact almost every software house has its own method). Thankfully they are all very similar (from the players point of view), so that it is not difficult to move between games written by different companies. To describe such a system would only be to write what has been written many times before, and hence a waste of resources. Therefore I have chosen to reproduce the instructions for one of the more popular systems - `Inglish`, to give you some idea of the guidelines that players must follow - and also make you familiar with text adventure games themselves. [Source: Lord of the Rings adventure game - by Melbourne House] (Note: Spelling errors and mistypes have been removed). (4) COMMUNICATING WITH THE COMPUTER The LORD OF THE RINGS program includes a very sophisticated program, INGLISH, which can understand your instructions in everyday language. More details are given later in this booklet about the power of INGLISH, but the important thing is that you can enter your commands freely and the computer will then react according to your requests. The computer program LORD OF THE RINGS has a very large vocabulary, so you should not have difficulty in expressing your ideas and commands. Your commands will usually take the form of actions, and at the back of this booklet you will find an abbreviated list of the actions you can carry out. The power of INGLISH together with the very large vocabulary of over 800 words makes this one of the easiest and friendliest adventure games ever published on micro-computers. Moreover, if the computer is not sure of something that you mean, or if you are ambiguous in any way it will ask you for clarification. The computer is also your source of information on what is happening to you, where you are and the characters around you. Some things may not be readily apparent to you, and thus can prove dangerous to the unwary player. PERFORMING ACTIONS ------------------ INGLISH is one of the most sophisticated language-recognition programs ever developed for micro-computers. It allows you to communicate with the program in a language and structure that is familiar to you. The rules for INGLISH are simple. The main thing to keep in mind is that each instruction must be in the form of `verb-then-noun`, where the noun (or pronoun) can also be implied. Each sentence must have a verb. The following examples in this instruction booklet are a guide to the way INGLISH sentences can be constructed. Note however that the specific examples shown may not be valid in this adventure. When an action does not directly concern any object, only a verb is necessary, i.e. WAIT RUN This is also the case if you simply wish to travel in some direction, i.e. SOUTH EAST If the action concerns an object or a person, this must be identified by a noun, English grammar applies, and the order of the different parts of the sentences is usually not critical. i.e. WEAR THE RING GO THROUGH THE DOOR DROP THE ROPE ONTO THE TABLE Adjectives that describe nouns must come before the noun. If it sounds right in English, it is probably valid in INGLISH, i.e. THROW THE HEAVY AXE AT THE HORRIBLE ORC LIGHT THE WOODEN PIPE WITH THE MATCH Terms used when making an instruction to the computer must be free from ambiguity. If there were two doors in a room, one red and one green, and you were to say GO THROUGH THE DOOR then the computer is placed in a quandary as to which door to put you through. In such situations, the program will put you through the first door it finds, which may not be the direction you intended. In case, it would be better to specify exactly what you mean GO THOROUGH THE GREEN DOOR PREPOSITIONS ------------ The meanings of many verbs can be altered by the use of prepositions, such as ON, OFF, ONTO and so on. Examples of INGLISH sentences using prepositions are: ATTACK WITH THE SWORD PICK UP THE RING Prepositions in INGLISH usually go before the noun, but in some cases it sounds more natural to have them after the noun, such as TURN THE LIGHT ON PICK THE GOLD UP Prepositions can also be used to specify the position of an object, or where you wish an action to be performed, such as PUT THE GOLD INTO THE BAG TAKE THE PIPE FROM THE BOX USE OF `AND` ------------ You can use the word AND in all its normal meaning in INGLISH. This means, among other things, that you can enter more than one sentence or perform more than one action at a time. TAKE THE LAMP AND THE MATCH FROM THE CUPBOARD DROP THE SHORT AND THE LONG SWORDS TAKE THE GOLD AND RUN PUNCTUATION ----------- Sentences can be separated by the use of punctuation. You can use commas and full stops as you normally would. The only limitation the program places on your commands is that your command should not be more than 128 characters long. CONVERSING WITH OTHER CHARACTERS -------------------------------- The LORD OF THE RINGS adventure also allows you to talk and converse with the characters you meet on your journey, you may wish to speak to them. The general form is SAY TO (name) `(sentence)` i.e. SAY TO GANDALF `HELLO` This is usually sufficient to draw most characters into conversation. You can ask the characters within earshot to do specific commands that are of use to you, such as: SAY TO TOM `KILL THE ORC WITH THE SWORD` SAY TO PIPPIN `TAKE THE GOLD FROM THE ORC` Of course, because all the other characters have an independence of their own, there is no guarantee that they will do what you ask them. Their decision will be based on a number of factors, including their allegiance to you, what they are currently doing, and so on. Some characters that you encounter will have messages for you that they will deliver only when you identify yourself, or ask them certain questions. In order to solve the LORD OF THE RINGS adventure, it will be necessary for you to become familiar with the SAY TO command. This is because some of the problems you face can only be solved by cooperation with the other members of the party. Each character also has his own limitations, such as strength and so on. Be warned that sometimes a certain character will be required in order to succeed with a certain action. Thus it will be necessary to become familiar with the varied talents of your party members. ABBREVIATED OF COMMANDS ----------------------- The abbreviation of your commands is quite permissible. For instance, if you wish to attack a green knight, you might say: KILL GREEN WITH SWORD The computer will see that `Green` corresponds with the green knight. Note also that the definite article `THE` can be omitted at will. In most circumstances, the computer will understand exactly what you mean. Unfortunately, if the Knight stood before a green door, then `green` no longer serves to identify the Knight only, in which case you could write: KILL KNIGHT WITH SWORD Multiple entries are easily effected simply by placing a comma between your instructions: i.e. OPEN BOX, TAKE AXE, GIVE AXE TO SAM. Each of the commands in the sentence will be dealt with by the computer in order. (5) THE SCREEN DISPLAY On your screen will appear (in normal script), the adventure description - the text which describes your surroundings, and the happenings around you. Upon entering a new location, the computer will give you a full description of the area, and the objects that are in plain sight. You will be given a list of exits that you can currently see. The second time that you enter a location, the computer will only give you a brief description of where you are. If you wish to obtain a more complete description, you can simply enter the command LOOK, and the computer will repeat the lengthier text. Below the adventure script, an arrow indicates your `instruction window`; the space in which you will type in the actions that you wish your characters to perform. This will appear on the screen in capital letters. Once you have typed in your commands and hit the `RETURN/ENTER` key, the computer will either acknowledge your action, or inform you that it does not understand you for some reason. Once the computer has acknowledged any entry, it will print any new text which results from your actions, and then indicate that it is ready to receive a new instruction. [End of reproduction]. By now you should have a good idea of what adventure gaming entails, but there is no substitute for actually playing one, or perhaps I should say, watching someone else play one - since with the following example I hope to make your knowledge complete (or at least as complete as anyone else who plays them). The following extract does not come from a real game - yet it might have, and much can be learnt as the `player` makes his way through this fantasy adventure world. It has assumed an intelligent player and a good system of recognition. `ESCAPE FROM DESERT ISLAND` COMPUTER: You are standing on a warm tropical beach. To the south the placid sea hardly ripples under the beams of the hot sun. A few yards away a large grey rock basks in the summer rays. To the west there appears to be a cave, sheltered in the rockface, while the north holds lush green vegetation. PLAYER: Examine rock. COMPUTER: It is very large and heavy and appears to have been here since the earth itself was formed. The letters `EM` are scraped into one side. PLAYER: EM. COMPUTER: Sorry, that command is not understood. PLAYER: West. COMPUTER: You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. PLAYER: Examine river. COMPUTER: The water flows slowly over a sandy bed, broken in many places by small rocks. PLAYER: Examine rocks. COMPUTER: There`s not much to tell. PLAYER: Look. COMPUTER: You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. PLAYER: Enter cave. COMPUTER: You are in a very dark cave which seems to tunnel its way deep into the mountains, but you could not progress further without a light. The entrance lies to the east. PLAYER: East. COMPUTER: You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. PLAYER: North. COMPUTER: You stand amidst large tropical trees. Exits lead east and south. You can also see a mirror. PLAYER: Take mirror. COMPUTER: You take the mirror. PLAYER: Inventory. COMPUTER: You are carrying a mirror, and a walking stick. PLAYER: South. COMPUTER: You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. PLAYER: Light the stick using the mirror. COMPUTER: The rays of the sun reflect off the mirror scorching the stick which, as a result, burns slowly away. PLAYER: West. COMPUTER: You are in the cave. You can also see a hatchet. PLAYER: Take hatchet. COMPUTER: You take the hatchet. PLAYER: Inventory. COMPUTER: You are currently carrying a mirror, a burning stick, and a hatchet. PLAYER: East. COMPUTER: The stick withers and goes out. You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. PLAYER: Drop stick. COMPUTER: You drop the stick. PLAYER: North. COMPUTER: You stand amidst large tropical trees. Exits lead east and south. PLAYER: Cut tree using hatchet. COMPUTER: You cut down a medium sized tree and shape it into a roughly made boat. PLAYER: Get boat. COMPUTER: You take the boat. PLAYER: South. COMPUTER: You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. You also see a withered stick. PLAYER: East. COMPUTER: You are standing on a warm tropical beach. To the south the placid sea hardly ripples under the beams of the hot sun. A few yards away a large grey rock basks in the summer rays. To the west there appears to be a cave, sheltered in the rockface, while the north holds lush green vegetation. PLAYER: South. COMPUTER: You sail south in your tree boat. Well done! You have escaped from the desert island. Although this adventure appears to be quite long, it is actually very simplified - containing only the most basic of game elements. The problem is straight-forward: a cave must be explored with the aid of a light (created by finding a mirror and lighting an already possessed stick) to reveal a hatchet which can be used to chop down a tree to make a boat. With this the character can escape (notice that the rock is not even used - it is common to have `red herrings` in adventure games to give the player something else to think about). If this is the first adventure problem you have encountered it may sound slightly complicated, but once you have played an adventure or two you will soon realise how simple it really is. This completes my description of the format of text adventure games, except it should be noted that most modern ones contain a selection of graphics which are displayed as you move form one location to another (these help provide better atmosphere, as well as give a better description of your surroundings). Please note that although they contain graphics they are still classed as text adventures, since graphical adventure games are in a completely different format, and hence are not examined in this project. HOW ADVENTURE GAMES ARE CREATED ------------------------------- For this project, `how computer adventures are created` directly translates into `an examination of existing methods`, since it is my wish to create a program which will allow the user to create their own adventure games. Hence, this project would not be complete without an analysis of existing methods, and an indication of their usefulness. The first method which springs openly to mind involves the author writing the adventure game from scratch in a high level language of their choice. Before the advent of the adventure game creator, this approach was actually ubiquitous, and only the adventurous of the adventurous deviated from its course. Obviously things have changed now, but even so a fair proportion of modern adventures are of this nature and cannot, therefore, be ignored. Since there is no standard way of writing adventures using this technique, it is difficult for me to furnish you with an exact definition or method. Consequently I have decided to reproduce only a small sample of a larger adventure game written in BASIC, before verbally describing what this method entails and reviewing its advantages and drawbacks. As this is part of the project report and no knowledge of programming can be assumed, I shall describe the fundamentals of the BASIC language so that the example can be followed even by a non-programmer. BASIC (Beginner`s All-purpose Symbolic Instruction Code) was developed in the 1960`s by J.G. Kemeny at Dartmouth College in the United States. It is a general purpose (as opposed to scientific or commercial) programming language and was initially designed as an easy to learn language for students who were new to programming. The BASIC language is usually interpreted rather than compiled, although compiled versions of BASIC (such as CBASIC) are available. This means that BASIC is rather slow in terms of execution speed, but is much more user-friendly, as programs can be instantly corrected and run without the need to go through the tedious recompilation stage. This user- friendliness and ease of use is primarily why it is used to write adventures - it means the game can be tested and modified very easily and in a short space of time when compared with other methods. There now follows a description of the commands used in the listing. If you are already familiar with BASIC I suggest you skip this part and move directly to the listing. The format of a BASIC command is as follows: -----:----- | | -<LINE NUMBER>-<COMMAND>-- Syntax: A line number followed by a command, and optionally a colon followed by another command - which can be repeated any number of times until the end of the line is reached. The line number decides the order of execution. The computer starts with the line with the lowest number and executes each sequentially until a command which alters the order of execution, or the end of the program is reached (see more about this below). The colon allows more commands to be placed on the same line, and although there is no definite limit to the amount of commands that can be represented in this way, it is a good idea to keep the program readable by not placing more than say four or five to a line. For the computer to process effectively, it must obviously have some way of storing the numbers it uses. In BASIC, `variables` can be assigned to either numeric values or text, depending on its type. It will help if you think of algebra when trying to understand this. Any group of letters can be strung together to form a numeric variable. E.g. The command LET X=5 ,will set `X` to the value 5. The command LET GHIKQ=10 ,will set `GHIKQ` to 10. The command LET PLAYERLOC=1 ,will set PLAYERLOC to 1. There are also what are known as text variables or `strings` (i.e. strings of characters). These are represented by a group of characters followed by the $ symbol (in this context called the string symbol). Strings store groups of characters (just like numeric variables store numbers), and are particularly useful for storing characters entered at the keyboard. In BASIC it is a simple matter to receive input from the keyboard and store it in a string - the INPUT command must be used. For example, say we wished to store what is typed at the keyboard in A$, the command INPUT A$ is used. It is essential to be able to test for a certain condition and then execute a set of instructions if this condition is met. This is done by using the IF command. As this is so close to English it really needs no further explanation, except to note that the `<>` symbol means `does not equal`, and can be used in reference to strings as well as numeric variables. Some examples follow: IF X=9 THEN LET Y=5 IF X=9 THEN LET X=X+1 IF A$="Hello" THEN LET B$="Goodbye" IF A$="Hello" AND X=9 THEN LET B$="Nine goodbyes" IF A$="Goodbye" OR Y=12 THEN LET X=Y+4 There are two commands which can be used to alter the sequence of execution. These are GOSUB and GOTO. GOTO simply sends the computer directly to the specified line number where execution will continue as normal. E.g. GOTO 20 will send the computer to a new line number as with GOTO, except, the computer remembers where to come back, and so the routine that is called must always have the command RETURN to send it back. E.g. 10 GOSUB 1000 20 END 1000 RETURN (Note: the END command simply ends the program(!)). In the above example, line 1000 will be `jumped` to and executed until RETURN is encountered. As the RETURN is on line 1000 the computer RETURN`s immediately to the next line after the GOSUB call - i.e. line 20, where execution continues. The only other commands that are used in the listing are PRINT and REM. PRINT simply PRINT`s the text surrounded by quotes to the screen. REM stands for REMARK and allows you to document your programs - this command has no effect when executed. If there is any part of the following program you do not understand, or if you have never used BASIC before, I suggest you type it out and play it! It should run on most implementations of BASIC, but be careful not to make any typing mistakes (any errors that appear will be of this nature), and if you get into difficulties consult your specific user manual. In any case you should follow the program through on paper, line by line, and note what is happening at each stage, as this will give you an insight into how adventures are written. THE GAME MAP FOR THE BIG CAVE ADVENTURE N ----- | | 2 | W-*-E ----- | | S ----- ----- ----- | 4 |**| 3 |--| 1 | ----- ----- ----- NOTES: A bronze key is located at location two. The gold is located at location four. To pass west from location three to location four the key must be used. To win the game the gold must be picked up. COMMANDS RECOGNISED: North South East West Get <Object> Drop <Object> Use <Object> 1 LET KEY=2 2 LET GOLD=4 3 LET PLAYERLOC=1 10 REM "The big cave adventure by Derek Whiteman" 11 REM "Note: All input should be in upper case" 20 GOSUB 1000 30 INPUT A$ 40 IF A$="NORTH" AND N<>0 THEN LET PLAYERLOC=N 50 IF A$="EAST" AND E<>0 THEN LET PLAYERLOC=E 60 IF A$="SOUTH" AND S<>0 THEN LET PLAYERLOC=S 70 IF A$="WEST" AND W<>0 THEN LET PLAYERLOC=W 80 IF A$="NORTH" AND N=0 THEN PRINT "Sorry you cannot go north." 90 IF A$="EAST" AND N=0 THEN PRINT "Sorry you cannot go east." 100 IF A$="SOUTH" AND N=0 THEN PRINT "Sorry you cannot go south." 110 IF A$="WEST" AND N=0 THEN PRINT "Sorry you cannot go west." 120 GOSUB 2000 130 GOTO 20 1000 REM "Print up the location description and define the exits" 1010 IF PLAYERLOC=1 THEN PRINT "You are standing near the entrance of a large cave. A path leads north and you may enter the cave by going west." : LET N=2 : LET E=0 : LET S=0 : LET W=3 1020 IF PLAYERLOC=2 THEN PRINT "Abruptly the path ends and drops away into nothingness. You stand on the brink of a great chasm. A path leads south." : LET N=0 : LET E=0 : LET S=1 : LET W=0 1030 IF PLAYERLOC=3 THEN PRINT "You stand in the big cave. There is a door to the west while the entrance is to the east." : LET N=0 : LET E=1 : LET S=0 : LET W=0 1040 IF PLAYERLOC=4 THEN PRINT "You stand in the secret room. You may go east through the swing door." : LET N=0 : LET E=3 : LET S=0 : LET W=0 1050 GOSUB 1500 1060 RETURN 1500 REM "Print up any objects the player can see" 1510 IF PLAYERLOC=KEY THEN PRINT "You see a bronze key." 1520 IF PLAYERLOC=GOLD THEN PRINT "You see the gold." 1530 RETURN 2000 REM "Do special actions" 2010 IF A$="GET KEY" AND PLAYERLOC=KEY THEN PRINT "You take the key." : LET KEY=254 2020 IF A$="DROP KEY" AND KEY=254 THEN PRINT "You drop the key." : LET KEY=PLAYERLOC 2030 IF A$="USE KEY" AND KEY=254 AND PLAYERLOC=3 THEN PRINT "You open the door and go through." : LET PLAYERLOC=4 2040 IF A$="GET GOLD" AND PLAYERLOC=4 THEN PRINT "You take the gold. Well done, you have completed the big cave adventure." : LET GOLD=254 2050 RETURN Although this may appear rather complicated if you are new to programming, the `big cave adventure` is actually very simplified and a commercial game would have many more locations, objects and puzzles. But from this simple example we can see the basic structure of any adventure program. That is: 1. Initialise all game variables (set them to their start value). 2. Print up the current location description. 3. Input players wishes from the keyboard. 4. If the player has entered a valid exit, move him to the new location. 5. Check input for a special event (such as opening a door) and act upon it. 6. Go to step 2. There are several advantages if you write your adventure in a high level language like BASIC. The most obvious is that you have complete control over the input and output resources, and can therefore define your game pretty much without restriction. Also most modern versions of BASIC allow for good file handling, music and even graphics, so that presentation will certainly not be an obstacle. But if you do decide to write your adventures from scratch in a high level language, there are numerous problems you would need to confront before your initial idea can be rendered. The first and most obvious is that you need to be able to program to at least a fair standard, even before work commences. This means a complete novice would need to master a programming language, and even then the quality of the game would be directly dependant on his programming skill, and not upon his imaginative powers - which it should be. Another problem is that although experience would be gained through the course of writing the adventure, all the programming is `adventure specific` and hence not transferable. This means you would have to start completely from scratch for each adventure you decided to write using this method. Of course this problem can be lessened by making your programs more standardised, for example, by calling object one, `object1` as opposed to `key` - but this highlights yet another problem: readability. Programs written this way without sufficient documentation tend to be difficult to read and modify, even for the author. It should now be clear that writing an adventure using this method is not exactly the ideal solution, and so others must be examined. The next method of creating your own adventure that shall be examined involves using a pre-prepared utility program. This allows you to write your game without ever having to learn any sort of language, and of course most of the work would have already been done for you. I have seen many different systems of `game creator`, but rather than highlight each individual case I will present an example of what I personally consider to be the `average` in this field. The first thing I should note is that this program was designed to be completely self-contained, allowing you to create your game from its own environment and then save your results as a separate executionable program - which could load independently of the main utility. This allowed people to create a free-standing product which could be marketed for profit if they so wished, and none of this profit would go to the original utility programmers. This of course fired peoples imaginations with notions of fame and fortune, and many such games appeared on the market - usually in the `budget` price range, but standards varied widely from game to game, ranging from the excellent and well conceived to the inferior. To use these utility programs no programming knowledge was required; the user simply defined the verbs he wished to use in his adventure (e.g. north, east, take, say) and then the nouns (e.g. wall, curtain, floor, and door). Some of the more advanced ones even allowed you to define pronouns or adverbs, while almost all allowed you to define, place and manipulate objects (e.g. keys, sticks, rings, bags and lamps). To represent each location the program draws a grid of octagonal shapes so that each is connected in eight places (I believe this was chosen to make it easy to implement the directions of North, North-East, East, South-East, South, South-West, West, and North-West). E.g. You might define the exits as: -- -- / \ / \ North -- 01 -- 02 -- North-West -- North-East / \ / \ / \ / \ | 03 || 04 || 05 | West | 04 | East \ / \ / \ / \ / -- 06 -- 07 -- South-West -- South-East \ / \ / South -- -- The program then allowed you to move a cursor to point to one of the exits (represented by a corner of the octagon), and then select which verb would move you through to the location on the other side. To provide the `raw processing elements` of your adventure, you simply selected an action from the menu, such as verb <noun> or verb <object> and this action was then made specific for that location. For example, if there was a verb called drop and an object called rope, you could define the condition ACTION CONSEQUENCE verb <object> The rope is moved to the DROP ROPE players current location. for any specific location. So now if the player typed drop rope at this location, the `consequence` of that action would be recognised and invoked (in this case the rope would be dropped). As the computer could not possibly know what the consequences should be if a certain action is inaugurated, the user had to define these in another menu, where he selected from things like: move object/player to a location, print some text to the screen, pick up an object, put down an object, and display the player`s inventory. You may not yet have realised it, but there is a serious drawback with this system. If you wished to be able to pick up an object at any location in the game, you would have to set two conditions at every single location, and do this for every single object you invented. This, as you are no doubt aware, would be a monumental task, and a task which could be accomplished far more easily by using other methods. Another problem is that these programs tend to be rather restrictive, with many things the user simply cannot achieve through the use of this software alone. To take an extreme example, say you wished to make a two player adventure game - or let the player control more than one character during the game. No provision has been made for this and so it would be impossible to accomplish using this utility. But despite all its problems, the adventure creating utilities do allow you to begin your adventure almost immediately with no programming knowledge what so ever, and then progress quickly and easily using a simple menu system. I feel these advantages are superlative for the beginner, but an experienced adventure writer would find the system too restrictive and therefore unusable. Besides using a self contained adventure creating utility, there exists another method which could be considered the complete opposite. Whereas with an adventure creator all the programming has been completed for you, using the method I shall now describe requires you to define your adventure through programming alone. Over the last few years I have witnessed the publication of several `adventure definition` languages. These are similar in structure to high level languages such as PASCAL or BASIC, but just as any language has its specific uses (e.g. COBOL - business applications, FORTRAN - mathematical), adventure definition languages are totally geared towards the programming requirements of an adventure game. As a consequence it should be easier for a programmer to write an adventure - taking full advantage of the features, to produce a much more powerful package than it would otherwise be. I say `should be` because in my experience it is just as, if not more difficult, to create an adventure this way primarily because the languages are nowhere near as friendly as, say, BASIC can be. Although I would rule this method out to anyone who has not had at least one years experience with another language, for the more experienced programmer (or the very fast learner) these adventure definition languages can be very useful, and allow the user to write their game free of the restrictions imposed by the adventure creating utilities discussed above. Merely out of interest, and to give you some idea of the structure of these languages, I have provided a sample below - although no attempt will be made to explain it since it is not related in any great way to my own intensions. ; This is the object-oriented runtime package ; by David Betz ; July 19, 1986 ; ******************** ; PROPERTY DEFINITIONS ; ******************** ; These properties will be used for connections between locations (property north ; the location to the north south ; the location to the south east ; the location to the east west ; the location to the west up ; the location above down) ; the location below ; Basic object properties (property initial-location ; the initial location of a "thing" description ; the "long" description of a location short-description) ; the "short" description of a location ; Connection properties (property parent ; the parent of an object sibling ; the next sibling of an object child) ; the first child of an object ; Location properties (property visited) ; true if location has been visited by player ; Portal properties (property closed ; true if the portal is closed locked ; true if the portal is locked key ; key to unlock the portal other-side) ; the other portal in a pair ; ********************** ; VOCABULARY DEFINITIONS ; ********************** ; Some abbreviations for common commands (synonym north n) (synonym south s) (synonym east e) (synonym west w) (synonym inventory i) ; Define the basic vocabulary (conjunction and) (article the that) ; ******************** ; VARIABLE DEFINITIONS ; ******************** (variable curloc ; the location of the player character %actor ; the actor object %dobject ; the direct object %iobject) ; the indirect object ; ********************* ; CONNECTION PRIMITIVES ; ********************* ; Connect an object to a parent (define (connect p c) (setp c parent p) (setp c sibling (getp p child)) (setp p child c)) ; Connect all objects to their initial parents (define (connect-all &aux obj maxp1 par) (setq obj 1) (setq maxp1 (+ $ocount 1)) (while (< obj maxp1) (if (setq par (getp obj initial-location)) (connect par obj)) (setq obj (+ obj 1)))) ; Disconnect an object from its current parent (define (disconnect obj &aux this prev) (setq this (getp (getp obj parent) child)) (setq prev nil) (while this (if (= this obj) (progn (if prev (setp prev sibling (getp this sibling)) (setp (getp this parent) child (getp this sibling))) (setp this parent nil) (return))) (setq prev this) (setq this (getp this sibling)))) ; Print the contents of an object (used by "look") (define (print-contents obj prop &aux desc) (setq obj (getp obj child)) (while obj (if (setq desc (getp obj prop)) (progn (print " ") (print desc))) (setq obj (getp obj sibling)))) ; List the contents of an object (used for "inventory") (define (list-contents obj prop &aux desc) (setq obj (getp obj child)) (while obj (if (setq desc (getp obj prop)) (progn (print "\t") (print desc) (terpri))) (setq obj (getp obj sibling)))) ; ************************ ; OBJECT CLASS DEFINITIONS ; ************************ ; *********************** ; The "basic-thing" class ; *********************** (object basic-thing (property parent nil ; the parent of this object sibling nil)) ; the next sibling of this object ; *************************** ; The "location" object class ; *************************** (object location (property child nil ; the first object in this location visited nil) ; has the player been here yet? (method (knock? obj) T) (method (enter obj) (connect self obj) T) (method (leave obj dir &aux loc) (if (setq loc (getp self dir)) (if (send loc knock? obj) (progn (disconnect obj) (send loc enter obj))) (progn (print "There is no exit in that direction.\n") nil))) (method (describe) (if (getp self visited) (print (getp self short-description)) (progn (print (getp self description)) (print-contents self description) (setp self visited t))) (terpri))) ; ****************** ; The "portal" class ; ****************** (basic-thing portal (method (knock? obj) (if (getp self closed) (progn (print "The ") (print (getp self short-description)) (print " is closed!\n") nil) T)) (method (enter obj) (connect (getp (getp self other-side) parent) obj)) (method (open) (if (not (getp self closed)) (progn (print "The ") (print (getp self short-description)) (print " is already open!\n") nil) (if (getp self locked) (progn (print "The ") (print (getp self short-description)) (print " is locked!\n") nil) (progn (setp self closed nil) T)))) (method (close) (if (getp self closed) (progn (print "The ") (print (getp self short-description)) (print " is already closed!\n") nil) (progn (setp self closed T) T))) (method (lock thekey) (if (not (getp self closed)) (progn (print "The ") (print (getp self short-description)) (print " is not closed!\n") nil) (if (getp self locked) (progn (print "The ") (print (getp self short-description)) (print " is already locked!\n") nil) (if (not (= thekey (getp self key))) (progn (print "It doesn't fit the lock!\n") nil) (progn (setp self locked t) T))))) (method (unlock thekey) (if (not (getp self closed)) (progn (print "The ") (print (getp self short-description)) (print " is already open!\n") nil) (if (not (getp self locked)) (progn (print "The ") (print (getp self short-description)) (print " is not locked!\n") nil) (if (not (= thekey (getp self key))) (progn (print "It doesn't fit the lock!\n") nil) (progn (setp self locked nil) T)))))) ; ***************** ; The "actor" class ; ***************** (basic-thing actor (property child nil) ; the first "thing" carried by this actor (method (move dir) (send (getp self parent) leave self dir)) (method (take obj) (disconnect obj) (connect self obj)) (method (drop obj) (disconnect obj) (connect (getp self parent) obj)) (method (carrying? obj) (= (getp obj parent) self)) (method (inventory) (cond ((getp %actor child) (print "You are carrying:\n") (list-contents %actor short-description)) (T (print "You are empty-handed.\n"))))) ; ***************** ; The "thing" class (things that can be taken) ; ***************** (basic-thing thing (class-property takeable t)) ; **************************** ; The "stationary-thing" class (things that can't be moved) ; **************************** (basic-thing stationary-thing) ; *********************** ; MISCELLANEOUS FUNCTIONS ; *********************** ; Complain about a noun phrase (define (complain head n tail) (print head) (print-noun n) (print tail) (abort)) ; Find an object in a location (define (findobject loc n &aux this found) (setq this (getp loc child)) (setq found nil) (while this (if (match this n) (if found (complain "I don't know which " n " you mean!\n") (setq found this))) (setq this (getp this sibling))) found) ; Find an object in the player's current location ; (or in the player's inventory) (define (in-location n &aux obj) (if (or (setq obj (findobject curloc n)) (setq obj (findobject %actor n))) obj (complain "I don't see a " n " here!\n"))) ; Find an object in the player's inventory ; (or in the player's current location) (define (in-pocket n &aux obj) (if (or (setq obj (findobject %actor n)) (setq obj (findobject curloc n))) obj (complain "You don't have a " n "!\n"))) DESIRED OUTCOME =============== Of all the methods discussed while evaluating the problem I feel none are completely satisfactory, and so I must endeavour to find a new method which proves more so. I believe the ideal solution would combine the ease of use and user friendliness of the purpose built editor, with the power and unrestrictiveness of a dedicated language. To do this I feel a direct fusion of the two classes is necessary before all of the requirements are met. I therefore propose a program which has a simple to use editor, so that the user can begin to write an adventure almost immediately (since most of the work would have already been done), but also have a simple to learn but powerful language modelled on the popular BASIC system, and with all of the commands specific to adventure writing. This amalgamation of all of the methods should produce a unique adventure game creation utility which surpasses all methods currently in existence. Therefore the desired outcome of this project is to create a program which allows the user to define things related to all adventures (such as location descriptions, verbs, nouns, objects and characters), by use of a simple menu-driven editor, and then define special events through the use of a BASIC style adventure language. The user should be able to test the game at any time without having to leave the utility, but also have the option of a break function in case the adventure program they have written gets stuck in an endless loop. Once created the game should then be saved in one of two formats: a data file which can be loaded back into the editor and modified at anytime, and also a special game file which cannot be loaded back into the editor for modification. Since only a small part of the main editor program is needed to `run` the adventure, a separate run-time control program will be created to allow people to run their adventures external to the editor. Also since knowledge of DOS commands cannot be assumed, I will create a program which formats disks ready for data files, and then a program which will install an auto-booting adventure game disk, so that users are able to create a free-standing product. Here is an input / output diagram for the adventure utility (which I have decided to name FRAC to represent the words Fantasy Roleplaying Adventure Creator), given here as a summary. THE FRAC SYSTEM INPUT PROCESSING OUTPUT ----- ----------- ----- | |--->----| |--->----| | | | | | | | ----- | | ----- Previously saved data file | | Saving a new data file to disk ----- | | ----- | |--->----| FRAC |--->----| | | | | | | | ----- | | ----- Input from the keyboard | | Saving a new game file to disk | | ----- | |--->----| | | | | | | | ----- ----------- Results displayed on screen INPUT PROCESSING OUTPUT ----- ----------- ----- | |--->----| |--->----| | | | | | | | ----- | FRAC | ----- Previously saved game file |run-time | Results displayed on screen ----- | control | | |--->----| program | | | | | ----- | | Input from the keyboard | | | | ----------- To create an adventure, three disks would be needed: -------- -------- -------- | | | FRAC | | FRAC | | FRAC | | DATA | | GAME | | | | DISK | | DISK | -------- -------- -------- FRAC: The FRAC boot disk is used to load the utility. FRAC DATA DISK: A FRAC data disk is used to save your data files on - (remember a data file is basically an unfinished adventure). FRAC GAME DISK: Once your adventure is complete, a game disk is needed to store the finished product. This would auto boot into the game once finished. USER MANUAL =========== To understand the material presented here, you should have knowledge of adventure games, realise that this is an adventure game creator, and know what this means. This information is given in the previous section, and if you have any doubts I would urge you to read it before continuing further. FRAC ---- FRAC stands for Fantasy Roleplaying Adventure Creator and is a utility for the Commodore Amiga home computer. It is a completely self contained adventure creating system, which can be used by a person with no programming experience to create their own text adventure games, and if appropriate, market them for profit. Although it is stated that a person with no programming experience could use it, they must come to terms with FRAC`s own programming language called FRACTOL (Fantasy Roleplaying Adventure CreaTors Operating Language). This language is very close to BASIC, but unlike BASIC provides many special commands specifically for use with creating text adventures. As this language is fully documented it should be simple even for a complete beginner to progress unhindered by technicalities. LOADING FRAC ------------ The main and associated programs of FRAC come on one auto-booting disk. To load FRAC simply switch on your computer and insert this disk into drive df0: (i.e. the internal drive). The disk will then be accessed for about thirty seconds, after which time you will be presented with the following menu: *** FRAC BOOT MENU *** 1. LOAD THE FRAC DEVELOPMENT SYSTEM 2. CREATE A FRAC DATA DISK 3. INSTALL AN ADVENTURE DISK 4. RESET SELECT: To make your selection you may press the respective function key of the choice you wish to make (e.g. if you wanted to select number three - INSTALL AN ADVENTURE DISK, you would press F3 or alternatively you could type `3` and then press return). Each of the functions are described below. 1. LOAD THE FRAC DEVELOPMENT SYSTEM -------------------------------- This, when selected, will take you to FRAC`s main editing system. From here you may create, save or load adventures. As the rest of this manual is dedicated to explaining this program, I feel no need to expand upon this description. 2. CREATE A FRAC DATA DISK ----------------------- For this function you will require a disk which has not yet been formatted, or one on which you no longer require the data. Once selected this function will ask you to insert a disk and then format it ready for use. The newly formatted disk will then be empty and consequently can be used to save FRAC data files. Simply follow the on- screen prompts and requests to successfully complete this operation. 3. INSTALL AN ADVENTURE DISK ------------------------- This function is slightly more complicated. It requires you to have previously saved an adventure file (as opposed to a data file) using FRAC. Firstly the program copies all the files it will need into memory. It will then ask you to insert the disk which contains one or more adventure files, and then copy these to memory. Finally it will ask you to insert a blank disk which it will proceed to format, initialise and make into an auto-booting adventure game disk for you. Once the operation is complete you will be told to reset. You may now boot new disk which will now load directly into your adventure (note: if there is more than one adventure file on disk a menu will appear to allow the player to select which game they wish to load). 4. RESET ----- This function clears the reset vectors (thereby killing any virii which might be lying dormant in memory) and then resets the computer. THE EDITOR ---------- The FRAC EDITOR allows you to create the main gaming components of your adventure quickly and easily. I have tried to make it as user-friendly as possible and as far as I can tell it is completely `uncrashable`. Before I go into any great detail about each menu option, I would like you to follow a short tutorial which will create the example adventure `Escape from desert island`, described in the evaluation. I have started off with this (even though the user has no knowledge of FRAC or its functions), because it is much easier to read a manual for a utility which you have already seen, and can therefore identify with. It also makes the potential user familiar with some of the more common functions, and could also serve as an example once they have mastered the basic techniques of adventure writing. `ESCAPE FROM DESERT ISLAND` Tutorial ------------------------------------ At the start of this tutorial you should be looking at the main menu, and the memory counter at the top left of the screen should read 80000. If it does not, select option 9 - `clear memory` by pressing F9 and then at the prompt `Are you sure you want to clear all of the memory?`, type `y` and press return. Whenever you are asked to type something, always press return once you have finished. If you make a mistake which you cannot see how to correct, it is best to start again by clearing the memory using the method described above. Select the Location Menu by pressing F1. Select Create Description by pressing F1. Type 1 at the prompt `Please Enter Location Number:`. At the prompt `Please Enter Description For Location 1:` type the following: You are standing on a warm tropical beach. To the south the placid sea hardly ripples under the beams of the hot sun. A few yards away a large grey rock basks in the summer rays. To the west there appears to be a cave, sheltered in the rockface, while You will notice that the sentence in not complete. This is because FRAC can only accept 254 characters for input at a time (approximately four lines). We must therefore use a function I developed to get around this problem. Select F4 - Add To Description. Type 1 at the prompt `Please Enter Location:`. You will see the description you typed above being displayed, but you can continue typing for another four lines. So now type: the north holds lush green vegetation. Select Create Description by pressing F1. Type 2 at the prompt `Please Enter Location Number:`. At the prompt `Please Enter Description For Location 2:` type the following: You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. Select Create Description by pressing F1. Type 3 at the prompt `Please Enter Location Number:`. At the prompt `Please Enter Description For Location 3:` type the following: You are in a very dark cave which seems to tunnel its way deep into the mountains, but you could not progress further without a light. The entrance lies to the east. Select Create Description by pressing F1. Type 4 at the prompt `Please Enter Location Number:`. At the prompt `Please Enter Description For Location 4:` type the following: You stand amidst large tropical trees. Exits lead east and south. Select Create Description by pressing F1. Type 5 at the prompt `Please Enter Location Number:`. At the prompt `Please Enter Description For Location 5:` type the following: You stand amidst large tropical trees. Exits lead west and south. Type E to return to the Main Menu. Press F8 to select Options. Press F3 to switch Visible Exit Reporting off. Type E to return to the Main Menu. Press F2 to select the Verb Menu. To create a verb use this procedure: ----------------------------------------------------------------------- | Press F1 to Create Verb. | | Press return at the prompt `Please Enter Verb Number:` - FRAC will | | then automatically select the next free verb. | | Type in the verb at the prompt. | ----------------------------------------------------------------------- Use this procedure to create the following verbs: NORTH.N (The full stop symbol allows you to have synonyms) EAST.E SOUTH.S WEST.W LOOK.L ENTER TAKE.GET DROP INVENTORY.I EXAMINE.EXAM LIGHT CUT Type E to return to the Main Menu. Press F1 to select Location Menu. Press F8 to select Exit Menu. Press F4 to select Auto Exits. Now type: 1 north south 2 east west Then type 0 to quit. Press F1 to Create Exits. Type 1 for Location Number. Type 1 for Exit Number You Wish To Edit. Type west at the Please Enter Verb prompt. Type 2 for jump location. Press F1 to Create Exits. Type 2 for Location Number. Type 2 for Exit Number You Wish To Edit. Type west at the Please Enter Verb prompt. Type 3 for jump location. Press F1 to Create Exits. Type 2 for Location Number. Type 3 for Exit Number You Wish To Edit. Type north at the Please Enter Verb prompt. Type 4 for jump location. Press F1 to Create Exits. Type 1 for Location Number. Type 4 for Exit Number You Wish To Edit. Type enter at the Please Enter Verb prompt. Type 3 for jump location. Press F1 to Create Exits. Type 4 for Location Number. Type 2 for Exit Number You Wish To Edit. Type east at the Please Enter Verb prompt. Type 5 for jump location. Press F1 to Create Exits. Type 5 for Location Number. Type 2 for Exit Number You Wish To Edit. Type south at the Please Enter Verb prompt. Type 1 for jump location. Type E to return to the Location Menu. Type E to return to the Main Menu. Press F3 for the Word Menu. Press F1 to create a word. Type 1 for word number. Type rock at the Please Enter Word prompt. Press F1 to create a word. Type 2 for word number. Type river.water at the Please Enter Word prompt. Press F1 to create a word. Type 3 for word number. Type tree.trees at the Please Enter Word prompt. Press F4 for Object Menu. Press F1 to create an object. Type 1 for object number. Type mirror for object name. Type 4 for start location. Press return eight times (once for each definition) to return to the object menu. Press F1 to create an object. Type 2 for object number. Type walking stick.walking for object name. Type 254 for start location. Press return eight times (once for each definition) to return to the object menu. Press F1 to create an object. Type 3 for object number. Type burning stick.burning for object name. Type 0 for start location. Press return eight times (once for each definition) to return to the object menu. Press F1 to create an object. Type 4 for object number. Type hatchet for object name. Type 0 for start location. Press return eight times (once for each definition) to return to the object menu. Press F1 to create an object. Type 5 for object number. Type charred stump.stump for object name. Type 0 for start location. Press return eight times (once for each definition) to return to the object menu. Press F1 to create an object. Type 5 for object number. Type boat for object name. Type 0 for start location. Press return eight times (once for each definition) to return to the object menu. Type E to return to the Main Menu. Press F10 to Enter FRACTOL. Press the TAB key to hold the display. Type p1 to point to procedure 1. Now type the following lines - pressing return after each. 10 IF (IN(1)=VERB(10) AND IN(2)=WORD(1)) THEN PRINT "It is very large and heavy and appears to have been here since the Earth itself was formed. The letters `EM` are scraped into the side." 20 IF (IN(1)=VERB(7) AND IN(2)=WORD(1)) THEN PRINT "You`re joking right? If Newtons first law states that every object continues at rest or with uniform velocity unless acted upon by a resultant force, my first law is Physics students can`t lift rocks." 30 IF (IN(1)=VERB(3) AND OBJLOC(6)=254) THEN PRINT "You sail south in your tree boat. Well done! You have escaped from the desert island." : READLINE : LET CHARLOC(0)=0 Type p2 to point to procedure 2. Now type the following lines - pressing return after each. 10 IF (IN(1)=VERB(10) AND IN(2)=WORD(0)) THEN PRINT "The water flows slowly over a sandy bank, broken in many places by small rocks." 20 IF (IN(1)=VERB(7) AND IN(2)=WORD(2)) THEN PRINT "Alright wise guy cut the cracks, if you wanna spend your life collecting the rivers of this world that`s up to you. But right now we`ve got an adventure to solve." 30 IF (IN(1)=VERB(3) AND OBJLOC(6)=254) THEN PRINT "You sail south in your tree boat. Well done! You have escaped from the desert island." : READLINE : LET CHARLOC(0)=0 Type p4 to point to procedure 4. Now type the following lines - pressing return after each. 10 IF (((IN(1)=VERB(12) AND IN(2)=WORD(3)) AND OBJLOC(4)=254) AND OBJLOC(6)=0) THEN PRINT "You cut down a medium sized tree and shape it into a roughly made boat." : LET OBJLOC(6)=CHARLOC(0) 20 IF (IN(1)=VERB(10) AND IN(2)=WORD(3)) THEN PRINT "The trees here are quite large, being what a helpful person would call `boat sized`." Type p5 to point to procedure 5. Now type the following line - then press return. 10 PROCEDURE 4 Type p253 to point to procedure 253 (this is known as the recurrent list because it is executed every turn). Now type the following lines - pressing return after each. 10 IF ((CHARLOC(0)=3 AND OBJLOC(4)=0) AND OBJLOC((3)=254) THEN LET OBJLOC(4)=3 20 IF ((CHARLOC(0)=3 AND OBJLOC(4)=3) AND OBJLOC(3)<>254) THEN LET OBJLOC(4)=0 30 IF VAR(0)<>CHARLOC(0) THEN WRITE DESCRIPTION(CHARLOC(0)) 40 LET VAR(0)=CHARLOC(0) 50 IF VAR(2)<>0 THEN LET VAR(2)=(VAR(2)+1) 60 IF VAR(2)=5 THEN PRINT "The stick withers and goes out." : LET OBJLOC(5)=OBJLOC(3) : LET OBJLOC(3)=0 Type p254 to point to procedure 254 (this is known as the general list because all commands which are `general` to the adventure - i.e. can be typed at any location - are placed here). Now type the following lines - pressing return after each. 10 IF IN(1)=VERB(5) THEN LET VAR(0)=0 : PROCEDURE 253 20 IF IN(1)=VERB(10) THEN PRINT "There`s not much to tell." 30 IF IN(1)<>VERB(9) THEN GOTO 80 40 PRINT "You are currently carrying:" 50 FOR VAR(1)=1 to 254 60 IF OBJLOC(VAR(1))=254 THEN PRINT "The ",OBJNAME(VAR(1)),"." 70 NEXT 80 IF ((IN(1)=VERB(7) AND IN(2)=OBJECT(X)) AND OBJLOC(X)=CHARLOC(0)) THEN PRINT "You take the ",OBJNAME(X),"." : LET OBJLOC(X)=254 90 IF ((IN(1)=VERB(8) AND IN(2)=OBJECT(X)) AND OBJLOC(X)=254) THEN PRINT "You drop the ",OBJNAME(X),"." : LET OBJLOC(X)=CHARLOC(0) 100 IF (((IN(1)=VERB(11) AND IN(2)=OBJECT(2)) AND OBJLOC(2)=254) AND OBJLOC(1)=254) THEN PRINT "The rays of the sun reflect off the mirror scorching the stick which, as a result, burns slowly away." : LET OBJLOC(2)=0 : LET OBJLOC(3)=254 : LET VAR(2)=1 110 IF IN(1)=UNKNOWN THEN PRINT "Sorry, that command is not understood." Now after all that hard work it`s time for the reward. Select Play Adventure from the Main Menu by pressing F7 and you will now enter the game world which you have just created. Use the verbs listed earlier; and although you know how to solve this adventure (having just typed it in!), it is still fun to experiment. Once you are bored (which should not take too long) you might like to play some of the other example adventures on this disk. To load them simply leave the game by pressing return without typing anything, select File Menu by pressing F6, press F1 to select Load File, then type the number of the game you wish to load and press return. To play this game you have just loaded, simply type E to return to the Main Menu and press F7 to begin. [Note: If you are incredibly lazy you might like to learn that a complete and working version of the above adventure is supplied on the boot disk. To load this simply follow the instructions given to load files, but select `ESCAPE FROM DESERT ISLAND` when the list of games appear.] THE MAIN MENU ------------- From the main menu you will have access to every function FRAC possesses (although you may have to go through several sub menus to get to it). When FRAC loads this is the first thing you will be presented with, so it is important that I give you a full description of it now. The main menu looks like this: *********************************************************************** * FRAC - The Fantasy Roleplaying Adventure Creator * * Copyright - 1992 Derek Whiteman. All rights reserved * *********************************************************************** MEM = 80000 MAIN MENU ^^^^ ^^^^ 1. LOCATION MENU 2. VERB MENU 3. WORD MENU 4. OBJECT MENU 5. CHARACTER MENU 6. FILE MENU 7. PLAY ADVENTURE 8. OPTIONS 9. CLEAR MEMORY 0. ENTER FRACTOL E. <EXIT> The memory counter at the top left gives you an up to date account of how many more ascii characters (i.e. letters - or for the more informed, bytes) FRAC is able to store in memory. At the start, or when the memory has just been cleared, it should display 80000 which is large enough for most adventures. (In case you are wondering, the memory taken up by the music and graphics you include in your adventures is not subtracted from this total, since only text is stored here). If this total ever gets below about 500, it is best to stop typing since you are now reaching the minimum amount of memory FRAC requires to operate. If you do ever write an adventure this big, it would be a good idea to split it up into smaller parts so that the whole adventure could be as large as you liked. To move onto the next part, you might decide to give the player a password on completion of all of the tasks. They could then use this to begin play, whereas a person who has not yet completed the previous part would not know the password, and consequently would be unable to jump ahead and cheat. Pressing escape or typing E at the main menu produces the prompt `Are You Sure You Want To Quit?`. Typing Y (or any word beginning with Y) will exit FRAC and return you to AmigaDOS, while anything else will return you to the main menu. Pressing escape or typing E at any other menu will take you back a level to the previous menu. THE KEYBOARD ------------ While you are in FRAC there are certain features that are not usually available. Firstly the function keys can be used instead of typing in a number, and escape may be used instead of typing E. Pressing help will automatically select help, and the tab key will flip between hold display on, and hold display off (note: these only work when in FRACTOL). Another feature is that because FRAC uses a shell environment, it will have an internal command history buffer. This means the last 2048 characters you have typed in will be remembered, and can be recalled and edited by you, and then re-entered by pressing return. There are also a few helpful line editing functions which can be invoked by pressing the following keys: LEFT CURSOR KEY - move cursor one character left within the text. RIGHT CURSOR KEY - move cursor one character right within the text. THE DELETE KEY - deletes the character at the current cursor position. THE BACKSPACE KEY - deletes the character to the left of the current cursor position. <CONTROL> THEN K - deletes everything from the cursor forward to the end of the line. <CONTROL> THEN U - deletes everything from the cursor backward to the start of the line. <CONTROL> THEN X - deletes the entire line. <SHIFT> THEN LEFT CURSOR KEY - moves cursor to the start of the line. <SHIFT> THEN RIGHT CURSOR KEY - moves cursor to the end of the line. <CONTROL> THEN W - moves cursor to the next tab stop. UP CURSOR KEY - move to previously entered line. This may be repeatedly pressed to move through everything you have typed so far. DOWN CURSOR KEY - move to next line. This can be used to move back through the lines you have already looked at using the key described above. <SHIFT> THEN UP CURSOR KEY - Scan through previous lines to try and locate a match with the text currently being displayed. <SHIFT> THEN DOWN CURSOR KEY - Scan through subsequent lines to try and locate a match with the text currently being displayed. The last four key sequences give you control of the history buffer, and are extremely useful. Say you wished to find the last line 10 you had typed in FRACTOL, and then edit it. You would simply type 10 and then press shift and the up cursor key. The last line 10 would be printed on the screen, and could be edited and re-entered in any form you like. As another example, say you wished to find the last sentence you had typed which began with the word `you`. You would simply type `you`, press shift and up, and if located, the sentence would be displayed ready for editing. There now follows an in depth study of each of the functions on the main menu, starting with the Location Menu. LOCATION MENU ------------- A location in an adventure game is not defined in terms of size or content, but is left to the individual game creator to decide his own interpretation, based upon the size and detail of his game. At first I thought of describing a location as a place of interest to the player, but this is not always true. For example if you wished to simulate the vastness of a sprawling forest, many locations would be similar and not really very interesting - although all would be necessary so that the player could lose his way and forget where he was. I also thought of describing locations in terms of distance, but very few adventures have their locations mapped out in this way, since it is necessary to `cut corners` to prevent the player becoming bored while wandering about large pockets of wilderness. To take an extreme (yet valid) example, a games creator might define an entire desert in one location, while a small house inside the desert might have six locations. This is because the author did not wish to have the player wandering around for ages looking for the house since this has nothing to do with solving the adventure, but the house is far more important, and so more locations are needed to give the player something to explore. You will often see such discrepancies in adventure games, but as long as it flows well and the same guidelines are followed throughout, it doesn`t really matter that much. So as you can see, locations are left pretty much to your own judgement, although it will help greatly if you draw a map using boxes to represent locations and lines to link them up. From this you will be able to determine the type of location description you are looking for, and also create any visible exits. If you are still unsure about how a location description should read, take a look at some of the example adventures which are provided on the boot disk for your entertainment. The Location Menu provides you with all of the functions necessary to define and manipulate locations and their exits. This will generally be one of the most frequently used of the FRAC menus, so it pays to study its layout. *********************************************************************** *** LOCATION MENU *** *********************************************************************** 1. CREATE LOCATION 2. VIEW LOCATION 3. ERASE LOCATION 4. ADD TO DESCRIPTION 5. LIST DESCRIPTIONS 6. EXCHANGE DESCRIPTIONS 7. DISPLAY USED LIST 8. EXIT MENU 9. CLEAR ALL DESCRIPTIONS E. EXIT TO MAIN MENU 1. CREATE DESCRIPTION ------------------ This allows you to create the text that will be displayed when the player is at a certain location. On selection you will be asked to enter the location number of the description you wish to create - enter this (a number between 0 and 254 - anything else will prompt you again) and press return. If there is already a description for this location it will be displayed, and then you will be asked to enter the new description for this location. When you have finished, press return. 2. VIEW DESCRIPTION ---------------- This allows you to view any location description currently in memory. Simply type the location number you wish to see (the range is 0 to 254) and press return. If the location has no description, `Sorry, location xxx has no description.` will be displayed, otherwise the description will be displayed. You will then be asked to press return. 3. ERASE DESCRIPTION ----------------- This erases a single location description from memory. You will be asked to enter a location number (must be between 0 and 254 or you will be asked again) and if the description exists it will be displayed with the prompt OK to erase location xxx? Simply type `Y` or any word beginning with `Y` to erase the description; anything else will send you back to the Location Menu. If the description number you entered has not yet been defined, you will be sent directly back to the location menu. 4. ADD TO DESCRIPTION ------------------ As you are only allowed to enter 254 characters at a time - a total I find too limiting, I have developed this function to allow users to enter more than this amount, by adding any new text typed to the original. The process can be repeated so that any description lengths are possible. Firstly, this function checks whether any descriptions have been created yet. If not you will be told `Sorry not enough free locations` at which you should just press return to get back to the Location Menu. If there is at least one description in memory, you will be asked to enter the description number which you wish to add to (type a number between 0 and 254). If this location is defined, the definition will be printed with a cursor directly after. Type in what you wish to add, then press return - you will then be sent back to the Location Menu. If the location has not yet been defined the text `This Location Is Empty!` will be printed and you will be asked to enter a different location number. 5. LIST DESCRIPTIONS ----------------- This simply starts at a description number and lists all the descriptions following this, one after another - waiting for you to press return before moving onto the next. Firstly you will be told to enter a location at which to start (a number between 0 and 254) - the description for this location will then be displayed. You may either press return to continue with the next location, or type 1 and press return to get back to the location menu. If you are at location number 254 and you press return, the program will automatically return you to the Location Menu. 6. EXCHANGE DESCRIPTIONS --------------------- This function simply swaps two location descriptions over. Firstly you will be asked to enter the number of the first location that is to be exchanged. Enter a number between 0 and 254 and press return - anything else will force a reprompt. Then you will be asked to enter the number of the second location that is to be exchanged. This must also be between 0 and 254. The descriptions will then be exchanged and you will be sent back to the Location Menu. 7. DISPLAY USED LIST ----------------- This originally displayed a map of all the used locations but I replaced this with a simple counter telling you how many locations you have used. Just press return to get back to the location menu. 8. EXIT MENU --------- This will take you to the Exit sub-menu. From here you can create the visible exits for a location. By visible exits I mean exits which due to their nature cannot be altered or destroyed during the course of the game. All `open-air` exits come into this category, so do all cave entrances and doorways which, for the purposes of the game are never modified. To give you a clearer understanding of what should be classified as a visible exit, it is best to define exits which are NOT classed as visible exits. Examples include cave entrances where a boulder must be removed before entry is possible, secret doors which have to be discovered before they can be used., and doors which need to be unlocked or opened before the exit is revealed. In fact anything which needs to be changed by the player doing something before it can be used - anything else is a visible exit, and can be defined using this menu. *********************************************************************** *** EXIT MENU *** *********************************************************************** 1. CREATE EXITS 2. VIEW EXITS 3. ERASE EXITS 4. AUTO EXITS 5. LIST EXITS 6. EXCHANGE EXITS 7. CLEAR ALL EXITS E. <EXIT> 1. CREATE EXITS ------------ This function allows you to create visible exits for a location: each location has eight visible exits which can be defined by the user. To do this simply enter the location number at the prompt (the range is 1 to 254), and then type in which visible exit you wish to change (between 1 and 8). On pressing return you will be told to `Please Enter Verb:`. You may either type the verb or a synonym, or the number of the verb (range 1 to 254). E.g. if verb 1 was north.n you could type 1, n or north to select it. Once you have selected the verb you will be asked to enter the jump location. This is simply the number of the location the player will jump to if this verb is entered. E.g. if we used north for the verb and set this to 4, every time the player types north or n at this location, he will be moved directly to location 4. 2. VIEW EXITS ---------- This allows you to see the visible exits for a location. Simply type the number of the location you wish to see the exits for (a number between 1 and 254), and once you have finished press return to get back to the Exit Menu. 3. ERASE EXITS ----------- This function allows you to erase one or all of the visible exits belonging to a location. Just type in the location number that you wish to erase exits at (a number between 1 and 254) then either type in the exit you wish to remove (a number between 1 and 8), or 99 if you wish to erase all of the exits at this location. 4. AUTO EXITS ---------- You may already have noticed that to define one exit which the player can walk back and forth between, two exits are needed. That is, one leading from the first location to the second, and then one leading from the second to the first. To save all this extra typing I have developed a system which recognises opposites and will automatically create the second exit for you. To use this you must simply define up to 16 opposite verbs which are used to define exits. Firstly type the number of the AutoExit you wish to edit (a number between 1 and 16). You will then be asked for the first verb, at which you should either type in the verb, a synonym, or its number (between 1 and 254). Here are some example opposites: NORTH/SOUTH NORTHEAST/SOUTHWEST UP/DOWN ENTER/LEAVE After you have entered the two verbs the screen will update and the prompts will start again. To exit simply type 0 at the `Enter Auto Exit Number` prompt. 5. LIST EXITS ---------- This allows you to go through all the locations one by one and examine their exits. Firstly you are asked to enter the start location (a number between 1 and 254). Then you may press return to continue onto the next location, or type 1 and press return to get back to the exit menu. If you are at location 254 and you press return, the program will automatically send you back to the exit menu. 6. EXCHANGE EXITS -------------- This function simply exchanges all the visible exits at one location for all the visible exits at another. You will then be asked to enter the first location number (between 1 and 254), and then the second (1 to 254). 7. CLEAR ALL EXITS --------------- You will be given the prompt `Are you sure you want to clear all exits?`. If you type `Y` or any word beginning with `Y`, all the exits will be cleared along with the Auto Exit definitions. You will then be returned to the Exit Menu. We have now completely examined the Exits sub-menu, so I now return to finish off the functions in the Location Menu. 9. CLEAR ALL DESCRIPTIONS ---------------------- You will be given the prompt `Are you sure you want to clear all descriptions?`. If you type `Y` or any word beginning with `Y` all the location descriptions will be erased. You will then be returned to the Location Menu. This completes the examination of the Location Menu, I now return back to the Main Menu. VERB MENU --------- There are several types of verb. These will be examined below: Active: Expressing action, especially action affecting an object. Neuter: Of neither gender; neither masculine nor feminine (in English grammar applied to all things without life). Transitive: Taking an object after it; denoting action passing to an object that is expressed (a transitive verb). Intransitive: Expressing an action or state that is limited to the subject; not having an object (an intransitive verb). All the actions the player will ever enter will begin with a verb, and this menu allows you to create these. Some examples of valid verbs are: take [transitive] cut [transitive] eat [transitive] throw [transitive] walk [intransitive] run [intransitive] attack [transitive] You can see from even this short list that most of the verbs you will use will be transitive and so require an object (used in the grammatical sense) on which to act. There are several exceptions and their numbers are broadened by a peculiarity which means that words that would normally be considered as nouns, must be treated as verbs. This arises from the strong connection of a noun used to signify a direction and any normal verb. E.g. these would all be defined as verbs in FRAC: fly [intransitive verb] dance [intransitive verb] north [noun!] wear [transitive verb] up [adverb!] The moral of this story is that any word which is used as an exit descriptive, must be defined as a verb - along with all `standard` verbs. Any word defined as a verb in FRAC may have as many synonyms as you like. This is achieved by placing a full stop symbol (.) after the previous definition, before entering the new one. Here is a list of examples: north.n east.e south.s west.w northeast.ne southeast.se northwest.nw southwest.sw up.u down.d take.get drop attack.hit.kill.punch.kick.maim.headbutt *********************************************************************** *** VERB MENU *** *********************************************************************** 1. CREATE VERB 2. VIEW VERB 3. ERASE VERB 4. ADD TO VERB 5. LIST VERBS 6. EXCHANGE VERBS 7. PAGE VERBS 8. CLEAR ALL VERBS E. EXIT TO MAIN MENU 1. CREATE VERB ----------- This allows you to add a verb to FRAC`s vocabulary or exchange an existing one for a new one. At the prompt `Please Enter Verb Number:`, you can do one of three things: type a number between 1 and 254 inclusive, type in an existing verb or synonym - in which case FRAC will instead locate the next free verb and use this to store your input. Next you will be asked to enter the verb (along with its synonyms, if necessary). As with all inputs in FRAC the letter case is irrelevant, but please note that if a verb or a synonym contains a space it will be unrecognisable to FRAC and therefore useless - so make sure you do not use spaces. 2. VIEW VERB --------- This simply displays a single verb of your choosing. To select the verb you may either type it in (or any valid synonym), or type a number between 1 and 254. If the verb you typed does not exist, you will be told `Sorry, verb xxx does not exist`. 3. ERASE VERB ---------- This erases a single verb from the memory. At the prompt `Please Enter Verb:`, you may enter a valid verb or synonym, or type a number between 1 and 254. If the verb does not exist you will return immediately to the verb menu, otherwise you will be asked `OK to erase verb xxx?`. Typing `Y` or any word beginning with `Y` will erase the verb and take you back to he verb menu - anything else will just return you to the verb menu. 4. ADD TO VERB ----------- This function allows you to add synonyms to a previously existing verb. At the prompt `Please Enter Verb:`, you may type in a valid word or synonym, or a number between 1 and 254. If you have not yet defined any verbs you will be told `Sorry, not enough free verbs` - at which you should press return to get back to the verb menu. If the verb you entered was invalid, you will be told `this verb is empty!`, otherwise the verb and its synonyms will be displayed with the cursor directly following. Just enter any synonyms you wish to add and then press return. 5. LIST VERBS ---------- This function asks for a start value and then lists all the verbs starting with this one, one after another. At the prompt `Please Enter Start Verb:` type a verb or its synonym, or any number between 1 and 254. The verb you selected will now be displayed. At the prompt you may either press return to move onto the next verb, or 1 and return to get back to the verb menu. 6. EXCHANGE VERBS -------------- This simply exchanges two verb definitions. At the prompt `Please Enter 1st Verb:`, you may either enter a verb or its synonym, type a number between 1 and 254, or just press return to get back to the verb menu (this will happen automatically if FRAC does not recognise the verb you have entered). 7. PAGE VERBS ---------- This allows you to `flick` through all the verbs you have defined like pages in a book. Twenty verbs will be displayed down the screen. Type 1 to flick left, and 2 to flick right, press return to return to the verb menu. 8. CLEAR ALL VERBS --------------- You will be asked `Are you sure you want to clear all verbs?`. Typing `Y` or any word beginning with `Y` will erase all the verb definitions you have entered so far. You will then be returned to the verb menu. WORD MENU --------- For the purposes of FRAC, `words` are anything which it can recognise. Since verbs are defined elsewhere, words will consist mainly of nouns which have no `directional` properties. Examples include: tree wall rock.boulder door writing As you can see these `words` mainly constitute the object of the sentence, as discussed earlier, and the simple addition of a verb will complete a valid input. For example: climb tree examine wall push rock open door read writing Please Note: For reasons which will be explained later, it is better not to define the definitive article as either a verb or word - but leave it undefined. *********************************************************************** *** WORD MENU *** *********************************************************************** 1. CREATE WORD 2. VIEW WORD 3. ERASE WORD 4. ADD TO WORD 5. LIST WORDS 6. EXCHANGE WORDS 7. PAGE WORDS 8. CLEAR ALL WORDS E. EXIT TO MAIN MENU 1. CREATE WORD ----------- This allows you to add a word to FRAC`s vocabulary or exchange an existing one for a new one. At the prompt `Please Enter Word Number:`, you can do one of three things: type a number between 1 and 254 inclusive, type in an existing word or synonym - in which case FRAC will instead locate the next free word and use this to store your input. Next you will be asked to enter the word (along with its synonyms, if necessary). As with all inputs in FRAC the letter case is irrelevant, but please note that if a word or a synonym contains a space it will be unrecognisable to FRAC and therefore useless - so make sure you do not use spaces. 2. VIEW WORD --------- This simply displays a single word of your choosing. To select the word you may either type it in (or any valid synonym), or type a number between 1 and 254. If the word you typed does not exist, you will be told `Sorry, word xxx does not exist`. 3. ERASE WORD ---------- This erases a single word from the memory. At the prompt `Please Enter Word:`, you may enter a valid word or synonym, or type a number between 1 and 254. If the word does not exist you will return immediately to the word menu, otherwise you will be asked `OK to erase word xxx?`. Typing `Y` or any word beginning with `Y` will erase the word and take you back to he word menu - anything else will just return you to the word menu. 4. ADD TO WORD ----------- This function allows you to add synonyms to a previously existing word. At the prompt `Please Enter Word:`, you may type in a valid word or synonym, or a number between 1 and 254. If you have not yet defined any words you will be told `Sorry, not enough free words` - at which you should press return to get back to the word menu. If the word you entered was invalid, you will be told `this word is empty!`, otherwise the word and its synonyms will be displayed with the cursor directly following. Just enter any synonyms you wish to add and then press return. 5. LIST WORDS ---------- This function asks for a start value and then lists all the words starting with this one, one after another. At the prompt `Please Enter Start Word:` type a word or its synonym, or any number between 1 and 254. The word you selected will now be displayed. At the prompt you may either press return to move onto the next word, or 1 and return to get back to the word menu. 6. EXCHANGE WORDS -------------- This simply exchanges two word definitions. At the prompt `Please Enter 1st Word:`, you may either enter a word or its synonym, type a number between 1 and 254, or just press return to get back to the word menu (this will happen automatically if FRAC does not recognise the word you have entered). 7. PAGE WORDS ---------- This allows you to `flick` through all the words you have defined like pages in a book. Twenty words will be displayed down the screen. Type 1 to flick left, and 2 to flick right, press return to return to the word menu. 8. CLEAR ALL WORDS --------------- You will be asked `Are you sure you want to clear all words?`. Typing `Y` or any word beginning with `Y` will erase all the word definitions you have entered so far. You will then be returned to the word menu. OBJECT MENU ----------- These are objects in the physical sense. Since an adventure would be very boring without things the player could manipulate, FRAC provides many functions dedicated to the inclusion of objects into adventures. If option 4 (visible object report) is switched on, any objects at the current location will automatically be displayed beneath the location description, in the form `you can also see:`. Following this will be the indefinite article which FRAC `guesses`, based upon the character structuring of the noun. The rules are as follows: If the noun ends with the letter `s`, `some` is used. E.g. some grapes. If the noun starts with a consonant, `a` is used. E.g. a gun. If the noun starts with a vowel, `an` is used. E.g. an apple. [Note: The first rule has priority over the second and third rules]. This is true for most nouns but there will always be some exceptions (e.g. FRAC would use `a hay` instead of `some hay`, `some cross` instead of `a cross`). To prevent this happening you can force FRAC to use your indefinite article, by placing the prefix - and a letter directly before the name of the object. Here are the possible prefixes: -a forces FRAC to use `a`. -n forces FRAC to use `an`. -s forces FRAC to use `some`. So to correct the mistakes mentioned above, we could type -shay and -across. *********************************************************************** *** OBJECT MENU *** *********************************************************************** 1. CREATE OBJECT 2. VIEW OBJECT 3. ERASE OBJECT 4. EXCHANGE OBJECTS 5. PAGE OBJECTS 6. SET DEFINITIONS 7. CLEAR ALL OBJECTS E. EXIT TO MAIN MENU 1. CREATE OBJECT ------------- At the prompt `Please Enter Object Number:`, you may either press return - in which case FRAC will locate the next free object for you - or type a number between 1 and 254. If the object you selected already exists it will now be displayed. You will then be given the prompt `Please Enter Name For Object xxx:`. Pressing return will take you back to the object menu with no modification of the object being made., while typing anything else will be taken as the objects name. After any prefix (if you decide to include one) you must type what is known as the title of the object; for this is the name the player will see. It may include spaces. If it does have any spaces, you must have a synonym which does not have any spaces in it, so that FRAC can identify it. E.g. long pole would not be valid since it does not have any synonyms which do not have a space, and so in this form would be unrecognisable (i.e. if the player typed take long pole, only take would be recognised). To avoid this problem we could either shorten the name to just pole, or add a synonym: long pole.pole. Now if the player typed take long pole, pole would be recognised (long would be ignored), and the long pole would be taken. As well as the title you may have as many synonyms as you like separated by full stops. After entering the name, you will be asked to enter the start location of the object. Type any number between 0 and 254. Location 0 means that the object does not yet exist in the game world (but it may be brought into existence later - after the player has committed a certain act. For example, in the tutorial adventure `Escape from desert island`, the burning stick starts at location zero, but as soon as the walking stick is lit, the burning stick swaps places with the walking stick - thus producing the illusion that the stick has caught fire). For the next part you will need to realise that an object possesses eight user definable stats. These can be set to any integer value between 0 and 999999. These `definitions` can be used for all kinds of purposes to make one object different from another. You might make one store the weight of an object, another the size and perhaps the cost - it is up to you. If you wish to leave these undefined just keep pressing return at each of the eight prompts - they will then be set to zero. This completes creating an object. Although it sounds complicated being described as it is above, it is really very simple, usually taking only a matter of second to `knock one out`. 2. VIEW OBJECT ----------- This displays an objects name, along with its starting location and eight definitions. At the prompt `Please Enter Object Number:`, simply type a number between 1 and 254 - anything else will cause FRAC to repeat the prompt. If the object you selected does not exist, you will be informed. 3. ERASE OBJECT ------------ This erases an object from memory. Just type the number of the object you wish to erase at the prompt `Please enter object number:` (from 1 to 254). If the object does not exist you will be told, otherwise it will be erased and you will be returned to the object menu. 4. EXCHANGE OBJECTS ---------------- This simply swaps two objects around. At the prompt `Please enter first object number:`, type a number between 1 and 254 for the first object. If it does not exist you will be returned to the object menu, otherwise you will be asked for the number of the second object, at which you should type a number between 1 and 254. The objects will then be exchanged. 5. PAGE OBJECTS ------------ This allows you to flick through all the objects you have created like pages in a book. The objects will be displayed with their starting location in brackets to the right. Type 1 to move left, 2 to move right, or zero to return to the object menu. 6. SET DEFINITIONS --------------- This allows you to give a name to the eight object definitions. As you can see this will not effect the game in any way and is not at all used by the program, but it makes objects more `readable` to others and yourself while inside the editor. To give a definition a title, firstly type the number you wish to edit (between 1 and 8) or 0 if you wish to quit. You will then be asked to `Enter new word definition:`; by this it means type in the number of the word which describes this definition. In other words you must first create a word which describes this definition, then point to it by using set definition. For example if you wished definition 1 to read `Damage Rating` instead of `DEFINITION #1`, you must first create the word `Damage Rating` (spaces are allowed here since `Damage Rating` never needs to be recognised when playing the game), then set definition word #1 to the word number of `Damage Rating`. Since the program is expecting a word number as input, type anything between 1 and 254, or 0 to leave it undefined. 7. CLEAR ALL OBJECTS ----------------- This clears all objects and all the `word` definitions. You will be asked `Are you sure you want to clear all objects?`. If you type `Y` or any word beginning with `Y` the objects will be cleared, otherwise you will be returned to the object menu. This concludes my examination of the Object sub menu, and so I return to the Main Menu. 5. CHARACTER MENU -------------- If you know about roleplaying games, you would know the characters which I am now describing as `NPC`s` or `Non Player Characters`. These act independently of the player although they may be influenced by him. Although these are meant to simulate life forms, the computer adaptations are understandably weak, mainly because the form of interaction is limited to a number of small keywords which the character can recognise. Even so, including characters in your adventure makes the game a lot more exciting, and if described properly, the players usually fill in any short comings with their imagination. From FRAC`s point of view the only difference between objects and characters, is that characters can move automatically, and so extra provision is made for this. Even though it is easier to define an object as an object and a character as a character, with sufficient programming one could quite easily emulate the other, and so the definitions become a bit fuzzy. As long as option 5 - visible character report - in the Option Menu is left on, the player will automatically be informed of any character movement at his location, and also of any characters currently present. 1. CREATE CHARACTER ---------------- This allows you to add a new character to the game. At the prompt `Please Enter Character Number:`, you may press return - in which case FRAC will locate the next free character for you - or type a number between 1 and 254. You will then be asked to enter the name of the character. Pressing return will send you straight back to the character menu, while typing anything else will be taken as the characters name. Remember that you may have as many synonyms as you like for the character, but at least one must not contain any spaces so that it may be recognised by FRAC. Again the first name is treated as the title, and this is how the player will know the character. Some example character names are as follows: the dark wraith.wraith an old man.old a young man.young Therefore if you typed attack old man, man would be ignored and the `old` recognised. After entering the name you will be asked to enter the characters start location i.e. a number between 0 and 254. Location zero is for unborn, dead or non-existent characters, while any other number will place the character in the game world. Next you will be asked to enter the characters status. This is simply a number between 0 and 999999. If the number is zero, FRAC will move the character around based on the movement list, which you will enter next. Any non-zero value will stop the character moving. Now you will be asked to enter the characters movement list. This is simply a string of characters separated by full stops which move the character about - one entry is executed each turn. The command characters you can use are: `q` - which centres the character onto the current player location, `x` - which move the character through a randomly picked exit at the current location, or you may enter a number between 0 and 254 - this will move the character to that location. If this list is exhausted during the game, it is repeated. Here are some example movement lists: x (wandering character) q (follows player) 1.1.2.2 (moves between 1 and 2, waiting a turn at each) 1.2.3.8.9.3.2 (follows a pattern) After entering the movement list you will be asked to enter the eight character definitions for this character. This can be any number between 0 and 999999. If you do not wish to set these to a value, simply press return at each of the prompts, and they will all be set to zero. 2. VIEW CHARACTER -------------- This simply displays a character`s name along with his starting location, status, movement list and eight character definitions. When asked, enter the number of the character you wish to see (the range is 1 to 254). When you have finished press return to get back to the menu. 3. ERASE CHARACTER --------------- At the prompt `Please Enter Character Number:`, type any number between 1 and 254. This character will then be erased. 4. EXCHANGE CHARACTERS ------------------- This function simply swaps two characters around. At the prompt `Please enter first character number:`, type a number between 1 and 254. If the character you have selected does not exist, you will be returned immediately to the character menu. At the prompt `Please enter second character number:`, type any number between 1 and 254. If the character exists, it will be swapped with the character you first entered. 5. PAGE CHARACTERS --------------- This displays all the characters and allows you to flick through them twenty at a time. To move left type 1, to move right type 2. To return to the character menu just type 0. Displayed to the right of the character in brackets is the start location of the character. 6. SET DEFINITIONS --------------- These are set in exactly the same way as object definitions with exactly the same effect (except these are for characters of course), so please look there for any required explanation. 7. CLEAR ALL CHARACTERS -------------------- You will be asked `Are you sure you want to clear all characters?`. Type `Y` or any word beginning with `Y` and all the characters will be cleared. You will then be returned to the character menu. Returning back to the Main Menu. FILE MENU --------- *********************************************************************** *** FILE MENU *** *********************************************************************** 1. LOAD FILE 2. SAVE FILE 3. DELETE FILE 4. GRAPHIC CONTROL 5. MODULE CONTROL 6. SAVE ADVENTURE E. EXIT TO MAIN MENU 1. FILE MENU --------- This function allows you to load a previously saved data file. Simply push in the disk that contains the file and select this function. The disk will then be directoried and all adventure files displayed in a list, numbered from 1 to 6. At the prompt `Please enter file number:`, simply type the number of the file you wish to load (1 to 6) and press return. Typing 0 will return you to the file menu. 2. SAVE FILE --------- This function allows you to save the game currently in memory as a data file. Simply push in the disk that you wish to save the file on and select the function. The disk will then be directoried and all adventure files displayed in a list, numbered from 1 to 6. At the prompt `Please enter file number:`, simply type the number of the file you wish to save (1 to 6) and press return. Typing 0 will return you to the file menu. 3. DELETE FILE ----------- This function deletes a data or adventure file from the disk. Simply push in the disk that you wish to delete a file from and select this function. The disk will then be directoried and all adventure files displayed in a list, numbered from 1 to 6. At the prompt `Please enter file number:`, simply type the number of the file you wish to delete (1 to 6) and press return. Typing 0 will return you to the file menu. 4. GRAPHIC CONTROL --------------- This function allows you to examine a graphic that is saved on disk. Simply push in the disk which contains the graphic and select this function. At the prompt `Please enter graphic number to display:` type any number between 0 and 15 - anything else returns you to the file menu. The graphic (assuming it is found) will now be displayed. Press any key to return to the file menu. [NOTE: To include graphics in your adventures they must be saved in IFF format (the type used by Deluxe Paint). They must also have the name FRACPIC00 (where the number is changed to match the graphic number - e.g. FRACPIC01, FRACPIC02 etc.). Also the disk that contains the graphics and music must be in the internal drive when the adventure is running.] [NOTE: To include music in your adventures they must be saved using ProTracker, and given the name FRAC1 (upto FRAC6). They will be saved on disk as mod.FRAC1, mod.FRAC2 etc. and should be located on the adventure`s boot disk.] 5. MODULE CONTROL -------------- Selecting this brings up the following menu: *********************************************************************** *** PLAY MODULE *** *********************************************************************** 1. PLAY MODULE 1 2. PLAY MODULE 2 3. PLAY MODULE 3 4. PLAY MODULE 4 5. PLAY MODULE 5 6. PLAY MODULE 6 7. STOP PLAYING E. <EXIT> Simply select the module you wish to hear by typing the number, or 7 to stop playing. Returning to the File Menu. 6. SAVE ADVENTURE -------------- This function allows you to save the game currently in memory as an adventure file. Simply push in the disk that you wish to save the file on and select the function. The disk will then be directoried and all adventure files displayed in a list, numbered from 1 to 6. At the prompt `Please enter file number:`, simply type the number of the file you wish to save (1 to 6) and press return. Typing 0 will return you to the file menu. PLAY ADVENTURE -------------- This function allows you to test your game by placing you directly into the game world. To return to the main menu either press return without typing anything or press control and C (the latter is the emergency override, which will escape under any circumstances). OPTIONS MENU ------------ The Options Menu allows you to set your personal preferences while FRAC is in operation. These options are saved with the file, so any options you set will be game specific. It looks like this: *********************************************************************** *** OPTIONS MENU *** *********************************************************************** 1. SET PLAYER LOCATION 2. UNKNOWN WORD TRAPPING IS: OFF 3. VISIBLE EXIT REPORT IS: ON 4. VISIBLE OBJECT REPORT IS: ON 5. VISIBLE CHARACTER REPORT IS: ON 6. DESCRIPTION FORMATTING IS: ON 7. SET OBJECT REFERENCE TEXT 8. SET CHARACTER REFERENCE TEXT 9. SET MULTIPLE COMMAND ENTRY TEXT 0. BOOT MUSIC IS: ON E. EXIT TO MAIN MENU 1. SET PLAYER START LOCATION ------------------------- This allows you to specify at which location the player will start at, at the beginning of the adventure. Once you select this function you will be told the previous start location (the default is one), and asked to input a new one. If you wish to leave it unchanged just type 0, otherwise type a number between 1 and 254. 2. UNKNOWN WORD TRAPPING --------------------- This and the next few functions are known as `toggle` functions. This means that if they are selected it changes the status from on to off, or off to on. If a toggle function is selected twice in succession it will be returned to its initial status. The default for unknown word trapping is off. This means that any words the player enters that FRAC does not understand will be ignored. For example if only the verb take and the object gun have been defined, and the following was input: take the loaded gun FRAC would remove all words it did not recognise, so it would become: take gun You can see that this is a far easier input to test for. As long as conjunctions remain undefined this is a very useful system, since it allows FRAC to just guess roughly what the player is trying to say - instead of following some strict syntax rules. Although I would advise you to use this method, this can be deactivated by switching unknown word trapping on. Now the players input will not be altered (any words FRAC does not understand will show up as `unknowns`). 3. VISIBLE EXIT REPORT ------------------- This, when activated, will add all the visible exits for that location to the location description, or `there are no visible exits` if there are none. 4. VISIBLE OBJECT REPORT --------------------- This, when activated, will add any objects at that location to the location description, or add nothing if there are none. 5. VISIBLE CHARACTER REPORT ------------------------ This, when activated, will add any characters at that location to the location description, or add nothing if there are none. 6. DESCRIPTION FORMATTING --------------------- If this is activated all text FRAC outputs will be formatted i.e. no word will `go off the right hand edge`. This makes the text far more readable - important since reading is what the player will be doing most of the time. 7. SET OBJECT REFERENCE TEXT ------------------------- This allows you to specify what words will cause FRAC to look for the last object the player has typed on the same line, and then change the word into that object. This may sound a really weird function, until I tell you a prime example (and the only one I can think of) would be the pronoun `it`. So if the object reference text was set to `it` (this may also have synonyms e.g. it.synonym1.synonym2 etc.) and the following text was entered by the player: take the pebble and throw it at gelfand FRAC will see the `it` and change the sentence to: take the pebble and throw pebble at gelfand Now the sentence is much easier to examine - especially if you have set the multiple command entry text to and.then. This will mean the above sentence will be broken into two separate inputs like this: take the pebble throw pebble at gelfand This function is essential if you want to be able to handle more than one command on the same line, and although this does not have a default, you should set it to `it`. 8. SET CHARACTER REFERENCE TEXT ---------------------------- This allows you to specify what words will cause FRAC to look for the last character the player has typed on the same line, and then change the word into that character. Again this may sound like a really weird function, until I tell you that a prime example would be the pronoun `him` (it may also have a synonym e.g. him.her). So if the character reference text was set to him.her, and the player entered the following text: take the stick off gelfand and hit him with it FRAC would amend it to read: take the stick off gelfand and hit gelfand with stick Again if the multiple entry text was set, the following two inputs would result: take the stick off gelfand hit gelfand with stick This function is also essential if you want be able to handle more than one command on the same line, and although this does not have a default, you should set it to `him.her`. 9. SET MULTIPLE COMMAND ENTRY TEXT ------------------------------- This allows you to specify the words that will make FRAC treat whatever follows next as a separate command. For example, if you set this to and.then, the following sentence: take the diamond and move north then drop the diamond would become: take the diamond move north drop the diamond This function is essential if you want to be able to handle more than one command on the same line, and although this does not have a default, you should set it to `and.then`. 0. BOOT MUSIC ---------- This sets whether you wish to hear the music while FRAC is loading. Simply select on or off for yes or no - a file called frac.prefs will then be amended, so the disk should be write enabled before calling this function. This concludes my examination into the Options Menu, and so I return to the Main Menu. 9. CLEAR MEMORY ------------ Upon selecting this you will be asked `Are you sure you want to clear all the memory?`. If you type `Y` or any word beginning with `Y`, everything will be cleared (objects, characters, exits, location, descriptions - everything). You will then be returned to the main menu. 0. ENTER FRACTOL ------------- This will take you into the FRACTOL programming environment. To return to the Main Menu press escape at any time. For a list of commands press help, and to hold the display press tab. The remainder of this manual is set aside to explain FRACTOL. THE FRACTOL PROGRAMMING MANUAL ============================== FRACTOL stands for Fantasy Roleplaying Adventure Creators Operating Language. It is an interpreted language, similar in many respects to BASIC, but with an instruction set specifically designed to be used for the writing of adventure games. Since I have already covered how BASIC works in great detail at the beginning of this project, there is no need to over elaborate here - except to remind the user that each instruction is executed one after another until the end of the program is reached, or an instruction is encountered which alters the sequence of execution - such as goto. Before each instruction is examined, procedures will be discussed and also the FRACTOL environment command, which allows you to manipulate lines and procedures with ease. AN INSTRUCTION IN FRACTOL ------------------------- Every instruction you enter into FRACTOL must begin with a line number between 0 and 254. This decides the order is which the instruction is executed: the computer simply start at the lowest and works upwards until all the lines have been executed. After the line number comes a statement. At present there are twenty three commands to choose from which may be used in a statement, each having a unique effect. Another way of stating the rules which define the way in which an instruction is constructed, or its `syntax`, it to symbols such as the following: ========= =========== Instruction syntax: -----|Integer|-----|Statement|----- ========= =========== This is my interpretation of what is known as a syntax diagram. You simply follow the line from left to right, and every time you come across a box you know that whatever it says in the box is now expected. If the box has double lines it means whatever it says in the box is defined elsewhere, and so you must look there for its definition - which will also be described using syntax diagrams. Here is the syntax diagram for an integer and a digit: ------<------ | ======= | --- Integer: -----|Digit|----- Digit: -----|0|----- ======= | --- | | --- | |-|1|-| | --- | | --- | |-|2|-| | --- | | --- | |-|3|-| | --- | | --- | |-|4|-| | --- | | --- | |-|5|-| | --- | | --- | |-|6|-| | --- | | --- | |-|7|-| | --- | | --- | |-|8|-| | --- | | --- | |-|9|-| --- This means that an integer must have at least one digit but may be followed by more (the line above the digit box means that you may loop back if necessary - so that more digits are possible). A digit is defined as a single character between 0 and 9. Although above it states that an integer may be followed by any number of digits, this, in practice, is not true. FRAC places a limit of 254 on any integer, and anything above this value will `clock around` e.g. 255 will become 0, 256 becomes 1, 257 becomes 2 etc.. In the above syntax of an integer, negative numbers are not possible, although FRAC does handle them: they must be formed inside expressions (see later). Therefore the lower limit of a FRAC integer is zero. Using the syntax diagrams, and taking into account the range restrictions mentioned above, here are some valid integers: 0000001 254 176 071 84 000000000000 --- ---<--|:|------ | --- | | ========= | Statement: -----|Command|----- ========= This means that a statement is made up of at least one command, but may be followed by more if a colon is used to separate each from the other. Before any commands are discussed I would like to fully explain procedures and their uses, and also the FRACTOL environment commands. PROCEDURES ---------- A procedure is basically a way of separating your program into smaller parts to aid readability and debugging methods. It does this by forcing you to put each part of your program in a separate area, and not one massively long listing. In FRACTOL, procedures are numbered rather than named, and 0 to 254 is possible. It is important to stress that each number has a specific use, and so you must be careful about which one you are going to use. To help explain this here is a flowchart which shows which procedures FRAC calls, and at what time it calls them. Remember that when a procedure is called, each line is executed (starting with the one with the lowest number) in sequence, one after another until the end of the procedure is reached or the return command (see later) is encountered. (The goto command may also have been used to alter the order of execution). Firstly when any FRAC adventure is started, procedure zero is called. This is extremely useful if you wish to have a title page or some kind of introduction which is separate from the main adventure. On entering the `Main loop`, procedure 253 - the recurrent list is called. The usual function of this is to display the current location description using the print command, and then add 1 to the turn counter, but of course you may put anything you like here. After procedure 253 has finished executing, control returns to FRAC where it will take input from the player and convert whatever is typed into verbs, words, objects, characters and unknowns, and then process this for object and character references (if defined) and also multiple command entry (if this is found to be true, FRAC will automatically repeat the line until all the individual commands have been entered). The next thing FRAC does might sound a little strange until you understand the reasoning behind it. FRAC will jump to the procedure number given by the player`s current location. E.g. if the player is currently at location 26, procedure 26 will be executed. Procedures 1 to 252 are called local lists because they are directly linked to the location they have the same number as, and so represent commands local to that area. To give an example, say there was a statue at location 3, and no others anywhere else in the adventure; you would wish commands such as `examine statue` and `hit statue` to only work when the player is at location 3. This can be done under the present system by simply placing the instructions which handle such events within procedure 3, they will then only be executed at the relevant time (i.e. when the player is at location 3). [Continued after diagram]. ------- |Start| ------- | -------------------------------------------------------------------- |Initialisation - all variables set to zero, all flags set to false| -------------------------------------------------------------------- | ------------------------------------------ |Procedure 0 - the introduction is called| ------------------------------------------ ---------------------------------| | ---------------------------------------------- | |Procedure 253 - the recurrent list is called| | ---------------------------------------------- | | | -------------------------------- | |Move all Non Player Characters| | -------------------------------- | | | -------------------------- | |Accept input from player| | -------------------------- | | | --------------------------------------------------------------------- | |Jump to the procedure number of the players location - a local list| | | E.g. if the player was at location 4, procedure 4 would be called | | --------------------------------------------------------------------- | | | / \ | ---------------------------- | |Was an IF command found to| YES | |be true in the procedure |---------------------- | |just called? | | | ---------------------------- | | \ / NO | | | | | --------------------------------------------------------------- | | |Procedure 254 - general list is called to handle general case| | | --------------------------------------------------------------- | | | | | |------------------------------------ | / \ | NO ------------------------------ --------------------|Is the player location zero?| ------------------------------ \ / YES | ------ |Stop| ------ Once execution of this procedure has been finished, FRAC will check to see if any IF statements just executed were true by testing flag zero (see flags). If flag zero is false (i.e. none were found to be true) then procedure 254 - the general list is called to consider the general case. This removes the need to have `get` and `drop` instructions at every single location in the adventure, since they can now simply be placed once in the general list. You should find writing adventures using this system far simpler and more effective than using other existing methods. FRACTOL EDITOR COMMANDS ----------------------- While you are in FRACTOL there are a number of commands specifically designed to manipulate lines and procedures. To get a full list of these simply press the help key, although do not forget that if you wish to edit a previously typed line you must use the `history buffer` discussed earlier. The first command we shall examine is list (or l). This lists all the lines in the procedure you are currently pointing to. It may be followed by the parameter startline which will start the listing at a line specified by you. E.g. LIST (will list the whole procedure) LIST 10 (will list all the lines following and including 10) LIST 150 (will list all the lines following and including 150) You may also enter a second parameter endline which will specify the line at which the listing should stop. E.g. LIST 26 46 (will list lines between 26 and 46 inclusive) The delete (or del or d) function erases a line in the current procedure, from memory. E.g. DELETE 8 (will delete line 8) Again you may specify an endline, in which case the entire range is deleted. DELETE 16 90 (will delete lines 16 to 90 inclusive) The erase command erases all the lines in the specified procedure. E.g. ERASE 1 (will erase procedure 1) A range may be specified by adding another parameter called endline. ERASE 0 4 (will erase procedures 0 and 4 inclusive) The copy command requires two parameters: the source, and the destination procedure. E.g. COPY 49 52 (will copy procedure 49 to procedure 52, erasing anything that was previously stored at procedure 52). The move command is similar to copy in that it requires two parameters, but this time once the source procedure has been copied it is erased. E.g. MOVE 10 254 (will move procedure 10 to procedure 254 - erasing anything that was previously there, and then procedure 10 will be erased). Renumber (or r) is one of the most useful commands if you are a tidy person. It renumbers all the lines in the current procedure using your parameters, and then automatically corrects all GOTO`s so that they still point to the same line. It requires two number: the startline and the gap. The startline simply specifies what line the first renumbered line will become. The gap parameter specifies how many numbers will be in between each line. E.g. if the following program was renumbered using R 10 3 it would look like the one below. BEFORE 30 CLS 35 PRINT "HELLO" 40 GOTO 35 AFTER 10 CLS 13 PRINT "HELLO" 16 GOTO 13 Lock (or p) changes the current procedure. It has just one parameter: the new procedure number. E.g. LOCK 12 (will make the current procedure number 12). The HOLD command simply toggles display hold on/off. When display hold is on, the current procedure will be relisted every time you press return - allowing you to see the new listing as you enter a new line. This in no way effects FRACTOL`s execution, and is merely there for your preference. HELP (or H) displays a complete list of the above commands, along with a short description and the parameters you must use when entering them. EXIT (or E) simply returns you to the main menu (escape also does this). While inside FRACTOL there are a number of variables you can influence. A complete list is given below. OBJLOC (1 TO 254) : This affects an object`s location. For example, if you set OBJLOC(5) to 10 then object 5 would be moved to location 10. CHARSTATUS (1 TO 254): This allows you to check or set a characters status. E.g. if you set CHARSTATUS(3) to 47, character 3 would now have a status of 47. CHARLOC (0 TO 254) : CHARLOC allows you to alter a characters location. Charloc zero represents the player`s location, while charlocs 1 to 254 represent characters 1 to 154. VAR (0 TO 254) : VAR stands for variable. This area is not used by FRAC and is completely left to the users own uses. Each storage area can hold a single integer. X,Y and Z : These three have a special use in FRACTOL (see the IF command), but can be treated as a storage location for a single integer. OBJDEF (1 TO 254,1 TO 8): This allows you to test and modify any object definition. For example, OBJDEF(12,1) would access object 12`s first definition. CHARDEF (1 TO 254,1 TO 8):This allows you to test and modify any character definition. For example, CHARDEF(16,2) would access character 16`s second definition. FLAG (0 TO 254) : Flags are different from the variables discussed so far. Flags do not store integer values, but must be set to one of two states: true or false. When trying to understand flags, it is best to imagine a little man with a signalling flag in his hand. All 255 of the little men start with their flags pointing towards the ground (false). But you can make them hold up their flags by setting them to true; they will remain in this state until set to false again. Now that we have discussed how the language works and also the commands which manipulate it, we must now examine the commands themselves. This will be done mainly through the use of syntax diagrams, although text descriptions will also be presented. There now follows the complete syntax diagram for a command. ============ Command: -----| IF |----- | ============ | | ============ | |--| LET |--| | ============ | | ------------ | |--| CLS |--| | ------------ | | ============ | |--| WRITE |--| | ============ | | ============ | |--| PRINT |--| | ============ | | ============ | |--| GRAPHIC |--| | ============ | | ============ | |--| MUSIC |--| | ============ | | ============ | |--| PROCEDURE|--| | ============ | | ============ | |--| REMARK |--| | ============ | | ------------ | |--| READLINE |--| | ------------ | | ============ | |--| FOR |--| | ============ | | ============ | |--| GOTO |--| | ============ | | ------------ | |--| RETURN |--| | ------------ | | ------------ | |--| NEXT |--| | ------------ | | ============ | |--| LOAD |--| | ============ | | ============ | |--| SAVE |--| | ============ | | ============ | |--| TAB |--| | ============ | | | | ------------ | |--| NORMAL |--| | ------------ | | ------------ | |--| BOLD |--| | ------------ | | ------------ | |--| ITALIC |--| | ------------ | | ------------ | |--|UNDERLINED|--| | ------------ | | ------------ | |--| INVERSE |--| | ------------ | | ------------ | |--| RESTART |--| ------------ You can see that we have not yet defined very many commands fully, since most require their own syntax diagrams (signified by double lines - meaning that their definitions must be found elsewhere). Before the syntax of any of the commands is discussed, I must first define things which all commands use, such as expressions and conditions. An expression is one of the most important structures in FRAC. Its syntax is as follows: ====================== Expression: ----------| CONSTANT |---------- | ====================== | | ====================== | |----| VARIABLE |----| | ====================== | | ====================== | |----|BRACKETED EXPRESSION|----| ====================== ------<------ ---| ==========| ====================== --- Bracketed Expression:--|(|--|OPERATOR|---| CONSTANT |---|)|-- --- |========== | ====================== ||--- | | ====================== || | |-| VARIABLE |-|| | | ====================== || | | ====================== || | |-|BRACKETED EXPRESSION|-|| | ====================== | | | --------------------->----------------- ------------ ====================== Variable: -------| OBJLOC |---|BRACKETED EXPRESSION|------------ | | ------------ | ====================== | | | ------------ | | | |-|CHARSTATUS|-| | | | ------------ | | | | ------------ | | | |-| CHARLOC |-| | | | ------------ | | | | ------------ | | | |-| VAR |-| | | | ------------ | | | ------------ | | |-| X |------------------------------------| | | ------------ | | | ------------ | | |-| Y |------------------------------------| | | ------------ | | | ------------ | | |-| Z |------------------------------------| | ------------ | | --------- --- ============ --- ============ --- | |--|OBJDEF |---|(|-|EXPRESSION|-|,|-|EXPRESSION|-|)|-- | --------- | --- ============ --- ============ --- | --------- | |--|CHARDEF|-| --------- Relational: ------- ================== --- ------ ================== -|INPUT|--|BRKT. EXPRESSION|---|=|------|VERB|------|BRKT. EXPRESSION|- |-------| ==================| --- || ------ | ==================| | ---- | | || ------ | | |-|IN|--| | ---- ||---|WORD|----| | | ---- |-|<>|-|| ------ | | | ---- | -------- | | | |---|OBJECT|--| | | | -------- | | | | ----------- | | | |-|CHARACTER|-| | | ----------- | | | | ------ ====================== --- ------ | |---|FLAG|---|BRACKETED EXPRESSION|---|=|---|TRUE|--------------------| | ------ ====================== --- | ------ | | | | ------- | | | |-|FALSE|--| | | ------- | | | | ========== ========== ============ | |---|VARIABLE|---|RELATION|---|EXPRESSION|----------------------------| ========== ========== ============ --- ====== --- String: --|"|--|TEXT|--|"| --- ====== --- --- =========== ----- =========== --- Condition: ---|(|--|CONDITION|---|AND|---|CONDITION|--|)|---- | --- =========== | ----- | =========== --- | | | ----- | | | |-|OR |-| | | ----- | | | | ============ | -----------------|RELATIONAL|-------->---------- ============ ---- Relational: ---|= |--- | ---- | | ---- | |-|<>|-| | ---- | | ---- | |-|<=|-| | ---- | | ---- | |-|>=|-| ---- There now follows a complete list of commands, along with the syntax diagram and an informative description. ---- =========== ------ =========== IF: --|IF|--|CONDITION|--|THEN|--|STATEMENT| ---- =========== ------ =========== The IF command is one of the most (if not the most) important commands in FRACTOL. It is the only command that allows statements to be executed if certain specified conditions are met. If the condition is found to be true, then the statement following the `then` is executed, otherwise it is ignored. The only restriction is that the statement may not contain another IF command i.e. you cannot `nest if`s`. Take a look at the syntax table to see how they are formed. You will notice that a condition may contain another condition. This means that theoretically you may have an infinite amount of conditions - all inside each other, but this of course is not possible in practice. Here are some example conditions - study the syntax diagrams for each type as you progress, as this will give you a much better understanding of them. EXAMPLE 1 (X=2 OR X=3) | CONDITION / | \ (CONDITION OR CONDITION) | | RELATIONAL RELATIONAL / | \ / | \ VARIABLE RELATION EXPRESSION VARIABLE RELATION EXPRESSION | | | | | | X = 2 X = 3 EXAMPLE 2 ((X=2 OR X=4) AND Y=1) | CONDITION / | \ (CONDITION AND CONDITION) | | CONDITION RELATION / | \ / | \ (CONDITION OR CONDITION) VARIABLE RELATION EXPRESSION | | | | | RELATIONAL RELATIONAL Y = 1 / | \ / | \ VARIABLE RELATION EXPRESSION VARIABLE RELATION EXPRESSION | | | | | | X = 2 X = 4 A condition must always have what is known as a boolean operator. This decides under what circumstances the condition will be true. The `OR` operator will produce the following results: (CONDITION1 OR CONDITION2) RESULT FALSE FALSE FALSE FALSE TRUE TRUE TRUE FALSE TRUE TRUE TRUE TRUE (i.e. if condition1 is false or condition2 is false, the result will be false). (CONDITION1 AND CONDITION2) RESULT FALSE FALSE FALSE FALSE TRUE FALSE TRUE FALSE FALSE TRUE TRUE TRUE (i.e. if condition1 is false and condition2 is false, the result will be false). For example the following condition will only be true if X is one or two, and Y is one - otherwise it is false. You should notice that any single condition can be built up of any number of other conditions, which are placed either side of the boolean operator. ((X=1 OR X=2) AND Y=1) So far the conditions we have looked at have only contained variables. Conditions may also contain tests on flags. For example: (FLAG(1)=TRUE AND FLAG(20)=FALSE) Another variation is the input variable, although this is not really a variable in the sense that the others are, being `read` only. Input is used to examine what the player has typed at the keyboard. The format is: INPUT(1) = VERB(1) | | |------- | | | | CLASS CLASS NUMBER | WORD NUMBER (word used in the sense of a word and not the variable word). For example, if diamond was an object, frodo a character, take a verb and from a word, the following input would be interpreted as below: take diamond from frodo verb(1) object(1) word(1) character(1) Input number: [1] [2] [3] [4] So the condition: (((INPUT(1)=VERB(1) AND INPUT(2)=OBJECT(1)) AND INPUT(3)=WORD(3)) AND INPUT(4)=CHARACTER(1)) would be true. While the condition: (INPUT(1)=VERB(4)) would be false, since input(1) is not verb 4, but verb 1. But what if we wanted to have a general case which allowed you `take` any object from any character (which is what the above condition is testing for). Normally if we wanted to do this we would have to have a line for every single object and character in the game - a monstrous task. To get around this, FRAC allows you to have a general input. E.g. (((INPUT(1)=VERB(1) AND INPUT(2)=OBJECT(X)) AND INPUT(3)=WORD(3)) AND INPUT(4)=CHARACTER(Y)) The variables X and Y will take on the values of the object and character that were actually input. You can then use this value to reference the thing that was entered - so only one line would be needed! This saves vast amounts of typing and is where the power of FRACTOL lies. This flexibility allows you to create your own command formats, although experimentation is recommended before complex structures are attempted. Please examine the tutorial adventure `Escape from desert island` for a host of example IF statements. ----- ------ ====================== --- ------ LET: --|LET|--|FLAG|--|BRACKETED EXPRESSION|--|=|---|TRUE|--- ----- |------ ====================== --- | ------ | | | ------- | | |-|FALSE|-| | ------- | | ========== --- ----- ============ | |--|VARIABLE|--|=|---|RND|---|EXPRESSION|------| ========== --- | ----- | ============ --------- The LET command assigns a variable to a value, or a flag to true or false. If the word is placed before the expression then a number is picked randomly within the range 1 to the value of the expression. For example, enter the following program at location zero: 10 LET VAR(0)=RND(100) 20 PRINT "VALUE=",VAR(0) 30 GOTO 10 and play the adventure. Press Control-C to return to the main menu. One peculiarity that is not inherent in any other languages, is the fact that you must place brackets around an expression if it has more than one term. E.g. LET VAR(0)=(VAR(0)+1) Whereas in BASIC you would type: LET VAR(0)=VAR(0)+1 ----- CLS: ---|CLS|--- ----- This command stands for clear screen, and it does just that. The print position is moved to the top left hand corner of the screen. --- ----------------------|,|--------------------- ------- | ========== --- | WRITE: ---|WRITE|------|VARIABLE|--------------------------------- | ------- | | ========== | | ------- | | ------------- =================== | |-|PRINT|-| |---|DESCRIPTION|------|BRAKT. EXPRESSION|-- ------- | | ------------- | =================== | | | --------- | | | |-|OBJNAME|------- | | | --------- | | | | ---------- | | | |-|CHARNAME|------ | | ---------- | | -------- | |-|STRING|---------------------------------- -------- This displays text, variables, descriptions, object names or character names to the screen. A comma is used to separate different types. For example: WRITE "You scored:",VAR(0)," points." WRITE "You take the ",OBJNAME(X) WRITE DESCRIPTION(12) WRITE DESCRIPTION(CHARLOC(0)) WRITE CHARNAME(VAR(1)),"greets you heartily." PRINT: This is exactly the same as write except a carriage return is executed after printing the text. --------- ============ GRAPHIC: ---|GRAPHIC|---|EXPRESSION|--- --------- ============ The expression should evaluate to a number between 0 and 15, otherwise it will be ignored. This will simply display the graphic with the specified number. ------- ============ MUSIC: ---|MUSIC|---|EXPRESSION|--- ------- ============ The expression should evaluate to a number between 1 and 6, otherwise it will be ignored. The relevant music will be loaded into memory and played. ----------- ============ PROCEDURE:---|PROCEDURE|---|EXPRESSION|---- | ----------- | ============ | ------ | |---|PROC|----| ------ This will execute the specified procedure (must be between 0 and 254 or will be ignored). Control will then return to immediately after this command (if there are more commands on the same line, these will be executed before the next line is examined). Note: If any variables are altered in the procedure you called, they will remain changed when you return. -------- ======== REMARK: ---|REMARK|---|STRING|---- | -------- | ======== | ----- | |--|REM|---| ----- This command has no effect, it merely allows you to annotate your listings. ------ ============ GOTO: ---|GOTO|---|EXPRESSION|--- ------ ============ Goto changes the order of execution. The specified line number is `jumped` to - execution will continue there. FOR: ----- ----- =================== --- ============ ---- ============ --|FOR|-|VAR|-|BRAKT. EXPRESSION|-|=|-|EXPRESSION|--|TO|--|EXPRESSION|- ----- ----- =================== --- ============ |----| ============ | | -------- |DOWNTO| -------- The for command allows you to repeat sections of your program a specified number of times. The variable you have chosen will start at the first value you have specified, and then be incremented by one (or decremented by one if you used downto) each time the section is repeated, until the value is equal to the second expression. For example the following program would have the effect: 10 FOR VAR(1)=2 TO 6 20 PRINT VAR(1) 30 NEXT EFFECT: 2 3 4 5 6 Or using downto: 10 FOR VAR(1)=8 DOWNTO 3 20 PRINT VAR(1) 30 NEXT EFFECT: 8 7 6 5 4 3 The next command is used to mark off the end of the section you wish to see repeated - all lines inside this area are then repeated. You may also `nest` for loops - i.e. you may place one loop inside the other. FRAC supports this for up to eight levels (eight loops inside each other). Here is an example: 10 FOR VAR(1)=1 TO 10 20 FOR VAR(2)=1 TO 12 30 LET VAR(3)=(VAR(1)*VAR(2)) 40 PRINT VAR(1)," * ",VAR(2),"=",VAR(3) 50 NEXT 60 PRINT "" 70 NEXT This will display all the multiplication tables between 1 and 10, with a gap in between each (the PRINT "" does this). I would suggest typing this out and trying it if you have never used loops before. ---------- READLINE: ---|READLINE|--- | ---------- | | ------ | |---|READ|---| ------ This simply accepts input from the player. You may then examine what was typed using IF statements, as discussed earlier. -------- RETURN: ---|RETURN|--- | -------- | | ----- | |--|RET|---| ----- Return forces the computer to return to the procedure which called it. (This happens automatically when there are no more lines to execute, or no lines in the procedure). If the PROCEDURE command was used to call this procedure, FRACTOL will return to directly after this command. If PROCEDURE was not used it means that FRAC itself must have called it, and so it will return there so that the next stage may begin. ------ NEXT: ---|NEXT|--- ------ Next forces the computer to increment or decrement the variable declared in the for statement, and then return to the line immediately after the for instruction. If you use this without declaring a for, you will get the runtime error "NEXT WITHOUT FOR". ------ ============ SAVE: ---|SAVE|---|EXPRESSION|--- ------ ============ This saves the current game position to disk. All variables are written, and also the positions of characters etc. You may store up to six game positions on one disk, and hence the expression you give must evaluate to a number between 1 and 6 inclusive. ------ ============ LOAD: ---|LOAD|---|EXPRESSION|--- ------ ============ This restores a previously saved game position. The expression must evaluate to between 1 and 6, or the command will be ignored. ----- ============ --- ============ TAB: ---|TAB|---|EXPRESSION|---|,|---|EXPRESSION|--- ----- ============ --- ============ This simply moves the cursor to the specified co-ordinates. The first expression represents magnitude in the X plane, and the second magnitude in the Y. The commands NORMAL, BOLD, ITALIC, UNDERLINED, and INVERSE just change the way in which any text is printed, and are really self-explanatory. Consequently they will not be examined. They require no parameters. --------- RESTART: ---|RESTART|--- --------- RESTART sets all variables back to their initial start values. You may use this command if the player wishes to begin the adventure from scratch. This concludes the USER MANUAL. THE EVALUATION ============== Here I will attempt to discuss FRAC (now that it is complete) assuming the role of a neutral, as this will allow me to accentuate its limitations in an open manner - something which is essential if this document is to be worthwhile. Usability: For my own part I feel the usability of FRAC is one of its better features - a view which has been emphasized by those who I have chosen to share the development stages with. The only proof I personally needed was when Peter, a complete non-programmer and general techno retard, was able to write several short adventures with only a two minute verbal introduction and a few late at night,`What do you want? I want to go to bed!` question and answer sessions. (I had not written the user manual at this time). The only flaw I can see in its usability is that FRACTOL may be a bit difficult if left only with the manual, and no possibility of the benefit of a direct line to the author (although I would be happy to answer any queries by post). This is a problem which cannot easily be overcome - an entire book could be written merely describing the fundamentals of programming in a BASIC type language. If you do have difficulty I suggest you perhaps play around with BASIC for a while - only the elementary principles need to be grasped - before moving onto FRACTOL (which should prove easier than any BASIC implementation). Reliability: Despite one bug which took an absolute age to track down (due to its nature) I have been blessed by having only encountered several `thought provoking` mess ups. Thankfully all of these have been removed and in its present state FRAC is as bug-proof as any program can claim to be. Due to time restrictions my documented testing of FRAC is rather pathetic, which is a pity because a lot of time went into making sure it did what it was supposed to. The only real way to judge reliability is to use the software for yourself over an extended period, as this is not possible in the case of an independent marker you will have to take my word for it. Effectiveness: I do not really know what to say about this. FRAC is effective in that it has achieved its original aim i.e. to produce a comprehensive adventure creation utility. To judge for myself how effective FRAC is, I feel it is capable of creating any form of text adventure without noticeable restriction, and so should score highly on any `effectiveness scale`. But of course there are limitations..... Limitations: I personally think the main limitation of FRAC is in its graphic handling capabilities which are pretty rudimentary. Another drawback is its text output speed for formatted text - but after seeing the speed of another adventure creators text output I concluded that FRAC was at least the same speed as it, so perhaps this is not really that much of a problem - although there is certainly room for improvement. The obvious limitations are where the amount of things are concerned (e.g. the amount of characters, the amount of objects etc). This can be partially overcome by the alteration of specific constants - but I would recommend you leaving these as they are since there may be difficulty accessing elements greater than 254 from FRACTOL (it can only handle single constants upto a value of 254 - another limitation I would like to see banished). There is also an inefficiency when entering lines in FRACTOL (sometimes you have to wait about ten seconds). This is caused by the (feeble) bubble sort routine which I would like to scrap and replace with a much improved version - it would move a line directly to where it is supposed to go and then reshuffle all of the lines after it. At the time I was only concerned with getting it working, but upon reflection this is a change I would definitely make if given the opportunity. (I attribute this slip-up to the reading of too many text books on programming theory while I was writing FRAC - places where things like bubble sorts get rammed down your throat as `miracles of creation`). Provision for future development: Because of the highly structured form Pascal enforces upon you, it is extremely easy to bolt on additional pieces of code. Also since I made up commands in FRACTOL as I went along, the programming is easily modified to insert any new commands you might choose. As for Menu functions, this would be difficult since most of the menus are full already - but the creation of sub menus should allow you to make as many extra options as you like. I would consider the source code for FRAC highly portable (with the exception of music/graphic routines, and several procedures which handle files). Although it is quite easy to upgrade FRAC, text adventures are not exactly on `the pinnacle of human advancement and endeavour` and so this has a limited significance here. This concludes what I hope you find to be a fair evaluation of FRAC. THE END You also see a grape, a spanner and three packets of liquorice all- sorts. TECHNICAL REFERENCE MANUAL ========================== OVERALL PLAN ------------ The source code for FRAC is divided amongst 11 files: one main, and ten external. There are several reasons for this. Firstly the compiler I was using could not handle files anywhere near this large, and so the separation was inevitable. In this state it can be considered more readable, since all associated procedures are grouped together. Another advantage is that if only one part is being edited, for test purposes only this needs to be compiled - rather than recompiling the whole lot (a task which takes some twenty five minutes). There now follows a complete list of procedures with reference being made to which source file they belong to. --------------------- | Source File: FRAC | --------------------- Procedures for output handling Cls CursorOn CursorOff Normal Bold Italics Underlined Inverse WriteEntry PrintEntry WriteType Row Procedures for input handling ClearInput GetStringLen StringInput CharacterInput IntegerInput UpperCase Procedures for list processing ClearLines ClearInterpret ClearInterpretBuffer ClearLocs ClearVerbs ClearWords ClearExits ClearObjects ClearCharacters ClearList CalcFreeMem LocateEnd StoreEntry UpdateList EraseEntry CombineEntries Initialise ClearMem Procedures for Run-Time handling Randomize InterpretWord InterpretInput MoveCharacters BuildDescription LetsPlay SetStartLoc SetObjectText SetCharText SetMultiText Procedures for menu handling OptionsMenu TitlePage The Main Program ------------------------------------ | Source File: External - Descrips | ------------------------------------ Procedures for description handling CreateDescrip ViewDescrip KillDescrip AddToDescrip ListDescrip ExchangeDescrip UsedList ClearDescrip LocationMenu --------------------------------- | Source File: External - Exits | --------------------------------- Procedures for exit handling ClearExits GetVerbNumber PrintExits CreateExits ViewExits KillExits ListExits ExchangeExits AutoExits ClearAllExits --------------------------------- | Source File: External - Verbs | --------------------------------- Procedures for verb handling GetVerbNumber CreateVerb ViewVerb KillVerb ListVerbs ExchangeVerbs PageVerbs AddToVerb ClearAllVerbs VerbMenu --------------------------------- | Source File: External - Words | --------------------------------- Procedures for word handling GetWordNumber CreateWord ViewWord KillWord ListWords ExchangeWords PageWords AddToWord ClearAllWords WordMenu ----------------------------------- | Source File: External - Objects | ----------------------------------- Procedures for object handling GetWordNumber CreateObject ViewObject KillObject ExchangeObjects PageObjects SetObjDefs ClearAllObjects ObjectMenu -------------------------------------- | Source File: External - Characters | -------------------------------------- Procedures for character handling CreateCharacter ViewCharacter KillCharacter ExchangeCharacters PageCharacters SetCharDefs ClearAllCharacters CharacterMenu --------------------------------- | Source File: External - Files | --------------------------------- Procedures for file handling SaveList LoadList SaveGame LoadGame GetFileInfo Directory LoadFile SaveFile DeleteFile GraphicControl ModControl FileMenu ----------------------------------- | Source File: External - FRACTOL | ----------------------------------- Procedures for FRACTOL handling UpperCaseII AddToLine InterpretLine ScanString ScanVariable ScanBracketedExpression ScanExpression ScanRelational ScanCondition ScanCommand FixConstants DisplayErrorReport PrintLine SortLines DeleteLine DeleteRange GoFRACTOL -------------------------------------- | Source File: External - FRACTOLEXE | -------------------------------------- Procedures for FRACTOL execution handling ExecuteProc [function] EvaluateVariable [function] EvaluateBracketedExpression [function] EvaluateExpression [function] EvaluateRelational [function] EvaluateCondition DoLet DoLoadSaveGame ExecuteCommand ExecuteLine ---------------------------------------- | Source File: External - FRACRoutines | ---------------------------------------- 68000 Assembler Routines used by FRAC OpenLibs KillBorder CloseLibs DeleteFile1 DeleteFile2 DeleteFile3 DeleteFile4 DeleteFile5 DeleteFile6 DelFile LoadModule1 LoadModule2 LoadModule3 LoadModule4 LoadModule5 LoadModule6 StartMusic StopModule DisplayGraphic0 DisplayGraphic1 DisplayGraphic2 DisplayGraphic3 DisplayGraphic4 DisplayGraphic5 DisplayGraphic6 DisplayGraphic7 DisplayGraphic8 DisplayGraphic9 DisplayGraphic10 DisplayGraphic11 DisplayGraphic12 DisplayGraphic13 DisplayGraphic14 DisplayGraphic15 Display CheckBreak ClearBreak Protracker V1.1b PlayRoutine To describe how FRAC works the main systems will be discussed and justified. The Menus --------- Menus require very little programming but are very effective and promote a good standard of user-friendliness. In FRAC the menu text is simply written to the screen using writeln statements, and then the procedure CharacterInput is called to receive a single character from the keyboard and pass the result in the variable CharInput. A CASE statement is then used to check for all valid inputs - in this way ll invalid entries are ignored. This is repeated until the exit function within the menu is selected - this sets the boolean variable quit to true, which lets the repeat until loop know that it is time to stop repeating. Here is an example of how a menu is programmed: repeat cls; writeln (`E. EXIT`); CharacterInput; case CharInput of `E`,`e` : Quit := True; end; until (Quit); Here is a diagram to show how the menus of FRAC are linked together: -------- | MAIN | -------- / | \ ---------- ------ ------ -------- ----------- ------ --------- |LOCATION| |VERB| |WORD| |OBJECT| |CHARACTER| |FILE| |OPTIONS| ---------- ------ ------ -------- ----------- ------ --------- | / \ ----------- --------------------------------- |EXIT MENU| |GRAPHIC CONTROL||MODULE CONTROL| ----------- --------------------------------- TEXT STORAGE ------------ The storage of text for FRAC was perhaps one of the most important problems which needed to be overcome, since text handling is essentially the basis of the entire project. The first method which sprang to mind was to declare static arrays of 255 characters for each location description, verb, word, object and character name. But there are two major disadvantages in doing this (although it would be relatively easy to program). Firstly in the case of location descriptions, 255 characters would not be enough in most instances, and there is no way of expanding upon this original number once the program is in execution. Secondly, to set aside 255 characters for a single verb would be absurd, since most only run to several letters. The obvious solution would be to cut down on the number of characters allocated - but then this would be too limiting in cases where many characters are needed. To solve both of these problems I have developed a system of dynamic allocation which I refer to as the datalist storage system. Rather than allocate fixed length arrays for each type, a memory pool is allocated which is shared by all of the text handlers. The advantages of such a system are numerous: the memory is allocated where needed, so while verbs etc. may only take up a small proportion of store (with no waste), large text descriptions are still possible for things like location descriptions. To manage this a workspace of some 80000 bytes is allocated as an array of characters (called the datalist). But other variables are also needed to store where in this datalist the text is actually stored. To take the example of a verb, it must have two integers: one to store its offset from character zero (i.e. its address) - called VerbAdr, and one to store its length since rogue or terminating characters are not used - called VerbLen. Further, these variables must be allocated for all verbs, producing two arrays like so: VerbAdr : Array [1..Verbs] of integer; VerbLen : Array [1..Verbs] of integer; Here is an example datalist: 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 T A K E D R O P T H R O W (0) Therefore if verb one is TAKE, verb two is THROW and verb three is DROP, the variables would be set as follows: VerbAdr[1] = 0 VerbLen[1] = 4 VerbAdr[2] = 8 VerbLen[2] = 5 VerbAdr[3] = 4 VerbLen[3] = 4 Similarly if we also wished to store words in the datalist, we would need two arrays: WordAdr : Array [1..Words] of Integer; WordLen : Array [1..Words] of Integer; This structure needs to be repeated for all types of text which are stored in the datalist. The datalist itself is defined as: DataList : Array [0..SystemMem-1] of Char; During the initialisation period every element is set to character zero. So whenever a zero is encountered it represents the end of the datalist - so any text that is stored here must not have a zero in it. One of the major advantages of using a datalist is that the same set of routines can be used to manipulate the text (such as PrintEntry, EraseEntry and StoreEntry). The address and length is simply passed using the WriteAdr and StringLen integer variables respectively, and the routine does the rest. Adding text to the datalist is a very simple matter. Firstly the procedure LocateEnd is called to locate the end of the datalist (it does this by searching for the character zero and setting WriteAdr to point to it), and then GetStringLen is called to calculate the length of the text the user has entered - this is passed in the integer StringLen. Now the variables used to store the address and length of the text are loaded with the variables WriteAdr and StringLen. So if the text was a verb, the following lines would be executed: VerbAdr[x] := WriteAdr; VerbLen[x] := StringLen; StoreEntry; StoreEntry is then called to copy the text from the input buffer to the datalist. The input buffer is defined as: TextInput : Array [0..255] of Char; The procedure StringInput is called to accept input from the user and store it in the TextInput array. To remove text from the datalist the procedure EraseEntry is used. This uses the variables WriteAdr and StringLen to erase an area of memory within the datalist (by setting all characters within the range to the character zero). The variables used to store the address and length of the text should then be set to zero. So if you wished to erase a verb, the following lines would need to be executed: WriteAdr := VerbAdr[x]; StringLen := VerbLen[x]; EraseEntry; VerbAdr[x] := 0; VerbLen[x] := 0; The procedure EraseEntry is rather more complicated than you might at first think. After clearing the text from the datalist a pocket of zeros is left which needs to be removed if high efficiency is to be maintained, and the system to continue operating correctly. For example, if verb three (drop) from the earlier example is erased using EraseEntry, the datalist would appear as: 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 T A K E (0)(0)(0)(0) T H R O W (0) Obviously all characters after the erased text must be moved to cover up the new zeros. This is done by a call to UpdateList which completes this task. But this only solves half of the problem: since the text has been moved, all the pointers which point to text after the newly erased text must have the length of the erased text subtracted from their address pointer so that they continue pointing to the correct data. So after UpdateList the result is: 0 0 0 0 0 0 0 0 0 0 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 T A K E T H R O W (0)(0)(0)(0)(0) etc. VerbAdr[1] = 0 VerbLen[1] = 4 VerbAdr[2] = 4 VerbLen[2] = 4 [8 - 4] VerbAdr[3] = 0 VerbLen[3] = 0 Since a VerbAdr of zero is valid, VerbLen is used to test if a verb actually exists - as a verb length of zero is not possible. This concludes my examination of the datalist. File Handling ------------- There are three file structures which FRAC uses to store data on disk. The first is a standard adventure data file - used to store adventures which the user is currently working on, and hence can be re- loaded back into the editor. One of the first things that should be noted is that the save routine is what I like to refer to as `intelligent`. That is, it checks the data before saving it to see which range actually needs to be stored. For example, if only verbs 1 to 9 are allocated, it is hardly worth wasting disk space by saving all 255 of them. This is not really a compression algorithm, but merely a very simply piece of programming which in practice saves vast amounts of memory. FRAC does this by setting the integer FirstVerb to the lowest allocated verb, setting the integer LastVerb to the highest allocated verb, then saving everything within this range. Note: FirstVerb and LastVerb are also saved so that the load routine will know what range it must load. This is done for all types of stored array so variables like: FirstExit, LastExit, FirstLoc, LastLoc, FirstWord, LastWord are necessary. Here is the file structure for a data file which is actually split into two separate files - one to store characters and one to store integers. |FRAC|40 characters set aside for file name/description|Datalist|0| This is hard to represent on paper since the datalist is of variable length. Every FRAC data file begins with the four characters `FRAC`. Then after the datalist a zero character is written. This is saved as FRACx.file, where x may be any number between 1 and 6. The second file which is used to store integers is called FRACx.data, where x is any number between 1 and 6. |FirstLoc|LastLoc|LocAdr/LocLen| |FirstVerb|LastVerb|VerbAdr/VerbLen| |FirstWord|LastWord|WordAdr/WordLen| |FirstObject|LastObject|ObjAdr/ObjLen/ObjLoc/ObjStat|ObjWord| |FirstCharacter|LastCharacter|CharAdr/CharLen/CharLoc/CharStatus /CharListAdr/CharListLen/CharStat|CharWord| |FirstLine|LastLine|LineAdr/LineLen/LineProc/LineNum| |StartLoc| |WordTrapping| |VisibleExits| |VisibleObjs| |VisibleChars| |DesForm| |ObjTextAdr| |ObjTextLen| |CharTextAdr| |CharTextLen| |MultiTextAdr| |MultiTextLen| |FirstExit|LastExit|LocVerb/LocExit|AutoVerb/AutoExit| The second file structure FRAC uses is an adventure file which cannot be loaded back into the main editor - but can be used to make a bootable game disk. It has exactly the same structure as a FRAC data file, but instead of the letters `FRAC`, the letters `GAME` are written at the start of the file. The last file structure is saved as FRACx.game and stores a game position (i.e. the position and status of all relevant variables so that if the file is re-loaded, the player may continue from exactly where he left off). x represents a number between 1 and 6. Here is the file structure (designated as a file of integer): |PlayerLoc|ObjLoc/ObjStat|CharLoc/CharStatus/CharListPtr/CharStat |Variable|Flag|X|Y|Z| Although flags are stored in memory as integers, they are saved to an integer file by making true take on the value one, and false the value zero. Another thing that should be noted is that the datalist is encrypted as it is saved. This prevents people simply using the DOS command type to examine all text in the adventure, and thereby gaining knowledge through improper means. The encryption method is very simple: every character that is written first undergoes an `xor 206` operation i.e. the character is exclusively or`ed with the integer 206 to produce a completely different character. E.g. The ascii code for character `A` is 65. After an xor 206 operation (which inverts the bits specified by the supplied integer), 65 becomes 143, thus the text is made unreadable. To return the text to its normal state we simply xor it with 206 again as it is loaded in, and it returns to its start value. So if 143 was loaded and then xor`ed with 206, it would become 65 again. If you have a calculator which supports binary, try it! This completes my examination of FRAC file handling; it has examined and described the functions of these procedures: SaveList (saves the datalist), LoadList (loads the datalist), SaveGame (saves current game position), and LoadGame (which loads a previous game position). But before proceeding I would like to mention the method used by the procedure called directory, which displays the name of all the FRAC files on a disk, or `empty` if there is not a file there. This simply goes through all 6 files and opens them one by one - if the file was successfully opened it means that it exists, and the description is displayed before the file is closed. If the file could not be opened it means that no FRAC file exists for this position, and so the word `empty` is displayed. FRACTOL ------- At this point you should have at least a basic understanding of the programming language FRACTOL, and possess some knowledge of its commands. The first thing that will be discussed is the way in which FRACTOL recognises things that are entered into it (- or the lexical analysis stage). Rather than compare every single character with all the possible characters producing massively inefficient code, I have developed a system which allows just a single integer to represent an entire word. It does this by adding all ascii codes it comes across to a total (which start at zero) until a non letter character is encountered. This total is then compared using a case statement and if a match is found the word is interpreted and stored. There are slight problems when interpreting words using this method. Firstly `clashes` are possible i.e. two different words can generate the same number e.g. C A T (67) (65) (84) TOTAL = 216 S A D (83) (65) (68) TOTAL = 216 To reduce the probability of this happening, each ascii code has twice its value added to it before being added to the total. (But even if clashes do occur due to a typing mistake it is easily rectified - as long as two FRACTOL definitions do not have values which clash: the computer would then not know which one is correct and consequently it would be interpreted incorrectly. As I have made sure every code is different, this is not a problem). Using this system everything that is not recognised is ignored, and also all spaces are removed for further optimisation. Now I will examine how a FRACTOL command is stored. As a temporary store the arrays LineType and LineNumber are used to hold the type and number of the recognised word. They are as below: LineType : Array [0..255] of Char; LineNumber : Array [0..255] of Char; An integer called line output points to the array element currently being accessed, and is incremented by one every time a new word is added to this list. As mentioned earlier, the ascii code generated by the word is used to determine the type and number that is added to the list. The AddToLine procedure adds a word to the list, and has two parameters: the type and the number. Here is list of types and numbers that are generated by the following recognised words and symbols: TYPE [1] - COMMAND NUMBER SYMBOL ASCII CODE [1] IF 356 [2] LET 542 [3] CLS 535 [4] WRITE 859 [5] PRINT 878 [6] GRAPHIC 1087 [7] MUSIC 837 [8] PROCEDURE/PROC 1431/683 [9] REMARK/REM 975/533 [10] READLINE/READ 1229/636 [11] FOR 544 [12] GOTO 705 [13] RETURN/RET 1038/554 [14] NEXT 722 [15] LOAD 644 [16] SAVE 675 [17] TAB 496 [18] NORMAL 990 [19] BOLD 646 [20] ITALIC 943 [21] UNDERLINED 1560 [22] INVERSE 1149 [23] RESTART 1186 TYPE [2] - NUMERIC VARIABLES [1] OBJDEF 922 [2] OBJLOC 949 [3] CHARDEF 1056 [4] CHARSTATUS 1623 [5] CHARLOC 1083 [6] VAR 548 [7] X 264 [8] Y 267 [9] Z 270 TYPE [3] - KEYWORDS [1] UNDEFINED ---- [2] UNDEFINED ---- [3] THEN 684 [4] UNDEFINED ---- [5] INPUT/IN 884/380 [6] TO 405 [7] DOWNTO 1029 [8] RND 524 TYPE [4] - RELATIONAL SYMBOLS [1] = [2] < [3] > [4] <= [5] >= [6] <> TYPE [5] - OPERATIONAL SYMBOLS [1] + [2] - [3] * [4] / TYPE [6] - CONSTANT [Here the number represents the actual constant.] TYPE [7] - SYMBOLS [1] ( [2] ) [3] , [4] " TYPE [8] - TEXT VARIABLES [1] DESCRIPTION 1750 [2] OBJNAME 1085 [3] CHARNAME 1219 TYPE [9] - INPUT TYPES [1] VERB 672 [2] WORD 700 [3] OBJECT 962 [4] CHARACTER 1388 [5] UNKNOWN 1198 TYPE [10] - FLAGS [1] FLAG 635 TYPE [11] - FLAG ASSIGNMENT [1] TRUE 709 [2] FALSE 795 TYPE [12] - BOOLEAN OPERATORS [1] AND 490 [2] OR 404 TYPE [13] - EDITOR COMMANDS [1] EXIT/E 712/207 [2] LIST/L 716/228 [3] DELETE/DEL/D 939/502/204 [4] ERASE 805 [5] COPY 719 [6] MOVE 691 [7] RENUMBER/R 1298/246 [8] LOCK/P 669/240 [9] HOLD 658 [10] HELP/H 674/216 TYPE [14] - COMMAND SEPARATOR [1] : As the type and number are invariably integers, you may be wondering why I go through the hassle of converting them into characters (I have declared the storage areas LineType and LineNumber as characters). This was done to make it easy to copy interpreted FRACTOL lines into the datalist, because although you may not think so, a line in FRACTOL is treated as text in its converted form - allowing it to be easily manipulated using already existing procedures. The LineAdr and LineLen store the address and length of the line respectively. Once the lexical analysis stage has been completed (the commands are now stored in compressed format in the arrays LineType and LineNumber), the syntax analysis stage begins. The procedures used in this are: ScanString, ScanVariable, ScanBracketedExpression, ScanExpression, ScanRelational, ScanCondition and ScanCommand. These procedures make extensive use of recursive techniques and can therefore handle any length of input. If anything is not correct at this stage, DisplayErrorReport is called to inform the user, and the line is ignored. If the line is syntactically correct, it is now ready to be entered into the datalist, but first it is necessary to correct the integers by adding one. This is because a zero is not allowed in the datalist for the simple reason that it signifies the end of the list, and a zero in the middle of a line would cause everything after it to be treated as empty. To solve this problem the procedure fix constants is called to make sure all integers are in the range 1 to 255. StoreEntry is then used to copy the line into the datalist. A line also possesses two more variables: LineProc (to remember which procedure the line belongs) and LineNum (to store the line number of the line). These are defined as below: LineProc : Array [0..Lines-1] of Integer; LineNum : Array [0..Lines-1] of Integer; The procedure PrintEntry is used to display a line in FRACTOL - a large case statement is executed for every symbol to display its expanded form. The procedure SortLines does a form of bubble sort on all of the lines currently in memory. This is necessary to make sure every new line that is entered goes in the correct place within the list. Lines which belong to a low procedure number are placed nearer to the beginning of the list. During the sort, lines are exchanges by swapping over LineAdr, LineLen, LineProc, and LineNum values - although no text needs to be moved, making it quite a speedy operation. DeleteLine makes use of the EraseEntry procedure, and consequently is very short and efficient. DeleteRange simply goes through all of the lines in memory and if one matches the deletion condition i.e. same procedure, and line number within range, it is deleted using the DeleteLine procedure described above. This concludes my examination into procedures which allow lines to be interpreted by FRACTOL, and then how they are stored. Next I will examine how FRACTOL takes these tokenised characters and executes them. The first thing that should be noted is that all procedures dealing with the execution of FRACTOL instructions are placed inside the procedure ExecuteProc. This is so that one procedure in FRACTOL may call another in FRACTOL, simply by recursively calling ExecuteProc, and the internal variables such as LinePC (which stores the number of the current line) will be preserved. Other control variables inside ExecuteProc are Pointer which points to the symbol that is currently being accessed in the datalist (the integer represents the character`s offset from position zero); Ret - a boolean variable which becomes true when a return instruction is encountered, forcing FRACTOL to leave the procedure; VarNum (an array of 1 to 8 integer) which holds the variable to be effected by a loop; Dest (defined as an array of 1 to 8 integer) which stores the destination number which a loop must achieve before it is terminated; and PCJump (an array of 1 to 8 integer) which stores the line number that a loop must return to when its respective NEXT is encountered. LoopPtr points to the next free loop that may be used. It starts on 1 and if a loop is encountered when it is equal to 8, the `too many fors` error is issued. The basis of execution of a FRACTOL instruction is that any expression will ultimately evaluate into a single integer value. Because of this it is easy to see that a recursive routine could be used to solve any expression. To make it easier and more efficient I have used functions as opposed to procedures, and the following are used in evaluating expressions: EvaluateVariable, EvaluateBracketedExpression, EvaluateExpression, and EvaluateRelational. The basis of the function EvaluateCondition is that any condition will ultimately evaluate into a single state of true or false, based on the result of a boolean operator applied on two other conditions. Again a recursive function is used to evaluate any possibility: EvauateCondition calls itself as many times as necessary, until the condition is broken down into its base components. The main control routine is ExecuteLine which calls ExecuteCommand for every command within this instruction. There is also a library of 68000 Assembler routines which can be called through the main program, and are included to handle music and graphics etc. - things that would be impossible or impractical using Pascal. AN EXPLANATION OF THE CONSTANTS AND VARIABLES FRAC USES ======================================================= CONSTANTS --------- SystemMem: This constant represents how many bytes should be reserved for the text pool (i.e. the datalist). It is initially set to 80000, but an expanded machine could easily manage 180000 bytes. Locations: This constant tells FRAC how many locations to reserve and access. This can be set as high as you like but remember that there are only 254 procedures in FRACTOL (cannot be changed) and so there seems little point in raising it above this figure. The default is 255 (location zero included). Verbs: This constant decides how many verbs FRAC will allocate. It starts at 254. Words: This simply tells FRAC how many words to reserve. It also starts at 254. Exits: This constant dictates how many visible exits will be allocated at each location. It starts at eight. Autos: The constant tells FRAC how many AutoExit definitions to remember. It starts at 16 which should be more than enough. Objects: This decides how many object to cater for. It starts at 254. ObjectStats: This states how many personal definitions each object will have. Its default is 8. Characters: This decides how many characters FRAC should reserve. CharacterStats: This states how many personal definitions each character will have. It starts at 8. LineLength: This tells FRAC how many characters can fit width ways across the screen, and is primarily used by the text formatting routines. It starts at 64 (the width of an AmigaDOS screen) but alteration of this variable makes it possible for FRAC to run on any number of different operating systems. MaxInput: This decides how many words FRAC will take from the player before the buffer is deemed full. It starts at 128 which is plenty. Lines: This constant tells FRAC how many FRACTOL line to allow for. Its initial value is 1000 which is certainly enough for most adventures. Here only variables which have not already been described will be examined - a complete list is shown at the start of the listing. LocVerb : Array [0..Locations-1,1..Exits] of integer; LocExit : Array [0..Locations-1,1..Exits] of integer; These two arrays hold the data for every visible exit in the entire game, and also where the player should be relocated on moving through this exit. LocVerb holds the number of the verb which when typed will take the player through the exit. It is a two dimensional array so accessing LocVerb[12,2] will give you the verb number of the second exit at location twelve. LocExit simply gives the number of the location the player should be moved to if this exit it activated - it is accessed in exactly the same way as LocVerb. Files : Array [1..6] of boolean; This is used by the directory to store which files actually exist - if the file exists its boolean variable is set to true. Before any file is loaded this is checked to see if the file actually exists, and also before any file is saved the user is prompted if this variable is found to be true (i.e. `file already exists! Overwrite?`). CharListAdr : Array [1..Characters] of integer; CharListLen : Array [1..Characters] of integer; CharListPtr : Array [1..Characters] of integer; The variables CharListAdr and CharListLen are used to store the position and length of all the characters` movement lists in the game - as this is also stored as text in the datalist to aid manipulation. CharListPtr is a pointer which points to the current character in a characters movement list which is being considered. One is needed for every single character because they may all have different length movement lists. The other variables are self-explanatory or have already been considered. TESTING FRACTOL =============== To test FRACTOL it is necessary to examine each of the commands in terms of its effect. This is made easier by the highly structured form that parameters are used i.e. to test all forms of condition, only one would need to be examined since all conditions, however complex, are made up of other conditions only. Firstly commands which affect objects will be examined. For this example object #1 is defined as below: NAME: BOX LOCATION: 1 DEFINITION #1: 10 DEFINITION #2: 20 DEFINITION #3: 30 DEFINITION #4: 40 DEFINITION #5: 50 DEFINITION #6: 60 DEFINITION #7: 70 DEFINITION #8: 80 At procedure zero the following program is entered: 10 LET VAR(0)=1 20 PRINT "Test Name=",OBJNAME(VAR(0)) 30 PRINT "Location=",OBJLOC(VAR(0)) 40 PRINT "" 50 FOR VAR(1)=1 TO 8 60 PRINT "Definition ",VAR(1),"=",OBJDEF(VAR(0),VAR(1)) 70 NEXT When the program was run the result was as follows: Test Name=box Location=1 Definition 1=10 Definition 2=20 Definition 3=30 Definition 4=40 Definition 5=50 Definition 6=60 Definition 7=70 Definition 8=80 Next commands which affect characters will be examined. For this example character #1 is defined as below: NAME: OLD MAN.MAN LOCATION: 1 STATUS: 2 MOVEMENT LIST: DEFINITION #1: 1 DEFINITION #2: 2 DEFINITION #3: 3 DEFINITION #4: 4 DEFINITION #5: 5 DEFINITION #6: 6 DEFINITION #7: 7 DEFINITION #8: 8 At procedure zero the following program is entered: 10 LET VAR(0)=1 20 PRINT "Test Name=",CHARNAME(VAR(0)) 30 PRINT "Location=",CHARLOC(VAR(0)) 40 PRINT "Status=",CHARSTATUS(VAR(0)) 50 PRINT "" 60 FOR VAR(1)=1 TO 8 70 PRINT "Definition ",VAR(1),"=",CHARDEF(VAR(0),VAR(1)) 80 NEXT When the program was run the result was as follows: Test Name=old man Location=1 Status=2 Definition 1=1 Definition 2=2 Definition 3=3 Definition 4=4 Definition 5=5 Definition 6=6 Definition 7=7 Definition 8=8 The following program was designed to test numeric conditions: 10 FOR VAR(0)=1 TO 5 20 IF (VAR(0)>0 AND VAR(0)<2) THEN PRINT "ONE OKAY!" 30 IF VAR(0)=2 THEN PRINT "TWO OKAY!" 40 IF ((VAR(0)<4 AND VAR(0)>2) AND VAR(0)=3) THEN PRINT "THREE OKAY!" 50 IF VAR(0)>=4 THEN PRINT "FOUR OR FIVE OKAY!" 60 IF VAR(0)>4 THEN PRINT "DEFINITELY FIVE!" 70 NEXT The correct result was obtained, shown below: ONE OKAY! TWO OKAY! THREE OKAY! FOUR OR FIVE OKAY! FOUR OR FIVE OKAY! DEFINITELY FIVE! The following program was designed to test boolean conditions: 10 LET FLAG(1)=TRUE 20 LET FLAG(2)=FALSE 30 IF (FLAG(1)=TRUE AND FLAG(2)=FALSE) THEN LET FLAG(2)=TRUE 40 IF (FLAG(1)=TRUE AND FLAG(2)=TRUE) THEN LET FLAG(1)=FALSE 50 IF FLAG(1)=FALSE THEN LET FLAG(2)=FALSE 60 IF (FLAG(1)=FALSE AND FLAG(2)=FALSE) THEN PRINT "TEST SUCCESSFUL" Upon entering at procedure zero and executing, the following result was obtained: TEST SUCCESSFUL To test `input` it was necessary to create the following: VERB #1 = BREAK.HIT OBJECT #1 = VASE CHARACTER #1 = DWARF The following program was entered at procedure 254: 10 IF (INPUT(1)=VERB(1) AND INPUT(2)=OBJECT(1)) THEN PRINT "The vase is too solid for you to break." 20 IF (INPUT(1)=VERB(1) AND INPUT(2)=CHARACTER(1)) THEN PRINT "The dwarf grunts and says `get lost!`." 30 IF (INPUT(1)=VERB(1) AND INPUT(2)=UNKNOWN) THEN PRINT "I do not understand what I should hit." The program was then tested using option seven on the main menu - PLAY ADVENTURE, and here is a run time listing of the result: You can also see a vase. dwarf is here. >hit dwarf The dwarf grunts and says `get lost!`. >break vase The vase is too solid for you to break. >hit vase The vase is too solid for you to break. >hit the moon I do not understand what I should hit. As you can see, input works correctly in all forms of interaction. This concludes the documented testing of the language FRACTOL. Presented below is a hex dump of the example adventure `Escape from desert island`. As you can see the text that should be readable has been completely hidden by the encryption algorithm. 0000: 46524143 7C455343 41504520 46524F4D FRAC|ESCAPE FROM 0010: 20444553 45525420 49534C41 4E443C20 DESERT ISLAND< 0020: 20202020 20202020 20202020 97A1BBEE .... 0030: AFBCABEE BDBAAFA0 AAA7A0A9 EEA1A0EE ................ 0040: AFEEB9AF BCA3EEBA BCA1BEA7 ADAFA2EE ................ 0050: ACABAFAD A6E0EE9A A1EEBAA6 ABEEBDA1 ................ 0060: BBBAA6EE BAA6ABEE BEA2AFAD A7AAEEBD ................ 0070: ABAFEEA6 AFBCAAA2 B7EEBCA7 BEBEA2AB ................ 0080: BDEEBBA0 AAABBCEE BAA6ABEE ACABAFA3 ................ 0090: BDEEA1A8 EEBAA6AB EEA6A1BA EEBDBBA0 ................ 00A0: E0EE8FEE A8ABB9EE B7AFBCAA BDEEAFB9 ................ 00B0: AFB7EEAF EEA2AFBC A9ABEEA9 BCABB7EE ................ 00C0: BCA1ADA5 EEACAFBD A5BDEEA7 A0EEBAA6 ................ 00D0: ABEEBDBB A3A3ABBC EEBCAFB7 BDE0EE9A ................ 00E0: A1EEBAA6 ABEEB9AB BDBAEEBA A6ABBCAB ................ 00F0: EEAFBEBE ABAFBCBD EEBAA1EE ACABEEAF ................ 0100: EEADAFB8 ABE2EEBD A6ABA2BA ABBCABAA ................ 0110: EEA7A0EE BAA6ABEE BCA1ADA5 A8AFADAB ................ 0120: E2EEB9A6 A7A2ABEE BAA6ABEE A0A1BCBA ................ 0130: A6EEA6A1 A2AABDEE A2BBBDA6 EEA9BCAB ................ 0140: ABA0EEB8 ABA9ABBA AFBAA7A1 A0E097A1 ................ 0150: BBEEBDBA AFA0AAEE A7A0EEBA A6ABEEBD ................ 0160: A6AFAAA1 B9EEA1A8 EEAFEEA2 AFBCA9AB ................ 0170: EEBCA1AD A5A8AFAD ABE0EE8F EEBDA3AF ................ 0180: A2A2EEBC A7B8ABBC EEBCBBA0 BDEEA8BC ................ 0190: A1A3EEBA A6ABEEA8 A1BCABBD BABDEEE6 ................ 01A0: B9A6A7AD A6EEA2A7 ABEEA0A1 BCBAA6E7 ................ 01B0: EEA7A0BA A1EEBAA6 ABEEBDAB AFE2EEBE ................ 01C0: AFBDBDA7 A0A9EEA7 A0EEA8BC A1A0BAEE ................ 01D0: A1A8EEBF BBA7BAAB EEAFEEA2 AFBCA9AB ................ 01E0: EEADAFB8 ABEEB9A6 A7ADA6EE A6AFBDEE ................ 01F0: BDA1A3AB A6A1B9EE A8A1BBA0 AAEEA7BA ................ 0200: BDEEB9AF B7EEA7A0 BAA1EEBA A6ABEEBC ................ 0210: A1ADA5A8 AFADABE0 97A1BBEE AFBCABEE ................ 0220: A7A0EEAF EEB8ABBC B7EEAAAF BCA5EEAD ................ 0230: AFB8ABEE B9A6A7AD A6EEBDAB ABA3BDEE ................ 0240: BAA1EEBA BBA0A0AB A2EEA7BA BDEEB9AF ................ 0250: B7EEAAAB ABBEEEA7 A0BAA1EE BAA6ABEE ................ 0260: A3A1BBA0 BAAFA7A0 BDE2EEAC BBBAEEB7 ................ 0270: A1BBEEAD A1BBA2AA EEA0A1BA EEBEBCA1 ................ 0280: A9BCABBD BDEEA8BB BCBAA6AB BCEEB9A7 ................ 0290: BAA6A1BB BAEEAFEE A2A7A9A6 BAE0EE9A ................ 02A0: A6ABEEAB A0BABCAF A0ADABEE A2A7ABBD ................ 02B0: EEBAA1EE BAA6ABEE ABAFBDBA E097A1BB ................ 02C0: EEBDBAAF A0AAEEAF A3A7AABD BAEEA2AF ................ 02D0: BCA9ABEE BABCA1BE A7ADAFA2 EEBABCAB ................ 02E0: ABBDE0EE 8BB6A7BA BDEEA2AB AFAAEEAB ................ 02F0: AFBDBAEE AFA0AAEE BDA1BBBA A6E08081 ................ 0300: 9C9A86E0 808B8F9D 9AE08B9D 819B9A86 ................ 0310: E09D998B 9D9AE099 82818185 E0828B80 ................ 0320: 9A8B9C9A 8F858BE0 898B9A8A 9C819E8B ................ 0330: 968F8387 808BE08B 968F8382 8789869A ................ 0340: 8780988B 809A819C 97E0878D 9B9A9C81 ................ 0350: 8D859C87 988B9CE0 998F9A8B 9C83879C ................ 0360: 9C819C99 8F828587 8089EE9D 9A878D85 ................ 0370: E0998F82 85878089 8C9B9C80 878089EE ................ 0380: 9D9A878D 85E08C9B 9C808780 89868F9A ................ 0390: 8D868B9A CFCFC9CF CDCBC9CF C8CCC9CC ................ 03A0: CACFC7CF C9CFC8C5 C9CCC2CF CDCBC9CF ................ 03B0: C8CDC9CC CACFC7CC C9CFC8CC C9CCC9CC ................ 03C0: CDCDCFCB C9CA87BA EEA7BDEE B8ABBCB7 ................ 03D0: EEA2AFBC A9ABEEAF A0AAEEA6 ABAFB8B7 ................ 03E0: EEAFA0AA EEAFBEBE ABAFBCBD EEBAA1EE ................ 03F0: A6AFB8AB EEACABAB A0EEA6AB BCABEEBD ................ 0400: A7A0ADAB EEBAA6AB EE8BAFBC BAA6EEA7 ................ 0410: BABDABA2 A8EEB9AF BDEEA8A1 BCA3ABAA ................ 0420: E0EE9AA6 ABEEA2AB BABAABBC BDEEAE8B ................ 0430: 83AEEEAF BCABEEBD ADBCAFBE ABAAEEA7 ................ 0440: A0BAA1EE BAA6ABEE BDA7AAAB E0CFC9CA ................ 0450: CFCFC9CF CDCBC9CF C8CCC9CC CACFC7CF ................ 0460: C9CFC8C6 C9CCC2CF CDCBC9CF C8CDC9CC ................ 0470: CACFC7CC C9CFC8CC C9CCC9CC CDCDCFCB ................ 0480: C9CA97A1 BBAEBCAB EEA4A1A5 A7A0A9EE ................ 0490: BCA7A9A6 BAF1EE87 A8EE80AB B9BAA1A0 ................ 04A0: BDEEA8A7 BCBDBAEE A2AFB9EE BDBAAFBA ................ 04B0: ABBDEEBA A6AFBAEE ABB8ABBC B7EEA1AC ................ 04C0: A4ABADBA EEADA1A0 BAA7A0BB ABBDEEAF ................ 04D0: BAEEBCAB BDBAEEA1 BCEEB9A7 BAA6EEBB ................ 04E0: A0A7A8A1 BCA3EEB8 ABA2A1AD A7BAB7EE ................ 04F0: BBA0A2AB BDBDEEAF ADBAABAA EEBBBEA1 ................ 0500: A0EEACB7 EEAFEEBC ABBDBBA2 BAAFA0BA ................ 0510: EEA8A1BC ADABE2EE A3B7EEA8 A7BCBDBA ................ 0520: EEA2AFB9 EEA7BDEE 9EA6B7BD A7ADBDEE ................ 0530: BDBABBAA ABA0BABD EEADAFA0 AEBAEEA2 ................ 0540: A7A8BAEE BCA1ADA5 BDE0C9CA CFCFC9CF ................ 0550: CDCBC9CF C8CCC9CC CACFC7CF C9CFC8C5 ................ 0560: C9CCC2CF CDCBC9CF C8CDC9CC CACFC7CC ................ 0570: C9CFC8CD C9CCC9CC CDCDCFCB C9CA9AA6 ................ 0580: ABEEB9AF BAABBCEE A8A2A1B9 BDEEBDA2 ................ 0590: A1B9A2B7 EEA1B8AB BCEEAFEE BDAFA0AA ................ 05A0: B7EEACAB AAE2EEAC BCA1A5AB A0EEA7A0 ................ 05B0: EEA3AFA0 B7EEBEA2 AFADABBD EEACB7EE ................ 05C0: BDA3AFA2 A2EEBCA1 ADA5BDE0 C9CACFCF ................ 05D0: C9CFCDCB C9CFC8CC C9CCCACF C7CFC9CF ................ 05E0: C8C6C9CC C2CFCDCB C9CFC8CD C9CCCACF ................ 05F0: C7CCC9CF C8CAC9CC C9CCCDCD CFCBC9CA ................ 0600: 8FA2BCA7 A9A6BAEE B9A7BDAB EEA9BBB7 ................ 0610: EEADBBBA EEBAA6AB EEADBCAF ADA5BDE2 ................ 0620: EEA7A8EE B7A1BBEE B9AFA0A0 AFEEBDBE ................ 0630: ABA0AAEE B7A1BBBC EEA2A7A8 ABEEADA1 ................ 0640: A2A2ABAD BAA7A0A9 EEBAA6AB EEBCA7B8 ................ 0650: ABBCBDEE A1A8EEBA A6A7BDEE B9A1BCA2 ................ 0660: AAEEBAA6 AFBAAEBD EEBBBEBA A1EEB7A1 ................ 0670: BBE2EEAC BBBAEEBC A7A9A6BA EEA0A1B9 ................ 0680: EEB9ABAE B8ABEEA9 A1BAEEAF A0EEAFAA ................ 0690: B8ABA0BA BBBCABEE BAA1EEBD A1A2B8AB ................ 06A0: E0CFC9CA CFCFCCC8 C9CFC8CF C9CCCAC8 ................ 06B0: CCCBC9CF C8CFC9CC CDCDCFCA C6CFC9CF ................ 06C0: CCCBC9CF C8CFC9CC C9CCCFCC CCC8C9CF ................ 06D0: C8CFC9CC CACFCCCB C9CFC8CF C9CCCFCF ................ 06E0: CDCBC9CF C8CCC9CC CACFC7CF C9CFC8C8 ................ 06F0: C9CCCDCD CFCCCCC8 C9CFC8CF C9CCCACF ................ 0700: C8CFC0CF CFC6C830 CFCFCDCB C9CFC8CC .......0........ 0710: C9CCCACF C7CFC9CF C8C5C9CC CDCDCFCB ................ 0720: C9CA9AA6 ABBCABAE BDEEA0A1 BAEEA3BB ................ 0730: ADA6EEBA A1EEBAAB A2A2E0CF C9CACFCF ................ 0740: CDCBC9CF C8CCC9CC CACFC7CB CDCDCFCB ................ 0750: C9CA9DA1 BCBCB7E2 EEBAA6AF BAEEADA1 ................ 0760: A3A3AFA0 AAEEA7BD EEA0A1BA EEBBA0AA ................ 0770: ABBCBDBA A1A1AAE0 C9CA97A1 BBEEBDBA ................ 0780: AFA0AAEE AFA3A7AA BDBAEEA2 AFBCA9AB ................ 0790: EEBABCA1 BEA7ADAF A2EEBABC ABABBDE0 ................ 07A0: EE8BB6A7 BABDEEA2 ABAFAAEE B9ABBDBA ................ 07B0: EEAFA0AA EEBDA1BB BAA6E0CF CFCDCBC9 ................ 07C0: CFC8CCC9 CCCAC8C7 CFC9CFC8 C4C9CCCD ................ 07D0: CDCFC2C8 9FCFC5CC C8C9CFC8 CCC9CCCA ................ 07E0: CFC8CCCD C8C831CF C0CFCFCC CCC9CFCC ......1......... 07F0: C8C9CFC8 CCC9CCC9 CCCACFC8 31CDCDCF ............1... 0800: CBC9CA9A A6ABEEC9 CAC9CDC6 CCC9CFCC ................ 0810: C8C9CFC8 CCC9CCC9 CCC9CDC9 CAE0CFC9 ................ 0820: CACFCBC9 CA97A1BB EEAFBCAB EEADBBBC ................ 0830: BCABA0BA A2B7EEAD AFBCBCB7 A7A0A9F4 ................ 0840: CFC9CACF CFC9CFC9 CFCDCBC9 CFC8CCC9 ................ 0850: CCCACFC7 CFC9CFC8 C6C9CCC2 CFCDCBC9 ................ 0860: CFC8CDC9 CCCACFC7 CDC9CFCC C9C9CCC9 ................ 0870: CCC2CFCC CCC9CFCC C9C9CCCA CFCCCBC9 ................ 0880: CFC8CFC9 CCC9CCCD CDCFCBC9 CA97A1BB ................ 0890: EEBAAFA5 ABEEBAA6 ABEECFC9 CAC9CDC6 ................ 08A0: CCC9CFCC C9C9CCC9 CDC9CAE0 CFC9CAC0 ................ 08B0: CFCFCCCC CCC9CFCC C9C9CCCA CFC831CF ..............1. 08C0: CFC9CFC9 CFCDCBC9 CFC8CCC9 CCCACFC7 ................ 08D0: CFC9CFC8 C7C9CCC2 CFCDCBC9 CFC8CDC9 ................ 08E0: CCCACFC7 CDC9CFCC C9C9CCC9 CCC2CFCC ................ 08F0: CCC9CFCC C9C9CCCA CFC831C9 CCCDCDCF ..........1..... 0900: CBC9CA97 A1BBEEAA BCA1BEEE BAA6ABEE ................ 0910: CFC9CAC9 CDC6CCC9 CFCCC9C9 CCC9CDC9 ................ 0920: CAE0CFC9 CAC0CFCF CCCCCCC9 CFCCC9C9 ................ 0930: CCCACFCC CBC9CFC8 CFC9CC8D 868F9C9C ................ 0940: 8B8AEE9D 9A9B839E E09D9A9B 839ECFCF ................ 0950: CCC8C9CF C8CDC9CC CAC8C8CF CDCDCFCC ................ 0960: CCC8C9CF C8CDC9CC CACFC9CF CCC8C9CF ................ 0970: C8CDC9CC CBCFC8CC C9CCCFCF C9CFC9CF ................ 0980: C9CFCDCB C9CFC8CC C9CCCACF C7CFC9CF ................ 0990: C8C2C9CC C2CFCDCB C9CFC8CD C9CCCACF ................ 09A0: C7CDC9CF C8CDC9CC C9CCC2CF CCCCC9CF ................ 09B0: C8CDC9CC CACFC831 C9CCC2CF CCCCC9CF .......1........ 09C0: C8CCC9CC CACFC831 C9CCCDCD CFCBC9CA .......1........ 09D0: 9AA6ABEE BCAFB7BD EEA1A8EE BAA6ABEE ................ 09E0: BDBBA0EE BCABA8A2 ABADBAEE A1A8A8EE ................ 09F0: BAA6ABEE A3A7BCBC A1BCEEBD ADA1BCAD ................ 0A00: A6A7A0A9 EEBAA6AB EEBDBAA7 ADA5E2EE ................ 0A10: B9A6A7AD A6EEAFBD EEAFEEBC ABBDBBA2 ................ 0A20: BAE2EEAC BBBCA0BD EEBDA2A1 B9A2B7EE ................ 0A30: AFB9AFB7 E0CFC9CA C0CFCFCC CCCCC9CF ................ 0A40: C8CDC9CC CACFC8CF C0CFCFCC CCCCC9CF ................ 0A50: C8CAC9CC CACFC831 C0CFCFCC CCC8C9CF .......1........ 0A60: C8CDC9CC CACFC8CC CFCFC9CF C9CFCCCB ................ 0A70: C9CFC8CF C9CCCACF C8CAC2CF CCCCC9CF ................ 0A80: C8CBC9CC CACFC8CF C9CCC2CF CCCCC9CF ................ 0A90: C8CAC9CC CACFC831 C9CCCDCD CFCCCCCC .......1........ 0AA0: C9CFC8CB C9CCCACF C8CACFCF C9CFC9CF ................ 0AB0: CCCBC9CF C8CFC9CC CACFC8CA C2CFCCCC ................ 0AC0: C9CFC8CB C9CCCACF C8CAC9CC C2CFCCCC ................ 0AD0: C9CFC8CA C9CCCAC8 C831C9CC CDCDCFCC .........1...... 0AE0: CCCCC9CF C8CBC9CC CACFC8CF CFCFCCC8 ................ 0AF0: C9CFC8CD C9CCCACF C8C8CDCD CFCBC9CA ................ 0B00: 9AA6ABEE BDBAA7AD A5EEB9A7 BAA6ABBC ................ 0B10: BDEEAFA0 AAEEA9A1 ABBDEEA1 BBBAE0CF ................ 0B20: C9CAC0CF CFCCCCCC C9CFC8C8 C9CCCACF ................ 0B30: CCCCC9CF C8CAC9CC C0CFCFCC CCCCC9CF ................ 0B40: C8CAC9CC CACFC8CF 8C818F9A 9A9C8B8B ................ 0B50: E09A9C8B 8B9DCFC6 C8CBCFCF C9CFCDCB ................ 0B60: C9CFC8CC C9CCCACF C7CFC9CF C8C5C9CC ................ 0B70: C2CFCDCB C9CFC8CD C9CCCACF C7CCC9CF ................ 0B80: C8CAC9CC C9CCCDCD CFCBC9CA 9AA6ABEE ................ 0B90: BABCABAB BDEEA6AB BCABEEAF BCABEEBF ................ 0BA0: BBA7BAAB EEA2AFBC A9ABE2EE ACABA7A0 ................ 0BB0: A9EEB9A6 AFBAEEAF EEA6ABA2 BEA8BBA2 ................ 0BC0: EEBEABBC BDA1A0EE B9A1BBA2 AAEEADAF ................ 0BD0: A2A2EEAE ACA1AFBA EEBDA7B4 ABAAAEE0 ................ 0BE0: C9CACFCF C9CFC9CF C9CFCDCB C9CFC8CC ................ 0BF0: C9CCCACF C7CFC9CF C8C3C9CC C2CFCDCB ................ 0C00: C9CFC8CD C9CCCACF C7CCC9CF C8CAC9CC ................ 0C10: C9CCC2CF CCCCC9CF C8CBC9CC CACFC831 ...............1 0C20: C9CCC2CF CCCCC9CF C8C9C9CC CACFC8CF ................ 0C30: C9CCCDCD CFCBC9CA 97A1BBEE ADBBBAEE ................ 0C40: AAA1B9A0 EEAFEEA3 ABAAA7BB A3EEBDA7 ................ 0C50: B4ABAAEE BABCABAB EEAFA0AA EEBDA6AF ................ 0C60: BEABEEA7 BAEEA7A0 BAA1EEAF EEBCA1BB ................ 0C70: A9A6A2B7 EEA3AFAA ABEEACA1 AFBAE0CF ................ 0C80: C9CAC0CF CFCCCCCC C9CFC8C9 C9CCCACF ................ 0C90: CCCBC9CF C8CFC9CC CFCFC9CF CDCBC9CF ................ 0CA0: C8CCC9CC CACFC7CF C9CFC8CA C9CCC2CF ................ 0CB0: CCCCC9CF C8C9C9CC CACFC831 C9CCCDCD ...........1.... 0CC0: CFCBC9CA 97A1BBEE BDAFA7A2 EEBDA1BB ................ 0CD0: BAA6EEA7 A0EEB7A1 BBBCEEBA BCABABEE ................ 0CE0: ACA1AFBA E0EE99AB A2A2EEAA A1A0ABEF ................ 0CF0: EE97A1BB EEA6AFB8 ABEEABBD ADAFBEAB ................ 0D00: AAEEA8BC A1A3EEBA A6ABEEAA ABBDABBC ................ 0D10: BAEEA7BD A2AFA0AA E0CFC9CA C0CFCFC4 ................ 0D20: C0CFCFCC CCCBC9CF C8CFC9CC CACFC8CF ................ 0D30: CFCFC9CF CDCBC9CF C8CCC9CC CACFC7CF ................ 0D40: C9CFC8CA C9CCC2CF CCCCC9CF C8C9C9CC ................ 0D50: CACFC831 C9CCCDCD CFCBC9CA 97A1BBEE ...1............ 0D60: BDAFA7A2 EEBDA1BB BAA6EEA7 A0EEB7A1 ................ 0D70: BBBCEEBA BCABABEE ACA1AFBA E0EE99AB ................ 0D80: A2A2EEAA A1A0ABEF EE97A1BB EEA6AFB8 ................ 0D90: ABEEABBD ADAFBEAB AAEEA8BC A1A3EEBA ................ 0DA0: A6ABEEAA ABBDABBC BAEEA7BD A2AFA0AA ................ 0DB0: E0CFC9CA C0CFCFC4 C0CFCFCC CCCBC9CF ................ 0DC0: C8CFC9CC CACFC8CF 00 ......... Below is a hex dump of the data file for the example adventure `Escape from desert island`. As you can see the `intelligent` save has removed the massive groupings of just zero bytes that would usually occur. 0000: 00000001 00000005 00000000 00000122 ..............." 0010: 00000122 000000CA 000001EC 000000A5 ..."............ 0020: 00000291 00000041 0000074E 00000041 .......A...N...A 0030: 00000001 0000000C 000002D2 00000007 ................ 0040: 000002D9 00000006 000002DF 00000007 ................ 0050: 000002E6 00000006 000002EC 00000006 ................ 0060: 000002F2 00000005 000002F7 00000008 ................ 0070: 000002FF 00000004 00000314 0000000B ................ 0080: 00000303 0000000C 0000030F 00000005 ................ 0090: 0000031F 00000003 00000001 00000003 ................ 00A0: 00000322 00000004 00000326 0000000B ...".......&.... 00B0: 00000B20 0000000A 00000001 00000006 ... ............ 00C0: 00000331 00000006 00000004 00000000 ...1............ 00D0: 00000000 00000000 00000000 00000000 ................ 00E0: 00000000 00000000 00000000 00000337 ...............7 00F0: 00000015 000000FE 00000000 00000000 ................ 0100: 00000000 00000000 00000000 00000000 ................ 0110: 00000000 00000000 0000034C 00000015 ...........L.... 0120: 00000000 00000000 00000000 00000000 ................ 0130: 00000000 00000000 00000000 00000000 ................ 0140: 00000000 00000361 00000007 00000000 .......a........ 0150: 00000000 00000000 00000000 00000000 ................ 0160: 00000000 00000000 00000000 00000000 ................ 0170: 0000090F 00000013 00000000 00000000 ................ 0180: 00000000 00000000 00000000 00000000 ................ 0190: 00000000 00000000 00000000 00000B1C ................ 01A0: 00000004 00000000 00000000 00000000 ................ 01B0: 00000000 00000000 00000000 00000000 ................ 01C0: 00000000 00000000 00000000 00000000 ................ 01D0: 00000000 00000000 00000000 00000000 ................ 01E0: 00000000 00000000 00000001 00000001 ................ 01F0: 00000000 00000000 00000000 00000000 ................ 0200: 00000000 00000000 00000000 00000000 ................ 0210: 00000000 00000000 00000000 00000000 ................ 0220: 00000000 00000000 00000000 00000000 ................ 0230: 00000000 00000000 00000000 00000000 ................ 0240: 00000000 00000000 00000000 00000019 ................ 0250: 00000368 000000BC 00000001 0000000A ...h............ 0260: 00000424 000000FC 00000001 00000014 ...$............ 0270: 00000C6C 00000098 00000001 0000001E ...l............ 0280: 00000520 00000082 00000002 0000000A ... ............ 0290: 000005A2 000000D6 00000002 00000014 ................ 02A0: 00000D04 00000098 00000002 0000001E ................ 02B0: 00000BB6 000000B6 00000004 0000000A ................ 02C0: 00000B2E 00000088 00000004 00000014 ................ 02D0: 00000B2A 00000004 00000005 0000000A ...*............ 02E0: 00000A3C 00000042 000000FD 0000000A ...<...B........ 02F0: 00000A7E 00000042 000000FD 00000014 ...~...B........ 0300: 00000678 00000026 000000FD 0000001E ...x...&........ 0310: 0000069E 00000014 000000FD 00000028 ...............( 0320: 00000922 0000002C 000000FD 00000032 ..."...,.......2 0330: 00000AC0 0000005C 000000FD 0000003C .......\.......< 0340: 000006B2 0000002A 000000FE 0000000A .......*........ 0350: 000006DC 00000036 000000FE 00000014 .......6........ 0360: 0000078F 0000001A 000000FE 0000001E ................ 0370: 000007F5 00000022 000000FE 00000028 .......".......( 0380: 000007A9 00000012 000000FE 00000032 ...............2 0390: 000007BD 00000038 000000FE 0000003C .......8.......< 03A0: 000007BB 00000002 000000FE 00000046 ...............F 03B0: 00000817 0000007C 000000FE 00000050 .......|.......P 03C0: 00000893 0000007C 000000FE 0000005A .......|.......Z 03D0: 0000094E 000000EE 000000FE 00000064 ...N...........d 03E0: 00000712 0000003C 000000FE 0000006E .......<.......n 03F0: 00000001 00000000 00000000 00000001 ................ 0400: 00000001 00000001 00000000 00000000 ................ 0410: 00000000 00000000 00000000 00000000 ................ 0420: 00000001 00000006 00000004 00000002 ................ 0430: 00000001 00000005 00000000 00000000 ................ 0440: 00000000 00000000 00000000 00000000 ................ 0450: 00000000 00000000 00000000 00000000 ................ 0460: 00000000 00000000 00000002 00000001 ................ 0470: 00000004 00000003 00000001 00000004 ................ 0480: 00000006 00000003 00000000 00000000 ................ 0490: 00000000 00000000 00000000 00000000 ................ 04A0: 00000000 00000000 00000002 00000002 ................ 04B0: 00000000 00000000 00000000 00000000 ................ 04C0: 00000000 00000000 00000000 00000000 ................ 04D0: 00000000 00000000 00000000 00000000 ................ 04E0: 00000000 00000000 00000003 00000002 ................ 04F0: 00000002 00000005 00000000 00000000 ................ 0500: 00000000 00000000 00000000 00000000 ................ 0510: 00000000 00000000 00000000 00000000 ................ 0520: 00000000 00000000 00000004 00000004 ................ 0530: 00000003 00000001 00000000 00000000 ................ 0540: 00000000 00000000 00000000 00000000 ................ 0550: 00000000 00000000 00000000 00000000 ................ 0560: 00000000 00000000 00000000 00000000 ................ 0570: 00000000 00000000 00000000 00000000 ................ 0580: 00000000 00000000 00000000 00000000 ................ 0590: 00000000 00000000 00000000 00000000 ................ 05A0: 00000000 00000000 00000001 00000003 ................ 05B0: 00000002 00000004 00000000 00000000 ................ 05C0: 00000000 00000000 00000000 00000000 ................ 05D0: 00000000 00000000 00000000 00000000 ................ 05E0: 00000000 00000000 00000000 00000000 ................ 05F0: 00000000 00000000 00000000 00000000 ................ 0600: 00000000 00000000 00000000 00000000 ................ 0610: 00000000 00000000 00000000 00000000 ................ 0620: 00000000 00000000 ........ Here is sample output from the run-time control program, showing that the codes given earlier are actually interpreted correctly, and that the adventure is `playable`. The solution presented below sould prove beyond doubt that FRAC does in fact work, and I consider this to be the ultimate test. You are standing on a warm tropical beach. To the south the placid sea hardly ripples under the beams of the hot sun. A few yards away a large grey rock basks in the summer rays. To the west there appears to be a cave, sheltered in the rockface, while the north holds lush green vegetation. examine rock It is very large and heavy and appears to have been here since the earth itself was formed. The letters `EM` are scraped into one side. em Sorry, that command is not understood. west You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. examine river The water flows slowly over a sandy bed, broken in many places by small rocks. examine rocks There`s not much to tell. look You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. enter cave You are in a very dark cave which seems to tunnel its way deep into the mountains, but you could not progress further without a light. The entrance lies to the east. east You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. north You stand amidst large tropical trees. Exits lead east and south. You can also see a mirror. take mirror You take the mirror. inventory You are carrying a mirror, and a walking stick. south You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. light the stick using the mirror The rays of the sun reflect off the mirror scorching the stick which, as a result, burns slowly away. west You are in the cave. You can also see a hatchet. take hatchet You take the hatchet. inventory You are currently carrying a mirror, a burning stick, and a hatchet. east The stick withers and goes out. You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. drop stick You drop the stick. north You stand amidst large tropical trees. Exits lead east and south. cut tree using hatchet You cut down a medium sized tree and shape it into a roughly made boat. get boat You take the boat. south You stand in the shadow of a large rockface. A small river runs from the forests (which lie north) into the sea, passing in front of quite a large cave which has somehow found its way into the rockface. You also see a withered stick. east You are standing on a warm tropical beach. To the south the placid sea hardly ripples under the beams of the hot sun. A few yards away a large grey rock basks in the summer rays. To the west there appears to be a cave, sheltered in the rockface, while the north holds lush green vegetation. south You sail south in your tree boat. Well done! You have escaped from the desert island.