Re: Sandbox MUD
@jjaquinta
You can solve the entire input problem by just supporting tab completion and telling us that you support tab completion. Maybe I don't know how to spell something but it's not hard to guess that it starts with a specific letter or set of letters and tab. I'm going to guess that you're sighted, and have found your way to writing games for blind people through some path. The problems you think exist don't exist unless you're going to block us from reviewing the output to check the spelling of things. You can go very far with soundex and "did you mean...". Beyond that you get seriously diminishing returns.
There was a mud called Wayfar 1444, built on top of Moo. It was exactly what you're describing. It ran fine without swapping things to disk, except that the coder who wrote it had zero programming experience and made all of his algorithms O(n^2) because he'd never heard of a tree, then it fell over (I use this example because most of this community misses that game, and it's the perfect example of what I mean about coding things poorly). There's lots of other muds that did massive outworlds without swapping to disk: medievia, Materia Magica, Empiremud, all of which are still running. People were doing what you wanted to do on servers from 20 years ago in lpmud which is definitely slower than Java. I would politely suggest that if your first thought is "I can't run a big text world without being able to offload things to disk on demand", you're really considering this wrong. Drop some of the genericity, for example inline exits into the room class, or even just say that areas are grids with tiles, and you will be able to scale the world as much as you want without having to solve these sorts of problems. You can reasonably get 1000x1000 grids into memory without even being clever in the slightest, a bit of cleverness gets you easily to 10k square, and then you can solve the rest just by calling them "planets" and making each planet a different area or continent or what have you. Just memoize your strings, you can get rooms down to (say) 100 bytes, lower if you weren't in Java or if you switch to an array of structs representation, then a 1k square of tiles is only 100mb and a 10k square of tiles is only 10gb. Both of those fit on a server fine, and if your goal is make big grid-shaped worlds you can be even more clever than that. But also, in a text world, no one will be going "wow, this 1k square is too small, I wish it were bigger", so just split it into zones, and save yourself the headache.
My point about git isn't that we need to use git, except that it kind of is. Anyone with a lot of coding experience will avoid your engine like the plague if it can't easily solve the merge conflict problem. You're re-inventing moo, which is fine, god knows we need a modern one. But lesson one from moo is that this sort of design actually prevents you from having a test port, and lesson two is that this sort of design entirely prevents you from working on a team. The road you're going down forces anyone coding content to code live against prod with no easy rollback and no easy way to collaborate without telling everyone else that you're coding on Mount Doom, don't touch it, and also god forbid that someone tries to play through the content while you're building/fixing it. Anyone experienced understands this and starts hating Moo very much, so if you want to attract experienced people you need to solve it.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
