News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_||C|-|E||

AKS - Adventure Kernel System, any one has it?

Started by ||C|-|E||, 13:57, 08 July 17

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

||C|-|E||

Hi!

I recently bought a physical copy of this book because I like to read as much as I can about old adventures, parsers and so on.

http://www.cpcwiki.eu/index.php/Writing_Adventure_Games_on_the_Amstrad_CPC_464_/_CPC_664

the PDF is freely downloadable from the University of Bristol, by the way:

https://www.cs.bris.ac.uk/~ecsnp/games/Writing%20Adventure%20Games%20on%20the%20Amstrad.pdf

The question is that it describes and implements a parser in BASIC to create your own adventure games, the AKS (Adventure Kernel System). I read the book and I must admit that I like the concept of the framework quite a lot. In my opinion nothing can beat PAWS for 128KB machines or DAAD if you want to develop something that runs in 64KB (at least nowadays), but this parser should be very easily expandable to 128KB computers and using bank switching it should be very possible to produce nice and complex games with bitmap graphics and tons of text by keeping the core of the game in one bank and the non modifiable data on the other (or others). Moreover, the source code is freely available and it can be expanded as much as you like. Of course, a caveat is that the AKS is meant to be used from Amstrad BASIC, but it should be easy enough to overcome this with an external text editor and the autotype function of emus like WinApe. I guess that it is quite slow as well, although some ASM routines could be called from the main program to speed up the most complex tasks...

Problem is that I cannot find a DSK or CDT with the listing of the AKS ready to run. Actually, I do not know if it even exists on the Internet. Does any one have it? Otherwise I could always try to type it myself, although it is quite a big program  :)

tastefulmrship

#1
I do love a type-in challenge... even at my age! ^_^


AKS Main Code.... COMPLETED!
Witch Hunt Data... COMPLETED!
CHEXSUM... COMPLETED...
BUG FIXING... working...

NOTE: I can't get the CHEXSUM program to work properly! I will have to debug the Witch Hunt adventure tomorrow or Monday as my eyes are killing me!


I'll post the .dsk when all done (unless someone already has a cdt/dsk and has posted it below!)

NOTE: Attached below. AKS.BAS is the AKS main code. AKS-WH.BAS is the "working" adventure (that runs soooo sllllooooowwwwww). CHEXSUM.BAS is the checksum calculator that doesn't work properly!

||C|-|E||


Sykobee (Briggsy)

I remember the magazine BASIC adventure type-in series's (I think there were two in ACU over the years, and one in CWTA, I didn't get Amstrad Action until later so I can't confirm there).


They pretty much ended up as a simple game engine and a lot of DATA commands that populated room description arrays, direction arrays, objects and vocabulary. And half the articles were trying to explain how to parse the player's input sensibly, and I doubt they got beyond verb [adjective] noun, heh.

tjohnson


Did you do it with a pdf to text converter????


Quote from: ||C|-|E|| on 21:33, 08 July 17
Oh Jesus, have you done it already?  :o

||C|-|E||

Quote from: SuTeKH/Epyteor on 19:33, 08 July 17
I do love a type-in challenge... even at my age! ^_^


AKS Main Code.... COMPLETED!
Witch Hunt Data... COMPLETED!
CHEXSUM... COMPLETED...
BUG FIXING... working...

NOTE: I can't get the CHEXSUM program to work properly! I will have to debug the Witch Hunt adventure tomorrow or Monday as my eyes are killing me!


I'll post the .dsk when all done (unless someone already has a cdt/dsk and has posted it below!)

NOTE: Attached below. AKS.BAS is the AKS main code. AKS-WH.BAS is the "working" adventure (that runs soooo sllllooooowwwwww). CHEXSUM.BAS is the checksum calculator that doesn't work properly!

