22 May, 2015, Mudder wrote in the 1st comment:
Votes: 0
Hey guys,

Been gone awhile. I thought I would poke in and see how everything is going.

I'm currently looking at new codebases and looking for something that is currently being supported so I don't have to worry about massive up-front updates.

Anything in a high level language is preferable: Python, Ruby, etc.

EDIT: I'd like to add the caveat that I have grown weary of legacy systems. Any base that is elegant and properly written is a major, major plus.

I'll attempt to start the discussion:
  • nakedMUD doesn't seem to have a community anymore?
  • What about teensyMUD?
  • Anyone know about RanvierMUD or similar node.js server?
22 May, 2015, plamzi wrote in the 2nd comment:
Votes: 0
Mudder said:
Anyone know about RanvierMUD or similar node.js server?


https://github.com/plamzi/Havoc
23 May, 2015, Idealiad wrote in the 3rd comment:
Votes: 0
Evennia is turning out well lately.
24 May, 2015, Tyche wrote in the 4th comment:
Votes: 0
Mudder said:
What about teensyMUD?


It was updated to run on Ruby 1.93
If it still works, it's probably well maintained. ;-)
25 May, 2015, donky wrote in the 5th comment:
Votes: 0
Idealiad said:
Evennia is turning out well lately.


Griatch publishes articles on Evennia related subjects in every issue of Imaginary Realities.
26 May, 2015, Nathan wrote in the 6th comment:
Votes: 0
Your criteria of "elegant and properly written" is kind of an opinion thing on some level. For the language they are in (C) and the libraries (standard, plus custom?) they use, there are probably plenty of Diku derivatives which fit that. What you are really after, I'd bet, is one written almost entirely by the same or a very small group of developers with minimal changes by others since the coding style, etc will be very uniform. What is "properly written" is kind of a fuzzy area since there is often more than one way of doing things.

I don't think there are very many muds written in low-level languages, if any. C is a high level language, even if other languages based on it mask some of things it has (like pointers). The notion of something that is currently supported is nice, but is likely to change. Most of them were at some point.
26 May, 2015, plamzi wrote in the 7th comment:
Votes: 0
As far as I know, Evennia and CoffeeMUD are the only ones that are both currently supported and documented. There's a couple of other modern codebases, mine included, that are worth checking out if you have strong feelings about the language, but they are not documented as well. I believe Evennia comes closest to fitting all your requirements.

Nathan said:
Your criteria of "elegant and properly written" is kind of an opinion thing on some level.


On some level it is, but on all the levels that count, it isn't. Uniform style is nice, but I find a range of styles totally acceptable if the design is sound. For example, if things are modular and extendable, then it doesn't particularly harm the code if a given module is written in a different style.

Nathan said:
I don't think there are very many muds written in low-level languages, if any. C is a high level language, even if other languages based on it mask some of things it has (like pointers).


Based on his examples, I think he means "interpreted / modern." Strictly speaking, C is high level of course, but compared to modern interpreted (and some compiled) languages, it now seems "medium-level" at best.

Nathan said:
The notion of something that is currently supported is nice, but is likely to change. Most of them were at some point.


Still better to pick one that's currently supported and looks like a long-distance runner. Even if you get one more update out of it, that's better than none.
26 May, 2015, Mudder wrote in the 8th comment:
Votes: 0
plamzi, whoa, you literally took the words from my mouth. Thank you. I also largely was seeking a MUD that is object oriented. I'm sick of dealing with legacy procedural systems. I just left a job because of a nightmare like that.

Also, I would like to thank everyone for the suggestions so far.

I would agree, Evennia seems to fit my specifications pretty well. I'll keep an eye on it and probably set it up somewhere and poke around. I'll also take a peek at teensyMUD as I would love to learn a little ruby.

I'll keep checking back and likely update this thread as I can't be the only one seeking out this information.

EDIT: Does Zeno still provide free hosting?
26 May, 2015, Nathan wrote in the 9th comment:
Votes: 0
@Plamzi
I get what you're trying to say, but what I really was referring to was something like mixing modular and non-modular code. That is, the person adding functionality to a modular codebase opts not to do it in a modular fashion. When it comes to calling something high/low level, strictness is what matters. It would be more productive to talk about static/dynamic typing and compiled/bytecode/interpreter. Which is to say, talking about the significant aspects of a given language that push you in one direction or another in terms of how you write your code. Something else worth considering is what sort of exception/error handling is available as part of the language.


I am not sure what to think of Evennia and CoffeeMUD personally. They both seem excessively complex to me. Whether that's entirely necessary is difficult to say.
27 May, 2015, quixadhal wrote in the 10th comment:
Votes: 0
If you do choose Evennia, I highly recommend grabbing PyCharm as well. Even if you intend to run it in a bash shell on your production game server, the PyCharm IDE is very nice. Quite comparable to Visual Studio, and far superior to Eclipse, IMHO.
01 Jun, 2015, Griatch wrote in the 11th comment:
Votes: 0
Nathan said:
@Plamzi
[…]
I am not sure what to think of Evennia and CoffeeMUD personally. They both seem excessively complex to me. Whether that's entirely necessary is difficult to say.

