Poking around to see what digital literature, e-lit, or interactive fiction journals and zines might be floating around I stumbled across an online installation of work, <terminal><in search of a new(er) digital literature>. On that page at the bottom there also is an extensive bibliography of sorts; many of those links are kind of kaput but there’s still some interesting stuff to be found, and the projects of the installation itself are all current.

Nearly all of that stuff is multimedia work. I haven’t really found a ‘zine of ergodic text’ or something like that, though I guess something probably is out there. I feel like something of that nature could fill a niche. Pacian has his new blog (Text) Games for (Space) Crows which approaches that idea, but what I’m imagining is a combination of that and the presentation of new works.

One thing I’ve been going back and forth about is the virtue of trying to write IF with Python. On one hand Python is a great language for writing games; on the other hand I much prefer the Inform 7 syntax for a simple reason — in IF you write a lot of prose, and anything that makes that process both simpler and nicer to look at is a huge win. However that very same syntax becomes something of a stumbling block for me (well, to be honest — a tortuous maze) when you start doing anything complex. In this respect I like Python’s syntax much more.

Python already has a well developed IF system in PAWS. However as you can see in the Cloak of Darkness implementation the source itself reads much more like a TADS 3 file than Inform 7. I’m not saying that doesn’t make sense, only it’s not how I’d like to write ideally.

This got me to wonder — how would I like to write IF ideally? So here is a hacked up version of the Cloak of Darkness source above. Let’s see how the WP sourcecode markup works with this — after the cut:

"Cloak Of Darkness Sample Game" by Roger Firth (implemented by Neil Cerutti, adapted by me)

Copyright 1999-2008
Version 1.5

from PAWS import *      # Game Engine (already written for you)
from Universe import *  # Game World Library (already written for you)

.. the game begins here

Introduction

Hurrying through the rainswept November night, you're glad to see the bright lights of the Opera House. It's surprising that there aren't more people about, but, hey, what do you expect from a cheap demo game?

.. Scene 

Foyer "Foyer of the Opera House" Start

    North = "You've only just arrived, and besides, the weather outside seems to be getting worse."
    South = Bar
    West = Cloakroom

You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.

Cloakroom

    East = Foyer

The walls of this small room were clearly once lined with hooks, though now only one remains. The exit is a door to the east.

Bar "Foyer Bar" dark

    North = Foyer

    def going(self, direction):
        if direction == 'North':
            return
        elif Bar.IsLit:
            return "There's no exit in that direction."
        else:
            Sawdust.trampled += 1
            return "Blundering about in the dark isn't a good idea."

The bar, much rougher than you expected after the opulence of the northern foyer, is completely empty. There seems to be some sort of message scrawled in the sawdust on the floor. 

Sawdust message/floor +Bar

    def read(self):
        Global.GameOver = True
        if self.Trampled < 2:
            return "The message, neatly marked in the sawdust, reads..."
        else:
             return "The message has been carelessly trampled, making it difficult to read. You can just distinguish the words..."

Cloak velvet/black/satin/dark/handsome +Player

    Take = "{Bar.SetIsLit(False)}Taken."

    def drop(self, Multiple=False):
        return "This isn't the best place to leave a smart cloak lying around."

    Bulk = 1
    Weight = 10

A handsome cloak, of velvet trimmed with satin, and slightly spattered with raindrops. Its blackness is so deep that it almost seems to suck light from the room. 

Hook small/brass hook/peg +Cloakroom

    Take = "The hook is screwed to the wall."

    def enter(self, Object):
        if Object == Cloak: Bar.SetIsLit(True)
        return inherited

    MaxBulk = 1
    MaxWeight = 10

It's just a small brass hook {"with a cloak hanging on it" if Cloak in Contents else "screwed to the wall"}.

Conclusion

*** {"\n You have won \n" if Sawdust.Trampled < 2 else "\n You have lost \n"}. ***

Now for some explanation. The goal here is to make the prose of the IF as easy to write as possible, while keeping the syntax of the Python code when you need it. To that end a parser will run on the source text to produce the game file, which the Python interpreter will then execute normally.

