29 Aug, 2012, KaVir wrote in the 1st comment:
Votes: 0
Today I read a blog post from someone talking about afflictions, which they described as "a part of MUDs that makes MUD combat so in-depth". While it can certainly add depth to a combat system, it's the sort of interactive depth that (in a real-time combat system) scripts can handle much better than humans.

That then reminded me of a comment I made elsewhere, that "when taken to the extreme (scripting is required to compete) you're effectively back to an automated combat system".

Which makes me wonder…if the goal is to encourage manual combat, is a detailed affliction system a counterproductive feature?
29 Aug, 2012, arholly wrote in the 2nd comment:
Votes: 0
I originally had a much longer post typed up, but scratched it. I think if you give your manual combat system a lot of detail, then as a by-product, you are generally going to see a similarly detailed affliction system. Or, it may appear to be a more detailed affliction system but in reality you just have a bunch of things renamed which do the same thing.

Example Affliction: Blindness
This can be used to cover a wide variety of situations (dirt kicking, magical, eye poking). Players might not know it is the same affliction because it is delivered different ways. You could have different ways to remove it, but effectively, they are all doing the same thing (removing the blindness affliction). Where this becomes tricky is when players figure it out. If a flush eye command was made to counter dirt kicking, players will eventually realize it could be used against ANY blindness. So, then you might have to resort to making each type of blindness it's own affliction with it's own cure.

I guess it really depends. I think hardcore players are going to use scripting regardless. Casual players far less so.
29 Aug, 2012, KaVir wrote in the 3rd comment:
Votes: 0
arholly said:
I think if you give your manual combat system a lot of detail, then as a by-product, you are generally going to see a similarly detailed affliction system.

There are many other ways to add detail to a combat system, and not all of them are reactive.

arholly said:
I think hardcore players are going to use scripting regardless. Casual players far less so.

The real problem isn't so much people choosing to use scripts, it's when they're required to use them in order to compete. The more speed-critical reactive commands a player needs to execute, the more important scripts become - and if your stated goal is to have a manual combat system, it strikes me as counterproductive to offer features that strongly encourage and reward automation.
29 Aug, 2012, quixadhal wrote in the 4th comment:
Votes: 0
Afflictions (debuffs in the MMO world) themselves are not counterproductive to manual (interactive) combat… however, if your afflictions are designed so they can be instantly countered, they will be scripted.

Simple example, let's suppose you are attacked by a character who uses a weapon/skill that causes a bleed debuff. By itself, it simply causes you to lose a few hit points per combat round. You may well choose to NOT counter it, using your action for another attack instead. However, having the bleed debuff might also make it possible to stack additional debuffs which can only happen while bleeding. If your opponent starts using these combos, you may find yourself at a severe disadvantage with multiple conditions all hindering your abilities.

So, the question is, how well thought out is your debuff system? Obviously, removing a debuff requires one (or more) actions, which means you aren't attacking or defending properly while dealing with them. But, to keep them from being overpowered, there also has to be some advantage to the attacker to NOT use them. Maybe they have to decide between stright-up damage vs. very minor damage + the debuff (which might also get a seperate hit roll). If the attacker spends all their time trying to get a debuff to stack, you might be able to win just by ignoring them and going for all-out attacks, since one would think an attack which is attempting to poison or bleed or blind might be slightly tricker to accomplish, and thus provide additional openings for ripostes.
29 Aug, 2012, Runter wrote in the 5th comment:
Votes: 0
Afflictions and debufs, etc, are really just states that change the parameters of a fight. From something basic like deals some damage, or something advanced like makes healing ineffective, etc etc. Stances and other things that change the parameters of the fight can be just as script driven. It's a problem if you care about "manual combat," whatever that is. I think it boils down in my opinion to your game valuing strategy over tactics, or vice versa. If it takes a script to keep 100% uptime of a vital debuf then it's tactics driven. An example of how the very same debuf could be strategy driven is if it read something like "Opponents always have this debuf" without needing to apply it. The higher the granularity of needing to reapply it (like every 5 seconds) the more tactics driven it is. I don't know what the answer is, but while people don't seem to care about even more disenfranchising concepts in muds…like the edge of being an expert typist, or grasp of english language…I'm not terribly concerned with this one as long as it's not too much.

