17 Bit Software 2: Collection B

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

/ 17 Bit Software 2: Collection B / 17Bit_Collection_B.iso / files / 1438.dms / in.adf / ADVENTURE / adt < prev next >

Wrap

Text File | 1978-02-11 | 25.4 KB | 556 lines

ADVENTURE WRITING TUTORIAL Copyright W.Jordan 1990 All Rights Reserved This article is public domain and may be freely copied and distributed, provided it is unaltered and if charged for, only a nominal copying fee is charged. INTRODUCTION This program is a tutorial in writing adventures games. It is specifically designed for people with little or no programming experience who would like to write their own adventure games. Whatever your age, this may be of assistance in creating your own games, whether they are for your own amusement, to be played by friends, or to be put on the public domain or eventually you go commercial! It contains many helpful tips and ideas, and hopefully will generate many ideas of your own. Hopefully, it will give people inspiration to write adventure games of their own! Many of the ideas in the article are the result of years of playing adventure games and writing them! HOW TO USE THIS TUTORIAL You may be happy just to browse through this. If you feel inclined to put some time into creating an adventure game, you will get the most from this tutorial by reading through it on different ocassions. Each time you will grasp points that were previously obscure to you. You may also gain some ideas just from reading sections that interest you. GENERAL This tutorial should be useful to you regardless of what programming language you use, though my background is in Basic. This tutorial presumes that you are confident in saving and loading a program. One of the beauties of programming is that you can save a program and return to it weeks or months later and modify it. As you become confident and experienced with the computing language you can gradually add enhancements to all your programs! An excellent way to gain ideas for your adventure games is to purchase and play games. There are also books available which contain solo games which play very much like a computer game. You might like to look at some of the public domain adventure games. To exploit the full power of the Amiga your game might contain IFF graphics, music, sounds(and perhaps voice), animated bobs and sprites, fancy menus and text presentation and a mouse driven interface. However, a good game need not contain all of these features. You need to learn to crawl before you can walk, and the more sophisticated features can be added later on. To write an adventure game with all the special effects can take a long time, you can still make a fun game with a lot less effort, even though it might be just for your friends. During the tutorial some basic commands will be mentioned. For full information on how to use these commands you will need to read the manual. There is a lot more to these commands than what will be mentioned here! I suggest to be both patient and persistent when developing a program. You will be surprised how complicated a simple program can become. You will probably be best off in the beginning not to be too ambitious. NOTES Hand written notes may prove to be helpful in writing your stories. Drawing a map may be particularly helpful. How much preplanning you wish to do is a matter of style. You may like to plan your adventure very carefully before you boot up your Amiga. You may prefer a much more ad hoc approach. Some people like to print out a listing of their program, so they examine it away from the computer. THEMES The theme for an adventure game is only limited by your imagination. An obvious theme is a medieval fantasy setting which is used in many D&D type role playing games. Other themes include a science fiction setting, a detective story, a spy story or whatever. You may like to use ideas from any book,movie or TV show that you like. You may like to try your hand at an educational type adventure story where the hero makes progress depending on his answers to specialised questions. Generally you will just have one main character in your story though you might like to have a party which includes several non playing characters which means that the player will control several game characters. Another idea (though more difficult) is to make the game a multi-player game. These could be within the same pary, or could be racing against each other. TEXT ADVENTURES About a decade ago there were very few graphics in text adventure games and most games consisted just of text. Some readers may be familiar with the old Scott Adams Adventure series of games. Despite these games being purely text they could nontheless be quite enjoyable. A text adventure is a game in which little or no graphics appear on the screen. In its purest form only text appears on the screen. Usually the user of the progran plays the role of a character in an adventure story. The text often describes what the character can see and hear and what is happening at the time. The player will have to make decisions on behalf of the character. Depending on what decisions are made, the story will branch in different directions. There may a chance element in the game. The original Scott Adams series allowed a player(the user) to move the story character by typing in such directional commands as N,S,E,W,UP and DOWN. Story items could be manipulated by commands such as GET,DROP,USE etc. and the player could perform other actions such as LOOK,TALK,OPEN etc. which did not always require an object. Whatever was typed in by the player led to a response by the computer. Sometimes the player progressed in the adventure, at other times not. The games contained many puzzles which the player could solve by logical deduction. As more and more obstacles were overcome the character progressed further and further into the story. STARTING OUT I highly recommend starting with something simple. You can always add to it later on. You will be surprised how complicated even a simple progam can be. When I first bougt my Amiga I was very keen to write a short program. Even though I knew very little about computing I wrote an adventure game on the first day I had my machine fully connected up. What is more the program was actually completed. But it did actually use only 3 commands! I used PRINT to make text appear on the screen. STOP to make the program stop after each paragraph of text. After each paragraph of text was displayed on the screen, the program would stop. The program would continue when the user typed in a GOTO command in direct mode(this was in AmigaBasic by the way). Getting the user to use direct mode was not really adequate! It would have been much more sensible to use the INPUT command to ask for the user(player) to type in information on the keyboard. However, the manual had a misprint in it and the INPUT command did not make any sense! It is quite possible to make a workable text adventure game with only 3 commands. PRINT,INPUT and ON GOTO. This is how. LABELS AND LINE NUMBERS Write your adventure story as a number of independent paragraphs. They will need some kind of identification, so precede each paragraph by a line number or label. Labels have the advantage that they can help you recognize what the paragraph is about while you are editing your story. (Of course, the PLAYER will never see the labels or linenumbers). They have the disadvantage that they cannot begin with a reserved word. PRINT Each line of text in a paragraph will need to be preceded by a ?(for PRINT) followed by a quotation mark. Do not make the paragraph so long that it will not fit onto a whole screen, otherwise the top of it will scroll off the top of the screen before you have a chance to read it! The paragraph will probably describe the location of the character, what the character can see and/or hear and an event that is happening. A paragraph effectively represents a location in time and space. The end of the paragraph can contain the various options available to the player. This can be followed by an INPUT statement asking for the players choice. The ON GOTO statement will decide in which way the story branches depending on the player's decision. INPUT The INPUT statement will work if the player enters a number of the correct value, but may well crash the program if the player enters a value outside the permitted range. This can be avoided by testing for the value of the inputed number. If the number is outside the permitted range then the program will branch back to the point where the input is being asked for and not reach the ON GOTO statement. The user should be able to type anything or click the mouse anytime and anywhere without crashing the program. This is all part of making a program user friendly. ON GOTO You can branch to any paragraph in your story. You may even branch to a paragraph that has been used before. It is possible to write an adventure that only branches forward. Some paragraphs may be used very often, while others may be used very rarely, and may be difficult parts of the story to reach. Choices may be more or less random e.g. North,South,East or West or there may be beter choices. Whether the player chooses the better choices may depend on any clues they have recieved and the logic of the player. It is a good idea to make the logic in your adventure consistent. Some games comsist of a number of logical puzzles which the player has to overcome. CHANCE An game can vary from having no element of chance at all to having a great amount of chance. A game with little chance may require more skill but has the disadvantage that the game will play the same way each time. Another disadvantage is that once the game is completed, there will be little point in playing the game again. With a chance element, the chances that the game can be played again and again will be increased. You can introduce chance by using the RND command. This will cause the generation of random numbers. By using RANDOMIZE TIMER you will be able to create different random numbers each time the program is run. You may use random numbers to recreate random events, or in combat etc. You can use random numbers to recreate the outcome of a die roll e.g. r=rnd(6) will mean that r is a number between 1 and 6. r=rnd(6)+rnd(6)+rnd(6) will give you the total of 3 dice. Note that this is different from r=rnd(18). There is no reason though, why you should be bound to 6 sided dice. You can create a random number between any two numbers. You may like to have the random numbers visible in the game, (particuarly during playtesting) or to have them invisible, but not their effects! WANDERING MONSTERS Random numbers can be used to determine whether a wandering monster appears, what kind of creature appears and other factors such as how many appear, what direction they come from and so forth. You may even have a table of monsters so that what monster appears depends on the location. This idea is like role-playing games in which what wandering monster appears depends on which level of a dungeon you are on. Random numbers can be used anywhere that dice(any number of sides) are used in a boardgame. They can be also used in combat, when searching for secret doors or other objects, for saving throws, for random events etc. An example of the latter is when the character is shipwrecked and lands on an island. A random number will determine whether the island is a desert island, a rocky island, Gilligans island or whatever. It is even possible to use random numbers to generate random mazes etc! If you are really clever you might use random numbers to generate landscapes, maps etc. PARSER One style of adventure game does not display the possible choices. What the character does must be typed in! The program must be able to recognise simple verbs and nouns etc. that the player might type in. In effect the player is telling the character what to do and hopefully finding the correct response without even knowing what the alternatives were. This method has advantages and disadvantages. One advantage is that it makes for a more difficult and challenging game and gives the player great freedom of choice. One disadvantage is that it requires more effort to play the game. People do not like to type too much. There is another disadvantage. The player may have the right idea, but may not be able to find the right words for it. An example of this was a game I was playing which contained the picture of a jug. I typed in "Get Jug" but to no avail. I eventually learned that the correct response was to type"Get Pitcher", pitcher being the American word for Jug. With this method it may be helpful to set up defaults, i.e. set responses if a particular attempted action fails. e.g.s are Player tries to go north. -You cannot go in this direction. Player tries to get something that cannot be moved. -You cannot get that item. Player tries to do something that is impossible. -You cannot "ATTACK" the piano. etc. One way to make the default text responses more interesting is to have several different responses, one of which is chosen at random. e.g. In response to a failed `get' -You cannot get the (object) -The (object) does not remove -Did you really think you could take the (object)? (Where object refers to the object name) Note to use the object name, you can use a string variable to store it in. e.g. ?"The ";item$;" does not remove". Some parsers in games are very advanced, being able to recognize the basic structure of a sentence, others like the ones I design are much simpler! ACTION COMBINATION Another way of recieving user input is to present all possible actions and all possible objects at each turn. For example, the possible player actions in a game might include some or all of the following: Directional actions N,S,E,W,NW,NE,SW,SE,UP,DOWN Actions not requiring object LOOK,WAIT Actions requiring object GET,DROP,USE,OPEN,CLOSE,DRINK,EAT,BUY,SELL,ATTACK These could be displayed continually in one corner of the screen. Objects that could be used, could be mentioned in the text, or in a seperate list. To be really fancy you could have all the game options in boxes which can be selected by a click with the mouse! If you are using graphics, the object could simply be in the picture and the player would have to recognize it before a command involving it could be made. PROCEDURES You will find it useful to use procedures that can be used again and again in a program. You can even use the same or modified procedures in different games. COMBAT For example, in a role-playing game you may like to have a combat procedure based on the combat system you wish to use. This will involve some mathematics and probably the use of logical operators, but this will generally be straight forward. Don't forget to share the necessary variables or to make them global if need be. Other possible procedures are for saving throws, encountering a trap, finding an object, casting a spell, using an object etc. etc. You can put almost your entire program in procedures! ITEMS You can make your game more complicated by containing items which are present in the game. Some items might be able to be carried by the character and possibly moved from location to location. Some actions may only be sucessful if the player is actually carrying a specific item. You may allow the character to carry an unlimited number of items or you may set an upper limit. Another approach is give each item a different weight so you may be able to carry a small number of heavy items or a larger number of lighter items. You could have a procedure to show what the character is carrying, or your could continually display a list on the screen. The player may be able to perform an action on an item e.g. open book or may be able to use one item on another item e.g. light candle with matches. ATTRIBUTES You may like to create a very double-edged story with many sudden death paragraphs or you might like to create a more subtle adventure. One way to do this is to introduce player attributes. These may include character attributes such as strength,stamina etc. or may be used to record things such as how many gold pieces a player is carrying. For example, you might not kill your character outright, but have him killed when his life level(or con etc.) reaches 0. This will draw the game out and not have everything hang on one decision or one bout of bad luck. To stop a variable from going below zero, you can use a comparision e.g. if str<0 then str=0 You will probably want your attributes to be global variables. ARRAYS Arrays can be very useful in an adventure game for storing related variables. Multi dimensional arrays could be used to store information on anything from details of monsters, items,people to the contents of rooms or locations. e.g. item$(100,5) This array stores up to 100 different items with 5(or 6 if you use the 0 element) characteristics each, or up to 500 different pieces of information. monster$(x,1) could be the name of the monster. monster$(x,2) could be the class. monster$(x,3) could be the life level. monster$(x,4) could be the strength. monster$(x,5) could be the magical data. Information could be numbers of words. Numbers can be stored as strings and converted to proper numbers with VAL e.g. x=val(X$) You could even store several bits of information in the same string and then break them up! VARIABLES Variables can be used to contain information about the course of a game. In its simplest form a variable can be equal to 1 or 0 (true or false). You may like a character to return to a paragraph location that they have already been to and want the circumstances to be exactly the same as what they were the first time the character was there. Or you may wish the circumstances to be different subsequent times the character reaches that paragraph. You can use variables in conjuction with END IF blocks to determine what happens depending on whether the character has beento that paragraph before or not. For example if the name of a location is tower you could create a variable called towr(though of course you could use another name). Initially the value of tower would be set to 0, if the character entered the tower, tower could then =1. Variables could also be used to store other things such as how many times an event has happened. END IF BLOCKS WAIT KEY You may like the user to respond by typing in a single key at the keyboard i.e. Wait Key. Clear the keyboard buffer before using Wait Key. MOUSE You may like the user to make a selection from a given number of choices by using the mouse. The choices may be presented as text in different coloured boxes, for example. STORING TEXT THere are different ways in which the text can be stored. Text can be stored in DATA statements and then read. Another way of storing text is by using sequential files. At the start of the game the sequential file can be read and text can be stored in arrays. Text from the arrays can be used as needed. You can divide the text in your files into paragraphs which are divided by headings which can be recognied by the Amiga. It can search through the file till it finds the appropriate heading and then read through and then stop when it reaches the next heading. One thing I have used for a heading is an uppercase word, being careful not to have any lines in the file which are fully uppercase. SEQUENTIAL FILES Sequential(or text) files and be usually in storing lists of related items. You may have a file to store a list of monsters,objects,people etc. These files can be read from and stored in arrays. This is less messy than assigning values directly to arrays, especially with large lists. As well as storing names, you may like to store other attributes. For example, on the monster file you might like to store the following characteristics: monster name, class, hit points, armour class, magical(y/n) etc. You will probably find it easiest to store all the information relating to one thing on the same line. Note that the different items in the file are seperated by commas, so they can be read off the file by INPUT#1. You will probably want text to be read by LINE INPUT#. Remember to have the same number of items on each line. Also note that items having a numerical value can be stored as strings and then converted with VAL. TURN LOOP On approach is to have a main do loop in your program, which will continue until your character has been sucessful in completing the adventure, completely unsucessful or the player has decided to quit the game. You can display details such as turn numbers, a player's score(if it exists) , a character's attributes and an inventory of what the player is carrying. The latter two things can be either be displayed continously or only displayed if the player requests it. SAVING THE GAME You may wish to allow he player to save the game and restart the game at a later stage in the same situation. One suggestion is to open a short sequential file containing certain variables and save these variables to disk. When the player wishes to continue this saved game, you can open the file and load up the variables. If you read the variables in the same order that they were saved in it can be easier thabn you think. Variables might include the location of the character, the character's current and maximum attributes, what the player is carrying and any other variables that may be important. HI-SCORES You may wish the player to save a hi-score or some other game statistics. For this you can write these details to disk in a sequential file. DEBUGGING All programs have to be debugged. Here are some tips for debugging. While developing a program you can add some code that will only be present during development. One idea is to print out the values of different variables at different points in the program. This will show whether the right values are being calculated at different points. If you have a bug, try and narrow down the area in which the bug is being created. Test procedures seperately, then add them together. Test your program, and write notes about things you want to chance. You may well get ideas for things you did not originally think off! SUPER CHARACTER To help playtest your adventure you might like to create a super character that cannot be killed. This will help you to playtest all the different branches of a game. It would appear that some commercial games have left their "super character" options in after playtesting. For example, in one game pressing the Alt-X key will create an invincible character. PLAYABILTY There are a number of things you can do to improve the playability of a game. It is generally good to allow the game to flow and not allow the player to get hopelessly bogged down. A frustrating game become boring. A game needs to be balanced. You want it neither too difficult or too easy. It may be undesirable to have a character killed off too easily. There is great scope for differences in style in an adventure game. You may have a bare minimum of text or you may have long descriptive paragraphs. Your adventure may be a fairly linear one in which the player must do step a, then step b, then step c etc. or may be a fairly broad adventure in which the player has some very wide choices at least at some points in the game. An example of this might be a town setting in which the character can explore any of a number of buildings. If your adventure is too linear it runs the risk of becoming frustrating at one point. PLAYER RESPONSE You may like to allow players to take as long as they like over their moves, or you may like to use real time. If they have not responsed in a cetain way, with either the keyboard, the mouse or a joystick then they may suffer some dire consequences. You may eventually like to have an interactive sequence, such as a mouse driven swordfight. GAME LOGIC You may like your game to be entirely brainless or you may require the player to do some clever deductive thinking. Some situations requiring some puzzle solving might include carefully hidden objects, information that can be only obtained from a non player character with careful questions, seemingly irrelevant information which is actually meaningful, information which fits together like a jigsaw- it does not make sense until all pieces are found, riddles, maps and strange symbols in the game. However fantastic your adventure may be, it is a good idea to keep the logic of your game consistent, otherwise it just becomes guesswork. GRAPHICS Adding graphics to a program is easy thanks to IFF-load. You can draw a painting with a program such as Deluxe paint. The drawing will not fill the entire screen and you will be able to add text at the bottom. Another option is to place text directly on your picture or to place it in a box. The text can then be removed without disturbing the graphics underneath. You may have to make some decisions regarding your IFF pictures depending on how many pictures you want in your program. Pictures in higher resolution and more bitplanes will occupy more space on disk and consequently you will be able to have fewer of them. If you wish to have many of them you will probably have to reduce the above characteristics. There are many options with graphics,including screen scrolling, zooming part of the screen, clipping, fading etc. SOUNDS AND MUSIC You will be able to add sound to your games by using sound stored at IFF files. Sound samples can be found on some PD disks. You can add some simple sounds with commands such as shoot,boom,bell or create a few simple sounds with the sound commands. ANIMATION When you become confident with drawing and using bobs and sprites you might like to put some animation in your adventures. An animation may be purely a demonstration, or may be an interactive sequence. There are many different things you can do with bobs and sprites. So... I hope you have fun with some of these ideas and good luck in your game designing!