There seems to be a misconception as to what Evennia is. The folks over at OR are using Evennia as the game engine to make their new game. And we love that they do! But that their game happens to be an RPI is only because that's the style of game this particular dev team likes to create.
Evennia is an open-source project that existed long before OR and Planet redshift. I don't think there is any particular overlap in our manpower - nor is theirs the only development team using Evennia. Our involvement in their project is technical support on Evennia specifics and them reporting (and sometimes fixing) bugs in the core if they find any during development. We have nothing to do with whatever choices they decide to take on staff-player policies, nor is that any business of ours.
.
Griatch
Best posts made by Griatch
-
RE: Optional Realities & Project Redshift
-
RE: Getting Young Blood Into MU*'ing
My anecdotal input: Having played mainly on RP-heavy MUDs rather than Mushes, my emotes would generally only include people my character would be expected to notice/react to. I'd personally get a little annoyed if my character was walking into what is described as a large, super-busy tavern and the people around the table behind a curtain on the other side of the busy stage immediately emotes how they notice me entering (it has happened, many a time).
If wanting to make it clear the player was noticed without actually addressing them, I might include them with a simple X doesn't notice Y coming through the door, but keeps doing Z, but I never felt this was expected or dictated by convention on any of the games I've played.
-
RE: Getting Young Blood Into MU*'ing
I still think it's the persistent 24/7 world with mostly-live scenes that is the principal defining quality of MUSHes compared to other online RP, but that's just me.
... and you just described an RP-heavy MUD.
We are all dealing with text-based, multiplayer, persistent worlds for [various degrees of] role playing. That's enough for me. Those terms encapsulate what I enjoy about this sub-genre of gaming.
I see games made in Evennia as Evennia games. Arx is this an Evennia game to me. AresMush makes AresMush-games. Penn/RhostMush makes Penn/RhostMush games, LambdaMoo makes LambdaMoo games. There are DIKU-Mud- and Circle-Mud- and LPMud-games along the same veins as there are Unity-created platformers (yes I know you can argue that DIKU is less of an engine and more of a source code you rewrite, but ...)
The variation of game-styles created on each engine is so big that, in my view, the engine name is really the only relevant thing grouping them together. Trying to let the engine name represent a game style is not only confusing (and why no-one can agree on what a 'Mush' truly is in here), it also leaves other types of games made with the same engine in limbo ...
-
RE: Serious Question About Making A MU
@mietze That is fair. And for the record, making a fun game with ready-made building blocks does in no way reduce the value of the result (nor does it make said result any less yours).
I'm just saying that learning even a little code (to carve custom blocks, in this analogy) will rapidly explode one's possibilities and ways of expression. I see coding as a creative skill, a sort of art. I don't think learning it is a wasted effort, no matter one's age, but I concede this is certainly a matter of opinion and preference.
-
RE: Evennia (Arx) webclient feedback
As long as the client retains the same session token, the Evennia webclient will log you back in where you were without need for a login process, even if you drop. But yeah, you will potentially miss stuff happening in the interim.
We don't store the client input history with the session today, but that's certainly something that we could do, it would make for a good usability boost. It'd not be impossible to store a buffer of the last X time's input/output either (since Evennia's input/output format is generalized you could even store OOB messages intended to update your client or, say, button-presses until you reconnect).
There is a quite extensive updates to the Evennia Session system coming and that would make something like this easier to implement. It not something I had planned but I could see the appeal of it.
.
Griatch -
RE: Evennia - a Python-Based Mu* Server
@Groth said:
So looking through the Evennia documentation it seems to support most things that builders would expect out of softcode. The main thing it does not support is the ability to define commands however in my experience builders do not usually need or want to define commands.
The bigger issue I see is that the command library looks rather sparse. For instance their example smile command looks like this
from evennia import Command class CmdSmile(Command): """ A smile command Usage: smile [at] [<someone>] grin [at] [<someone>] Smiles to someone in your vicinity or to the room in general. (This initial string (the __doc__ string) is also used to auto-generate the help for this command) """ key = "smile" aliases = ["smile at", "grin", "grin at"] locks = "cmd:all()" help_category = "General" def parse(self): "Very trivial parser" self.target = self.args.strip() def func(self): "This actually does things" caller = self.caller if not self.target or self.target == "here": string = "%s smiles." % caller.name caller.location.msg_contents(string, exclude=caller) caller.msg("You smile.") else: target = caller.search(self.target) if not target: # caller.search handles error messages return string = "%s smiles to you." % caller.name target.msg(string) string = "You smile to %s." % target.name caller.msg(string) string = "%s smiles to %s." % (caller.name, target.name) caller.location.msg_contents(string, exclude=[caller,target])
That is not a reasonable way for such a simple function to be written. One of the few strengths of MUSHcode is that it has very powerful and easy to use parsers built in and all the relevant variables like the caller, target, arguments etc are already pre-stored into default substitutions variables.
Ah, I guess I should take my first post on musoapbox (hello everybody) to comment on this technical aspect of Evennia's design. For full disclosure - I'm the Evennia lead developer.
Evennia actually does make a minimum of "relevant" variables available in its base Command class. For example you will find self.args (the arguments to this command), self.caller (who called this command) and so on already available on the Command instance. There are some 10 dynamic variables available to the Command at runtime related to the call of it, the object it is assigned to and so on.
The Command class is however (by default) not knowing anything about what syntax you want your commands to support - all it knows at this point is that it has figured out what command-name is being called (the first part of your input, which can have any length, including spaces, how we determine this uniquely is a technical issue I'll leave for now) - the rest of the input string is just dropped in self.args. It's now up to you to parse that.
Now, it may sound like you need to do a lot of parsing all the time (and the smile example is just that - an example where a simple parser was introduced). But the thinking behind the Command system is that Commands are Python classes, and those can be inherited. This means that you implement the parse() method once, storing all the "relevant variables" the way you want. You could also make a little helper method to easily template your return messages to your particular preference (Python excels at string manipulation after all). All other commands that share a similar syntax can now inherit from your custom "MUSHCommand" class and not have to worry about parsing themselves - you'll have all the convenient variables available directly in func(), where you want them to do whatever your command should do.
This is in fact how we implement our "MUX-like" default commands throughout Evennia: they all inherit from MuxCommand, which parses the incoming argument into understanding stuff like /switches, the use of = for assignment and so on. We have a second base class for some admin commands which (some of which were originally borrowed from a MUX flavor) really go all out in syntax complexity ...
Is Evennia's Python code more verbose than softcode, covering more lines for the same functionality? I've not done a comparison - my softcode skills are severely lacking I must admit - but you are probably correct in that.
As for the default command library, there are currently about 90 commands in Evennia's default set I think. These are by no means intended to be comprehensive though; most are admin-level stuff (boring stuff all games need). We expect most commands will be modified to fit each game anyway. We could certainly offer more Commands to build from in our contrib/ folder though, this is a slowly growing resource.
.
Griatch -
RE: Evennia - a Python-Based Mu* Server
@ThatGuyThere said:
Fair enough and part of the reason I bring up questions is to spur that thought by developers. In the MUSH community there is less of a divide between players and developers, we are all pretty one big soup. so when I mention things that might need to be added I do it at least partially because people reading this boards will be the ones making the games I play. Heck Theno has coded on or supplied code for at least 4 games i have played in the past and likely more. That is why I insert player concerns into these threads.
My second concern is compatibility with the clients currently in use but that is likely a whole different kettle of fish.
The shared coding aspect tradition of MUSHes is a very fair point. Evennia is not designed (at least not out of the box) for doing such shared coding in-game. Rather it is built for people contributing using professional external code-sharing tools and version control systems. For more advanced game systems, I would propose this is a world-proven, well-developed and highly efficient way to collaborate on code. No server access is necessary to contribute this way, but there is no way around that it is different and a touch more involved than in-game softcode coding.
@Tirit
This seems to echo the experience of other MU* coders involved in the Evennia community.
As pointed out by @thenomain, @glitch and @ThatGuyThere though, the issue is not really softcode vs Python (as I understand it) but who may code the game and when it can be done. And here Evennia does default to work differently from traditional MUSH.
.
Griatch -
RE: Evennia - a Python-Based Mu* Server
Evennia is a game development framework for building text-based online multiplayer games. It's aimed at small teams of game developers interested in making such a game using primarily Python. To that end it supplies programming resources and tools highly customized for this genre of game. That's it. Those preferring other solutions are more than welcome to pursue them.
I'm surprised and saddened to hear such a bitter tone. Did you maybe try Evennia and were disappointed it was not what you thought it would be?
.
GriatchPS:
Commands are parsed just fine out of the box, but you are given the option to change the syntax to one you prefer better. And to clarify, Evennia always worked like this; there has in fact never been more game-specific code in Evennia's distribution than there is now, due to our contrib folder slowly growing. The features out-of-box are covered here. -
RE: Evennia - a Python-Based Mu* Server
Thanks for the elaboration!
From our perspective the "framework" term is actually the more honest one. Evennia is a MU* server too, which is confusing the issue, but the problem is that traditional MU* people expect something different from a "server/codebase": to many traditional devs it suggests something like Diku or a mudlib containing more game code and aiming to a particular game style. "Framework" better fits what Evennia actually is. Regardless of what we call it, the actual concept of Evennia actually hasn't changed much along the way though: The default commands you get from a vanilla install are still very much remniscent of MUX for example. We've just gradually expanded Evennia's capabilities and made it easier for people to rip out things and replace it with things of their own (if they feel so inclined).
There is no denying that to make the most of Evennia it requires you to read up on what it offers. There is a reason we spend so much time on our documentation. If you are completely new to python there will be a definite learning curve. The amount of complete Python newbies using Evennia does suggest it's not impossible however.
Simple examples are always potentially misleading, but if you are completely new to Evennia you might want to try something simple. So here are the lines for adding a trivial echo command: it requires the modification of two files already prepared for you when you initialize your game directory:
# mygame/commands/command.py class MyEcho (Command): key = "echo" def func(self): self.caller.msg("You hear your own echo: '%s'." % self.args.strip())
To add it to your game you need to put your command into a command set. This could be all in the same file if you wanted to, but by default we separate them for cleanliness. Doing so requires two additional lines in another pre-created file:
# mygame/commands/default_cmdsets.py from commands.command import MyEcho #... # (inside the pre-created default cmdset class) self.add(MyEcho())
After a server
@reload
, you can useecho Hellooooo
in game to see your argument returned to you. My impression is that this doesn't represent unsurmountable complexity even for beginner Python users (and we have a lot of those). Admittedly this is a trivial example, but you can get very far from this point by "just" knowing Python along with some of the properties Evennia makes available in the command body.But at the end of the day: Can you "just go learn Python and then use Evennia"? No of course not, in the same way you can't "just go learn C++/Lua and then use the Cryengine"; The language and the libraries on top of it represent different ecosystem levels.
I admit it can be very hard for me/us as developers to actually determine what is hard for a newbie however. We are constantly trying to improve in this respect, so if you have any particular ideas for how you think Evennia could/should improve I'm happy to milk you for them.
.
Griatch -
RE: Non-MU* online roleplay
You could try a vanilla Evennia install. Without further modification you'll have
chat/pose capabilities, can build/describe rooms. You also have npc puppetting, channels etc but it sounds like you more want the writing parts.While it could be (pretty easily) added, there is no rp logging out of the box, but if you are willing to use a separate mu client, that could be handled that way (currently our web client doesn't log).
If you could succinctly list what kind of features you'd want from your environment I could look into making an Evennia tutorial for how to add in eventual missing features.
.
Griatch -
RE: Coming Soon: Arx, After the Reckoning
Just noticed this thread, glad to see people interested in this.
Arx was pretty much a surprise out of nowhere for us in Evennia-land. I happened to stumble over their website during a google search and went and invited them to come chat to us (their in-game dev channel is connected to the #evennia IRC chatroom now).
You guys have made some very impressive progress so far in a relatively short time, it's awesome to hear you may be approaching a more open testing stage!
.
Griatch -
RE: Separating UX from Functionality (Design Patterns!)
@Sparks prototype is indeed looking very cool. There are Django bb apps but this of course has the advantage of being adapted to Evennia - and I guarantee no third party app offers an in-game text-only version of the same thing! Hope you may consider it as an Evennia contrib as some point.
.
Griatch -
RE: The Board Game Thread
@Sab : What do you think about Dark Moon, aka BSG Express?
I'm not @Sab Sab, but I do own Dark Moon. I never played Battlestar Galactica but I enjoy hidden-role games and I heard a lot of good about BSG.
I must admit Dark Moon didn't grip me as much as I hoped it would; I've played it several times and somehow we don't get quite the same level of wild accusations flying and involvement into the outcome as we get when playing a straight-up game of Resistance. Many times it felt like the bad guys had to be pretty overt if they wanted to mess with things and them winning had more to do with poor playing by the good guys than skillful maneuvering on their part.
Maybe I just need to play it more to get the nuances ... but at least so far Dark Moon has not really clicked for me. -
RE: Alternative Formats to MU
@thenomain said in Alternative Formats to MU:
I still consider Evennia a MUD-like because, as you said earlier, it's not a game installation, but a framework in which you can create a game.
I would personally say that Evennia is an engine/framework for creating MU* games, some of which are "MUSH-like" or "MUD-like" depedning on your goals. I think our developers are pretty evenly split between either play style (with a few going far away from either or combining elements of each).
The built-in interpreter, that you can code from the inside, is what I use to classify a MUSH-like game.
Hey, if that is the only definition, then Evennia can (now) fulfill it. Just activate the in-game-python Evennia contrib module and you can essentially code and script your game in-Python from inside the game. Now, it's not safe for use by untrusted users. I wouldn't personally want to code a game over a telnet-like connection when I could use real development tools outside the game. But it's real Evennia softcode if that's your cup of tea.
@thatguythere said in Alternative Formats to MU:
@arkandel said in Alternative Formats to MU:
For me RP needs to be real time. Again, it doesn't mean this is the only 'valid' way to do it, but that's what would work for me.
This would be the biggest sticking point for me to move away from telnet. If the RP is not real time I lose interest. I tend to wander a bit waiting for a pose if it is longer than 5 minutes. With MUSH this is when i get my house work done peeking back every couple of minutes until things pick up. Sadly with web based this would be were I found a video to watch and the scene would likely be forgotten about.
Out of curiosity, why do you feel telnet is needed for real-time interaction? Modern web browser clients with websockets or ajax/comet can (and do) also produce real-time game play. I can see the argument for long-time mud-clients having more features than their browser equivalents, but telnet has nothing to do with that? Maybe you are referring to "forum RP" when you say "web"?
.
Griatch -
RE: Podcast/interview about Evennia
@faraday said in Podcast/interview about Evennia:
Nice job. And thanks for the shout-out.
Maybe they'll contact you for an interview too; they seemed quite interested in going more into the tech side of things. Previous entries were more into individual games and building.
@Tehom
Ha, yes indeed.
.
Griatch -
RE: The Death Of Telnet: Is It Time To Face The Music?
The discussion of Telnet vs the world is old. From the server-developer's perspective telnet itself is easy to work with. You can even add encryption to make it secure. From the server's perspective the problem is the inconsistencies on the client side. The MUD-extensions to telnet (GMCP/MSSP/MSDP etc) are described in various online documents but there are no "official" standards or agreements apart from what the biggest games/clients once implemented. Going to a web interface when one controls both the server and the client is a very appealing prospect.
(Coincidentally, if anyone's interested in using
/me <pose>
in an Evennia game, you can enter the following (assuming the game didn't remove Evennia's defaultnick
command):nick /me $1 = pose $1
Henceforth,
/me smiles
is the same as doingpose smiles
. ) -
RE: The Board Game Thread
@cobaltasaurus I've been wanting to try this one but it's not for sale here yet. Will be interested in hearing your opinions on it.
.
Griatch -
RE: Questions About Evennia
We are not tired of people asking questions in the Evennia support channel. If people don't reply right away it's usually because people are preoccupied, not that they ignore you. Time zone differences are also a thing, People are spread all over.
- Yes. Evennia works quite differently under the hood compared to your average mush though.
- Evennia is its own web server and has a default website and webclient it starts along with the server. There is no wiki out of the box.
- Maybe https://github.com/evennia/evennia/wiki/Evennia-Introduction or https://github.com/evennia/evennia/tree/master/evennia/contrib ?
.
Griatch
-
RE: Evscaperoom - a full playable multiplayer 'escape room' in Evennia with a layered story and multiple endings!
@eye8urcake
Thanks! Yes, this makes for quite a different game-style thing a MU* game engine is usually used for. Glad you liked it@Pandora
Awesome to hear! But you never need to get stumped - just eat a pie! The Jester baked for you after all!
.
Griatch -
RE: The Death Of Telnet: Is It Time To Face The Music?
The 'issue with telnet', from the perspective of the server is indeed not the protocol itself but the inconsistency in the interfaces of the clients using it and the lack of standards when it comes to the mud-specific telnet extensions. This is a technical issue and it matters greatly for your development time if you can't be sure just how your fancy new design will show up in different clients.
If you make your own stand-alone telnet (or whatever protocol) client or dictate that your game only works with a single client of a specific version, design and specification, that'll indeed serve the same purpose as supplying a web client (assuming you make it cross-platform). Depending on how complex your designs you'll also need an update-infrastructure or otherwise make sure that your players all update their client down the line as you add new features or gui elements. Mudlet has this for plug-in GUIs as far as i know. Web clients have it natively.
.
Griatch