Planet Mud-Dev

July 31, 2015

Optional Realities

Lowering Barriers to Entry, Part Two (of Two)

written by Stefan Ludlow (“Icarus”)

In Part One of my article “Lowering Barriers to Entry”, I discussed the new player experience in our games. Now, I’d like to discuss the two facets of the main idea that I believe needs to be a central tenant of the our roleplaying genre:


New players must be able to actively engage with the game within the first 2 hours of play, regardless of any other factor.


This means that players must be able to: 


– Learn and apply the basic commands that they will need to play the game.


– Use those commands to play the game in an immersive way.


Atonement, Parallel, and Shadows of Isildur managed to make significant strides toward accomplishing #2 at the end of character generation. Players could come into the game with armor, weapons, and crafting supplies in such quantities that they, if they knew what they were doing, could get a quick start and be useful in the game-world. For experienced players, this eased their entry into the game. However, for new players who had no understanding of the basic mechanics of the world, or how the items they were given impacted their play, this was still inadequate. Despite these games having the same administrators, the same staff, and the same resourcesm we never identified #1 as a major priority.


Let me be clear, for our games to succeed in the future, new players must be first able to learn and use the basic game commands to play the games. And honestly, with very little effort on their parts to do so. They need to be fed this information.


So, how do we accomplish this? Most modern AAA games utilize in-game tutorials for this purpose. These tutorials are not walls of text, but rather they encourage learning through playing. It has been documented time and again that walls of text telling people how to play a game do not work; most potential players just aren’t going to spend time clicking through a game’s Wiki or reading helpfiles. Rather players must be shown how to use the commands in a meaningful way from their very first introduction to the game. This creates a conundrum for our games, as we are text-based. A wall of text is indeed the easiest way for us to explain a mechanic, yet it is also perhaps the worst way we can explain a mechanic. As we are multiplayer games too, we don’t often have the opportunity to gently introduce new players to these systems in such a way that isn’t completely jarring to older players who are playing to immerse themselves in our games’ worlds.


In researching potential solutions for the upcoming Sanctuary MMO, I’m looking at instanced new-player environments as a way to introduce players to the basic commands and concepts of the game. As a sci-fi text-based MMO, I have some latitude here as I can easily wrap the tutorial area into “virtual reality” flavor, but I believe that any text based game could accomplish something similar. Less roleplay-focused games like Achaea and Aardwolf certainly manage to do so. The key is to keep things nice and simple. Introduce one element at a time in a safe environment, build upon previously learned skills, and give the player an experience pleasant enough that they won’t even know they are moving through a tutorial environment. Include your game’s roleplaying tools and encourage them to roleplay through your scripted event tutorials, so that they understand what sort of game it is that they are playing.


I firmly believe that by accomplishing this task, we can bring the user-friendliness of text-based games back in line with modern MMOs, to a certain extent. We’ve lagged behind for far too long, and it’s time to come out of the darkness and join other developers in following the industry’s best practices. Text-based games are currently undergoing something of a renaissance in the Interactive Fiction genre – let’s extend that renaissance to the RPI genre.

Icarus is best known for his work as a Senior Administrator on Shadows of Isildur’s Mirkwood region, Parallel RPI, and Atonement RPI’s Grungetown region. He got his start as a Craft Designer on Shadow of Isildur’s Gondor region.

Join the Discussion!

The post Lowering Barriers to Entry, Part Two (of Two) appeared first on Optional Realities.

by Jaunt at July 31, 2015 01:58 AM

July 29, 2015


Further replacements

