Regarding VPS cost, the price has come down a lot, so it's quite a bit more feasible to run something like this without completely breaking the bank, or constantly running out of memory.
Always wondered why Hell has so many objects. What happened to recycling? They at least have that wacky furnace thing, but that doesn't use garbage objects.
@27, I honestly have no idea why it has so many. Its ridiculous. Most of it, I suspect, is the NPCs.
It's insane. I wonder if these guys were high the entire time while coding it.
It's very easy, if you see a topic about BGT, simply don't reply to it.
If you're thinking about creating a topic about BGT, just don't.
Doing these things will cause all such topics to sink to oblivion.
So... The codebase is pretty archaic, and virtual exits didn't occur to them at that time. Every exit is an object, so 2 rooms with one linking exit is 4 objects. That makes up a significant chunk of it. Then there are various NPCs and monsters. Then there are all the players and their vehicles and containers and etc. Most containers can be virtualized IIRC, but I think unique items are unable to be. Other than that I'm not sure, there are probably a load of objects that could be cleaned up but aren't because people are too lazy to look through 300-400k lines of code and figure out where something isn't getting cleaned up properly etc.
Moo doesn't scale. It's fast enough but "look through the code" isn't even something you can really do. "I have to edit the game while it's live and have no version control" means that the risk of refactoring anything at all is super high. It's the ideal environment to continually accumulate code debt that can't be cleaned up. Hellmoo sucks because Moo isn't an environment in which it is possible to sanely write something like it. People go for it because the instant gratification trumps anything else at a certain skill level.
Although, now I wonder if there are actually that many objects in the database or if the max object number is just insanely high because they keep using the recycle function. Most MOOs today are set up to recycle objects and recreate them from garbage objects when needed with the recycler. The max object goes up only when an entirely new object is created due to there not being any garbage objects available for reuse. If the recycle function is used instead, then you end up with a hole in the database because that object is simply gone. I always thought the furnace system in Hell was basically a sort of recycler.
#33 (edited by Ethin 2021-02-26 01:35:36)
@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). The last problem with the server is that 99 percent of it is pure C and there is very little C++ in the code, so it doesn't use smart pointers or any actual modern C++ features, but that's not necessarily relevant to scaling.
Edit: Okay, so you can store a MOO database in a database engine like SQLite or MySQL, but it probably wouldn't be a pretty design. Something like: one table for objects, properties and verbs. I won't list the table structure here but that's probably the only way that would work, and that would be quite messy, I imagine.
#34 (edited by camlorn 2021-02-26 01:46:52)
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.
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.
@34: They're actually trying to bring Diku back as a modern codebase, believe it or not. Looks semi-promising. Here you go.
That being said, the problem with any codebase (including Evennia) is you do need to know what you're doing, and many--many--people do not and have no interest in learning. That's the same for MOO, LPC, C, C++, whatever. When the term "Spaghetti code" was invented, they had the writers of the Smaug codebase in mind, for example.
Specific to MOO, keep in mind that standard practice is to store your code somewhere outside of the MOO in case of something happening. So you could easily enough put whatever you were using external to the MOO under version control. Not ideal, but if you've decided to develop your game in MOO you've given up on ideal. But, if you stored your code externally, it would be fairly trivial to set up a dev port, copy the database over, implement your code, and see what breaks. Most developers don't, however, which is why you get changelog entries such as "fixed the problem where X fails to go boom when you do y. I think." If they'd done that and tested it first, then they'd know.
So modern MOO version control probably looks like a dev port with code that automatically checks a github repository for updates to files and integrates them if there are any. Testing can then be done, and then the same process can be manually triggered on the main game so that the code gets implemented. The files in version control would likely share similar formatting to MOO object dumps. I feel like there are probably issues I'm missing with this approach because I haven't worked with MOO in a while to know the specifics of what would go wrong, but I'm not going to actually implement the system to see. It would be an interesting experiment for anybody that would start a new project in MOO these days I guess. The most recent thing I can think of that was started in MOO is Chatmud.
Interesting project but also probably not going to get lots of traction because muds are dead outside blind players, and there's enough games for blind players to play that developing something new doesn't need to happen often.
I don't realistically expect a stable, modern codebase which can gain traction to happen at this point. I suppose it's theoretically possible that if muds were marketed specifically to blind people in some sort of professional capacity you could get a lot more players, but at the moment I'd estimate the number that do as *maybe* 5000 and muds are kind of, call it non-friendly UX I guess. Hard to articulate what I mean, other than that muds really aren't a casual thing that the average blind person looking for a game can just get into. It's all "Do you know every single feature of your screen reader and how to install these extensions and also here is how you make a trigger to block text. Good, now start memorizing command syntax" and not "you download, you click play, you're playing". Except for Alter Aeon at any rate, but even alter aeon still requires a technical aptitude that makes the barrier of entry pretty high. I've played Swamp with someone who barely knew screen readers and who was still at the point of using their synth at merely human speeds once. That can't happen much in mud land.
every once in a while there's a Wayfar or Empiremud or Dark Legacy that overturns all the conventions and does something new, but all of those one-offs typically need their own non-shareable codebase by the nature of the game.
And even then there's only so much you can do with text anyway, and that was exhausted a long time ago.
We'll keep muds alive honestly probably for the next 10 to 20 years. There's nothing like an audience with literally nowhere else to go. But alive kind of means "on life support".
yeah, I think that might work. Though you'd also have to solve migrations and stuff, which likely requires a different core because I don't think anyone doing moo is even thinking that way at all at the moment. And it doesn't solve the thing where haha oops you overwrote a field hat was modified at runtime because of the aforementioned lack of separation between code and data, and you'd not be able to roll that sort of change back unless you noticed it immediately.
I find miriani's changelog very enlightening w.r.t. the kinds of things that come up with Moo. So many "fixed doing x with y when z" entries, and very few "here's a new cool and nontrivial feature that isn't making something do emotes" entries.
As I recall Moo can be set up so that child objects point at parent objects and with Stunt you get multiple inheritance, which implies that you could get something resembling database transactions working with herculian effort that I will never put in either. But they wouldn't be anything at all resembling fast, so probably not super useful.
Wrong, there are MUDs that everyone play that have upwards of 50+ players on daily. Hell, there /is/ a modern, up to date codebase that's doing relatively wel.
I've been warned off of Evenia time and again because it is not, I repeat, /not/ a good, or responsive codebase. My source? Volund, who explained this to me last year and about the shortcomings of Evenia and why Python based things Do. Not. Work. for MU* code
#39 (edited by Lucas1853 2021-02-26 20:04:44)
I feel like this might be one of those applications where you're actually probably not going to hit any meaningful limitations with Pythohn, because it's just text. Python can handle concurrent connections as well (at least unless your mud somehow becomes popular and you get over 100 or something), so I don't really see what else would be the problem.
Regarding muds with more than 50 concurrents on average, I honestly can't think of many. Alter Aeon, Miriani (and other similar space moos for whatever weird reason), and Hellmoo might get 50 on a really good day not counting the 15-20 admins on constantly. AA and the space MOOs have high blind populations as well. Feel free to enlighten me on some others. Also I'm curious what the modern codebase you're talking about that's doing well is.
For Evenia: I'll quote Volund on this one since he's my main source of do not use Evenia:
It's slow. It's laggy. It is not straightforward to code for and there is a lot of back end fuckery going on.
Far as MU* with 100+ on..
Arx has....about 100+ on daily, uses Evenia but it is a house of cards and held together with duct tape and some very....questionable admin decisions and ruled by a MuSoapbox crowd. Which is....not a pleasant place to play, honestly. It's as toxic as it gets really, but nobody tells you directly they don't much like you.
The modern code base is Ares MUSH, that is very much modern and I know for a fact there's 20+ on your average Ares MUSH game, yes many people play several Ares MUSH games, but nontheless...
Upward of 50 players is incredibly tiny in the grand scheme of things, and incredibly huge for muds. That's important to remember. Swamp used to have 100. When I say 1000-5000 blind players of muds in the world I am accounting for two factors. First is that many of those players are playing more than one mud. Second is that there's only 20-30 muds that get over 50 concurrent players. If you don't believe me, see mudstats.com. If you want to refute those numbers, you'll need to find significantly large muds that they don't list, and they've got almost every mud that exists period. Alter Aeon is now one of the largest muds that exists, only gets 120 or so max, and is majority blind.
If another codebase is to come into being and be mature you need two things: a skilled programmer, and a reason to write it. Maybe 1% of the world is a programmer in the first place. Assume 5000 mud players. Hell, let's assume 10000. That gets you down to 100ish people who might contribute. Maybe a bit higher since playing muds and being nerdy go together. Of those, way more than half are going to be blind 16-year-olds, the same sorts of people who come here and get stuck on non-blocking sockets, and make claims like "Python can't work for muds" and stuff like that. Those people will try, then get it wrong, have a codebase that's laggy and buggy, and it all falls down. This is a big part of how we got hellcore. Of the remaining fraction, many are going to be like myself: already with a dayjob, only have weekends, etc.
Once you've got your team, you then have to do a good enough game to poach players off something else, or do good enough that you can reach new audiences. By the nature of muds and mud clients, you're not going to reach new audiences while still being a mud. All the rest of it requires producing enough content and such so that the players come. Without a flagship game, you're just throwing code into the ether. It's not like Synthizer, where I'm effectively only competing with myself and OpenALSoft. You're competing with 50 or so other options, many of which are already very full-featured (see: every mature LPC mudlib, in particular haven, discworld, and to some extent dead souls; diku; smaug; circle; etc).
It's not going to happen in other words. There will be attempts. They won't get far. Coffeemud didn't get far for exactly these reasons. Evennia didn't get far for exactly these reasons.
Evennia is shit because it's shit, not because Python. You can run under Pypy and get the performance of C if being slow is really an issue, and you don't have desktop distribution concerns so it's literally just replacing the word Python with the word Pypy at the command line. No mud in the world is multi-threaded. For some reason people in Python mud land make really bad decisions, like trying to use Twisted (Clok I believe; slows down networking by a lot for the typical mud use case) or cannibalizing Django's ORM (Evennia, randomly introduces blocking database operations because it's not for games, maybe they moved off it).
You can say what you want about Smaug, but Smaug is actually pretty good C code. So is Godwars, Diku, etc. What everyone should remember about this topic is that when the mud codebases everyone used were first written, a ton of very skilled programmers were involved. They were World of Warcraft. As muds died, the number of skilled programmers that existed died with them. New codebases don't gain traction in part because the really old ones are super capable, super stable, and amazingly fast and efficient. They were written in C only because back then C was the most advanced, portable, etc thing on the market.
It's time to stop the wishful thinking about how muds aren't effectively dead and how they can reach tons of new players and how we'll get so much amazing stuff if only thing X or Y would happen. They're dead. They had a run of something like 40 years. That's really good. It makes me melancholic sometimes to have been around for the early 2000s when even small muds still had medium-to-high double digit player counts, and the big ones could top 500. People have been trying to revive them since 2000. If the last 20 years couldn't, the next 20 years won't. Sighted people are on the verge of having experiences that are literally exactly as good as the real world both in terms of sight and sound. They're not coming back. Thre aren't enough interested blind players. BK3 and Shadow Line have more complex gameplay than 90% of muds, and by the nature of text it's the rare thing like Wayfar that can do more. The future of muds is the occasional gem that lasts for however long, and everyone else playing Alter Aeon until the end of time, basically.
You could argue that C/C++ has these same problems, but I feel like transitioning from one C++ standard is a lot smoother and easier. The language might be huge, sure, and though there might be four different ways of declaring a pointer or allocating memory, its at least consistent (if you want an example of inconsistencies, check out this article from 2017).
Perhaps my arguments are weak, perhaps not, but JS is just not a language that I can comfortably use. Something similar is with Haskell for me too, though that's more along the lines of thinking differently than with weirdness in the language and finding a ton of "wrong" ways of doing things when trying to figure out how to do something or having to use a custom compiler just to make the language a bit better. Of course, Python's dynamic typing and its type hints comes to mind, but at least with that I don't need to use a custom translator, just a type checker. I can use the same interpreter (and perhaps Python will get type checking in it sometime).
I'm not saying you should use JS.
But Moo borrows the weird prototypical inheritance, and definitely has more than one way to do things by virtue of having even less than is built into JS. Nothing like bring your own standard library. No typing. Hard to get right concurrency.
JS is more consistent than you give it credit for though, in the same way that C++ seems inconsistent to anyone who doesn't know the entire language surface area. As someone who has done C++ in anger and does know the entire language surface area, I'd take JS over it any day.
I value reliable, stable, long-lived software. I don't think that's the primary value in this community though, and maybe not yours either. The language being fun isn't what matters, at least not beyond a point. JS > C++ for reliable. JS > Moo for reliable. TS > JS for reliable. If limited only to those technologies the answer is clearly TS, though in practice I would reach for Rust or Python-with-typing first. I'm even starting to come to the terms with Go's existence these days, not from the stance of agreeing with the vast majority as to where it should be used, but from the stance of them establishing conventions like contexts which properly solve the cancellation problem and such. If they get generics I'd probably use it for some stuff.
I used to think in a "do I like this language" mode, but "is this language reliable and productive enough to get the thing done" is what actually matters: Moo is neither reliable or productive in practice. C++ is reliable in practice if and only if you know all of it and everyone else on your team also knows all of it. But what you're missing about JS/TS is that they are reasonably reliable technologies that lots of people know or can learn easily, thus the popularity. I don't really like them or intend to use them. But there is, call it a reliability hierarchy. You want to figure out what the project is, what languages are suitable, then climb the reliability hierarchy as high as you can.
To be clear I include "this code is maintainable in 5 years" in reliable, not just testing etc (I exclude Java for this reason because OOP is the only thing you can do doesn't work out that way--nothing like 10 classes for what should be 2 functions to avoid bit rot. Fight me).
Moo's popularity and good-idea-ness is primarily found among newer programmers who will always without fail land entirely on the fun side of the trade-off. But seriously, moo is entirely on the fun side, not the reliable side.
@43, fair enough. I prefer Rust myself for code though I'll dive into C++ when I need to. I've used both for serious projects (though that depends on your definition of a "serious" project), though I haven't actually been able to employ it in an organization/professional development cycle yet, though I'm working on that.
All this bashing of muds saddens me. I haven't played regularly for a while, but still like to keep my eye out in case I find something interesting.
I intend to explore Wayfar as long as it remains up, and continue looking into other games which have done unique things with the medium.
Yeah it's unfounded IMO. Yeah, if they die then they die, but they've been a part of my life for so long that I am not giving up on them until they just vanish.
It's very easy, if you see a topic about BGT, simply don't reply to it.
If you're thinking about creating a topic about BGT, just don't.
Doing these things will cause all such topics to sink to oblivion.
I'm not bashing muds. I'm pointing out that they're all but dead, and not coming back. There's a difference. Muds on the whole are a good thing for us. I got a lot of enjoyment out of them until I eventually realized that they're even worse than the stereotypical MMOs where someone plays for hours and hours for real-life money when it comes to doing the same thing repeatedly and watching numbers go up, but that took 10 years of my life and is thus on the whole worth it, since 10 years of fun isn't something to sneeze at by any means (and I imagine the same can be said for those stereotypical MMOs: it takes a long time for the originality of that sort of thing to wear off).
They've also got a quite venerable history being as all the earliest ones came out of universities, and any MMO player anywhere is only playing an MMO because muds proved the concepts. I don't know whether it's an urban legend or not, but supposedly Everquest was inspired by Diku, and if that's true--well, Everquest is still going 20 years after it first opened. I've even got a coworker who ran one once upon a time (not still up; I don't know which; probably not notable. If you were in your late teens or 20s in the 90s that was just a thing that programmer university nerds etc. did).
Hell, let's all remember a rape in cyberspace: http://www.juliandibbell.com/articles/a … yberspace/
But that doesn't change the fact that few if any of them are built using sustainable software development practices, that moo is a terrible platform to be building off of if you want anything other than a chat server with added scripting and maybe the occasional player-written text adventure, that most people who could do better have dayjobs, that few if any of them have any sort of plan for longevity, and that the best that can be hoped for is that they hold steady in terms of players.
Yeah guys, I don't think he's bashing either, he's just pointing out the uncomfortable truths that most of us have probably at least thought about a bit at some point anyway.
I don't get the impression that what he's saying is even aimed at players, it's just his side of the debate when it comes to the value of creating a new codebase that's actually worth something at this point in the MUD timeline.
Aaah. Body paaarts.
#50 (edited by defender 2021-03-03 18:58:34)
If you type map biome to see what's around, then type nearby followed by a biome name from that list, it will then show you which of those are in range and where.
Getting the materials and prospector handbooks from the complex helps knowing where to look for certain things, but scanning with your harvester tools in various environments with lots of things in the room description will also help you recognize what's what.
Look especially for tiles with buildings or objects in them, or drop something in a tile with a valuable biome, then come back the next day.
The longer something (even a player) sits in a tile, the longer that tile is kept filled up with materials, and isn't recycled.
In general though, things like deserts, flatlands, and mountains have more minerals, forests, heavy forests, jungles, and swamps have more plants, while deserts, forests, and oceans have more energy.
For certain materials, going to a moon is a quick way to find lots of them, particularly crystals.
Aaah. Body paaarts.