Thank you so much! It is incredibly slow indeed  :( Let´s hope that there is still a small bug somewhere and the system was not conceived like that!!  :laugh:

tastefulmrship

#6
Quote from: ||C|-|E|| on 12:06, 09 July 17
It is incredibly slow indeed  :(  Let´s hope that there is still a small bug somewhere and the system was not conceived like that!!  :laugh:
I wish I had better news for you, but I've just gone through it all again and, other than a few description typos, it seems to be correct. If someone else could double check, to make 100% sure, then I'd be grateful.

I think the issue is that this "parser engine" is trying to do too much. The ACU/CwtA type-in adventures all had bespoke parsers and so they could pick and choose which commands and actions to include, but this one checks all possible actions against all possible objects in your current location to see if the player has picked one. If so, great! If not, then "You cannot do that!" So, if there's a lot going on, then it will slow the whole process down... making it almost unplayable!

Anyway, I have attached a new version of the adventure here with the few spelling mistakes corrected.

Sykobee (Briggsy)

Yeah, string matching is terribly slow unfortunately, especially in BASIC. That's why many parsers only check up to 3 or 4 characters if possible. O(n^2) - length of token * number of possible tokens.
And then after that you need to match the tokens against the possible actions in that room or globally. Lots of array traversing, in the end.


Sure, you could write a quick hashing algorithm and have a hashtable of verbs, nouns, etc, which scales O(1) despite the overhead of the hashing. In BASIC that's not so nice. In C or M/C it's fine, and you might store a single table of tokens, and associate a type with it, giving you more flexibility in the parser.

||C|-|E||

Quote from: tjohnson on 11:05, 09 July 17
Did you do it with a pdf to text converter? ???

I tried yesterday with different types of OCR software but, sadly, none of them was good enough...  :-X If SuTeKH/Epyteor would not had been so fast I would be probably typing it, yes...

Regarding the speed... oh well, what can we do  :( I was hoping it to be faster, to be honest, although if professional (and compiled) parsers like DAAD or PAWS only scan the first 5 letter of every word it is not by chance. I was liking this framework because it is definitely much closer to a real engine than all the rest of type-ins I have ever seen, but it would be probably necessary to implement it on C or change many things in order to make it work in a proper way  :(

Sykobee (Briggsy)

A quick win is to have your verbs/nouns/etc in a 2 level table, where you check the first letter then select an array that on average is 1/26th the length, so you do 1/26th the work. Requires some thought as to set that up in BASIC, whereas in C you'd have an array of 26 pointers to linked lists.


[Obviously you can keep on doing the above, and have your vocabulary in a tree structure instead of arrays/lists. You only need to store enough in the tree to uniquely identify that word too - e.g., SO (South) and SH (Shut) differentiates both of those full words, but add the word Shoot and you need SO, SHU, SHO in your tree. Problem is as you get deeper (+Shout -> SO, SHU, SHOO, SHOU), you need more and more memory. But the idea - store only what uniquely identifies a word - can be applied even in a BASIC array]


This is likely where the fast text adventures parsers of the 80s differentiated themselves.


So yeah, if you want speed, it's not about literal rewriting in a different language, you need to rethink the data structures for fast lookup as you are parsing the user's input character by character.


These days, things are massively more advanced - natural language processing, grammars, etc.

||C|-|E||

Nowadays, as you say, parsers are orders of magnitude better  :)  By definition, even the best 8 bit parsers tend to be quite deaf, although you can try to overcome the limitation with a huge list of synonims and plenty plenty of location specific condacts. This works quite well although it is necessary to define a series of words that will be used only for a few specific things in order to save RAM. For example, keeping EXAMINE to analyze objects and LOOK to redescribe a particular location. 


Something else that PAWS and DAAD do in order to increase the speed is to read the databases from up to bottom in every turn. The first subroutine that matches with the input from the player is executed and the reading stopped right there. It is a very simple way to define prioriries of execution and you really need to have it very present when coding the game, because it is not possible to use the standard IF/ELSE, loops or jump to different parts of the database from a subroutine  :) .

GeoffB17

Hello,


I'd be interested in looking at this.


I'm using a PCW by the way.


I've downloaded your file, but this gives me a .DSK - which I CAN access and do something with, but it's far from convenient.   A simple .ZIP of the two files would be better.


I'd need the files to be saved as ASCII, can the CPCs do that?


I'd then need to change the code as required for MALLARD BASIC.


Regarding the discussion about speed, I'd tend to be looking at indexed files (I've got one of JonB's uIDE devices, so I can handle BIG disk files).   If you need to stay with data in memory, and you've got some spare memory, you might consider indexing, and binary chop look-ups.


Depending on speed matters, I could re-do code as CBASIC compiler, or even re-do totally as C.   The latter is possible, although I have the difficulty that my work is with PC C (MS C 7.0) and this has a LOT of facilities I'm used to that are NOT in the CP/M C implementations, so quite a bit of work-around might be required.


Still, that's all part of the fun?


Geoff

||C|-|E||

If it is because you like to play with the program or expand the parser then great!  :)  otherwise, do not forget that for the PCW you have PAWS with all the bells and whistles, including graphics support  :)

GeoffB17

My interest is primarily as a programmer, especially regarding data files.    That was my profession, although I'm now substantially retired (I'm still involved with a couple of long standing systems).


I did get a copy of PAWS a while back, I tried playing with it, but I don't remember how that went.  Much more interesting when I have the code to see just what's going on.   Or supposed to be going on.


I was never much interested in graphics.   Nor did I ever believe in the suggestion that 'a picture tells a thousand words'.   I always think of things in terms of quantity of data, size of prog, performance of prog, etc, and tend more towards the idea that a few well chosen words CAN be far better (byte for byte) than any practical picture.   I remember reading a LONG time ago, someone commenting on the old C&W Colossal Caves Adventure, quoting one of the 'room' descriptions in that game and asking 'what sort of picture could ever do justice to this description?'.   Obviously, a picture COULD be done, but it would require FAR more data than the text, plus the extra time to process, AND it would make the imagination of the player quite redundant!


I'll dig out the bits of PAWS again.   Now I've got JonB's uIDE drives, it may be more practical.   Swapping floppies was a bit of a pain.


Geoff



||C|-|E||

I agree that it is great to have the source code to play. In that regard, the AKS is very nice and I think that it could be greatly improved.

About graphics and adventures, I like them if I think they fit the game and add something to it. However, I have played great adventures that were text only, so I would say that I am absolutely fine with both approaches  :) In any case, PAWS was originally graphic-less but then the graphics patch appeared as an external add-on, the parser itself does not bother you with them. Another thing you will probably like is that for the Amstrad CPC and PCW you need to code your game using PAWS scripting language instead of all the menus that the other computers have. I find this great, since you can type all the code in your favorite text editor, annotate it as much as you like, and then launch PAWS in an emu as a "compiler". During the integration of the database and the game engine PAWS gets rid of all the comments and it does not mind if you original file was 200, 300 or 700KB. Oh well, I am sure that you are well aware of this if you played with it years ago  :)

Zoe Robinson

PAWS sounds like a lot of fun to code with. I think I'll have to give it a try over GAC when I finally get time to re-write my old adventure games.

Gryzor

Anyone cares enough to do a small article on the wiki?

Powered by SMFPacks Menu Editor Mod