This is valuable feedback! I can of course not speak for CoffeeMUD but I'm genuinely interested in hearing your view on Evennia and how it is perceived from the outside or to someone new to it. Do you have any specific examples of where you find Evennia excessively complex or inaccessible or is it an overall impression? We can only improve with good comments and critique. :)
.
Griatch
01 Jun, 2015, plamzi wrote in the 12th comment:
Votes: 0
Griatch said:
Nathan said:
@Plamzi
[…]
I am not sure what to think of Evennia and CoffeeMUD personally. They both seem excessively complex to me. Whether that's entirely necessary is difficult to say.

This is valuable feedback! I can of course not speak for CoffeeMUD but I'm genuinely interested in hearing your view on Evennia and how it is perceived from the outside or to someone new to it. Do you have any specific examples of where you find Evennia excessively complex or inaccessible or is it an overall impression? We can only improve with good comments and critique. :)
.
Griatch


Speaking for myself, when I first took a look at Evennia, most of my MUD coding experience was in highly procedural C of a very traditional main loop Circle garden variety. I think the reality is that writing event-based code in a highly coupled application will invariably seem like having to jump through a few extra hoops to get things done at the core code modification level.

Where event-based code really shines is not immediately obvious from looking at the code itself. What is immediately obvious is that, over and above having to gain some levels in the language the codebase is written in, you also have a learning curve in how to extend, customize, and add content properly. That's a big turn-off for many hobbyists who are coming from patching and modifying Dikurivatives.

In addition to the layers of complexity added by events, in modern codebases there's also the learning curve of achieving persistence. For many folks, there's some good old comfort in human-readable flat files that no database is ever going to give them. Again, the advantages of database persistence are not immediately obvious to them. What's obvious is that they'll have to learn some new tricks, with some vague promises of things getting easier way way down the line.

I don't know that there's a magic bullet for any of this. Evennia is already very well documented by any standards. From some cursory reading, it seems sensibly structured as well. Seeing a long list of methods in the documentation can discourage prospective adopters, sure, but anyone who's had to deal with API-type frameworks knows that it signifies strength, especially when there's an immediate and clear pattern / logic.

Probably the only advice I can give is that I find more self-contained source files (wherever possible) and inline comments (wherever not possible) extremely helpful when learning this type of code. What I mean by self-contained is that in object-oriented programming of highly coupled applications, it is very common to have completely opaque inheritance, and in addition, to phone out to other objects very often to obtain references to stuff you need. This means that someone taking their first look at any part of your code is going to immediately be faced with the need to know a lot about it just to understand what it does on a basic level. To mitigate this, having visual clues goes a long way. For code that extends / overrides other code, performing all overrides in the same file I find to be much easier to process than having things scattered over multiple files that you then have to teach people where to create / place, how to name, what to put / not to put in them etc.
01 Jun, 2015, Griatch wrote in the 13th comment:
Votes: 0
@plamzi

Thanks for the reply! Yes, I can certainly understsand this notion. It can indeed be daunting if one goes into Evennia with the mindset of rebuilding/hacking the library itself from the start (like one would the diku source code). Both learning Python as well as all the details of asynchronous python programming as well as abstracted database management and mud-specific systems can be a lot to take in, even with extensive documentation.

Evennia is after all a "library" more so than a "codebase" in the traditional mud sense - as you allude to, it's an (by most feedback considered pretty easy) API you use to build your game. And whereas there is of course nothing stopping you from hacking the core if you really want (it's after all just open-source python code), our policy is instead to allow users to plug their own stuff in almost everywhere. The most do-it-yourself types could, if they felt like it, replace most of Evennia's core systems with their own without changing a line of upstream code. This way we have an easier time to support Evennia since we know where the interface go between "ours" and "yours".

As for code documentation, your comment on class inheritance is well taken; it is easy to make class inheritance confusing or hard to follow in the interest of code-reusal. I think we may be partly beginning to address this concern though since Evennia's github API documentation (created by our new and custom API-autodoc builder) specifies the entire parent history for every class, including classes not found in the current module, with links. This should hopefully make it easy (or at least easier) to browse and jump through class inheritance trees for those interested.

I understand the desire from wanting to know how it all works from the get-go though, and why coming from the diku world would make for a very different impression of just where complexity lies for one's usage of Evennia.

(and sorry to the OP for derailing the thread with Evennia-specific feedback. To answer the original question, yes Evennia is in Python and actively maintained. :))
.
Griatch
01 Jun, 2015, Jeshin wrote in the 14th comment:
Votes: 0
Hey,