I think this intermediary step makes a lot of sense — if I want to make the source text as easy to write as possible over and over, why not offload a lot of the work to the IF system, instead of putting it on the IF author? The key would be not to obfuscate the Python code or write a ‘custom Python’ — I want this as close to Python as possible.

First, take everything before the Introduction. This looks a little like I7. The first line is the game title and the author. Following that are a series of keywords followed by their values. A blank line separates this header from the imports you wish to make (I’m assuming I’m building this on PAWS here; you could also import other modules you would want to use here). Another blank line, then a sample comment not to be included in the game file, then the Introduction keyword.

This text is what’s printed before anything else, and is optional. After this we have object definitions, so to look at one more closely:

Foyer "Foyer of the Opera House" Start

    North = "You've only just arrived, and besides, the weather outside seems to be getting worse."
    South = Bar
    West = Cloakroom

You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.

I’ve taken some inspiration from PyLit in how the formatting works.

One thing I like about TADS 3 is the conciseness of its object definitions (which take advantage of a template feature I believe); I’m using a similar idea here. The first line includes the code name and then printed name of the object, in this case “Foyer of the Opera House”. The Start keyword means this is the start room.

Notice at no point have I actually said this is a room at all, and I’m not sure I need to. All objects could implement the features of a room, though not all objects might be enterable. I guess this could have some problems with game file size, but I’m not sure this is too important right now.

Also you could have an object with no printed name — this just creates a generic object where its source name is its printed name (like Cloakroom).

On the definition line you can declare starting location with a ‘+’ prefix as in Tads 3.

Following the definition line is an indented block, which means code. These are attributes on the object, and the parser would recognize these as exits with destination objects.

Now, none of these other objects are declared yet, and in Python this could be a problem (if this code was in an initialization block for example). But if the system parses this file first it could (somehow, I’m hand waving at this point) fill in the relationships on a ‘as I go’ basis. I think this improves the readability of the code a great deal (and is the standard in IF-specific domain languages like Inform and TADS 3).

After the indented block is another prose block, which is the description of the object. I realize there are a few things I’m missing here, like first-time descriptions for items.

These object definitions lay out the world model. Room and item definitions can be interleaved (see how Sawdust follows Bar). To look at a function definition within an object:

Bar "Foyer Bar" dark

    North = Foyer

    def going(self, direction):
        if direction == 'North':
            return
        elif Bar.IsLit:
            return "There's no exit in that direction."
        else:
            Sawdust.trampled += 1
            return "Blundering about in the dark isn't a good idea."

The bar, much rougher than you expected after the opulence of the northern foyer, is completely empty. There seems to be some sort of message scrawled in the sawdust on the floor.

I wanted that to look as much like Python code as possible — the only difference is it’s not contained in a class definition. A big part of this idea is many of these function names and keywords are reserved by the system (here I override the going function) but this is a big part of any IF system anyway.

That return inherited thing is a little bit of a hack in the enter method for the hook — I needed some way to continue the action. The parser would pick this up somehow.

Text substitution is always a big deal in IF, here’s an example:

It's just a small brass hook {"with a cloak hanging on it" if Cloak in Contents else "screwed to the wall"}.

This shows that prose blocks can include code — this is a Python equivalent of a condition/true result/false result ternary operator. The curly brackets cause the parser to execute this code and return the result to the prose block.

I think a key component of this parser would be its ability to create objects, either whole objects or instance attributes, on the fly if they didn’t exist already.

One open question that intrigues me is how to include additional functionality for objects. In this example I’m just kind of assuming all objects, when parsed, inherit from some monolithic game object class that includes all the functionality I want. However this probably isn’t a great way to go about things — how would the author, in this file to be parsed, include this functionality? I guess that’s where the rubber meets the road in a system like this.

One possibility would be to create objects with the required functionality (maybe they override system methods or whatever) and then include these objects in new object definitions. Something like:

A Big Foo :: Foo

    def bar(self):
         return "Now we're barring"

Biff :: "Foo"