Also, I think the discussion goes for more than just afflictions and debufs. It applies to more than just combat driven games.
29 Aug, 2012, Idealiad wrote in the 6th comment:
Votes: 0
For me manual combat is about making choices during the fight. Automatic combat is about typing 'kill rat' and waiting for the fight to end. Needless to say there's a continuum between the two.

It's only a problem if a mud advertises itself having 'manual, in-depth combat' when its combat is affliction-based (at least as most afflictions are implemented in muds today). If a player wants manual combat they're going to be disappointed. I'm not sure if any affliction-heavy mud touts manual combat as a feature though.
06 Nov, 2012, Nathan wrote in the 7th comment:
Votes: 0
Well, the resource intensive way to get around is to make an affliction just a state of the player. I.e. they actually have dirt IN their eye, so a blindness removal spell would go off without effect. Of course then you have to consider whether you want an eye flushing command or a general system that allows you to pour water in your eye or something.
06 Nov, 2012, Barrons wrote in the 8th comment:
Votes: 0
you don't necessarily have to have many different blindness afflictions, perhaps just a GIVEN_BY flag… (pseudocode) this.player.blindness.GIVEN_BY = "magic", that.player.blindness.GIVEN_BY = "dirt", then the check is coded into the skill… "flush eyes" would be something like if player.blindness.GIVEN_BY["dirt"] do cure(blindness,"dirt") else do msg("You flush water in your eyes, to no effect.")

edit: that was a very contrived example, I know in a real system affs are probably not mapped to the player in that manner. Heh.
07 Nov, 2012, quixadhal wrote in the 9th comment:
Votes: 0
You don't want to embed such things directly in the player object, as that means every time you think up a new one, you have to modify the (mission-critical) player object.

It's far more sensible to implement a stack of conditions, so whenever something bad happens, you push that condition onto the debuff stack, and good things are pushed onto the buff stack. When checking conditions, you simply iterate over the stack in your combat code. If you keep the stack ordered by duration, as things wear off they get popped and removed.

If you try to track specific conditions by source without using a stack, you can't have multiple sources. In the above example, what if a mage casts 'blindness' on you and then a thief kicks dirt in your eyes? The "cure blindness" spell should still remove the magical blindness, even if it doesn't remove the dirt.
07 Nov, 2012, Scandum wrote in the 10th comment:
Votes: 0
KaVir said:
Which makes me wonder…if the goal is to encourage manual combat, is a detailed affliction system a counterproductive feature?

It is indeed counter productive. You want to design a system where a player decides on a meaningful action every 8 seconds or so. The WoW cooldown concept could be used, with of course longer and more meaningful cooldowns, and add diminishing returns and combo bonuses while at it. If you attack someone in real life with the exact same blow they'll quickly adapt to it, the same mechanism can be implemented in a game world, though then you have the problem of adding meaningful alternative attacks.

From a perspective of added complexity roomless MUDs are a poor design choice because in most cases you end up going from many rooms to a few rooms, decreasing complexity. Assault was a good example of a MUD where the room model proved to be a crucial aspect of entertaining PK combat with the grid functioning as a game board. I don't think anyone managed to fully script Assault combat. I'd even suggest taking this one step further by making furniture inside a room a meaningful component of gameplay.

From what I've seen IRE uses a hundred affections that all work more or less the same way, ideally you want game components to interact with each other so complexity increases exponentially. Having 20 variants of fireball doesn't add real variety, and as such it doesn't add complexity.
07 Nov, 2012, KaVir wrote in the 11th comment:
Votes: 0
Scandum said:
From a perspective of added complexity roomless MUDs are a poor design choice because in most cases you end up going from many rooms to a few rooms, decreasing complexity.

No, the roomless model doesn't decrease complexity. However it does make it easier to add certain tactical features, such as variable movement rate (including fleeing, leaping, knockbacks, etc), weapon reach, ranged attacks, area of effect attacks, facing, visibility, and so on.

Scandum said:
Assault was a good example of a MUD where the room model proved to be a crucial aspect of entertaining PK combat with the grid functioning as a game board. I don't think anyone managed to fully script Assault combat. I'd even suggest taking this one step further by making furniture inside a room a meaningful component of gameplay.

Whether people can script or not has nothing to do with the mud being roomless.

