LAND - A Multi-User Dungeon (well almost)

[fuzzel]

With reference to my post in "Programming: Assembly Language Text Adventure", here's the opening screen. I'm now a bit dubious as to whether I will be able to cram all 346 locations in....

[0xC0DE]

Good luck! Will be following your progress with interest.

[Lardo Boffin]

It would complicate things a bit but if you broke the game up into 16K chunks that were loaded on demand you not have to worry so much about RAM.

[tricky]

How many strings do you have?
How big are they in total?
How much room do you have to store them?

[AndyF]

That's looking good.

When I tried to convert Colossal Cave, I ran out of memory via Quill despite much truncating of texts I was not able to fit it in, in any sensible way although I ran out of time rather than patience (this was about 4 years ago mind you!)

The idea of loading in a 16K chunk from disc or perhaps SWRam if available is a very good one if practical to do so.

[Elminster]

I wrote a mud style system with dynamic object creation in C as my degree project,many years ago, was huge when compiled. Interested to C what you can do on Beeb in assembler.

[fuzzel]

This is definitely proving to be a lot less straightforward than I'd originally envisaged ! My first problem is how my program prints location text. In my Lords of Time level 1 test program I stored sequentially each compressed location text in a 256 byte memory block followed by the directions and had a lookup table which was used each time a new location was entered or look was typed. The decompression routine then sent the location text to the &6E00 memory block where the wordwrap routine printed the text onto the screen. This worked well and was simple to program and I wonder whether it is a coincidence that Level 9's locations had less than 256 bytes each. However, location 1, and indeed lots of LAND locations, require more than 256 bytes so I would need to modify both the decompression routine to handle larger blocks of text and also the wordwrap routine, reserving a larger area of memory for wordwrap, say &6D00 to &6FFF.
The next problem is the fact that the number of locations exceeds 256. At present I only need one byte of memory to store the location number, but for LAND I will need two. My first thoughts on a way to overcome this would be to divide the game up into four areas or zones, each with it's own location number and these would be stored in the four available SW Ram banks in Beebem. I'll produce a map of the entire game (should be fun sticking together sheets of a4 with sellotape) and hopefully I can find a small number of "bridging" locations where you step from one zone to another, switching between SW Ram banks at the same time. The most time consuming and annoying element of this will be that, as you can imagine, there are lots of occasions when programming where I will need to check the location number and this will complicate things somewhat (doable but irritating).
This leads me on to questions of memory. Hopefully if I use the SW ram banks for the locations this will free up quite a bit of room for messages and the program. In answer to Tricky's question above I'll get to work now with a pen and paper and a brew....

[fuzzel]

Hi Tricky, storage requirements as follows. I'm glad you asked the question (fail to plan, plan to fail and all that)....

Rooms = 341. Storage required = 89k or 60k with compression (33% saving). Directions will take it up to 64k so I will need to use the 4 x 16k SW ram banks. If I want to use more than the 4 SW ram banks (4-7) can Beebem oblige ?

Messages including object descriptions = 400 = 55k - this will be a problem, I will need more SW Ram Banks.

Objects including mobiles = 118.

The program itself after freeing up ram from locations and possibly messages should be ok I would think.

I could always strip out some text if required but this would not be ideal as I want a complete unadulterated conversion.

btw, if you want to know how I managed to print the first location in the screen image above when I said each location was restricted to 255 bytes, I cheated by adding a message to be printed every time you visit that location which contained the extra text.

[fuzzel]

After further consideration I think I'm being overly ambitious with my previous plan. I think I'll stick to 256 locations and a maximum of 256 characters of text per location. That should do and it means I can use my template program. I do like the idea however of utilising the 4 SW ram banks for locations and would be interested to know if any of the other rom banks can be used as ram banks. Note that any data I store will only need to be read only so I presume there's a way of creating roms which would also do the trick ?

[lurkio]

Please ignore the following comments if they're retreading old ground or just plain useless!

