Member Discussions

While designing my combat system, I decided it might be fun and interesting to do multi-room combat. I figure I can't be the first to think of this, so I'm hoping those who have thought about, or implemented it, would be able to guide me through some areas I'm having problems with.

In multi-room combat, when would combat end. For instance, in other cores I've worked on, combat would end if the person/people you were attacking or who were attacking you are no longer in the same room. In multi-room combat, it may have to be time based or such. Like if x amount of time passes and you are not actually fighting then combat ends.

Another issue I came across is what happens when more than one 'combat' runs into each other. Combat on my MUD is initiative based, with players getting actions per round based on how fast they are.

I can forsee, and have no problem with two seperate 'combat entities' occuring in the same room, but if an attacker in one combat decides to attack someone in another combat, should the combats combine?

And what if a third combat comes into play.

For instance:

ABCDE = Combatants
[] = Combat 1
{} = Combat 2
() = Combat 3
| | = Room
-- = Exit between rooms

| [AB] |--| {CD} |
| [AB]{C |--| D} |
| [AB{C] |--| (D}E)|
| [AB{C] |--| (D} |--| E) |

When C goes to [], C is now in 2 combats. Running as two independant combat modules, C is receiving twice as many attacks as AB and D. If the combats combine, then E enters combat with D and then flees to a 3rd room, is E forced to wait for ABC to go through their actions each round just to attack D?

Any input is greatly appreciated.

I think you're reaching some of the limitations of the simplistic combat model found within many muds.

> In multi-room combat, when would combat end.

I think the more appropriate question is why does combat have to be a separate entity at all? In my mind there is no such separation between a person or group in 'combat mode' and a person or group in whatever mode there were in before they started fighting. I think if we do away with the idea that combat is something that needs to be handled specially that it will help solve your problems. It also helps greatly to think of characters as a base unit. That is, you wouldn't have a combat object with two opponents, you would have two 'current target' references on each combatant.

You raised a few points that I feel can be addressed by thinking about combat differently:
1) Combat would have no end (or no beginning) because there's nothing special about two players fighting versus two players sitting and chatting normally.

2) There's no problem with combatants attacking other foes, because there's no real distinction to their current foe other than a 'current target' reference. Changing the target of one player shouldn't change the target of another since they are independent entities.

3) Initiative is simply whoever initiates the first combat action. Concepts like stealth and surprise can be modeled by a lack of notification to the surprised player, allowing thieves and assassins to work. Initiative can be maintained by a character taking less time to perform an action, which results in that character getting the chance to take another action sooner. Again no special calculation about the relative magical initiative score of any other player need take place, since this is based solely on an individual character.

I would say don't allow mixing of fights like this. It adds a lot of complication with minimal (in my view) additional gameplay. If C wants to join the AB fight that bad, C has two options. One is to hurry up and finish off D, the other is to disengage from D and join the AB fight. If C disengages (via a run command or some other mechinism) then D has the option of chasing C into the now ABC fight, making it an ABCD fight. E can then notice that his arch rival D is involved in an all out brawl, and the fight becomes ABCDE, all one fight. Much smoother than trying to allow overlapping fight groups.

I think the solution to both problems is to de-abstractatize (er... yeh) combat. Traditional diku combat is abstracted into a flagged state that tells the game to include affected players in the violence_update routine which takes both players and computes mutual damage in a hyopthetical encounter. This is a very simple and effective abstraction of a combat sequence. But if you want to have players free to roam around than you can shift the combat into a less abstracted realm where a combat-entity, as you call it, doesnt exist, but rather individual attacks from one player to another are calculated independantly. What I did was replace my violence_update with an event queue where each player attack is a self-perpetuating event, in other words instead of having a combat-entity between two players there is a single attack-entity everytime a player's speed permits it.

So in dealing the the 'when is the fight over?' question, well- if you check for a line-of-sight between the two players and break the attack-event chain when a line-of-sight no longer exists then it is over when one player can no longer 'see' the other.

And in regards to the group combat scenario this method inherently fixes this dilemma. Each player initiates an attack-event with another, so what does it matter if three attack-events are targeted towards one person?

The only problem here is one that plagues traditional diku combat as well- and that is defense calculations. If you can imagine a scenario where a newbie is a attacking a veteran warrior, the warrior intentionally does not fight back and just focuses his efforts on blocking (which he does with ease) his opponent's weak attacks. Now imagine 50 newbies attacking this same warrior, in both traditional combat as well as the one I just proposed every newbie attack has the same chance to be blocked. This is of course silly imagining that the warrior is now defending himself 50 to 1 he cannot possibly defend against all those attacks equally. I will let you find your own solution to this problem...

> I will let you find your own solution to this problem...
easy, its not that cryptic: balance, fatigue and focus

I tend to agree with Unifex. I'm not familiar enough with Diku to comment on how it handles combat, but in my own codebase, my solution is to let each character maintain its own combat data.

Each character has a 'combat track' that contains data about its opponents. The track logs the amount of damage that each opponent has done to the character. When the character heals, the amount of inflicted damage is removed from each opponent in appropriate ratios. When an opponent's inflicted damage reaches 0, it will eventually be removed from the combat track. Among the track's uses:

* Determine how many opponents a character has.
* Identify the opponent doing the most damage.
* Find the nearest opponent.
* If the character is defeated, award points to its opponents according to how much damage they inflicted.

The combat track doesn't care where the character's opponents are located. In the case of NPCs, it is up to the character's AI to determine whether it will attack the nearest or the most dangerous opponent, chase an opponent to a different room, etc.

Or simply have dodging and parries affect the character negatively. For example, the veteran can choose to dedicate all required resources to defensive skills.

1 Newbie attacks...veteran easily blocks all newbie attacks and is able to strike back rather easily.

50 newbies attack...veteran easily blocks newbie #1s attacks, #2s attacks, and maybe newbie #3s attacks, but then is completely unable to block [perhaps out of movement points that round or action points to parry, whichever abstraction you'd like...remember a round is a limited time frame] and the rest will hit him...leaving his survival to his armor. Perhaps his armor is amazing and it will stop all their attacks, then he really should have just concentrated on attacking and not worried about blocking their attacks.

Kelson

the point is... there are a million ways to handle this problem and I didn't want to persuade the original poster into doing it my way so I left it open ended.

I would rather do the other way, i.e abstract more a fight.

A fight would then be made by 'groups' battling together.
A group is a list of mob or player that are together.

The violence update function would then simply run into the list of fight and each fight into his own list of fighters.

The condition would be that if a character from a fight involve itself into another fight, then the two are mixed by adding all group of fightters from the first to the second.

A fight stop when only one group of fighter remains. ( or when a certain time without damage elapsed )

What is gained by having a "Combat" flag? Is there a reason the MUD needs to track who is in combat and who isn't?

In my opinion "Combat" should be conceptual...players and mobs recognize combat by attacks taking place (and in the case of mobs, a timer since the last attack occured). I'm currently coding my own codebase, and this is how combat is handled. This allows the easy addition of multi-room combat (for instance a bow that can shoot into an adjacent room) without any headache or tracking.