I would love to see some proper survival systems in the game and some proper cooking systems.

Also, for FutureMUD, I'd really love seeing MUDs where you actually have a sense of ownership in the form of houses and apartments, or even a shack. There should be the possibility of either offering the classical RPi apartments and then there should be the possibility of having actual spaces which could be owned by people.

If I ever host a MUD with FutureMUD, I would definitely have each house or shack built in an individual location, and hope that it can get customized by the owner.

A way to codedly bind someone so that they aren't able to move or attack. Maybe other options, too, like a blindfold/gag to stop them from being able to speak or see.

A chase or flee system that's entirely dependent on character skills/stats rather than a player's ability. By this, I mean in Armageddon for instance, being able to PK relied heavily on the player's ability to mash directions and 'attack x' before they left the room and as fast as humanly possible. Since I have one hand, this isn't something I've ever been able to do and viable concepts for what I can play are severely limited because of it.

Coded construction that doesn't require any admin assistance.

Realistic stealth or none at all. Make it so a player has to specify which object they're hiding behind or in. There's some places where hiding shouldn't be viable.

Telecommunications that can be compromised and listened into by someone with the right skills/equipment. I'd perfer they be phones, just so that text messages can be a thing and you can never be 100% that the person you're texting is the person they claim to be.

A combat system that allows weaker PCs to get the upperhand on stronger ones if the situation is right. Obviously, if you've invested in a combat character, you should be better at it than someone who hasn't, but there's times where that should be irrelevant, such as if a tough guy is attacked while sleeping or stabbed at from behind while unarmed. It shouldn't be easy to draw a weapon once combat has started.

Not sleeping for extended periods of times should cause illness/debuffs, imo, since no one should feel completely safe all the time, regardless of how badass you are. By this I mean sleeping in game and not by having quit.

SomeKnob wrote:Realistic stealth or none at all. Make it so a player has to specify which object they're hiding behind or in. There's some places where hiding shouldn't be viable.

I really really really wish I hadn't let the old freeforums forum slide...I had such a good long post explaining how stealth worked in FutureMUD, but alas even options like the Wayback Machine didn't archive the forums over the period the post was up. Ah well.

At a very quick level, here's a series of dot points on how stealth (which is really perception) works in FutureMUD:

There are four basic "senses" that are relevant for the stealth system - sight, hearing, smell and "sense" (the latter of which represents magical/mystical senses that you may want to include in your MUD). Sight is the most important - if you can't see someone, at best you can tell that there is -someone- stealthing about, but the others can be used too.

Perception is also done through different "PerceptionTypes" - such as "Visual Spectrum" or "X-Ray" or "Psychic Sight". Different races can be set to see in different spectrums, and effects or tech could also add additional perception types (e.g. infrared goggles). Spells/effects could hide you from particular perception types (or all perception types, which would be the usual).

Whether you can see someone is independent of whether other people can see someone. Just because one person spots a hiding person for example, does not remove the hidden effect from the person. It merely means that you can see the hidden person.

Perception tests last for approximately 30 seconds (depending on perception) until they go stale. This means that just because you spam LOOK doesn't mean you'll get to spam your perception test - your result against a particular person is fixed for a certain duration.

Difficulties for all perception tests are effected by light levels and terrain types. When I do weather, weather will factor in as well. For example, perception in a jungle is much harder than perception in a barren, rocky field. Perception is harder when it is darker. Perception would be harder in the driving snow than it would be in clear weather.

Difficulties for hide tests are also terrain dependent. Hiding in a "Junkyard" terrain might be much easier than hiding in a "Plains" terrain. Sneak tests are also terrain affected but the difficulty is separate from hide - it might be easy to hide in a forest, but I daresay it's harder to sneak.

Hiders can reveal themselves to individual people without giving up their hiding spot. This is like the person automatically spotting them. Similarly, people can point out the hider to all present or specific people. In both cases, when "person limited" reveals are made, other people have another chance to spot them (effectively any non-stale failed test is removed and they get another shot) - presumably they notice the exchange.

When you hide in a room where other people are, all the people currently in the room automatically see you and get the effect so long as they remain, but new people entering the room would not.

Many actions that you take while hidden will give people another chance to see you, but still don't necessarily remove your hidden status.