... location 1, and indeed lots of LAND locations, require more than 256 bytes so I would need to modify both the decompression routine to handle larger blocks of text and also the wordwrap routine, reserving a larger area of memory for wordwrap, say &6D00 to &6FFF.

Can you not split each overlong room description into two (or more) Pages (i.e. two or more 256-byte blocks)? And then run your existing text-decompression and -wordwrap routine repeatedly -- i.e. once per Page of text?

The next problem is the fact that the number of locations exceeds 256.

I'm probably being very naive, but can't you just store the location number in two bytes instead of one?

This leads me on to questions of memory. Hopefully if I use the SW ram banks for the locations this will free up quite a bit of room for messages and the program.

Have you decided not to store any data on disc (rather than in RAM)?

[tricky]

I think you can add another four banks in cartridges, or presumably use them as ROM.

[fuzzel]

Lurkio wrote: I'm probably being very naive, but can't you just store the location number in two bytes instead of one?

You can but checking the location number is probably the most common test in an adventure program and you're basically doubling the code. I suppose it's more annoying than anything, the extra bytes probably wouldn't add up to a great deal.

[fuzzel]

Lardo Boffin wrote:
It would complicate things a bit but if you broke the game up into 16K chunks that were loaded on demand you not have to worry so much about RAM.

Lurkio wrote:
Have you decided not to store any data on disc (rather than in RAM)?

I feel like there's a bit of pressure on me to utilise disc space rather than SW ram! My reason for plumping for SW ram is that it is available in a number of 16k blocks which don't impinge upon the BBC's 32k standard ram which I can reserve for my main program. It would also be faster than using the disc where I imagine I would have to create lots of individual files to load into ram when needed. I know that as a peripheral, disc drives were virtually ubiquitous, whereas SW ram was much less commonly used (I imagine) so I can understand a preference for discs.
There is also the question of the second processor which is a complete mystery to me. Does anyone know of a feature or review of it in the Micro User or Acorn User so I can read up about it?

[Lardo Boffin]

No pressure from me! I went to the extreme of loading a lot of stuff on demand.

Loaded initially:-

Verbs and nouns
Objects
System messages (first 20 or so)
Game framework and all logic

Loaded on demand:-

All messages above 20
Room details (including message numbers and links to other rooms)

The game framework would convert what you entered into the corresponding verb etc. numbers and the logic would compare the numbers and decide what to do.
If you typed in a direction it would compare it to the loaded link data and move accordingly.
The room / link data included the numbers of one or more 256 byte messages. So the messages were then loaded as required and displayed. The messages took up the majority of the space.

On a real disc drive it was a bit slow. On an SD drive (or datacentre etc.) it was ok. On a standard co-proc connected to an SD drive it was pretty good.

Disc access was the killer. As an experiment I rewrote the whole thing in C on Arm Evaluation co-proc and given the large amount of RAM I loaded everything. It was properly fast.

[tricky]

There have been quite a few surveys of machines and I think over 50% have some SWR (16K or 32K usually) but most people don't have masters.
You will be loading from DISC/MMC/DC 99% of the time anyway and MMC is much faster than disc, sorry, don't know about DC.

I thought I had quite a good compressor for text strings, but it isn't as good as I thought:
439 game names + publishers gives 623 strings which total 36,926 bytes and encode to 19,588 bytes (53%).
This is from my menu program which draws 23 game names + publisher if available as fast as you can press a key in very little code.

[lurkio]

Lurkio wrote: Have you decided not to store any data on disc (rather than in RAM)?

I feel like there's a bit of pressure on me to utilise disc space rather than SW ram!

Absolutely no pressure from me! Please feel free to code your game in any way you wish! (I was just throwing ideas around, really.)

... It would also be faster than using the disc where I imagine I would have to create lots of individual files to load into ram when needed.

Not necessarily. Here's a text adventure game that loads individual per-room graphics (compressed with tricky's code) from a single lump of data on disc by using OSWORD &7F:

• viewtopic.php?f=40&t=12409#p158533

[fuzzel]