Finally is the Conclusion keyword and another example of the ternary operator. The conclusion would trigger when the game state was marked as over, which happens when the player reads the message in the sawdust.

What I like about this format is the simplicity of writing the prose combined with the Python syntax — granted, it may not be easy at all to parse this into actual Python code.

This does look like an unholy union of Python, TADS 3, and Inform 7, doesn’t it. I don’t know if that’s scary or awesome to be honest.

Another thing pushing me to Python would then be the possibility of writing the interpreter in pyglet, with all the benefits pyglet would provide. I’m thinking mainly of a really cool text interface, not really all the other graphics capabilities you’d get, though that’s certainly there, and of course you get this on all platforms. One drawback would be in how to present games on the web — but zcode games solve this with separate interpreters, so this would be the road you’d have to take anyway.

edit: I couldn’t resist messing around with the example source, and the changes are significant enough to post it here:

"Cloak Of Darkness Sample Game" by Roger Firth (implemented by Neil Cerutti, adapted by me)

Copyright 1999-2008
Version 1.5

from PAWS import *      # Game Engine (already written for you)
from Universe import *  # Game World Library (already written for you)

.. the game begins here

Introduction

Hurrying through the rainswept November night, you're glad to see the bright lights of the Opera House. It's surprising that there aren't more people about, but, hey, what do you expect from a cheap demo game?

.. Scene 

Player "Regina" in Foyer

Foyer "Foyer of the Opera House" 

You are standing in a spacious hall, splendidly decorated in red and gold, with glittering chandeliers overhead. The entrance from the street is to the north, and there are doorways south and west.

    North = "You've only just arrived, and besides, the weather outside seems to be getting worse."
    South = Bar
    West = Cloakroom

Cloakroom

The walls of this small room were clearly once lined with hooks, though now only one remains. The exit is a door to the east.

    East = Foyer

Bar "Foyer Bar" 

The bar, much rougher than you expected after the opulence of the northern foyer, is completely empty. There seems to be some sort of message scrawled in the sawdust on the floor. 

    IsLit = False
    North = Foyer

    def going(self, direction):
        if not direction == 'North' and Bar.IsLit:
            return "There's no exit in that direction."
        else:
            Sawdust.trampled += 1
            return "Blundering about in the dark isn't a good idea."

Sawdust message/floor in Bar

    def read(self):
        GameOver = True
        if self.Trampled < 2:
            return "The message, neatly marked in the sawdust, reads..."
        else:
             return "The message has been carelessly trampled, making it difficult to read. You can just distinguish the words..."

Cloak DontDrop velvet/black/satin/dark/handsome in Player

A handsome cloak, of velvet trimmed with satin, and slightly spattered with raindrops. Its blackness is so deep that it almost seems to suck light from the room. 

    Take = "{Bar.SetIsLit(False)}Taken."
    Bulk = 1
    Weight = 10

DontDrop 

    def drop(self, Multiple=False):
        return "This isn't the best place to leave a smart {noun} lying around."

Hook small/brass hook/peg in Cloakroom

It's just a small brass hook {"with a cloak hanging on it" if Cloak in Contents else "screwed to the wall"}.

    Take = "The hook is screwed to the wall."

    def enter(self, Object):
        if Object == Cloak:
            Bar.SetIsLit(True)

    MaxBulk = 1
    MaxWeight = 10

Conclusion

*** {"\n You have won \n" if Sawdust.Trampled < 2 else "\n You have lost \n"}. ***

I realized it makes more sense to put the object description before the indented code block (then the next object definition comes after the indented block).

Instead of using a ‘+’ to denote containment I’ve opted for a more readable ‘in’ keyword. Also there is now an example of adding functionality to the core library object:

Cloak DontDrop velvet/black/satin/dark/handsome in Player

A handsome cloak, of velvet trimmed with satin, and slightly spattered with raindrops. Its blackness is so deep that it almost seems to suck light from the room. 

    Take = "{Bar.SetIsLit(False)}Taken."
    Bulk = 1
    Weight = 10

