Hmm, also if you were to make it true multi-player you'd have to store visited/not-visited on a player by player basis for each room, and this would soon become a big memory overhead as it wouldn't fit in your spare byte.
You're quite right, I hadn't actually thought that through yet but it would probably be prohibitive in terms of memory usage.
After having a couple of weeks off writing LAND (which has been rather welcome as it's been a fairly intense 6 months so far) I thought I'd put together another to-do list before officially releasing the game. Unfortunately, my progress towards completion will now be slowed down somewhat, I have to help my daughter with her GCSE revision so I'm not sure when I'll manage to get it finished. Here's what I need to do to reach the finish line.
Single User Version - this will be the initial release. The multi-user aspects of the game will involve me getting to grips with Econet / RS232 from a standing start so I'll do that version later.
1. I need to restructure the code, there is far too much JMPing around so I'll need to replace them with subroutines (JSRs and RTSs) where I can. Does anyone know how many nested subroutines assembly language on the beeb allows and what sort of error you get if you exceed it?
2. I need to check through all the messages in the printout and ensure I include them. I still have plenty SWR to accommodate them. Some messages relate to the multi-user version so these can be left out for the moment.
3. I still have a maze puzzle to do which is more complicated than simply finding your way out of identically described rooms. This will take a bit of thinking through.
4. On the Viking island there's a puzzle including a boulder and I'm not sure based on the code in the printout how this works. Unfortunately the DEC-10 at the University of Essex has long seen turned to rust so I can't actually play the original game to see how it works.
5. The scoring system works and to give the game a MUD flavour I'll assign a ranking eg novice, magician, wizard as your score passes various milestones. MUDs allow the option of entering a name and choosing your sex so I may or may not incorporate these elements on this version.
Another MUD element is health, stamina, etc for combat mode. Again I may leave this for the multi-user version. However, there are monsters in the game, some of which are standard objects you don't fight but just have to eliminate by solving a puzzle and there are others which can wander around. I need to decide whether its worth incorporating the combat mode so you can fight them or just have them as static characters for show at various locations. I'm keen to get a playable version out so may switch this to the MUD version.
6. Save game facility. I've reserved a part of memory where the game variables can be stored so a save file can be created. However, the locations are stored in sideways ram including an extra byte for each location, for example whether you've visited the location before, which can change during the game (see above posts) and I haven't the memory to have this byte saved so I'll need to work out what to do here.
7. To add atmosphere to the game I'm going to include weather. I've not started on this yet but it is in the original so I'll include it. I don't think it affects any puzzles but it will improve the game.
8. Once the above have been done I'll do some thorough testing. Not just typos but at each puzzle trying various obvious things and determining whether to include a response or not. Again, do I remain faithful to the original and leave improvements out or add a few extras for playability?
9. Release game and start work on the MUD version. Alternatively, start work on the second in the trilogy (MUD or MIST) - now that I have the basic adventure system coded it'll be a massive temptation to start work on the next game.