06 Jun, 2015, quixadhal wrote in the 21st comment:
Votes: 0
I *LOVE* the idea of a built-in web server.

Why? Because it has (or can have) direct access to the data. When I write web pages to go with my MUD, I'd much rather have them able to directly pull data from the live and running server without having to code up some half-assed socket system for a cgi script to query, or rely on the MUD pushing the data I want to various files or SQL tables just so I can pull it back out a few seconds later.

I haven't looked at Evennia very hard, but it sounds like I should. :)

Here's an example of a web page written in LPC, served by the "web server" that the Dead Souls mudlib implements (in LPC, via the FluffOS game driver).

The Mud List, and the source code that generates the HTML on the fly (as a cgi).

The LPC system doesn't support embedded scripting snippets like apache does (The <? ?> constructs), but if it did, the page would be even cleaner since much of that is just HTML embedded in strings to be printed.

But, I *LOVE* being able to iterate directly over data like: foreach( mud, info in INTERMUD_D->GetMudList() ) {

But, if you like doing stuff the hard way by forcing an external server to pull data from some intermediate repository, nothing says you HAVE to use the built-in one. I'm sure Evennia has a config option to disable it. I know Dead Souls has one. Even if I didn't want to use it, I'd probably just leave it enabled with no content, since it runs on a different port and won't use any resources if nothing touches it (other than one socket listening for connections).
06 Jun, 2015, plamzi wrote in the 22nd comment:
Votes: 0
Nathan said:
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.


I think it matters how a feature is implemented, no? Did you really find it to be, to any degree, inseparable? That would be pretty amazing in and of itself. And what happens if you simply don't use it, or find a way to tweak it to make your integration of any external web server easier?

In my observation, which earlier comments from Mudder and from you both confirm, anyone who has any coding skills at all in this community is really on a quest to roll their own anything. It takes only a few minutes to find something that "feels wrong", that you would have done differently in a codebase, so you tell yourself it's a deal-breaker and that your own codebase will be "perfect". It's this kind of mentality that holds us all back, and makes fully playable games less likely to ever see the light of day. Complete fragmentation, no real "teams", or incentives to team up = no real progress.


Nathan said:
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 knew this argument was coming. I've already heard that writing your own homebrew database for your game can easily get you SQL-type functionality, concurrency, etc. So now writing your own web server is the only way to learn about the web. I must have been doing something wrong writing for the web all these years and serving it all on a good old LAMP stack instead of writing my own :)


Nathan said:
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.


This is where I agree completely. Which is why my codebase, currently at v0.3 is a fully playable game with major features built into it (in a modular way) including an easy-to-build-up world, a complex quest system, advanced item affects (including crafting), advanced skills, etc. Unlike Evennia, which chose to emphasize the API and the documentation, I put off documentation in exchange for fully functional "examples" of the kinds of features one can build, a full-featured game.

That said, I have already heard "feedback" from some potential adopters that, while they think Havoc and its example UI are already "eye-popping", it is written in JavaScript, which is not, according to this person, "a general purpose language" like Python.

So there you have it! It is not just the players that you can never please in this community, it's also most of the devs :)
06 Jun, 2015, donky wrote in the 23rd comment:
Votes: 0
plamzi said:
That said, I have already heard "feedback" from some potential adopters that, while they think Havoc and its example UI are already "eye-popping", it is written in JavaScript, which is not, according to this person, "a general purpose language" like Python.

So there you have it! It is not just the players that you can never please in this community, it's also most of the devs :)

I'd say most people have a preferred programming language, and even only a select range of frameworks and libraries they are willing to use of those available within that language. It should be reasonable to say different people have different requirements to feeling comfortable in their programming environment. I don't think it's unfair to also say that by choosing to write in javascript you self-selected for the group who were willing to adopt that language and the dependencies you pay the price for using.

But that said, at some level I believe that a modern MUD codebase is going to include some javascript, when it comes to writing the website which in a modern codebase should be integrated in some way. This was true even 11 years ago in 1994. Discworld mudlib back in the day had an integrated web server. My variant of the Discworld mudlib had an LPC service that presented generated VRML mixed with HTML and javascript (or ecmascript as it was known back then) to the VRML plugin you had installed in your browser. And web programming is an order of magnitude more powerful today.
06 Jun, 2015, plamzi wrote in the 24th comment:
Votes: 0
donky said:
I don't think it's unfair to also say that by choosing to write in javascript you self-selected for the group who were willing to adopt that language and the dependencies you pay the price for using.


Insofar as you need to choose a language to write functional code, and you need to have dependencies to produce anything remotely useful in this day and age, I am totally aware it will turn many people off, possibly everyone in this place. I just wanted to share what I think is a funny anecdote, namely the way this person chose to rationalize their unwillingness to learn something new. If there ever was a more general purpose language than JS, I would immediately switch to it for all my daily needs :)
07 Jun, 2015, Famine wrote in the 25th comment:
Votes: 0
I'm looking forward to Evennia because I <3 python and love to get into more Django. But, I also hate that it's pretty much a blank slate too. It means I have a lot of work ahead of me in learning and implementing. At the end of the day, I may just give up and go with what I know better and what's already has me halfway there.
08 Jun, 2015, Davion wrote in the 26th comment:
Votes: 0
Famine said:
I'm looking forward to Evennia because I <3 python and love to get into more Django. But, I also hate that it's pretty much a blank slate too. It means I have a lot of work ahead of me in learning and implementing. At the end of the day, I may just give up and go with what I know better and what's already has me halfway there.