DontDrop 

    def drop(self, Multiple=False):
        return "This isn't the best place to leave a smart {noun} lying around."

This works a lot like a TADS 3 mix-in (and the PAWS class system). The Cloak object includes whatever code you put into DontDrop; the idea now is that the first keyword in the definition is the object, and after that come objects mixed in, then synonyms.

I got rid of the return inherited idea; now I’m thinking that if the overridden function doesn’t return something explicitly, the action continues.

On a minor note Global.GameOver is now TheEnd.

Also there’s a player definition now, and a removal of the idea of a ’start’ keyword.

The IGF main competition entries are up, bigger by a third than last year (which was bigger by a third than the year before apparently). Will it be bigger and badder though? Such remains to be seen, but there definitely were some that caught my eye:

7 Nights: “”7 Nights” shows that a quality AAA-style 3D first person shooter can be deployed on the web and could be created in about 7 MB.

This is also the first videogame in the world that was created and tested while on public transportation (Seattle Sound Transit Routes 545 & 577)”. Represent!

78641: “Saluton!! GZ Storm is now proudly to present – 78641 – the classic Esperanto-language adventure game now playing first time in Language English!!!”

A Slow Year: “A Slow Year is a collection of four games, one for each season, about the expereince of observing things. Played on the Atari Video Computer System (aka Atari 2600), the game invites sedate observation and methodical action.

A Slow Year is a kind of videogame chapbook, a set of “game poems” that attempt to embrace maximum expressive constraint and representational condensation. The game will be available for PC and Mac in a custom Atari emulator, and for Atari as a limited edition cartridge and poetry set.”

Achron: “Achron is the first “meta-time strategy” game. It is a real-time strategy game where all players can simultaneously travel through time, change the past, preview the future, and send their forces through time to when they are needed.”

ARGH: Augmented Reality Ghost Hunter: “ARGH is an augmented reality game that lets you use your Ghost Goggles to discover ghosts in your actual environment.

Players collect different ghosts located in physical locations all over the world. Explore the REAL WORLD and experiment with the time of day and time of year to discover the phantoms that share our space.”

Good lord I’m not even out of the a’s.

edit: Too bad, no parser IF this year. Looks like a few games you could call IF though.

I have only two weeks to play the games. Luckily there’s just 24 this year. Instead of posting here I think I’ll keep everything at the Intfiction forums.

MiniBoa, a minimal Python socket and telnet package

Jim Storch, author of the in development BogBoa, has kindly packaged his socket and telnet modules into a minimal, Python, single-threaded asynchronous telnet server called MiniBoa (think SocketMUD), much to my own delight! The cool thing is, as far as I’ve found, MiniBoa is the first such package to be made available in Python. Up to now your choices were to strip out something from an existing codebase, or use something like Twisted — which is great, but for learning purposes not the best for people like me. Not only is this a good learning tool but if you want to start writing a mud in Python for fun this is a great solution for the networking side.

Maiden Desmodus

For the last few weeks I’ve been playing Maiden Desmodus with my first character — the first time in a couple years probably that I’ve done more than just login to a mud to chat or check a place out. As I’ve found MD suits my casual drop-in play very well, aided in no small part by its Flash client, but also by the somewhat episodic nature of the gameplay. Every other day or so I can drop in and complete a task (a quest in other words, usually a fetch or kill task but sometimes something more involved). Skill progression is time-based on a decreasing power curve so this also encourages playing at the front of the curve if you don’t have a lot of time (or money, as MD allows you to buy skill progression blessings). Anyway, my physician is level 5!

The game itself is quite fun, and as a pleasant surprise does most of the things that I personally like in a mud. The world is well done and not filled with generic races or silly fantasy names. Its setting is a refreshing mix of dark medievalish fantasy and more Elizabethan to Victorian era stuff (quite a broad cut I know but I like that sort of thing). The skill and guild system is interesting, and the combat is on the shorter and less spammy side thank God. The players also seem to be a good group on the whole. So while I don’t see myself putting a whole lot of time or money into the game right now (maybe if I had started playing ten years ago), it’s definitely worth it to keep playing my character (give Caturige a shout if you see him!).

