Dying Age MUD

[F. Scott Banks]

Ahhhh, after a pleasant break to do some serious writing (actually, it was grinding drudgery, but no one wants to hear that) I'm back to finish up the first "phase" of the gaming project I began in this thread .  

For those who were paying attention, that would be the Multi-User Dungeon (MUD) program.  For those who are wondering what happened to the MMORPG, a MUD is an MMORPG, but without all the bells and whistles so it needs strong role-playing elements and solid gameplay (for those who consider the two mutually exclusive) in order to keep a players attention.  If I can make a tight MUD, I'll shop around for bells and whistles and we'll see where it goes from there.

I feel I should reintroduce the project here in order to initiate the new and orient the old.  Some of the elements discussed in the afformentioned thread won't be making an appearance in the MUD and the gameplay will be largely different.  While I am looking into a graphical interface to simplify the game somewhat, it won't be anything remotely capable of things like free-building culture-specific architectures, real-time battles between armies of thousands, or building a kingdom one brick at a time.

So yeah...those things won't be making it into this version.  The client that "plays" the game is simply not powerfull enough graphically.

That said, the MUD is designed to be a framework for the mammoth game we brainstormed in the other thread.  It's also designed to ensure the quality of the underlying ruleset.  All of the character-building and roleplaying elements will be in place.  The Heritage System, the Flexible Skills, the self-sustaining environments...all there.

So, this is just a call to anyone who wanted to work on this and was waiting to see it resurface.  I'll be posting the basic ruleset a little later on today.  I'm taking an A+ certification class right now and the instructors are persnickety about people posting to game design forums on a machine that isn't technically "assembled".

No sense of adventure these technical types.  I like watching the hard drive platters spin while I work.

- Wyld -

[shoka]

It's good to hear from you again, WK - I was getting a bit concerned that this project would silently die like so many others.. :)

I have also been taking a break due to quite a heavy workload, but luckily it is now easing a bit and I'll be able to concentrate on more interesting things, like this. Have you given any thought to setting up an actual project for the MUD (in other words, are you going open-source with it) or do you want to keep it here for now?

I'm a bit reluctant to code anything more until I'm sure somebody else hasn't already implemented the same things, so it would help quite a lot to get an overview of what features have been done and who's doing what next.. :P

[F. Scott Banks]

Honestly, I'm not terribly familiar with open-sorce.  I've written a few little programs, but nothing so massive I needed to call upon the greater programming community.  I'd been trying to figure out how that works as well as picking through the tangle of legalese regarding open-gaming license and what one can legally do when using the source code of other MUDS.  I'd seen a few MUDs closed down for misuse of source code so I wasn't overly eager to "share".  The closest I've come is the "example" software the accompanies most "How To Program" books.

Then again, the advice of a more experienced programmer who knows how to use open-source properly would be appreciated.  

Been hustlin' lately.  I've gotta post the changes I've made for the MUD later on today.  Then again, the time difference between myself and most of the posters interested in this particular thread means that interested parties will probably just be waking up as I post it.

[shoka]

Yeah, I know what you mean. :) Actually I'm not so keen on using open-source MUDs for the same reason, but will rather implement my own - I'll just use some frameworks which are released under LGPL or BSD (or some similar) license, because they allow me to even create commercial software with them. I'm considering open-sourcing the framework just to get some outside opinion on my design as every developer tends to be blind for some things.. Just hoping somebody will prevent me doing mistakes that would cost a lot (in terms of workhours and system coherence) to fix at later time - that's why I make such a fuss about open-sourcing..

One can get quite far by just coding stuff and documenting/designing as they go but, if we're going to do any serious, coordinated development where number of contributing coders is greater than two or three, we'll need management. I'm not saying we'll have to go open-source for that, we could as easily set up a closed environment with CVS and other stuff - but it'll be a lot easier to just utilize some community like sourceforge.

Basically I could provide everything we need at my company's servers, if we prefer closed group (at start, anyways) - but connection speeds from Finland to US might not be high enough (as far as I know, correct me if I'm wrong).

[F. Scott Banks]

Wow, I love coming back to the forge...it's like a huge hug, a pat on the back, and a kick in the pants combined.  Welcoming, encouraging, and making sure you stay on task.

I'm definately down for collaboration (although I have no idea what connection speeds from finalnd to the U.S. are).  I think closed group would be best at first (I'm not opposed to sharing, but I'd hate to see someone beat us simply through sheer force of manpower) in order to build a solid foundation and in order to avoid posting long and boring technical documents on the forge where I'm sure most people are looking for die rolls, hooks and kickers.