A short note that you can now use edit on ContentObjectIdentifier fields. However, I did end up going with the editinstance 4 gender Core:Female style, so I may (after saying I wouldn't) end up redoing the other build commands to take colon-delimited identifiers. I'll figure it out later.

In more substantial news, I successfully used the Java Minimal Template Engine to change how emotes are done, and will apply it to other parts of the code later. Now, an emote that used to look like "$n nods to you" will now look like "${actor:name} nods to you". It's longer, but MUCH easier to read. The pronouns are handled with things like "${actor:himher}". This will be far more useful with prompts later on, but I won't do those until after I've made Resources a thing.

Additionally, I made a new Content Object: Author. It won't be visible by players, it'll just be used to track the person or people who worked on an Area. Right now it just holds their full name (in case it has spaces or something else not usable for an identifier), their e-mail address, and their website (which will ideally be for linking to other work by that author). This is mostly for pulling more information off the Content Pack object itself, which I eventually want to have nothing at all except the content objects so that they no longer have to be themselves Editable, but it provides a better way to give attribution and author info than the old way (a regular String).

Now that I have one full converted object (Genders) I can readily move on adding and converting more objects, which is fantastic. Full speed ahead!

July 29, 2015 11:31 PM

July 28, 2015


DIY Gender

Genders are now Content Objects. The Core area comes with two (male and female) and if a Mobile doesn't have one assigned, any attempts to use its gender will get a special 'genderless' gender with it/its for pronouns.

This means that you can create as arbitrarily many as you want, and put them in Content Packs. When I get around to putting races into content packs as well, this means you can create your own race that has its own genders; the most obvious example of this would be an insectoid race with worker/warrior/queen for its genders. It's not the most large-scale example, but it was the smallest and easiest, so I did it first as a proof-of-concept.

However, there's currently no way to actually assign a gender to a Mobile except by editing the save file, because it is not stored as a direct reference but instead just a ContentObjectIdentifier - a Content Pack + Object Identifier object, which are currently not editable. This is because if I stored a direct reference, then any time the Mobile was saved/loaded it would end up creating a new Gender object, and if I made changes to the original (say, I realize I mistyped a pronoun), it wouldn't be pushed out. This way, because I just have a Pack+ID reference, it looks up the gender every time to always get the correct information.

(While I am developing, I am going to be doing this a lot, always checking the master copy. If performance becomes an issue down the road, stuff like this would be perfect for employing caching; however, for now, to keep things simple I am not going to do that.)

However, since I'm going to be following this pattern quite often as more and more attributes of players and mobiles become Content Objects, I'm going to have to make it so that ContentPackName:ObjectIdentifier strings can be assigned to ContentObjectIdentifier fields. Then, once I do that, to set a gender you would do something like the following:

edit Example Mobile TestMobile gender Core:Female

Or with the new editinstance command, if my Instance ID was '4':

edit 4 gender Core:Male

And suddenly, Codelizard is a man.Non-canonically

July 28, 2015 11:08 PM

Fixing an old problem

Entities now have instance IDs and there are statinstance and editinstance commands, though not quite in the way I originally planned.

Firstly, I ditched the idea that instance IDs would be saved. Instead, every time Smerg starts up, instance IDs get reset to 0, and every instance loaded or instantiated gets allocated a new ID. This avoids the whole problem of having to track different IDs for different objects; now they are all assigned a globally unique instance ID.

This also solves the problem of needing a fake 'global' content pack for things like the player list; Players are themselves Entities, and thus, have an Instance ID, and can be modified with editinstance.

Now, for this to really work I'm going to need to add a ton of different ways to report instance IDs to admins, typically by prefixing them to the shortdesc and adding them to any lists.

I still have to rewrite how manual invocations happen (there'll be an invoke or instantiate command) but not all Entities can be arbitrarily instantiated - Rooms, for instance. They'll also do different things when instantiated; items will go into the admin's inventory while mobiles will go into their room. I'll have to add a couple methods to Entity: canInvoke() which will have the same basic idea as canDelete(), and then afterInvoke(Administrator) which will let the Entity decide what to do after it has been instantiated.

There's also the problem of deleting entities, which will have to work in the same way. If you delete an entity, it'll need to know what to do with itself by way of cleanup; removing itself from the inventory of the person carrying it (which means entities are going to need to know if they have an owner...), removing people from rooms, and so on.

Additionally, because all instance-specific stuff has its own command, I'm not going to make commands take colon-delimited arguments, and just keep them consistent with everything else - so "list Core Emote" will remain the same, and will not become "list Core:Emote" and so on.

July 28, 2015 07:52 PM

Sorrows mudlib

Imaginary Realities volume 7, issue 3 is out!

The latest issue of Imaginary Realities is now available for reading.  Volume 7, issue 3.

It features the following articles:

  • A text MUD with a working ecology system
  • Dispelling the gloom
  • How integral are letters and text to ASCII gaming?
  • Legend and the lore
  • The bonds of mudding
  • The mercurial temperament at the end of the world
  • Where do I begin?
With one article related to roguelikes, another to interactive fiction and the rest to mudding, it should provide our most diverse collection yet.

PDF and EPUB e-books are not currently available.  The new website generation creates these automatically, rather than manually as they were made before.  But unfortunately, getting them to look nice enough to be worth distributing requires a little more work.  They'll be added back to the website before (or with) the next issue hopefully.

Announcements have been made on:

by Richard ( at July 28, 2015 05:39 PM


Coming Soon to an Epitaph Near You

We’re not going to have strongholds for the next patch – instead, the Codex system is going to be introduced. Hugo has been working hard[1] on putting content in this, and has even written an article for the new issue of Imaginary Realities to explain what he’s planning for it. For now, think of it like an in-game story system you progressively unlock with clues you find in the game. There’s XP, titles, and achievements that go along with it, and will flesh out some more of the world in which you wander. For those interested in the new Imaginary … Continue reading

by drakkos at July 28, 2015 09:15 AM