LFG - Volunteer Project

84 views
Skip to first unread message

TLTBDEV

unread,
Nov 7, 2015, 8:43:12 PM11/7/15
to Evennia

Hello one and all,
 
     It's TLTBdev again, coming to you with well managed expectations! Woo! Getting to the point, I'm looking for between 1 and ∞ volunteer(s) to put together a functional MUD, purpose built for private gaming sessions which emulate tabletop play. I believe that the features needed are relatively few and in my layman's understanding of the coding world, probably pretty novice, even. So, what would these features be and why can't I do it myself? 


  • The Character Sheet: Much like the sheets used on such systems as Roll20.net and Fantasy Grounds, the Character sheet collects information about a character into one convenient place and is viewable by the player and their DM. When playing tabletop games through a computer medium, the most powerful feature is to link attributes listed there to functions they are used in. I'm sure that most, if not all of these would be simple variables and have various applications when used with commands given to the player. The commands referred to are simplifications of dice rolling formulas a tabletop player would normally have to do in their own head. ie, "I want to attack so I'll be adding my proficiency bonus and strength score to a roll of 1d20...".
 
  •  In-Game enemy creation and implementation: At the core, an enemy is only another object with its own Character sheet and in the very simplest implementation possible the enemy doesn't need to do anything on its own. It simply needs to be easily puppeted. Something related and likewise distinct from this feature is a strict requirement for leeway in improvisation. If, say, during combat I realize that the creature I've faced the party with is simply too strong, I should be able to edit its health or really any other attribute on the fly. Additionally, 'spawning' prepared creatures within rooms, setting whether they are visible or not and any other simple staging tools would be paramount to the presentation of the game, which is largely run manually by me (The DM). Automation and other improvements could come far, far down the line for this project.
 
  •  "Mapping, movement and initiative": Area creation is, of course, a standard to the genre. Without a room you hardly have anything to play in, do you? As before, the functions of rooms have many, many possibilities but the bare and agreeable minimum is likely some distinction of flags like "dark/lit, difficult terrain, etc". Few of these flags would need to interact with rolls, which are so far the only 'automated' feature that's really necessary on this project. Tying into the rooms and the areas they comprise are movement and initiative. Translating freeform tabletop roleplay into a text environment requires some simple gates to stop players from moving to quickly, out of turn or without prior permission to do so. Initiative need only be tracked and lock most movement or combat related commands from all but the player whose turn is currently live on the initiative order. Text D&D, as one might expect, works in two modes. One of more or less 'free exploration, descriptive posting of exploration and/or dialogue, and queries to the DM for further information. The other is when initiative is important to track, as enemies must be given a chance to react, traps need to spring or events otherwise must be resolved in order of their priority. Most of the need for features here lies in power for the admin/DM to lock players out of movement or any particular command set on the fly, whenever necessary. Again,the vast majority of this project is simply to provide the platform and some automatic dice rolling. 

     So that is a basic overview of the most important features needed to make this 'MUD' like platform useable for my purposes. The finer details of what a character sheet must contain, how initiative is defined and other erroneous features that might be nice to have are probably best suited to a more in depth discussion with a would be code monkey.
 
     Lastly, the question of how to represent combat space in an easy to read way is, most probably, the most difficult part of creating this system. Typically combat is dealt with either on a grid or in the 'theater of the mind' where only description is necessary. On the one hand, rooms in a MUD don't lend themselves too well to the 5 foot square standard of movement in a tabletop game. On the other, representing a grid in the MUD might be a terrible, terrible design burden. After all, allowing for impassable areas, elevations or many differing sizes could be problematic. This also brings up the question of how one represents rooms and a grid simultaneously! All things that bear more informed discussion.

     That's it. If you're interested in volunteering to help put this together, shoot me an email or add me on skype: amrylin ( CA, USA). Due to my current life situation I simply can't offer monetary compensation, however, I am willing to seek donations and even honor some form of compensation retroactively, if situations change or the scope of the project goes to the point of not being used privately one day. 
 
 

Griatch Art

unread,
Nov 8, 2015, 3:39:53 AM11/8/15
to Evennia
Hi there,

So you are basically looking for a tabletop RPG base. You are correct that this is not too much work, here's a break down as far as I can tell, to help whomever is interested in taking on a pretty straight-forward project: 

  • Character sheet graphic + linked commands for checking attributes: This sounds highly dependent on the type of RPG system you choose to use, no? Hard to make a "system-generic" character sheet after all. Making commands to check a particular attribute is indeed simple though: If all it's doing is to pull the skills/attributes you want from the sheet and roll a random value, each command is something like 3 lines. But again, exactly how the commands should look is dependent on the system. You need a custom PC typeclass to hold the stats as well.
  • In game enemy: If all you want are puppetable objects, you have those out of the box in Evennia. So if you have the sheet from the previous point linked to a PC, then this one follows almost automatically. You'd need to make some GM commands (or maybe only one) to easily tweak attributes though.
  • Room with light/dark/terrain: This would be one custom Room typeclass. Maybe build off the contrib/extended_room.py. It'd also require another code line to roll-resolution commands needing to take the current location into account.
  • Restrict movement: Since it sounds like you are aiming to use a human GM anyway, this is likely just a flag you can easily set on every PC in the room - this means overloading the at_before_move() method on the PC typeclass to return False if that flag is set (which means the move is blocked before it even starts). So you need that method changed and a GM-level command to set it easily.
  • Change/add PC command sets on the fly: This is a GM command. Unless the GM is also always an Immortal, the sets available to add should probably be limited to ones in a specific module.
  • Grid/Room: One way to do this would be to do both; room movement in "normal mode" and grid-movement in "combat/turn mode" (where normal movement is turned off anyway as already discussed). This would mean that each room holds a 2-dimentional list (e.g. in an Attribute) of a size that may vary by room. Players can be moved around on this grid by the GM (another GM command) and PCs have a cmdset with custom move commands to move them along the grid. As you say, this is likely the bigger of the coding challenges in your project, but depending on the scope and features you want for it, it needs not necessarily be too bad.

As said, technically this is not hard for whomever decided to take it on. Some of the GM commands would likely be pretty generically useful but the character sheet and skill resolution will by definition be highly dependent on the kind of game system you want to use. The grid is the most involved bit and something that would need a more formal design document before establishing just what mechanic would be the best.

.

Griatch

Reply all
Reply to author
Forward
0 new messages