Also, come hell or high water, I'm posting the game overview within the next couple of hours.  I'm repeatedly tempted to post everything in great detail, but if I keep it limited to character development/generation (some of you might rememebr from the last thread that the two aren't mutually exclusive..."It's a boy!  He's got his father's nose and his mother's  summoning ability."), actions (due to the computer interface, and to keep combat an integral, rather than a seperate part of roleplay, all character "actions" follow the same ruleset.  A mundane act like gardening follows the same laws as combat.  This means no break in the action if someone offends you while you're working and you decide to cut his throat for the insult), and backstory (race descriptions, the "culture" system, etc.), I should peel this out in about half an hour or so.

I was getting hung up trying to decribe the skills system, but since I simplified it for the computer, there's no need to turn it into rocket science for the Forge.

But lemme get the game laid out for the uninitiated before we start making changes and such to it.  I don't want someone coming to this and thinking they can't chime in because it looks like a work well underway.

- Wyld -

[F. Scott Banks]

The Dying Age
Multi-User Dungeon

Story:

It is the Twentieth Year of The Era of New Birth and the world of Eliam is on the cusp of a Dying Age.  The Yoloram leads his grey legion against the noble houses of the Meridian Kingdom.  Open war has trampled the old alliances and endless peace of ancient times.  The Yoloram's magic has perverted a conce beautiful landscape into a nightmarish wasteland and his armies slay all who do not submit to his rule.

These dark times need heroes...

Character Generation

Character Generation and Development is structured differently than in most games.  The usual conventions of "Strength", "Dexterity" and the like have been changed slightly to better refect the nuances inherent in this system.

Players will choose a race (later versions will implement the "Culture" system), a sex, and a name.  Then, with the template of their character set, they will go through the time honored process of rolling their stats.

Rolling beginning stats will occur in one of two ways.  A simple "stat generation" where each stat is set at 30% of it's maximum, and a true "roll" wherein 3d6 is rolled for each sub-stat.

Getting confusing?  Lemme throw the numbers up and maybe that'll clear it up some.

The Stats are as follows:

Power
Speed
Endurance
Allure

Knowledge
Insight
Resolve
Poise

If they seem broad and vague, it's because each stat hides two sub-stats.  Those are:

Power=Strength & Force
Stength is a measure of musclular limitations, defining how much a character can carry or lift while Force is a measure of explosive power, defining how hard they hit and how much mass they can move in one fluid gesture.

Speed=Dexterity & Agility
Dexterity is a measure of hand speed, defining how quickly a character can maneuver a sword or wield a lock pick while Agility is a measure of body speed, defining how quickly a character can dodge in combat or flat-out sprint should the need arise.

Endurance=Constitution & Resistance
Constitution is a measure of overall health and fitness whereas Resistance defines how "tough" a character is, acting as a measure of innate resistance to injury.

Allure=Appeal to Males & Appeal to Females
Allure, being a social stat is transitory.  Depending upon cultural standards, this number will vary depending upon the social interaction.  Allure combines with Poise to establish "Reaction" in social interactions.

Knowledge=Wisdom & Intelligence
Wisdom is much like force in that it is the application of intellect whereas Intelligence is a measure of how a character's memory and ability to retain information.

Insight=Perception & Accuity
Perception is a measure of how much a character can comprehend at any given time while Accuity is a measure of focused and intense mental concentration.

Resolve=Willpower & Determination
Willpower is a measure of how much abuse a character can take before their concentration breaks and Determination is a measure of how long a character can exert themselves mentally.

Poise=Passion & Opinion
This stat is unique, much like Allure, in that it is defined more by other characters than by the character that it applies to.  Passion is a rating of how you try to make other characters feel about you and Opinion is a rating of how you try to make other characters think about you.  The two stats effect each other as well, making it difficult for a character who passionately hates you to hold you in high esteem (it is however, possible to be disliked and respected or loved yet feared...not desirable scenarios, but attainable).

So, that's character generation...next post, gameplay.

[F. Scott Banks]

Okay, gameplay.  Also, it couldn't hurt to explain how that mismash of stats is configured for all my number-crunchers.

Essentially, the dual-stat system works like this, it's all percentages so I won't bother with numbers too much...

If a character's Power is, say 40% strength and 30% force, then their total Power is 70% of the total "possible" power for their race.  This 70% is the "chance of success" rating when performing a task that makes demands of a characters Power.  Note, the task itself may be of a difficulty that lowers the "chance of success" but we're all gamers here, I don't need to discuss in detail what a modifier is do I?  In any event, let's assume that the task isn't extraordinarily difficult, it just requires a certain amount of Power to perofrm.