The sheer scale of my game means I'm thinking of it as a long term project, possibly 6 months maybe even a year given other commitments.
It's probably worth me putting together a plan and timeline which will be realistic and stop me getting stressed or disillusioned with my progress.
My first task, which I'm giving myself a month to do, is to map LAND in it's entirety. I've already done about 80 locations and have noticed there
are four sub-maps, for example the castle and the pub, which have numerous locations but within a small area of the main map (funny to think that most of this seems new to me now after 30 years, even though I wrote it!). Then, when the 300-350 locations are fully mapped, I'll try to reduce them to 256 by taking out redundant ones. There are also around 20 "dead" locations which I can replace with a message instead (do many games use locations to describe one's death?). Before I can take out any locations though I will need to understand and plot on the map(s) all of the puzzles and the locations of objects including mobiles (my printout should be enough for this). I will also need to reduce location text to 256 bytes in line with the way my program currently works (at a later date I'd like to rewrite it to incorporate the entire original game if memory permits).
One thing that will help me enormously is to transfer my LAND.TXT file which is on a PC compatible 3.5" disc to my pc so I can work sequentially through the messages by number and search for them in the MUDDL game code to find what event triggered them. Unfortunately I no longer have access to a 3.5" floppy drive so will have to purchase a usb one from somewhere (probably Amazon) - ADDED - I've just bought one for £9.99 on Amazon arriving tomorrow !

[Lardo Boffin]

My framework only has a single file for messages. Well, strictly speaking two - one is an index file and the other a big long chunk of text. The index holds a lookup address of each message for fast retrieval.

[fuzzel]

Hi Lardo, that's the way mine works too. The same principle applies for my locations. I store the low-byte at say 7A00 and the high-byte at say 7B00 and the Y register takes the message or location number.

[fuzzel]

Well, the law of unintended consequences strikes again! Following on from Lurkio's comment above, I decided to incorporate multi-blocks of text for locations and have managed to accommodate any size text now, although if you enter a location and the text is too big for the screen it scrolls down and looks rather untidy (I may need to add a VDU14 followed by VDU15 when printing text to screen). My problem is that my wordwrap routine is now not working properly and prints the last word of each text block on a new line. Better fix that next..

[fuzzel]

Note to above message - fixed wordwrap error and the location text is printing perfectly. The way I've handled multi-blocks of text is by having &FE at the end of any blocks which aren't the last block and &FF at the end of the last block of text. The program then knows whether to, after printing the block of text, go back up and do the next one (in the case of &FE) or end (&FF) and go on to get the location directions. I suppose it always pays to think through a problem thoroughly first before diving in and writing code.

[fuzzel]

I'm now attempting to store my location data in &8000 but the program is failing to read the text. I'm doing the following, can anyone help?

1. I've stored the BASIC Rom location and selected SW Ram Bank 4 (SW Ram Board is ON in Beebem and SW Ram Bank 4 is Write Enabled). This has all been done at the start of my program:
LDA&F4: STA&61: LDA#4: STA&FE30: STA&F4
2. I've then loaded my LOCS file within the Assembly program:
LDX#&D0 :LDY#&C: JSR&FFF7 (&CD0 contains the string *LOAD LOCS 8000" - I can hear this load ok.

However, the location text printed on screen is blank. I've checked that my lookup table is correctly referring to &8000 onwards. Is there a problem with *LOADing a file to &8000 even though I've done it within the assembly language program after selecting the correct rom number?
The alternative if this doesn't work is to either use a ROM which supports loading files into SW Ram (not ideal) or load the file into normal ram and move the data to &8000 (also not ideal - the point here is to save conventional memory for other things).

Further to the above, I've written a little routine which transfers the location data from the original file location &4000 to &8000 and the program works ok, i.e. it can read location data from &8000 onwards. However, I'd like to know why I can't load my file directly into SW Ram if anyone knows?

[lurkio]

I think the OS passes the *LOAD command to DFS, so your SWRAM bank will be paged out and DFS will be paged in, at &8000, which I think is why you can’t directly *LOAD a file to &8000.

[Pernod]

I think the OS passes the *LOAD command to DFS, so your SWRAM bank will be paged out and DFS will be paged in, at &8000, which I think is why you can’t directly *LOAD a file to &8000.

Agreed, how does *SRLOAD work? Does it load to RAM first, at say &2000, then move to &8000?

[lurkio]

how does *SRLOAD work? Does it load to RAM first, at say &2000, then move to &8000?

If this is the correct source then yes — looks like it does:

• http://mdfs.net/Software/CommandSrc/SROM/SRLoad.src.bas

[hoglet]

how does *SRLOAD work? Does it load to RAM first, at say &2000, then move to &8000?

If this is the correct source then yes — looks like it does:

• http://mdfs.net/Software/CommandSrc/SROM/SRLoad.src.bas

That's JGH's implementation that form part of his portable SRAM utilities. It's not the same as the implementation in the Master MOS.

As far as I know, the Master MOS implementation of *SRLOAD only uses memory between PAGE and HIMEM if you specify the Q (quick) option. If this is omitted, then the file is opened as a random access file.

See section G.7 of the Master Reference Manual Volume 1 for more details:
http://www.8bs.com/othrdnld/manuals/ess ... asref1.zip

Also, checkout OSWORD A=&43 (Load or Save to/from sideways RAM), which is documented in the same section.

Dave

[fuzzel]

Here's a quick update on my progress in the last month on LAND. I've now mapped all locations totaling 373. This caused me an initial headache because it exceeds my usual single byte memory location. However, because I'm now using 3 SW Ram banks, by looking at the map I've found convenient places where I can switch between the ram banks (i.e. bridging locations) so if you head south across the river you switch from SW Ram bank 4 to SW Ram bank 5 and back in the opposite direction. Both of these (river!) banks use locations 1-255 but for SW Ram bank 6 I've started the location numbers back at 1 again. When I include objects (and a quick tot up of the printout suggests there are well over 100) I will need an extra byte to distinguish, for example, each location 1, otherwise the same object will appear in two locations! I've also refined my text compression routine which now holds the 620 most common "words", which I calculated by putting the whole location and message text into excel and letting it calculate the most frequent ones based on lengths of between 3 and 11 characters. The most common, by the way is " the ", followed by "ing " and " you". I've created a text compression program in BBC Basic which takes up to 20 locations at a time and compresses them (I learnt a lesson here about not using arrays as they take up too much memory). The program typically takes about 5 minutes to run at x50 speed (I'd like to know how Level 9 et al managed to do theirs, did they leave it running all night or have access to a mini or mainframe ?). I then "stitch" them together from &3000 to &6FFF which creates a large 16k file for the SW Ram. Up to today I've entered 170 locations so I'm a little short of half-way. I'd say looking at the locations each one on average is at least 6 lines long so I'm guessing when finished it will be the biggest beeb text adventure out there (can anyone prove me wrong?). Once all the locations have been inputted I'll do a big walk around and then start adding the objects. Version one will be a straight single player affair where you solve all the puzzles and collect all the treasures to win. It'll get interesting though when I attempt the MUD version, introducing mobiles, or pretend multi-user adventurers who are also wandering around, picking things up and generally making a nuisance of themselves. I recently discovered Micromud for the C64 which is a very good conversion but is painfully, nay prohibitively, slow to play so that'll be my benchmark (in assembly language so far my game is lightning fast). I've included some screenshots below so you can see some random examples of the locations in the game.

The graveyard - every MUD has one!

More tea vicar ?

The ubiquitous store room

The jetty - I wonder what you're supposed to do here?

Bogged down

[lurkio]

I've included some screenshots below so you can see some random examples of the locations in the game ...

Interesting! Those location descriptions seem vaguely reminiscent of Bartle’s original MUD (of which I admittedly know very little). Is that where they’re taken from or are they unique to LAND?

[fuzzel]

From memory we wouldn't have lifted any text from MUD or its successor MIST.
We were inspired by them of course.

[leenew]

Looking good!
This is really coming together now
Can't wait to play the finished version

Lee.