Up to now message handling (what gets printed to the message log) was just adding a message string to the log wherever something in the code warranted it. This was simple at first, but required checks to make sure a monster wasn’t initiating a message (like ‘you can’t go that way’ — seemed like a bug until I understood what was going on!).

So I’ve taken the next step to something a little more involved. Here’s what the message class looks like now;

class Log(object):
    def __init__(self):
        self.history = ["Go!"]
        self.cursor = 0

    def add(self, message, enactor, *string):
        for handler in enactor.handlers:
            if isinstance(enactor.handlers[handler], Messages):
                script = enactor.handlers[handler].script

                if message in script:
                    if string:
                        self.history.append(script[message] % string)
                    else:
                        self.history.append(script[message])
                    self.cursor += 1

            break

    def set_cursor(self, line_number):
        self.cursor = line_number

Adding a message now requires the message (which isn’t the message itself as I’ll explain), the enactor who initiated it, and an optional string to pass into the message. Using this method looks like this:

game.log.add("got something", enactor, target.name)

You can see that before anything gets added to the log I check if there’s a handler in the enactor’s handlers that is of type Messages. This class is a parent class that doesn’t really do anything, but allows me to subclass off it with handlers that actually do something — namely, add scripts to the enactor. For example:

class Messages(object):
    def __init__(self):
        self.script = {}

class PlayerMessages(Messages):
    def __init__(self, gid):
        self.gid = gid
        self.script = {
                        "move failed"       : "You can't go that way.",
                        "opened something"  : "You opened the %s",
                        "closed something"  : "You closed the %s",
                        "command not found" : "Try again!",
                        "got something"     : "You get the %s",
                        "used inventory item" : "You used inventory item %s"}

    def update(self):
        pass

By checking for an instance of Messages I can create many different message subclasses with different scripts, and attach these to actors depending on what messages I want them to have. Once the add method finds a Messages subclass, it checks if the message is in the script, and if so adds it to the log — with another check if the optional string was passed in as an argument or not.

This should get more interesting once I have messages for other actors — I can customize a standard message for each script.

I think I can extend this to be able to attach multiple scripts to the same actor — I’ll have to change the conditional check in the add method to create a list of handlers that are Messages subclasses, and then run through each handler’s script to find if a particular message is in there. There could be a problem though if I attach two subclasses that have the same type of message in their scripts — I’ll probably just have to add the first one that matches if that case arises.

Also I’ve been playing around with the UI some more.

I dropped the idea of the alt key + a number as a secondary use for inventory items — I’ll probably have enough to do just adding single uses for items! I also mocked up a pane selection scheme, where the tab key cycles through each pane and highlights it (the inventory pane is highlighted in that screenshot). When you highlight a pane you’ll get some additional functionality — scrolling through the message log, examining inventory items, examining things in the viewport, and scrolling through the journal pane (the pane to the right).

Usually it’s for a good reason, to fix something I did earlier for no reason, or maybe for a bad reason that I didn’t understand at the time.

Up to now I’ve been passing objects around by referring to the object itself (I guess this is passing by reference? I think this is what Python does by default). However when you save the game state with yaml (and perhaps with the pickle module too, though I haven’t investigated this), it saves every reference as the actual object data. For example, if you had an attribute on every thing that referenced a map object, that whole map object including its map array would be saved once for each thing.

That in itself wasn’t a problem, as you can clear data that you don’t need to save in your saving routine before you exit the game. However my future plans for the game include a lot of cross-referencing between objects, and I do want to be able to save that state without saving the same object data over and over.

So now instead of passing objects around by reference, each object has a unique game id (the gid). This gets created in a thing’s __init__ method like so:

class Thing(object):
    def __init__(self, name, x, y, properties, *handlers):
        self.gid = id(self)
        while self.gid in game.gids:
            self.gid = self.gid + 1
        game.gids[self.gid] = self

The reason for the while loop is if I create a thing after a game has been saved and reloaded, there is a slim chance that a new gid could match an old gid (as I’m just using Python’s id() function to create the number). If that does happen, I create a new gid until I have a unique one.

Of course this is not as simple as what I was doing before (though saving is actually a little simpler, as I just save a single dictionary of gids and re-use it when I load it back in). Every time I want to look up a thing’s properties I need to look up the thing’s object first in the gids dictionary. Nevertheless I think it’ll pay off in the long run.

Things are getting to the point where this is less of a demo and more of what I want to do in the game itself. I may or may not write a more complete tutorial based on the demo — I think there’s more than enough here for people to get familiar and get started with libtcod in general.

I’ve put in a rudimentary message log in the bottom pane of the display. That skull on the right is from the libtcod package — I’m thinking about using the right-hand pane to display images like character portraits, text of signs, books, conversations maybe? The top pane will contain game information views, like inventory and so on.

The command set right now is very simple — bump to open things (I’ll extend this to mean operate something that isn’t otherwise openable), press x to pick things up. Control + direction closes things (or will turn something ‘off’). Control by itself will act on a thing in the same cell as you. I still mean to work in throwing things, and using things in inventory, but I’m going to keep the command set simple. I’d like to use ‘z’ for taking an action with something in hand, but allow using anything in inventory (which will be limited) by selecting its inventory number (I think this is what Chickhack does if I remember correctly, I liked it at the time). Control + z then could be used as an undo/rewind, but that’s so far off I’m not really thinking about it at the moment.