Sneaking is a mode rather than an action - e.g. you don't "Sneak N", you "sneak" and then regular movement commands become sneak attempts. If you are hidden when you sneak, you will also be hidden in your new room. You can sneak without being hidden and while people won't notice you enter, you won't be hiding when you get there.

SomeKnob wrote:Hidden emotes.

These already exist. There is an HEMOTE command (for hidden emotes) and SEMOTE command (for silent emotes). Hidden Emotes require someone to pass a notice check to see them - they are for actions which are subtle and might not be noticed. Silent Emotes are for actions which make no noise (and incidentally you cannot include speech in silent emotes), and silent emotes can be used while hidden without immediately revealing yourself to everyone.

The rest of the stuff you both mentioned is definitely on the list but not necessarily in yet. Blindfolds, gags and the like will probably be in soon (because they're easy). Binding will probably work with the limb system that I am working on as part of combat - you would bind specific limbs which would prevent them from being used. You could also cripple a person's limb for the same effect - break a leg or tie them up, depends on how you want to swing it.

Coded construction will not be in for the short term in LabMUD, but is definitely on the list. It's important to do right and it would be a complex system, so it unfortunately has to take a back seat to the other more critical stuff to work on for now. I would eventually like to integrate it with character creation (so most people come into the game with somewhere to live) and potentially address SomeKnob's "Not sleeping for extended periods of time", which I would probably render as "Being homeless for extended periods of time". The assumption would be if you don't own a place or aren't renting a room, you're sleeping rough, so you get penalties. Maybe I can even tie it in with the crime system eventually?

Telecommunications is actually going in early LabMUD. I will consider interferable/interceptable communications when I lay down the design.

The chase or flee system you mentioned is likely to be addressed by the way I am intending to do combat, but I feel like it deserves its own explanation (but I will have to give that later).

I've always wanted this. 1) because I enjoy the idea of being able to create something from nothing and 2) because I hate admins.

SomeKnob wrote:Not sleeping for extended periods of times should cause illness/debuffs, imo, since no one should feel completely safe all the time, regardless of how badass you are. By this I mean sleeping in game and not by having quit.

This is a tricky one. While I personally am in favour of penalties and "exhaustion" creeping in after PCs have been active for a period of time without codedly sleeping, I also can understand the arguments against forcing people to sleep. Namely, that everyone has only a limited amount of time to play each day, and nobody wants to spend a portion of that time idling in a room, vulnerable, doing nothing when they could be doing something.

Japheth and I have talked about implementing a system where you can divide your PC's day up into tasks they accomplish offline. We never really went into specifics about it, but how I imagine it working is that every PC has a set amount of time counted toward offline play. You determine how that offline time is "spent" and things accrue or occur as a result. You might set your PC to labour menially, or sleep. There might be a way to "spend" several of these hours training, to prevent skill degradation (if that does ever become a thing.)

That might be the best compromise I can see in regards to forcing sleep, though: require it, but give players the option of having their PCs sleep while they're offline. Otherwise, it becomes too much of a punishment for a casual player who doesn't want to get pigeonholed into a "casual" role (social/crafter.) (Or you end up with ARM situations, where a whole bunch of combatants curl up in a tent and sleep for 5 minutes after every mile they've walked, with zero RP surrounding it.)

SomeKnob wrote:Warnings when someone walks into the room armed.

Not sure how much work this would be, but it sounds like it could be a relatively simple addition to the code that could be toggled on and off at will by the player on their account.

lawedan wrote:proper survival systems

The best survival system also hinges on a solid crafting system at its core, in addition to a forage system and a hunting system that is separate from the aforementioned crafting system. It also requires, IMO, a predator/prey model and a wildlife spawning system that is more than just "on crash or on hour, spawn x mobs in y room and walk up." I would kill to see predation, over hunting, seasonal change and lack of food source all affect the amount (and quality) of mobs that are spawned at any given time.

The crafting system, obviously, is important because at some point you need to be able to make something from nothing. It drove me crazy on SOI when I was out in the middle of the harsh, unforgiving wilderness, struggling to make a campfire to stave off the night and the cold, and couldn't because there was no flint and tinder kit lying around, or because I had object A when what I really needed was the slightly different but functionally similar object B.

Japheth has put the forage system in place, and I think it's actually pretty decent, but I haven't tested it out extensively or anything yet either.

But that said... LabMUD won't likely have a proper survival system in place. FutureMUD, undoubtedly, will. MUDs that are made in later iterations of FutureMUD, undoubtedly, will. But there are higher things on the list of priorities now that make it, at best, a later addition to LabMUD.

lawedan wrote:some proper cooking systems.

I've never been big on the crafting side of RPI MUDs, mostly because I haven't seen a crafting system yet that I actually liked. That said, I think the knowledges system, coupled with whatever crafting system Japheth puts in place eventually, could make cooking actually worth a damn.

It might be a thing in LabMUD, and it might not. There are certainly conditions in the game world that would make a cooking system important. But even if it's not in LabMUD, I don't doubt it'll crop up in other games - especially fantasy ones. Anything with a remotely medieval or late medieval vibe usually has pages and pages of descriptions of food, and crafts to go with it.

lawedan wrote:I'd really love seeing MUDs where you actually have a sense of ownership in the form of houses and apartments, or even a shack.

Me too. I should have put that on my list, along with a farming system that is separate from crafting and is influenced by weather and terrain type, and has timers on it that are as long as seasons, or even decades.

I have two MUD ideas floating around waiting for a (more) full release of FutureMUD: Beyond the Door and ArmorMUD. Beyond the Door is the medieval peasant simulator one, and thus relevant to the discussion. In it, ideally, no one will be "homeless" - everyone will either have a house, a guildhall, someone else's house (if they are an apprentice), a farm & farmhouse, barn (if a farmhand, etc.) or a hovel somewhere. I hate how the majority of PCs in MUDs just "exist" - when they are online, they're active, and when they're offline, they're... sleeping somewhere in a gutter if they're mentioned by others at all. So I want everyone to have a home somewhere to go back to, even if it's a shitty one, and for the truly homeless people to be so only by choice - ie, they're playing a homeless person specifically. In addition to that, I want roles to open up to family roles in addition to RPP race/special perks/etc. roles. I want PCs who run a farm able to put up a role call of their own, with admin approval (accepting or declining an already written role) for farmhands, for family members - brothers, cousins, etc.

It was just frustrating for me that in certain games you could never get the upper-hand on a more skilled opponent regardless of how careful or patient you were. Characters wouldn't fall ill, wouldn't sleep, lived in heavy armor 24/7 in a desert, and were rightly confident that you could never be a threat to them in any situation that requires code. Literally the only thing you could do was hope to stumble upon them when they were badly hurt (even then you'd have to be similarly skilled to hope to land a hit) or wait for them to end up crossing a bigger badass who you could work with.

If there's a system intended where limbs have health and you can't just rest until they magically recover in five minutes, coupled with coded illnesses, then that should be more than enough to stop combat monsters from feeling and acting as though they're invincible.

I feel you. Characters wearing armor 24/7 has always been a problem in RPI MUDs, because players realize they're vulnerable outside of armor, and realize they can get away with simply not roleplaying that they're wearing heavy armor 24/7. The way to stop that isn't with code, IMO, but with building practices and proper staff oversight. It'd be helped by a few code additions here and there, but the reality is that if some staff member had put their foot down, the problem could've been resolved ages ago.

Another big complaint I have personally is the weapons and sheaths situation. In RPI MUDs, there is a strap, harness, sheath or scabbard for every stupidly exotic weapon available - and even for improvised weapons. I hate how Johnny Peasant can walk into a bar and sit down with three spears strapped to his back, an axe at either hip and clubs tucked away up under his armpits.

Going back to Beyond the Door as an example - I don't want people to walk around armed all the time, unless that weapon is a symbol of their rank or authority. Only swords and some knives really should have scabbards, and everything else should be picked up, utilized, then set down again. Even most swords, for common folk, should be hung up on the wall and rusty, some ornamental memory of their great grandfather's time spent in the army.

Robots: the ability to build robots with some constellation of programming and mechanics etc.

"Out of body experience": (presumably) for games with a fantasy or cyberpunk setting - the ability for a player to navigate a sort of "alternate map" (understood icly as "the net" or "the spirit world" or what have you) while leaving their body...wherever they left it.

Environmental effects: again, probably more FutureMUD than LabMUD given my understanding of the setting. At its simplest - increased stamina drain for actions in a room where the temperature is outside a certain "comfort zone", with increased penalties as distance from comfort increases. Worn items (coats, gloves, shoes/boots, etc) can increase/decrease the effect. Can be extended into certain room conditions causing certain kinds of damage (eg. smoke inhalation or radioactivity) again with worn items (gas mask, hazmat suit, magic talisman, etc) to mitigate.

Contagion: mostly calling it that to differentiate from "infection" which already exists and is specific to wounds... Bacterial/fungal/viral/magical infections (a magical "infection" more likely being called a curse or hex) producing a set of symptoms, which may vary according to degree of infection. The possibility of transmission by various means.

Nutrition (and malnutrition): Probably best kept simple, with broad categories like "protein" and "vitamins" in addition to caloric intake. Encourages pcs to eat a more "balanced diet" as they won't starve on bread and water, but they might develop scurvy.

Poisons: inhalation, injection, ingestion or dermal reactions to plant and chemical toxins or animal venom producing a set of symptoms

Possibly some system of "building upkeep" (especially for constructed buildings, lest the world become cluttered with abandoned hovels that never decay.) It would be particularly nice if the "interior" descriptions reflected the condition of the building

More wear and tear, maintenance and cleaning generally. Things like crafts or actions that apply "dirt" to a room (think bloody abbatoirs and sooty kitchens), clothes that get rumpled or dingy over time if worn (but can be brushed, pressed or laundered), furniture that gets dusty and machinery that needs to be maintained. Also a way for an npc to do it for you, so Lord Fancypants isn't stuck scrubbing his own toilets due to a lack of pc housekeepers.

And my most outlandish suggestion (not so much in terms of realism, but in the sense that I have yet to think of a way it could be implemented that isn't overly complex or resource intensive):

A clear, publically posted policy on what is and isn't appropriate to ask the staff for, and instructions on how to make requests. Some players (and admins) take a hardline stance that everything should be acquired in-game through IC means, others see nothing wrong with requesting animations, custom objects, rprogs, or inclusion in plots. This can lead to frustration and resentment when player X, who has been trying unsuccessfully to schedule a meeting with the boss for five years without so much as sending in a log of his troubles, discovers that player Y got her awesome secret base/jetpack/mission just by asking. Or player Z's hurt and confusion when a staffer bites his head off for petitioning "Hey, what's up/Is that you?/Thanks for the awesome animation" without realizing that petition is considered akin to calling emergency services which you do not do "to be friendly"

incognito wrote:Robots: the ability to build robots with some constellation of programming and mechanics etc.

Definitely on the list.

incognito wrote:Environmental effects: again, probably more FutureMUD than LabMUD given my understanding of the setting. At its simplest - increased stamina drain for actions in a room where the temperature is outside a certain "comfort zone", with increased penalties as distance from comfort increases. Worn items (coats, gloves, shoes/boots, etc) can increase/decrease the effect. Can be extended into certain room conditions causing certain kinds of damage (eg. smoke inhalation or radioactivity) again with worn items (gas mask, hazmat suit, magic talisman, etc) to mitigate.

I give my ironclad guarantee that lab subjects will be exposed to radiation and extreme environmental effects in the Lab.

incognito wrote:Nutrition (and malnutrition): Probably best kept simple, with broad categories like "protein" and "vitamins" in addition to caloric intake. Encourages pcs to eat a more "balanced diet" as they won't starve on bread and water, but they might develop scurvy.

I have struggled with how to make this work conceptually while the player is offline. I am of the opinion that to some extent you should assume the player is doing anything tedious offline (like balancing their diet). It's not very difficult to implement a system like this in the game but making it work for the players is something I am not convinced can even be done.

incognito wrote:A clear, publically posted policy on what is and isn't appropriate to ask the staff for, and instructions on how to make requests. Some players (and admins) take a hardline stance that everything should be acquired in-game through IC means, others see nothing wrong with requesting animations, custom objects, rprogs, or inclusion in plots. This can lead to frustration and resentment when player X, who has been trying unsuccessfully to schedule a meeting with the boss for five years without so much as sending in a log of his troubles, discovers that player Y got her awesome secret base/jetpack/mission just by asking. Or player Z's hurt and confusion when a staffer bites his head off for petitioning "Hey, what's up/Is that you?/Thanks for the awesome animation" without realizing that petition is considered akin to calling emergency services which you do not do "to be friendly"

It is my understand that the way Wolfsong intends to run LabMUD is that if you can't do it in code, you can't do it. Any other such requests should be made IC and will be dealt with IC.

There are three essential design elements on my combat wishlist, but they interact in such a way as to create a system in which each part is reliant on the others. Simply put I would like for combat to be:

SLOWER, STRATEGIC, and COLORFUL

SLOWER: I'd like for players to be able to have the time to read and respond to what's happening in combat.

STRATEGIC: I'd like to see more actions that could be taken in combat. Actions would fall into two major categories, which I'll call “continuous” and “specific.” A “continuous action” would be similar to (but more specific than) combat “stances” or “styles” and would represent a kind of action that the character attempts to maintain until interrupted or discontinued. Block, dodge, strike, even “taunt” or “distract” could be kinds of continuous actions. Continuous actions also allow for fun calculations, like the stamina drain of dodge being mitigated by both agility and dodge skill, whereas block's stamina drain is mitigated by block skill and strength. Specific actions would be actions taken as an individual attempt to produce a specific response, and may or may not be dependent on the current continuous action.

Both specific and continuous actions could have advantages and disadvantages against other specific and continuous actions. With high intelligence or perception you may be prompted with appropriate strategy suggestions when “openings” present themselves.

An individual's skills and stats could also be an element in overall strategy; for example, one character may find it advantageous to duck and weave until their opponent has exhausted themselves before running away/moving in for the kill, whereas another may find it more effective to try and land a few good hits in at the beginning before they start to tire and find their accuracy or hit strength dropping.

COLORFUL: I could go on at length about the problems of emoting in combat but the most salient point is that it is strategically disadvantageous.

To resolve this I propose the always controversial “involuntary emotes.” Example: “<character> yelps/grimaces/remains stoically unmoved as blood oozes/runs/gushes from <wound>”, checking against will, severity of injury and rate of bloodloss. These involuntary emotes serve two purposes, one is the obvious “immersive” element of letting the code cover the descriptive flourishes, the other is the use of these messages as “cues” for strategic actions. It could possibly even be set up in such a way that what you see is dependent on your own skills and stats, eg high perception could allow you to pick up on your opponent's relative fatigue, whereas a combat medic might notice a troubling injury on friend or foe

Ideally this would lead to a system in which strategy becomes more about actions taken than “build” which, in turn, allows discussions of strategy to be something that happens in-game and in character. A sparring session might actually be something where you learn to recognize and react to certain kinds of openings, rather than a simple matter of time spent → skill gained, and where a veteran combatant makes for a desirable training partner because they have a broader range of “moves” to train against.

Needless to say I'm very excited to see how combat plays out and develops.

Yet another thing I'd like to add to my list is completely nerfed training weapons. Of the many problems of the old "spar to three stars" system, possibly the most poisonous (imho) is the way it would devalue injuries sustained in actual combat, which in turn drives the "dab dab, you're fine" model of medicine.

I'd love to see people spar for time, or points (like every real match I've ever encountered), I would even settle for exhaustion. Stopping due to pain or stun are at the outer edge of my tolerance, but regularly practicing until someone is seriously injured is immersion shatteringly absurd. The fact that they will be better tomorrow does not help.

Of course there should be room for "accidents", it shouldn't be impossible for people to get hurt. Hell, I'm in the camp that believes crafting should be more dangerous. I'm just advocating that it be the exception, rather than the rule.

incognito wrote:Yet another thing I'd like to add to my list is completely nerfed training weapons. Of the many problems of the old "spar to three stars" system, possibly the most poisonous (imho) is the way it would devalue injuries sustained in actual combat, which in turn drives the "dab dab, you're fine" model of medicine.

I'd love to see people spar for time, or points (like every real match I've ever encountered), I would even settle for exhaustion. Stopping due to pain or stun are at the outer edge of my tolerance, but regularly practicing until someone is seriously injured is immersion shatteringly absurd. The fact that they will be better tomorrow does not help.

Of course there should be room for "accidents", it shouldn't be impossible for people to get hurt.

This is within scope of what I intend to do in LabMUD. Points-based spars or rules-based fights (a duel with real weapons to first blood for example) will not be in on day 1 but the system I am making is designed with that as an extension goal in the near future.

I also intend to do laser-tag and/or paintball-like options for ranged combat when that goes in too. Realistically it's just a matter of building the weapons that way. Not sure what I will do with regards to the same kind of rules-based fights yet for ranged combat - we shall see.

incognito wrote:Hell, I'm in the camp that believes crafting should be more dangerous. I'm just advocating that it be the exception, rather than the rule ... Also, crafting should be more dangerous.

cook vegetable-soup
You begin to cook a hearty vegetable soup, starting by chopping the vegetables.
You have tripped and fallen and impaled yourself on the kitchen knife!
Blood gushes from a grievous slash on your throat!

I am hoping for a nice solid crafting system that allows a lot of room for customisation and being creative. This is mainly because I am the crafty sort. I'd like it to have realistic timers, but that allow you to use offline time / energy as well. For example; people who craft a full ball gown in ten minutes really bugs me. By the same token, I'd like to not spend the next four days, eight hours online working on a dress when I could be rping (though rping WHILE crafting is often fun too!). I think that they idea of using offline time to either sleep / train / craft etc would be a very interesting element.

A point command that allows you to target things that aren't in the room, but are in your "line of sight".

I'm actually pretty intrigued by Zargen's impromptu weapons proposal.

Although most objects would presumably have damage calculated by weight this poses an issue for items like "a scalpel" or "a piece of broken glass." So that builders wouldn't have to individually specify damage potential for each item there could perhaps be something akin to a "sharp" flag that adds additional damage. You could even include a whole shiv production suite, allowing players to apply the "sharp" characteristic to things like spoons and toothbrushes.

There could also be a similar "nowield" characteristic for particularly cumbersome objects that characters could reasonably lift, but would be hard pressed to use as a weapon (a large box of towels for example.)

Conversely you could flag certain items as "safe" to ensure that no one is hurt during a pillow fight, without having to make soft objects improbably lightweight.

As for crafting- I'd personally like to see a move away from the branching specific crafts model, and the weirdness therein (I can make a roast peacock, but not a green salad? I can make an axe blade, a sword hilt, and three different sizes of mace heads but no finished weapons?) The Knowledges system seems very promising, and I'm very interested to see how it plays out.

Not having given it a great deal of thought, my first stab at a system I'd prefer would be more of a processing model where your Knowledges control what can be converted into what else, and your Skill determines both your success/failure rate and the quality of the finished product. While there is room in that system for specific crafts, I'd like to see them tied into Knowledges, and granted as a set. Certain materials may be easier or harder to work with, and certain knowledge/craft groups may branch into other, logical groups. I suspect that some interesting things could be done with specializations and dependencies, but like I said, I haven't given it a lot of thought.

Also, on the subject of craft timers:

I'd like to see them lowered but instead of performing a two minute craft with a two hour timer, I'd like for it to be set up in such a way that the timer is advanced so long as the crafter is in the room with the timered object.

Of course there should also be a bank of offline hours that you can alternatively apply to advance the timer.

With good building support for communal crafting areas it should actually encourage people to craft and RP at the same time, to in fact play crafters.

This does mean that players should be able to put down what they're working on and pick it up again later, so that they're never Stuck Crafting. It also includes the possibility of other players advancing a project someone else started.

incognito wrote:With good building support for communal crafting areas it should actually encourage people to craft and RP at the same time, to in fact play crafters.

This does mean that players should be able to put down what they're working on and pick it up again later, so that they're never Stuck Crafting. It also includes the possibility of other players advancing a project someone else started.

I really like these ideas. What might also be cool is to be able to craft with other crafters. Like having apprentices working the bellows means that you don't have to stop and start the time sensitive moment of forging a blade.

I've mentioned this elsewhere, but I've always thought that one of the weaknesses of the base RPI system is its reliance on 'timers' when there are really a wealth of superior options available. SoI has their modified system, but it still relies on time, as do skill timers.

What if, rather than imposing a timer, skill gains and crafts created a roleplay 'quota' that would need to be filled before doing the next craft, or gaining the next skill? In conjunction with communal crafting areas and team-oriented crafting or crafts that require apprentices, I think this would be a monumental improvement on the traditional RPI system, where I honestly have always felt like the nature of the crafting game actually causes it to take more away from the game than it adds.

One of the ways in which FutureMUD differs with skills gains compared to other MUDs is that it can be configured for gain on success or gain on failure, and there is also a difficulty-based threshold.

In the RPI Engine (and Diku more generally), skill ups are on failure, the logic being that as you get better at the skill, you fail less often - so that will slow down skill gain. This kind of thing creates a weird incentive where (in Armageddon for example) to get to the highest levels of skill, people seek out really bad items that give them penalties, and do things like sit down in combat to fail dodge. In other words, they stack themselves with penalties so that they fail. Still, skill advancement in Armageddon is tuned to be very, very slow - you have to be either long lived or non-casual to max things out in general.

In LabMUD, I have set skills to improve based on success only - you actually need to succeed at the skill to learn. This might seem like it would slow down skill gain at the beginning but there are actually many ways to get very large positive bonuses on tests so that if you're taking baby steps in a skill, you really do take baby steps and learn something.

I've also set a difficulty threshold so that every x points of skill you get, you only get a chance for skillup above the next level of difficulty up - so by the time you're getting to high level of skill, you actually have to be doing hard things and succeeding at them to skill up. Thus, say you had some junk craft that was dead easy, you wouldn't be able to grind up your cooking skill to grand master by churning out five billion "boil water" type crafts. You'd actually have to be doing crafts that were appropriate for your skill level.

Similarly, if you're just a novice cook, you're not going to really be learning much from spectacularly failing at making Croquembouche or Snow Eggs or some other ludicrously complex dish. But successfully hard boiling a few eggs might teach you a thing or two that lets you develop your skills.

Nonetheless, I will still have some short timers on the skill gains so that you can't just jump up spectacularly in one session - but they won't be the primary control of progress of skills. I think that the need to seek out difficult challenges will actually be quite a good balancer.

This will be true across the board, from language to combat to crafts to everything.

Incidentally Incognito you hit the nail on the head with knowledges, which will be the primary way by which access to crafts is controlled. Knowledges can be set to be gained as you skill up in a skill, they can be taught and I'm also planning for there to be a way to "research" knowledges you don't know (but know of), so that through trial and error you can eventually figure out how to do certain things. The latter part is not in yet but the other two are.

In my experience fights in the RPI engine generally end at death, unconsciousness, or surrender, which tends to shift control to the losing side. Given FutureMUD's calculation of relative advantage I'd love to see a Subdue-type Move or Strategy which allows for the side with the upper hand to essentially “pause” combat or Engage without attacking. This could be used to demand surrender in situations where you want to keep your opponent alive and beating them into unconsciousness is too risky, or in situations where you just want to give both sides a chance to do some dramatic emoting before you deliver your deathblow.

There should, of course, be a chance for the subdued party to try and escape, or make some other appropriate move, which, on success may provide a sort of “attack of opportunity” for the subduer, the nature of which may be determined by their Strategy (eg. Defensive → release, Aggressive → stab.)

As indicated by the above example this interpretation of Subdue does not exclusively imply grappling holds, but could apply to any situation in which one party has the other at a significant disadvantage. Thus the logic can be extended to pre, or peri-combat situations, for example “the ambush.”

A traditionally divisive subject; surprise attacks have a tendency to arouse contention over one party “going straight to code” with no (visible) rp, versus the legitimate counter-argument that there is very little recourse for the assailant who sacrifices their code advantage for rp, only for their target to suddenly develop magic ninja skills and backflip away.

Allowing players to hold their unsuspecting/heavily outnumbered/etc opponents at gun or knife point without actually attacking them (but with the code restrictions of the combat state) enables players to realistically distinguish between coercion by violence as opposed to the threat of violence without having to rely on good sportsmanship to prevent the victim from streaking off at a diagonal, unfettered