Amiga Plus 2000 #1

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

/ Amiga Plus 2000 #1 / Amiga Plus CD - 2000 - No. 1.iso / Games / Oldies / Haktar / Haktar.doc < prev next >

Wrap

Text File | 1999-12-03 | 41.6 KB | 939 lines

Haktar V1.6 (C) by Guido Wegener Mar.1992 Eisenacher Str. 2 °ª° 5300 Bonn 1 West Germany This program is Freeware and may only be copied on an unchanched disc of the series mentioned when Haktar starts. If you want to sell it on your own discs, then please ask me for a special version for you. Please inform me about the copyrights, prices etc. of your series. Haktar uses the ARP.library and was written using Aztec C 5.0b. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Request : Haktar was written to entertain, and it would be very nice if you'd write some cute adventures and then send them to me. You will get the disk back with some of the other adventures I received from all over the world. Please list the languages you are able to understand. It would be very friendly (and will improve your chances of getting a fast answer) if you would send some money (for postage (and some beers)). Oh, look at this UGLY .doc-file ! My English is so bad und the structure is so chaotic ! I am sure that you could write a better one ! Yeah, become a hero of the scene ! Write a good manual for Haktar ! Send it to me ! Oh Boy ! You are soooooooooooooooooooooooooooooooooo kind ! I know that I ask a lot of you to do, but I did an awful lot of work for Haktar and would be glad to know that there are some guys out there who are using it. Please spread the whole package. The more people are testing it, the more improvements will be made. And we all do want that perfect proggy, don't we ? °ª° THANKS °ª° /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ About Haktar : About a year ago I started to read H.P.Lovecraft's books. I started with 'The Case of Charles Dexter Ward'. When that good guy investigated the giant cave under Joseph Curwen's house, I was fascinated and thought about ways to explore such dungeons in the computer. Since I once wrote some C-64-Basic adventures and had thought about such problems before, it did not take long until I had the first ideas for it. But how should I manage the parser ? A good parser for an adventure construction kit is very hard to program, isn't it ? I gave up... Some days later I bought 'Dungeon Quest', a primitive and cheap, but somewhat cute, adventure. One time I was standing in front of a little hut. I wanted to enter it, or at least to read the message at the door, but for doing so I had to try about 10 commands until the parser understood what I meant. That day the first complete concept for Haktar was born : - everything you can do is displayed on the screen - each item or room is one DOS-file - these files are simple ASCII text files - these texts consist of some simple commands - according to your inputs, Haktar is jumping from file to file /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ About The Name : Some time ago Douglas Adams wrote 'The Hitch Hiker's Guide to the Galaxy'. It was a real success and he wrote three more books on the subject. One of the books is called 'Life, the Universe and Everything'. In this book there is a giant computer that was destroyed because of a failure. But the particles of the computer were still communicating with each other and the crippled computer floated through space. He was still able to create illusions and some real things. His name was 'Hactar' (or Haktar in the German translation of the book). "It was thin and feeble, like a voice carried on the wind from a great distance, half heard, a memory or a dream of a voice." "'I have nothing to offer you by way of hospitality,' said Hactar faintly, 'but tricks of the light. It is possible to be comfortable with tricks of light, though, if that is all you have.' His voice evanesced, and in the dark dust a long velvet paisley-covered sofa coalesced into hazy shape." "I can encourage and suggest tiny pieces of space debris - the odd minute meteor, a few molecules here, a few hydrogen atoms there - to move together." When I was thinking about the name for this program, I remebered this computer and thought that the name would fit : I wrote Haktar to create new worlds. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Structure Of An Adventure : The key to an adventure is the head-file. In this file there are the initial commands. You must give a headpath here. You may set the time. You may set the maximum weight. You may set some initial flags and variables. You should declare files that contain thing-commands. You may create some items in the hero's pocket. You should print some introducing words for the user. You MUST use a go-command to mark the first room. Every room is a single DOS-file. There you can list the items that are in there, and the things the hero can do there. Every item is a DOS-file, too. Here you can only list the things the hero can do with it. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ How To Start Haktar : Type 'Haktar <headfile>' in the CLI. <headfile> is the full name of the head-file of your adventure. OR : Click its icon. But there still may be some problems with the WBstart. It is very wise to use an addbuffers on the drive you are using, this will prevent Haktar from loading the same file several times. Addbuffers 50 is a good command for medium size adventures. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ The Userinterface : The Interface consists of the following groups of elements : A menu (right mouse button) B list gadgets (that upper half of the screen with the prop-gadget) C control gadgets (the six boolean gadgets in the middle) D text output A:a:Project : 1 Restart The adventure you were playing is started again. You will not have to type the filename again. 2 Start... A file requester will appear. Choose the headfile of an adventure. My own adventures are marked by the .hhf (Haktar header file) extension, but do not count on that when dealing with other adventures. The chosen adventure will be started. 3 Load... After saving the game (Aa4) you can restart it by entering the name of the file here. After loading you will have to click on C1,2 or 3. 4 Save... Save your position in the adventure. 5 About... You know this. 6 Crap Ey, just crap, ey, you know, small-talk, isn't it, or what ? 7 Short Instructions A VERY short guide to the secrets of Haktar. 8 Quit It does not look like the close gadget but it works exactly the same. b:System : 1 Headpath : After copying an adventure to another device it is neccessary to change the headpath command in the headfile. For testing you can also set the new headpath with this option and all following headpath-commands will be ignored. I do not know why I included this option, but some months ago I thought that it was important... 2 Restore Headpath After changing the headpath (Ab2) you can restore the real headpath with this option. B: 1 the big big list When you have to choose what to do, you have to click on one of the actions or things listed here. When the time is right, you can choose different lists by clicking C1-3. And you may scroll through long lists by using B2-4. 2 the long proportional gadget Move the bar to scroll through lists. 3 arrow up Scroll up one entry. 4 arrow down Scroll down again. C: 1 Room By clicking this gadget you can get a list of all the possible actions in the room you are in. In most cases you can find something to leave the room here. Choose one and see what happens. For profis : All do-commands of the room file are displayed. This list will also appear every time you enter a new room. 2 Items Click here to get a list of the items in the room. Click one of the displayed items to see what you can do with that specific item. Click one of the displayed actions and it will be executed. Do not forget to use this gadget when entering a new room! If you don't, you may overlook some important items. 3 Inventory All items you are holding will be displayed. You may then choose what to do with a chosen item, just like C2. 4,5 Continue, Ok This gadgets are dead in this version. But you can use the (especially the Continue) to scroll a page of text. 6 Cancel You can use this gadget to forbid the waiting when showing a text. This will speed it up, but you will still be able to pause by pressing the right mouse button. To stop all output, press the close gadget once. Note that Haktar has to read through the whole file, even after pressing close; so please wait until it is ready. D: In the text window all messages and descriptions will be displayed. After each move the name of the room you are in will be displayed here to mark the paragraphs. When reading texts that are too long for the window, a red arrow will appear in the right corner of the window. Click on the text or C4 for continue. You may also press any (real==undead) key or the right mouse button or any other gadget (except Cancel and close). You can also use keys to activate the gadget functions : Key Gadget r C1 i or <Space> C2 n C3 u B3 d B4 1-9 B1 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Haktar Commands : Haktar's commands consist of their name and some (or none) arguments. There are three groups of arguments : short name stop chars I integer number <return>·[] |,abcdef.... W word <return>·[] |, N name <return>·[]|, S string <return>· B block [] BB double block [|] - Stop chars are the chars that mark the end of an argument. - No argument except B and BB may be longer than 80 characters ! - Arguments that have to be displayed as text must not be longer than 79 characters, while arguments that will be listed as choices have a limit of 77 characters. When dealing with pure ASCII files that are to be printed via printfile, you should use my WordWrap utility. This small tool should be on this disk, too. But Fred Fish will probably have killed it. - The arguments may not be complex in any way, they are not parsed. Haktar reads them as they are and does not do much thinking. - When using some of the commands, it is neccessary to tell Haktar about the name of a room. You may type simply type the name of a room that you have created or INV or ACTROOM. -You may use the name INV instead of a real room name to refer to the hero's hands and pockets. This means the things that the hero is carrying. Instead of INV, you may also use an empty argument, but this is unclean. -You may refer to the room the hero is in by ACTROOM, or in an unclean way by ¡. - Leading spaces in all arguments except strings are deleted. - All spaces at the end of anything will be killed, too. - Words are not used yet, but maybe I will need them later. In this version are implemented for internal use only. - Blocks are very special arguments, they consist of some (or none) additional Haktar commands. Simple blocks must be enclosed by [ and ]. Double blocks have to start with [. The second block has to start with | and ends with ]. These double blocks are used in if-statements, where the first block expresses the TRUE (or positive) block and the second block contains the FALSE (or negative) block. The TRUE block will be executed if the if-statement is true. In all other cases the FALSE block will be executed. It works something like IF THEN ELSE. - If a double block is needed, you have to give BOTH blocks. Each of them may be empty to express that you do not want anything to be executed here. This is also true for simple blocks. So you will have to use the [] or [|] characters to avoid ugly results. - To build an or-constructions with if commands, you may write several ifs in one line, seperated by commas. You may then use only one double block for all if-commands of that line. This will be executed if any of the previous ifs was true. ATTENTION, your attention please ! You may not, never and not at all use characters like [ or ] or | in any other place or sense than as blocking parantheses. In other words : Do not place []| in rems, prints, names, vars, flags, doscalls, filenames, etc. But you must use them after EACH and EVERY do, choose, thing or if ! The following descriptions consist of the command name and the format of its arguments : First there is a character to express the argument type. This is followed by something like <flag>. This has to be replaced by the real argument. The type and the <> chars do not belong to the argument. All commands may be written in any way : BIG, small or SOmeWAy. There may come a time when you do not want the full name of a room or item to be displayed. You can hide parts of these names by placing a § at the start and a the end of the part that is to be hidden. This is usefull when dealing with mazes or other things that look the same, but work differently. In the tradition of the C-64 Basic, you can use abbreviations for most of the commands. The ? is quite cute and some of the others may proove usefull in extreme circumstances. Somewhere below, there is a list of them. do N<action> B<block of commands> Several of these commands should be in every room/item-file. When the user selects the room/item, all do-commands in this file will be read and the <action> strings will be displayed in the list. The user chooses one of them and its <block of commands> will be executed. This is the heart and core of Haktar, you can do without it, but not well. Do not place normal commands outside a do-command and do not place a do- command into another do-command. items N<item> N<item> .... Haktar needs a list of all the items lying in each room (How could he know ?). Place one of these commands in every room and list the items that are in it. For reasons of style you can use several items-commands in one file. Do not hide items-commands in if-statements. When the first reference to a room occurs, Haktar will read its file and remembers the items listed. It will never again look at the items-commands of that file. If you want to add items to a room, then the create-command is the only legal way. move N<item> N<source> N<destination> Moves the <item> from room <source> to the room <destination>. If the item cannot be found in <source>, it will be created in <destination>. The move-command works like : gone <item> <source> create <item> destination> create N<item> N<room> Creates the <item> in the <room> out of thin air. You may create more than one item of a type (=name), but this will lead to some troubles when using the handle-command. Be sure that the create-commands are at the right spot. A friend of mine had some ugly results when putting the creates into the wrong if-statement. Note that this version of Haktar puts new items at the beginning of the lists. This is good, because the user will see these changes first. But it could mess up the order in your lists. gone N<item> N<room> The <item> in the <room> will be deleted/killed/get lost/annihilated/ destroyed forever. (You can create it again). If you do not know where the item is, you may use the INVACT room name. Haktar will try to kill the item in the inventory list and, if it was not there, in the current room. choose N<action> B<block of commands> This command works like the do-command. While do-commands may not be placed within other do-commands, this command may ONLY be placed there. If you use choose, you will also have to place a startchoose at the start of a group of choose-commands, and an endchoose at its end. You may place a choose-block inside another's <block of commands>. There is a limit of 10 choose-commands inside each other. Do not use several choose-blocks AFTER each other. startchoose Marks the start of a group of choose-commands. endchoose Marks the end of a group of choose-commands. setflag N<flag> The <flag> will be set. delflag N<flag> The <flag> is deleted. setvar N<var> I<value> The Variable <var> will be created and set to the <value>. <value> is a simple CONSTANT. Variables can only hold integer values. Negative values are allowed. Variables use more memory than flags and cannot be deleted. So please use flags where it is possible. addvar N<var> I<value> The <value> is added to the Variable <var>. If the variable was not set upto now (it has no value), it will be set to <value>. To decrease <var>, you may use negative <value>s. print S<text> Prints the <text> on the screen. Please use it as often as possible. Before the text is scrolled out of view by following lines, Haktar will call the wait-command. cprint S<text> Like print, but the text is centred. printvar N<intro> N<var> N<ending> This prints the value of a <var>iable between the texts <intro> and <ending>. You may not use commas in these texts. wait This command waits for the user to click on the text-window. It can be used to split the output into sane passages, preventing Haktar from doing it himself (and, boy, is he cruel !). noautowait Switch off all automatic waits. This will work like clicking on the Cancel gadget, except that wait-commands will still do their duty. locoff Normally the current location of the hero is displayed in the text window AND the title bar. If you use simpleface, the graphics in the title bar will be deleted every move. To prevent this, you can switch off the display in the title bar. BUGS: locoff does not prevent the destruction of the title bar when reactivating the window. I hope that I can change that later. locon From now on the current location will be displayed in the title bar again. getphrase S<get text> If you want to make life easier by using the handle-command (see below), you must use this and the following two commands before (best in the head- file). This one lets you give a text that will be used in the list of choices for the user. Please refer to the handle-command. Here and in the following two commands, the use of a § expresses that you want Haktar to replace the char by the name of the item the handle is in. dropphrase S<drop text> This command defines the text that is used to express the possibility of dropping an item. cantgetphrase S<too heavy text> An item may be too heavy to be taken by the hero. In this case the <too heavy text> is printed. handle I<weight> This is one of my personal goodies. It solves the get/drop problem. It works like a do-command. When Haktar finds this command, it adds the getphrase or dropphrase string, depending on if the hero already holds the item or not, to the list of do-choices. If the user selects it, the item in which the handle-command is used is taken or dropped and the <weight> of the item is added or substracted to/from the weight the hero carries. Handle is working like a block of other commands, and you may think of it as being replaced by these commands : ifitemin stone,INV [ do drop stone [ move stone,INV,ACTROOM addweight -10 ] | do get stone [ ifweight 10 [ print Too heavy ! | move stone,ACTROOM,INV addweight 10 ] ] ] These lines could be replaced by 'handle 10'. Short, eh ? It will only work exactly like this if the following conditions are true: - The handle is included in the file 'stone'. - You gave the following commands somewhere before : getphrase get § dropphrase drop § cantdropphrase Too heavy ! headpath N<path> Haktar needs to know where all the rooms and items of your adventure are. You must tell him by using headpath. <path> is the directory where Haktar must search for the files. This command should be in your headfile ! <path> must be written in normal CLI-path-format : Start with the disk's name and list the subdirectoriesin the right order to get to the directory where the files are. Examples : DF0: HaktarDisk:adventures HaktarDisk:adventures/MyRoom multi N<file> N<file> .... By using the thing-command, you can store more than one item in a single DOS file. But Haktar needs to know which files contain these thing-commands. Use multi in the head-file and list all these files behind it. thing N<name> B<commands> This command allows you to store several items or rooms in one file. Each item's block of <commands> is simply placed between the usual [] and put behind a thing-command. The <name> of the item or room is put directly behind the thing-command. After telling Haktar about it (multi), each thing-complex is treated exactly like a real single file with the <name>, consisting of the block of <commands>. maxweight I<weight> You can limit the weight the hero is able to carry by setting the maximum <weight> to carry with the maxweight-command. It depends on you if you think of the weight as pounds, kg, g, Martian Grav-Meter or Vogonian Standard Towel Weight. Or you can limit the number of items, that the hero can carry, by declaring the maximum number as maxweight and giving all items the weight of 1. addweight I<weight> Each time the hero takes an item, you may add its weight to the weight the hero carries by using addweight. The <weight> will be added to the carried weight. When an item is dropped, it is wise to use a negative <weight>. settime I<time> The game time is set to a constant value. addtime I<time> The <time> is added to the game time. go N<room> The hero is moved into the <room>. This is the only way to change his position. You must use this command in the head-file to set the starting room. input The user is to type a string. This string can be examined by an ifinput- command later. dead This is that lovely command that cuts the rope of the 10000tons weight hanging above the hero's head. Game Over ! rem S<remark> This command will be overread. You can use it to place some comments or <remark>s in the listing. execute N<file> The Haktar-<file> will be executed like any normal file. Often there are groups of commands that are repeated several times in an adventure. You can place this repeating commands in a DOS file and let Haktar execute this file. doscall N<command> The <command> will be executed like a CLI-command. That command has to be in reach of DOS, that means in C: or the current directory. eachmove N<file> Sometimes you will want to check something each move, independent of the room the hero is in. This check-commands can be placed in a DOS file and the name of this <file> can be told Haktar by this command. There can be only one file set by eachmove at any given time. When the testing becomes useless, you can use an empty <file> name to forbid the execution. BUG: In this version the <file> must be a real, seperate file. It must NOT be part of a multi-file. showpic N<file> I<MaxTime> The IFF/ILBM-pic <file> will be shown. The computer then waits for a mouse click. To limit the time the user is able to see the picture, you can use <MaxTime>. Haktar will show the pic for <MaxTime> frames. One second equals 50 or 60 frames, depending on your type of computer (PAL or NTSC). <MaxTime>=0 will show the pic forever, until the user clicks his mouse. showpicsub N<file> I<MaxTime> Same as showpic, but the picture will be displayed at the buttom of the screen and will remain there until it is changed by another call to showpicsub. Call showpicsub without parameters to delete any shown pic. Do not try to display pictures larger than 54 pixels. When called on NTSC, showpicsub will be handled as showpic. simpleface N<file> The ILBM-picture <file> will be used as grafic user interface. It must be 640 pixels wide and 200 pixels heigh. These are the coordinates of the gadgets (x,y,w,h): PropDown 5,76,11,9 PropUp 5,12,11,9 Prop 5,23,11,51 ListGad 17,13,618,8 (there are nine of this type, with y increasing at a rate of 8 pixels) Standard 7,91,100,9 (there are six of this type, with x increasing at a rate of 105 pixels) TextGad 4,106,632,81 font S<charset name> Use special font for all coming text output (lists and text window). Do not forget to add the .font extension where needed. The charset must be a standard Amiga-font in the FONT: directory. You may only use 8x8 fonts like Topaz 8. Do not use the proportional option. Create your fonts by editing the Topaz 8 with FED on your Extras disk. printfile N<file> The ASCII <file> will be printed. It is just like using lots of prints. sys S<code> ??? There are some things that cannot be realized with the Haktar commands. These can be coded in C and put into the listing of Haktar. Please do not invent new commands, it is better to use sys. Put your routines at the right place, that is into the sys-command. storevars N<file> N<var>... Sometimes you may want to transfer Haktar-variables to another program (for example one called by execute). In this case you can use this command to write a number a selected <var>iables to a <file>. Normally this file should be placed into the ram-disc. The file created will consist of the following entries: 1. a long integer that stores the value 2. a return-terminated string that stores the variable 3. same as 1. 4. same as 2. ... Look at a file created by this command to see how it looks like. getvars N<file> N<var>... The variables that were stored in the file (via storevars) are read. The values on disc will be stored into the actual Haktar-variables. You may create the <file> yourself, but be sure that its format is correct. Use this command to respond to the results of files you called via execute. ifflag N<flag> BB<blocks> If the <flag> is set, then the first block is executed. If the <flag> is FALSE, then the second block is executed. ifvar N<var> I<low> I<high> BB<blocks> This is TRUE if the value of the variable <var> is larger than or equal to <low> and smaller or equal than <high>. Unset variables are given the value 0. If you give no <high> value, Haktar will only test if the variable is larger or equal. Please note : In this case you must place a <return> or · after <low> !! ifitemin N<item> N<room> BB<blocks> Is TRUE if the <item> is in the <room>. You may use the term INVACT as <room>-name to express that the exact location of the item does not matter. The command is TRUE if the item is in the hero's hands or in the room he is in. It all works like the INVACT of "gone". ifin N<room> BB<blocks> Is TRUE if the hero is in the <room>. ifweight I<weight> BB<blocks> Is TRUE if the hero is able to hold the additional <weight>. iftime I<low> I<high> BB<blocks> Is TRUE if the time is between <low> and <high>. (see also ifvar) ifinput N<string> BB<blocks> Is TRUE if the user answered the last input-command with the <string>. You may check the same input more than one time. ifchance I<percent> BB<blocks> Haktar will generate a random number between 1 and 100. ifchance is true if <percent> is smaller or equal than that number. Too quick, too much ? Read it again ! One more time ! You still don't get it ? Look at the example adventure (if it is on the disk). /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ For all of you out there, who got lost in this list : All commands in a sorted list : Note: Type has the following meaning: 1 : Use only in the lowest level (not in a block). 2 : Use only in the highest level (a block without anymore choose or do commands enclosed). 3 : Use it where you like. 4 : Do not use in lowest or highest level. Haktar reads every file several times each turn. Be carefull to prevent sideeffects. For every time a list of choices is displayed to the user, Haktar reads the file one time and executes all commands on lesser levels than the one of the command that caused the displaying of the list. You may use type 2 commands in low levels, but be carefull! Haktar tries to execute every command no more than a single time per turn, but has problems with this. You may print a text before using choose, but Haktar gets crazy if you use print AND choose in another choose-block. In other words: Be carefull... command abbreviations type arguments addtime at 2 I<duration> addvar av 2 N<variable> I<value> addweight aw 2 I<weight> cantgetphrase cgp 2 S<too heavy text> choose c 4 S<action name> B cprint c? , ! 2 S<text> create c 2 N<item> N<room> dead d 2 delflag df 2 N<flag> do 1 N<action name> B doscall dc 2 N<CLI-command> dropphrase dp 2 S<drop text> eachmove em 2 N<file> endchoose ec 4 execute e 2 N<file> font fo 2 S<font name> getphrase gp 2 S<get text> getvars gv 2 N<file> N<var>... go 2 N<room> gone g , lost 2 N<item> N<room> handle h 1 I<weight> headpath hp 2 N<directory> ifchance ic 3 I<percent> BB ifflag if 3 N<flag> BB ifin ii 3 N<room> BB ifinput iinp 3 N<text> BB ifitemin iii 3 N<item> N<room> BB iftime it 3 I<lower limit> I<upper limit> BB ifvar iv 3 N<variable> I<lower limit> I<upper limit> BB ifweight iw 3 I<additional weight> input inp 2 items i 1 N<item> NNNN... locoff loff 2 locon lon 2 maxweight mw 2 I<weight limit> move m 2 N<item> N<source room> N<destination room> multi mf 2 N<file> NNNN... noautowait naw 2 print p , ? 2 S<text> printfile pf 2 N<text file> printvar pv , ?v 2 N<text> N<var> N<text> rem ; 3 S<comment> setflag sf 2 N<flag> settime st 2 I<Time> setvar sv 2 N<variable> I<Value> showpic sp 2 N<file> simpleface sif 2 N<file> startchoose sc 4 storevars stv 2 N<file> N<var>... sys s 2 S<code> thing t 1 wait w 2 /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Examples : This is no adventure. It is not even a correct file. I only wanted to give some examples for the use of some commands. To get an impression of a whole adventure, look at the example.hhf adventure. items book,ball,pen do read book [ addtime 10 print boring... ] ifitemin book,INV [ rem if he has the book, he can drop it do drop book [ move book,INV,ACTROOM rem move book from his hands/pockets into room ] | do take book rem if he has no book, he can take it [ move book,ACTROOM,INV rem move book from room into pocket ] ] /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Advices : - You do not have to format your programs the way I did, but it looks nicer, doesn't it ? And H.C.F. does not always format his stuff precisely, and so there are many bugs in his adventures. You see that it is important to keep a certain structure to avoid errors with parantheses. Maybe I will teach haktar to reformat your adventures in a later version. - When dealing with if-statements, you MUST use all three seperators ([|]). If you want no positive commands use [|<negative>]. If you want no negative commands use [<positive>|]. - To reduce the necessary scrolling up and down, you should place the most needed actions and items at the top of the lists. - Since all possible actions are displayed to the user, you will have to hide the key-actions by giving lots of choices. - Often it is wise to really hide the do-command by using an if. This way the hero may walk through a room, not seeing that there is a hidden switch. Later he finds a drawing, showing that there is a switch. When he walks back into the room, the ifitemin drawing,INV is true and the do-commands you hid there become visible. - There are people who will execute EVERY do, just to get ALL information. That is not nice, so prevent this by using some dead-commands and by using lots of ifs to change the course of action according to the things the user did upto now. - Please give the user lots of informations by using lots of prints. - Haktar can be used to create adventures, but it was designed to create a reality. The aim is not to solve the adventure, but to explore the world and gather all informations. That does not mean that you can't write adventures with it. You can and you may, I just wanted to suggest... - If you have enough RAM or a harddisk, you should copy the adventure to it. Take care of the head-file : Change the headpath statement or use assign to make it work. - Be carefull with the doscall-command. Its parameters are passed to the Amiga-DOS without parsing. Please do not depend on any files you did not supply and do not depend on your files being in a certain directory. This is why you should use headpath and the DOS command assign. - To make swapping easier, you should place the headpath-command at the beginning of your headfile. If you need some assigns, please place the correct doscall-commands directly after the headpath-command. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Excuses : Yes, I know that some of Haktar's characteristics are not well liked by all people. Here is a list of them and the reasons why I did it this way : - It is too complicated to make a whole file for each item. When making changes, you have to load and save a lot to update all files. I do not think so; most of the changes are made within one item. Changing that would change the whole concept of Hakter. And it would result in a chaotic structure of the adventures. Haktar would need extra memory and huge amounts of time. You would not be able to find a specific item at once. And there are the multi/thing commands for the hard core of that type. So : When you are done with your adventure, please kill the multi files (by calling HakCheck ... SPLIT). - I want to have a parser, the multiple-choice principle is stupid ! Yes, I agree with you, but I don't think that there is a way to program a parser-orientated adventure interpreter. And some people actually like this way of doing it (Hi HCF !). - There is a small memory loss when calling simpleface! Yes, but that is my way of killing lamers: Cool freaks with 8MBytes do not notice such small losses, but all these A500-lamers will be killed by the 500 Bytes that dissapear. No, I just can't find that bug. If you can help me here, then do it! Features of later versions (I hope...) : - complex calculations, terms with variables - keep special files in memory (as a command) - IFF grafix even for selected gadgets - an ask-like IfTheUserSaysThatItIsOKThen command - some simple battle functions to implement aspects of role-playing (as RAT would express it) or hack'n'slay (that's my name for it) fights /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ HakCheck : HakCheck is a little tool for Haktar. It reads an adventure and creates some lists : 1. Used rooms/items. You can read through this list to find unused rooms. 2. References to rooms or items that do not exist on disk. You have forgotten to create these files or you spelled them wrong. 3. Used flags. Check these to eleminate flags that you spelled wrong. 4. Used vars. Same as flags... 5. Bad var references. List of variables you used before initializing them. If you own a printer, it is very wise to print these lists to prevent several items to be given the same name or vice versa. It also displays the number of files and the average and total length. I am planning to check even more errors, mostly syntax errors, but that will have to wait. When HakCheck finds a syntax error, it will display the file and the line it is in. That service is very generously, and is not included in any other list, so look into your manual and learn to work with the search command. Starting HakCheck : Type 'HakCheck <headfile>' in the CLI. I don't think that I will include WBench start. HakCheck can also be used to make adventure files unreadable. You will still be able to play these, but the files will be coded. The CLI call for this feature looks like this : HakCheck <headfile> CODE <code> <code> is a 4 letter word. You can decode the adventure (if you know the code) again : HakCheck <headfile> DECODE <code> Adventures that consist of huge multi/thing files become very slow. You should split these into small files. This can be done with HakCheck : HakCheck <headfile> SPLIT Whenever HakCheck finds a thing command, it creates a new file with the name and contents of the thing command. After that you will have to delete all multi commands in the headfile. The files that contained the thing commands will be useless now, so you can delete them, too. When checking long adventures, the lists will get very long. To prevent all unimportant output (as lists and the what-are-you-doing-infos), use this : HakCheck <headfile> QUIET And do not mix the options in a single call ! NOTE: HakCheck needs lots of stack for long and complex adventures. If a wise man from india appears while HakCheck is running, then the most likely reason is that your stack was too small. Please try again with a bigger stack. If you have any idea of how to prevent this, please inform me. Other tools for Haktar: ======================= Yes, there tools for Haktar that have not been written by me. Of these I know the following: HakCrunch by Eric Hambuch transforms all Haktar-commands into shortcuts. HakFormat by Eric Hambuch formats the structure of adventures. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Bugs : HakCheck seems to have problems with counting the lines, so do not rely on the number it prints. Check the previous and next line, too. I do not know why, but I just found out that HakCheck has problems with spaces after commands. And Haktar does not like to be started from the WorkBench directly, so I still have to use IconX, but it already reads the wbargs. If you know why Haktar goes bananas when being clicked (You can't even click the adventures directly !), PLEASE write to me ! I have tested my ShowPic with every ILBM file I found on my discs. And this is the result : It is perfect, BUT : DPaint III seems to ignore some rules. It does not set the HBRIGHT flag in the CAMG chunk. And the brushes are different (unshowable), too. I just tested Haktar on memory losses. Result : OK. But somehow I gained some bytes by calling it. That is not too bad... Remember to set the stack correctly. HakCheck is rather complex and will need lots of stack when checking large adventures. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Your Rights, My Rights : - You may write adventures with Haktar and you have all rights on the text files you wrote, but I beg you to declare your adventures as PD. - It would be nice of you to send your good adventures to me, I will try to send back the disk with some new adventures on it. If you do this, please include a note if I may spread the adventure on PD. - When spreading your own adventures, please note that Haktar may not be sold on any other discs except the series that is mentioned when starting Haktar. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Thanx'n'Greetungs'n'da whole stuff : - Guido Wegener : Thanks for being me. He/I wrote the whole thing. - Hans Christian Freankel : Thanks for testing, Powerplays and lots of Game Boy matches (lots of them are still to come). - Eric Hambuch : Thanx for bug reports, tools, tips & ideas! - André Wichmann : Thanks for testing/ideas and your fast text tool. Special thanks for trying to deliver your FileSelect. - Robert Heselmann : Thanks for testing/writing and the cheap Game Boy. - Martin Rosenkranz : No thanx for not testing and not writing. And what does "I won't use >YOUR< (fucking) language !" mean ? You want to get old with that attitude ? Grow up, Cogan. - Commodore : Thanks for AMIGA 500, 1MB, A590, 1084S - SWF3 : cool radio broadcasts (I could think of better ones, but...) - Addison Wesley : Thanks for the Manuals, they made it all possible. - Manx : Aztec C 5.0 is GREAT ! - School, sickness, relations, drinks, glass, games, TV : Thanks for disturbing my programming-sessions. - Kronsteiner, Schrader : That's what I need. The softest soft-drinks ! - Lovecraft : inspiration - E.A.Poe : relaxation - Competition Pro : For real fun with real games. I tuned my transparent stick by replacing the metal stick by one of my old knobs. Now it works like hell and it has a rugh knob ! - Benji (my dog) : Thanks for fresh air and keeping me up all night. (That's over since the little operation. =ß-) - Lutz Grandrath, Philipp Witkop : Hi ! (friendly... °º°) - Martin Mohr : Hi, thanx for not killing Tower of Babel ! - Martin Baumann : Phone me ! - All the ST-idiots around : You will not be able to read this ! - Nintendo : A big THANK YOU for the Game Boy ! - The Acient City Healthy Ball Factory of Baoding : Qigong balls for compiling time... - Edward Bulwer-Lytton : "Zanoni" is good. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Send errors, corrections, supporting ideas, criticism, enthusiastic fan- letters and money to the author: Guido Wegener Eisenacher Str. 2 5300 Bonn 1 West Germany