Re: Suggestions for Wayfar 1444 relaunch welcome
@31, how exactly would you implement version control on a game that's supposed to be live-edited? Yeah, you could make objects versioned, but then you'd need to store *every* version of the object, its properties, verbs, permissions, verb code, and so on. Sure, you could lower the consumption a little by deduplicating things like properties if they haven't changed between versions but, again, that would only bloat the database format even more than it already is. You can't really store the MOO database in an actual database engine, because MOO isn't designed in that manner, and you'd completely ruin the concept if you tried to design it that way.
Your argument of "look through the code" not being something you can really do makes no sense. MOO has built-in editors and tools that allow programmers and wizards to examine the code of any object they have access to. Granted, such tools are database specific, but its pretty much a prerequisite for your database to be considered good to have that functionality.
I've already covered your argument against version control -- the architecture of MOO doesn't allow for such a system, and you'd be hard-pressed to figure out how you'd even modify a MOO DB to work with that properly. It would require a complete database format rewrite for the idea of version control that your talking about. MOO does have version control in the sense of periodic database dumps, however, so it is easy to roll back to a previous version of the database if you run your server properly. In that manner, yes, MOO does have version control. Combine that with an actual VCS and your covered, not just on server code but DB dumps as well.
Finally, your last argument about MOO being "the ideal environment to continually accumulate code debt that can't be cleaned up" is subjective at best. Hellmoo is horrible in terms of design not because MOO was never designed for that system (because it is perfectly capable of simulating such a system) but because of poor database structure and management on the developers part. Hellmoo was designed long before virtual objects had even been considered, and though forks of it use WAIFs in some areas, WAIFs aren't generic enough to solve the problem completely. Toaststunt brings in the idea of anonymous objects, and though this would solve the problem if employed properly, anonymous objects have their own caveats (e.g.: if you modify a parent of an anonymous object's properties, all its anonymous descendants become invalidated; similarly, anonymous objects also must be stored in properties because they have no other way to reference them permanently). Also, it implements a color-based reference-counted garbage collector, though I have never tested this so I don't know if the implementation is actually correct. Hellmoo was designed when quite literally everything was an object, and by the time virtual objects had actually gotten traction it was far too late to go completely refactor the entire database and would've required far too much time. (Also, the programmers who wrote the code write some pretty crappy code as well, and none of them have bothered to refactor it into better code, so that certainly doesn't help.)
If Hellmoo was written today using modern software design methodologies but still using MOO, I guarantee you that it would be far different, far smaller, and far, far less cluttered. MOO is pretty powerful and you can do *a lot* if you know how. It might be going the easy route to make a game, perhaps, but there have been fantastic successes made with it, and quibbling over whether its the easy way or not is just semantics at this point.
You are right, however, that MOO doesn't scale in the sense of system utilization. Toaststunt recently introduced the ability to thread builtins, making it possible for a verb to run a builtin on a separate thread. It does this via connection handles, with each handle being assigned a mutex. (I actually think this is a pretty clever design myself, though it does have obvious limitations, like being only usable on verbs that run on network connections and not on verbs that run independently of the network.) However, MOO still can't utilize SMP setups, though that may be harder to do given it has to go through the OS for that. It also uses a custom thread pool implementation (this one, in fact).
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
