25 Oct, 2009, Mudder wrote in the 1st comment:
Votes: 0
There was a link posted in another thread rather recently(I cannot remember the name of the MUD, nor is it important) but it was the MUD that claims to no longer be a Merc derivative with their new V3 release.

I was looking through the changes and I saw something that caught my attention and curiosity. It said that ticks no longer exist in the MUD and that the illusion of ticks was created because players liked them. To replace ticks, the MUD is now completely event driven.

What does that mean exactly? I thought ticks were themselves an event? I realize that with each "tick" other events are triggered off of this and creates a somewhat machine like feel but how else could this be done without creating other versions of a "tick" and making them fire off other events. In a sense, simply creating a tick for each event type. So how could a MUD truly be "tick free" and purely "event driven" ?
25 Oct, 2009, Tonitrus wrote in the 2nd comment:
Votes: 0
Mudder said:
I was looking through the changes and I saw something that caught my attention and curiosity. It said that ticks no longer exist in the MUD and that the illusion of ticks was created because players liked them. To replace ticks, the MUD is now completely event driven.

What does that mean exactly? I thought ticks were themselves an event? I realize that with each "tick" other events are triggered off of this and creates a somewhat machine like feel but how else could this be done without creating other versions of a "tick" and making them fire off other events. In a sense, simply creating a tick for each event type. So how could a MUD truly be "tick free" and purely "event driven" ?

Ticks aren't really "events", I don't think. When ticks are supposed to happen, most muds run a lot of updates for various states of the game, but that's not really the same as an event. For an event, it would work something more along the lines of the timer function noticing that a tick should happen, and yelling "TICK", and then a bunch of other functions responding to it. Normal ticks don't really do that, the functions that are supposed to run on a tick actually are added to the timer loop or whatever. From a player perspective, there's pretty much no difference. From a programming perspective, events make it easier to modularize code, since you don't have to add your code into the timer_tick() code, or whatever it happens to be called. To add something to a system that used ticks as events, you'd just have to specify that your function responds to it in some way, probably by registering a callback. That means that you can keep your file wholly separate of the tick code, which is handy, as changing 30 files every time you want to update something gets very old very quickly.
25 Oct, 2009, Mudder wrote in the 3rd comment:
Votes: 0
So the only difference then is on a tick based MUD, the tick timer itself calls the function but on an event based MUD the function instead responds to the tick and calls itself?
25 Oct, 2009, elanthis wrote in the 4th comment:
Votes: 0
It's just terminology.

Whether a game has a "tick" function that calls update functions on all game objects or there is an event sent out saying "a tick has passed," the game is the same.

Any MUD claiming that it has no ticks, or that it "emulates ticks," is just playing bullshity word games.
25 Oct, 2009, Scandum wrote in the 5th comment:
Votes: 0
Every MUD is event driven. From what I've gathered event driven is typically supposed to mean that the MUD has a centralized generic event handler.
25 Oct, 2009, Runter wrote in the 6th comment:
Votes: 0
Indeed. It's just terminology.

Sometimes people use the term when they are describing their use of independent timers. Sometimes when they are using anything but the typical absolute polling seen in many muds. E.g. tick_cleanup only happening when trash exists in the world to act upon. Or tick_combat only happening when someone is actually engaged in the world in combat.

Either way it probably isn't a wise or precise description.

I should also mention that often times I've seen people use the term "event driven" when they are actually describing a use of a scheme like the Observer pattern to act upon said events.
25 Oct, 2009, Davion wrote in the 7th comment:
Votes: 0
I believe in this case, the term 'event driven' vs 'tick based' is referring to the way the events are triggered. The diku-genre tends to transverse entire lists checking for a specific condition to execute. Event driven would refer to these specific conditions being contained and executed.

Eg. Changing the aggressive update to store a list of aggressive mobs and searching that instead of the char_list for aggressive behaviour (a part of diku/ROMs limited AI). This is of course a very simple example. Such lists could be part of a much larger system dedicated to executing events.
25 Oct, 2009, flumpy wrote in the 8th comment:
Votes: 0
Runter said:
Indeed. It's just terminology.

I should also mention that often times I've seen people use the term "event driven" when they are actually describing a use of a scheme like the Observer pattern to act upon said events.


So how would you code an event model? As far as I am aware, the observer pattern is a perfectly good methodology to follow when wanting an "event system". I use it myself in GroovyMud. Which, btw, also has ticks (heartbeats).

From what I know, the observer pattern is related to the publish/subscribe paradigm and is just a way of facilitating an event system without having to use point-cuts or interrupts…
25 Oct, 2009, Runter wrote in the 9th comment:
Votes: 0
flumpy said:
Runter said:
Indeed. It's just terminology.

I should also mention that often times I've seen people use the term "event driven" when they are actually describing a use of a scheme like the Observer pattern to act upon said events.