Now, here's where the dual stats come in.  If the task we're trying to perform is, say, holding a door shut against an enemy, then it applies to the dual system like this.

Keeping a heavy iron door in place = Doors Weight vs. Strength.

Negating the attempts of an enemy to get through the door = Character Force vs. Enemy Force.

Not being murdered by Orcs = priceless.

This way, a single stat can be applied to several factors.  Also it prevents uber-characters because strength can fall to force (and vice-versa).  This is an implementation of a roleplay device in that there are different types of Power, Speed, etc.  Powergamers have to roleplay to an extent because developing characters this way is so involved.  Taking a back seat and grabbing the heaviest thing you can swing isn't a sure path to glory.

"But hey, I want to get my force as high as I can, does this mean I'm a hard-hitting weakling who can't lift a two-handed sword?"

Not really, although you can make a character like that (monks don't need heavy weapons or armor and may just want to focus on hitting as hard as they possibly can).  The 100% mark isn't a cap on your Power, it's just the end of conventional Power.  Heroes tend to be stronger, faster, and smarter than normal.  Even the strongest man looks pitifully weak next to Hercules.  It's possible to raise sub-stats to 100% even after their parent stat has peaked (in fact, it's the only time a player becomes aware of their specific stat-split).  

This is done through specialized training, as rewards for quests, and through the use of magical items.  If you posess as much physical power as any human in recorded history has ever posessed, lifting weights isn't going to cut it any more.  You're going to need to train with hermits on mountaintops and perform feats worthy of demi-gods in order to improve at that point.

So that should explain the stat system.  For those interested in the numbers, a "generated" character starts with 30% in each stat and can gain as much as 6% through training with each level plus a 2% increase in whatever stats were put to the greatest use between levels.

"Wait, you said there'd be no levels!!!  Liar!  Blasphemer!"

Well, a computer needs numbers to function.  And with any RPG, there are incremental improvements in a character's development that define a certain heirarchy of overall character effectiveness and efficiency.

"Levels" is just easier to say.

And with that said, the "level" system is too freeform to be defined easily.  Since characters increase their "level" through increasing individual skills, no (or at least few) characters at the same level are going to have the same abilities.

For example, a level one character is a character who has ten skills at 50%.  Any ten skills.  While a level two character is a character that has ten skills as 50% and five skills at 60 %.

"But there are ways around that system.  I could have a level one character who is superior to other level one characters!"

Then you'd be a good roleplayer.  Also, there are obviously degrees of level one-ness.  If a character has ten skills at 55%, one at 60% and four at 58%, then he's "better" than a character who only has ten skills at 52% isn't he?

Yep.

Also, I should probably note that, to a computer, it's possible for a character to have ten skills at 55%, one at 60% and four at 58% while only having ten skills,  If a skill has a value of 60%, then doesn't it also have a value of 55%?  However, the reverse it true where a player can have ten stats at 55%, one at 60% and four at 58% and have fifteen skills.  Depends on what skills you want and how eager you are to get them.  There are limitations of course (defined by Knowledge), but this system is extremely freeform.

How can that work?

This is where I get into the skill system (and finally describe gameplay).  Skills aren't as "open" as they normally are in some RPG's.  Since there are programmers trolling this thread (and posting to it, wassup shoka), I'll say that each skill represents a single mathematical value.

What?

Okay, skills work like this.  If you're good at performing Riposte, then that's a Skill.  If you're handy with a Rapier, then that's a Talent.  And if you use that Rapier in single-combat frequently, then Dueling is one of your Merits.  Just as it's possible to be a level one character with fifteen skills, it's also possible to have fifteen skills and only one talent.

My skill list is shorter than it should be to support this system (hence my overuse of combat references) but that's why I'm here, to grow it along with other parts of the game.

Anyway, lets get deeper into this skill system.  Again, it's designed to encourage roleplay by turning the established method of choosing skills to create a character into full customization of skills.

"I've seen riposte before, how's that new?  You're just adding lots of skills."

Not exactly.  Since Riposte defines a single variant on weapon use in combat (specifically, it allows for instantaneous counter-response to any physical action taken against the character), it's not as all-encompasing as some cases, nor is it as limited.  I've usually seen riposte limited to thin blades or swords or one specific sword.  In this system, riposte is a true skill wherein it can be used (attempted is more accurate) in any combat situation.  It can even be used in applicable social situations, such as grabbing your dates arm after being slapped for a rude comment or grabbing a tool in midair after its dropped.  

Combat is more linear, your purpose more clearly defined, so the examples of social interactions are merely instances in which something like riposte could be factored in.  Usually there are specific skills that apply in those situations.  "Nimble" is a Merit that allows for combat-level reflexes in non-combat situations.  If a player wanted to use a skill like riposte in order to improve their Juggling skill, they'd need that Merit.

The skill list I have in place isn't long enough to show many examples, but I think this example shows what we're shooting for.  It's involved, it's complicated, and it would cause any human GM to run screaming from the room (possibly crying and tearing at his fractured mind).

But since the GM is, in this case, a math processor...I think we'll be allright.

[shoka]

Since there are programmers trolling this thread (and posting to it, wassup shoka), I'll say that each skill represents a single mathematical value.

Duh. Got me. x)

The skill list I have in place isn't long enough to show many examples, but I think this example shows what we're shooting for.

Yeah, and I even think that if we get the basic principles of the system right, we won't even need so much different skills at the start - we'll just grow new ones as the system expands.. We could define the various actions in the game as combinations of required attributes (swinging a sword might require strength to wield it, agility to move it precisely and finally intelligence to know where to thrust the sharp end to).

Thus a character would need to meet the basic requirements to be capable of performing a certain action at all - then the skills would kick in and boost up the not-so-impressive initial result. By breaking down each task into basic elements we give freedom for the content designers (or GMs, if you prefer) by having a repository of generic actions out of which to excavate ideas. Should the task not fit to their specific requirements, it could easily be tuned by adding new requirements (perhaps this indivudual task requires a specific skill).

According to division made by WK, there are skills, talents and merits which affect various activities and when combined with physical and mental attributes I think we've got quite a good base for this. Various skills the character has could then affect different stages of action completion - some could improve the chances of success while others would affect just the result and not give any modifiers to the check itself. Like a fencing skill would make the character hit more often while anatomy would increase damage.

Programming-wise we would simply have each skill object the character is 'carrying' with him notified of each attempted action and provide an API through which those skills would be able to affect the outcome. Events would be posted on various stages and the skill implementation would only react to those it is concerned about. In an alternative model we would have all logic in task objects, which would browse through character's skills and note all affecting skill levels, then adjust the outcome according to those.

We'll probably need both models, as skills vary so much - in fact, I'd like to divide them into active and passive according to which model they fall into. Active skills might require the character to trigger them (or, be turned 'on') when attempting an action and would participate in resolving process; passive skills would just exist and be duly noted if defined as requirement for a task.

As you might notice, I *really* like the WK's idea of skills.. :)

I'm setting up the closed development environment, but it'll take couple of days as we're doing some adjustments to server configuration. For now, I'll need to know who and what I'm setting this up for - that is, what software and which accounts do we need? We'll probably get quite far with just CVS through SSH and a closed board for internal discussion (mailing list is another option, any preference?) but if somebody has any special requirements, please let me know as soon as possible.

That's it for now, boys and girls - maybe I should do some actual work today to justify being in the payroll.. ;)

[F. Scott Banks]

Hmmm...this is why I like having a programmer look over my stuff.  I was wondering how to divide the active and passive skills, since further on, some skills behave in a completely different way from others (I'd broken them down into combat and non-combat, but in my own example, combat skills aren't exclusively restricted to combat situations...hence my conundrum).

I think I'll get into combat a little later on today (I also have to justify being on payroll...and being on scholarship).  It uses the skill system to the greatest degree, combining skills, stances, and tactics to create customized fighting styles.  I've never liked the click-till-it's dead (or roll till it's dead) style of fighting.  Again, a pen-and-paper GM would probably snap under all the modifiers being applied.  Then again, maybe not...combat generally only has one, clearly defined purpose so while there are many modifiers in combat there is usually only one end result (or degrees of that end result).

So, if anyone wants to see their favorite widget in place, speak up.  Also, once shoka sets up this closed development environment (cool, I'm in the big leagues now...lol), most of the discussion will likely be contained there so if you're interested in seeing this through to the end, let a brotha know.

[shoka]

Yeah, we're set up now - at least initially, I'm still fixing some issues regarding security settings for the ssh accounts. But board is up and running, connection URLs and accounts will be supplied at request - please PM me or post here. :)

(I'm not posting any addresses here, as the group is currently invite-only - there isn't much to see without a validated account anyway.)