Planet Mud-Dev

October 11, 2015


Illustrations and soaps

I recently made an article presenting the infrastructure and main coding features of Evennia using a series of nifty diagrams.

It can hopefully help newcomers get a feeling for the grand structure of an Evennia server/game a little easier. It's published as a feature on Optional Realities and you can find the article here: Evennia Illustrated.

I also recently joined MU Soapbox, a forum predominantly discussing MUSH games, to answer some technical questions on Evennia. Unsurprisingly, some (although so far surprisingly few) MUSHers express concern about Evennia's explicit lack of softcode (that is, the ability for players to use a safe in-game language to code their game rather than to use external Python modules). Their argument is sound:  They are used to in-game coding as a way to easily express creatitivy and easily garner help from players.

Evennia's stance here clash a bit with those opinions: Our philosophy is that our command system is powerful enough to offer players any complexity of build commands they want. The design/coding of the game itself should be done using proper coding IDEs and modern version control tools.

There is no denying that compared to a softcode-coded game, a player-level contributor to an Evennia game needs some extra tools to create and contribute code over version control. The admin also needs to check such contributions for malicious code before merging it into their running game. Now, these are differences I actually consider advantages from a code-quality perspective. And for finding help, people on average are more likely to know Python than a custom softcode language. But here opinions differ and in a given game community those language adoption numbers can be severely skewed.

So far, the MUSHers that have adopted Evennia seems to have done so very much to get away from softcode. It will be interesting to see if things like Kelketek's in-development Group building Evennia contrib will be stirring some interest from those on the fence, or if coding their entire game in softcode is indeed an irreplaceable source of their gaming fun.

by Griatch Art ( at October 11, 2015 02:26 PM

Optional Realities

Preserving Game Concept in Development

written by Raphael Osteen (“Jeshin”)

In the gaming industry there are often points in the development of a product at which the original idea and plans meet with the constraints of reality and the developmental budget. When this happens, the people whose goal it is to transform a game concept into a product have to make realistic decisions about how best to maintain the idea of a game when producing the final product. This can often lead to features being removed or altered to be less resource-intensive, or less interconnected with other game or feature systems.

When it comes to text-based gaming, developers are less often concerned with resources from budget and cashflow, but instead concern themselves with motivation and release date. The biggest concern that text-based gaming projects face in the progression of development to release, is that changes to ideas are difficult to properly translate into gameplay.

Often when a game is first conceptualized there is a core gameplay feature or story element which births the idea. With the original Zelda, one such element was the ability to explore and progress without linear storytelling. This goal in the game’s development was the driving force behind many of the concepts that made it into the final product. Many would say that these ideas for Zelda went from concept features to gameplay very efficiently, in that the sense of adventure and exploration was conveyed with game mechanics that worked well together and fed into that theme.

In the same vein one can critically examine a game like Aliens: Colonial Marines, a game that released one of the most praised E3 trailers of all time and clearly had a design direction that was ambitious, but powerful in the horror suspense genre. The issue became that the final game did not have the same game concepts reflected in its gameplay. What was an immersive and suspense filled game, based on its trailer, ended up being a generic shooter. At some point in the game’s development the concepts and ideas that had motivated its original direction were removed from the final product. That decision ruined the game according a staggering number critics and fans.

During the development of MUDs there are generally two common starting points. A potential developer can create their game using a custom codebase, or they can refurbish an existing codebase for their own use. For the most part, the projects which most successfully convert game concepts into final products are those built on the foundations of existing codebases.

Unlike professionally produced games with large teams of paid employees and contractors– which can work through staff burnout by hiring others– text-based game development is driven by small teams or individuals with a passion for their projects. A developer losing interest or motivation for their product, or burnout, is the most common reason text-based game concepts turn into vaporware.

This is why refurbishing an existing codebase and using pre-existing game systems with modifications is the most common way that new games are produced. They have short development lifecycles and thus lower risk of burnout amongst their teams. The downside to this is that when a developer works from a pre-existing base, their game concept will not always last from the beginning of development until the end. Sometimes things they imagined, or wanted the engine to do, will simply not work—or they’ll have to be implemented in a janky fashion.

Applying one of the professional gaming industry’s valuable abilities– the ability to convert game concepts into a reliable finished product with the desired gameplay elements– to text-based games and their development isn’t impossible, and oftentimes it’s not entirely difficult, despite the sometimes overwhelming ‘volunteer’ nature of such projects.

There will always be a difference between where a developer starts and where they will end, and the road between them is the development lifecycle. Potential developers have to be wary of the length of this period because games that never leave development are vaporware and the longer a development lifecycle becomes, the higher risk there is of burnout among one or more team members, financial issues, or a myriad of other problems that can be devastating to the development of a potential text-based game. This is universal. Whether a project in development is a volunteer undertaking or a professional enterprise, there will be obstacles to team productivity such as a financial issue, a decline in motivation, or the prioritizing of more important or profitable activities among team members.

That being said, some of the tips and tricks of the trade easily transfer between massive-scale game production and that of text-based gaming. One trick is to have a realistic game concept which focuses on direction more than fleshing out every aspect of the game on day one. When a developer begins to write game systems, it helps to make sure they are modular and take into account their interactions.

It’s important to understand why players will want to engage with these game systems– otherwise they will go unused. Critically examine any wealth and upgrade mini-game in an Assassins Creed series title. They are abusable, low reward, and actually detract from many players’ gaming experience because they do not compliment the core game systems. It’s possible that they were tacked on after the realization of the original idea as a way to lengthen the games’ playing time. For MUDs this can happen when developers do not properly balance their core game systems, like combat, social RP, or travel, with their lower priority systems. This leads to those systems being underutilized or outright ignored, thus harming the cohesion of their game world.

Identifying the path a game takes from concept, to development, to actual product is helpful in a lot of ways. It shows where many systemic problems in gaming come from, not only for video games but text-based games as well. Oftentimes games are started with the purest of intentions and the most innovative of ideas, but the truth is that development forces the reality of time and energy on all things. Potential developers need to approach it carefully if they want to preserve their game concept.

As this is a two part series on the transition of game concept into gameplay, the following article will identify the kind of issues that will crop up when that transition fails and how potential developers can best address them.


Jeshin is best known as an outspoken and experienced player of pretty much every existing RPI, as well as for his ten years of work as a Storyteller and Public Relations Admin for The Sea of Storms.

Editor: Sam Crowley, or “Leah,” is a semi-inactive member of the Optional Realities’ Community Forum.


Join the Discussion!

The post Preserving Game Concept in Development appeared first on Optional Realities.

by God at October 11, 2015 07:57 AM