So how would you code an event model? As far as I am aware, the observer pattern is a perfectly good methodology to follow when wanting an "event system". I use it myself in GroovyMud. Which, btw, also has ticks (heartbeats).

From what I know, the observer pattern is related to the publish/subscribe paradigm and is just a way of facilitating an event system without having to use point-cuts or interrupts…


I use the observer pattern, but like I said. I think the term "event driven" or "event system" can be a multitude of things. I'm using EventMachine in Ruby for facilitating my timer based events without having to actually write any of the underlying code. (And more importantly, without having to write it in Ruby. It's implemented in C and interacted with through Ruby.)
25 Oct, 2009, flumpy wrote in the 10th comment:
Votes: 0
Runter said:
flumpy said:
Runter said:
Indeed. It's just terminology.

I should also mention that often times I've seen people use the term "event driven" when they are actually describing a use of a scheme like the Observer pattern to act upon said events.


So how would you code an event model? As far as I am aware, the observer pattern is a perfectly good methodology to follow when wanting an "event system". I use it myself in GroovyMud. Which, btw, also has ticks (heartbeats).

From what I know, the observer pattern is related to the publish/subscribe paradigm and is just a way of facilitating an event system without having to use point-cuts or interrupts…


I use the observer pattern, but like I said. I think the term "event driven" or "event system" can be a multitude of things. I'm using EventMachine in Ruby for facilitating my timer based events without having to actually write any of the underlying code. (And more importantly, without having to write it in Ruby. It's implemented in C and interacted with through Ruby.)


oh.. ok.. It sounded to me like you were saying that because some people use the observer pattern it wasn't really an event system..
25 Oct, 2009, KaVir wrote in the 11th comment:
Votes: 0
elanthis said:
It's just terminology.

Whether a game has a "tick" function that calls update functions on all game objects or there is an event sent out saying "a tick has passed," the game is the same.

Agreed, it's just a minor optimisation on the standard tick-based system. I don't understand why a game would even advertise something like that, either, when it's completely unnoticable to the players.

elanthis said:
Any MUD claiming that it has no ticks, or that it "emulates ticks," is just playing bullshity word games.

Well I wouldn't consider my system tick-based - mobs are spawned as players move around, and they vanish after a while if no players are nearby.
25 Oct, 2009, Erok wrote in the 12th comment:
Votes: 0
elanthis said:
It's just terminology.
Whether a game has a "tick" function that calls update functions on all game objects or there is an event sent out saying "a tick has passed," the game is the same.
Any MUD claiming that it has no ticks, or that it "emulates ticks," is just playing bullshity word games.

Not sure I agree. A tick system means there is a main loop that wakes up every tick and looks for work to do. Event driven, at least in the way I'm using it, means there is no loop. Rather, the mud wakes up only if there truly is work to do (i.e., some input is ready to read, some output is ready to write, some timer has expired). It's the classic polling versus interrupt approach.

It's not entirely transparent to the user, though not really an issue either. For example, on a tick, the user may see the results of multiple events that have expired since the last tick. That is, events become "bursty" because they are buffered into alignment due to the granularity of the tick. This won't be the case with an event driven approach, where they are processed as they happen, and timers (singular or repeating) can have granularity finer than a tick.

Ultimately, it does only make a minor impact on the user experience, but I think the internals of the MUD are more elegant if it's done right. Which is most of the fun for those of us writing them, right?
25 Oct, 2009, Erok wrote in the 13th comment:
Votes: 0
flumpy said:
So how would you code an event model? As far as I am aware, the observer pattern is a perfectly good methodology to follow when wanting an "event system". I use it myself in GroovyMud. Which, btw, also has ticks (heartbeats).

Two libraries I'm aware of are libevent (C) and asio (C++). I use the latter, in combination with weak pointers to handle expired objects.
25 Oct, 2009, Runter wrote in the 14th comment:
Votes: 0
Erok said:
elanthis said:
It's just terminology.
Whether a game has a "tick" function that calls update functions on all game objects or there is an event sent out saying "a tick has passed," the game is the same.
Any MUD claiming that it has no ticks, or that it "emulates ticks," is just playing bullshity word games.

Not sure I agree. A tick system means there is a main loop that wakes up every tick and looks for work to do. Event driven, at least in the way I'm using it, means there is no loop. Rather, the mud wakes up only if there truly is work to do (i.e., some input is ready to read, some output is ready to write, some timer has expired). It's the classic polling versus interrupt approach.

It's not entirely transparent to the user, though not really an issue either. For example, on a tick, the user may see the results of multiple events that have expired since the last tick. That is, events become "bursty" because they are buffered into alignment due to the granularity of the tick. This won't be the case with an event driven approach, where they are processed as they happen.

Ultimately, it does only make a minor impact on the user experience, but I think the internals of the MUD are more elegant if it's done right. Which is most of the fun for those of us writing them, right?


