★ CODING ★ 6. WHAT IS AKS? ★ |
| Writing Adventure Games on the Amstrad - 00 - Contents | Writing Adventure Games on the Amstrad - 06 - What is AKS? |
This section of the book describes the use of AKS — the Adventure Kernal System. This has been designed as a data driven adventure games system which enables you to change the adventure scenario data without needing any knowledge of programming and without having to modify the main driving routines. Yet, it has been written in BASIC so that you can understand and modify the data simply and easily, if you so desire. What can you use AKS for, and why would you want to use it? What are the advantages over writing your own adventures? Well, we'll try and give you an idea of the wide range of possibilities available with AKS, and the uses to which it can be put. The first and obvious use for the AKS system is to create and play your own adventure games. This section outlines the commands available in AKS and gives examples of each of them. You will find that very complex games can be created using the techniques and commands shown and that they can be developed quickly and easily, as there is no actual programming work involved. The advantage of not writing your own adventure from scratch is that we have done all the hard work for your already! There is little point in duplicating programs when you can use the time creatively to design adventure games! The fact that AKS is based on a data-driven structure means that new adventures can be constructed simply by changing the actual scenario data, without having to modify the program, or rewrite any part of it. The approach most adventure game books have advanced in the past is that of specific coding — each action and event in the game is tied to a specific piece of code which deals with that one part of the adventure alone. This is extremely inefficient, and a criminal waste of time and effort as the basis of most adventure games is exactly the same, although with different data components. The specific coding approach requires you to rewrite the whole adventure game from scratch each time you create a new scenario; the data-driven approach simply means coding your scenario data each time. Apart from designing your own adventure games without resorting to programming, the AKS system can teach you a lot of useful techniques for adventure games writing, and careful study of the program will prove extremely helpful. After you have mastered designing adventure games using AKS, you can then move on to expanding the system, using your own programming skills. We will look at the expansion possibilities of AKS in a later chapter. We have included an example AKS scenario WITCHHUNT in the book, and you might wish to buy the cassette tape version of AKS and WITCHHUNT before you read through the relevant chapters on the scenario, so that you can enjoy the game, and then study the plot details after you have finished playing it. DATA REPRESENTATION IN AKS There are basically two approaches to representing the actual scenario data for an adventure game. The first of these is to store the data as straight forward BASIC DATA statements as any ordinary program data might be stored; or to store the data in arrays, which are generated by a special data preparation program and loaded into the program from tape or disk each time it is run. There are advantages and disadvantages to both of these methods, and the method we have chosen to use with the Adventure Kernel System is the first approach. Let's look at the two methods and try to explain why we found our chosen style of game the most suitable for AKS. Advantages of readability over coding With all the scenario information stored directly in the program itself, all the data is immediately visible to the scenario designer, you can easily list the locations or objects you are interested in, without having to print out array values or load in separate programs. This advantage will be immediately evident to someone who has tried to design any adventure game using either commercial adventure creators, or other programming methods. The adventure game data can be seen as a whole using DATA statements, something which is not possible otherwise; and if you want to check just what object 16 is, there is nothing more annoying than having to go through several menus, or printing out an array. Coding the scenario within the program does mean that data cannot be easily edited or altered. Adding a location can mean having to change a large chunk of the program as well as just the locations array. Data statements mean the data can be easily added to and corrected using nothing more than the Amstrad BASIC editor, which allows you to simply alter lines of scenario data in the same way you would alter any program line. This also avoids the necessity of having to write a special editor for the data, or having to learn to use one! Not only can the data be entered and corrected more easily using this method of representation, but the whole process of debugging and developing the adventure game is speeded up. If the data is stored separately from the main adventure program and has to be loaded in to the machine each time, it is going to slow development work down enormously. Each time you edit and correct an invalid part of the adventure game, you will have to load in the data generator, load the data, edit the data, save the data, load the adventure driver, and finally load the edited data! With the AKS method you simply have to load the adventure program and your data is already there. Simply edit any data which is wrong and re-run the driver. The only time the program has to be loaded or saved is at the start and end of the design session. Clearly, the use of a separate data generator on a tape based machine is totally impractical, as most of the time will be spent swapping tapes! The other major advantage of using BASIC and a very readable form of data is that the BASIC interpreter is already resident in the machine, and avoids the necessity of loading in yet another program for each session. This is a major failing with adventure design systems where you have to load the programming "language" and the database every time you wish to use them. Disadvantages of readable data compared with coded data Despite all the advantages listed above and the fact that we have chosen this method for the AKS system, it is not totally perfect and can cause some serious problems. One problem on a lot of machines is that the data is in no way compacted. Using text compression techniques can reduce the size of the data by a significant amount. The problem is balancing the need for space against the need for readability and ease of development. Compressing text can take a lot of time, and you don't want to have to do that each time you test a new part of the adventure! On a machine with limited memory — say only 16 or 32K, the need for space is extremely pressing if the game is going to have more than just a few locations, or a reasonable number of locations and little descriptive text. In this case, text compression would probably be advisable, though it may be possible to test at least part of the adventure game before compressing the text for the final version. On a 64K machine such as the Amstrad, this is not such a problem and you are unlikely to find space a major concern while using AKS, unless you are trying to write a truly enormous adventure! The use of large amounts of uncompressed text also results in a large program, which will slow the game down. The more data the program has to scan through, the slower it will become and the use of DATA and RESTORE can slow the program by a significant amount. Adventure games are meant to be a challenge and they should keep the player occupied for at least several hours, if not days or months. However, players can often be driven to extremes by a puzzle they cannot solve and thus they may be tempted to “cheat". This is not possible on most games where the text messages and responses for the game are coded — in order to find the solution to a puzzle you will have to write a decoding routine of your own; and this can be a major puzzle in itself! However, with the AKS approach the whole idea is to have adventure puzzles, solutions, etc as visible and as easy to find as possible, so that the writer can easily debug and finish the game. This will allow any player to cheat, simply by listing the program and finding the pertinent DATA statement. On most machines this is a problem, but there is a solution on the Amstrad. Develop your game using the normal mode of files and tape handling. Once you are sure that the program is fully debugged, tested and finished, save it using the PROTECT option. This will allow other people to load in your adventure and play it, but they won't be able to break into the listing to find the solutions to problems. Keep an unprotected copy for yourself though, just in case there are any bugs left undetected! Considering the overall advantages and disadvantages, it can be seen that the use of easily read, easily edited DATA statements is the better approach for the Amstrad AKS system. The problems are far outweighed by the advantages. THE LAYOUT OF AKS AKS is designed rather like a programming environment, in that each part of the program and data has a set place in memory. The diagram in FIG 6.1 is a memory map of the AKS system, and shows you the order of data. FIGURE 6.1
MEMORY MAP OF AKS Thus, all the data is located below the AKS system, and it should be presented in the order of Locations, Objects and then Events. The end of the data section is marked simply by an F. Within each section, the data is ordered by location, object or event number in numerical, increasing order.
|
