mirror of
https://bitbucket.org/oreolek/imaginary-realities.git
synced 2024-05-17 00:18:26 +03:00
Add the templates, and associated template files.
This commit is contained in:
richard.m.tew@gmail.com
parent
6334be83be
commit
59e33a6579
114
templates/base.html
Normal file
114
templates/base.html
Normal file
|
|
@ -0,0 +1,114 @@
|
|||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<!-- This page is generated from templates -->
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||||
|
||||
<link rel="alternate" type="application/rss+xml" href="{{tp.rss_link}}" title="Imaginary Realities release feed">
|
||||
<link href="{{tp.link_prefix}}css/reset.css" rel="stylesheet" media="screen, handheld, print, projection">
|
||||
<link href="{{tp.link_prefix}}css/style.css" rel="stylesheet" media="screen, handheld, print, projection">
|
||||
<link href="{{tp.link_prefix}}css/style-desktop.css" rel="stylesheet" media="screen and (min-device-width:768px) and (min-width:768px), print, projection">
|
||||
<script src="{{tp.link_prefix}}js/modernizr.js"></script>
|
||||
|
||||
<title>{{tp.website_title_text}} - {% block page_title %}{% endblock %}</title>
|
||||
</head>
|
||||
<body>
|
||||
<a id="menu-area" href="#0"><span class="menu-text">Menu</span><span class="menu-icon"></span></a>
|
||||
<header>
|
||||
<div class="title"><a href="{{tp.homepage_link}}">IMAGINARY REALITIES</a></div>
|
||||
</header>
|
||||
<main>
|
||||
<div class="main">
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="current-issue">{{tp.content_title}}</a></div>
|
||||
<div class="mainbody">
|
||||
{{tp.content}}
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
</div>
|
||||
</main>
|
||||
<footer>
|
||||
<div>
|
||||
<div class="section">
|
||||
<a href="{{tp.copyright_link}}"><img class="mini" alt="Copyright symbol icon" src="{{tp.link_prefix}}images/copyright.svg"/><span>Copyright</span></a>
|
||||
<a href="{{tp.contact_link}}"><img class="mini" alt="Email envelope icon" src="{{tp.link_prefix}}images/email.svg"/><span>Contact Us</span></a>
|
||||
</div>
|
||||
<div class="section">
|
||||
<a href="{{tp.rss_link}}"><img class="mini" alt="Standard RSS icon" src="{{tp.link_prefix}}images/rss.svg"/><span>RSS</span></a>
|
||||
<a href="{{tp.twitter_link}}"><img class="mini" src="{{tp.link_prefix}}images/twitter.svg"/><span>Twitter</span></a>
|
||||
<a href="{{tp.reddit_link}}"><img class="mini" alt="Reddit icon" src="{{tp.link_prefix}}images/reddit.svg"/><span>Reddit</span></a>
|
||||
</div>
|
||||
</div>
|
||||
</footer>
|
||||
<nav id="lateral-nav">
|
||||
<ul class="cd-navigation">
|
||||
<ul class="cd-navigation cd-single-item-wrapper first-menu-item">
|
||||
<li><a href="{{tp.contribute_link}}">Contribute</a></li>
|
||||
</ul>
|
||||
</ul> <!-- cd-navigation -->
|
||||
|
||||
<ul class="cd-navigation">
|
||||
<li><a href="{{tp.sections.latest_issue.read_link}}">{{tp.menu.latest_issue_title}}</a></li>
|
||||
<li class="item-has-children">
|
||||
<a href="#0">{{tp.menu.back_issues_title}}</a>
|
||||
<ul class="sub-menu">
|
||||
{% for issue in tp.sections.back_issues.issues %}
|
||||
<li><a href="{{issue.link}}">{{issue.volume_text}}, {{issue.issue_text}}</a></li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
</li> <!-- item-has-children -->
|
||||
</ul>
|
||||
<ul class="cd-navigation cd-single-item-wrapper">
|
||||
<li><a href="{{tp.contact_link}}">Contact Us</a></li>
|
||||
<li><a href="{{tp.copyright_link}}">Copyright</a></li>
|
||||
</ul>
|
||||
<ul class="cd-navigation">
|
||||
<li class="item-has-children">
|
||||
<a href="#0">Aggregator Links</a>
|
||||
<ul class="sub-menu">
|
||||
<li><a href="http://planet-muddev.disinterest.org/">Planet MUD-Dev</a></li>
|
||||
<li><a href="http://planet-rldev.disinterest.org">Planet RL-Dev</a></li>
|
||||
<li><a href="http://www.planet-if.com/">Planet IF</a></li>
|
||||
<li><a href="http://www.roguebase.net/">Roguebase</a></li>
|
||||
</ul>
|
||||
</li> <!-- item-has-children -->
|
||||
<li class="item-has-children">
|
||||
<a href="#0">MUD Forum Links</a>
|
||||
<ul class="sub-menu">
|
||||
<li><a href="http://www.mudbytes.net/">MUDBytes</a></li>
|
||||
<li><a href="http://mudconnect.com/SMF/index.php">The MUD Connector</a></li>
|
||||
<li><a href="http://topmudsites.com/forums/">Top Mud Sites</a></li>
|
||||
<li><a href="http://www.reddit.com/r/MUD/">/r/MUD</a></li>
|
||||
</ul>
|
||||
</li> <!-- item-has-children -->
|
||||
<li class="item-has-children">
|
||||
<a href="#0">Roguelike Forum Links</a>
|
||||
<ul class="sub-menu">
|
||||
<li><a href="http://forums.roguetemple.com/index.php">Rogue Temple</a></li>
|
||||
<li><a href="http://www.reddit.com/r/roguelikedev/">/r/roguelikedev</a></li>
|
||||
<li><a href="http://www.reddit.com/r/roguelikes/">/r/roguelikes</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="item-has-children">
|
||||
<a href="#0">IF Forum Links</a>
|
||||
<ul class="sub-menu">
|
||||
<li><a href="http://www.intfiction.org/forum/">intfiction.org</a></li>
|
||||
<li><a href="http://www.reddit.com/r/interactivefiction">/r/interactivefiction</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<div class="cd-navigation socials">
|
||||
<a href="{{tp.contact_link}}"><img src="{{tp.link_prefix}}images/email.svg"/></a>
|
||||
<a href="{{tp.rss_link}}"><img src="{{tp.link_prefix}}images/rss.svg"/></a>
|
||||
<a href="{{tp.twitter_link}}"><img src="{{tp.link_prefix}}images/twitter.svg"/></a>
|
||||
<a href="{{tp.reddit_link}}"><img src="{{tp.link_prefix}}images/reddit.svg"/></a>
|
||||
</div>
|
||||
</nav>
|
||||
<script src="{{tp.js_jquery_link}}"></script>
|
||||
<script src="{{tp.link_prefix}}js/main.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
13
templates/contact.html
Normal file
13
templates/contact.html
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
{% extends "base.html" %}
|
||||
{% block page_title %}
|
||||
Contact Information
|
||||
{% endblock %}
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="contribute">Contact Information</a></div>
|
||||
<div class="mainbody">
|
||||
<p>You can contact <a href="mailto:richard.m.tew@gmail.com">Richard Tew</a> regarding any matter to do with Imaginary Realities.</p>
|
||||
<p>If you are considering contributing an article, it might be worth reading over the <a href="{{tp.contribute_link}}">contribution requirements</a> before offering to do so.</p>
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
50
templates/contribute.html
Normal file
50
templates/contribute.html
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
{% extends "base.html" %}
|
||||
{% block page_title %}
|
||||
Contribute
|
||||
{% endblock %}
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="contribute">Contribute</a></div>
|
||||
<div class="mainbody">
|
||||
<p>
|
||||
If you have an idea for an article you would like to write for us, please <a href="{{tp.contact_link}}">contact us</a>. If you don't have an idea, but would like
|
||||
to write an article and are not sure what to write about, that's also okay.
|
||||
</p>
|
||||
<p>
|
||||
Submissions must meet the following requirements:
|
||||
<p>
|
||||
<ul class="squarelist">
|
||||
<li>Articles must be within the range of 1000-4000 words. Longer articles may be approved for serialisation, in order to reduce the workload of the editors and proofreaders.</li>
|
||||
<li>Articles must be original material, not yet published elsewhere. The article should not be published elsewhere until a week has passed after we publish the issue containing it.</li>
|
||||
<li>Authors are required to license their article to us under the <a href="{{tp.license_link}}">By Attribution Non-Commercial Share-Alike</a> Creative Commons license.</li>
|
||||
</ul>
|
||||
<p>
|
||||
<!--<a href="https://creativecommons.org/licenses/by-nc-sa/3.0/nz/"><img alt="By Attribution Non-Commercial Share-Alike icon" src="images/CC-BY-NC-SA-icon-80x15.png"/></a> Creative Commons license.-->
|
||||
The licensing requirement ensures that:
|
||||
</p>
|
||||
<ul class="squarelist">
|
||||
<li>You grant us the right to publish your article.</li>
|
||||
<li>We are not allowed to make money from it.</li>
|
||||
<li>We have to credit you as the author.</li>
|
||||
<li>We are not allowed to modify your work in any way that misrepresents you as the author.</li>
|
||||
</ul>
|
||||
<div class="rcaptionblock"><a href="http://drive.google.com"><img alt="Google Drive logo" src="images/googledrive.svg" width=40px height=40px/></a></div>
|
||||
<p>
|
||||
Your article will be added to our private Google Drive folder, which our editing/proofing team share. It will be shared back to you, and you will be able to see changes made to the document, and edit it to address comments made by the team.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="contribute">Covered Genres</a></div>
|
||||
<div class="mainbody">
|
||||
<p>
|
||||
While we do not limit accepted articles to just the genres featured below, they are the main ones where text-based games are present, and it is not uncommon to find text-based games within them that overlap two of these.
|
||||
</p>
|
||||
<div class="aligned-examples smaller-text">
|
||||
<div class="aligned-example highlight"><img alt="Screenshot of a MUD being played" src="images/example-discworld-01-350x217.png"/><br/>MUD: <a href="http://discworld.imaginary.com:5678/">Discworld</a></div>
|
||||
<div class="aligned-example highlight"><img alt="Screenshot of a roguelike being played" src="images/example-brogue-01-350x217.png"/><br/>Roguelike: <a href="https://sites.google.com/site/broguegame/">Brogue</a></div>
|
||||
<div class="aligned-example highlight"><img alt="Screenshot of an interactive fiction game being played" src="images/example-lostpig-01-350x217.png"/><br/>Interactive Fiction: <a href="http://en.wikipedia.org/wiki/Lost_Pig">Lost Pig</a></div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
14
templates/copyright.html
Normal file
14
templates/copyright.html
Normal file
|
|
@ -0,0 +1,14 @@
|
|||
{% extends "base.html" %}
|
||||
{% block page_title %}
|
||||
Copyright Information
|
||||
{% endblock %}
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="contribute">Copyright Information</a></div>
|
||||
<div class="mainbody">
|
||||
<p>This web site is copyright © 2015 Richard Tew.</p>
|
||||
<p>To date, published issues are copyright © 2013-2015 Jennifer Melchert, Matthew Sheahan, Richard Tew, Richard Woolcock.</p>
|
||||
<p>All contributing authors retain copyright to their work, and have made their contributed work available under the <a href="{{tp.license_link}}">{{tp.license_text}}</a> license, so that we have the right to publish it.</p>
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
96
templates/homepage.html
Normal file
96
templates/homepage.html
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
{% extends "base.html" %}
|
||||
{% block page_title %}
|
||||
A Journal for Text-based Gaming
|
||||
{% endblock %}
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainbody">
|
||||
<img alt="{{tp.sections.introduction.logo_text}}" src="{{tp.sections.introduction.logo_link}}" style="float: left; display: inline-block; padding-right: 15px"/>
|
||||
<p>Imaginary Realities is a journal focusing on text-based gaming, from <a href="http://en.wikipedia.org/wiki/MUD">mudding</a> and <a href="http://en.wikipedia.org/wiki/Roguelike">roguelikes</a>, to <a href="http://en.wikipedia.org/wiki/Interactive_fiction">interactive fiction</a> and beyond.</p>
|
||||
<p>
|
||||
Our goal is to publish issues every couple of months, where we collect together relevant articles written by people from the community, for the enjoyment and education of other people in the community.
|
||||
</p>
|
||||
<p>
|
||||
If you are interested in <a href="{{tp.contribute_link}}">contributing an article</a>, please <a href="{{tp.contact_link}}">get in touch</a>!
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="mainsection">
|
||||
<div class="aligned-examples">
|
||||
<div class="aligned-example text">
|
||||
<div class="mainheader"><a name="current-issue">{{tp.sections.latest_issue.title}}</a></div>
|
||||
<div class="mainbody">
|
||||
<div class="current-issue-title">{{tp.sections.latest_issue.issue_title}}</div>
|
||||
<br/>
|
||||
<div class="table-issues-wrapper indent-left">
|
||||
<table class="table-issues">
|
||||
<thead>
|
||||
<tr>
|
||||
<td>Articles</td>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{% for article in tp.sections.latest_issue.issue_articles %}
|
||||
<tr>
|
||||
<td><a class="row-link" href="{{article.link}}">{{article.title}}</a></td>
|
||||
</tr>
|
||||
{% endfor %}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<br/>
|
||||
<div class="text-read-issue">
|
||||
<a class="action-button" href="{{tp.sections.latest_issue.read_link}}">{{tp.sections.latest_issue.read_text}}</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="aligned-example text">
|
||||
<div class="mainheader"><a name="past-issues">{{tp.sections.back_issues.title}}</a></div>
|
||||
<div class="mainbody">
|
||||
<div class="table-issues-wrapper">
|
||||
<table class="table-issues">
|
||||
<thead>
|
||||
<tr>
|
||||
<td colspan=4>Issues</td>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{% for issue in tp.sections.back_issues.issues %}
|
||||
<tr>
|
||||
<td><a class="row-link" href="{{issue.link}}">{{issue.volume_text}}</a></td>
|
||||
<td><a class="row-link" href="{{issue.link}}">{{issue.issue_text}}</a></td>
|
||||
<td><a class="row-link" href="{{issue.link}}">{{issue.publication_year_text}}</a></td>
|
||||
<td><a class="row-link" href="{{issue.link}}">{{issue.publication_month_text}}</a></td>
|
||||
</tr>
|
||||
{% endfor %}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="aligned-example text">
|
||||
<div class="mainheader"><a name="featured-article">{{tp.sections.featured_article.title}}</a></div>
|
||||
<div class="mainbody">
|
||||
<div class="featured-article-title">{{tp.sections.featured_article.article_title}}</div>
|
||||
<br/>
|
||||
{{tp.sections.featured_article.article_hype_text}}
|
||||
<br/><br/>
|
||||
<div class="quotetext">
|
||||
{{tp.sections.featured_article.article_quote_text}}
|
||||
</div>
|
||||
<div class="quoteattr">{{tp.sections.featured_article.article_authorname_text}}</div>
|
||||
<div class="text-read-issue">
|
||||
<br/>
|
||||
<a class="action-button" href="{{tp.sections.featured_article.read_link}}">{{tp.sections.featured_article.read_text}}</a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="aligned-example text">
|
||||
<div class="mainheader"><a name="recent-comments">{{tp.sections.recent_comments.title}}</a></div>
|
||||
<div class="mainbody">
|
||||
{{tp.sections.recent_comments.content}}
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
25
templates/issue/article/index.html
Normal file
25
templates/issue/article/index.html
Normal file
|
|
@ -0,0 +1,25 @@
|
|||
{% extends "base.html" %}
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="article-title">{% block page_title %}ARTICLE TITLE{% endblock %}</a></div>
|
||||
<div class="mainbody">
|
||||
{% block article_byline %}<p>
|
||||
by {% block article_authors %}SOMEONES{% endblock %}, {% block article_date %}SOMEWHEN{% endblock %}
|
||||
</p>{% endblock %}
|
||||
|
||||
{% block article_content %}
|
||||
<p>
|
||||
<b>ARTICLE CONTENT</b>
|
||||
</p>
|
||||
{% endblock %}
|
||||
<p class="staffbio authorbio">
|
||||
{% block article_bio_content %}
|
||||
<b>AUTHOR BIO</b>
|
||||
{% endblock %}
|
||||
</p>
|
||||
{% block article_references_content %}
|
||||
<h3>References</h3>
|
||||
{% endblock %}
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
9
templates/issue/other/index.html
Normal file
9
templates/issue/other/index.html
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
{% extends "base.html" %}
|
||||
{% block page_content %}
|
||||
<div class="mainsection">
|
||||
<div class="mainheader"><a name="article-title">{% block page_title %}{% endblock %}</a></div>
|
||||
<div class="mainbody">
|
||||
{% block other_content %}{% endblock %}
|
||||
</div>
|
||||
</div>
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,80 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
Blind accessibility: challenges and opportunities
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Matthew “Chaos” Sheahan, 30th October 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p>
|
||||
In the years after the decline of the overall MUD player base from its heights in the 1990s, I gradually noticed that one group of players was particularly stubborn in its attachment to MUDs: blind and visually-impaired people. It made sense: in a gaming world focused on visual experiences, text-based MUDs relied on an interface practically designed for <a href="http://en.wikipedia.org/wiki/Screen_reader">screen readers</a> (the class of software generally used to make the Internet accessible to those who can’t rely on vision). My interest in blind accessibility in MUDs has slowly increased since then, and I’ve come to regard this area as one where MUDs in general face significant challenges, but also meaningful opportunities.
|
||||
</p>
|
||||
<p>
|
||||
I spoke to Dennis “Dentin” Towne, lead coder for <a class="gametitle" href="http://www.alteraeon.com/">Alter Aeon</a>, the MUD widely regarded as the leader in blind accessibility, and to Hussain “Fate” Jasim, blind mudder and developer on my home MUD, <a class="gametitle" href="http://lostsouls.org/">Lost Souls</a>.
|
||||
</p>
|
||||
<h3>The bad news</h3>
|
||||
<p class="quotetext">I'd say it's as difficult to get MUD players in the blind community as it is in the sighted.</p>
|
||||
<p class="quoteattr">— Dennis Towne</p>
|
||||
<p>
|
||||
Towne is quick to caution us that blind accessibility cannot simply be a matter of adding a slapdash handful of features and declaring victory. Meaningful accessibility improvements are best achieved by an ongoing dialogue between developers and the community to identify “what is most needed for a particular game, and what is most helpful”. (Towne 2013)
|
||||
</p>
|
||||
<p>
|
||||
Towne has seen a distressing prevalence of MUDs that “treat the blind rather poorly, like second class citizens or idiots”. Obviously, this isn’t the sort of reception we should be giving any players, particularly not because of a disability.
|
||||
</p>
|
||||
<p>
|
||||
Jasim and Towne both identify spam, in particular combat spam, as one of the biggest accessibility problems in MUDs. On many MUDs, if a screen reader were to output speech at the rate text scrolls by, it would be gibberish, which makes the availability of output filtering a critical issue. Both the server side and the client side can help with this. Server-side filters such as suppression of output from other people fighting in the same room, brief room descriptions, and skipping missed attacks provide both direct benefits, by reducing output at the source, and indirect, by allowing client-based filters to address a more targeted set of cases. Constructing messages so that different types of events have distinctive messages, and preventing those from being spoofed, also helps considerably with designing client-side triggers and filters. At an advanced level, out-of-band data can be attached to messages that gives the client even more to work with. (Jasim 2013, Towne)
|
||||
</p>
|
||||
<p>
|
||||
The second most problematic element common to MUDs is ASCII art, such as pseudographical maps and drawing-character-based diagrams. These are simply nonsense to screen readers, and if vital information is only available through them, that will place blind players at a great disadvantage. Some MUDs address this by providing entirely different output from relevant systems if the player is known to be using a screen reader. (Towne, Jasim)
|
||||
</p>
|
||||
<p>
|
||||
Another design choice that can have an outsized negative impact on blind accessibility is over-reliance on ANSI or MXP color. (Towne) To keep from damaging accessibility, color should be used such that whatever information it conveys is also available through the text. Color should never be the only way to find out significant information. Note that this is as relevant for how your game is experienced by colorblind players as those with more severe visual impairments.
|
||||
</p>
|
||||
<p>
|
||||
Unfortunately, blind accessibility resources available on the Web are of little use in improving the accessibility of MUDs, as they tend to be focused on traditional GUI applications and websites. The text-rich, real-time environment of a MUD has needs that aren’t well-understood in the broader community. (Towne)
|
||||
</p>
|
||||
<p>
|
||||
Towne cautions that, while MUDs have particular appeal for blind players — “the bulk” of <span class="gametitle">Alter Aeon’s</span> player base is blind — this doesn’t necessarily mean that blind players are the strongest of markets for MUDs to draw players from. Like sighted gamers, they’re largely drawn to other genres, some of which are specifically designed for audio-based play. Jasim is the only person who plays MUDs among the visually-impaired people he knows. Towne credits <span class="gametitle">Alter Aeon’s</span> success with blind players mainly to “being an active part of the community for a long time”. He and Jasim both see active engagement and awareness-raising with blind gamers as an important key to successful accessibility efforts.
|
||||
</p>
|
||||
<p>
|
||||
Developing for blind accessibility can be difficult for the sighted simply because it’s an unfamiliar mindset to most. Even in an accessibility-focused MUD, it isn’t unusual to implement a new feature only to realize it needs to behave differently to facilitate accessibility. (Towne)
|
||||
</p>
|
||||
<h3>The good news</h3>
|
||||
<p class="quotetext">MUDs are great… They allow me to explore my imagination and experience the same love of gaming that my peers do while playing MMORPGs.</p>
|
||||
<p class="quoteattr">— Hussain Jasim</p>
|
||||
<p>
|
||||
The starting point of most text-based MUDs is already relatively accessible. Mere reliance on verbal, non-ASCII-art content for the basic interface puts a MUD head and shoulders above most of the software and websites in the world. (Jasim)
|
||||
</p>
|
||||
<p>
|
||||
The most effective way to begin improving accessibility is simply to engage with blind players — either those you already have, and more MUDs have blind players than necessarily realize it, or those on sites for blind gamers like <a class="website" href="http://audiogames.net/">audiogames.net</a> — and listen to their feedback. (Towne, Jasim) Many MUDs have places where a little bit of work can mean a lot of improvement to blind players’ experiences.
|
||||
</p>
|
||||
<p>
|
||||
The MUD community has proven technologies available, like <a href="http://www.zuggsoft.com/zmud/msp.htm">MSP, the MUD Sound Protocol</a>, that can greatly improve accessibility. MSP sound packs are an important part of <span class="gametitle">Alter Aeon’s</span> accessibility approach, Towne having been inspired to add this functionality by the MOO <a class="gametitle" href="http://www.toastsoft.net/">Miriani</a>. (Jasim, Towne)
|
||||
</p>
|
||||
<p>
|
||||
Blind accessibility doesn’t have to mean abandoning powerful ASCII-art-based features entirely. <span class="gametitle">Lost Souls</span> follows an approach of supporting ASCII art features for sighted players and providing alternate forms of those features’ output for those registered as using screen readers. (Jasim) It’s important in approaches like this, though, to “prevent any one group from feeling like they're at a disadvantage to another, which actually does matter for mixed crowds”. (Towne)
|
||||
</p>
|
||||
<h3>Why blind accessible?</h3>
|
||||
<p class="quotetext">I think the only way MUDs will be significant in making accessible gaming experiences available in the future is if the MUD community cooperates with the blind community, such as by including MUD clients on braille notetakers and becoming visible on blind mailing lists.</p>
|
||||
<p class="quoteattr">— Hussain Jasim</p>
|
||||
<p>
|
||||
So, then, are the opportunities here worth taking on the challenges? Why prioritize blind accessibility?
|
||||
</p>
|
||||
<p>
|
||||
For any MUD developer traumatized by living under the shadow of mass-market AAA MMORPGs, there’s a simple and superficially compelling argument that a blind player is one who will never abandon a MUD for the latest shiny graphics. That’s a limited perspective that may lead to unreasonable expectations, though, since blind players cycle through games like anyone else, and as Towne points out, they have plenty of options available. So the siren song of loyal players is probably not the best way to motivate developers toward accessibility efforts.
|
||||
</p>
|
||||
<p>
|
||||
Possibly the most compelling reason is social responsibility. I don’t mean this strictly in the sense that it’s ethically desirable to provide accommodations for people with disabilities, though that’s true and relevant. I mean it equally in the sense that <em>these are our players</em>, and as developers we have a measure of responsibility in the experience that they have in playing our games. That this experience is different from ours, if we are sighted, doesn’t particularly alter this consideration. So if, by listening to the feedback of my players and spending some of my time, I can improve the experience my game provides to a number of people over many hours, I call that a win.
|
||||
</p>
|
||||
<p>
|
||||
Beyond the immediate gains, though, I think work done on accessibility has the potential to grant MUD developers much-needed perspective in the area of user experience design. It essentially forces us over what can be a difficult hurdle in that area: understanding the user’s experience as meaningfully different from our own, and validly so. Reaching that perspective, whether through working on blind accessibility or otherwise, could turn out to be the difference between a good MUD developer and a great one.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Chaos (Matthew Sheahan) is the lead developer of <a class="gametitle" href="http://lostsouls.org/">Lost Souls</a> and the maintainer of <a class="website" href="http://mudseek.com/">MUDseek</a>.
|
||||
{% endblock %}
|
||||
{% block article_references_content %}
|
||||
{{ super() }}
|
||||
<p class="citation">Towne, Dennis. Interview by author. Email. August 15, 2013.</p>
|
||||
<p class="citation">Jasim, Hussain. Interview by author. Email. October 30, 2013.</p>
|
||||
{% endblock %}
|
||||
BIN
templates/volume05_issue01/copyright/images/spreddit3.gif
Normal file
BIN
templates/volume05_issue01/copyright/images/spreddit3.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
11
templates/volume05_issue01/copyright/index.html
Normal file
11
templates/volume05_issue01/copyright/index.html
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
{% extends "issue/other/index.html" %}
|
||||
{% block page_title %}Copyright{% endblock %}
|
||||
{% block other_content %}
|
||||
<p>
|
||||
This issue of Imaginary Realities is copyright © 2013 Jennifer Melchert, Matthew Sheahan, Richard Tew, Richard Woolcock.
|
||||
</p>
|
||||
<p>
|
||||
All authors retain copyright to their work, and have made their work available under the
|
||||
<a href="{{tp.license_link}}">{{tp.license_text}}</a> license, which allows us to publish it.
|
||||
</p>
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 261 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
231
templates/volume05_issue01/evennia-introduction/index.html
Normal file
231
templates/volume05_issue01/evennia-introduction/index.html
Normal file
|
|
@ -0,0 +1,231 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
Evennia: an introduction
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Griatch, 10th September 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<h3>How I got into Evennia</h3>
|
||||
<img style="float: right" height="165" src="images/image01.png" width="150"/>
|
||||
<p>
|
||||
It’s a common dream among mudders: a game of your own, just the way you want it, lacking the quirks and annoyances of your favourite game, that has those extra features you cannot get existing admins to implement for you.
|
||||
</p>
|
||||
<p>
|
||||
I got into MUDs very late for my age. Being a long-time tabletop roleplayer, I was looking for online alternatives and found the mainstream graphical RPGs severely lacking. I didn’t actually test a MUD until a few years back, but I soon found this was the best roleplaying experience to be had online. It also did not take long for the developer in me to find things I wanted to improve on. The alluring thought of my own game snuck up on me.
|
||||
</p>
|
||||
<p>
|
||||
Having used C, C++, Java, and Fortran at work, I had no interest in also using them in my free time. I had become very fond of Python and thus started to look into Python MUD codebases.
|
||||
</p>
|
||||
<p>
|
||||
My first stint was with an abandoned Python-MOO project. I got it up and running, fixed some old bugs and toyed with some of the basic systems I pictured for my game. I got a few nice things going before realizing that I spent most of my time working around limitations in the MOO-language interpreter. Following that thought further — I was working in a <em>scripting language implemented in Python</em>. Something is wrong with that concept. Why not use Python itself?
|
||||
</p>
|
||||
<p>
|
||||
I looked into NakedMud, which is a very nice system using Python for a lot of functionality. But I felt, at least at the time, that I would eventually have to go to C to get the kind of flexibility I wanted. I preferred to be able to stay in Python throughout.
|
||||
</p>
|
||||
<p>
|
||||
That was when I came upon <a class="softwaretitle" href="http://evennia.com/">Evennia</a>. Evennia was a bare-bones Python codebase originally created and developed by Greg Taylor. None of its technical underpinnings meant all that much to me at the time. What intrigued me was that Evennia simply imported and used normal Python modules for all its coding, using neither a custom softcode language for its content nor a compiled language for its core.
|
||||
</p>
|
||||
<p>
|
||||
Evennia turned out to be just what I had been looking for: a base system I could expand on freely using plain Python. Evennia was in alpha, so I helped as best I could with patches and new features. I knew nothing about the frameworks that Evennia is based on, so this was a great learning experience for me. In 2010, Greg Taylor found himself lacking the time to maintain the project and passed the role of project owner to me.
|
||||
</p>
|
||||
<p>
|
||||
Evennia has come a long way towards being a general MUD-design system since then. My dream of my own MUD game remains, but is on hold. For now, I’m happy to see others begin to use the system to create worlds of their own.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="488" src="images/image00.png" width="612"/>
|
||||
</div>
|
||||
<div class="imgcaption" style="max-width: 602px; margin-left: auto; margin-right: auto">
|
||||
Example of Evennia server running, showing the default web site, web client and view from a third-party Telnet client (tintin++)
|
||||
</div>
|
||||
<h3>Evennia technical overview and philosophy</h3>
|
||||
<p>
|
||||
<span class="softwaretitle">Evennia</span> is written in Python; it is open-source, released under the BSD license. It isn’t really a “MUD codebase” in the usual sense — it’s more of a MUD/MU*-creation system and server in one. Since Evennia is leveraging the <a class="softwaretitle" href="http://twistedmatrix.com/">Twisted</a> and <a class="softwaretitle" href="https://www.djangoproject.com/">Django</a> frameworks, one can easily expand one’s game with a dynamic web presence. Evennia is, in fact, its own web server — a default web page and game web client comes with the package.
|
||||
</p>
|
||||
<p>
|
||||
The idea is to handle all the boring database and networking stuff that all games need while offering the building blocks for building the game and world itself with as much freedom as possible. This is the reason there are no character classes, combat systems or really any game-specific systems hardcoded into Evennia. For convenience, the distribution does come with a number of default commands for administrative and basic game functionality, as well as base objects for rooms, exits, player accounts and characters, but all of these are intended to be modified, extended or discarded as desired. The base Evennia install works fine as a minimal talker-type server.
|
||||
</p>
|
||||
<p>
|
||||
Contributors are more than welcome to offer up more specialized systems, which are distributed via an optional “contrib” folder. We have stuff from dice rollers to barter systems, character generators and tutorial worlds in there.
|
||||
</p>
|
||||
<p>
|
||||
Evennia is currently in beta. While we continue to work on it, people have already started to use it, both for new games and to convert old ones. Our IRC channel #evennia on Freenode has a lot of good MUD discussion. The current status and development effort is best summarised in our devblog at <a class="website" href="http://evennia.blogspot.se/">http://evennia.blogspot.se/</a>.
|
||||
</p>
|
||||
<h3>Diving into Evennia: Living on the asynchronous edge</h3>
|
||||
<p>
|
||||
Evennia runs on top of the <span class="softwaretitle">Twisted</span> asynchronous framework. <span class="softwaretitle">Twisted</span> not only offers asynchronous event execution, it also makes it easy to implement and support various connection protocols (e.g. Telnet, SSH, SSL, Comet, WebSockets). We allow for interconnection between Evennia game channels and IRC, IMC2 and RSS feeds. People who want to add their own protocols (such as for their own custom web client) can plug that in, often just by referring to a Twisted tutorial.
|
||||
</p>
|
||||
<p>
|
||||
An important point about Twisted is that it is not <em>concurrent</em> in the way a thread or a subprocess is; program tasks do not execute simultaneously. Rather, Twisted works by “chopping up” code into small snippets that relinquish control of the process whenever they would otherwise block, which allows other tasks to run. The result is tasks that rarely have to wait long to execute; in a MUD platform like Evennia, this means that players generally do not have to wait for each other. There is no magic here, though; the application is single-threaded, and each task has 100% of the process’s resources while it is running. So calling <span class="code">sleep(10)</span>, which is a blocking operation, is a sure way to freeze the entire server for ten seconds. To function properly in an asynchronous framework, code must be written to avoid blocking operations by using asynchronous calls, which allow the current code snippet to stop running and let other snippets execute; once the asynchronous call is complete, execution continues using a callback to a new snippet, this having been provided by the first snippet when it made the asynchronous call. Though this can add complexity, a lot of simplicity is gained back because snippets always have a completely consistent internal state during their execution, meaning that the concurrency issues multi-threaded environments manage by synchronization techniques like locks, semaphores and mutexes simply do not exist in single-threaded asynchronous environments.
|
||||
</p>
|
||||
<p>
|
||||
<span class="softwaretitle">Twisted</span> is used in many professional environments, and a MUD is certainly not the most demanding one. That said, one needs to keep these things in mind to avoid having long-running pieces of code execute too often. Our command execution code is an example where Evennia yields often in order to allow Twisted to do its thing.
|
||||
</p>
|
||||
<p>
|
||||
While we know Twisted scales very well, our combining it with <a class="softwaretitle" href="https://www.djangoproject.com/">Django</a> for ORM (<a href="http://en.wikipedia.org/wiki/Object-relational_mapping">object-relational mapping</a>) and for web integration is worth discussing. Firstly, Django is a very solid, professional web framework that adds considerably to the maintainability and web capabilities of Evennia. Tasks like integrating a website or forum directly with the game, adding a web-based character generation system or supporting a custom web client are what Django excels at (as mentioned, we offer a website and web client out of the box).
|
||||
</p>
|
||||
<p>
|
||||
But <span class="softwaretitle">Django</span> is <em>not</em> asynchronous, which means that its database access is written as a blocking operation. While modern databases are very fast, this could certainly be a bottleneck for Evennia’s performance. In testing, however, we have found this to less of an issue than one would think, especially once we apply aggressive database query caching to limit the number of lookups.
|
||||
</p>
|
||||
<p>
|
||||
There is certainly room for improvement, but Evennia’s scaling capabilities are nevertheless promising. In a stress test I had several hundred simulated players online on my laptop: bots that would register, log in and, at random intervals, chat, build, read help entries, pose and move between rooms. On an older version of the server I’ve had a thousand dummy players connected in this way without the game feeling too sluggish. While this was on a vanilla install, and it’s hard to simulate the behaviour of that many actual players, I dare say few modern hobby MUDs can hope to attract even a hundred simultaneous players, so Evennia’s current performance should stand up well to its intended use.
|
||||
</p>
|
||||
<h3>Diving into Evennia: Typeclasses and Attributes</h3>
|
||||
<p>
|
||||
Evennia supports a number of different SQL databases for its persistent storage. But how does one represent game entities in the database? How do you differentiate a chair from a bear or a room from a laser gun?
|
||||
</p>
|
||||
<p>
|
||||
The naïve solution is to create separate database tables for each type. The bear would have separate fields for health, AI and so on. The chair would have weight and a field for storing who is currently sitting on it, the gun would list its remaining ammo, and so on. Whenever you wanted a new type of object you’d need to create a new table. For very specific, simple games this might work. For complex, open-ended games, it’s hardly a very flexible approach.
|
||||
</p>
|
||||
<p>
|
||||
Instead, Evennia uses generic database tables, leveraging the Django ORM for abstracted Python access, in which a table is represented by a Django model. On top of this we use what we call a typeclass, which is an almost-normal Python class, a child of Evennia’s Typeclass parent. Typeclasses can be inherited, expanded and used pretty much as you would expect. The difference is that each instance of a typeclass is directly tied to a row in the database, and updating named fields on the typeclass automatically updates the database underneath.
|
||||
</p>
|
||||
<p>
|
||||
The interesting thing about this is that, to the game developer, it looks like they are just developing their game by creating new classes. To overload base functionality, you just overload methods on the typeclass. Our goal is that you should never need to touch the core library because everything you need to do can be done through polymorphism. For example, you could add new functionality to how text is returned to the player by overloading the <span class="code">msg()</span> method on the parent typeclass and modifying its behavior to your specifications.
|
||||
</p>
|
||||
<p>
|
||||
However, typeclasses as a mechanism are not sufficient for representing game entities. Consider this case: assuming their only main difference is colour, you generally wouldn’t want to have to create separate classes to represent “red roses” and “white roses”. For this, Evennia uses Attributes, properties that are connected to each typeclassed entity through a foreign key relationship. Using Python’s <span class="code">pickle</span> module for serialization, they allow for storing arbitrary data. So, in our example, the instance of the <span class="code">Rose</span> typeclass would have an Attribute <span class="code">colour</span> with the value “red”.
|
||||
</p>
|
||||
<p>
|
||||
This example typeclass is for an unliftable “Heavy” object (possibly used as a parent for other objects):
|
||||
</p>
|
||||
<pre class="python-code">
|
||||
from ev import Object
|
||||
|
||||
class Heavy(Object):
|
||||
"Heavy object that cannot be picked up"
|
||||
def at_object_creation(self):
|
||||
"Called whenever a new object is created"
|
||||
# lock so only Builders (and above) can pick it up
|
||||
self.locks.add("get:perm(Builders)")
|
||||
# attribute the "get" command looks for
|
||||
self.db.get_err_msg = \
|
||||
"This is too heavy for you to pick up."
|
||||
# You’d probably change desc on a per-instance basis
|
||||
self.db.desc = "An immovable and heavy object"</pre>
|
||||
<p>
|
||||
The simplicity of coding offered by typeclasses is paid for by increased complexity under the hood. What is happening is that the Python get/set property methods are overloaded to seamlessly convey data from the typeclass to the database model. This adds some overhead for property access as well as forcing core developers to tread more carefully to avoid accidental lookup loops between the involved model and its typeclass. Careful caching is again useful from an implementation perspective.
|
||||
</p>
|
||||
<h3>Diving into Evennia: The Hierarchy of the User</h3>
|
||||
<p>
|
||||
Many MUDs have a very simple relation between the user (the person playing the game) and the player character (the in-game avatar): they log in and immediately connect to their avatar. If they want to create a new character, they have to register anew. “Character creation” consists of gradually setting properties on the avatar object to customize it.
|
||||
</p>
|
||||
<p>
|
||||
More sophisticated systems allow for an account mechanic. In its simplest form, this means that multiple game logins are tied together by a global account name. This helps with tracking multi-playing users as well as with distributing account-level perks and bonuses (such as giving a bonus to your next character if your last one died heroically).
|
||||
</p>
|
||||
<p>
|
||||
Evennia uses this hierarchy:
|
||||
</p>
|
||||
<p style="text-align: center">
|
||||
User ⇔ <span class="code">Sessions(s)</span> ⇔ <span class="code">Player</span> ⇔ <span class="code">Object(s)</span>
|
||||
</p>
|
||||
<p>
|
||||
Here, “user” is the actual individual playing the game. <span class="code">Session(s)</span> represents the actual connection(s) to the game. <span class="code">Player</span> is our equivalent to an “account”, an OOC object that has no existence in the game world. Finally, the <span class="code">Player</span> is puppeting an <span class="code">Object</span>. This is the in-game avatar; <span class="code">Object</span> is usually of typeclass <span class="code">Character</span>.
|
||||
</p>
|
||||
<p>
|
||||
Output text sent to the <span class="code">Object/Character</span> is piped upward to the relevant <span class="code">Session</span>. In the other direction, command instructions flow down through the hierarchy to reach the current bottommost level (<span class="code">Session</span> if user is not currently logged in, otherwise <span class="code">Player</span> or <span class="code">Object/Character</span>). This makes it very easy to implement puppeting and multiple-character systems: just disconnect the <span class="code">Player</span> from its current <span class="code">Object/Character</span> and connect it to something else, permissions allowing.
|
||||
</p>
|
||||
<p>
|
||||
This separation of <span class="code">Player</span> from <span class="code">Object/Character</span> means that you can design your character creation to happen while in “player mode” — for example, by using a menu. The use of generic objects for avatars also means you could just as well puppet a vase on a table as a person.
|
||||
</p>
|
||||
<p>
|
||||
An interesting feature (originally requested by MUCK players) that this separation enables is connecting multiple <span class="code">Sessions</span> to the same <span class="code">Player</span>, with each <span class="code">Session</span> tracking which <span class="code">Object/Character</span> is puppeted. Through this Evennia allows true multiplaying, where a single account (<span class="code">Player</span>) can control any number of <span class="code">Objects/Characters</span> at the same time from multiple open clients. You can turn this feature off in settings, but it offers a lot of flexibility for creating different game experiences.
|
||||
</p>
|
||||
<h3>Diving into Evennia: Commands</h3>
|
||||
<p>
|
||||
A command in Evennia is defined as everything entered by the user through whatever client and protocol they are using to connect. But how is that represented in code?
|
||||
</p>
|
||||
<p>
|
||||
Evennia, being a MUD-design system, has some rather stringent requirements for a command implementation. It needs commands to be flexible and easily extensible but also able to represent a wide range of situations. A hard-coded command set is not an option.
|
||||
</p>
|
||||
<p>
|
||||
In MUDs, a common way to implement a command is by functions, as a function maps naturally to a command: it has a name and it takes arguments. Evennia, instead, uses classes. This design choice was made for a number of reasons: classes can be inherited and are thus easy to modify and extend while avoiding a lot of boilerplate. An instance of a class can also hold properties of its own. A very simplified sketch of the command invocation process looks like:
|
||||
</p>
|
||||
<ol>
|
||||
<li>
|
||||
Once a command has been identified by Evennia (by getting the beginning of the raw user input), its relevant class is brought up and, if necessary, instanced (existing instances are reused on a per-object level). The instance is then loaded with useful properties — such as who called it, on which object the command is defined, the original raw input string, and so on.
|
||||
</li>
|
||||
<li>
|
||||
The <span class="code">parse()</span> method of the command is called. This deals with detailed parsing of the input, splitting eventual arguments into lists, and so on. Results are stored directly on the command object itself. This step is almost always the same, so you usually only implement <span class="code">parse()</span> once, then let other commands inherit it.
|
||||
</li>
|
||||
<li>
|
||||
Next the <span class="code">func()</span> method is called. This is always overloaded by each command class, and implements the actual work of the command. It has available all the properties saved and prepared by <span class="code">parse()</span> before it.
|
||||
</li>
|
||||
</ol>
|
||||
<p>
|
||||
A simple Evennia command implementation:
|
||||
</p>
|
||||
<pre class="python-code">
|
||||
from ev import Command
|
||||
class CmdEcho(Command):
|
||||
"""
|
||||
Simple command example
|
||||
Usage:
|
||||
echo <text>
|
||||
This command simply echoes text back to the caller.
|
||||
"""
|
||||
key = "echo"
|
||||
locks = "cmd:all()"
|
||||
|
||||
def func(self):
|
||||
"This actually does things"
|
||||
if not self.args:
|
||||
self.caller.msg("You didn't enter anything!")
|
||||
else:
|
||||
self.caller.msg("You gave the string: '%s'." % self.args)</pre>
|
||||
<p>
|
||||
The initial doc string is used to dynamically create and update the command’s help entry. This example does not even worry about implementing <span class="code">parse()</span>, simply using the data already available to it to perform its (in this case minimal) work.
|
||||
</p>
|
||||
<p>
|
||||
Another feature of this system is that none of the methods require any arguments or return values, as all data is available on the command object. This may seem like a small style issue, but when writing a lot of command classes, this lack of boilerplate makes for very clean code.
|
||||
</p>
|
||||
<h3>Diving into Evennia: Command Sets</h3>
|
||||
<p>
|
||||
So we have individual commands. How do we now group and access them?
|
||||
</p>
|
||||
<p>
|
||||
A common method, used by older versions of Evennia, is to use a global command list: whenever a user enters a command, the system looks to the global list and gets the matching command object. All users have access to this list, as determined by their permissions. Most codebases use this method, and it clearly works very well for many games. The problem comes when wanting to deal with <em>states</em>. Consider the following examples:
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
An in-game menu. Selecting a menu item means an instruction from the player — that is, a command. A menu could have numbered options, but it might also have named options that vary from menu node to menu node.
|
||||
</li>
|
||||
<li>
|
||||
You are walking down a dark hallway, torch in hand. Suddenly your light goes out and you are thrown into darkness. You cannot see anything now, not even to look in your own backpack! Next, you knock your head and become dizzy. Suddenly your "navigation" skill is gone and your movement commands may randomly be turned around. Dizziness combined with darkness means your inventory command now returns a strange, confused mess. Next, you get into a fight, and discover that dizzy fight commands in the dark are very different from those available during the day.
|
||||
</li>
|
||||
<li>
|
||||
In a hypothetical <span class="gametitle">FishingMUD</span>, you have lots of detailed skills for fishing. However, different types of fishing rods make different types of throws (that is, commands) available. Also, they all work differently if you are on a shore rather than on a boat.
|
||||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
These are all examples of <em>state-dependent</em> commands. In principle, you could implement the features above with a slew of nested <span class="code">if</span> statements in all your commands, but the complexity climbs quickly, and the chance to make errors or miss edge cases climbs even faster. Let’s see what could be done instead.
|
||||
</p>
|
||||
<p>
|
||||
You could picture handling the menu problem by dynamically adding new commands to the available ones. But now the global list becomes an issue. Why would other users suddenly have access to your menu commands?
|
||||
</p>
|
||||
<p>
|
||||
You could resolve this by tracking who has which list of commands available to them at any moment. One user would have the extended menu-command list and another would not. This can be thought of as being in a character-specific state. But what then happens when you start combining multiple states, such as being dark and dizzy and in a fight? From there, how do you conveniently get back to a previous interim state, such as light returning while still being dizzy and fighting?
|
||||
</p>
|
||||
<p>
|
||||
A few iterations of such thinking leads to what Evennia now uses: a non-global command set system. A command set (<span class="code">cmdset</span>) is stored on individual objects. It groups any number of commands inside it and behaves similarly to a mathematical set. Command sets can be merged using various set operations (like union, intersection, and so on) to produce new, temporary sets. The merged set is what is available to the <span class="code">Object</span> (and thus most often to the user) at any moment.
|
||||
</p>
|
||||
<p>
|
||||
The important thing about <span class="code">cmdsets</span> is that they are merged non-destructively, which means that even though we merged the “dark <span class="code">cmdset</span>” with the “dizzy <span class="code">cmdset</span>” and the “fighting <span class="code">cmdset</span>”, we can remove either of them and produce a new subset to describe the new state. A menu becomes trivial to implement in complete isolation: you create your “menu <span class="code">cmdset</span>” and just have it temporarily replace your normal set. Then, while you are in the menu, you’ll only have the valid options available. The available <span class="code">cmdset</span> can even update as you progress through the menu to give you new menu choices. The fishing poles become items with different <span class="code">cmdsets</span> for the user to access, all of which may be modified by the situation.
|
||||
</p>
|
||||
<p>
|
||||
We have found that the combination of commands-as-classes and <span class="code">cmdsets</span> allow for great flexibility in command schemes and for implementing interesting game states. No custom code handling or checking for special cases is needed. Plugging in something like a barter system becomes a matter of supplying a <span class="code">cmdset</span> to merge into the default one — the new commands are immediately integrated into the game.
|
||||
</p>
|
||||
<h3>Ending thoughts</h3>
|
||||
<p>
|
||||
An article like this can necessarily only touch briefly on the various systems going into a game server. Do check into our documentation, IRC chat or mailing list if you are curious.
|
||||
</p>
|
||||
<p>
|
||||
Some of our users use <span class="softwaretitle">Evennia</span> as a motivation to learn Python. I don’t know how efficient that is, but I do know I’ve learned a truckload of Python since starting to work in earnest on the server, and my <span class="softwaretitle">Django</span> experience made me qualified for a project at work. One of our users even got a job based on <span class="softwaretitle">Django</span> skills they picked up when working with Evennia!
|
||||
</p>
|
||||
<p>
|
||||
This is a hobby for almost all of us, and as such one of the most fun things is the interaction with our little open-source community. Time will tell where things lead from here.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Griatch is the current lead developer of <a class="softwaretitle" href="http://evennia.com/">Evennia</a>.
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.9 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.4 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,161 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
Getting a roleplaying scene going
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Griatch, 12th September 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<aside>
|
||||
<h4>Glossary of Terms</h4>
|
||||
<dl>
|
||||
<dt>Character concept</dt>
|
||||
<dd>
|
||||
The general idea behind your player character (PC), like “the scarred veteran”, “the grumpy old magician” or “the swashbuckling bounty-hunter”.
|
||||
</dd>
|
||||
<dt>IC/OOC</dt>
|
||||
<dd>
|
||||
In Character/Out Of Character.
|
||||
</dd>
|
||||
<dt>Emote/pose</dd>
|
||||
<dd>
|
||||
This is a common way to roleplay in MUDs. An emote or pose command displays a free-form action to everyone in the room, such as “The tall man sighs heavily”. Some MUDs offer a variety of special commands for particular actions or special syntax to decorate poses. Some games use specific “say” commands for verbal communication, while others make speech part of emoting/posing.
|
||||
</dd>
|
||||
<dt>Action/static pose</dt>
|
||||
<dd>
|
||||
A pose that “lingers”, such as “The tall man is sitting by the bar”. Commonly, static poses remain assigned to your character’s description until you change it or exit the room, meaning that new people entering will immediately see your current status.
|
||||
</dd>
|
||||
<dt>NPC</dt>
|
||||
<dd>
|
||||
Non-Player Character. Also known as a “mob”. An in-game character that is controlled by the computer, such as a bartender or a city guard.
|
||||
</dd>
|
||||
<dt>vNPC</dt>
|
||||
<dd>
|
||||
A “virtual” NPC. This NPC does not actually exist in code, but their existence is implied by the setting. Even though there are only fully modeled objects representing two player characters and a city guard in the central plaza, narratively we understand that that place is packed with people most of the day. Most RP MUDs ask players to imagine vNPCs being all around them and have it influence their roleplay.
|
||||
</dd>
|
||||
<dt>Godmoding</dt>
|
||||
<dd>
|
||||
The act of including another player’s character in your roleplay in a way that takes control away from them unfairly — interacting with other player characters in “god mode”. (Also commonly written as “godmodding”.) This is considered very bad form. Depending on the game, disagreements on how to resolve a situation may be down to skill checks, die rolls or calling in a staff arbiter.
|
||||
</dd>
|
||||
</dl>
|
||||
</aside>
|
||||
<p class="disclaimer">
|
||||
Disclaimer: This article is intended for players interested in roleplaying and who consider “getting good RP” a worthy goal. If this isn’t you, it really is fine to go beat up some orcs instead of reading this article. Also, I primarily have experience with roleplay-oriented MUDs; in other forms of roleplay-focused MU*, the way roleplay is arranged and the tropes at work are likely different.
|
||||
</p>
|
||||
<p>
|
||||
In roleplay-oriented MUDs, the concept of <em>scenes</em> becomes important. A scene is simply a situation, big or small, that involves you and your fellow players in interesting roleplay. A scene can be as simple as two players meeting in the street and exchanging a few words or as high-stakes as the dramatic conclusion to a staff-driven quest. Whenever roleplay-interested players meet, a scene may happen.
|
||||
</p>
|
||||
<p>
|
||||
However, sometimes scenes won’t come naturally. Sometimes your favourite game has only a few people online, or most players are hovering in private areas. Then it’s time to take the initiative. Below I offer some archetypes, tropes and ideas for how to get a scene started and people interested. The list is based on one I wrote for an RP MUD I play.
|
||||
</p>
|
||||
<h3>Scene starters</h3>
|
||||
<p>
|
||||
Scene starters are for when you are alone in a room hoping for others to join you — we've all done it. It is considerably easier to run scene starters if there is some OOC way for other players to know where to find you, such as a list showing the location of those setting an “I’m available for RP” flag. If not, it’s best to prepare your starter in a commonly visited central location or hub. You normally trigger the starter whenever a player character enters.
|
||||
</p>
|
||||
<p>
|
||||
The Scene starters below are intended as ideas and suggestions, but are also examples of archetypal behaviour I’ve observed myself.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image02.jpg" width="200"/>
|
||||
<h5>The Barfly</h5>
|
||||
<p>
|
||||
A roleplaying MUD classic since time immemorial. <em>The barfly</em> is alone in a tavern and tends a drink, waiting for things to happen. A passive role, but trivial to set up and easy for other players to jump in on — they just slide up to the bar and ask what's up. Fun variations include the <em>drunk barfly</em> and the <em>really, really sad/happy barfly</em>, states which immediately give other players things to ask about and work with.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image10.jpg" width="200"/>
|
||||
<h5>The Strider</h5>
|
||||
<p>
|
||||
This is the "dark stranger in the corner" variation of <em>the barfly</em>. It is simple to execute — just sit in a dark tavern corner looking glum and mysterious. Often used by newbie players unsure of the game’s commands. The problem is that unless they know <em>the strider</em> from before, it's hard for other characters to include him/her in their roleplay in a realistic way. The whole IC point of this trope is, after all, to avoid attention.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image13.jpg" width="200"/>
|
||||
<h5>The Busybody</h5>
|
||||
<p>
|
||||
<em>The busybody</em> is keeping busy in this room. Most commonly they are performing their job. If they own a bar or run the shop, they tend it. If they are guardsmen, they are standing on patrol. If they are jesters, they are making fools of themselves. You see the pattern. This is a great starter since it is natural, realistic and in-character all at once. The nature of <em>the busybody’s</em> work may occasionally make it easier or harder for other characters come up with reasons to interact with them, though — it might be harder to invent motivations for some characters to strike up a conversation with a guardsman than for interacting with a street vendor.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image08.jpg" width="200"/>
|
||||
<h5>The Demagogue</h5>
|
||||
<p>
|
||||
This more-involved starter involves striking up a loud conversation with an NPC or vNPC. Whenever another player character enters, <em>the demagogue</em> begins a small scene where they are "arguing" with the NPC, playing both roles. The argument could be "continuing" or just starting as the new PC enters. It could be about anything from tavern prices to refuting a made-up insult. The advantage of this is that it provides immediate characterization for <em>the demagogue</em> and the NPC both. It also makes it easy for the newcomer to get into the scene just by taking a side in the debate.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image17.jpg" width="200"/>
|
||||
<h5>The Mayday</h5>
|
||||
<p>
|
||||
This starter sets up a character as needing help from whoever enters the room next. <em>The mayday</em> involves describing the initiating character in a sort of precarious situation that clearly requires an extra hand to resolve. This could be anything: having their hands full and nearly dropping stuff, chasing a dog that is running off with their book, being accosted by vNPC ruffians (who should vacate the area quickly, unless roleplaying completely “virtual” combat is your cup of tea). Either way, the newcomer has an ongoing scene to react to, and roleplay immediately ensues.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image12.jpg" width="200"/>
|
||||
<h5>The Organizer</h5>
|
||||
<p>
|
||||
This starter requires that the MUD have a developed in-game message or mailing system. If so, use it to explicitly and in character invite people to a scene! If <em>the organizer</em> is in a position of in-game power, this could make good IC sense — as with the lord calling on their vassals to attend a function. Anything from calling in a favor to suggesting a business opportunity or looking for a job works, though. Throw a party. Get drunk and send an ill-advised love letter. This starter works exceptionally well in combination with <em>the stage director</em> or <em>the aggravator</em> for getting selected player characters into a memorable scene.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image16.jpg" width="200"/>
|
||||
<h5>The Aggravator</h5>
|
||||
<p>
|
||||
<em>The aggravator</em> starts off on the wrong foot with people. Maybe they lash out due to some perceived injustice or they are just grumpy. This starter does not fit all character concepts. <em>The aggravator</em> should accuse the newly arrived PC of something. It could be something from their common history or something made up out of the blue. It is an active starter in that it leads the way and forces other PCs into roleplay — in self-defense if nothing else. A simple example is to chide the newly arrived PC for not stopping the vNPC that just ran past them out the door. It's important not to take <em>the aggravator</em> trope too far, especially not when using vNPCs. The idea is to get a scene started with some tension, not to get the other (possibly random) PC into real trouble. No godmoding, remember. If the two characters are <em>actual</em> enemies though, it may be another matter...
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image01.jpg" width="200"/>
|
||||
<h5>The Stage Director</h5>
|
||||
<p>
|
||||
This is a more sophisticated starter that’s halfway to improvised theater. It sets up a whole little scene involving some event with a number of semi-named vNPCs. <em>The stage director</em> could be directly involved or be a spectator (in which case other PCs can walk up to them and ask what's going on). The event could be anything from a bar brawl to a domestic dispute in progress to a marriage proposal between two vNPCs in the middle of the street! If the <em>stage director</em> is threatened in some way, this is a large-scale version of <em>the mayday</em>.
|
||||
</p>
|
||||
<p>
|
||||
The nice thing about staged scenes like this is that it gives depth and personality to the game and is often highly appreciated by other players. If done well, <em>the stage director</em> can give everyone involved a true feeling of being in a living environment.
|
||||
</p>
|
||||
<p>
|
||||
The scene could continue to be played out around the PCs as they interact, making this starter potentially demanding for the <em>stage director</em>. If the other players are experienced, they should pick up on this and even contribute their own vNPCs to the scenario (or the <em>stage director</em> could actively invite other players to do so). It's important to remember to avoid godmoding here — never dictate another PC’s actions. Let other players react as they see fit.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image06.jpg" width="200"/>
|
||||
<h5>The Lazy Bum</h5>
|
||||
<p>
|
||||
This is, unfortunately, the most common of starters and we've probably all done it one time or another. It does not involve anything but simply standing in a room. No action set, no nothing. Just being there, the player character staring blankly into space until something happens. Yeah.
|
||||
</p>
|
||||
<h3 class="clear">Scene entrances</h3>
|
||||
<p>
|
||||
Here are some ideas on how to enter a scene/room with one or more other PCs already involved in roleplay. It should be noted that if other players already have a scene going they might be OOC annoyed if the newcomer muscles in with some scene-changing entrance. So you, as a player, are wise to show consideration here. Check the situation and eventual actions set on people in the room. If a great scene is already in progress you shouldn’t need to start your own — instead, try to get in on the action!
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image09.jpg" width="200"/>
|
||||
<h5>The Mouse</h5>
|
||||
<p>
|
||||
The most common of entering schemes, <em>the mouse</em> walks into the area not drawing attention to themselves. This is a simple, passive setup that fits many situations and character concepts. <em>The mouse</em> is a useful way to enter an already-running scene. It is a bit overused, though, possibly being <em>the lazy bum</em> of entrances. It seem to imply that it is up to others to notice and respond to <em>the mouse</em>. If truly aiming for anonymity, <em>the mouse</em> should emote explicitly that they are not drawing attention to themselves, making it clear to other characters that they need not go out of their way to be courteous and notice the newcomer.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image04.jpg" width="200"/>
|
||||
<h5>The Ignoranti</h5>
|
||||
<p>
|
||||
<em>The ignoranti</em> acts as if they do not notice the other characters in the room. This entrance variant is useful for crowded or large locations. It is also realistic; just because the “chock-full” tavern has only two PCs in it, it doesn’t mean you would actually immediately notice them — vNPCs are everywhere. <em>The ignoranti</em> must emote their ignorance explicitly, with something like <em>"The newcomer does not notice the others yet"</em>. This entrance makes for a nice variation by allowing <em>the ignoranti</em> and other PCs to "accidentally" bump into each other later in a natural way.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image00.jpg" width="200"/>
|
||||
<h5>The Walker</h5>
|
||||
<p>
|
||||
<em>The walker</em> is just "passing through" this area. This entrance is useful for outdoor areas or minor streets were many character concepts probably have no real reason to be hanging about more than necessary. <em>The walker</em> is really heading somewhere else and just happens to stop to chat with people in this room. It's an effective entrance that allows for quick, logical exits as well: they just have to “be on their way”. This is far better than the common approach of standing in a street room greeting people as if all you do is loiter in the street all day.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image14.jpg" width="200"/>
|
||||
<h5>The Planned Visitor</h5>
|
||||
<p>
|
||||
This is a variation on <em>the busybody</em> and the opposite of <em>the walker</em>. <em>The planned visitor</em> needs to come to this room, and not in order to chat with random PCs. The <em>visitor</em> will start to perform whatever they are here to do — interaction with others is a mere side effect. The classic takes on this trope are to read message boards or to order food and drink. More imaginative ones could be to ask the NPC barkeep for a job, look for a vNPC (who turns out to not be there), repair something, do some sort of inspection, or set up for an artistic performance. If done well, others will have plenty of opportunity to ask the <em>planned visitor</em> what they are up to. It also provides an in-character way to exit the scene once you declare your business there done.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image15.jpg" width="200"/>
|
||||
<h5>The Wet Kitten</h5>
|
||||
<p>
|
||||
A classic that involves entering a scene drenched to the bone, shivering from cold, gasping from heat or otherwise being dramatically and visibly affected by whatever weather or situation reigns outside. <em>The wet kitten</em> is common to taverns everywhere. For some reason this entrance rarely instills as much sympathy as one would think, but at the least it opens up opportunities for other characters to comment on the weather. Taken to an extreme, this becomes a variation on <em>the mayday</em>.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image05.jpg" width="200"/>
|
||||
<h5>The Third Wheel</h5>
|
||||
<p>
|
||||
This is an active, provocative entrance and a variant on <em>the aggravator</em>. It should directly interrupt and involve other PCs in the room entered. The trivial, confrontational way to do this is for the intruder to muscle or elbow past other PCs in a rude way, maybe even attempting to give them a rough shove (remember to avoid godmoding). This is sure to start off a scene! The more common approach is to walk up to a group of conversing PCs and simply jump into their conversation mid-sentence. How this is received depends on the situation and characters involved. In both cases it's important to make it clear that your actions are a conscious RP choice — it’s your character who is inconsiderate, not the player behind it. In other words, emote something like <em>“The newcomer does not seem to notice or care about intruding on the conversation...”</em>
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image11.jpg" width="200"/>
|
||||
<h5>The Dramatist</h5>
|
||||
<p>
|
||||
This is an on-the-fly version of <em>the stage director</em> or <em>the demagogue</em>. Only use <em>the dramatist</em> if it's clear the currently ongoing scene allows for it — it’s often a good idea to follow a few emotes in the room before setting this one off. Just like <em>the stage director</em>, it starts some sort of background action in the room, based on vNPCs. For example, this might be a brawl, an argument, or a happy announcement. Maybe a vNPC starts hitting on a PC, or, like <em>the demagogue</em>, <em>the dramatist</em> might get involved in a discussion with an NPC/vNPC. Bartender NPCs are classic useful targets for this. <em>The dramatist</em> must be perceptive and considerate so as to avoid taking over an already-running scene. Some PCs might forcibly choose to ignore the events going on in order to focus on their ongoing RP, so don't shove it down their throats (no godmoding!).
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image03.jpg" width="200"/>
|
||||
<h5>The Non-sequitur</h5>
|
||||
<p>
|
||||
This strangely rare entrance involves running into a crowded room, shouting "Monkeeey!" and then running out again. This one will, at the least, lead to roleplay for the confused people in the room you just visited. Don't do this unless you have a very specific and suitable character concept, kids.
|
||||
</p>
|
||||
<img style="margin-left: 15px" xheight="200" src="images/image07.jpg" width="200"/>
|
||||
<h5>The Newbie</h5>
|
||||
<p>
|
||||
The classic <em>newbie</em> entrance involves walking into a room and saying "Hello" to no one in particular. Bonus points if this is done while ignoring the fact that the room's on fire and the PCs within are all involved in mortal combat. Luckily, this entrance trope screams <em>newbie</em> so clearly that players may be urged to pity and lenience. It may, in fact, be the trigger for getting a more experienced player to take <em>the newbie</em> in hand and explain a thing or two.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Griatch is the current lead developer of <a class="gametitle" href="http://evennia.com/">Evennia</a>.
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,49 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
Help save old mudding resources
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Richard Tew, 9th November 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p>
|
||||
A recent widely reported study (Zittrain 2013) discovered that half the links in all United States Supreme Court decisions are broken. Whatever they point to is no longer there. Mudding resources aren’t that much better off.
|
||||
</p>
|
||||
<p>
|
||||
Maybe you can help us undo the damage?
|
||||
</p>
|
||||
<h3><a href="http://www.disinterest.org/resource/MUD-Dev/">The MUD-Dev mailing list</a></h3>
|
||||
<p>
|
||||
This archive is mostly complete. Thanks to the help of others who provided partial collections of posts, I painfully pieced it together. But it is a mess. There are dead links and duplicate posts. The times and dates of the posts are incorrect, which means you often start reading the tail end of a discussion before you reach the post which started it. Do you have all the original emails stored away? Are you willing to put in the work to build a better version of this archive? What about the mailing list that preceded this one, whose posts were intended to be made available at some point?
|
||||
</p>
|
||||
<h3>The MUD-DEV conference</h3>
|
||||
<p>
|
||||
Back when the MUD-Dev mailing list was most active, mini conferences would be held while the Game Developer Conference (GDC) was also being held. There was talk of CD-roms being made of the presentations, and perhaps even video. Do you have any of these presentations, or even a one of these CD-roms?
|
||||
</p>
|
||||
<h3>The USENET newsgroup archives</h3>
|
||||
<p>
|
||||
There were several newsgroups focusing on various parts of the mudding community; amongst them were <a href="https://groups.google.com/forum/#!forum/rec.games.mud.lp">rec.games.mud.lp</a> and <a href="https://groups.google.com/forum/#!forum/rec.games.mud.admin">rec.games.mud.admin</a>. Years and years of discussion on a myriad of interesting topics happened within them. What were these topics? Good luck finding out. Google has the archives, and has slowly over the years been upgrading the interface which you can use to access them. Once you could start at the beginning, or at any point in their history, and skim your way through them. Maybe you’d find a gem. But these days, you can mostly just search the archives. How do you know what to search for? How can you know? You can’t really. Do you know someone at Google that can get us a more useful form of access, or even copies to work through offline?
|
||||
</p>
|
||||
<h3>The MUD Magic discussion forum</h3>
|
||||
<p>
|
||||
I never really participated in these, but they were taken offline for some reason or other. Years and years of interesting discussion, also lost. The original administrator no longer has backups. Do you have some form of archives for this resource?
|
||||
</p>
|
||||
<h3>The <span class="publicationtitle">Imaginary Realities</span> discussion forum</h3>
|
||||
<p>
|
||||
As David Bennett published each issue, he also linked each article to a discussion thread. There people would get together and talk about ideas and thoughts related to each published article. This resource is also lost, unfortunately. Or is it? We were lucky enough that Fred Clift had mirrored <span class="publicationtitle">Imaginary Realities</span> itself, perhaps there is someone else out there that mirrored these forums?
|
||||
</p>
|
||||
<h3>Mirrored MUD content which is not longer available</h3>
|
||||
<p>
|
||||
Do you have any MUD content you downloaded, which is no longer available? As Fred mirrored <span class="publicationtitle">Imaginary Realities</span>, perhaps you mirrored something else of interest?
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Richard Tew (<a href="mailto:richard.m.tew@gmail.com">richard.m.tew@gmail.com</a>)
|
||||
{% endblock %}
|
||||
{% block article_references_content %}
|
||||
{{ super() }}
|
||||
<p class="citation">
|
||||
Zittrain, Jonathan. 2013. “Scoping and addressing the problem of 'link rot'.”
|
||||
<a href="http://blogs.law.harvard.edu/futureoftheinternet/2013/09/22/perma/">http://blogs.law.harvard.edu/futureoftheinternet/2013/09/22/perma/</a>
|
||||
</p>
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,183 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
The Hunger Game, or how I learned to break the ship from the bottle
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Michael “Drakkos” Heron, 19th August 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p>
|
||||
Before you start developing a MUD, you need to realize one key thing — it's going to take a long time to make it something people want to play. You can technically tick the “have my own MUD” box in a matter of minutes if you like, but to operate a MUD that’s worth people’s time, you need original content, original game systems, and interesting areas that properly reflect the game theme you’ve chosen. You need enough of each of these to hold someone's interest long enough for them to want to come back.
|
||||
</p>
|
||||
<p>
|
||||
You also need to expect that all the work that goes into making this game will fall on <em>your</em> shoulders. You can post around asking for builders and coders, but unless you make a spectacularly good pitch, you're unlikely to have much joy; it's very much a seller's market. There are dozens of projects started every month, and someone who knows how to make things happen is never going to lack for offers. If all you are bringing to the table is “management” or “a server” or “an idea” — well, I wish you the best of luck, but that’s a very tough sell.
|
||||
</p>
|
||||
<p>
|
||||
Finally, you need to work to the expectation that even if you do beat the odds and end up with a MUD that opens properly, you're going to be one of the 95% of MUDs that get no significant player numbers. It's not that your MUD is one of the “bad ones”, it's that we work in a niche field: text based multiplayer gaming via what are, in many ways, obsolete protocols. We're a brand that has almost no market recognition. There's a very small pool of people looking for a MUD, and there are already twenty or so well-established MUDs that can each boast extensive content and a vibrant social community with at least a hundred players online at all times.
|
||||
</p>
|
||||
<p>
|
||||
What I'm saying is: choosing to start a MUD is choosing to participate in all-but-inevitable failure. Yet, back in 2009, that's exactly what I chose to do.
|
||||
</p>
|
||||
<p>
|
||||
It's not that I didn't know better. I'd been mudding since my first year of university, back in 1996. I'd been a developer on <span class="gametitle">Discworld MUD</span> since 1999. From 2005 to 2008 I was working on my own game engine — a Java MMO builder called <span class="softwaretitle">Swordsmith</span>. I remember the high points of the ‘90s when player counts only ever trended up, and I remember the slump that followed the first graphical MMOs, when player numbers only ever trended downward. I've never been much for integrating into the greater MUD community, but I read all the boards, I knew all the conventional wisdom. I knew the finality and pessimism that was the day-to-day atmosphere of our hobby.
|
||||
</p>
|
||||
<p>
|
||||
I had every reason not to do it, in other words.
|
||||
</p>
|
||||
<p>
|
||||
It's not even that I was stuck because I had no other options — I'm a pretty good coder, and I know dozens of languages. I had all kinds of ways to scratch a creative itch, and none of them had to be a MUD, but that's what I wanted to do. It's what I love doing, and even in my academic career as a researcher into accessibility and games, I've looked for opportunities to discuss text games where I can — see my previous works, <a href="http://www.scribd.com/doc/134002484/M-Heron-Likely-to-be-eaten-by-a-Grue-the-relevance-of-text-games-in-the-modern-era">“‘Likely to be eaten by a Grue’ — the relevance of text games in the modern era”</a> and <a href="http://tinyurl.com/mk6v3k2">“Authorship and Auteurship in the Collaborative Development Process of Text-Based Games”</a>, the latter with John Townsend.
|
||||
</p>
|
||||
<p>
|
||||
I believe there is an audience out there for MUDs — we don't have to work under the assumption that what we're doing is building our own little ship in a bottle. I started with the intention to make a great MUD that people played. In this article, I want to talk about how that worked and give a “lessons learned” summary on taking a MUD from bare bones to fully-released game.
|
||||
</p>
|
||||
<h3>Oh, the infrastructure you'll need</h3>
|
||||
<p>
|
||||
Let's assume you've read all the above and decided, “Screw it, I want a MUD, so I'm going to make a MUD, and if you don't like it you can ride the suck-it train all the way to its terminus.” That's good — you have to <em>want</em> to do this, and if you don't have a burning in you to make it happen, you're not going to get anywhere. It's a long, long slog to get to the end and it's going to take years of your life. If you can be put off by my saying your failure is inevitable, then, well, your failure <em>was</em> inevitable. The next step is deciding where you start. Generally, you need two things, although strictly speaking both are optional.
|
||||
</p>
|
||||
<p>
|
||||
The first is someplace dedicated to run your game. <a class="gametitle" href="http://epitaphonline.co.uk/">Epitaph</a>, my MUD, used <a class="website" href="https://www.linode.com/">Linode</a> early on, and has since moved to <a class="website" href="https://www.bhost.net/home?afid=119631">Bhost</a>. We have Bhost’s largest package (two of them, in fact), which is fast, has excellent bandwidth, and is generously provisioned. You can just run your MUD from your own computer, of course, but don't undervalue the benefits of having something external. It makes it easier for people to come try it out, for one thing, and if nothing else it means you can have a chat room for your friends to use while you get on with the business of building the game. Every time someone tries to connect and is denied reduces the likelihood they will try again.
|
||||
</p>
|
||||
<p>
|
||||
Don't underestimate the value of having people there, either, even if only for conversation. It gets lonely on a MUD all by yourself, no matter how much fun you may be having.
|
||||
</p>
|
||||
<p>
|
||||
The second thing you need is a mudlib, or a codebase. That's your starting point. I know some of you are reading this and saying “Oh, it's okay, I'm going to code that from scratch”. You folks — this isn't the article for you. I get that you want to do it, and you'll be having a lot of fun with it (as I did with Swordsmith), but you're not building a game. Seriously — you have years of work ahead of you before you're even ready to <em>start</em> building a game. If you're interested in the technical challenge, that's great — more power to your elbow. If, however, you want to make a <em>game</em>, then that's really not the place to start.
|
||||
</p>
|
||||
<p>
|
||||
What you want to start with is <em>anything</em>. Seriously — do not stress about or overanalyze this. Pick the codebase that you're most familiar with, or the codebase that's most popular for the kind of game you want to make. I'd recommend an LPC codebase, but that's because I'm an LPC guy. Just pick one — the fact that it isn't going to be able to do the things you want it to do is irrelevant. As the years go by, you'll make it do the things you want it to do.
|
||||
</p>
|
||||
<p>
|
||||
We started on <span class="gametitle">Epitaph</span> with a barebones <a class="softwaretitle" href="http://en.wikipedia.org/wiki/Discworld_mudlib">Discworld mudlib</a>. Not the one that's generally available — being an ex-admin there did come with some perks. We were also hosted in the short term by Sojan of <span class="gametitle">Discworld</span>, who generously made server space available. This by itself ensured that “starting a MUD” was instantly something more than “a crazy notion I'll get around to”. My lengthy experience with <span class="gametitle">Discworld</span> and the mudlib itself, which has my dirty fingerprints all over its creaky innards, was the sole reason I picked it. Seriously, just pick anything. Then treat it like a musical instrument that you can retune yourself. You'll make it sing in exactly the ways you want it to.
|
||||
</p>
|
||||
<h3>The initial development</h3>
|
||||
<p>
|
||||
The first question is, “where do I start?” It's tempting to just dive in and start coding up areas and items and NPCs. My advice is: don't do that. It was six months of hard work before we had more than a couple of rooms on <span class="gametitle">Epitaph</span>. That was largely because I knew what I wanted to do to pimp out the mudlib. I knew what I wanted to change, how I wanted to change it, and the kind of game experience I was aiming to provide. You might not know that right away, but that's fine. The first few steps of development should be planning.
|
||||
</p>
|
||||
<p>
|
||||
Put up a wiki. Seriously.
|
||||
</p>
|
||||
<p>
|
||||
It doesn't matter if it's only ever you who will see it, make one available so you can start plotting out your ideas and <em>try</em> to get other people to check it out. A wiki is accessible from anywhere that has an Internet connection, and the freeform syntax means it's really easy to structure even complicated ideas. It's also something you can point interested people towards. It's going to be a year, at least, until you have something genuinely worth showing people in terms of code. Your ideas might be exactly what you need to sell people on your vision. Get as many people as you can discussing your ideas.
|
||||
</p>
|
||||
<p>
|
||||
At all times, be mindful of one key question — where is the <em>fun</em>? Remember, games are supposed to be fun, and they're supposed to be engaging. At this stage, you're going to experience a very common pattern: you'll start off narrowly focused on a game theme, then your focus will rapidly expand and go off on tangents and explore new directions, experimental systems, and so on. Then you'll realize, “oh yes, I have to code all of this,” which is when you'll see what kind of developer you are.
|
||||
</p>
|
||||
<p>
|
||||
Developers who are going to succeed will do some kind of prioritization here — they'll underline the things that they absolutely must have, and the things that they really <em>should</em> have. They'll put the things they <em>could</em> have off to the side, and then completely mothball the stuff that they <em>want</em> but don’t <em>need</em>. Those developers will have a firm estimate of development time in mind (it’ll be wrong, but it’ll be firm) and a good sense of what they can reasonably achieve in that time. They will kill off even their most cherished ideas if they're not feasible, or not critical to the game experience they want to make. They will know what's important architecture and what is mostly “designerbation”. They will, in the old editing wisdom, “kill their darlings”.
|
||||
</p>
|
||||
<p>
|
||||
Developers who are going to fail won't do any of that. Every idea will become a promise they have made to themselves. They'll be unable to let anything go, and in the end will have so much plotted and planned out that they've already failed. Don't overwhelm yourself, and don't let yourself (or others) write cheques your ability can't cash. Ideas are cheap and people generally dispense them like tic-tacs. That's awesome as part of a scope-setting or brainstorming effort, but it's terrible as part of a development agenda.
|
||||
</p>
|
||||
<p>
|
||||
Once you've set your scope, plan your architecture. What game features do you need to make your MUD happen? This is why you shouldn't start with building — spending a few weeks planning out will show you what your game requires, and what you may find out is that it needs you to do rooms, NPCs and items entirely differently from how you would have done them starting out. For example, on <span class="gametitle">Epitaph</span> we went with a design philosophy for handling items that was completely different from what we had inherited as an assumption from <span class="gametitle">Discworld</span>. Rather than everything being hand-coded, we created special replaceable tokens and a set of properties that were inherited from the materials items could be made from. We could have spent a month developing an interesting series of weapons at the start, only to find we needed to rewrite them all once we properly decided on how they were going to work.
|
||||
</p>
|
||||
<p>
|
||||
After all of that, start coding. It doesn't matter where you start — pick a starting point and begin there. Get yourself some form of source control and just go nuts. Don't be afraid to gut your code to make it do what you want. Don't be afraid to experiment. Just make sure that, if the experiment goes wrong, you can roll back to when everything was working.
|
||||
</p>
|
||||
<p>
|
||||
Schedule a good chunk of time for this, but leave off area development until the later stages. You want to ensure that when you do get to the point of building your first few pieces of content, you don't have to waste time converting old code across into your new, shiny architecture.
|
||||
</p>
|
||||
<h3>Closed Alpha</h3>
|
||||
<p>
|
||||
Once you've been developing for a bit, I'd highly recommend bringing some people in. Not too many, and don't be indiscriminate, but the value of early player feedback is huge. It's been my experience that a stripped down system that’s fun will only become more so when it's fleshed out. On the other hand, if a stripped down system <em>isn’t</em> fun, no amount of beefing it up is going to help. Fundamental systems are either fun at the core or they’re not — there may be exceptions to this as a general rule, and if you bend a system that isn't fun <em>enough</em> you might just snap it in place.
|
||||
</p>
|
||||
<p>
|
||||
The earlier you find out if the core of your game is fun, the better. If it's not, you haven't sunk so much time into it that you can't really adjust your course — it’s better to know that early. If it is fun, it's a huge rush to know that people are going to enjoy what you have for them.
|
||||
</p>
|
||||
<p>
|
||||
A closed alpha period can last maybe a couple of weeks, and you should pay very close attention to what people are saying and playing. If there are systems they're not touching, ask yourself why. Sometimes it's a lack of signposting. Sometimes it's a skewed cost to benefit ratio. Sometimes it's that your system just ain't fun. Be ruthless with your code. Bad game systems are like tumors: they need to be cut out. On <span class="gametitle">Epitaph</span> I went through six or so incarnations of a temperature system that gave your outfits game impact. As it turned out, though, no matter how hard I tried, I just could not make it a fun system. So we got rid of it entirely.
|
||||
</p>
|
||||
<p>
|
||||
A whole suite of game mechanics were cut out in <span class="gametitle">Epitaph’s</span> closed alpha, and the game emerged from the process much better for it. We've gone through a number of alpha and beta cycles, open and closed, and each one has been more significant in terms of what was removed than what was added. Don't get me wrong — you'll be drowning in great ideas, and the enthusiasm of your players for certain things will be a barometer for what's neat about what you're doing. You'll find, though, that if they're enjoying what you've got out there, they'll generate more feedback and ideas than you can reasonably work your way through. That means you get to cherry-pick the best feedback and fold it into your later development.
|
||||
</p>
|
||||
<p>
|
||||
However, this kind of thing has the potential to make your scope run away from you. As in the planning phase, don't let people pull you into a spiral of new developments. Incorporate what you can and put a pin in the rest. Close the alpha relatively early, too — it's not a serious testing phase, it's really just a “kicking the tires” phase. While players are hanging around, you won't get much done, so thank them for their efforts, give them some kind of recognition for their support (on <span class="gametitle">Epitaph</span> we do this via badges), then lock the doors and get your head down.
|
||||
</p>
|
||||
<h3>Recruitment</h3>
|
||||
<p>
|
||||
What you'll likely find is that some of your alpha players might be inspired by what you're doing. That recruitment that was so hard at the beginning becomes a lot easier when people can really get a feel for what you're trying to accomplish. When our closed alpha on <span class="gametitle">Epitaph</span> ended, I received a number of offers from players saying they'd like to try their hand at development. My philosophy on this was always permissive.
|
||||
</p>
|
||||
<p>
|
||||
The problem with recruitment is this: people don't really know what it is they're getting into. As part of the alpha, you'll be busy beavering around, adding in new things, fixing problems as they arise, and from the perspective of someone who hasn't coded before, what you do may as well be magic. It's very seductive, the idea that you can step up in a world like this and just shape reality on a whim. Unfortunately, we all know better — learning how to code is, for most people, a long and arduous task that involves developing skills that are in many ways completely alien.
|
||||
</p>
|
||||
<p>
|
||||
Various ways exist to bridge the gap between required and actual ability, but all they do is delay the inevitable realization — being a coder or builder, even for a game you love, is <em>hard work</em>. With many people, as soon as they realize that what they've done is take on a second job that they need to study to be able to do, they fade away. I'd say of the dozens of people I have promoted to creator, both on <span class="gametitle">Epitaph</span> and on <span class="gametitle">Discworld</span>, fewer than ten percent of them have gone on to really become valuable and productive. That's putting no blame on them — the fact is that you need to have a burning desire in you to <em>want</em> to develop a game day in and day out.
|
||||
</p>
|
||||
<p>
|
||||
After your closed alpha, you'll be getting a number of offers of help, if all has gone well, so consider how best to parlay that into actual assistance. Remember <a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month">the mythical man-month</a> — all adding a new developer will do, in the short term, is slow you down. You need to be sure that you don't assume that, <em>finally</em>, you have others who will take some of your work off your back. If you're lucky, you'll get a couple of good recruits who absolutely will, in the fullness of time. Most of your recruits, though, will be a net drain on your time as you invest what effort you can in bringing them up to speed — effort that never pays off as they drift away.
|
||||
</p>
|
||||
<p>
|
||||
Don’t recruit too early. Most MUD coding is non-formal and often done through the use of examples. If you, as a player, see something in a game you like, and you want to do something “kinda like it”, then working from an example is vital. Early on in the process, you won’t have examples — some creators will be able to deal with that. Most won’t, and you’ll save yourself a lot of hassle by simply waiting until you do have a sufficiently large library of game code for people to use as a learning resource.
|
||||
</p>
|
||||
<h3>The Roadmap</h3>
|
||||
<p>
|
||||
Let's assume, though, that you've managed to con a few people into lending their support for free. It's time to really knuckle down and consider the shape of the first version of your game. What you need is a roadmap of some kind. Basically, this is an itemized list of coming versions of the game, what's going to be in them and who's responsible for making them happen. A roadmap can be as simple as a <a href="https://en.wikipedia.org/wiki/MoSCoW_Method">MoSCoW</a> analysis of your big ideas list or as formal as you like. On <span class="gametitle">Epitaph</span> we went somewhere in-between: formal patch numbers, with each patch on the wiki being given a list of our intended feature set. That list grows and shrinks day to day. As we headed into the last couple of months before release, the list swelled hugely as we did some internal playtesting and discovered many, many flaws. From that point on we whittled it down farther and farther until it had one entry: “fix remaining bugs”. I’m proud to say that we went to release with zero open bug reports that hadn’t been, in some way, considered.
|
||||
</p>
|
||||
<p>
|
||||
We did something relatively unusual early on <span class="gametitle">Epitaph</span> — we split the game into two versions. A lot of MUDs have “clones” where creators can log on and perform risky patches without breaking the game, but as far as I know it's still the norm that changes in most MUDs are made to the live game. The clone, if it exists at all, is a sandbox for creator experimentation. We went the other way — we set up a dedicated development MUD, which is where all the active development is done. Most creators have no access on the live MUD to make any code changes. We then put in place a patch architecture that allowed us to cleanly update content from the dev MUD (known as “Black Ops”) to the live MUD. We then set up a <a href="http://epitaphonline.co.uk/patches.c">formal patch notes system</a>, one that listed each of the changes under a discrete version number, so everyone who wanted to could track the evolution of the game. In a development environment like this, you can't just patch on a whim because you fixed a few bugs, but you gain unparalleled development discipline. It gave us complete developer freedom whilst ensuring that the game experience remained consistent and reliable for everyone. It also ensured that we could version the software properly, which made the roadmap easier to handle.
|
||||
</p>
|
||||
<p>
|
||||
We put in a (few, moving) dates for when the initial 1.0 release would happen. As time passed, the roadmap for that version grew, and occasionally shrank, as features were added, evaluated and removed. We were pretty transparent about it — the roadmap was hidden from players on our developer wiki, but our patch notes were always available. A side benefit of doing this was that it generated a good deal of excitement amongst our pre-release players — there was a healthy buzz about the coming patch, what was involved, and when it was going to happen.
|
||||
</p>
|
||||
<p>
|
||||
The roadmap is the thing that will ensure you keep a steady course on development without veering too far away from your goal, which is an eventual release of a full-featured game.
|
||||
</p>
|
||||
<h3>Planning for Release</h3>
|
||||
<p>
|
||||
No game is ever going to be perfect. No game is ever going to be bug-free. No game the size and complexity of your average MUD is even going to come close to either of those goals. The fact is, you are never going to <em>feel</em> ready for release and you'll always find more reasons not to do it. Until you release, though — until people are playing your game and doing so with “live ammo” — you don't have a game, you've got a technical project. Your game <em>needs</em> to be released. Birds gotta fly, fish gotta swim, and games gotta be played.
|
||||
</p>
|
||||
<p>
|
||||
A game that releases is infinitely better than a game that doesn't. It doesn't matter how bad the released game is or how (theoretically) great the unreleased one is. This was absolutely the hardest lesson for me to learn, and the most difficult thing to accept. I would happily have continued tinkering with <span class="gametitle">Epitaph</span> for several more years without actually releasing, but at that point it would be obvious that I never would. So, I picked a date that came in the middle of my annual leave from work, which meant I had many full time days I could sink into polishing up what we had. Unfortunately, the first few weeks were unproductive because of a horrible heat wave, so I extended the date to the weekend before my leave ended. Those two weeks were a blur of activity — fixing bugs, testing, adding things, etc. As the release date loomed, I still felt as if we weren't ready, but I needed to keep reminding myself “we're never going to be <em>ready enough</em> for you”. I knew we had bugs aplenty, but then, every game does. We'd reached the point where any time we invested in polishing the game was having rapidly diminishing impact. You need players to find the bugs and report the bugs, and the only way they can do that is if they can play.
|
||||
</p>
|
||||
<h3>Release Day</h3>
|
||||
<p>
|
||||
My first piece of advice here is: leave plenty of time for opening day to make sure everything is ready. My second: make backups at least daily, and make an extra backup immediately before release. I had a very direct object lesson in the importance of backups: when I attempted to release <span class="gametitle">Epitaph</span>, I accidentally copied the old, public 0.5 version on top of the current 1.0 version that was to be released.
|
||||
</p>
|
||||
<p>
|
||||
Without backups, that would have been game over. The MUD would not have recovered. As it was, I hadn’t made a backup immediately before release, so some of the work since the last nightly backup was lost (what wasn’t recoverable from people’s open editors and local files), and the release was delayed. With a fresh backup, nothing would have been lost at all.
|
||||
</p>
|
||||
<p>
|
||||
Next piece of advice: don't list or advertise too early. Rely on the people who have been following your progress since the start, since they're the ones most likely to be forgiving, which they'll have to be. Develop a hard skin, and make sure everyone knows what a new release of a MUD involves. No matter how much work you put in, no matter how exhaustively you tested, your first contact with real players will be an enlightening experience.
|
||||
</p>
|
||||
<p>
|
||||
You'll be starting, broadly speaking, from a base of complete newbies. The first members of your nascent player base are just crawling around like children without adults, without anyone to give them “player useful” advice. Moreover, they don't know how everything works, so they're stress testing the mechanics in all kinds of interesting ways. They’re trying to eat living rats or slash people with trousers. They’re doing all the things that you wouldn’t have expected because you know the right way to play your game.
|
||||
</p>
|
||||
<p>
|
||||
Code tends to drift over time, too; something that was working the last time you tested may not be working by the time you go live, and you're just a handful of people with only your spare time to invest. Most projects can't do rigorous regression testing of the entire game every time something is changed.
|
||||
</p>
|
||||
<p>
|
||||
Expect to spend the next couple of days aggressively firefighting. We got <span class="gametitle">Epitaph</span> to the point where there were no longer any critical errors, so we could focus on the less tangible things like adjusting balance and penalties and so on. At that point, though, all we'd done is plug the bigger leaks — the boat was still taking on water. This is a situation you need to be ready for, which means actively fixing things. People will see that you're working hard and they'll be accommodating, but that's predicated on the assumption they want to see you succeed, so you want your long-term supporters around for this stage. Leave yourself enough time to deal with new people and reported issues. If it's just you, give yourself at least a week. If you have other reliable people with you, you can cut that down a bit.
|
||||
</p>
|
||||
<p>
|
||||
When you feel that the game is going to be solid enough for people who don't care if you succeed, throw out some ads for it. If you advertise on MUD-related sites, don't expect a huge influx of people. Most of the regular people frequenting these sites are developers or players who already have a favorite location. You'll get a few interested souls coming along, but many will be set in their ways already; if they're used to a DikuMUD, for example, even the syntax might be a turnoff. There are more ways to lose players in the first few minutes than there are to keep them.
|
||||
</p>
|
||||
<p>
|
||||
I would suggest a three-tier advertising strategy if you can manage it: your existing base of interested parties first, then mudders generally, and lastly some group of people outside the normal mudding world. <span class="gametitle">Epitaph</span> is a post-apocalyptic game, so we could reasonably advertise to zombie game and book fans. These are going to be the people who are hardest to satisfy, so don't try to recruit them right away. You'll get exactly one chance to make a first impression on them. Make sure that what they see is polished enough to draw them in.
|
||||
</p>
|
||||
<h3>Conclusion and Lessons Learned</h3>
|
||||
<p>
|
||||
I have worked on no project larger and more intense than <span class="gametitle">Epitaph</span> in my life. I have poured more of my blood and tears into this game than I did into my PhD. The evenings, weekends, and holidays devoted to this MUD have made it the equivalent of a second full-time job. I haven't had a proper vacation since I started; I've had weekends here, evenings there, a few snatched hours every other evening to do something with Mrs. Drakkos.
|
||||
</p>
|
||||
<p>
|
||||
The third biggest lesson I learned during this process was: you have to be able to do that. The reason why most MUDs never open isn't because of a lack of talent, or a lack of vision. It's because of a lack of <em>hunger</em>. I have <em>hungered</em> to release <span class="gametitle">Epitaph</span>, and it is that, more than anything else, that has ensured I made the time to make it happen. It's not enough to shrug one day and say “Meh, I'll make a MUD”.
|
||||
</p>
|
||||
<p>
|
||||
The second biggest lesson I learned is: when release day comes, you'll be hit with a realization. Your job isn't over. It's really only just begun. What release day provides is a promise of wonders to come for those who are willing to give your game a try. Players are voracious, though, and they consume content at incredible rates. Give it a few weeks — a month if you're lucky — and you'll find your newly addicted players are hungry for your next offering. The MUD demands you feed it with time, effort and enthusiasm. Leave yourself some energy to do that before you eventually collapse.
|
||||
</p>
|
||||
<p>
|
||||
The biggest lesson of all was this: for all the hard work it was, it was also an absolute joy. This is related to the hunger element above. We all have our addictions. Some are hooked on drugs, others on adrenaline. I'm hooked on coding, and the most fulfilling coding you can do is for a project where there are no limitations beyond your own capabilities. It's intoxicating to code for the unfettered love of it, and that intoxication grows when you see people enjoying what you have done.
|
||||
</p>
|
||||
<h3>Further Reading</h3>
|
||||
<p>
|
||||
I wrote extensively on my experiences when developing <span class="gametitle">Epitaph</span>, and you can find them on the <a class="website" href="http://epitaph.imaginary-realities.com/wp/?cat=1">Epitaph Textual Intercourse blog</a>. When I say “extensively”, I'm not kidding. There are around a quarter of a million words of content in there at the current count. I doubt the development of any MUD has ever been so exhaustively documented.
|
||||
</p>
|
||||
<p>
|
||||
For those interested in seeing how <span class="gametitle">Epitaph</span> code looks, you might want to have a peek inside the <a class="website" href="http://www.imaginary-realities.com/epitaph.pdf">Epitaph Survival Guide</a>, which is our internal development textbook.
|
||||
</p>
|
||||
<p>
|
||||
If you want to come check <span class="gametitle">Epitaph</span> out, and I absolutely think you should, then come see us. The grim darkness of the zombie apocalypse is waiting for you to make it just a little bit brighter.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Drakkos (Michael Heron) is the lead developer of <a class="gametitle" href="http://epitaphonline.co.uk/">Epitaph</a>.
|
||||
{% endblock %}
|
||||
73
templates/volume05_issue01/index.html
Normal file
73
templates/volume05_issue01/index.html
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<title>Imaginary Realities</title>
|
||||
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
||||
<link rel="stylesheet" type="text/css" media="all" href="stylesheet-index.css">
|
||||
<link rel="stylesheet" type="text/css" media="all" href="stylesheet.css">
|
||||
</head>
|
||||
|
||||
<body class="global tocpage">
|
||||
<div class="pagetitle">Imaginary Realities<span class="pagetitle-cursor"> </div></div>
|
||||
<main>
|
||||
<div class="main">
|
||||
<div class="issue-column">
|
||||
<div class="toc-header">
|
||||
<div class="issue-toc-label"><h2>Table of Contents</h2></div>
|
||||
<div class="issue-toc-month">December 2013</div>
|
||||
<div class="issue-toc-volumeissue">Volume 5, Issue 1</div>
|
||||
</div>
|
||||
<div class="download">
|
||||
<div class="download-label">Other Formats</div>
|
||||
<div class="download-entries">
|
||||
<div class="download-entry">
|
||||
<div class="download-entry-format"><a href="downloads/imaginary-realities-v05i01-201312.zip">ZIP/HTML</a></div><div class="download-entry-size">1.75 MB</div>
|
||||
</div>
|
||||
<div class="download-entry">
|
||||
<div class="download-entry-format"><a href="downloads/imaginary-realities-v05i01-201312.pdf">PDF</a></div><div class="download-entry-size">2 MB</div>
|
||||
</div>
|
||||
<div class="download-entry">
|
||||
<div class="download-entry-format"><a href="downloads/imaginary-realities-v05i01-201312.epub">EPUB</a></div><div class="download-entry-size">2 MB</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="reddit-link-offline"><a target="_blank" href="http://www.reddit.com/r/imaginaryrealities/comments/1syvpy/volume_5_issue_1_general_discussion/"><img width="19" height="15" src="images/spreddit3.gif"/> Discuss</a></div>
|
||||
</div>
|
||||
<nav>
|
||||
<ul>
|
||||
<li><a href="introduction/index.html">Introduction</a></li>
|
||||
</ul>
|
||||
<div class="content-articles">
|
||||
<div class="content-section-header"><h3>Articles</h3></div>
|
||||
<ul>
|
||||
<li><a href="modern-interface-modern-mud/index.html">A modern interface for a modern MUD</a></li>
|
||||
<li><a href="well-built-zone-work-art/index.html">A well built zone is a work of art</a></li>
|
||||
<li><a href="journey-through-paradice/index.html">A journey through Paradice</a></li>
|
||||
<li><a href="blind-accessibility-challenges-opportunities/index.html">Blind accessibility: challenges and opportunities</a></li>
|
||||
<li><a href="evennia-introduction/index.html">Evennia: an introduction</a></li>
|
||||
<li><a href="getting-roleplaying-scene-going/index.html">Getting a roleplaying scene going</a></li>
|
||||
<li><a href="introducing-new-players-redesigning-mud-school/index.html">Introducing new players and redesigning MUD School</a></li>
|
||||
<li><a href="hunger-game-learned-break-ship-bottle/index.html">The Hunger Game, or how I learned to break the ship from the bottle</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
<ul>
|
||||
<li><a href="help-save-old-mudding-resources/index.html">Help save old mudding resources</a></li>
|
||||
<li><a href="request-for-content/index.html">Request for content</a></li>
|
||||
<li><a href="staff/index.html">Staff</a></li>
|
||||
</ul>
|
||||
</nav>
|
||||
</div>
|
||||
</main>
|
||||
<div class="floating-box">
|
||||
<table class="floating-box-table floating-box-br">
|
||||
<tr>
|
||||
<td class="page-back floating-box-button unlinked-button">« article</td>
|
||||
<td class="floating-box-button unlinked-button">toc<td>
|
||||
<td class="floating-box-button"><a href="copyright/index.html">copyright</a><td>
|
||||
<td class="page-forward floating-box-button"><a href="introduction/index.html">article »</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 4.7 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 43 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 41 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,53 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
Introducing new players and redesigning MUD School
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Darcie “Natilena” Laur, 13th October 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p>
|
||||
For a long time, the MUD community has been discussing the dwindling player base, and the impact of modern games as a probable cause: the typical MUD community is an “older generation” of computer gamers. It’s always bothered me that the prevailing thought as to why the “younger generation” doesn’t play MUDs is that they are too graphics oriented and won’t give it a try as a result. I disagree; I’ve always felt that the issues involved are more those of any niche interest than a simple matter of “graphical games are ruining MUDs!”. Just as there are people who enjoy reading the book rather than seeing the movie, there are types of gamers who probably would enjoy a MUD if they could get past the barrier of the initial introduction. There are many ways of bridging the gap that are worth exploring, but my current focus is more towards how the game itself can become more welcoming and user-friendly.
|
||||
</p>
|
||||
<p>
|
||||
I spent some time introducing my kids and a few of their friends (ages 11 to 15) to my own home MUD. Of course I wanted them to like it and keep playing, but my primary goal was to observe and discern where the disconnect is between a new player’s expectations and how the game actually introduces itself. Truly, kids (well, mine at least) have the attention span of a zombie squirrel. Getting them invested enough to learn the ropes and enjoy the game has been an interesting challenge.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center screenshot" xheight="205" src="images/image01.png" width="287"/>
|
||||
</div>
|
||||
<p>
|
||||
I will concede that graphical games do much better than most MUDs at getting the player right into the game. There isn’t a school or an obvious tutorial, and game manuals are often not even included anymore. Modern games will just dump you right in and teach you as you go. This is related to the biggest problems the kids had trying to log in and play. They faced walls of text, and the overall feeling was “I just want to stop reading and kill something already!”. They would even try to inflict a messy death upon the various helper NPCs in the first parts of the game. Obviously this is not the outcome I had in mind.
|
||||
</p>
|
||||
<p>
|
||||
On the flip side, we also have a lot of new characters logging in who appear to be familiar with MUD s but then drop link a short time after starting a character, and I wanted to know why this happens, too. Rarely does a player who is unimpressed with the introduction to your game stick around to explain why, so as a starting point we started logging all of the failed commands entered by a level 1 character. The database log shows a time stamp, the failed command and the room number the character was in at the time. By focusing only on the failed commands, as opposed to trying to log everything, it excludes the extra “noise” of successful commands and gives a data set that is much easier to review and identify trends within. Its small size even made it possible to spot trends by eye rather than relying on queries. By reading through the database log, it was easy to see many of the incorrect commands were entered while the character was in the very first room. Failed commands such as map, search, inspect, enter and start, all entered from the New Player entrance, confirmed that nobody wants to read help files. I thought there must be a better way of teaching that didn’t involve all the reading.
|
||||
</p>
|
||||
<p>
|
||||
There is <a href="http://www.gdcvault.com/play/1015541/How-I-Got-My-Mom">a talk I highly recommend for any game designer</a> given by George Fan, the creator of <span class="gametitle">Plants vs. Zombies</span>. It discusses tutorial design and methods of getting a player into the game without having to read a novel first. My biggest take-away from this was how important it is to present the basic commands so that players are <em>doing</em> rather than reading about it. Second biggest was not to present too much information at once; for instance, they don’t need to know about death at the first login screen. That message can wait for the actual death.
|
||||
</p>
|
||||
<p>
|
||||
Notes and research done, I set out to redesign the introduction to the game. My philosophy and ultimate goal was to get away from all of the “look here”, “read this sign”, “read the newbie book” and “read this help file” stuff in order to get players into the game more quickly.
|
||||
</p>
|
||||
<p>
|
||||
The character creation process in our game, like many Diku-rivatives, was very linear, full of explanatory text with command prompts that only responded to very specific inputs. With some review, I focused the cleanup on rewriting the large, wordy paragraphs and replacing them with simple one- or two-line instructions. The process of choosing a race and class received a lot of attention. Previously, it was in a format of “pick a number for the race you want to be” followed by “pick a number for the class you wish to be”. Our class choices are restricted by race, causing a situation where the class the player may have wanted isn’t available for the race they’ve already chosen, without any easy way to back up and change race. Oh, and of course nobody reads the multi-page help files before making a choice. So, the race and class choices have now been combined together into a single step which better displays the available combinations. This screen will also take multiple arguments for input. For instance, if you wished to be a human cleric, you could type any of the following: human, then cleric; <span class="code">cl hum</span> (short forms); <span class="code">cleric hum</span>; or any combination of these. Only if you enter an impossible combination does the system respond with additional information.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center vmid screenshot" xheight="204" src="images/image04.jpg" width="359"/>
|
||||
<img class="center vmid screenshot" xheight="225" src="images/image02.jpg" width="359"/>
|
||||
</div>
|
||||
<p>
|
||||
In the game itself, the first room is where we tend to lose most new players. My first task was to remove the reading and replace it with actual actions (including MXP clickable links). This is a change from our old introduction, which would instruct new players to spend a good hour reading various help files, policies and command lists. We wanted to see how much of the basics could be taught in the first few rooms rather than through the required reading route. This creates another challenge because it is now essentially a forced tutorial. It needs to be mild enough not to annoy existing/MUD-knowledgeable users, but still teach truly new players the basics of what they will need to know. Our new opening screen no longer recommends all of the reading. It gives brief instructions with language that speaks directly to the player on the basics of experiencing the environment and getting around. To make it interesting, there are full exit descriptions and a multitude of extra little details that can be looked at. Once the player moves west into the next room, more brief instructions are there, in the room description, explaining about equipment and object manipulation. This is where players will receive their starter equipment. I considered creating an NPC that spoke to the player in the first few rooms, but decided that this would be overwhelming to a new player and annoying for an experienced player. Instead, the first NPC that speaks to the player and offers quests is presented only after the introductory rooms.
|
||||
</p>
|
||||
<p>
|
||||
While working directly with the kids, I took to heart the message that they really just wanted to get into the fight, but I maintained that basic combat commands still have to be taught. A good example is noting that a fighter doesn’t need all of the extra information about spell casting that a magic user does. Additionally, different types of magic users need different messages. I developed a technique that will display text in the description based on the character class. Now we have a room where a mage will get instruction on casting Magic Missile, a Cleric on Magic Stone and so on. In the screenshots, note how nothing is mentioned in the fight instruction room to show how to flee or what happens when you die. The character doesn’t need to know that quite yet, so instead the relevant instructions appear only when they get themselves into that situation. The focus has become about building on information as the player progresses rather than force feeding it all at once. This creates a better, more immersive experience for players and keeps them interested in progressing through the game.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center screenshot" xheight="203" src="images/image03.jpg" width="407"/>
|
||||
<img class="center screenshot" xheight="201" src="images/image00.jpg" width="405"/>
|
||||
</div>
|
||||
<p>
|
||||
This is all part of our large version 5 project; it is not all quite finished or live. While it feels like we’ve achieved some of my basic goals for the first few moments of the game it’ll probably always be a “work in progress”. It is one of those areas that can always be monitored and improved upon. The final product will be finished with a quest sequence that will teach some of the remaining basics along the way while at the same time be fun.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Natilena (Darcie Laur) is a Greater Goddess on <a href="http://www.tfcmud.com">The Final Challenge</a>.
|
||||
{% endblock %}
|
||||
BIN
templates/volume05_issue01/introduction/images/spreddit3.gif
Normal file
BIN
templates/volume05_issue01/introduction/images/spreddit3.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
26
templates/volume05_issue01/introduction/index.html
Normal file
26
templates/volume05_issue01/introduction/index.html
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
{% extends "issue/other/index.html" %}
|
||||
{% block page_title %}Introduction{% endblock %}
|
||||
{% block other_content %}
|
||||
<p>
|
||||
Welcome to the first issue of <span class="publicationtitle">Imaginary Realities</span> in twelve years.
|
||||
</p>
|
||||
<p>
|
||||
<span class="publicationtitle">Imaginary Realities</span> is now fifteen years old. Created and published by David Bennett from September 1998 to December 2001, thirty-seven issues were published within four volumes. Three people in addition to myself worked to create this new issue, Jennifer Melchert, Matthew Sheahan and Richard Woolcock.
|
||||
</p>
|
||||
<p>
|
||||
It might be argued that the late ‘90s were the heyday of sharing information about mudding. Although mudding is a popular hobby today, there are now few places where this sharing still happens. The MUD-Dev mailing list survives, no longer active, but archived in a poorly reconstructed form. The USENET newsgroups are almost lost to us, with Google letting us search them, but without the ability to wander through and look for topics of interest which we hadn’t known the keywords for. The old <span class="publicationtitle">Imaginary Realities</span> website is perhaps the best surviving resource, thanks to Fred Clift who had an old archived copy stored away.
|
||||
</p>
|
||||
<p>
|
||||
Mudding and MUD development are evolving. Telnet is still around, and still a contender, but one of many. While it was possible to play a MUD through a website back in the ‘90s, it wasn’t pretty. Nowadays we have web sockets, and while there are still situations where Flash is required to be involved, it isn’t often. MUDs can be played on mobile devices, and there are ways that the experience needs to be tailored to suit those smaller screens. Clients like mushclient have changed to allow the developers of a MUD to provide graphic enhancements to the core text-based gameplay. And that’s just the MUD development side of it. This is just the tip of the iceberg; many other topics should be explored and shared so that others can benefit from them.
|
||||
</p>
|
||||
<p>
|
||||
For this issue of <span class="publicationtitle">Imaginary Realities</span>, twenty articles were offered, and eight of these ended up actually being submitted. The twenty is a good indication that there’s enough support to publish more issues in future, and the eight is around the number of articles that David published back in the day, in any given issue. These numbers together are promising enough to continue publishing more issues, and we’re excited to keep bringing information and opinions to our gaming community.
|
||||
</p>
|
||||
<p>
|
||||
We only asked for articles about text-based mudding, but the original intention was that, if it was worthwhile to publish further issues, we would widen the scope to cover text-based gaming in general. For future issues, we are seeking articles on the subjects of (text-based) mudding, interactive fiction, roguelikes, browser games, or gamebooks. If you would like to submit an article, please let us know! <span class="publicationtitle">Imaginary Realities</span> is for the community and we need your input.
|
||||
</p>
|
||||
<p>
|
||||
Thanks for reading!
|
||||
</p>
|
||||
<p class="authorbio">Richard Tew</p>
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 64 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 100 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,81 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
A journey through Paradice
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Matthew Chaplain, 2nd October 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p class="quotetext">
|
||||
"Sorry guys, I missed the rolls. Let me log in again."
|
||||
</p>
|
||||
<p>
|
||||
In 2009, myself and a group of friends were playing a <a class="gametitle" href="http://www.fantasyflightgames.com/edge_minisite.asp?eidm=50">Dark Heresy</a> tabletop roleplaying game over the Internet. We used <a class="softwaretitle" href="http://www.teamspeak.com/">TeamSpeak</a> for voice communication and a bot implemented over <a class="softwaretitle" href="https://en.wikipedia.org/wiki/Internet_Relay_Chat">IRC</a> for simulating die rolls.
|
||||
</p>
|
||||
<p>
|
||||
One of our players had a problem, however. If a connection from his computer was inactive for five minutes, this resulted in him being disconnected. This usually meant he had to log in to IRC for each die roll, and he would frequently miss other people's rolls, and thus much of the excitement during these sections of the game. This was extremely frustrating for both him and us.
|
||||
</p>
|
||||
<p>
|
||||
Once upon a time, I was a coder for a MUD. Since then, I have begun development for a couple of experimental codebase frameworks that were, unfortunately, never in a complete enough state to see the light of day. Nevertheless, I decided I had the knowledge, and I had the technology (since our gaming group maintains a colocated box upon which the TeamSpeak server and other goodies are installed). Why should I not use my old MUD knowledge to put together something everyone can use for rolling dice?
|
||||
</p>
|
||||
<p>
|
||||
And so I did. A few lunchtimes later, most of which was spent looking for a decent enough pun, the <a class="softwaretitle" href="https://code.google.com/p/paradice9/">Paradice</a> project was born.
|
||||
</p>
|
||||
<p>
|
||||
The first iteration of Paradice was what could be considered a simple one-room talker. It was, like most MUDs, Telnet-based and fundamentally line-mode, although it made use of the "scrolling region" (<span class="code">DECSTBM</span>) feature of the <a href="http://vt100.net/docs/vt100-ug/chapter3.html">VT100 protocol</a>. This allowed for two regions on the screen, one containing the names of all the players currently online, and the other containing the more normal interactive area of dice rolls, whispers, chats, and so on.
|
||||
</p>
|
||||
<p>
|
||||
The disconnection issue was also solved by using a feature that I never thought would be useful: every thirty seconds or so, the server sends out a two-byte packet that represents a Telnet <span class="code">NOP</span> (No Operation instruction). On all good terminal software, including <a class="softwaretitle" href="http://www.chiark.greenend.org.uk/~sgtatham/putty/">PuTTY</a> (which I had recommended to our group), this has no visible effect, and is thus a non-intrusive solution to the problem.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="437" src="images/image00.png" width="624"/>
|
||||
<div class="imgcaption">"Hey Kaz, I wish Paradice wouldn't interrupt whatever I'm typing. Can you fix that?"</div>
|
||||
</div>
|
||||
<p>
|
||||
At this point, Paradice was everything that it needed to be, but not what I wanted it to be. There were two major complaints with the program. First, due to the scrolling regions feature I was using, there was no scrollback available in the client. This could be solved by removing the feature that used the scrolling regions and reverting to the classic scrolling text look-and-feel that MUDs have. However, it would also mean that the player list was no longer visible all the time.
|
||||
</p>
|
||||
<p>
|
||||
The other complaint was the same complaint I had about MUDs in the late ‘90s: if you were typing a command in, and some other action occurred in-game, then it would interrupt your typing. These days, this problem is mostly solved by using a MUD client. But the vast majority of clients do not support scrolling regions, so the solution became not only to get my gaming group to download yet another piece of software, but also to re-implement a feature to make it less useful.
|
||||
</p>
|
||||
<p>
|
||||
I found this to be unacceptable, especially since I already knew that this was solvable using the technology that was in front of me.
|
||||
</p>
|
||||
<p>
|
||||
By using the Telnet options of <span class="code">WILL ECHO</span> and <span class="code">WILL SUPPRESS_GO_AHEAD</span>, terminals change from line mode to the so-called <a href="http://www.ietf.org/rfc/rfc857.txt">"character-at-a-time" mode</a>, or character mode. At this point, the terminal becomes an 80 x 24 character-by-character window rather than an 80 x ∞ line-by-line window. Add your VT100 protocol onto this and you control the display in its entirety, including all text on the screen and the cursor position.
|
||||
</span>
|
||||
</p>
|
||||
<p>
|
||||
Taking my inspiration from Java, I created a library called Munin that implements a component-based user interface where positioning and sizing of components is controlled by a series of layout objects. For example, a container component that is managed by a grid layout will arrange its components in a fixed number of rows and columns. A compass layout will arrange its components by squeezing them to the north, east, south or west sides and giving the remaining space to a centre component.
|
||||
</p>
|
||||
<p>
|
||||
Each element of a component is then an attributed character that contains information about the underlying character it represents. This includes graphical attributes, such as foreground colour and background colour, lesser-known attributes such as polarity and underlining, and its character set and locale attributes, which are useful for accessing alternative character sets for graphical drawing characters.
|
||||
</p>
|
||||
<p>
|
||||
Actually drawing to the display is one of the more interesting parts of the process, of which the essence is an attempt to update changes to the screen in the most efficient way possible. For example, if a text box's border has changed colour, then only the characters for the border need to change; the text inside does not need to be rewritten. This involves maintaining a copy of the client's screen on the server and some careful detection of the parts of the screen that are changed. Then, the client's cursor is manipulated to produce the shortest sequence of characters that can be sent to the client to complete the update.
|
||||
</p>
|
||||
<p>
|
||||
Paradice also implements an event framework that recognises VT100 command codes and forwards them through the user interface. For example, hitting the up arrow on the terminal sends the <span class="code">CUP</span> sequence, <span class="code">ESC [ H</span>. This can filter through the top-level window component, down through the containers to, for example, the command prompt component. This component then looks at the command history and fills its text area with the previous command. Handling these command codes can result in a much more intuitive interface than just handling textual commands alone.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="392" src="images/image01.png" width="624"/>
|
||||
<div class="imgcaption">"Why is clicking on this button not working?"</div>
|
||||
</div>
|
||||
<p>
|
||||
Later on in the development of Paradice, I implemented some button-like components. However, to "click" these buttons, you had to tab to them and hit either space or enter. When one of our gaming group asked me why clicking on them wasn't working, my initial response was that it couldn't work that way. After research, I stumbled upon another protocol layer that proved me wrong.
|
||||
</p>
|
||||
<p>
|
||||
PuTTY also implements many of the <a href="http://invisible-island.net/xterm/ctlseqs/ctlseqs.html">XTerm control sequences</a>. These overlap somewhat with the VT100 control sequences, but with the addition of some very interesting extensions — for example, being able to control the text in the title bar of the client window and to detect mouse button presses. Since this discovery, the capabilities of the user interface have grown greatly, to the point where one of the most recent features is almost entirely point-and-click based, although it can still be controlled via the keyboard.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="358" src="images/image02.png" width="624"/>
|
||||
</div>
|
||||
<p>
|
||||
Development of Paradice is still ongoing, but the conclusion of this tale is that the features of the basic textual interface that MUDs have been provided with since the 1990s are woefully underused. Some of the protocols that exist in certain clients need never have existed at all, their functionality already being replicable using existing features. Worse yet, while clients have gone forward to produce some astounding pieces of work — <a href="http://www.mudbytes.net/topic-2899">KaVir's work on customising MUSHClient</a> is truly inspirational in this respect — the clients have also gone backwards in not supporting character mode, and by having input fields separate from the output display. The only client I know of not to have gone backwards this way is <a href="http://tintin.sourceforge.net/">TinTin++</a>.
|
||||
</p>
|
||||
<p>
|
||||
Truly, the MUD codebase of tomorrow would be better served by a client with character mode, fully server-controllable displays and the scripting and customisability of modern clients. With client development having once more come to the foreground over the past few months and the launch of new clients such as <a class="softwaretitle" href="http://www.mudportal.com/play">The MUD Portal</a>, I hope that developers of these clients will consider this article carefully.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Matthew Chaplain develops <a href="https://code.google.com/p/paradice9/">the Paradice codebase</a>. Comments, criticism, and code submissions are all welcome.
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 5.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 201 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 105 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 89 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 263 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
|
|
@ -0,0 +1,153 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
A modern interface for a modern MUD
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Richard “KaVir” Woolcock, 14th October 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p class="quotetext">
|
||||
Do you see novels in color? I don't, and prefer my mudding life to be that way too.
|
||||
</p>
|
||||
<p class="quoteattr">— Robert Peckham, 8th June 1995</p>
|
||||
<p>
|
||||
Early MUDs were usually played through basic Telnet clients, which offered relatively few options to improve the presentation of output. The introduction of specialised MUD clients provided mudders with a range of new features to enhance gameplay, but the simple terminal interface remained the norm for many years, and is still used today by some players.
|
||||
</p>
|
||||
<p>
|
||||
A few MUDs used VT100 control codes to display status bars or clear the screen, but even they were rare; the options available for enhancing the interface were usually ignored or dismissed. Even the use of ANSI colour was initially disdained by many, and it was years before colour became a standard MUD feature. It should come as no surprise that the adoption of new standards is still slow in the modern age of mudding.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" src="images/image02.png" width="602" />
|
||||
</div>
|
||||
<h3>The rise of graphics</h3>
|
||||
<p class="quotetext">
|
||||
I think both are really the same thing; in many ways, there are far larger differences between certain kinds of text muds than there are between graphical and text-based games.
|
||||
</p>
|
||||
<p class="quoteattr">— Raph Koster, 31st March 2006</p>
|
||||
<p>
|
||||
Although there were earlier graphical MUDs, such as <span class="gametitle">Habitat</span> in 1985, it wasn't until the mid to late 1990s that graphical MUDs really started becoming popular. Rebranded as MMORPGs in 1997 by Richard Garriott, they have continued to evolve and grow in popularity over the years, and there’s no disputing that they’ve become very successful.
|
||||
</p>
|
||||
<p>
|
||||
Yet the primary difference between a MUD and an MMORPG lies not in the <em>server</em> but in the <em>client</em>.
|
||||
(Koster 2006) Of course there are other differences, but they tend to be the same sort of things that differentiate one MUD server from another — choice of protocols, scaling for playerbase, combat and movement systems, content, and so on. These are all decisions that every server developer needs to consider, regardless of whether they’re designing a MUD or an MMORPG.
|
||||
</p>
|
||||
<h3>Graphics are not the enemy</h3>
|
||||
<p class="quotetext">
|
||||
I don't think there is much interest in adventure games anymore. Everyone wants graphical interfaces without text input... basically TEXT ADVENTURES ARE DEAD.
|
||||
</p>
|
||||
<p class="quoteattr">— Colin Adams, 1st October 1990</p>
|
||||
<p>
|
||||
For decades, people have been claiming that text-based games are dead or dying. They’ll often accuse the MMORPGs of stealing their audience, while at the same time refusing to put any effort into client development. However, if you look at the most popular MUDs, you'll see that many of them <em>have</em> customised their own clients, designed their own interfaces, and retained a sizeable playerbase. While there are certainly other factors to be taken into account, the value of aesthetics should not be underestimated — it’s a lesson we can and should learn from MMORPGs.
|
||||
</p>
|
||||
<p>
|
||||
There are few people who would argue that aesthetics <em>aren't</em> important. Even for interfaces that are pure text, it makes a far better impression on prospective players if that text is nicely formatted, checked for spelling and grammar, uses colour to highlight important information, and so on.
|
||||
</p>
|
||||
<p>
|
||||
If you take a look at the websites for various MUDs, you'll see the use of fonts, colour, and graphics, all designed to improve aesthetics — after all, websites are important even for text-based games, and a well-presented website can give visitors a far better impression of your MUD.
|
||||
</p>
|
||||
<p>
|
||||
But then you need to ask yourself the question: if you're putting all that effort into making the website look nice, shouldn't you put at <em>least</em> as much effort into the appearance of the MUD itself? Would you use ASCII graphics on your website?
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="75" src="images/image01.png" width="602"/>
|
||||
<div class="imgcaption">Traditional text prompt, VT100 energy bars, and graphical energy bars. Three ways to display the same information — which would you rather use?</div>
|
||||
</div>
|
||||
<h3>Text versus graphics</h3>
|
||||
<p class="quotetext">
|
||||
Adding flashy graphics and whatnot won't keep people playing your game because there will be much better graphical games out there.
|
||||
</p>
|
||||
<p class="quoteattr">— Quixadhal, 19th August 2013</p>
|
||||
<p>
|
||||
One of the more common objections to the use of graphics is based on a false dilemma — the mistaken belief that a good game has to be either graphical <em>or</em> text-based, and that it's not worth adding any graphics unless you can offer something on-par with the latest commercial MMORPGs.
|
||||
</p>
|
||||
<p>
|
||||
Yet there are many examples that prove otherwise. Take a look at a game like
|
||||
<a class="gametitle" href="http://www.travian.us/">Travian</a>,
|
||||
which has an very basic graphical interface layered over what could just as easily be played as a text-based game. Take a look at
|
||||
<a class="gametitle" href="http://www.ftlgame.com/">Faster Than Light</a>,
|
||||
which is effectively a roguelike with a fairly simple GUI, and yet it really <em>works</em>.
|
||||
The interface might be simple, but it complements the gameplay beautifully and makes the overall product feel polished as a result.
|
||||
</p>
|
||||
<p>
|
||||
However, at the end of the day, it shouldn’t be about what <em>other</em> games are doing, but about making the most of the tools available to improve the appeal of your <em>own</em> game. A well-designed MUD should have an intuitive and user-friendly interface, and certain aspects of an interface can be better represented through graphics than through text: a gauge is easier to read (and less spammy) than a prompt, a proper graphical map is easier to understand than an ASCII map, and so on. For blind players in particular, sound can go a long way towards making the game more accessible.
|
||||
</p>
|
||||
<p>
|
||||
Of course, a fancy interface won't turn a bad game into a good one — it goes without saying that you need to put effort into the gameplay as well. But conversely, if your MUD is poorly presented and the interface is ugly and clunky, it won't matter how many cool features you've got, because nobody will hang around long enough to give your game a chance. (Gray and Gabler 2005)
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="272" src="images/image04.png" width="291"/> <img class="center" xheight="271" src="images/image05.png" width="271"/>
|
||||
<div class="imgcaption">ASCII graphics are still graphics. If you’ve already decided to use ASCII graphics in your MUD, why not take it to the next level?</div>
|
||||
</div>
|
||||
<h3>Modern MUD clients</h3>
|
||||
<p>
|
||||
Text-based MUDs with graphical interfaces have been around for a while, but in the past they tended to use private clients and closed protocols. In recent years this has changed, with modern clients adding support for a range of new features, MUSHclient and Mudlet being particularly notable examples for their flexible graphical support. In the case of Mudlet, individual MUDs can even offer a custom script which the client downloads automatically when a player first connects, removing the entry barrier of having to download and install a separate interface for each MUD.
|
||||
</p>
|
||||
<p>
|
||||
The number of browser-based MUD clients has also been growing, with FMud being customised and integrated into a number of websites, and a relatively new contender called The MUD Portal offering a powerful and extensible interface. While not everyone likes playing a MUD through their web browser, such an option can significantly lower the entry barrier for new players, who might otherwise be required to download and install a client before they can play.
|
||||
</p>
|
||||
<p>
|
||||
There are even clients designed for smartphones and tablets, such as the feature-rich Blowtorch client for Android. While many clients offer data compression via MCCP, it becomes particularly important for smartphone clients, as they often have a limited data plan.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="325" src="images/image00.png" width="601"/>
|
||||
<div class="imgcaption">A custom interface for MUSHclient, showing dungeon exploration.</div>
|
||||
</div>
|
||||
<p>
|
||||
In addition to looking better than ASCII, proper graphics can be a lot easier for players to understand. Take a look at the comparison below: the first map is ASCII and provides only a rough indication of where you are and what parts of the dungeon you’ve explored, while the second map is detailed enough to be useful for navigation.
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" src="images/areamap1.png" width="269"/> <img class="center" src="images/areamap2.png" width="248"/>
|
||||
</div>
|
||||
<h3>Modern client features</h3>
|
||||
<p>
|
||||
Out-of-band protocols such as MSDP, ATCP, and GMCP can be used to pass data transparently between the MUD and the client. This allows you to refresh maps, energy bars and other graphics in real-time without waiting for the text window to update.
|
||||
</p>
|
||||
<p>
|
||||
Most modern clients now support at least 256 colours (8-bit), while some support over 16 million (24-bit). Although this might seem excessive for text, it can be useful to have access to certain colours and shades that aren’t included with the normal 16 ANSI colours.
|
||||
</p>
|
||||
<p>
|
||||
Above and beyond 24-bit colour, MXP adds support for clickable links and menus, fonts, inline graphics, and a range of other features.
|
||||
</p>
|
||||
<p>
|
||||
Some clients also support Unicode characters such as the Norse runic alphabet, alchemical symbols, gender symbols, weather symbols, line-drawing characters, chess pieces, and so on.
|
||||
</p>
|
||||
<p>
|
||||
Sound is another useful option that’s particularly popular among blind and visually-impaired players, serving a role that’s both aesthetic and functional — the audible “clank” of a sword-blow is much faster to interpret than waiting for your screen reader to spit out an entire combat message. While blind players may be a minority, they’re also less likely to be lured away by fully graphical games, which tend to be less accessible than text-based MUDs. (Peters 2009)
|
||||
</p>
|
||||
<div class="imgcenter">
|
||||
<img class="center" xheight="363" src="images/image06.png" width="602" />
|
||||
<div class="imgcaption">A custom interface for Mudlet, showing a fight in the dojo.</div>
|
||||
</div>
|
||||
<h3>Modern MUD servers</h3>
|
||||
<p>
|
||||
Of course it doesn’t matter how fancy a client is if the MUD server doesn’t use any of its features! Graphics and sound are handled at the client end, but the MUD still needs to tell the client <em>what</em> and <em>when</em> to draw. You can theoretically do much of the work with triggers and regular expressions, and many players do indeed create their own interfaces, but that’s a poor substitute for official server-side support, not to mention a lot more effort for the players you’re trying to attract and retain.
|
||||
</p>
|
||||
<p>
|
||||
Many MUD owners seem to view graphical interfaces as some sort of mysterious black magic that requires a vast investment of time and skill. While it's certainly possible to spend a lot of time on GUI work, even a simple interface can be a huge improvement, and it's something that can be achieved extremely quickly; there are public snippets, like my own
|
||||
<a href="http://www.mudbytes.net/file-2811">MUD Protocol Handler</a>
|
||||
and Scandum’s
|
||||
<a href="http://www.mudbytes.net/file-2608">MUD Telopt Handler</a>,
|
||||
that provide the server-side support, and various scripts and plugins that can be used as a starting point for designing your own GUI. It should be possible for most MUD owners to have something functional in a matter of hours.
|
||||
</p>
|
||||
<p>
|
||||
The tools are all there. You just have to use them.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
KaVir (Richard Woolcock) is the owner of <a href="http://www.godwars2.org/">God Wars II</a>.
|
||||
{% endblock %}
|
||||
{% block article_references_content %}
|
||||
{{ super() }}
|
||||
<p class="citation">
|
||||
Koster, Raph. 2006. “Are MUDs and MMORPGs the same thing?”
|
||||
<a href="http://www.raphkoster.com/2006/03/31/are-muds-and-mmorpgs-the-same-thing/">http://www.raphkoster.com/2006/03/31/are-muds-and-mmorpgs-the-same-thing/</a>
|
||||
</p>
|
||||
<p class="citation">
|
||||
Gray, Kyle and Gabler, Kyle. 2005. “How to Prototype a Game in Under 7 Days.”
|
||||
<a href="http://www.gamasutra.com/view/feature/2438/how_to_prototype_a_game_in_under_7_.php">http://www.gamasutra.com/view/feature/2438/how_to_prototype_a_game_in_under_7_.php</a>
|
||||
</p>
|
||||
<p class="citation">
|
||||
Peters, Matthew. 2009. “Spot On: The blind gaming the blind.”
|
||||
<a href="http://www.gamespot.com/articles/spot-on-the-blind-gaming-the-blind/1100-6215457/">http://www.gamespot.com/articles/spot-on-the-blind-gaming-the-blind/1100-6215457/</a>
|
||||
</p>
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
38
templates/volume05_issue01/request-for-content/index.html
Normal file
38
templates/volume05_issue01/request-for-content/index.html
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
{% extends "issue/other/index.html" %}
|
||||
{% block page_title %}Request for content{% endblock %}
|
||||
{% block other_content %}
|
||||
<h3>Articles</h3>
|
||||
<p>
|
||||
Would you like to write an article for the next issue of <span class="publicationtitle">Imaginary Realities</span>?
|
||||
</p>
|
||||
<p>
|
||||
Text-based gaming related articles are currently accepted on these topics:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Browser games</li>
|
||||
<li>Gamebooks</li>
|
||||
<li>Interactive fiction</li>
|
||||
<li>MUDs</li>
|
||||
<li>Roguelikes</li>
|
||||
</ul>
|
||||
<p>
|
||||
Articles should not have been previously published. If they have been previously published, they should be substantially revised to be made current, perhaps to address a changing situation, or even a changed viewpoint. Fiction will be accepted, as long as its relationship to the above topics can be determined by a reader.
|
||||
</p>
|
||||
<h3>Letters</h3>
|
||||
<p>
|
||||
In the past, <span class="publicationtitle">Imaginary Realities</span> has featured a “Letters” section. If you have something you would like to write (perhaps to address past articles, or for whatever reason), please send it and we may publish it, if it is suitable.
|
||||
</p>
|
||||
<h3>Content Ideas</h3>
|
||||
<p>
|
||||
If you have an idea for content you would like to see, please let us know, and maybe we can solicit someone to write about it.
|
||||
</p>
|
||||
<h3>Licensing</h3>
|
||||
<p>
|
||||
Contributed content is required to be licensed by you under the
|
||||
<a href="{{tp.license_link}}">{{tp.license_text}}</a> license.
|
||||
</p>
|
||||
<h3>Contact Information</h3>
|
||||
<p>
|
||||
Please contact Richard Tew (<a href="mailto:richard.m.tew@gmail.com">richard.m.tew@gmail.com</a>) for approval before proceeding to write an article, to ensure that your intended subject is suitable.
|
||||
</p>
|
||||
{% endblock %}
|
||||
BIN
templates/volume05_issue01/staff/images/image00.png
Normal file
BIN
templates/volume05_issue01/staff/images/image00.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 29 KiB |
BIN
templates/volume05_issue01/staff/images/image01.png
Normal file
BIN
templates/volume05_issue01/staff/images/image01.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
BIN
templates/volume05_issue01/staff/images/image02.jpg
Normal file
BIN
templates/volume05_issue01/staff/images/image02.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 9.8 KiB |
BIN
templates/volume05_issue01/staff/images/image03.png
Normal file
BIN
templates/volume05_issue01/staff/images/image03.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 36 KiB |
75
templates/volume05_issue01/staff/index.html
Normal file
75
templates/volume05_issue01/staff/index.html
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
{% extends "issue/other/index.html" %}
|
||||
{% block page_title %}Staff{% endblock %}
|
||||
{% block other_content %}
|
||||
<table cellpadding="0" cellspacing="0" class="stafftable">
|
||||
<tbody>
|
||||
<tr>
|
||||
<td class="imgcenter">
|
||||
<img src="images/image03.png" width="112"/>
|
||||
</td>
|
||||
<td>
|
||||
<div>
|
||||
<div class="staffname">Richard Tew (Donky)</div>
|
||||
<div class="stafftitle">Managing Editor</div>
|
||||
</div>
|
||||
<div class="staffbio">
|
||||
Richard has worked on one
|
||||
<a href="https://code.google.com/p/sorrows-mudlib/">Stackless Python mudlib</a>
|
||||
and two
|
||||
<a href="http://www.disinterest.org/projects.html">LP mudlibs</a>, as well as a telnet-based
|
||||
<a href="https://code.google.com/p/sorrows-mudlib/source/browse/#svn%2Ftrunk%2Fgames%2Froguelike">multiplayer roguelike</a>.
|
||||
</div>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="imgcenter">
|
||||
<img src="images/image00.png" width="120"/>
|
||||
</td>
|
||||
<td>
|
||||
<div>
|
||||
<div class="staffname">Matthew Sheahan (Chaos)</div>
|
||||
<div class="stafftitle">Editor</div>
|
||||
</div>
|
||||
<div class="staffbio">
|
||||
Chaos has been lead developer of
|
||||
<a class="gametitle" href="http://lostsouls.org/">Lost Souls</a>
|
||||
since 1998. He curates
|
||||
<a class="website" href="http://mudseek.com/">MUDseek</a>
|
||||
and has published an
|
||||
<a href="https://github.com/chaosprime/lpc-astar">LPC implementation of A* search</a>
|
||||
as open source. In real life, he is a Web software architect.
|
||||
</div>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="imgcenter">
|
||||
<img src="images/image01.png" width="100"/>
|
||||
</td>
|
||||
<td>
|
||||
<div>
|
||||
<div class="staffname">Richard Woolcock (KaVir)</div>
|
||||
<div class="stafftitle">Associate Editor</div>
|
||||
</div>
|
||||
<div class="staffbio">
|
||||
KaVir is the owner of
|
||||
<a class="gametitle" href="http://www.godwars2.org">God Wars II</a>
|
||||
and developer of the GodWars and Gladiator Pits codebases. He has also written several MUD-related snippets and articles, and is an auditor for
|
||||
<a class="website" href="http://www.mudconnect.com">The Mud Connector</a>.
|
||||
</div>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="imgcenter">
|
||||
<img src="images/image02.jpg" width="100"/>
|
||||
</td>
|
||||
<td>
|
||||
<div>
|
||||
<div class="staffname">Jennifer Melchert (jenphalian)</div>
|
||||
<div class="stafftitle">Copyeditor</div>
|
||||
</div>
|
||||
<div class="staffbio">jenphalian is a literary assistant for a New York Times bestselling author and one-time first reader for a Hugo-nominated literary magazine.</div>
|
||||
</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
{% endblock %}
|
||||
119
templates/volume05_issue01/stylesheet-article.css
Normal file
119
templates/volume05_issue01/stylesheet-article.css
Normal file
|
|
@ -0,0 +1,119 @@
|
|||
p.title {
|
||||
font-size: 24pt;
|
||||
font-family: PTSZ, Courier New;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
p.title + p {
|
||||
font-size: 10pt;
|
||||
}
|
||||
|
||||
h3 {
|
||||
margin-top: 30px;
|
||||
}
|
||||
h3, h3 * {
|
||||
font-size: 14pt;
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
.python-code {
|
||||
font-family: Courier New;
|
||||
}
|
||||
|
||||
table.stafftable {
|
||||
border-left: dashed 1pt grey;
|
||||
border-top: dashed 1pt grey;
|
||||
margin-bottom: 4px;
|
||||
}
|
||||
|
||||
/* The first paragraph in the first td in each row. */
|
||||
table.stafftable td:first-child div:first-child {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
/* All table cells. */
|
||||
table.stafftable tr td {
|
||||
padding: 5px;
|
||||
border-right: dashed 1pt grey;
|
||||
border-bottom: dashed 1pt grey;
|
||||
}
|
||||
|
||||
table.stafftable td.imgcenter {
|
||||
width: 120px;
|
||||
}
|
||||
|
||||
.staffname {
|
||||
float: left;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.stafftitle {
|
||||
float: right;
|
||||
}
|
||||
|
||||
.staffbio {
|
||||
clear: both;
|
||||
float: none;
|
||||
padding-top: 10px;
|
||||
}
|
||||
|
||||
.byline {
|
||||
margin-top: 0;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
|
||||
.citation {
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.authorbio {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.disclaimer {
|
||||
font-style: italic;
|
||||
font-size: 9pt;
|
||||
}
|
||||
|
||||
/* Need to automatically rename, or manually, class usage to use these... */
|
||||
|
||||
.quotetext {
|
||||
direction: ltr;
|
||||
margin-left: 36pt;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.quoteattr {
|
||||
text-align: right;
|
||||
}
|
||||
|
||||
.imgcenter, .imgcaption {
|
||||
text-align: center;
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.imgcaption {
|
||||
margin-top: 5px;
|
||||
}
|
||||
|
||||
.code {
|
||||
font-family: Courier New,Courier,fixed;
|
||||
}
|
||||
|
||||
img.center {
|
||||
display: inline-block;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
}
|
||||
|
||||
.screenshot {
|
||||
margin: 10px;
|
||||
}
|
||||
|
||||
.vtop {
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
.vmid {
|
||||
vertical-align: middle;
|
||||
}
|
||||
112
templates/volume05_issue01/stylesheet-index.css
Normal file
112
templates/volume05_issue01/stylesheet-index.css
Normal file
|
|
@ -0,0 +1,112 @@
|
|||
@font-face {
|
||||
font-family: PTSZ;
|
||||
src: url(_fonts/ProggyTinySZ.ttf#ProggyTinyTTSZ) format(truetype);
|
||||
}
|
||||
|
||||
h2, h3 {
|
||||
font-style: normal;
|
||||
font-variant: small-caps;
|
||||
font-weight: normal;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 11pt;
|
||||
font-weight: bold;
|
||||
padding-bottom: 20px;
|
||||
margin-top: 0px;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 10pt;
|
||||
margin-top: 0px;
|
||||
margin-bottom: 0px;
|
||||
}
|
||||
|
||||
.issue-column {
|
||||
float: left;
|
||||
width: 140px;
|
||||
padding-left: 30px;
|
||||
padding-right: 30px;
|
||||
}
|
||||
|
||||
.issue-column div, .issue-column div * {
|
||||
}
|
||||
|
||||
.issue-toc-label h2 {
|
||||
text-align: center !important;
|
||||
}
|
||||
|
||||
.issue-toc-month, .issue-toc-volumeissue {
|
||||
font-size: 10pt;
|
||||
color: #888888;
|
||||
text-align: center !important;
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.issue-toc-month {
|
||||
padding-bottom: 10px;
|
||||
}
|
||||
|
||||
.toc-header {
|
||||
}
|
||||
|
||||
.download {
|
||||
margin-top: 100px;
|
||||
}
|
||||
|
||||
.download-label {
|
||||
font-style: normal;
|
||||
font-variant: small-caps;
|
||||
font-weight: normal;
|
||||
text-align: center !important;
|
||||
border: 1px dashed #DDDDDD;
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
.download-entries {
|
||||
overflow: auto;
|
||||
padding: 4px;
|
||||
border-left: 1px dashed #DDDDDD;
|
||||
border-right: 1px dashed #DDDDDD;
|
||||
border-bottom: 1px dashed #DDDDDD;
|
||||
}
|
||||
|
||||
.download-entry-format, .download-entry-size {
|
||||
float: left;
|
||||
width: 50%;
|
||||
font-size: 8pt;
|
||||
text-align: right !important;
|
||||
}
|
||||
|
||||
.download-entry-format a, .download-entry-format a {
|
||||
font-size: 8pt;
|
||||
}
|
||||
|
||||
.download-entry-format {
|
||||
width: 6em;
|
||||
}
|
||||
|
||||
nav {
|
||||
position: relative;
|
||||
float: left;
|
||||
width: 569px;
|
||||
border-left: 1px solid #DDDDDD;
|
||||
padding-left: 30px;
|
||||
padding-bottom: 10px;
|
||||
}
|
||||
|
||||
nav ul {
|
||||
list-style: none;
|
||||
margin-top: 0px;
|
||||
padding-top: 0px;
|
||||
padding-left: 0px;
|
||||
}
|
||||
|
||||
.content-articles ul {
|
||||
padding-left: 20px;
|
||||
}
|
||||
|
||||
.content-section-header {
|
||||
font-variant: small-caps;
|
||||
padding-bottom: 10px;
|
||||
}
|
||||
277
templates/volume05_issue01/stylesheet.css
Normal file
277
templates/volume05_issue01/stylesheet.css
Normal file
|
|
@ -0,0 +1,277 @@
|
|||
/* This always shows the right hand scroll bar. This is necessary because every article
|
||||
scrolls vertically and has the bar, but the index page does not. Whether the bar is
|
||||
present affects page centering, and placement of the nav bar down the bottom. If the
|
||||
page centering changes between pages, then the nav bar shifts under the mouse. */
|
||||
html {
|
||||
overflow-y: scroll;
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: 'PTSZ';
|
||||
src: url('_fonts/ProggyTinySZ.ttf#ProggyTinyTTSZ') format('truetype'); /* Chrome */
|
||||
src: url('_fonts/ProggyTinySZ.ttf') format('truetype'); /* IE 10 */
|
||||
}
|
||||
|
||||
@keyframes blink {
|
||||
0% { background-color: black; }
|
||||
50% { background-color: #00FF00; }
|
||||
100% { background-color: black; }
|
||||
}
|
||||
@-webkit-keyframes blink {
|
||||
0% { background-color: black; }
|
||||
50% { background-color: #00FF00; }
|
||||
100% { background-color: black; }
|
||||
}
|
||||
@-moz-keyframes blink {
|
||||
0% { background-color: black; }
|
||||
50% { background-color: #00FF00; }
|
||||
100% { background-color: black; }
|
||||
}
|
||||
@-o-keyframes blink {
|
||||
0% { background-color: black; }
|
||||
50% { background-color: #00FF00; }
|
||||
100% { background-color: black; }
|
||||
}
|
||||
|
||||
.pagetitle-cursor {
|
||||
/* Time moved from realistic 1.5s to 10s, to prevent Griatch from being made ill from blinking. */
|
||||
animation: blink 10s steps(1) infinite;
|
||||
-webkit-animation: blink 10s steps(1) infinite;
|
||||
-moz-animation: blink 10s steps(1) infinite;
|
||||
-o-animation: blink 10s steps(1) infinite;
|
||||
}
|
||||
|
||||
* {
|
||||
background-color: #FFFFFF;
|
||||
font-family: Verdana, Trebuchet, Times New Roman, Arial;
|
||||
font-size: 10pt;
|
||||
}
|
||||
|
||||
a {
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.global nav a {
|
||||
border-style: solid;
|
||||
border-width: 1px;
|
||||
border-color: #777;
|
||||
color: black;
|
||||
background-color: #eee;
|
||||
text-decoration: none;
|
||||
padding: 1px 3px;
|
||||
margin: 1px 3px;
|
||||
line-height: 24px;
|
||||
display: inline-block;
|
||||
min-width: 510px;
|
||||
border-radius: 5px;
|
||||
}
|
||||
|
||||
.global nav div ul a {
|
||||
min-width: 490px;
|
||||
}
|
||||
|
||||
.floating-box-button a {
|
||||
border-style: solid;
|
||||
border-width: 1px;
|
||||
border-color: #777777;
|
||||
color: black;
|
||||
background-color: #DDDDDD;
|
||||
text-decoration: none;
|
||||
padding: 2px 5px 2px 5px;
|
||||
line-height: 24px;
|
||||
}
|
||||
|
||||
.global nav a:hover, .floating-box-button a:hover {
|
||||
color: white;
|
||||
background-color: green;
|
||||
}
|
||||
|
||||
.pagetitle, .pagetitle a, .pagetitle-cursor, .pagetitle-cursor-off {
|
||||
font-family: 'PTSZ', Courier New;
|
||||
line-height: 70px;
|
||||
font-size: 64pt;
|
||||
}
|
||||
|
||||
.pagetitle, .pagetitle a {
|
||||
max-width: 800px;
|
||||
text-align: center;
|
||||
margin: 0 auto;
|
||||
margin-bottom: 20px;
|
||||
padding: 10px 0px 10px 0px;
|
||||
background-color: black;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.main * {
|
||||
text-align: justify;
|
||||
}
|
||||
|
||||
main, .main {
|
||||
position: relative;
|
||||
max-width: 800px;
|
||||
margin: 0 auto;
|
||||
padding-bottom: 50px; /* Space for fixed nav bar. */
|
||||
}
|
||||
|
||||
.page-controls {
|
||||
position: absolute;
|
||||
bottom: 0;
|
||||
right: 0;
|
||||
width: 80px;
|
||||
border-style: dashed;
|
||||
border-width: 1px;
|
||||
border-color: darkgrey;
|
||||
}
|
||||
|
||||
|
||||
.page-controls-left, .page-controls-right, .page-controls-detail {
|
||||
float: left;
|
||||
height: 100%;
|
||||
text-align: center;
|
||||
font-size: 8pt;
|
||||
}
|
||||
|
||||
.page-controls-left {
|
||||
vertical-align: middle;
|
||||
width: 16px;
|
||||
}
|
||||
|
||||
.page-controls-detail {
|
||||
width: 48px;
|
||||
}
|
||||
|
||||
.page-controls-right {
|
||||
width: 16px;
|
||||
}
|
||||
|
||||
.next-page-control {
|
||||
position: absolute;
|
||||
bottom: 10;
|
||||
right: 0;
|
||||
}
|
||||
|
||||
.next-page-control a {
|
||||
font-size: 12pt;
|
||||
}
|
||||
|
||||
.floating-box {
|
||||
position: fixed;
|
||||
/* Center the box at the bottom of the screen. */
|
||||
bottom: 0px;
|
||||
left: 50%;
|
||||
right: 25%;
|
||||
width: 300px;
|
||||
margin-left: -150px;
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
.floating-box-table {
|
||||
border: dashed 1px #AAAAAA;
|
||||
}
|
||||
|
||||
.floating-box-table * {
|
||||
background-color: #EEEEEE;
|
||||
}
|
||||
|
||||
.floating-box-tr {
|
||||
right: 20px;
|
||||
top: 20px;
|
||||
}
|
||||
|
||||
.floating-box-br {
|
||||
}
|
||||
|
||||
.floating-box-button {
|
||||
margin: 5px 5px 5px 5px;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.unlinked-button {
|
||||
padding: 3px 7px 3px 7px
|
||||
}
|
||||
|
||||
.page-back {
|
||||
}
|
||||
|
||||
.page-forward {
|
||||
}
|
||||
|
||||
aside {
|
||||
float: right;
|
||||
margin-left: 18px;
|
||||
padding: 5px;
|
||||
border: 1px solid black;
|
||||
border-radius: 8px;
|
||||
max-width: 250px;
|
||||
}
|
||||
|
||||
aside, aside * {
|
||||
background-color: #eee;
|
||||
}
|
||||
|
||||
aside dt {
|
||||
font-style: italic;
|
||||
font-weight: bold;
|
||||
margin-top: 15px;
|
||||
margin-bottom: 3px;
|
||||
font-size: 9pt;
|
||||
}
|
||||
|
||||
aside dd {
|
||||
text-align: right !important;
|
||||
font-size: 8pt;
|
||||
margin-left: 20px;
|
||||
}
|
||||
|
||||
aside h4 {
|
||||
margin-top: 0;
|
||||
font-variant: small-caps;
|
||||
}
|
||||
|
||||
.midbar {
|
||||
overflow: hidden;
|
||||
height: 1px;
|
||||
width: 30%;
|
||||
align: center;
|
||||
border-bottom: 1px dashed grey;
|
||||
}
|
||||
|
||||
.inline-blocks h4 {
|
||||
display: block;
|
||||
clear: both;
|
||||
}
|
||||
|
||||
.inline-blocks img {
|
||||
display: inline;
|
||||
float: right;
|
||||
}
|
||||
|
||||
.gametitle, .publicationtitle {
|
||||
font-style: italic;
|
||||
}
|
||||
|
||||
.softwaretitle, .website {
|
||||
}
|
||||
|
||||
.reddit-link, .reddit-link-offline {
|
||||
margin-top: 30px;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.reddit-link-offline {
|
||||
margin: 0 auto;
|
||||
margin-top: 30px;
|
||||
max-width: 200px;
|
||||
}
|
||||
.reddit-link-offline img {
|
||||
vertical-align: middle;
|
||||
float: inherit;
|
||||
}
|
||||
|
||||
.reddit-link-offline a {
|
||||
target-new: tab;
|
||||
}
|
||||
|
||||
.clear {
|
||||
clear:both;
|
||||
}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
157
templates/volume05_issue01/well-built-zone-work-art/index.html
Normal file
157
templates/volume05_issue01/well-built-zone-work-art/index.html
Normal file
|
|
@ -0,0 +1,157 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
A well built zone is a work of art
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Molly O’Hara, 8th October 2013
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<h3>Not everyone is cut out to be a Builder</h3>
|
||||
<p>
|
||||
Anyone can slap on a badge that says “Builder” and learn the mechanics of <a href="http://en.wikipedia.org/wiki/Online_creation">OLC</a>. Very few have the stamina to actually finish their project; I think the general rate is about 5 percent. Even fewer manage to produce something really good, not just another rehash of some hack'n'slash zone that they played in some other MUD.
|
||||
</p>
|
||||
<p>
|
||||
Once it comes down to actually building the zone, you need to be organized and have lots of stamina to see the project through. Above all, though, a good Builder needs creativity, imagination, and a way with words. Some of what follows will be specific to MUDs similar to my home MUD, <a class="gametitle" href="http://4dimensions.org/">4Dimensions</a>, but these core qualities are universal.
|
||||
</p>
|
||||
<h3>Mapping the zone</h3>
|
||||
<p>
|
||||
The first step in building a zone is usually to make a map of it. The map provides two things: an overview of all the rooms included, and a check that their linking is logical. This is very important; every zone should be mappable on graph paper unless there’s an established reason that’s not the case. Even then, you need to put some consideration into how you link the rooms; you cannot just make a jumble of the exits. If you type ”<span class="code">look west</span>” in a room and see yourself a few rooms away, that is a dead give-away of bad mapping.
|
||||
</p>
|
||||
<h3>The zone needs a good story</h3>
|
||||
<p>
|
||||
The next step is to flesh out your original idea for the zone into a full background story, with a plot. You can write this down like you would a novel, then use it as a reference, with bits and pieces used to set up the right atmosphere in a room, in the description of a character or object, or as the theme for one or several built-in quests.
|
||||
</p>
|
||||
<p>
|
||||
Like a novel, a good zone needs to have a theme — a reason for existing — and everything in the zone needs to be consistent with that theme. This means <em>everything</em> in the zone — the time period, the terrain, the vegetation, the wildlife, the architecture, the inhabitants, the clothes, the weapons. No laser guns or cowboys in a medieval fantasy setting, or sudden swings between steamy jungle and icy tundra, and if the MUD has a general theme, everything needs to be consistent with that too.
|
||||
</p>
|
||||
<h3>Interacting with the zone</h3>
|
||||
<p>
|
||||
Creating a zone for a text MUD is a bit like writing a novel, but a MUD is interactive. In a way it is more complex, since you cannot just write the text down in one sequence, like you do with a novel; it needs to be chopped up in small pieces, suitable to fit into a room. In addition to writing the room descriptions, you need to consider the objects that can be picked up or interacted with in different ways, and the characters that move in and interact with the environment. On top of that, you have the scripts, which really bring life to the zone: characters that talk and answer questions, messages that bring atmosphere to the environment, obstacles and puzzles for the player to overcome and solve.
|
||||
</p>
|
||||
<p>
|
||||
All of this has to work together in every room to create an image of reality — or of a convincing fantasy setting. However, in a MUD there is also the scrolling text that appears continuously: when someone enters or leaves the room, performs an action or uses the global channels, and above all, the potentially overwhelming flow of messages when a fight is going on. The scrolling text makes the MUD come to life, but also adds to the spam on the player's screen, which has to be considered when you decide on the amount of information a room can contain.
|
||||
</p>
|
||||
<h3>The ideal length of the room description depends on the environment</h3>
|
||||
<p>
|
||||
Another thing that you need to consider is how things look when you move around. There is a big difference between a “travel zone” — an environment that you basically move through to get somewhere else — and a “goal zone”, where you are expected to remain for some time. For a travel zone to look good when you walk around in it, the room descriptions should be of even length and fairly short — two to four lines are ideal. Once you have reached a destination, be it a castle, a tavern or just a hidden cave behind some bushes, the room description can be longer and more detailed, since you expect the player to pay a bit more attention in an environment like that.
|
||||
</p>
|
||||
<p>
|
||||
Even in goal zones, there still is a limit to how long the room description should be. Spam is something you should always avoid in a zone. To me, seven lines is the maximum; any detail needed beyond that should be left to descriptions of the room’s contents. There are some builders — especially those who have attended classes in creative writing — who tend to go overboard with long, flowery descriptions. In doing so, they shoot themselves in the foot, since a MUD is not a bedside novel but an interactive game, and in less roleplay-oriented games, the majority of the players are really just out to kill monsters and pick up whatever good equipment they can find to make it easier to kill those monsters. So if the descriptions are too long, they will just engage brief mode and never see the lovely prose that you put so much work into.
|
||||
</p>
|
||||
<h3>Adding depth and detail</h3>
|
||||
<p>
|
||||
You do also want to cater to those that treat your zone like an interactive novel, actually reading everything they come across. This elite group of players is really why we put all that extra work into a zone. So now you utilize all the descriptive capabilities provided in your OLC. Ideally, there should be a description for every noun in the main room description. You can also put detailed descriptions on all <em>directions</em>, not just the directions you can walk in. In some MUDs, like the one I work for, there are also descriptions for <em>listen, smell, taste</em> and <em>feel</em>, and different room descriptions for daytime, nighttime, different seasons, and various weather conditions.
|
||||
</p>
|
||||
<p>
|
||||
Naturally, all characters and objects should have description too, preferably something interesting that relates to the theme of the zone or some quest that the player is expected to solve. This is where your background story starts to become useful. You can describe a character in ways that give hints of its capabilities and nature, not just what it looks like. You can make love letters to hide in drawers or caches, and even books that can be read by looking at the index, and then at chapter 1, chapter 2, and so on. Not everyone might bother to read those books at first, but if the information that you get that way is vital for solving a quest, they will soon start doing it.
|
||||
</p>
|
||||
<h3>Adding challenges</h3>
|
||||
<p>
|
||||
All this is still elementary. For a zone to be excellent, there also needs to be some kind of challenge, something more than just a really tough boss monster to kill. This is where <em>scripts</em> and <em>quests</em> come in. This is also where you can really use your background story — the logical thing to do is turn the plot into the basis for a main quest, usually carried out in several steps. The zone can also contain a number of mini-quests, where players can collect experience, gold, quest points, tokens, or currency by doing various tasks. These smaller tasks can be parts of the main quest or totally independent, but all of them should be in-theme, and also repeatable, to give the players an extra motivation to return to the zone — but for a lesser reward each time, since a quest is only really hard the first time you do it.
|
||||
</p>
|
||||
<p>
|
||||
There are basically three main ways to finish a character-driven quest in a MUD:
|
||||
</p>
|
||||
<ol>
|
||||
<li>give the character a specific item</li>
|
||||
<li>kill some other character and bring proof of it</li>
|
||||
<li>bring another character to it, perhaps a missing child or spouse</li>
|
||||
</ol>
|
||||
<p>
|
||||
Nearly every quest you encounter in any MUD is a variation on these three. Whether a quest is good or bad depends on how it is designed. Here, we get back to the theme and background story of the zone. How interesting, entertaining, and challenging a quest becomes depends equally on the quality of the plot and on how well the scripts are set up.
|
||||
</p>
|
||||
<h3>Don't spam the players</h3>
|
||||
<p>
|
||||
You can do almost anything conceivable with scripts — the only real limit is your imagination. This is really a subject for another article, because writing good and cheat-proof quest scripts is an art in itself. Before we leave the subject of scripts, though, let me add a warning about a trap that too many new builders fall into — SPAM.
|
||||
</p>
|
||||
<p>
|
||||
Scripts are often used to create a certain atmosphere in a zone — a sudden rustle in the leaves behind your back, a character who welcomes you into their house, a stray dog starting to follow you, that sort of thing. These are good additions to a zone as long as the scripts don't go off too often, in which case it soon becomes irritating instead. So, if you use a random trigger to set off the script, make sure that the chance of the script triggering isn't set too high. Also, be wary of “greet” or “entry” scripts that trigger every time someone enters the room. Remember that players often run back and forth several times when exploring a zone, and that non-player characters can trigger a script too, unless you take precautions against it.
|
||||
</p>
|
||||
<h3>Making it harder for the players</h3>
|
||||
<p>
|
||||
There are several tricks that you can use to make a zone harder beyond just raising the number and/or level of the monsters. You can, for instance, make a character or object that the player needs to find rather hard to get to. This can be achieved in many ways.
|
||||
</p>
|
||||
<p>
|
||||
The most obvious way is using a maze (which I'm not overly fond of, myself). Most MUD code also support hidden exits, but seasoned players quickly learn to type <span class="code">search</span> a couple of times in each room, and then the secret door isn't a secret any more.
|
||||
</p>
|
||||
<p>
|
||||
Portals (objects that transport you based on a specific command) are better, because they can be prevented from appearing in the room’s contents, so the player will have to read the descriptions in the room thoroughly to find out if there is a hidden portal in the room and how to enter it. For example, let’s say looking west provides the following description:
|
||||
</p>
|
||||
<p class="quotetext">
|
||||
“An embroidered tapestry hangs on the west wall.”
|
||||
</p>
|
||||
<p>
|
||||
<span class="code">look tapestry</span> gives the result:
|
||||
</p>
|
||||
<p class="quotetext">
|
||||
“The tapestry depicts a maiden sitting in a field of flowers. It hangs slightly askew.”
|
||||
</p>
|
||||
<p>
|
||||
<span class="code">look behind tapestry</span> finally gives:
|
||||
</p>
|
||||
<p class="quotetext">
|
||||
“Behind the tapestry is a secret passageway.”
|
||||
</p>
|
||||
<p>
|
||||
The command <span class="code">enter secret passageway</span> then moves the PC to a new location.
|
||||
</p>
|
||||
<p>
|
||||
The same method can be used for hidden containers. After looking around a bit in the room, you might discover that there is a king-size bed against the east wall. The command <span class="code">look bed</span> may just give a description of the sheets and pillows, but <span class="code">look under bed</span>
|
||||
could reveal a chamber pot, which in turn might contain something more interesting than the usual.
|
||||
</p>
|
||||
<p>
|
||||
This can be varied in many ways. The trick is to not choose too-obvious names for the portal or container, since experienced players learn to routinely type things like <span class="code">enter hole</span> or <span class="code">get all from hole</span> each time they find a new room, if they notice a pattern in the aliases used. However, you also need to be fair and provide a clue to the identity of the hidden objects so that players don't need to resort to <a href="http://en.wikipedia.org/wiki/Syntax_guessing">noun or verb guessing</a>. The rule in my MUD is that if there is an object in a room that the players need to interact with and that doesn’t appear in the room’s contents, the name needed to address it it must also be mentioned in one of the room descriptions.
|
||||
</p>
|
||||
<p>
|
||||
You can also use gadgets like a sturdy safe with a combination lock. Figuring out the combination could be as simple as finding a note with some digits on it or as involved as talking to many NPCs in order to find out the name of the owner's pet dog.
|
||||
</p>
|
||||
<p>
|
||||
If you want to be even more subtle, you can use things like a mithril inscription on a stone wall that only becomes visible at midnight or when hit by the light of the full moon, or fruits and berries that only ripen in autumn. (This means that the code of your MUD must support things like day and night descriptions, seasons and moon phases. If it doesn't, you need to pester your coders until they add it.)
|
||||
</p>
|
||||
<h3>Balanced rewards</h3>
|
||||
<p>
|
||||
Finally, we get to quest rewards.
|
||||
</p>
|
||||
<p>
|
||||
All Builders want their zones to be popular, and the easiest way to achieve that is to add a piece of overpowered equipment and hope that it slips through quality control.
|
||||
</p>
|
||||
<p>
|
||||
Don't fall for this easy trick. Overpowered equipment might make your zone popular, at least until every player has collected the item, but it doesn't make it a good zone. On the contrary, it makes it a bad one, since it upsets the balance of the entire MUD.
|
||||
</p>
|
||||
<p>
|
||||
The reward can't be too small, either. If the players need to go through a long and elaborate quest to finally get to the reward, they will feel cheated if they don't find it worth the effort.
|
||||
</p>
|
||||
<p>
|
||||
There are two main rules for making rewards:
|
||||
</p>
|
||||
<ol>
|
||||
<li>If a reward is a weapon or piece of equipment, its quality should be in proportion to how hard it is to get.</li>
|
||||
<li>If the reward is gold, experience, trade points, or quest tokens, it needs to be substantially higher the first time you do a quest and then become lower for each repetition.</li>
|
||||
</ol>
|
||||
<h3>Summary</h3>
|
||||
<p>
|
||||
So to sum this up: what constitutes a really good zone? Below is my own list:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Consistency with theme</li>
|
||||
<li>Good background story</li>
|
||||
<li>Logical linking (unless justified otherwise)</li>
|
||||
<li>Appropriate length of descriptions</li>
|
||||
<li>Detail and depth</li>
|
||||
<li>Challenges and puzzles</li>
|
||||
<li>Nifty gadgets and tricks</li>
|
||||
<li>Balanced rewards</li>
|
||||
<li>Correct spelling, grammar, and punctuation</li>
|
||||
<li>No spammy scripts</li>
|
||||
<li>No buggy scripts</li>
|
||||
</ul>
|
||||
<p>
|
||||
As you can see, I've put three rather important points at the bottom of my list. Why?
|
||||
</p>
|
||||
<p>
|
||||
Because nothing can replace a writer's creativity and imagination, and the way things are designed to interact in each room, but a good Head Builder can run the files through a spellchecker and fix up the bad scripts. Sometimes it’s a good idea to handle the last three items that way, as a way of avoiding having the Head Builder be too nitpicky in feedback to other Builders.
|
||||
</p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Molly O'Hara is the Zone Coordinator and Administrator of Game Architecture and Design for <a class="gametitle" href="http://4dimensions.org/">4Dimensions</a>.
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
|
|
@ -0,0 +1,188 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
A Journey Through Paradice, Part II
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
by Matthew Chaplain, 11th January 2014
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p><span>In the</span> <span>first</span> <span class="c10"><a class="c6" href=
|
||||
"http://journal.imaginary-realities.com/volume-05/issue-01/journey-through-paradice/index.html">article</a></span><span> of
|
||||
this series</span><span>, I described a series of events that led to the creation of a character-based GUI-style
|
||||
output, using a larger-than-usual set of the ANSI escape codes.</span></p>
|
||||
|
||||
<div class="imgcenter">
|
||||
<img class="center" src="images/image01.png" width="624"/>
|
||||
</div>
|
||||
<div class="imgcaption" style="max-width: 602px; margin-left: auto; margin-right: auto">
|
||||
Paradice 9 Login Screen
|
||||
</div>
|
||||
|
||||
<p><span>Continuing with the theme, this article will discuss the advantages of this output style, and the
|
||||
design and protocols that</span> <span class="c10"><a class="softwaretitle" href=
|
||||
"https://code.google.com/p/paradice9/">Paradice</a></span><span> (a codebase for writing Telnet-based
|
||||
applications with which the Paradice 9 server is built) uses to achieve it.</span></p>
|
||||
|
||||
<p><span>As mentioned in the original article,</span> <span class="c10"><a class="c6" href=
|
||||
"http://www.ietf.org/rfc/rfc857.txt">character-at-a-time mode</a></span><span> is engaged by enabling</span>
|
||||
<span class="code">WILL ECHO</span><span> and</span> <span class="code">WILL SUPPRESS_GO_AHEAD</span><span> via
|
||||
the Telnet protocol. Before explaining the design of Paradice's user interface, a recap of some of the concrete
|
||||
problems solved by this output style:</span></p>
|
||||
|
||||
<div class="imgcenter">
|
||||
<img class="center" src="images/image00.png" width="624"/>
|
||||
</div>
|
||||
<div class="imgcaption" style="max-width: 602px; margin-left: auto; margin-right: auto">
|
||||
Stock Envy MUD
|
||||
</div>
|
||||
|
||||
<ul class="c1 lst-kix_d0sm8pxgvkdb-0 start">
|
||||
<li class="c2 c11">Interrupted commands<br/>
|
||||
<br/>
|
||||
The very first complaint I received on my initial implementation of Paradice 9 was that, if a player was typing a
|
||||
command, and something on the MUD occurred that caused output to be sent to that player, it would appear in the
|
||||
middle of the command being written. When you have control over the output, this issue vanishes.<br/>
|
||||
<br/>
|
||||
This very issue has probably inspired more MUD clients than any other.<br/><br/></li>
|
||||
<li class="c2 c11"><span>Prompt spamming<br/>
|
||||
<br/>
|
||||
On a DIKU-derived MUD I once played, a new prompt, typically containing data about the characters such as health
|
||||
and magic points, would be sent every time anything happened to the character. Very helpful, especially in combat
|
||||
situations.<br/>
|
||||
<br/>
|
||||
However, a character would have to go to “sleep” in order to regenerate health. A lot less input is
|
||||
displayed in this state, and this meant that characters would frequently oversleep</span> <span class=
|
||||
"c0">—</span><span> they did not know when their character was fully rested. Eventually, a change came
|
||||
that caused a new prompt to be displayed when a sleeping character reached maximum health, but that was of no use
|
||||
to those who only wanted to be “healthy-enough” (say, 75% health), or wanted maximum magic points. For
|
||||
those people, the de facto solution was to tap the enter key every few seconds, filling the screen with new
|
||||
prompts.<br/>
|
||||
<br/>
|
||||
This kind of prompt spamming is terrible from a user interface perspective. And why, in this day and age, do we
|
||||
accept the status quo of having several prompts on the screen at once, most having out-of-date
|
||||
information?<br/><br/></span></li>
|
||||
<li class="c2 c11"><span>Disorganized, linear output<br/>
|
||||
<br/>
|
||||
You’re in a heated battle, and information is spewed past you at an enormous rate. Someone sends you a
|
||||
message. The battle continues, and the only way you can retrieve that message is to look carefully through the
|
||||
client’s scroll-back to see if you can find it. If you’re lucky, it will be colour-coded.<br/>
|
||||
<br/>
|
||||
With a better interface control, several solutions present themselves. For example, having separate windows, or
|
||||
even a tabbed display where the combat text and social text are segregated.<br/><br/></span></li>
|
||||
<li class="c2 c11"><span>Mis-aimed replies<br>
|
||||
<br>
|
||||
I think everyone must have done this. You’re having a conversation with a friend, and type</span>
|
||||
<span class="command">r Yeah, Biffo, you’re right. Bubba *is* a bit of a butthead</span><span>.  In this
|
||||
command,</span> <span class="command">r</span><span> is a shorthand for</span> <span class="command">reply</span><span>,
|
||||
which causes a whisper or tell to be sent to the last person who sent you a message.<br>
|
||||
<br>
|
||||
Just as you’re hitting enter, Bubba sends you a message. The reply is sent to Bubba instead. Hilarity
|
||||
ensues.<br>
|
||||
<br>
|
||||
This problem is impossible to solve from the server side with line-mode, because the server does not receive the
|
||||
information that you plan to reply until the command is being sent. Thus, the target of the reply is bound at the
|
||||
time the command is complete, and not at the type you type the first</span> <span class="command">r</span><span>.<br>
|
||||
<br>
|
||||
In a character-based exchange, a note (e.g. “Replying to: Biffo”) could be made somewhere at the time
|
||||
that you first tap</span> <span class="command">r</span><span>, or the server could just wholesale replace</span>
|
||||
<span class="command">r</span><span> with “tell biffo” on the command line. Either way, this means that
|
||||
the reply target can be locked in place from the moment</span> <span class="command">r</span><span> is pressed and
|
||||
for the duration of the reply.</span></li>
|
||||
</ul>
|
||||
|
||||
<p><span>As you can see, there are many benefits to this style of display. There are also disadvantages,
|
||||
of course, and the most immediate of those is complexity. It is many times more complex to produce a GUI display
|
||||
than</span> <span class="code">send_to_char(ch, stuff_that_just_happened);</span><span>.</span> <span>Nevertheless, it
|
||||
can give a very satisfying result.</span></p>
|
||||
|
||||
<p><span>The fundamental design of the user interface renderer in Paradice 9 is based around one guiding
|
||||
question: given the current state of the screen and a desired state that we would like to put the screen in, what is
|
||||
the smallest amount of data (using the ANSI protocol) that describes the change between the two states? The answer to
|
||||
this question is the sequence of characters that is sent to the client so that it can render the output
|
||||
required.</span></p>
|
||||
|
||||
<p><span>Before working on the exact algorithm, it is necessary to explain what a screen looks like to the
|
||||
program. In Paradice, a screen is represented by a grid of elements. The grid is initially 80x24, since that is the
|
||||
default screen size of nearly every terminal emulator ever, and is the assumed width and page size of many MUDs, but
|
||||
it can be negotiated by using Telnet</span> <span class="c10"><a class="c6" href=
|
||||
"http://www.ietf.org/rfc/rfc1073.txt">NAWS</a></span><span>. The grid is 1-based, and extends in the positive
|
||||
direction downwards, meaning the very top left character is at position [1,1].</span></p>
|
||||
|
||||
<p><span>Each element is a two-part structure comprising a glyph and an attribute. The glyph part contains
|
||||
information about the character to be drawn, including character set, locale, and actual character to write. The
|
||||
attribute part describes how to draw the glyph: foreground and background colours, intensity (bolding), underlining,
|
||||
and so on.</span></p>
|
||||
|
||||
<p><span>Between the screen abstraction and the element abstraction there are a number of components that
|
||||
describe widgets on the screen</span> <span class="c0">—</span><span> text areas, ASCII art
|
||||
"images" and the like. Precipitated by in-game events such as another player saying something or sending a
|
||||
message, or input events such as cursor keys or mouse clicks, the components update their internal states and request
|
||||
that they be redrawn. These redraw requests also contain information about the "regions" (rectangular
|
||||
areas) that need to be redrawn. These requests are not processed immediately; they are collected and coalesced by the
|
||||
screen abstraction for when the next redraw cycle occurs. The exact nature of the redraw cycle scheduler is not
|
||||
important here, but it is important to have this occur frequently enough for the user interface to feel
|
||||
responsive.</span></p>
|
||||
|
||||
<p><span>During the redraw cycle, a clone of the current state of the screen is created and the screen is
|
||||
asked to draw itself onto the clone in the regions requested. The difference between the two screen states is now
|
||||
known, but there remains one more step before generating protocol data: it's possible that some of the data in
|
||||
the redraw regions has not actually changed. Since, except for certain niche cases, it's unlikely that we want to
|
||||
generate protocol data to draw out exactly what is already on the screen, the redraw regions need to be trimmed down
|
||||
to only those parts of the screen that actually differ between the current state and the clone.</span></p>
|
||||
|
||||
<p><span>The result of this operation yields a series of non-overlapping rectangles, each with non-zero
|
||||
width and a height of 1, which describe the areas that require protocol data to be sent. Paradice refers to these as
|
||||
"slices".</span></p>
|
||||
|
||||
<p><span>With this information now known, the algorithm to generate protocol data goes something like
|
||||
this, with references to the necessary</span><span> </span><span class="c10"><a class="c6" href=
|
||||
"http://invisible-island.net/xterm/ctlseqs/ctlseqs.html">terminal</a></span><span class="c10"><a class="c6" href=
|
||||
"http://invisible-island.net/xterm/ctlseqs/ctlseqs.html"> commands</a></span><span> embedded
|
||||
therein:</span></p>
|
||||
|
||||
<ol start="1" type="1">
|
||||
<li class="c2 c11"><span>If the cursor was enabled, disable the cursor (</span><span class=
|
||||
"code">DECTRST/DECTCEM</span><span>). This prevents the visual effect of the cursor position flickering around the
|
||||
screen as parts are redrawn.</span></li>
|
||||
<li class="c7"><span>For each slice,</span>
|
||||
<ol start="1" type="a">
|
||||
<li class="c2 c14"><span>Move the cursor to the left-most coordinate of the slice (</span><span class=
|
||||
"code">CUP</span><span>).</span></li>
|
||||
<li class="c2 c14"><span>If this is also on a new line, generate protocol for setting the character attributes to
|
||||
default and set the "current" character attributes to the default (</span><span class=
|
||||
"code">SGR</span><span>).</span></li>
|
||||
<li class="c2 c14"><span>For each element in the slice,</span>
|
||||
<ol type="i">
|
||||
<li class="c2 c12"><span>Generate protocol for setting the current character attributes to the current
|
||||
element's attributes, and store this new set in the current character attributes (</span><span class=
|
||||
"code">SGR</span><span>).</span></li>
|
||||
<li class="c2 c12"><span>Write the current element's character.</span></li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
</li>
|
||||
<li class="c2 c11"><span>If the cursor was enabled, move to the current cursor position and enable the cursor
|
||||
(</span><span class="code">DECTSET/DECTCEM</span><span>).</span></li>
|
||||
</ol>
|
||||
|
||||
<p><span>It's worth noting that there is a lot of room for optimization here, both in code speed and
|
||||
protocol output. For example, point 2a may involve a</span> <span class="code">CUP</span><span> (Cursor Position)
|
||||
command, or a</span> <span class="code">CUF</span> <span>(Cursor Forward) command, or may be just as simple as writing
|
||||
over a couple of existing characters, if their attributes happen to match the current attribute set. Possible
|
||||
optimizations for getting the cursor from one position to another could also be generated speculatively, with all but
|
||||
the shortest exchange being discarded.</span></p>
|
||||
|
||||
<p><span>Also of interest is point 2ci. At the time of writing, all attribute exchanges in Paradice assume
|
||||
that the attribute set starts at default, which overcomes an unexplored incompatibility with <span="softwaretitle">TeraTerm</span>.</span></p>
|
||||
|
||||
<p><span>By following this layout, it is possible to generate some high quality textual output for a MUD.
|
||||
There remain many areas for improvement. For example, negotiating for and adding the capability for outputting
|
||||
Unicode characters would greatly add to the output possibilities. The story does not end here, however. The Paradice
|
||||
codebase also supports and recognises an extended set of input methods, including control keys such as</span>
|
||||
<span class="c3">PgUp/PgDn</span><span> and the numeric keypad, a limited set of function keys, and mouse
|
||||
clicks. These subjects will be the topic of a future article.</span></p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Matthew Chaplain, known in the mudding community as Kastagaar or Kaz, is a professional C++ software developer who tinkers on the <a class="softwaretitle" href=
|
||||
"https://code.google.com/p/paradice9/">Paradice</a> codebase in his spare time. Comments, criticism, and code submissions are all welcome.
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
286
templates/volume06_issue01/building-a-mech-in-evennia/index.html
Normal file
286
templates/volume06_issue01/building-a-mech-in-evennia/index.html
Normal file
|
|
@ -0,0 +1,286 @@
|
|||
{% extends "issue/article/index.html" %}
|
||||
{% block page_title %}
|
||||
Building a Giant Mech in Evennia
|
||||
{% endblock %}
|
||||
{% block article_byline %}
|
||||
<span style="font-size: 10pt; font-style: italic">Because everybody should have one</span><br/>
|
||||
by Griatch, 25th January 2014
|
||||
{% endblock %}
|
||||
{% block article_content %}
|
||||
<p class="rcaptionblock"><img height="287" src="images/image00.jpg" width="203"><br/>
|
||||
<span style="font-style: italic"><br/>image from <a class="c20" href="http://griatch-art.deviantart.com">griatch-art.deviantart.com</a></span></p>
|
||||
|
||||
<p class="c13 c8"><span>Let us create a functioning giant</span> <span class="c16"><a class="c20" href=
|
||||
"http://en.wikipedia.org/wiki/Mecha">mech</a> using the Python MUD-creation system</span> <span class="c16"><a class="softwaretitle"
|
||||
href="http://www.evennia.com/">Evennia</a></span><span>. Everyone likes a giant mech, right?</span></p>
|
||||
|
||||
<p class="code">> @create/drop Giant Mech ; mech</p>
|
||||
|
||||
<p class="c13 c8"><span>Boom. We created a</span> <span class="c15">Giant
|
||||
Mech</span><span> </span><span class="code">Object</span><span> and dropped it in the room. We also gave it
|
||||
an alias</span> <span class="c15">mech</span><span>. Let’s describe it.</span></p>
|
||||
|
||||
<p class="code">> @desc mech = This is a huge mech. It has missiles and stuff.</p>
|
||||
|
||||
<p class="c13"><span>Next we define who can “puppet” the mech object.</span></p>
|
||||
|
||||
<p class="code">> @lock mech = puppet:all()</p>
|
||||
|
||||
<p class="c13 c8"><span>This makes it so that everyone can control the mech. More mechs to the people!
|
||||
(</span><span>Note that whereas <span class="softwaretitle">Evennia’s</span> default commands may look vaguely MUX-like, you can change the
|
||||
syntax to look like whatever interface style you prefer.)</span></p>
|
||||
|
||||
<p class="c13 c8"><span>Before we continue, let’s make a brief detour. <span class="softwaretitle">Evennia</span> is very flexible about its
|
||||
objects and even more flexible about using and adding commands to those objects. Here are some ground rules well
|
||||
worth remembering for the remainder of this article:</span></p>
|
||||
|
||||
<p class="c13 c4"></p>
|
||||
|
||||
<ul class="c18 lst-kix_ajhaw4j5v1t4-0 start">
|
||||
<li class="c10"><span class="code">Player</span><span> represents the real person logging in and has no game-world existence.</span></li>
|
||||
<li class="c10"><span>Any</span> <span class="code">Object</span><span> can be puppeted by a</span>
|
||||
<span class="code">Player</span><span> (with proper permissions).</span></li>
|
||||
<li class="c10"><span class="code">Characters</span><span>,</span> <span class=
|
||||
"code">Rooms,</span><span> and</span> <span class="code">Exits</span><span> are just children of
|
||||
normal</span> <span class="code">Objects.</span></li>
|
||||
<li class="c10"><span>Any</span> <span class="code">Object</span><span> can be inside another (except if it
|
||||
creates a loop).</span></li>
|
||||
<li class="c10"><span>Any</span> <span class="code">Object</span><span> can store custom sets of commands on
|
||||
it. Those commands can:</span>
|
||||
<ul class="c18 lst-kix_ajhaw4j5v1t4-1 start">
|
||||
<li class="c21 c13"><span>be made available to the puppeteer,</span></li>
|
||||
|
||||
<li class="c13 c21"><span>be made available to anyone in the same location as the</span> <span class=
|
||||
"code">Object</span><span>, and</span></li>
|
||||
|
||||
<li class="c21 c13"><span>be made available to anyone “inside” the</span> <span class=
|
||||
"code">Object</span></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="c10"><span>Also</span> <span class="code">Players</span><span> can store commands on
|
||||
themselves.</span><span class="code"> Player</span><span> </span><span>commands are always available
|
||||
unless commands on a puppeted</span> <span class="code">Object</span><span> explicitly override
|
||||
them.</span></li>
|
||||
</ul>
|
||||
|
||||
<p class="c13 c8"><span>In <span class="softwaretitle">Evennia</span>, using the</span> <span class="code">@ic</span><span> command will allow you
|
||||
to puppet a given object (assuming you have puppet-access to do so). As mentioned above, the bog-standard</span>
|
||||
<span class="code">Character</span><span> class is in fact like any</span> <span class="code">Object</span><span>:
|
||||
it is auto-puppeted when logging in and just has a</span> <span class="c15">command set</span> <span>on it
|
||||
containing the normal in-game commands, like</span> <span class="command">look</span><span>,</span> <span class=
|
||||
"command">inventory</span><span>,</span> <span class="command">get</span> <span>and so on.</span></p>
|
||||
|
||||
<p class="code">> @ic mech</p>
|
||||
|
||||
<p class="c13 c8"><span>You just jumped out of your</span> <span class=
|
||||
"code">Character</span><span> and</span><span> are n</span><span>ow the mech! If people look at you
|
||||
in-game, they will look at a mech. The problem at this point is that the mech</span> <span class=
|
||||
"code">Object</span><span> has no commands of its own. The usual things like</span> <span class=
|
||||
"command">look,</span><span> </span><span class="command">inventory</span> <span>and</span> <span class=
|
||||
"command">get</span><span> sat on the</span> <span class="code">Character</span><span> object, remember? So
|
||||
at the moment the mech is not quite as cool as it could be.</span></p>
|
||||
|
||||
<p class="code">> @ic <Your old Character></p>
|
||||
|
||||
<p class="c13 c8"><span>You just jumped back to puppeting your normal, mundane</span> <span class=
|
||||
"code">Character</span><span> again. All is well.</span></p>
|
||||
|
||||
<p class="c13 c8"><span>(But, you ask, where did</span> <span class=
|
||||
"c15">that</span><span> </span><span class="command">@ic</span><span> command come from, if the mech had no
|
||||
commands on it? The answer is that it came from the</span> <span class="code">Player</span><span>’s command
|
||||
set. This is important. Without the</span> <span class="code">Player</span><span> being the one with the</span>
|
||||
<span class="command">@ic</span><span> command, we would not have been able to get back out of our mech
|
||||
again.)</span></p>
|
||||
|
||||
<h3>Arming the mech</h3>
|
||||
|
||||
<p class="c13 c8"><span>Let us make the mech a little more interesting. In our favorite text editor, we will create
|
||||
some new mech-suitable commands. In <span class="softwaretitle">Evennia</span>, commands are defined as Python</span> <span class=
|
||||
"c15">classes</span><span>.</span></p>
|
||||
|
||||
<pre class="code">
|
||||
from ev import Command
|
||||
|
||||
class CmdShoot(Command):
|
||||
"""
|
||||
Firing the mech’s gun
|
||||
|
||||
Usage:
|
||||
shoot [target]
|
||||
|
||||
This will fire your mech’s main gun. If no
|
||||
target is given, you will shoot in the air.
|
||||
"""
|
||||
key = "shoot"
|
||||
aliases = ["fire", "fire!"]
|
||||
|
||||
def func(self):
|
||||
"This actually does the shooting"
|
||||
|
||||
caller = self.caller
|
||||
location = caller.location
|
||||
|
||||
if not self.args:
|
||||
# no argument given to command - shoot in the air
|
||||
message = “BOOM! The mech fires its gun in the air!”
|
||||
location.msg_contents(message)
|
||||
return
|
||||
|
||||
# we have an argument, search for target
|
||||
target = caller.search(self.args)
|
||||
if target:
|
||||
targetname = target.key
|
||||
message = "BOOM! The mech fires its gun at %s"
|
||||
location.msg_contents(message % targetname)
|
||||
</pre>
|
||||
|
||||
<p class="c13 c8"><span>This is saved as a normal Python module (let’s call it</span> <span class=
|
||||
"code">mechcommands.py</span><span>), in a place <span class="softwaretitle">Evennia</span> looks for such modules. This command will trigger when
|
||||
the</span> <span class="code">Player</span><span> gives the command “shoot”, “fire,” or
|
||||
even “fire!” with an exclamation mark. The mech can shoot in the air or at a target if you give one. In
|
||||
a real game the gun would probably be given a chance to hit and give damage to the target, but this is enough for
|
||||
now. We also make a second command for launching missiles (</span><span class="code">CmdLaunch</span><span>). To save
|
||||
space we won’t describe it here; it looks very similar.</span></p>
|
||||
|
||||
<p class="c13 c4"></p>
|
||||
|
||||
<p class="c13 c8"><span>Now we shove our commands into a</span> <span class="c15">command
|
||||
set</span><span> (</span><span class="command">cmdset</span><span>). This is a container holding any number of
|
||||
commands. The command set is what we will store on the mech.</span></p>
|
||||
|
||||
<pre class="code">
|
||||
from ev import CmdSet
|
||||
from ev import default_cmds
|
||||
|
||||
class MechCmdSet(CmdSet):
|
||||
"""
|
||||
This allows mechs to do do mech stuff.
|
||||
"""
|
||||
key = "mechcmdset"
|
||||
|
||||
def at_cmdset_creation(self):
|
||||
"Called once, when cmdset is first created"
|
||||
self.add(default_cmds.CharacterCmdSet)
|
||||
self.add(CmdShoot())
|
||||
self.add(CmdLaunch())
|
||||
</pre>
|
||||
|
||||
<p class="c7"><span>This simply groups all the commands we want. We even include the full contents of the
|
||||
default</span> <span class="code">CharacterCmdSet</span><span> in there. This will make a</span> <span class=
|
||||
"code">Character</span><span>’s normal commands available to the mech.</span></p>
|
||||
|
||||
<p class="c3 c4"></p>
|
||||
|
||||
<p class="c3 c8"><span>Let’s head back into the game. For testing we will attach our new</span> <span class=
|
||||
"command">cmdset</span><span> to the mech.</span></p>
|
||||
|
||||
<p class="c3 c4"></p>
|
||||
|
||||
<p class="c1"><span class="command">> @py
|
||||
self.search("mech").cmdset.add("mechcommands.MechCmdSet")</span></p>
|
||||
|
||||
<p class="c3 c4"></p>
|
||||
|
||||
<p class="c7"><span>This is a little Python snippet (run from the command line as an admin) that searches for the
|
||||
mech in our current location and attaches our new</span> <span class="code">MechCmdSet</span><span> to it. What
|
||||
we add is actually the</span> <span class="c15">Python path</span><span> to our cmdset class. <span class="softwaretitle">Evennia</span> will
|
||||
import and initialize it behind the scenes.</span></p>
|
||||
|
||||
<p class="c3 c4"></p>
|
||||
|
||||
<p class="command">> @ic mech</p>
|
||||
|
||||
<p class="c3 c8"><span>We are back as the mech! Let’s do some shooting!</span></p>
|
||||
|
||||
<p class="code">> fire!</p>
|
||||
|
||||
<p class="c1"><span class="c2">BOOM! The mech fires its gun in the air!</span></p>
|
||||
|
||||
<p class="c7"><span>There we go, one functioning mech. We can not only walk around as the mech</span> <span class=
|
||||
"c24">—</span><span> since the</span> <span class="code">CharacterCmdSet</span><span> is included in
|
||||
our</span> <span class="code">MechCmdSet</span><span>, the mech can also do everything a</span> <span class=
|
||||
"code">Character</span><span> could do, like look around, pick up stuff, and have an inventory. We could now
|
||||
shoot the gun at a target or try the missile launch command. Once you have your own mech, what else do you
|
||||
need?</span></p>
|
||||
|
||||
<h3>Making a mech production line</h3>
|
||||
|
||||
<p class="c7"><span>What we’ve done so far is just to make a normal</span> <span class=
|
||||
"code">Object,</span><span> describe it and put some commands on it. This is great for testing. The way we added
|
||||
it, the</span> <span class="code">MechCmdSet</span><span> will even go away if we reload the server. Now we want
|
||||
to make the mech an actual object “type” so we can create mechs without those extra steps. For this we
|
||||
need to create a new</span> <span class="code">Typeclass</span><span class="c15">.</span></p>
|
||||
|
||||
<p class="c12 c4"></p>
|
||||
|
||||
<p class="c7"><span>A</span> <span class="code">Typeclass</span><span> is a near-normal Python class that stores
|
||||
its existence to the database behind the scenes. (For now, this is all you need to know about</span> <span class=
|
||||
"code">Typeclasses</span><span>. They are extensively detailed in</span> <span class="c16"><a class="c20" href=
|
||||
"https://github.com/evennia/evennia/wiki">Evennia’s manual</a></span><span> if you want more
|
||||
details.)</span></p>
|
||||
|
||||
<p class="c12 c4"></p>
|
||||
|
||||
<p class="c7"><span>A</span> <span class="code">Typeclass</span><span> is created in a normal Python source
|
||||
file. This is our new file</span> <span class="code">mechobject.py</span><span>:</span></p>
|
||||
|
||||
<pre class="code">
|
||||
from ev import Object
|
||||
from mechcommands import MechCmdSet
|
||||
|
||||
class Mech(Object):
|
||||
"""
|
||||
This typeclass describes an armed Mech.
|
||||
"""
|
||||
def at_object_creation(self):
|
||||
"This is called only when object is first created"
|
||||
self.cmdset.add_default(MechCmdSet)
|
||||
self.locks.add("puppet:all()")
|
||||
self.db.desc = "This is a huge mech. It has missiles and stuff."
|
||||
</pre>
|
||||
|
||||
<p class="c3 c8"><span>That’s it. When</span> <span class="code">Objects</span><span> of this type are
|
||||
created, they will always start out with the mech’s command set and the correct lock. We set a default
|
||||
description, but you would probably change this with</span> <span class="command">@desc</span><span> to
|
||||
individualize your mechs as you build them.</span></p>
|
||||
|
||||
<p class="c3 c8"><span>Back in the game, just exit the old mech (</span><span class="command">@ic</span><span> back
|
||||
to your old character) then do</span></p>
|
||||
|
||||
<p class="c1"><span class="command">> @create/drop The Bigger Mech ; bigmech : mechobject.Mech</span></p>
|
||||
|
||||
<p class="c3 c8"><span>We create a new, bigger mech with an alias</span> <span class="c15">bigmech.</span>
|
||||
<span>Note how we give the python-path to our</span> <span class="code">Typeclass</span><span> at the end</span>
|
||||
<span class="c24">—</span><span> this tells <span class="softwaretitle">Evennia</span> to create the new object based on that class. A
|
||||
shining new mech will appear in the room! Just use</span></p>
|
||||
|
||||
<p class="c1"><span class="command">> @ic bigmech</span></p>
|
||||
|
||||
<p class="c3"><span>to take it on a test drive.</span></p>
|
||||
|
||||
<h3>Future mechs</h3>
|
||||
|
||||
<p class="c3 c4"></p>
|
||||
|
||||
<p class="c3 c8"><span>To expand on this you could add more commands to the mech and remove others. Maybe the mech
|
||||
shouldn’t work just like a</span> <span class="code">Character</span><span> after all. Maybe it makes loud
|
||||
noises every time it passes from room to room. Maybe it cannot pick up things without crushing them. Maybe it needs
|
||||
fuel, ammo and repairs. Maybe you’ll lock it down so it can only be puppeted by emo teenagers.</span></p>
|
||||
|
||||
<p class="c3 c4"></p>
|
||||
|
||||
<p class="c3 c8">Having you puppet the mech-object directly is also just one way to implement a giant mech in
|
||||
<span class="softwaretitle">Evennia</span>.</p>
|
||||
|
||||
<p class="c3 c8"><span>For example, you could instead picture a mech as a “vehicle” that you
|
||||
“enter” as your normal  </span><span class="code">Character</span><span> (since any</span>
|
||||
<span class="code">Object</span><span> can move inside another). In that case the “insides” of the
|
||||
mech</span> <span class="code">Object</span><span> could be the “cockpit”. The cockpit would have
|
||||
the</span> <span class="code">MechCommandSet</span><span> stored on itself and all the shooting goodness would
|
||||
be made available to you only when you enter it.</span></p>
|
||||
|
||||
<p class="c3 c8"><span>And of course you could put more guns on it. And make it fly.</span></p>
|
||||
{% endblock %}
|
||||
{% block article_bio_content %}
|
||||
Griatch is the lead developer of <a class="softwaretitle" href="http://www.evennia.com/">Evennia</a>.
|
||||
{% endblock %}
|
||||
BIN
templates/volume06_issue01/copyright/images/spreddit3.gif
Normal file
BIN
templates/volume06_issue01/copyright/images/spreddit3.gif
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 675 B |
11
templates/volume06_issue01/copyright/index.html
Normal file
11
templates/volume06_issue01/copyright/index.html
Normal file
|
|
@ -0,0 +1,11 @@
|
|||
{% extends "issue/other/index.html" %}
|
||||
{% block page_title %}Copyright{% endblock %}
|
||||
{% block other_content %}
|
||||
<p>
|
||||
This issue of Imaginary Realities is copyright © 2014 Jennifer Melchert, Matthew Sheahan, Richard Tew, Richard Woolcock.
|
||||
</p>
|
||||
<p>
|
||||
All authors retain copyright to their work, and have made their work available under the
|
||||
<a href="{{tp.license_link}}">{{tp.license_text}}</a> license, which allows us to publish it.
|
||||
</p>
|
||||
{% endblock %}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 100 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 53 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 98 KiB |
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue