Showing posts with label community. Show all posts
Showing posts with label community. Show all posts

Sunday, October 29, 2017

Getting a MUD Roleplaying Scene going

Getting a MUD RP-scene going


This article is a little different from the normal more technical Evennia-specific content of this blog. It was originally published as a light-hearted addition to the Imaginary Realities e-zine many years ago. While IR is still online it has since dozed off. So I'm reposting it here to bring it to a new audience.

In roleplay-heavy MUDs (and in other categories of text-based roleplaying games), the concept of scenes become important. A scene in this concept is simply a situation big or small that involves you and your fellow players in interesting role play. A scene can be as simple as two players meeting in the street and exchanging a few words to the dramatic conclusion to a staff-driven quest. Whenever role player-interested players meet, a scene may happen.

But sometimes scenes won’t come naturally. Sometimes your favourite game has only a few people online, or most of them are hovering in private areas. It’s time to go proactive. Below I offer some archetypes, tropes and ideas for how to get a random Scene started and people interested. The list is based on one I did for a RP-heavy MUD I played some time back.

Some terms used in the list:
  • Character concept - The general idea behind your player character (PC), like “The scarred veteran”, “The grumpy old magician” or “The swashbuckling bounty-hunter”.
  • IC/OOC - In-Character/Out-Of-Character.
  • Emote/pose - This is the common way to roleplay in MUDs. This displays a free-form action to the room, such as “The tall man sighs heavily”. Some MUDs offer a slew of special commands for particular actions or special syntax to decorate poses. Some games use specific “say” commands for verbal communication whereas others make say’s part of the emote completely.
  • Action/static pose - 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.
  • NPC - 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.
  • vNPC - a “virtual” NPC. This NPC does not actually exist in code but they should be there. Even though there are only two Players and a City guard in the central plaza, that place is actually packed with people most of the day. Most RP-heavy muds ask players to imagine vNPCs being all around them and have it influence their roleplay.
  • Godmodding - this is considered very bad form. Godmodding means to include another Player’s character in your roleplay in a way that takes control away from them unfairly. 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.

Scene starters


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 who's interesting in roleplay and where they are in the game). If not, it’s best to prepare your starter in a commonly visited central location or hub. You normally trigger the starter whenever another Player enters.

The Scene starters below are intended as ideas and suggestions, but are also examples of archetypical behaviour I’ve observed myself.

The Barfly

A role playing mud classic since time immemorial. The barfly is alone in a tavern and tends their drink, waiting for things to happen. A passive role, but trivial to setup and easy for other players to jump in on - they just slide up to the bar and ask what's up. Fun variations is the drunk barfly or really, really sad/happy barfly, states which immediately give other Players things to ask about and work with.





The Strider

This is the "dark stranger in the corner" variation of the barfly. 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 the Strider 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.


The Busybody

The busybody 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 wee jesters they are making fools out of themselves. And so on. This is a great starter since it is both natural, realistic and in-character all at once. The nature of their 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 motivate why some characters would strike up a conversation with a guardsman than they would with a street vendor.

 

 

 The Demagogue

This more involved starter involves striking up a loud conversation with an NPC/vNPC. Whenever another Character enters, the Demagogue plays out 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 gives immediate character to the demagogue and to the NPC both. It also makes it easy for the newcomer to get into the scene just by taking sides in the debate.

 

The Damsel in Distress

This starter, which of course works both for male and female Characters, sets up the damsel as being in a dependency situation to whomever enters the room next. It involves describing the damsel 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 (which should bugger off 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.

 

The Organizer

This starter requires that the game has a developed in-game message- or mailing system. If so - use it to explicitly and in-character invite  people to a scene! If the organizer is in a position of in-game power, this could make good IC sense - like the lord calling on their vassals to attend some sort of function. But anything from calling in a favor to suggesting a business opportunity or looking for a job works. Throw a party. Get drunk and send an ill-advised love letter. This starter works exceptionally well in combination with Stage director or Aggravator for getting selected Players into a memorable scene.

 

 The Aggravator

The aggravator 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. The aggravator should accuse the newly arrived PC for 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 - if nothing else in order to defend themselves. 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 the aggravator 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 god-modding, remember. If the two Characters are actual enemies though, it may be another matter ...

 

The Stage Director

This is a more sophisticated starter that is halfway to improvised theater. It sets up a whole little scene involving some event with a number of semi-named vNPCs. The stage director 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 trite bar brawl to a domestic dispute in progress. Or why not a marriage proposal between two vNPCs in the middle of the street! If the stage director is threatened in some way, this is a large-scale version of damsel in distress.
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, the stage director could give everyone involved a true feeling of being in a living environment.

The scene could continue to be played out around the PCs also as they interact, making this starter potentially  demanding on the stage director. If the other Players are experienced they should pick up on this and maybe even contribute their own vNPCs to the scenario (or the stage director could actively invite other Players to do so). It's important to remember to avoid god-modding here - never dictate another PCs actions, let other Players react as they see fit.




 

 

The Lazy Bum

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 Character staring blankly into space until something happens. Yeah.




 

Scene entrances


Here are some ideas on how to enter a scene/room with one or more other PCs already involved in role play. It should be noted that if other PCs already have a scene going they might be OOC annoyed if the newcomer muscles in with some room-changing entrance. So you as a Player have to show some consideration here. Check the land 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!


The Mouse

The most common of entering schemes. The Mouse walks into the room/area not drawing attention to themselves. A simple, passive setup that fits many situations and Character concepts. The mouse is a useful way to enter an already running scene. It is a bit overused though, possibly being The lazy bum of entrances. It seem to imply that it is up to others to notice and respond to the mouse. If really aiming for anonymity, the mouse must emote explicitly that they are not drawing attention to themselves, making it clear to other characters they need not go out of their way to be courteous and notice the newcomer.

 

The Ignoranti

The ignoranti 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. The ignoranti must emote their ignorance explicitly, with something like "S/he does not notice the others yet". This entrance makes for a nice variation by allowing the ignoranti and other PCs to "accidentally" bump into each other later in a very natural way.

 

 

The Walker

The walker 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. The walker 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 more common approach of just congesting onto a street room and start greeting people as if all you do is stand in the street all day.

 

 

The Planned Visitor

This is a variation on The busybody and the opposite of The walker. The planned visitor needs to come to this room, and that is not in order to chat with random PCs. The visitor will start to perform whatever they are here to do and interaction with others is mere a side effect. The classic take on this trope is 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 (which turns out to not be here), repair something, do some sort of inspection or setup for an artistic performance. If done well, others will have plenty of opportunity to ask The Planned Visitor what they are up to. It also makes for a thematic way to exit the scene once you declare your business there done.

The Wet Kitten

A classic that involves entering a scene drenched to the bone, shivering from cold, gasping from heat or otherwise be dramatically and visually affected by whatever weather or situation reigns outside. Common to taverns everywhere. For some reason this entrance rarely instills as much sympathy as one would think - but at least it opens up for other Characters to comment on the weather. Taken to the extreme, this becomes a variation on Damsel in Distress.


 

 

 The Third Wheel

This is an active, provocative entrance and a variant on the aggravator. 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 god-modding). This is sure to start off a scene! The more common third-wheel approach is to walk up to another 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 is a conscious RP choice - it’s your Character which is inconsiderate, not the Player behind it. In other words, emote something like “... He/She does not seem to notice or care that s/he is intruding...


The Theatrist

This is an on-the-fly version of the Stage director or demagogue. Only use if it's clear the currently ongoing scene allows it (so its often a good idea to follow a few emotes in the room  before setting this one off). Just like stage director, it starts some sort of background action in the room based on vNPCs. Maybe a brawl, an argument or some other event like a happy announcement. Maybe a vNPC starts hitting on a PC. Or, like the demagogue, the theatrist gets involved in a discussion with an NPC/vNPC. Bartender NPCs are classically useful targets for this. Again, the theatrist must be considerate here, and perceptive so as to not take 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 god-modding!)


The Non-sequitur