Scandum said:
From what I've seen IRE uses a hundred affections that all work more or less the same way, ideally you want game components to interact with each other so complexity increases exponentially. Having 20 variants of fireball doesn't add real variety, and as such it doesn't add complexity.

Complexity for its own sake is something I'd always consider undesirable, but that's not the point I was making. The issue is that "when taken to the extreme (scripting is required to compete) you're effectively back to an automated combat system".
31 Dec, 2012, Kastion wrote in the 12th comment:
Votes: 0
Scandum said:
Assault was a good example of a MUD where the room model proved to be a crucial aspect of entertaining PK combat with the grid functioning as a game board. I don't think anyone managed to fully script Assault combat. I'd even suggest taking this one step further by making furniture inside a room a meaningful component of gameplay.

I did something similar to this over a decade ago on a MUD I ran. I had a hybrid ASCII map system - I used the conventional room system but each room had a grid you moved around which played a big role in combat. Items in the room were dropped and had to be picked up at the specific X/Y positions and there were tons of "flavor" items with the primary purpose of being used in combat. You could pick up a chair and throw it at another player, or pick up the player and throw them at a table (or even at another player) - you could also throw the chair at the table if you wanted, you could even directly attack an item and destroy it if you wanted to get rid of obstacles or just for the hell of it. You could also set items on fire and rooms could catch fire and even be destroyed but that's a whole other story. Items had a hardness based on material and the strength of the attack on it determined whether it was destroyed or not. You may not have thrown that other player at the table hard enough to break it…
01 Jan, 2013, Scandum wrote in the 13th comment:
Votes: 0
Kastion said:
Scandum said:
Assault was a good example of a MUD where the room model proved to be a crucial aspect of entertaining PK combat with the grid functioning as a game board. I don't think anyone managed to fully script Assault combat. I'd even suggest taking this one step further by making furniture inside a room a meaningful component of gameplay.

I did something similar to this over a decade ago on a MUD I ran. I had a hybrid ASCII map system - I used the conventional room system but each room had a grid you moved around which played a big role in combat. Items in the room were dropped and had to be picked up at the specific X/Y positions and there were tons of "flavor" items with the primary purpose of being used in combat. You could pick up a chair and throw it at another player, or pick up the player and throw them at a table (or even at another player) - you could also throw the chair at the table if you wanted, you could even directly attack an item and destroy it if you wanted to get rid of obstacles or just for the hell of it. You could also set items on fire and rooms could catch fire and even be destroyed but that's a whole other story. Items had a hardness based on material and the strength of the attack on it determined whether it was destroyed or not. You may not have thrown that other player at the table hard enough to break it…

That sounds interesting. One downside is that fleeing becomes increasingly difficult as the line of sight is increased, though this can be solved by allowing players to sprint for short distances and hide behind furniture. On games like WoW fleeing is pretty much useless, and in a 50/50 combat situation fleeing actually means certain death if the chance to flee is less than 10%. For that reason alone I'd prefer a 3x3 grid where the grid is primarily used for dynamic description generation.


KaVir said:
The issue is that "when taken to the extreme (scripting is required to compete) you're effectively back to an automated combat system".

I've said this for years. The same goes for graphical tactical interfaces, where these interfaces can become required to compete, and you've effectively gained nothing.
01 Jan, 2013, Jhypsy Shah wrote in the 14th comment:
Votes: 0
I can't help but feel some kiter hate up in here. XD
03 Jan, 2013, Ripley wrote in the 15th comment:
Votes: 0
I think an Affliction system can be built that does not require scripting. Lithmeria, for example, has built a system that has multiple afflictions, but with minimal cures. The strategic part of afflicting, stacking afflictions, etc. is still there but curing is vastly simplified.

Basically, each affliction has a strength and a type, physical or magical. (IIRC) There are two types of cures, physical or magical, although there exist various potencies of these cures that heal different strengths of afflictions in different combinations.

I have played it manually without a system and it is possible with only a few aliases to play effectively without a system. It is, of course, easier with one, but it is by no means a requirement for competitive play. They even use colors to differentiate the different types of afflictions, making it even easier. Of course, gameplay gets to be a bit twitchy if you do everything manually, but most PK based muds have some twitchy aspects, be it fleeing, doors, or some other mechanic.

If the complexity is reduced, I think that afflictions can be entertaining and provide some challenging, rich combat without making scripting a requirement for competitive play.
0.0/15