Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUDs
➜ General
➜ Handling Action Delays, Spell Timers, etc...
|
Handling Action Delays, Spell Timers, etc...
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Amicus
(3 posts) Bio
|
| Date
| Mon 15 Dec 2008 06:21 PM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| Nick Gammon
Australia (23,057 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Wed 17 Dec 2008 05:20 AM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Cash
USA (626 posts) Bio
|
| Date
| Reply #2 on Wed 17 Dec 2008 06:22 AM (UTC) |
| Message
| 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. |
~Nick Cash
http://www.nick-cash.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #3 on Wed 17 Dec 2008 07:26 PM (UTC) |
| Message
| | 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. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
14,261 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top