dunebum
Clueless newb
Smells like beer and sweat
Posts: 107
|
Post by dunebum on Mar 20, 2017 22:52:50 GMT -5
I realize MUDs are on the way out, but I am interested in both systems administration and learning more about coding. I've configured a few codebases from source, logged in and poked around as an admin/implementor, but I'm not sure which one I'd like to play around with long term. I've got a few VPS' setup running various Valve games, but those are stupid easy to setup and manage on Linux platforms. I'd like a challenge.
If you were start out building a new mud, what codebase would you use, and why?
Which are actively being developed still?
Have you coded on one, built on one you like, and would recommend?
|
|
A Girl
staff puppet account
"And what do you say to Staff?" "Not today."
Posts: 35
|
Post by A Girl on Mar 21, 2017 7:17:11 GMT -5
The only codebase I have managed to get to successfully compile is coffeemud. It is mostly Java and still developing with a vast array of bells and whistles. The GUI on the browser tool for building is easy to use and the map on it is nice to work with though in game itself the building is similar enough that experience with an olc builder command set will get you pretty far. It lacks in a lot of tools that would work well in am rpi like emote targeting and crafting though the exp, levels, and even classes can all be disabled. Out of the box you really only have to worry about having Java up to date then fixing your class path and running the build and mud batch files from command prompt, then you should be able to log in, that simple. I like a lot of the variables and scripts and environmental type stuff that is already in but the codebase itself is huge and seems to intimidate even experienced coders to a degree because it is so vast.
|
|
|
Post by BitterFlashback on Mar 22, 2017 15:46:14 GMT -5
If you were start out building a new mud, what codebase would you use, and why? I would write one from scratch in C++ with support for some scripting language or another so that not all changes would require a recompile. As to why I would start from scratch: I do not trust other programmers and I have seen almost no features that seem screamingly obvious to me as a long-time player show up in the existing code bases.
|
|
julio
Displaced Tuluki
Posts: 270
|
Post by julio on Mar 29, 2017 14:38:18 GMT -5
From scratch? Is that even possible? I'm going to stick to medicine.
|
|
|
Post by BitterFlashback on Mar 29, 2017 17:21:10 GMT -5
Of course it's possible. Codebases have to start from somewhere in the past where someone made something from nothing. MUDs aren't even that complicated as programs go. The reason it probably doesn't seem that way is MUDs tend to be something newer programmers make as part of the learning process, so they make a lot of short-sighted mistakes they wouldn't make down the line.
There's also a lot of reuse of bad code because people just want to get something working as soon as possible (to avoid losing their momentum) with the idea they'll just add/fix what they need down the line, but they're still just welding Ferrari parts onto the sides of a beat-up old van. The more invested you get in just making your game work in a bad codebase, the harder it is to transition to a new codebase.
|
|
dcdc
Shartist
Posts: 531
|
Post by dcdc on Mar 29, 2017 18:46:25 GMT -5
Bitter is a legit programmer.
Sad part is, though correct me if I'm wrong. Must of us aren't.
Which is usually the biggest hurdle.
Though I guess it's worth to try if your interested. I tried coding and found I simply don't have interest nor the brain for it.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Mar 29, 2017 19:22:49 GMT -5
If you were start out building a new mud, what codebase would you use, and why? I would write one from scratch in C++ with support for some scripting language or another so that not all changes would require a recompile. As to why I would start from scratch: I do not trust other programmers and I have seen almost no features that seem screamingly obvious to me as a long-time player show up in the existing code bases. Evennia is "built on top of the Twisted library using the Django framework." That's pretty web integrated - what other features seem screamingly obvious but aren't present? I didn't like coffeemud but it seemed pretty web GUI driven.
|
|
julio
Displaced Tuluki
Posts: 270
|
Post by julio on Mar 30, 2017 8:29:11 GMT -5
Well, if Bitter decides to code a new game from scratch, I'll order him a pizza.
|
|
|
Post by BitterFlashback on Apr 7, 2017 20:22:31 GMT -5
Evennia is "built on top of the Twisted library using the Django framework." That's pretty web integrated - what other features seem screamingly obvious but aren't present? I think we're going to be talking past each other a little bit, so please understand it may take a couple tries before we're on the same page and I'm not dodging the question. I looked at their website to check out their features. The only web integration I could find was they had a MUD client that runs off a site. It looks like the MUD server itself can be piggy-backed on web services (negating the requirement you have access permissions to compile an execute a program), but that's not really what you'd call web integrated. Web integrated means your thing --which itself is not a website-- can also be utilized through a website in some manner or another. I'd rather not divulge all of my ideas, but let me use Arm as an example. You log into the MUD and create a character. An email gets sent to the MUD account. Some staffer logs into the MUD and reads your thing, then types something to approve or reject the character application. Even with Arm running off flat files instead of a database, there's nothing stopping someone from integrating that into the website. You would be given the option of logging into the Arm website and creating your character there with a text area instead of having to type everything in one line at a time. Likewise, a staffer could see all of the character apps from the website, regardless of where players applied from. All of that could piggy-back on the MUD's functionality or just bypass so the end result is indistinguishable from logging into the MUD to do it. Everything would hit the data directly, so you wouldn't wind up checking for things in two places, you'd just be able to do things from two places.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Apr 13, 2017 19:27:37 GMT -5
Evennia is "built on top of the Twisted library using the Django framework." That's pretty web integrated - what other features seem screamingly obvious but aren't present? I think we're going to be talking past each other a little bit, so please understand it may take a couple tries before we're on the same page and I'm not dodging the question. I looked at their website to check out their features. The only web integration I could find was they had a MUD client that runs off a site. It looks like the MUD server itself can be piggy-backed on web services (negating the requirement you have access permissions to compile an execute a program), but that's not really what you'd call web integrated. Web integrated means your thing --which itself is not a website-- can also be utilized through a website in some manner or another. I'd rather not divulge all of my ideas, but let me use Arm as an example. You log into the MUD and create a character. An email gets sent to the MUD account. Some staffer logs into the MUD and reads your thing, then types something to approve or reject the character application. Even with Arm running off flat files instead of a database, there's nothing stopping someone from integrating that into the website. You would be given the option of logging into the Arm website and creating your character there with a text area instead of having to type everything in one line at a time. Likewise, a staffer could see all of the character apps from the website, regardless of where players applied from. All of that could piggy-back on the MUD's functionality or just bypass so the end result is indistinguishable from logging into the MUD to do it. Everything would hit the data directly, so you wouldn't wind up checking for things in two places, you'd just be able to do things from two places. "We also run the webserver in the same process as the game server which means they both have access to the same database without needing to worry about caching or race conditions - this allows for easy integration of your game with its web presence. You could run the web presence under some other stand-alone webserver if you wanted, by all means - there is just no real reason to do so for most use cases." To expand on that: "Always full persistence -> Semi/Full persistence In Evennia trunk, everything has to be saved back/from the database at all times, also if you just need a temporary storage that you’ll use only once, one second from now. This enforced full persistency is a good thing for most cases - especially for web-integration, where you want the world to be consistent regardless of from where you are accessing it. | Devel offer the ability to yourself decide this; since semi-persistent variables can be stored on objects (see previous section). What actually happens is that such variables are stored on a normal python object called ndb (non-database), which is transparently accessed. This does not touch the database at all. Evennia-devel offers a setting FULL_PERSISTENCE that switches how the server operates. With this off, you have to explicitly assign attributes to database storage with e.g. obj.db.attr = value, whereas normal assignment (obj.attr = value) will be stored non-persistent. With FULL_PERSISTENT on however, the roles are reversed. Doing obj.attr = value will now actually be saving to database, and you have to explicitly do obj.ndb.attr = value if you want non-persistence. In the end it’s a matter of taste and of what kind of game/features you are implementing. Default is to use full persistence (but all of the engine explicitly put out db and ndb making it work the same with both)." I could go into a much more in depth writeup, but... Basically: 1) Yes, it really truly is web integrated - if web integrated seamless access to the same resources whether approaching from the front-end or not, which is how I think it's being used. That means you can do what you want (implement) from a friendly UI perspective with no hassle, which is the point right? You don't have to have glue code or otherwise make workarounds to set up something to get info back and forth from a and b. If that's not the point of 'web integrated' I guess I'm unsure what is. 2) Django is "A complete high-level web framework that encourages rapid development and clean, pragmatic design." Also, Python. You're using the same language for your frontend as you are in your MUD. And again, there's no trouble accessing your database from there. 3) In conclusion, pretty much everything that could be done has been done to make everything mesh seamlessly together across the board. ¯\_(ツ)_/¯
|
|
|
Post by BitterFlashback on Apr 14, 2017 14:11:48 GMT -5
I could go into a much more in depth writeup, but... Basically: 1) Yes, it really truly is web integrated - if web integrated seamless access to the same resources whether approaching from the front-end or not, which is how I think it's being used. That means you can do what you want (implement) from a friendly UI perspective with no hassle, which is the point right? You don't have to have glue code or otherwise make workarounds to set up something to get info back and forth from a and b. If that's not the point of 'web integrated' I guess I'm unsure what is. 2) Django is "A complete high-level web framework that encourages rapid development and clean, pragmatic design." Also, Python. You're using the same language for your frontend as you are in your MUD. And again, there's no trouble accessing your database from there. 3) In conclusion, pretty much everything that could be done has been done to make everything mesh seamlessly together across the board. ¯\_(ツ)_/¯ Yeah, I got all that, but what you're missing is it isn't web-integrated. Everything you copied over was about how it is capable of having web-integration features created for it by you.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Apr 14, 2017 20:18:20 GMT -5
I could go into a much more in depth writeup, but... Basically: 1) Yes, it really truly is web integrated - if web integrated seamless access to the same resources whether approaching from the front-end or not, which is how I think it's being used. That means you can do what you want (implement) from a friendly UI perspective with no hassle, which is the point right? You don't have to have glue code or otherwise make workarounds to set up something to get info back and forth from a and b. If that's not the point of 'web integrated' I guess I'm unsure what is. 2) Django is "A complete high-level web framework that encourages rapid development and clean, pragmatic design." Also, Python. You're using the same language for your frontend as you are in your MUD. And again, there's no trouble accessing your database from there. 3) In conclusion, pretty much everything that could be done has been done to make everything mesh seamlessly together across the board. ¯\_(ツ)_/¯ Yeah, I got all that, but what you're missing is it isn't web-integrated. Everything you copied over was about how it is capable of having web-integration features created for it by you. I'll split that hair into thirds. It's a given that Evennia isn't a to go ready setup for any given use case. It's meant to be a very logical starting point if you want to start off right without going from scratch, which it does well. So you're right about that. We're talking about the structure here. That's what web integrated is describing. There are two parts to that, how things relate to each other and how future things are meant to fit in. It is web integrated in both senses. Yup what's there to play with on the web ui is sparse, but not non-existent. You'd want to slap on forms and stuff for creating and managing specific types of data: Django comes with a built-in admin website. This is accessible by clicking the 'admin' button from your game website. The admin site allows you to see, edit and create objects in your database from a graphical interface. Your data is accessible from both ends freshly out of the box. When you add some data, you're not going to have to do additional steps to access it from the web UI or the other way around. When examining a codebase where the mud isn't integrated with the web UI, meaning data is not synced seamlessly, I would describe that codebase as not being web integrated. If some types of data sync I would call it partially web integrated, etc. etc. I think I got the answer 'secret sauce' to this, but having basically acknowledged that it's web integrated so far as it has been developed, why go from scratch instead of going from here?
|
|
|
Post by BitterFlashback on Apr 14, 2017 22:28:32 GMT -5
We're talking about the structure here. That's what web integrated is describing. No, it's not. Web-integrated doesn't mean "can be integrated with the web, maybe, if you program all the features yourself." It's not a future tense adjective. This all started because you asked me what I meant when I was rambling about obvious features not being in other people's code bases. Telling me this MUD would let me add those features reinforces my point it's missing them.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Apr 14, 2017 23:47:25 GMT -5
We're talking about the structure here. That's what web integrated is describing. No, it's not. Web-integrated doesn't mean "can be integrated with the web, maybe, if you program all the features yourself." It's not a future tense adjective. This all started because you asked me what I meant when I was rambling about obvious features not being in other people's code bases. Telling me this MUD would let me add those features reinforces my point it's missing them. ... I just lost a really long reply to this. Trying to decide if I care enough to type it back up again. We'll see. I clicked send and the site wanted me to prove I wasn't a bot because of my VPN. Didn't get anything back after.
|
|
|
Post by BitterFlashback on Apr 15, 2017 9:54:59 GMT -5
I looked over Evannia's features quite thoroughly. I didn't see any web integration features that are included with the codebase and you've yet to list a single example of one.
Regardless, I don't see how we wound up fixated on web integration. You were the one who brought it up. There are a lot of obvious features I haven't seen that have nothing to do with linking a MUD's database with its website/forum. To keep it vague, things like forensic support, character reputation, or really any map system that isn't built on the concept of rooms.
|
|