I’m going back and forth right now about extending this command set and keeping it simple. I’m leaning toward keeping it simple, both as a creative constraint and to keep the project size small. The one thing that bugs me about this is I’d like multiple uses of things (for example, you have a potion you could either drink or throw at something). I may have to accept single-use items if I keep the command set limited. One possibility to open options up a bit is to use inventory-keys for an item’s primary use (so hitting ‘1′ and then ‘enter’ drinks the potion if that’s inventory item #1) and pressing ‘1′ then ‘z’ does an item’s secondary action, which could be throw. In the end I may save multiple-uses for another project…I don’t want things to get too convoluted.

update: don’t want it too convoluted?…where’s the fun in that? I’ve started trying something I think could work — using number keys for primary use of the item, and Alt + number for the secondary use. I may be able then to hijack Alt + x as a drop key if I ever want one.

I don’t write much about muds anymore as I haven’t been playing muds. Nearly all of them are far less suited to casual play that I would like. Nevertheless I still read the various forums, and right now there’s a long thread over at Mudbytes about a new moderation system the admins there are considering implementing. Read on if you’re curious, but fair warning that this may be interesting only to a very few people.

If you don’t follow muds, there are three main sites with forums: The Mud Connector, Top Mud Sites, and Mudbytes. Mudbytes is a relative newcomer, in some sense taking the role that MudMagic used to fill (a site which is now closed), indeed, as is often the case with community sites, it got its start partly due to people leaving MudMagic. All things considered I’d say that Mudbytes is the most vibrant discussion forum currently going. Particularly in the last few months it seems to have gained some new members, and while in my opinion it used to be focused on DIKU-derived codebases, lately it’s seen a more interesting range of discussion from programming to design.

All of this is a long preamble of context to frame why I’m posting this. I would have posted in the thread linked above but I felt it wouldn’t have served much purpose really, and what I’m trying to do here is get some thoughts out there to figure something out. For the record my nick on Mudbytes is Idealiad.

So what the Mudbytes admin are proposing is a system of moderation with a dedicated forum to contain ‘moderation threads’ — basically reference threads created when any disciplinary action takes place. The basic idea is to create a transparent system so that threads aren’t derailed with moderation disputes, and make it easier to reference moderation actions without digging up threads all over the forum. Also new moderators would be put in place to do the actual work of modding. The idea for this is derived from another forum with a similar system.

This is all in response to some recent issues with people getting suspensions and threads getting locked over some troll threads and responses that apparently are against various Mudbytes rules. People were crying foul over what they saw as heavy-handed moderation and wanted more transparency and accountability in how the modding went down.

So the proposal thread has developed in an interesting way. First of all my response was against the idea of a moderation sub-forum, but for the idea of new mods. My main beef with the separate sub-forum is that I think it creates an atmosphere of antagonism rather than cooperation. I’ll try to explain my reasons for thinking that.

I think the ‘community energy’ of a site is relatively fixed. How the community chooses to spend that energy influences the tone and direction of the site, how its members will treat each other and how new members will integrate into the established community. So when the community spends its energy in creating an infrastructure to deal with infractions, it is taking away energy from other things.

I have to admit my main influence on this thinking is the time I spend on TIGSource. TIGS is not without moderation of course. People there have been banned and threads locked. In general though, I get the sense that the atmosphere of TIGS is much, much different than that of Mudbytes (to be fair it’s also a much larger site, and so personal disputes don’t tend to involve the whole community like they do at Mudbytes, so their impact is somewhat diluted in the grand scheme of things). In essence TIGS spends its community energy on, for lack of a better word, ‘positive infrastructure’. An effort is made to keep things moving in a positive direction. When people trend the other way there is an effort by others to steer the ship to its original course.

As a result of this comparison, I got frustrated with Mudbytes. What I’d like to see is a similar focus on positive infrastructure, and less on what is in effect an infrastructure for litigation.

What could be the reasons for this difference? My first thought was that it has to do with the nature of mudding itself. Muds are games that primarily are social spaces. Unlike the majority of games on TIGS, a mud is in itself a social space. You certainly can have a community based around a game on TIGS, but this idea of a social space is quite different. There is a long tradition of large hierarchies running muds, with all the rules, sometimes formal and sometimes informal, you would expect in any community. By their nature then, mudders are used to all sorts of frameworks for maintaining this social space, and these frameworks are going to mirror what we see in society at large — judicial and political systems — and when the time comes to moderate another social space which they are a member of, like Mudbytes, they’re going to turn to these same rules and frameworks as the tools they’re comfortable with.

It’s not surprising then that in that Mudbytes thread people are not really arguing about the need for such a system of moderation (with one or two exceptions), but instead debating what seems to me more and more elaborate systems of moderation and their finer points of implementation. In essence the die already is cast.

The thing here though is that I think people like this. Whether there is a sub-forum for moderation or not it doesn’t really matter — the community at Mudbytes already is oriented toward this way of being. They like going back and forth over who’s trolling who, what should be modded or shouldn’t, and all the finer political points in between, and will continue to do so no matter what kind of system is set up. It’s kind of like people who go for student government or model UN. In that case a system with more transparency is probably better than a system with less, don’t you think?

So in the end I guess I have to accept this community for what it is if I want to participate in it. I don’t know if it’s possible for it to be different, more like TIGS or something like it. In effect its social space already is dictated by the social habits of the mudders themselves, and I don’t see in the near future those habits changing very much at all.

I haven’t really spent much time yet figuring out what a thing from the Thing class is, so far defining it as an object with a name, speed, position, and maybe a handler for field-of-view or dumb AI. Furthermore the character used to represent it on screen simply was based on its name. Since I knew I wanted to better define a Thing and start figuring out how I want to represent it visually, I’ve started hacking on Thing.

First of all Thing’s parameters have changed. The __init__ now looks like this:

class Thing(object):
    def __init__(self, name, x, y, properties, *handlers):
        self.name = name
        self.x = x
        self.y = y
        self.properties = properties
        self.handlers = {}
        if not None in handlers:
            for string in handlers:
                handler = eval(string)
                self.handlers[string] = handler(self)

        self.things = []
        self.stage = None

        self.char_type = self.get_char_type()

As you can see I got rid of the speed parameter, which is now included in properties. A thing therefore looks like this in its yaml definition file:

- iron-barred window
- 35
- 12
- speed : normal
  kind :
  - window
  state :
  - none
-

That definition gives the thing’s name, x, and y attributes. The next item in the list is a dictionary containing the keys speed, kind, and state. This dictionary is passed into a new instance of a thing as properties. The last blank list item is handlers.

It’s all very provisional right now as I figure out how to define a thing. But here’s a closer look at the last statement in __init__, self.char_type = self.get_char_type().

Here’s that function:

 def get_char_type(self):
        name = ''
        if self.name in player.ui.char_types:
            name = self.name
        else:
            name_tokens = self.name.split(' ')
            for token in name_tokens:
                if token in player.ui.char_types:
                    name = token

        if not len(name):
            for kind in self.properties['kind']:
                if kind in player.ui.char_types:
                    name = kind

        for state in self.properties['state']:
            state_modifying_name = ' '.join([state, name])
            if state_modifying_name in player.ui.chars:
                return state_modifying_name
            if len(name):
                return name
            else:
                return 'unknown'

What I’m trying to do is find the visual symbol for a thing (its char_type) based on its name, kind, and state (if any). This is of course not very straightforward and I may have to choose a different method. Whenever a thing’s state changes, its symbol may change as well. There is also the possibility, not accounted for in this code yet, that a thing may have a combination of states that modify its name or kind producing a unique visual symbol. I think I can get this to work but it’ll require some experimentation.

In the meantime I’ll explain how this works. The player.ui.char_types list looks like this:

        self.char_types = ['player', 'unknown', 'ground', 'wall', 'window', \
        'lamp', 'knife', 'door', 'portal']

So the first thing the get_char_type function asks is if the thing’s self.name is in that list; if so, it assigns it to the local variable name, previously set to an empty string allowing it to be referenced later in the function. If the thing’s self.name is not in the list we break up the name into its tokens (parts), and if one of those are in the list, we assign that to name. Keep in mind that name may still be empty at this point.

Next, if name is empty, we see if the thing’s kind is in the list of char_types, and if so, assign that to name.

Finally we combine whatever state the thing might have with its name, and check if that’s in the list. This takes care of things like ‘closed door’. If there’s a match we return it. If not, we see if name is non-empty (there was a successful match earlier) and return that. Lastly if name is still empty, it’s not in the list of char_types and so we call it ‘unknown’, which gets the question mark symbol when drawn to the screen.

Some notes after the cut on how to find symbols for combination of states.

I’m imagining things like an object that’s an ‘open broken door’. (perhaps this door can’t then be closed and/or locked). I would have to find this symbol (if I do indeed try to represent this with a unique symbol) in the dictionary of ui.chars when I draw it to the screen. Given the code above this isn’t going to happen, as it only searches for individual states, not a combination — how then could I find the right symbol?

First of all it seems like I don’t want to depend on an exact match, as I would have to reorder every combination of words in the string — i.e., ‘broken open door’ and ‘open broken door’. What I really want to do is compare the list of states + name (‘open broken door’) with the ‘list’ of the key (a string, really) into ui.chars (for example, say the key actually is the string ‘broken open door’).

If I convert the string to a list by splitting on the space (string.split(‘ ‘)), then find the difference of the two sets like this:

difference = set.difference(set(a), set(b))

If the two strings in any order are different from each other, difference will be non-empty.

This alone doesn’t solve the problem where a thing has multiple states and only one of them in combination with its name matches a key in ui.chars. For example, if a door has the states ‘open’ and ‘pickled’. If the key is ‘open door’, ‘open pickled door’ won’t match it using a difference of sets. But maybe ‘pickled’ isn’t applicable to the visual symbol for the door at all, and it should match as ‘open door’.

One possible preliminary test is to create a list of states + name, then check if each word of a key’s string is in this list. If so, this should match if the states + name in its entirety doesn’t match any other key. For example:

list = thing.properties['state'] + [name]

for key in player.ui.chars.keys():
    key_list = key.split(' ')
    for item in key_list:
        if item in list:
            print 'match'
....
#etcetera

Perhaps more trouble than its worth. For certain effects/states I’m going to want to just color the character anyway, rather than having a separate symbol for every combination of thing and its state. Still, this could work well for updating a thing’s symbol on a dynamic basis as states change. Have to try it out and see.