As I noticed Evennia being discussed so I appear. I (and my team) are currently developing a fairly ambitious game on the Evennia engine. Thus far it has been significantly easier to work with than other options such as SmaugFUSS or ARPI's open source engine. In fact two of my developers are the people who were heavily involved in the creation of the current generation RPI++ engine that was used on Atonement RPI, Parallel RPI, and now Shadows of Isildur: Laketown (alpha). So when I say that this 'codebase/library' is very flexible and open to development it should be clear that I am not speaking without some level of experience.

The only concerns that we have had with Evennia was developers (I am not personally a coder) is that we had concerns about execution times for commands and potential lag when doing numerous complex activities game-wide such as maintaining grids with people all following a leader while using a shortest path algorithm for movement. The greatest benefit of using Evennia over every other engine currently out there which is "non-legacy" is the documentation. This codebase/library has documentation that puts fortune 500 companies to shame and it is very well maintained with an active community that are willing to help out via their IRC groupchat. So where Evennia may seem complex and hard to grasp at first, you have to weigh the learning curve against the community and documentation support that is there to assist you.
01 Jun, 2015, Jeshin wrote in the 15th comment:
Votes: 0
On a side note: The FutureMUD engine created by Japheth and Wolfsong is nearing the end of its development cycle. It is supposed to be a "next-gen" codebase like Evennia and CoffeMUD where it doesn't have a pre-built game in there for you but instead the tools to create the game you want. It is a closed source engine but will support modifications via XML sheets?

http://www.futuremud.com/

You can check out their website there and see if that is something that might fall in line with your request?
05 Jun, 2015, Mudder wrote in the 16th comment:
Votes: 0
This is in no way a derailment of the original thread. I love open discussions about the pros and cons or even complaints regarding new engines.

My immediate and biggest negative reaction to Evennia so far was it's integrated webserver. Though I realize the average user would consider this a strength, I am just a fan of separation. That and I prefer to use PHP's laravel for my web apps. ;)

I understand Django is an amazing framework so it probably wouldn't hurt to also learn that.

EDIT:
quixadhal said:
If you do choose Evennia, I highly recommend grabbing PyCharm as well. Even if you intend to run it in a bash shell on your production game server, the PyCharm IDE is very nice. Quite comparable to Visual Studio, and far superior to Eclipse, IMHO.

Absolutely. I love jetbrains' IDE.
05 Jun, 2015, plamzi wrote in the 17th comment:
Votes: 0
Mudder said:
My immediate and biggest negative reaction to Evennia so far was it's integrated webserver. Though I realize the average user would consider this a strength, I am just a fan of separation. That and I prefer to use PHP's laravel for my web apps. ;)


I've heard things like this very often in this community, and never quite understood it. Negative reactions to features in open source code which there is absolutely no obligation to use, and which in most cases can be "turned off" by commenting out a few lines or moving a few files.

If you have an "immediate" reaction to the presence of a feature you yourself realize may be useful to many, I wonder what kinds of reactions you have reserved for buggy features, poorly designed features, missing features that you really want, and for poor codebase design choices that make adding your own features overly difficult or impossible.
05 Jun, 2015, Mudder wrote in the 18th comment:
Votes: 0
I was actually responding to the request for input. Those were my first impressions and I blatantly stated that I am probably not in the majority. If there were an equal framework that did not have that I would have gone with it.

For the other actions I reserve for buggy features, etc? I would simply avoid that program and likely not comment in the first place.

That said, I am looking at Evennia right now and toying with it. I think you may have read my comment as a complaint and not a working document of my first impressions.
06 Jun, 2015, khyldes wrote in the 19th comment:
Votes: 0
Quote
That and I prefer to use PHP's laravel for my web apps. ;)


/wrists
06 Jun, 2015, Nathan wrote in the 20th comment:
Votes: 0
I don't personally use Evennia (I don't need to and I found it hard to pick up the one time I tried), but I also find the notion of an integrated and, to a degree, inseparable web server annoying and concerning. It feels like adding unnecessary complexity. While it's certainly a neat tool and idea if you happen to need/want it and don't want to do it yourself, it adds bulk to the program you are working with and just feels wrong somehow as a matter of design principle. It also has the disadvantage that you may not learn anything about the web and if you move to a system without such a feature you may have no idea how to build that functionality yourself. As with so many other things it is a trade-off and not necessarily an improvement without drawbacks.

I don't think anyone is presently writing a codebase which isn't "next-gen" (at least in their minds), unless they are porting something or is less serious of a project than most. Unfortunately, or not, just because it's "next-gen" doesn't make it easy to understand or work with. Most of that stuff SHOULD provide a pre-built game so you can see how things are done. Tutorials are nice, but an actual working world is much more useful than stumbling in the darkness between a tutorial and a completed thing.
0.0/31