Re: Suggestions for Wayfar 1444 relaunch welcome
@33
I'm saying that vc is a reason to avoid moo, not that it could be implemented. That said the lpc-stuyle live development process could probably play nice with git if I felt masochistic enough to try to use lpc for something.
I think you're misunderstanding the fundamental problem with moo. The fundamental problem with moo is that you can't patch the game by having a dev port and a prod port and merging your changes across. Moo just fundamentally doesn't support that sort of operation since there's no distinction between code and game data. I'm sure you can homegrow something for it but anything off the shelf/reasonable/whatever isn't going to help you. If moo did have a distinction between code and game data VC wouldn't be a problem because you'd only version control the code parts. You could also write e.g. a migrations framework. I'm sure you can write a migrations framework against moo now, but it's low value without dev ports etc.
In an environment where rolling back changes is basically impossible, comparing changes between two things is basically impossible, etc. whatever bad decisions are made are decisions you're stuck with. Moo wasn't intended for big rpg-style games. It was intended to be a chatroom/collaborative small-scale building platform. Hundreds of thousands of lines of code live-edited into place with no rollback and no tooling is not what you want to be doing.
In standard developer land, refactors to get rid of tech debt have zero risk. In moo land, refactors to get rid of tech debt have tons of risk. It is probably the case that Hellcore has too much going on to refactor the things you're mentioning, but a lot of small "we could refactor this but it will take 5x longer than it should because moo and what if we destroy data" concerns adding up over a long time does not end well.
I'm surprised that you can defend moo but hate _javascript_/Node at the same time. Moo has most of the disadvantages of Node, plus also you can't do any standard development practices on it. Absolutely nothing moo-related is conducive to producing good code for large projects. That doesn't mean that good code wasn't produced with it--good code has been produced with assembly. But it's not going to help you at all.
Moo only looks good because the alternative is C. If muds weren't dead we'd probably have good modern codebases with most of the advantages and none of the disadvantages, but the only thing I can think of with any maturity that's not in C is Evennia and Evennia is kind of an odd snowflake last I looked at it. I suppose there's Coffeemud but last I checked Coffeemud was both terrible code and horrifyingly slow and memory hungry. I get why people use moo, in other words. But then everyone turns around and is like "X in Moo is bad code", then the devs get blamed for the bad code, and no one steps back and says "you know, maybe it's moo making everything harder all the time".
Moo has its place. It's cool if you want some sort of collaborative building thing where you and all your friends hop on and build a text adventure. But trying to make some big cohesive RPG experience out of it is borderline misuse, kind of. I'm sure that back when it first came out it was more reasonable, but the rest of the world has moved on by a lot in every dimension. If Moo were so great for that then there would be a lot more big cohesive RPG experiences. Instead I think we have only ever had like 10 total. I don't mean RPI, I mean things like Alter Aeon.
But anyway I doubt I'm going to convince anyone of anything so whatever. Most of this is the kind of argument where the argument itself sounds like the things being said don't matter until you've actually had them matter in real life. I can say that if I cared to write a mud then writing the equivalent of what Moo offers without a core would be like a weekend (moo without a core is barely more than a glorified telnet server). After that, any time lost at the beginning writing the basic abstractions like rooms would be saved so many times over by not being terrified to touch things after they'd been exposed to players, having isolated dev environments, and so on and so on etc.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
