★ CODING ★ 14. EXTENDING AKS ★ |
| Writing Adventure Games on the Amstrad - 00 - Contents | Writing Adventure Games on the Amstrad - 14 - Extending AKS |
While the basic AKS system does provide a complete adventure game generator, and one which can be used to create some very complex and large adventures, obviously there are additions which could be made. Everyone has their own ideas for adventure games, and for the types of actions and situations they would like to include in their own games. In this chapter we will detail some of the additions we have thought of, as well as methods for adding your own additions and extensions to the basic AKS format. We hope that you will experiment with AKS, and add your own new actions, commands and so on; you will learn a lot more about programming and adventure games writing in this way than from any commercial games designer. EXTRA ACTIONS This is the simplest addition to AKS, and the easiest to carry out. The actions included in the basic system cover all the usual adventure game requirements, but you may well wish to add other actions which cannot be constructed from several existing ones. Possible new actions might be EAT, DRINK or even SLEEP! These can be fitted into the system by inserting a new subroutine which deals with the objects the new action affects. This new subroutine is then accessed by adding a new line into the Actions routine, which tests “act$” for the new value. An example might be: IF act$ ="SL" THEN GOSUB 6000 : REM *SLeep* where the subroutine dealing with the sleep action is located at line 6000. REAL TIME ACTION Although the AKS system already provides a system of counters which can simulate a timed event, where the time is measured in turns, this may not be enough. In many games, the adventure is played in realtime, with time ticking away between turns (while the player is making his decisions and typing in a command) as well as while the computer is actively engaged in processing a command. In machine code, this is fairly easy to achieve, using interrupts to update a clock. Indeed, on some machines a realtime clock is provided by the computer's hardware. In the case of the Amstrad, we are fortunate that the Basic itself provides for interrupts, and allows us to create real time events from Basic. The way such a feature could be implemented is to alter the Initialise Counter subroutine so that it sets an interrupt timer in progress. Thus, we would use the Amstrad AFTER statement to say that a certain subroutine would execute after a certain amount of time. This would enable us to set an event going, and then the basic hardware would interrupt whatever process was going on in order to execute our event after the elapsed time. Once the event has occurred, we can return to the main program at the point we left it. It would also be possible to implement an event which occurred every so often using the basic command EVERY, instead of AFTER, as in the above example. This would cause our event subroutine to execute at regular intervals, instead of just once. One possible use for this would be intelligent characters, who could move through the game of their own accord, with their position updated after every three minutes or so. The Amstrad manual gives full details of the interrupt facilities available in Chapter 10. DON'T CARE MATCHES At the moment, we have to match all of our command input against a set of trigger phrases, with a match for each word in the trigger phrase being necessary. Wouldn't it be better if we didn't always have to match every word, but could just make sure that some of the input phrase was correct, while not caring about the rest? This is where what is known as a “don't care” indicator comes in. This enables us to say that we are not bothered about what value some part of the phrase has, just that we want that part of the phrase to be present. To add this feature to AKS, we simply have to add a "don't care" facility into the routine triggertest, which compares the phrases with the command line input. This could be a symbol such as “£”, which would represent a “don't care” word. For instance, in: T,eat £,* we are simply testing to see if the player wants to eat an object, we are not bothered about which object he is trying to eat! This facility also allows us to set unconditional triggers which will activate whenever the player inputs a command at their location, regardless of what that command is. This is done by using the trigger: T,£,* which will ignore the player's input completely. This might be useful if we wish to cause an action the first time the player tries to do something in a location, or perhaps to simulate something like the player being drunk, where it will trap any of the player's input! A RANDOM FACTOR Although, personally, we do not like random happenings in adventure games, as they can spoil an otherwise excellent adventure by taking away any skill factor, some people do like them. If you wish to add a random facility to AKS, it would be possible by adding the random facility to the conditions part of a trigger. Thus, the trigger: T,jump,*R25 would only happen 25% of the time, where the “R25” condition indicates the random 25% chance. SKILLS With the growth of roleplaying games and the increasing interest in such games, there are more and more adventure games being produced which attempt to emulate a roleplaying game. This means adding player character skills to the adventure. In AKS, this would require a character generating section, which would enable the player to create his character. You could then test these skills in the normal conditional checks to see if the player is capable of performing an action, or to see if the player is affected by an event. Again, skills do tend to add to the random elements in the adventure game, and produce a poorer adventure in our opinion. There is no way a computer can substitute for a human games master!
|
