I've not posted here in a while, but just had a new release. Evennia, the Python MU* creation system, is moving forward, now at version 4.0.0 (we follow semantic versioning).

Release post

Evennia 4.0.0

March 17, 2024

Major release. Check out for backwards-incompatible changes below.

Version updates

• Feature: Support Python 3.12 (Griatch). Currently supporting 3.10,3.11 and 3.12. Note that 3.10 support will be removed in a future release.
• Feature: Update evennia[extra] scipy dependency to 1.12 to support latest Python. Note that this may change which (equivalent) path is being picked when following an xyzgrid contrib pathfinding.
  Backwards incompatible changes
• Feature: Backwards incompatible: DefaultObject.get_numbered_name now gets object's name via .get_display_name for better compatibility with recog systems.
• Feature: Backwards incompatible: Removed the (#dbref) display from DefaultObject.get_display_name, instead using new .get_extra_display_name_info method for getting this info. The Object's display template was extended for optionally adding this information. This makes showing extra object info to admins an explicit action and opens up get_display_name for general use.
• Fix: (partly Backwards incompatible depending on your usage): DefaultObject.get_numbered_name used .name instead of
  .get_display_name before, which broke recog systems.

New features

• Feature: Add ON_DEMAND_HANDLER.set_dt(key, category, dt) and .set_stage(key, category, stage) to allow manual tweaking of task timings, for example for a spell speeding a plant's growth (Griatch)
• Feature: Add ON_DEMAND_HANDLER.get_dt/stages(key,category, **kwargs), where the kwargs are passed into any stage-callable defined with the stages. (Griatch)
• Feature: Add use_assertequal kwarg to the EvenniaCommandTestMixin testing class; this uses django's assertEqual over the default more lenient checker, which can be useful for testing table whitespace (Griatch)
• Feature: New utils.group_objects_by_key_and_desc for grouping a list of objects based on the visible key and desc. Useful for inventory listings (Griatch)
• Feature: Add DefaultObject.get_numbered_name return_string bool kwarg, for only returning singular/plural based on count instead of a tuple with both (Griatch)

Bug and security fixes

• Fix Removed the @reboot alias to @reset to not mislead people into thinking you can do a portal+server reboot from in-game (you cannot) (Griatch)
• Fix: Refactor Clothing contrib's inventory command align with Evennia core's version (michaelfaith84, Griatch)
• Fix: Limiting search by tag didn't take search-string into account (Griatch)
• Fix: SSH connection caused a traceback in protocol (Griatch)
• Fix: Resolve a bug when loading on-demand-handler data from database (Griatch)
• Security: Potential O(n2) regex exploit in rpsystem regex (Griatch)
• Security: Fix potential redirect vulnerability in character page redirect (Griatch)
• Doc fixes (iLPdev, Griatch, CloudKeeper)

http://evennia.blogspot.com/2021/01/happy-new-years-2021-evennia-things-to.html?m=1

A happy-new-years-blog post summing up some of the new things being worked on for the Python MU development system Evennia in 2021!

I completely forgot to check back on this thread, but people seem to have replied to upcoming questions just fine already.
You can also find a summary of what Evennia is under the Overview section on the main https://www.evennia.com homepage.
.
Griatch

@phase-face

Whereas you ask some good specific questions about design, I would like to be a little more generic and add that the main thing for any hobby project is to get to something playable before your determination runs out or your hard drive crashes.

In a hobby/free-time-driven game development process, 99.99% of good ideas never lead to a game people can actually play. People in this thread have good specific advice - you should heed those you like. But I'd suggest not covering all bases immediately - planning is fine but you need to eventually do something, create something you can show off. A sort of save-point you can continue from should the unforeseen happen and you have to take a break from your project.

Keep your grand plans in mind but strip most of them away for your first version - you will often find even 'must-have' features are not so must-have once you realize other things are not yet in place. The 'perpetual beta' is a tried and true concept for a reason; not assuming (indeed knowing) that your first few versions will be incomplete and imperfect can be quite liberating and allow you to get something out sooner.

@tce said in Evscaperoom - a full playable multiplayer 'escape room' in Evennia with a layered story and multiple endings!:

Oh, hey. This reminds me of the quests from DragonMUD and gives me all kinds of nostalgia fuzzies

I never played DragonMUD but glad to hear this gives good vibes.
.
Griatch

Since people have asked me about it, the Evscaperoom can nowadays be played in the browser at https://demo.evennia.com or via telnet at demo.evennia.com port 4000. After you connect, just write evscaperoom in the first room to start!

Please read the help carefully, due to the restrictions of the format (read my dev blog above for more info), this does not play quite like a normal MU* does.

Plenty of people have tried (and seem to have enjoyed) this, both trying to solve the puzzles and trying to deduce what the heck is actually going on in that little village by the highway. It's really fun to see people use the multi-player aspect to join a room in pairs/groups to solve it together too!

top left: Evennia server running. Top right: Default website. Bottom left: HTML5 webclient. Bottom right: Telnet client (tintin++).

Evennia is a Python MUD/MU* creation library and framework. This is an intermediary release, leading up to the future v1.0. If you have followed the Evennia master branch, this will not be much change code-wise, but compared to 0.9, there are a lot of new features, fixes and improvements!

The main feature is otherwise on the 'meta' level in that we have moved to a static documentation and have overhauled evennia.com.

Check out the dev blog post for more details: http://evennia.blogspot.com/2020/11/evennia-095-released.html

@Ifrit This thread have more steered towards Ares implementation and use, but to reply to the original post - a scene-system would work well to implement in Evennia and would of course be useful to have as a contrib. Some, like Pax, already considered/worked on it but I don't think there is a complete system available at this time.

... But even so, Evennia and its contribs tend to be more developer/toolbox-centric. If the goal was more Ares-like plug-and-play one would need to release things as a gamestyle-specific Evennia game-dir (like Arx did for Arxcode, but with a bit more polish for reuse).

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

@The-Sands There is no reason not to allow people to chat, read help files etc while in a menu, as long as the commands don't clash with the menu's commands one could in principle have access to all normal commands, if so desired. A menu is just a CmdSet after all.

@The-Sands

I would suggest that menus is actually a pretty good option when you have 'hundreds of possible stats' to choose from - they allow users to get a chance to explore themselves what to pick without having to refer to external documentation.

EvMenus are created in-code, which means that they can be dynamically generated from a list of stats rather than you having to maintain and update it separately. The EvMenu also comes with the list_node decorator to turn a menu node into a multi-page list of alphabetized (or whatever order you prefer) list of entries for the user to select between. Below it's only 10 (rather long) options per page, but you can set that as you like:

@The-Sands

Maybe you want to consider also utilizing Evennia EvMenus for these commands in addition to the pure command-with-arguments-and-switches approach. Even if a menu is slower for experienced users, for a newcomer they make it very easy to explore and learn what is available.
.
Griatch

@Selerik This is a bit of a thread-necro, but I just noticed this topic and wondered if you ever continued this exploration or what the conclusion was?

@The-Sands Awesome progress there! I can't say I have enough experience with that rule system to help out with the details, but good luck!

Finally, after diving into Evennia a bit I think it's got a lot of promise since nearly all the commands accessed by players are overwriteable

A small correction: all commands, available to players or otherwise, are replaceable.
.
Griatch

Hi folks, I wrote a new Evennia dev blog here in these curious times to outline what's happening with this Python MU* development system as we progress towards version 1.0.
.
Griatch

Freeman Dyson (most commonly known for the Dyson sphere concept, but really credited for a lot more)

@Lotherio said in Serious Question About Making A MU:

I imagine Evennia may be the same, combat goes by the numbers but its not fully tapped into for the versatility it can provide.

Just to be clear, Evennia itself has no prescribed combat system whatsoever. It's up to each game-maker to pick a contrib combat system or, like Arx, make their own combat system on top of the Evennia framework.

@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.

@faraday Yes, coding a full game in any language and framework will always take a lot of work. To learn programming means both learning a language and a mindset.

It doesn't change the fact that Ruby/Python are some of the best beginner languages around. I stand by my opinion that for being programming languages they are outright easy to learn and get started in. Does that mean that it takes no effort at all? Of course not. But even minute knowledge in either will help you tremendously and is a worthwhile thing to spend time on.

The original post didn't mention if @HelloProject had any code experience or willingness to learn some. But I note people in the thread are referring to themselves as wanting to make a game without any coding. Which is fine, by all means.

But for the record, Ruby (for Ares) or Python (for something like Evennia) are languages that are simple to learn. Both are also worthwhile to know outside the hobby (unlike mush softcode which has no use outside the mush world).
And the power even a little code-skill opens up to you is tremendous, far out-weighing the effort to learn it. It's what allows you to go beyond anything the engine dev imagined and make your game truly uniquely yours.