Handling Action Delays, Spell Timers, etc...

This is my first time posting here though I've been looking at some of the different posts and trying to learn what I can. Like many of the other people who post here, I'm trying to create a MUD from scratch in C++. I would consider myself a moderate programmer and started MUD programming as a fun way to learn how to code better.

I've gotten most of the telnet serve basics down and have already which accepts connections and can process the data. I'm getting to the point where I can start adding actions. However, I can't seem to think of a good way to implement handling delays, either for action delays or spell timers. Examples would be like:

1. Kill <NPC>
2. [Delay 3 sec]
3. Kill <NPC>
4. [Delay 3 sec]

or

1. Cast Spell Buff [Lasts 1 Minute]

-----

In the first case where a player is in delay before he can execute the next action, would you queue additional inputs from the player? If so, do you only keep like 1 extra queued combined or a few?

If there is any source could that implements combat with delays and maybe spells with time limited buffs/debuffs, that'd be really if you could link me.

Thanks in advance for the help.

Smaug has delayed actions (like spells that wear off). Most MUDs would do that.

An essential part of any MUD engine would be some sort of "heartbeat" - code that gets executed periodically (eg. every second, or every 1/5 or a second). This would be used to make mobs move around, and handle combat rounds.

As part of the heartbeat checks you would check to see if a player buff had worn off.

Similarly you could pull commands out of a queue - you would need to decide if you wanted them executed eventually, or just ignored if they are sent too quickly.

The way I currently have mine set up is to have a master queue of timers can do a number of basic things (fire x times or indefinitely, store the interval, enable/disable, etc). Due to inheritance it is then easy to make timers for whatever I happened to need (call a function every time the timer expires, etc).

This may or may not be a good way to ultimately set things up. I don't know how well the system will perform when under a significant user load (as I plan to let most actions create and use specific timers if they are called for), but overall I doubt it will really be a problem.

Like most muds, my main game loop still sleeps if it finishes its tick early so the game input is still processed at a set interval instead of as fast as possible. Most vital things (user input and output, connections, etc) are handled directly in the game loop and not put in timers. Almost everything else is clumped into timers that trigger at regular intervals (second, minute, hour, day, etc).

Sounds complicated when I describe it, but it has actually turned out to be easy to work with and far less confusing then Smaug/SWR updates.

One tricky thing about event systems like these are how to handle characters disappearing when there are still timers pending. Using some kind of id map -- Nick posted one here some time ago -- is very helpful for this: you don't store the pointer to the character, but some session-unique identifier and you have a map from id to character. When a character is destroyed, the map is updated to remove the mapping. Then, when you need to look up a character, you can know by using that map if the character still in fact exists.