I guess I'm prepared to give Elanthis the benefit of the doubt that he knew all this already. He's not exactly a noob programmer. ;)

I think the bigger point is you can design your game with different granularity of ticks. E.g. regenerating mana only once every 60 seconds @ 60 mana/minute or regenerating mana every second for 60 seconds @ 1 mana/second. Yeah, it makes a difference in the design of your game perhaps, but at the end of the day the end result is completely akin over a longer term. And as the granularity aligns better it becomes even less of a difference regardless of how it's implemented internally.
25 Oct, 2009, Erok wrote in the 15th comment:
Votes: 0
Runter said:
I think the bigger point is you can design your game with different granularity of ticks. E.g. regenerating mana only once every 60 seconds @ 60 mana/minute or regenerating mana every second for 60 seconds @ 1 mana/second.

Exactly.

To extend the example, suppose my game design involves accounting for exhaustion during melee. The progression of attacks may occur in 1.33 seconds, then 1.82 seconds, then 2.27 seconds, etc. So the sequence of attacks happen at t+1.33, t+3.15, t+5.42, etc. In an event driven MUD, the attacks happen at these precise times. Most polling MUDs have a tick in the range of 250ms (4 heartbeats per second), so now the sequence of attacks happen at t+1.50s, t+3.50, t+6.00, etc.

In other words, the tick becomes a constraint on the timing granularity you want to use in your design. Whether that constraint is a problem is up to you, but I prefer not to have it.
25 Oct, 2009, Runter wrote in the 16th comment:
Votes: 0
Eh, a tick is different from a minimum pulse value. In your example you place importance on hundredths of a second. Which for your game (although I can't imagine it needing that, since latency ebbs from moment to moment more than that value) may be important. That being said, sure, everyone wants to approach a constant update time. As you approach this constant update you're going to pay for it. You're going to pay for it under the hood and it may be abstracted away from the programmer.

The idea, though, that you can remove this pulse per second completely is a bit of a red herring. At face value even you need certain facilities in your game which at best can be delegated somewhere else that requires it to have a pulse per second of some kind. E.g. dealing with active connections. These things, by caste and design, will require this.
25 Oct, 2009, Erok wrote in the 17th comment:
Votes: 0
Runter said:
The idea, though, that you can remove this pulse per second completely is a bit of a red herring. At face value even you need certain facilities in your game which at best can be delegated somewhere else that requires it to have a pulse per second of some kind. E.g. dealing with active connections. These things, by caste and design, will require this.

Sorry, but that is not correct. I politely suggest looking into the low-level details of how systems (underlying OS and hardware, not MUD application) implement asynchronous i/o.
25 Oct, 2009, Runter wrote in the 18th comment:
Votes: 0
Erok said:
Runter said:
The idea, though, that you can remove this pulse per second completely is a bit of a red herring. At face value even you need certain facilities in your game which at best can be delegated somewhere else that requires it to have a pulse per second of some kind. E.g. dealing with active connections. These things, by caste and design, will require this.

Sorry, but that is not correct. I politely suggest looking into the low-level details of how systems (underlying OS and hardware, not MUD application) implement asynchronous i/o.


Okay, tell me how you in your mud are dealing with receiving data since you don't use any pulses per second or scheduling to check from incoming data?
25 Oct, 2009, Erok wrote in the 19th comment:
Votes: 0
Runter said:
Okay, tell me how you in your mud are dealing with receiving data since you don't ever do it at a minimum regular interval?

In my specific case, I'm using asio which supports scheduled events in addition to asynchronous i/o handling via callbacks, so there is no loop/tick. asio itself uses a set of platform specific methods, where select() is the most common demultiplexing mechanism. asio internals are discussed here, and again there is no loop/tick. If we delve into how an OS typically implements the select() system call, it ultimately boils down to the hardware signaling the OS that it is ready to read or write data, or has timed out doing so.
25 Oct, 2009, Scandum wrote in the 20th comment:
Votes: 0
Erok said:
For example, on a tick, the user may see the results of multiple events that have expired since the last tick. That is, events become "bursty" because they are buffered into alignment due to the granularity of the tick. This won't be the case with an event driven approach, where they are processed as they happen, and timers (singular or repeating) can have granularity finer than a tick.

There's still the client bottleneck, tintin++ for example polls 20 times per second. Then there is the human bottle neck, no one will notice the difference between 20 loops per second and 50 loops per second. Not to mention network and OS lag.

From a practical viewpoint 10 to 20 loops per second gives a pretty fluid experience.

Davion said:
Eg. Changing the aggressive update to store a list of aggressive mobs and searching that instead of the char_list for aggressive behaviour (a part of diku/ROMs limited AI). This is of course a very simple example. Such lists could be part of a much larger system dedicated to executing events.

Would make more sense (and be more event like) to launch an event looking for aggressive mobs whenever a player moves.
0.0/45