What is out there? Hard and soft codebases of choice.
-
There are many codebases out there, and I haven't played on all of them. I know the developers and maintainers of some of those codebases are here. I know there are players who have experience with many codebases as well.
What is your favorite code base and what makes it special? What benefits are there to using it that other people might not have thought of?
I'm considering more than just the underlying code (MUX, Penn, Rhost, Evennia, etc). Encompassing soft coded systems are something I'm also interested in. I don't want to exist in a bubble where I only play with the same thing endlessly, never knowing there is a better or different way to do things.
-
Evennia is odd, but it's also the shit because of the Django web aspect. As staff, I can do so much through a nice, clean (thanks Tehom!), browser gui. Players can also do sheet maintenance (journals and relationships) through the website. So, so nice.
-
@Kanye-Qwest I played with it some, but it was quite some time ago. I remember getting only so far in before I ran into some error that was sitting in the issue tracker and stopping, waiting for it to get past that. But the web interface was such a beautiful thing.
-
Evennia is an impressive work indeed, but I find it kind of overengineered. Very much "kingdom of nouns" design.
It also lacks something that's key in hobbyist adoption: easy explorability. If ever my conceptual Logtalk-based server leaves the stage of throwing out a few models and test spikes and becomes actual, coherent code, I will be looking close at Evennia for lessons: both good and bad.
-
@WTFE What do you prefer? What is Logtalk?
-
Honestly, I don't like any of the code bases out there. I'd never consider even trying to run a game on a MUSH base or Evennia. Of the code bases I've seen thus far the one I dislike least is MUCK, but it's tainted by association with ... less than savoury segments of society. (Tainted in that if you open a MUCK that set of segments will assume its for them and move in, driving off anybody else.)
Logtalk is an object layer construction kit built on top of Prolog.
-
An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?
As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!
OP: sorry for what may be a bit of a derailment of the thread...
.
Griatch -
@Griatch said in What is out there? Hard and soft codebases of choice.:
An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?
As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!
OP: sorry for what may be a bit of a derailment of the thread...
.
GriatchMy main issue when I tried out Evennia is that it felt a lot easier to just ignore most of the Evennia abstraction layers and use Django directly because the Evennia storage obfuscates the data relationships.
What is obvious to you may not be obvious to me and vice versa.
-
@Griatch Not a derailment at all, that's exactly the kind of thing I wanted to hear. I've poked at TinyMUX, Penn, Rhost, Evennia... I installed that Ruby based sample game. Everything is a little different, and it seems like the majority of things translate between them. But there are differences, and my sampling isn't deep enough to really know what they are and why one might be better than another in some cases.
Further, some systems have very active developers of softcode and that's also an important draw. If you can talk to @Cobaltasaurus or @Thenomain or @Ashen-Shugar or you (or more, I can't list all of you coders, but I'm glad you're here) about the code they wrote instead of using decade old castoffs or three week old undocumented experiments, then that's also really important.
-
You assume that our code projects aren't three week cast-off projects. Just the way we planned.
-
My main issue when I tried out Evennia is that it felt a lot easier to just ignore most of the Evennia abstraction layers and use Django directly because the Evennia storage obfuscates the data relationships.
I can certainly see this, especially if you are coming from a background where you are used to manipulating sql directly. Evennia allows you to write a game writing mostly plain Python with little knowledge of Django. The ability to extend with your own storage/web solutions through Django is not anything obscure or hackish in Evennia though; it's covered in some detail in our documentation for those that need it for their particular design.
@Hexagon
Aye, it's indeed always a good idea to look around to see how different people have tackled a problem independently of each other.
-
@Griatch said in What is out there? Hard and soft codebases of choice.:
An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?
I won't elaborate on it. I'll let the guy who coined the phrase do it for me.
As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!
Well, item #1: the Evennia installation process is terrible. I mean utterly God-awful. When I finally got something that worked, I was never actually quite certain if I'd done it right or if I'd merely stumbled accidentally over a configuration that would work right up to the point it stops. Work on your installation process and please, PLEASE, PLEASE, PLEASE, MOTHERFUCKING PLEASE cut down on the number of "install this, then install this, then install this, then configure this, then do this, then do that" steps. An ideal setup process should involve one step:
./setup(or equivalent). You're not making enterprisey software here. Enterprise management are idiots and will tolerate things like Entrust's fifteen-stage (with three reboots!) installation process. Hobbyists ... not so much.Item #2: There's very little that can be done in the environment itself. Yet doing things in the environment itself is the very essence of explorability. Everything in Evennia is done out of band. Compare and contrast with MUSHes (terrible as they are!) where any user can go in and start tinkering around with MUSHcode like this:
&FUN_ANSIFY me=foreach(me/fun_randansi,%0) &FUN_RANDANSI me=ansi(+[randword([colors()])],%0) &CMD_ANSIFY_CHAT me=$.ca *=*:@chat %0=[ufun(me/fun_ansify,%1)] &CMD_ANSIFY_PAGE me=$.pa *=*:page %0=[ufun(me/fun_ansify,%1)] &CMD_ANSIFY_TALK me=$.a *:say [ufun(me/fun_ansify,%0)]I mean seriously, this is an incredibly crappy programming language ... but it's a programming language available to the end-user at point of usage. This fosters explorability.
In my youth BASIC was the gateway drug that led to an explosion of people learning to program. BASIC is a shit language, just like MUSHcode, but it was better than any of the alternatives available at the time because it was a shit language that was there in front of you. You typed at it and it gave you its (sometimes insane) response. It was BASIC and this explorability that led to where I am now almost casually doing R&D work in embedded systems. If I'd grown up in the Dark Ages of Exploration (the '90s and '00s) I'd never have gotten to where I am now.
-
@WTFE said in What is out there? Hard and soft codebases of choice.:
When I finally got something that worked, I was never actually quite certain if I'd done it right or if I'd merely stumbled accidentally over a configuration that would work right up to the point it stops.
This was pretty much how I felt tinkering with Evennia. I eventually turned it off because it felt like I was holding it together with a shoestring and a prayer.
-
@WTFE said in What is out there? Hard and soft codebases of choice.:
@Griatch said in What is out there? Hard and soft codebases of choice.:
An interesting observation. I've not heard the term "Kingdom of nouns design" before, would you mind elaborating what you refer to by that?
I won't elaborate on it. I'll let the guy who coined the phrase do it for me.
The way I interpret that is he doesn't think objects should make the work of functions. Which is not very relevant for Python that has no problem to support functional programming where it makes more sense. Evennia uses objects for example for Commands for a very specific reason - functions are too limited for the functionality of Commands. In other places (such as for creating menus or spawning mechanisms) we instead rely on functions because the complexity of an object is not needed.
I would need a more concise example of what you mean here to reply.
As for "explorability", I guess this comes down to what one is used to. Most previous Python users that interact with us seem to report that they find Evennia pretty easy to get to grips with, many being productive within a day of finding it and asking some basic questions. But it varies greatly and there is no denying that starting to use any new library will always be a hurdle. We can only do our best to make it easier. So if you have any ideas for how to make Evennia more "explorable" I'd be genuinely happy to hear them!
Well, item #1: the Evennia installation process is terrible. I mean utterly God-awful. When I finally got something that worked, I was never actually quite certain if I'd done it right or if I'd merely stumbled accidentally over a configuration that would work right up to the point it stops. Work on your installation process and please, PLEASE, PLEASE, PLEASE, MOTHERFUCKING PLEASE cut down on the number of "install this, then install this, then install this, then configure this, then do this, then do that" steps. An ideal setup process should involve one step:
./setup(or equivalent). You're not making enterprisey software here. Enterprise management are idiots and will tolerate things like Entrust's fifteen-stage (with three reboots!) installation process. Hobbyists ... not so much.I'm sorry to hear you had issues with the install process. Which OS did you install on?
There is a briefer point-by-point summary up top but the main install text is indeed pretty lengthy. It's possible we can cut down on that; the text is explaining how to set up things also for those without any previous Python environment. It also helps to troubleshoot known issues . Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then runningpip install -e evennia.While we will eventually also put the package on pypi (so you can get evennia with
pip install evennia), using GIT will likely remain the most convenient way for developers to access Evennia since that gives easy access to the source for reference. For the same reason we can't really distribute a monolithic binary. It's great with feedback and critique though, thanks for that, we'll try to take it to heart to make things easier!Item #2: There's very little that can be done in the environment itself. Yet doing things in the environment itself is the very essence of explorability. Everything in Evennia is done out of band. Compare and contrast with MUSHes (terrible as they are!) where any user can go in and start tinkering around with MUSHcode like this:
&FUN_ANSIFY me=foreach(me/fun_randansi,%0) &FUN_RANDANSI me=ansi(+[randword([colors()])],%0) &CMD_ANSIFY_CHAT me=$.ca *=*:@chat %0=[ufun(me/fun_ansify,%1)] &CMD_ANSIFY_PAGE me=$.pa *=*:page %0=[ufun(me/fun_ansify,%1)] &CMD_ANSIFY_TALK me=$.a *:say [ufun(me/fun_ansify,%0)]I mean seriously, this is an incredibly crappy programming language ... but it's a programming language available to the end-user at point of usage. This fosters explorability.
Evennia does not allow unprivileged players access to programming tools out of the box, this is true (see also Evennia for MUSHers for some more elaboration on this). I can see the value of this argument if you want your players to explore coding as part of your game design. I'm not sure it's all that relevant for you downloading Evennia though? After all, you have all the exploratory tools available at your fingertips. You can explore and code to your heart's extent without any compilation and you will see the results of your work in-game immediately after just a
@reload. And you can also experiment directly in-game by executing Python directly from the command line with@py.In my youth BASIC was the gateway drug that led to an explosion of people learning to program. BASIC is a shit language, just like MUSHcode, but it was better than any of the alternatives available at the time because it was a shit language that was there in front of you. You typed at it and it gave you its (sometimes insane) response. It was BASIC and this explorability that led to where I am now almost casually doing R&D work in embedded systems. If I'd grown up in the Dark Ages of Exploration (the '90s and '00s) I'd never have gotten to where I am now.
BASIC was great on the Commodore 64 in the 80's (which is when I came into contact with it). And I can see the argument about having the code at hand if you want a game where unprivileged players can get creative with code. I cannot really relate to this notion (anymore) as a game developer though - the immediacy of the telnet just doesn't outweigh the advantages of a proper development environment (to me).
.
Griatch -
Further, some systems have very active developers of softcode and that's also an important draw. If you can talk to @Cobaltasaurus or @Thenomain or @Ashen-Shugar or you (or more, I can't list all of you coders, but I'm glad you're here) about the code they wrote instead of using decade old castoffs or three week old undocumented experiments, then that's also really important.
As @Griatch can attest to, the devs of RhostMUSH are pretty open on interoperability. In so far as even opening a dialog with @Griatch once we get around to finally writing our Python API so that Evennia and Rhost can talk to each other on some level. Cross-compatible python modules for the win!
One big thing we do have with Rhost is we have a built in execscript. This is a built in function that allows you to interactively execute external script/binaries/other as a local built-in function and be able to scrape the results off it. It allows fun things like running things through an external spell program, calling the mush patch process in-game so you could compile your game inside your game, allowing you to scrape web pages, do external sql calls, populate external files, basically absolutely anything and everything in a sandboxed location. A lot of flexibility here.
And once the Python API is written (We plan for that in the Alpha of Rhost 4.0 hopefully in 2017 Q1), we will have the framework for other API's, maybe perl, ruby, and so forth. Our goal is to move the main mush engine into it's own API extraction layer so that you have all the power of the mush internal language and all the external tools of calling API tools. So hopefully a merger of two worlds.
Some stuff may be vaporware and far too far to reach, but the Python API is already down on paper, just have to get the guy who knows how to add it to, well, find time to add it
-
@Griatch said in What is out there? Hard and soft codebases of choice.:
I won't elaborate on it. I'll let the guy who coined the phrase do it for me.
The way I interpret that is he doesn't think objects should make the work of functions.
Whereas it's actually a rather eloquent rant against the noun-centric thinking that has infected programming to the point that it is considered the norm.
https://github.com/evennia/evennia/wiki/evennia
Go there. Count the noun objects. Count the managers, factories, models, etc. Some of that kind of stuff is useful and necessary, but what I see in that API reference is a shopping list of design patterns. Of nouns and only nouns.
Professional developers steeped in (the utterly broken and failed) modern OOP software methodology will not find this a problem.
HOBBYISTS will.
That is a ludicrous number of noun objects there.
Which is not very relevant for Python that has no problem to support functional programming …
BWAAAAAAAAAAAAAAAAAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
Well, item #1: the Evennia installation process is terrible.
I'm sorry to hear you had issues with the install process. Which OS did you install on?
Linux.
There is a briefer point-by-point summary up top but the main install text is indeed pretty lengthy. It's possible we can cut down on that; the text is explaining how to set up things also for those without any previous Python environment.
Look to Textadept for how to do this right. Textadept is a code editor built on Lua, GTK, etc. Its build process downloads all the stuff it needs and builds a local copy, thus guaranteeing that the correct (compatible) version is installed and ready to rock. (The documentation for building Textadept is atrocious -- it's by no means a perfect package! -- but the bit about bringing in its own prerequisites and building them in a local copy is dead perfect.)
Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running
pip install -e evennia.If it's a "standard practice" WHY THE FUCKING FUCK IS IT NOT AUTOMATED!? Again you're acting as if your users are professional Python developers. If this is, in fact, your target audience, feel free to ignore my critique. But holy fucking shit, if this is your answer to fucking HOBBYISTS you really, really, really, really, FUCKING REALLY need to take a semester or ten of human/machine interaction courses!
Evennia does not allow unprivileged players access to programming tools out of the box, this is true (see also Evennia for MUSHers for some more elaboration on this). I can see the value of this argument if you want your players to explore coding as part of your game design.
Fuck the game design, the question is how do you get people from being players to being people who build games with your framework?
I'm pretty sure every one of the semi-legendary MUSHcode softcoders out there started off just playing around with softcode on MUSHes, making dumb little functions and commands like my random ANSI example above. This is stuff that has no material impact on the game, but is a) fun to do, b) engages users as they find ways to write things that are convenient for them in your game, and c) acts as a gateway to more serious development.
I'm not sure it's all that relevant for you downloading Evennia though? After all, you have all the exploratory tools available at your fingertips.
I'm looking at a far wider picture than you're looking at. You persist in looking at "only professional Python developers" in effect. I'm looking at "how do you make people who aren't professional Python developers interested in using your product?"
(Hint: if it's "read this document and follow the 18,000 lines of instructions in it to run your very own server, that's a non-starter.)
I cannot really relate to this notion (anymore) …
And it is abundantly clear that this is the case.
-
@Griatch said in What is out there? Hard and soft codebases of choice.:
I cannot really relate to this notion (anymore) as a game developer though - the immediacy of the telnet just doesn't outweigh the advantages of a proper development environment (to me).
Yeah, I'm with you on that one. On many games, players aren't allowed to code much (if anything) anyway. If you want in-game player-accessible scripting support, Penn/Tiny/Rhost is good for that.
Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running
pip install -e evennia.I think this is the core difference between Evennia and AresMUSH, which is my MUSH server in development. Evennia seems to be more of an open framework - "build whatever you want" - with a presumption that you are tech-savvy enough that you've either started with a Python dev environment or can figure it out.
Ares' goal is to be more of a "MUSH in a box" that someone with no server experience and no coder could get up and running themselves. (Assuming they are content with what the out-of-the-box code can be configured to do.)
That is the principal reason why I opted not to put a web front-end on Ares. Sure it's very cool. It could absolutely be done. But it increases the server and code maintenance requirements and complexity significantly.
-
Go there. Count the noun objects. Count the managers, factories, models, etc. Some of that kind of stuff is useful and necessary, but what I see in that API reference is a shopping list of design patterns. Of nouns and only nouns.
Professional developers steeped in (the utterly broken and failed) modern OOP software methodology will not find this a problem.
HOBBYISTS will.
That is a ludicrous number of noun objects there.
Which is not very relevant for Python that has no problem to support functional programming …
BWAAAAAAAAAAAAAAAAAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!
Python certainly has limited functional programming paradigms compared to something like Lisp. It does support many aspects of it though, especially compared to Java which is used in that example. And Evennia is using functional paradigms a lot even though you are certainly right that entities in the database are represented by classes and there are many situations where we use class-based handlers for managing data.
Anyway, if you hate OOP and think "hobbyists" as a whole can't enjoy it, I guess we just have to agree to disagree.Linux.
That is curious, it's usually a very smooth process on Linux, even for those claiming to blindly follow the quick-start instructions with little understanding. Guess you found some edge case. Sorry about that.
There is a briefer point-by-point summary up top but the main install text is indeed pretty lengthy. It's possible we can cut down on that; the text is explaining how to set up things also for those without any previous Python environment.
Look to Textadept for how to do this right. Textadept is a code editor built on Lua, GTK, etc. Its build process downloads all the stuff it needs and builds a local copy, thus guaranteeing that the correct (compatible) version is installed and ready to rock. (The documentation for building Textadept is atrocious -- it's by no means a perfect package! -- but the bit about bringing in its own prerequisites and building them in a local copy is dead perfect.)
I looked at Textadept, thanks! Textadept is a compiled C program with embedded Lua. It does fetch Lua script libs (it looks like) during the install setup process but you still need to download the actual dependencies (GTK, ncurses, gcc compilers) before you do that. Their documentation is brief and to the point, presuming one knows the GNU compilation process beforehand.
It's a fundamentally different type of program than Evennia (Textadept is a stand-alone binary with no particular wish for you to dive into their code) but I concede that for me, who already had all the dependencies, it's indeed a breeze to compile from source.Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running
pip install -e evennia.If it's a "standard practice" WHY THE FUCKING FUCK IS IT NOT AUTOMATED!?
It's a good notion, we could by all means look into offering a build script for setting up the virtualenv for those not keen on organizing their own development environment on a particular OS. Any way to quicken the route for newcomers to check things out is beneficial.
Again you're acting as if your users are professional Python developers. If this is, in fact, your target audience, feel free to ignore my critique. But holy fucking shit, if this is your answer to fucking HOBBYISTS you really, really, really, really, FUCKING REALLY need to take a semester or ten of human/machine interaction courses!
No, your critique is appreciated! Many of our users are indeed professional programmers but that does not mean those are the sole target audience - the MU* world is not big enough for that.
We have a slew of people learning Python and even learning programming in general on Evennia. If the install process is perceived as "utterly god-awful" by someone new to it, it's worth looking into (it's the first time I hear that, which is why it's a little surprising to me).Evennia does not allow unprivileged players access to programming tools out of the box, this is true (see also Evennia for MUSHers for some more elaboration on this). I can see the value of this argument if you want your players to explore coding as part of your game design.
Fuck the game design, the question is how do you get people from being players to being people who build games with your framework?
Presumably by being a good codebase that developers like to use? As I've said before, I can see the advantage of softcode in the sense of fostering immediate experimentation directly in-game. The validity of the argument comes down to how many players actually make use of this functionality for more than copy&pasting a snippet or making very primitive improvement-of-life things. Such uses Evennia supports too, and without resorting to full softcode.
I have no doubt that softcode will remain strong for a long time to come. And if building an entire complex game system (not just simple things) line-by-line over a telnet bridge is a requirement for your enjoyment and learning, Evennia will likely never fill your need.
I'm pretty sure every one of the semi-legendary MUSHcode softcoders out there started off just playing around with softcode on MUSHes, making dumb little functions and commands like my random ANSI example above. This is stuff that has no material impact on the game, but is a) fun to do, b) engages users as they find ways to write things that are convenient for them in your game, and c) acts as a gateway to more serious development.
I have no doubt this is one avenue into programming. Conversely you can of course argue that DIKU is the more popular codebase out there by far (definitely in the amount of games it has spawned). And that is despite it having no concept of softcode and requires the budding game creator to learn and code in (archaic) C outside the game.
I'm not sure it's all that relevant for you downloading Evennia though? After all, you have all the exploratory tools available at your fingertips.
I'm looking at a far wider picture than you're looking at. You persist in looking at "only professional Python developers" in effect. I'm looking at "how do you make people who aren't professional Python developers interested in using your product?"
(Hint: if it's "read this document and follow the 18,000 lines of instructions in it to run your very own server, that's a non-starter.)
The beginner's perspective is always useful, it's indeed hard to know what is difficult or not with something you are inherently familiar with. It is the first time I hear that much vitriol against the install process so it's worth to consider. Evennia seems to be considered to be a pretty easy system to use by most beginners, but maybe there is a selection effect with critical voices failing at the install process and not telling us, I don't know.
.
Griatch -
Sorry for the double-post, but the other post got a bit long.
@Ashen-Shugar said in What is out there? Hard and soft codebases of choice.:
As @Griatch can attest to, the devs of RhostMUSH are pretty open on interoperability. In so far as even opening a dialog with @Griatch once we get around to finally writing our Python API so that Evennia and Rhost can talk to each other on some level. Cross-compatible python modules for the win!
Yeah, it's a cool idea, it will be interesting to see if we can get some cross-compatibility going there and how big the differences will end up being once your API is in place.
Yeah, I'm with you on that one. On many games, players aren't allowed to code much (if anything) anyway.
This is my impression too, but I guess the mileage varies.
I think this is the core difference between Evennia and AresMUSH, which is my MUSH server in development. Evennia seems to be more of an open framework - "build whatever you want" - with a presumption that you are tech-savvy enough that you've either started with a Python dev environment or can figure it out.
This is probably true, from our previous discussion of the differences. Of course, once you have the server running, the minimal "Python dev environment" in Evennia's case is basically a text editor and that's it.
.
Griatch -
@Griatch said in What is out there? Hard and soft codebases of choice.:
This is probably true, from our previous discussion of the differences. Of course, once you have the server running, the minimal "Python dev environment" in Evennia's case is basically a text editor and that's it.
Well, yeah, but I'm talking about getting the server itself up and running. I've had a bunch of people give up trying to run a game because the PennMUSH install was too intimidating (and it's like a FTP and a couple 'make' commands). Devs take it for granted because we live in a world of command lines and shell scripts, but I think it's important to keep in mind that you've got basically an entire generation now that's never had to use a C:\ prompt. SSH? SFTP? Text editor? You just get blank looks.
These are smart people, but their experience and foundational tech knowledge is completely different than what's required to run a traditional MUSH server.
