I'm wondering if people could respond with the general speed of combat rounds (in seconds) in their games (if your game doesn't have rounds per se, then maybe the best approximation of that), and what games/codebase it is.

I don't have a strict definition of what makes a round, but for starters let's say the time that passes from when the player makes their attack command (or it's automatically made for them) to the time they see the text of the mob's counter-attack.

I'm interested in slowing this time down, and I'm curious what the acceptable limits might be.

#define PULSE_PER_SECOND 4
#define PULSE_VIOLENCE ( 3 * PULSE_PER_SECOND) <- 3 sec between each basic spell/skill
#define PULSE_MOBILE ( 4 * PULSE_PER_SECOND)
#define PULSE_TICK ( 50 * PULSE_PER_SECOND)
#define PULSE_AREA (120 * PULSE_PER_SECOND)

Slower is REALLY annoying imho.
Faster is really hard to manage in fight as some action does not take a 'full round' already (giving orders can only take half a round as an example)

Yeah, it's not really the combat speed that matters so much to the user, it's the speed at which commands are evaluated and actions appear to happen.

In the DikuMUD system, a "pulse" is the smallest unit of time in which anything can occur. Mine uses 5 per second, meaning the latency between hitting return and seeing SOMETHING is at most 40ms (20ms per pulse, assuming you hit return but it didn't get processed until the following update). Also, assuming your MUD isn't lagging. :)

One of the things that bugs diku people about LpMUD's is the seemingly slower combat. LpMUD's typically use a 2 second heartbeat, and while the combat rounds may be around the same, this introduces a longer latency between action and reaction.

I would say you could slow combat down quite dramatically as long as response to other activities remains snappy. I'd have no issue with combat being one round per 10 seconds *IF* it were engaging so I actually had to think about what to do next (as opposed to hitting up-arrow/return), and if while in combat, response to informational commands was quick.

for me combat, should feel natural to fast and i might as well not be doing anything, to slow and well i don't feel like fighting, the slowest combat i enjoyed in a mud was the space combat in default hspace 3, because there was a lot going on it the actions that you were taking felt realtime because of the ability to navigate in 3d space, i'm sure if the same thing was done in graphics it wouldn't be as fun but then again that same idea could interest others then myself.

on more standard muds i've found a 2 pulse per second to be fairly optimal with 5 processing frames per pulse, so for each second the mud does about 10 frames where it can update the player fairly quickly with while still keeping combat and logic actions on the pulse,

i'm implementing an action point system in theory that will let players do actions "in between the pulses" ie player has 10 action points per round if the player base attack takes 5 points he can do 2 base attacks per pulse but also if an attack takes 40 points ie some spell the player wants to cast then it would take 2 seconds for that action to be completed once its on command que, onces that action was cleared the default action would once again take over there place in the que

The closest approximation is probably 1 round per second, where most attacks take around 2-4 rounds to execute, and up to 6 attacks can be performed simultaneously.

For my war minigame, each round takes 30, 45 or 60 seconds, and players can usually execute 3 actions per round.

Both approaches work fairly well in practice, but result in a very different feel.

Typically players are used to an execution range of the round trip time plus a random interval between 0 and 0.25 seconds.

As long as the command executes between 0 and 0.25 seconds they're alright. If you change it to execute between 0 and 0.10 seconds they won't notice the difference as commands still executed in the unpredictable 0 to 0.25 range. If they go back to a slower MUD they'll notice the difference however.

Most MUDs have lag spikes due to poor update scheduling, and that's typically what annoys players.


I think it's acceptable to slow it down when combat is complex, but you might want to keep the total time to kill a monster the same. Have you considered using a cooldown system instead of static combat round times?

Kind of tangential here, and from someone with almost no experience in the matter. First, do most systems give the whole attack data at once? If they do, then breaking an action by either party into it's constituent parts and delaying those by some amount could increase the time without feeling laggy. Example below:

> attack [target] # holding broadsword at ready
[name] steps forward, broadsword behind them, and lunges forward.
As [name] lunges forward, <target> pulls their shield forward in a sweeping motion which is probably too slow.
<name>'s wide slash with the broadsword cuts a deep slice into [target], almost getting stuck, but slipping away.
# end of [name's] action.

VS.

> attack [target] # holding broadsword at ready
[name] attacks [target] with broadsword.
The blow glances off [target]'s armor.

Playing with the delay between those messages and the number and content of the messages could extend the player's attention. Potentially this method could lend a real-time feel to the action, if the player is reasonable quick to respond with their next action. If you do this for every action (player and target, attempting to keep excessive commentary to a minimum) then the amount of messages per given attack and their respective delay times could be used to smooth over a longer round time. What I mean by that is that the response of the game seems instantaneous, even though the actual calculation of the result could take longer and if it's timed right still feel like it follows directly after However, one does have to ensure that messages from different actions occurring mesh up in either the correct way, or a reasonably congruous way that makes sense for the battle situation.

My MUD no longer really works on the concept of static rounds… Rather, your Agility stat determines how quickly your automated combat actions occur. It is feasibly possible for someone to have twice the number of "rounds" in a given span of time than someone with much lower AGI.

Twice the rounds, or more like 2 attacks? or something that would otherwise take 2 rounds. Is it extra "real time" or "virtual time"? That is does it give extra actions or extra time for a single action?

If this was directed at my comment…


Basically, every participant in combat has their own combat round timer. "Lag time" on skills and such aren't modified by AGI (although, we don't use lag time, we use a "wait state" that doesn't lag, it just doesn't allow you to perform certain actions while waiting, while most other commands can still be used). Your AGI stat determines the pace of your own personal "rounds". It makes combat a little more spammy, unfortunately, but it works with much of how we've redesigned our combat.

I do things very similar Hades, although I break things down per hand instead of per player. Each hand performs an auto-attack every X.YZ seconds based on speed stats, spell modifiers, etc. Unarmed attack speed improves with your skill, while weapons all have their own speeds defined. All spells/skills use either an offensive or defensive cooldown timer, and set it an appropriate length based on the strength of the skill/spell.