APDL Soft Rock Games

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

/ APDL Soft Rock Games / APDL_SOFTROCK.iso / trellis / docs / part06 < prev next >

Wrap

Text File | 1999-04-02 | 14.1 KB | 303 lines

TRELLIS - The Adventure Interpreter (c) copyright 1991-9 Soft Rock Software Implementing Puzzles -------------------- Puzzles are an integral part of an adventure game. Without them the game would present no challenge to the player, except perhaps as a maze. There are all sorts of puzzles you can implement, many of which are variations on a theme, and this section will show how to use the simplest types in a game. You will need to have read the sections, on Stores and the TScript command set, since it's by using stores and TScript programming that you will add puzzles to your game. One of the simplest puzzles to implement is a darkened room, in which the player must use a torch or some other source of light in order to see. This has been mentioned before in these instructions, so will not be explained again - except to say that !Pyramid provides an example of this. Another very simple puzzle is to define the amount a player can carry, by way of a weight limit. When this is done the player may only be able to carry, say, the sword if he/she drops the shield first, and so must decide which would be more useful. Again, this has been explained elsewhere in these instructions, so will not be covered here, except for... Using the 'weight' idea, you could limit the player to carrying a certain *number* of items. Give each of the objects the player can carry a weight of 1 (in the Objects file) and at the start of your script file, use... LET Store%(1)=5 (If the maximum number of objects the player can carry is 5) The use of doors is another type of puzzle, and may well be one of the most common puzzles found in adventure games. This is probably because doors are very easy to code, as you can see from the following example:- Suppose you want a door to lead North from room 15 to room 16. Firstly, to stop Trellis automatically telling the player that there's an exit North, you should not include a link between these two rooms in your rooms file - ie, there should be no 'N16' as part of the definition of room 15, or 'S15' as part of room 16. When the rooms are set up, North%(15) and South%(16) will both contain 0. You can also lock the door. Do this by using one of the Store%() variables to contain, perhaps, 0 if the door is locked and -1 if unlocked. In this example, I'll use Store%(21). So, to ensure the door is locked include the following line near the start of your script:- LET Store%(21)=0 With these initial components of the puzzle in place, you can now tell the player about the door (if you want to). Somewhere after the 'LOOK' command in your TScript file you should include something like this:- IF Store%(3)=15 AND North%(15)=0 THEN PRINT" There is a closed door to the North" IF Store%(3)=16 AND South%(16)=0 THEN PRINT" There is a closed door to the South." You will notice that I have not said whether or not the door is locked. This is because you can't normally tell if a door is locked just by looking at it. You have to try to open it to discover this fact. So, you can allow the player to interact with the door. First of all, the door needs to be unlocked. Somewhere after the 'INPUT' command you need to include something like this:- IF FNSaid("UNLOCK") AND FNSaid("DOOR") THEN IF Store%(3)<>15 AND Store%(3)<>16 THEN GOTO you_cant IF Location%(4)<>0 THEN GOTO you_cant IF Store%(21)=-1 THEN GOTO you_cant LET Store%(21)=-1 PRINT"You unlock the door."' GOTO input_loop END IF If the player enters the commands UNLOCK and DOOR Trellis will check various things, to see if the door can be unlocked. Firstly, it checks to see if the player is at either room 15 or room 16 - the rooms that the door connects. If the player is not there, the door can't be opened so a jump is made to the 'you_cant' label - which simply tells the player 'You can't do that' and gets the next command. Secondly, it checks to see if the player is carrying the key. (I have assumed for the purposes of this example that the key is object 4.) If so, the key's location will be 0. If it isn't the jump is again made to 'you_cant' Thirdly, it checks that the door is locked. Obviously, it can't be unlocked if it is already so. Again, a jump might be made to 'you_cant' These three checks could have been included on one line. When writing adventure games, it often pays to do this for reasons of speed. However, the line becomes long and spills over several screen lines, making it difficult to read. To make these instructions clearer I have, and will continue to split them up in this manner. If you wanted, you could have more messages than the ubiquitous 'You can't do that.' You could tell the player he/she doesn't have the key, or isn't near a door, or that the door is already unlocked. To do this, however, splitting the checks up as I have done above becomes necessary since each IF statement checks for these particular circumstances. Once these checks are carried out you know the player is able to unlock the door, so the contents of Store%(21) is changed to -1, a message is displayed on the screen for the player's benefit, and the script jumps to the input command. To enable the player to open the door, the next section of script could be used, also after the 'INPUT' command:- IF FNSaid("OPEN") AND FNSaid("DOOR") THEN IF Store%(3)<>15 AND Store%(3)<>16 THEN GOTO you_cant IF Store%(21)=0 THEN GOTO you_cant IF North%(15)<>0 THEN GOTO you_cant LET North%(15)=16 LET South%(16)=15 PRINT"You open the door."' GOTO input_loop END IF As you can see, the basic structure of this is similar to the script for unlocking the door, given above. The checks are made for the player being in one of the right rooms, the door being unlocked, and the door being already open respectively. The first two are fairly clear, but the third might need explaining:- By not defining the exit N16 in the rooms file for room 15, and S15 for room 16, the variables North%(15) and South%(16) are set to 0 and Trellis won't let the player use them. When you open the door (which comes next) you change the contents of these two variables. Therefore, if one or the other of these stores contains 0 the door must be closed - hence the check to see if North%(15) contains 0. So having made the various checks, the door can be opened by changing the contents of North%(15) (which leads to room 16) and South%(16) (which leads to room 15). A message is printed, and a jump is made to the input routine. The player can now move between the rooms freely. Trellis will handle this. It's worth remembering that you can also redefine the room descriptions, by using LET Room$( )="..." To put this in the context of the above example, the original room descriptions could have included the messages about a closed door. When the door was opened, you could have changed the contents (of both room descriptions) to include a message about an open door. If you look at the examples above, you will notice that I am allowing the player to open the door from both of the rooms it connects. You might think that if this is one of the puzzles in the game, the player will need to get past the door after first finding the key - which means he/she will only reach the door from the one side, so checking for both rooms is not necessary. This is not so. If the player can unlock and open the door, it should also be possible to close and lock the door. The player could unlock the door, open it, go through it, close it and lock it again. This means he/she is now on the other side of the locked door, where the same procedures can be applied. The script for closing and locking the door is very similar to that given above. I'll leave it to you to try and work it out for yourselves. Obviously, the script given in this example would need to be expanded if there were more than one door. Another easy type of puzzle to include are creatures (which, for the purposes of adventure games, can be anything you like, such as another person, a monster or even a robot of some kind - the word 'creature' is used for convenience.) If a creature in your game is blocking an exit, so that the player can't get through until it has been killed, the creature can almost be programmed in as a door! The only exceptions are that the TScript program must check the condition of the creature (alive or dead) and inform the player as is appropriate. In terms of the example doors above, then, the script might become:- IF Store%(3)=15 THEN PRINT" There is a demonic creature to the North." IF Store%(21)=1 THEN PRINT" It is blocking your exit in that direction." IF Store%(21)=0 THEN PRINT" It is dead." END IF IF Store%(3)=16 THEN PRINT" There is a demonic creature to the South. It is dead." Now, store 21 is being used to represent whether or not the creature is dead (0) or alive (1). Also, notice that the IF/END IF structure has been dropped from location 16 and replaced with a simple IF THEN. This is because the player can't get from 15 to 16 until the creature is killed so, if the player is at 16 we know the creature is dead. The exception to this would be if there were another route the player could take to get to location 16, in which case the creature wouldn't present much of a problem anyway! The next section of script used above might become:- IF FNSaid("KILL") AND FNSaid("CREATURE") THEN IF Store%(3)<>15 THEN GOTO you_cant IF Store%(21)<>1 THEN GOTO you_cant IF Location%(2)<>0 THEN GOTO you_cant LET Store%(21)=0 PRINT" You attack the creature with your sword. You kill it." GOTO what_next END IF The first thing you will notice is that the player commands checked for have been replaced - you don't want to pick a fight with the command UNLOCK DOOR! This script will jump to the 'you_cant' routine in three cases: if the player is not at location 15, if the creature is not alive, and if the player is not carrying a sword (which I have assumed to be object number 2). Otherwise the creature is killed. With the code for doors described above, there were two stages to opening a door - unlocking it, then opening it. With creatures there is just one stage - killing it. So the next section of code must enable the player to move between the rooms if the creature is dead. Again, if the player is at location 16 the creature MUST be dead. This means that a link south (S15) can be included in the rooms file definition for location 16 to enable Trellis to deal with that direction automatically. To move North from location 15 to 16, the easiest method is to provide a link North (N16) and put this section of code somewhere after the INPUT command. IF FNsaid("NORTH") THEN IF Store%(3)=15 AND Store%(21)=1 THEN GOTO you_cant GOTO process_command END IF If the player enters NORTH, the software will give the 'you cant' message if he/she is at location 15 with the creature alive. Otherwise, control is passed to the routine labelled 'process_command' which simply calls COMMAND and lets Trellis do the work. The creature is now implemented, but using a method based loosely on doors. This can be simplified further by defining the creature as two objects - the creature and a dead creature. This means that the store need not be used to represent whether or not the creature is dead or alive - with objects you check to see which object is in the room, creature or corpse:- IF Location%(6)=Store%(3) THEN PRINT "The demon blocks the way North." This is much simpler than before, because Trellis will tell the player if the creature is 'here' automatically, so you need only check that the creature is alive and inform the player that he/she can't go North because of it - which is done by comparing the creature's location (assuming it has been set up as object 6) with the players location, which is held in Store%(3). And the next section:- IF FNSaid("KILL") AND FNSaid("CREATURE") THEN IF Location%(6)<>Store%(3) THEN GOTO you_cant IF Location%(2)<>0 THEN GOTO you_cant LET Location%(6)=-1 LET Location%(7)=15 PRINT" You attack the creature with your sword. You kill it." GOTO what_next END IF This time, you don't even check that the player is in room 15 since, if the demon is in the same place as the player, that is what matters. If it is, and the player carries the sword, the creature can be killed. The creature is moved out of play, by setting its location to -1, and the corpse is moved to room 15. The final section of script, to move the player about, becomes the following:- IF FNSaid("NORTH") THEN IF Location%(6)=Store%(3) THEN GOTO you_cant GOTO process_command END IF The IF in this section is slightly simpler than in the alternative version above, which means it will run fractionally quicker - but that isn't the only advantage for using this method. By defining the creature (and it's corpse) as objects the player can examine them, thus providing more information about them. However, it probably wouldn't pay for the player to be able to pick up the creature so you should give it a weight in excess of the limit the player can carry. An additional point to remember is that you might want to make the creature more versatile than in the above example. Perhaps, when the player attacks the creature without a weapon the creature will kill the player. Or maybe the creature stays hidden until the player tries to move North, then reveals itself to stop him. Another possibility is that the creature is too strong to be killed by the player, so should be bribed - or weakened with some kind of poison. There are many possibilities. Again, the code would have to be altered if you wanted more than one creature. If you are using the 'object' method, each creature should have its own set of objects. Alternatively, use a series of flags to represent whether or not the creatures are dead or alive and, whenever the player enters a room in which there would be a creature check the appropriate flag. If the creature is alive bring the 'alive' object into the room and if dead bring the 'dead' object. This way, you only need the two objects. You may well realise by now that there are all sorts of things you could do to create a puzzle for the player to solve, and for each type of puzzle you think of there are probably a number of ways to do it. The simple ideas presented above should give you a start - the rest is up to you and your imagination.