This, strangely rare, entrance involves running into a crowded room, shouting "Monkeeey!" and then run out again. This one will at least lead to roleplay for the confused people in the room you just visited. And no, don't do this unless you have a very specific and suitable character concept, kids.




 

 The Newbie

The classic newbie 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 newbie 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 the newbie under their wing and explain a thing or two.

Sunday, October 1, 2017

Evennia in Hacktoberfest 2017

Evennia, the Python MUD/MUSH/MU* creation library participates in the Hacktoberfest 2017 (sign up on that page)! Hacktoberfest is open for all open-source projects like ours. After registering, if you make at least four Pull Requests to a public repo on Github during October (need not just be to Evennia), you win a limited-edition T-shirt!

The help Evennia out and get your T-Shirt, look at our Issue Tracker. I have marked some issues with "Hacktoberfest" but you could take on any issue you want. Take a look in particular at the Unit test issue if you are looking to get into contributing on a smaller scale while helping us tremendously.

If you have any questions on contributing (or it's your first time making a Pull Request), don't be shy to drop into #evennia on irc.freenode.net or ask in our forum/mailing list. Have fun!

Sunday, April 23, 2017

The luxury of a creative community

For this blog post I want to focus on the series of very nice pull requests coming in from a growing cadre of contributors over the last few months.

Contributed goodness

People have put in a lot of good work to boost Evennia, both by improving existing things and by adding new features. Thanks a lot everyone (below is just a small selection)!
  •  Contrib: Turn-based combat system - this is a full, if intentionally bare-bones implementation of a combat system, meant as a template to put in your particular game system into.
  • Contrib: Clothing sytem - a roleplaying mechanic where a character can 'wear' items and have this show in their descriptions. Worn items can also be layered to hide that underneath. Had plenty of opportunities for extensions to a given game.
  • Contrib: An 'event' system is in the works, for allowing privileged builders to add dynamic code to objects that fires when particular events happen. The PR is not yet merged but promises the oft pondered feature of in-game coding without using softcode (and notably also without the security of softcode!). 
  • A lot of PRs, especially from one user, dealt with cleanup and adherence to PEP8 as well as fixing the 'alerts' given by LGTM on our code (LGTM is by the way a pretty nifty service, they parse the code from the github repo without actually running it and try to find problems. Abiding by their advice results is cleaner code and it also found some actual edge-case bugs here and there not covered by unit tests. The joint effort has brought us down from some 600+ alerts to somewhere around 90 - the remaining ones are alerts which I don't agree with or which are not important enough to spend effort on). 
  • The help mechanics of Evennia were improved by splitting up the default help command into smaller parts, making it easier to inject some changes to your help system without completely replacing the default one. 
  • Evennia's Xterm256 implementation was not correctly including the additional greyscale colors, those were added with new tags |=a ... |=z.
  • Evennia has the ability to relay data to external services through 'bots'. An example of this is the IRC bot, which is a sort of 'player' that sits in an in-game channel and connects that to a counterpart-bot sitting in a remote IRC channel. It allows for direct game-IRC communication, something enjoyed by people in the Evennia demo for many years now. The way the bot was defined used to be pretty hard-coded though. A crafty contributor changed that though, but incorporating the bot mechanism into Evennia's normal message flow. This allows for adding new types of bots or extending existing ones without having to modify Evennia's core. There is already an alternative IRC bot out there that represents everyone in the IRC room as a room full of people in the MUD. 
  • Evennia's Attributes is a database table connected to other objects via a ForeignKey relation. This relation is cached on the object. A user however found that for certain implementations, such as using Attributes for large coordinate systems, non-matches (that is failed Attribute lookups on the object) can also be cached and leads to dramatic speed increases for those particular use cases. A PR followed. You live and learn.
  • Another contributor helped improve the EvEditor (Evennia's VIM-like in-game text editor) by giving it a code-mode for editing Python code in-game with auto-indents and code execution. Jump into the code mode with the command @py/edit.
  • Time scheduling is another feature that has been discussed now and then and has now been added through a PR. This means that rather than specifying 'Do this in 400 seconds' you can say 'do this at 12AM, in-game time'. The core system works with the real-world time units. If you want 10 hours to a day or two weeks to a month the same contributor also made an optional calendar contrib for that!
  • A new 'whisper' command was added to the Default cmdset. It's an in-game command for whispering to someone in the same room without other people hearing it. This is a nice thing to have considering Evennia is out-of-the-box pretty much offering the features of a 'talker' type of game.
  • Lots of bug fixes big and small!
  • Some at_* hooks were added, such as at_give(giver, getter). This allows for finer control of the give process without handling all the logics at the command level. There are others hooks in the works but those will not be added until in Evennia 0.7. 
About that Evennia 0.7 ...

So while PRs are popping up left and right in master I've been working in the devel branch towards what will be the Evennia 0.7 release. The branch is not ready for public consumption and testing yet But tentatively it's about halfway there as I am slowly progressing through the tickets. Most of the upcoming features were covered in the previous blog post so I'll leave it at that.

I just want to end by saying that it's a very luxurious (and awesome) feeling for me to see master-branch Evennia expand with lots of new stuff "without me" so to speak. The power of Open Source indeed!
  

Image from http://maxpixel.freegreatpicture.com, released as public domain.

Sunday, February 5, 2017

News items from the new year

The last few months have been mostly occupied with fixing bugs and straightening out usage quirks as more and more people take Evennia through its paces.

Webclient progress

One of our contributors, mewser/titeuf87 has put in work on implementing part of our roadmap for the webclient. In the first merged batch, the client now has an option window for adjusting and saving settings. This is an important first step towards expanding the client's functionality. Other  features is showing help in an (optional) popup window and to report window activity by popup and/or sound.

The goal for the future is to allow the user or developer to split the client window into panes to which they can then direct various output from the server as they please It's early days still but some of the example designs being discussed can be found in the wiki webclient brainstorm (see the title image of this blog for one of the mockups).
 
New server stuff

Last year saw the death of our old demo server on horizondark.com, luckily the new one at silvren.com has worked out fine with no hickups. As part of setting that up, we also got together a more proper list of recommended hosts for Evennia games. Evennia requires more memory than your average C code base so this is important information to have. It seems most of our users run Evennia on various cloud hosting services rather than from a traditional remote server login.

Arx going strong 

The currently largest Evennia game, the mush Arx - After the Reckoning has helped a lot in stress testing. Their lead coder Tehom has also been active both in reporting issues and fixing them - kudos! There are however some lingering issues which appears rarely enough that they have not been possible to reproduce yet; we're working on those. Overall though I must say that considering how active Arx is, I would have expected to have seen even more "childhood diseases" than we have. 

Launch scripts and discussions

It is always interesting with feedback, and some time back another discussion thread erupted over on musoapbox, here. The musoapbox regulars have strong opinions about many things and this time some were critical of Evennia's install process. They felt it was too elaborate with too many steps, especially if you are approaching the system with no knowledge about Python. Apparently the average MUSH server has a much shorter path to go (even though that does require C compiling). Whereas I don't necessarily agree with all notions in that thread, it's valuable feedback - I've long acknowledged that it's hard to know just what is hard or not for a beginner.

Whereas we are planning to eventually move Evennia to pypi (so you can do pip install evennia), the instructions around getting virtualenv setup is not likely to change. So there is now unix shell scripts supplied with the system for installing on debian-derived systems (Debian, Ubuntu, Mint etc). I also made scripts for automating the setup and launch of Evennia and to use it with linux' initd within the scope of a virtualenv.
So far these scripts are not tested by enough people to warrant them being generally recommended, but if you are on a supported OS and is interested to try they are found from the top of the Evennia repo, in bin/unix/. More info can be found on their documentation page.

Docker

Speaking of installing, Evennia now has an official Docker image, courtesy of the work of contributor and Ainneve dev feend78. The image is automatically kept up-to.date with the latest Evennia repo and allows Evennia to be easily deployed in a production environment (most cloud services supports this). See Docker wiki page for more info.


Lots of new PRs

There was a whole slew of contributions waiting for me when returning from Chistmas break, and this has not slowed since. Github makes it easy to contribute and I think we are really starting to see this effect (Google Code back in the day was not as simple in this regard). The best thing with many of these PRs is that they address common things that people need to do but which could be made simpler or more flexible. It's hard to plan for all possibilities, so many people using the system is the best way to find such solutions.

Apart from the map-creation contribs from last year we also have a new Wildnerness system by mewser/titeuf87. This implements wilderness according to an old idea I had on the mailing list - instead of making a room per location, players get a single room.  The room tracks its coordinate in the wildnerness and updates its description and exits dynamically every time you move. This way you could in principle have an infinite wilderness without it taking any space. It's great to see the idea turned into a practical implementation and that it seems to work so well. Will be fun to see what people can do with it in the future!

Wednesday, November 30, 2016

Birthday retrospective

So, recently Evennia celebrated its ten-year anniversary. That is, it was on Nov 20, 2006, Greg Taylor made the first repo commit to what would eventually become the Evennia of today. Greg has said that Evennia started out as a "weird experiment" of building a MUD/MUX using Django. The strange name he got from a cheesy NPC in the Guild Wars MMORPG and Greg's first post to the mailing list also echoes the experimental intention of the codebase. The merger with Twisted came pretty early too, replacing the early asyncore hack he used and immediately seeing a massive speedup. Evennia got attention from the MUD community - clearly a Python-based MUD system sounded attractive.

When I first joined the project I had been looking at doing something MUD-like in Python for a good while. I had looked over the various existing Python code bases at the time and found them all to be either abandoned or very limited. I had a few week's stunt working with pymoo before asking myself why I was going through the trouble of parsing a custom script language ... in Python ... Why not use Python throughout? This is when I came upon Evennia. I started making contributions and around 2010 I took over the development as real life commitments forced Greg to step down.

Over the years we have gone through a series of changes. We have gone from using SVN to Mercurial and then to using GIT. We have transited from GoogleCode to GitHub - the main problem of which was converting the wiki documentation (Evennia has extensive documentation).

For a long time we used Python's reload() function to add code to the running game. It worked ... sometimes, depending on what you changed. Eventually it turned out to be so unpredictable that we now use two processes, one to connect clients to and the other running the game, meaning we can completely restart one process without disconnecting anyone.

Back in the day you were also expected to create your own game in a folder game/ inside the Evennia repo itself. It made it really hard for us to update that folder without creating merge conflicts all over. Now Evennia is a proper library and the code you write is properly separated from ours.

So in summary, many things have happened over the years, much of it documented in this blog. With 3500 commits, 28 000 lines of code (+46% comments) and some 25 people contributing in the last year, Openhub lists us as

"A mature, well-established codebase with a stable commit history, a large development team and very well documented source code". 

It's just words compiled by an algorithm, but they still feel kinda good!


While Evennia was always meant to be used for any type of multiplayer text game, this general use have been expanded and cleaned up a lot over the years.

This has been reflected in the width of people wanting to use it for different genres: Over time the MUSH people influenced us into adding the option to play the same character from many different clients at the same time (apparently, playing on the bus and then continuing on another device later is common for such games). Others have wanted to use Evennia for interactive fiction, for hack&slash, deep roleplay, strategy, education or just for learning Python.

Since Evennia is a framework/library and tries to not impose any particular game systems, it means there is much work to do when building a game using Evennia. The result is that there are dozens of games "in production" using Evennia (and more we probably don't know about), but few public releases yet.

The first active "game" may have been an Evennia game/chat supporting the Russian version of 4chan... The community driven Evennia demo-game Ainneve is also progressing, recently adding combat for testing. This is aimed at offering an example of more game-specific code people can build from (the way Diku does). There are similar projects meant for helping people create RPI (RolePlay Intensive) and MUSH-style games. That said, the Evennia-game Arx, After the Reckoning is progressing through beta at a good clip and is showing all signs of becoming the first full-fledged released Evennia game. 


So cheers, Evennia for turning 10. That's enough of the introspection and history. I'll get back to more technical aspects in the next post.