Re: Sandbox MUD
Good points, @camlorn.
Unlike LambdaMOO, objects are not required to be persisted in memory. They are only instantiated when needed, and discarded afterwards. I do have a cache for speed, but that can be managed within whatever the memory constraints are. The whole object persistence layer is abstracted behind an interface. Each object is described via a URI, and that URI contains which persistence store to use to retrieve it. For the reference model, there is a disk model for persistent objects, and a memory model for temporary ones. One reason for this is that some of my ideas (a Star Lanes port, or if I resurrect Six Thieves or Star Trade) have procedural generated landscapes. On feature people liked in Six Swords was that you could explore the entire islands of Ireland and Iceland in the game. This would allow for implementation of that (or infinite landscapes if completely generated) without overwhelming resources requirements.
It wouldn't be too hard to be able to checkpoint the whole world, for static rollback positions. But, yes, it gets a little trickier with subsections of the world and there is much I would re-implement to get things the way I want them, but I'm not up for re-implementing Git! That said, though, I'll think about the idea that you could point to a repository as the source for your scripts, instead of actually putting them in-line.
Right now there is no multi-threading. And, yes, you are entirely right that adding that would open the gate to a world of problems. Definitely one of those "approach with caution" sort of things.
I have a lot of ideas that I've accumulated since I started the audio games stuff, and I didn't want to just regurgitate them all into an endless post that no one would read. But I'm happy to go into more detail and you can correct me if there's something that does it already. I'll be the first to admit that I don't have exhaustive knowledge of everything that's out there.
The MUD cores I've seen out there seem pretty static and finite. I tend to gravitate towards writing open world type games with either vast or infinite landscapes. I like sandbox styles games because I want to give users more creative control, but that has a lot of the problems you mention.
I put a lot of work (and lines of code) into the back end of my Alexa games to cover the sort of things ironcross32 mentions. This kind of breaks down into two major areas: input and output.
On the input side, voice recognition is not an exact science. Alexa, as many people complain, doesn't always get exactly what you say, to say nothing of homonyms. There's a bunch of stuff I've done on the voice side to deal with that like fuzzy matching and phonetic matching. Right now, for example, I stuck into the Sandbox an analog of my late lamented pet cat Khol. Now, if this is being read out by a screen reader I don't think the user is going to be able to distinguish between Khol, Coal, Cole, or Kohl. The stupid regex matcher I have there right now isn't either. My understanding is that most MUD engines are still primarily geared toward sighted users, and don't do that sort of matching. I have the tools to make this better, and with my own platform I can add that in.
For output, on the voice side, I have stuff that lets you declare different parts of your output to be within certain verbosity levels. The system tracks how often you've heard things, and can scale it back as you become more familiar. All strings are externalized, nominally to allow for translation, which I could never afford, but more usefully it forces the coding to refer to everything by identifier. That allows for alternative text to be supplied and randomly delivered, decreasing the monotony of output. Similarly cross references and inclusion can be done that makes it easier to build up complex output.
Sort of between those two categories is discoverability. In my voice back end I can tag certain commands as having likely commands that are likely to be subsequently invoked. If the user hasn't been told about them before, then one of them is mentioned. Like the verbosity, this decays over time based on how often the user has heard the prompt and how often they have used the undiscovered command. This was critical is voice since long dumps of command options are just way too tedious when read out.
So, overall, I want the toolbox of stuff that I needed to have for voice available for text adventure type games. If the primary audience is people with screen readers, much of what I needed to do for voice would provide good usability there as well. I've already got all the code. I just have to move it over. If there are platforms that do much of this in an easy way, then I guess I don't need to.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