You should check out Pyom. A few of us worked on turning ROM into something more modern. The results are impressive. Started off with almost a literal translation to Python.
09 Jun, 2015, Famine wrote in the 27th comment:
Votes: 0
Davion said:
Famine said:
I'm looking forward to Evennia because I <3 python and love to get into more Django. But, I also hate that it's pretty much a blank slate too. It means I have a lot of work ahead of me in learning and implementing. At the end of the day, I may just give up and go with what I know better and what's already has me halfway there.


You should check out Pyom. A few of us worked on turning ROM into something more modern. The results are impressive. Started off with almost a literal translation to Python.


Oh, even better! I will check this out too.

But, this is for Python 3 right? If so, I only have worked with 2.7.
09 Jun, 2015, quixadhal wrote in the 28th comment:
Votes: 0
Because of the small but gotcha-type changes from Python 2 to Python 3, I'd learn 3 and pray that 2.x dies soon… I'd never use 2.x in anything but legacy code someone was paying me to write. :)
09 Jun, 2015, Famine wrote in the 29th comment:
Votes: 0
quixadhal said:
Because of the small but gotcha-type changes from Python 2 to Python 3, I'd learn 3 and pray that 2.x dies soon… I'd never use 2.x in anything but legacy code someone was paying me to write. :)


I work with a lot of legacy stuff at work, that's why I still use 2.

I'm in no means a python guy, but I'm trying to get more into it from a data science standpoint. A lot of the packages I use have been converted. Just haven't taken the dive yet.

I was wanting to use Evennia with Pymssql and see if I could experiment with the SQL Server 2016 Preview version that was released to the public. That way I could tie the whole analytical platform (Azure ML - R/Python) with 2016 with a MUD just for kicks. But, not being too familiar with Django is making it a bit of a pain. So, this gives me a second option to try.
09 Jun, 2015, Davion wrote in the 30th comment:
Votes: 0
Famine said:
Davion said:
Famine said:
I'm looking forward to Evennia because I <3 python and love to get into more Django. But, I also hate that it's pretty much a blank slate too. It means I have a lot of work ahead of me in learning and implementing. At the end of the day, I may just give up and go with what I know better and what's already has me halfway there.


You should check out Pyom. A few of us worked on turning ROM into something more modern. The results are impressive. Started off with almost a literal translation to Python.


Oh, even better! I will check this out too.

But, this is for Python 3 right? If so, I only have worked with 2.7.


It is Python 3 but I wouldn't let that hold you back. You can just setup a virtualenv with python3 installed and you're good to go. We don't use any external libs. Most python libs work on both 2 and 3, so it shouldn't limit you there. The difference is pretty minimal. You probably wont even notice the difference starting from a pure python 3 project.
11 Jun, 2015, Griatch wrote in the 31st 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 understand Django is an amazing framework so it probably wouldn't hurt to also learn that.


Thanks for the feedback! If you don't like Evennia's integrated webserver you are of course welcome to turn it off. You can deactivate all or parts of Evennia's web presence with a line in your server settings. You can for example have apache or ngnix serve your pages if you prefer (but you are probably on your own if you want to use our webclient).

Our impression is that most people (as you allude to) do consider Evennia's webserver to be a strength of the system. As others mention, the ability to conveniently use the same database for your game as for your website gives you the direct ability to integrate the two into one whole. And Django is a professional-level web framework, you can code eventual custom web backbones using the same principles you use to fetch your game data.

That said, while very powerful, Evennia's web presence is admittedly not as polished as it could be out-of-the-box, so this is something we could certainly improve on. :) More web-centric devs are welcome to get in touch.

Nathan said:
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.


Bloating is never good but whereas we are bare-bones when it comes to game systems we aim to supply a fully-featured multiplayer game backbone. This includes the game's web infrastructure. The idea is to handle all this behind-the-scenes stuff so devs can focus on designing the systems that are actually unique for their particular dream game (which is also why we have a contrib folder with more gametype-specific code you can make use of).

… But as said, if you didn't want to use these features, decides to code them from scratch or want to use some other web server of your choice - you can turn Evennia's own webserver off very easily. It's a modular system and the webserver is just one module. And Evennia itself is a library. You pick and chose the stuff you want to use.

Nathan said:
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.

Agreed, "next-gen" is not meaning much, which is why I don't tend to use that term for Evennia. It is a "modern" MUD server and development library though, BSD-licensed, based around a modern programming language and workflow, with very extensive documentation and API docs and without legacy ties to other engines. If this totals to a plus or a minus is something up to each respective developer to decide.

It is a fair point that Evennia does not include a full game out of the box. There is plenty of example codes and Evennia does come with a tutorial world - it is a 20-room mini adventure/quest showcasing features including puzzles, combat and scripting. It's by no means a "full" game though, that is certainly true.

Famine said:
I'm looking forward to Evennia because I <3 python and love to get into more Django. But, I also hate that it's pretty much a blank slate too. It means I have a lot of work ahead of me in learning and implementing. At the end of the day, I may just give up and go with what I know better and what's already has me halfway there.

Sure, it's a fair point. The bare-bones approach of Evennia is not everyone's cup of tea. If you love Python and want to learn more Django I think there is very little else in MUD world that compares though. ;)


Thanks for the comments and feedback people, it's always useful to hear of people's impressions, good or bad!
.
Griatch
20.0/31