Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualL. Spiro

Posted 31 January 2013 - 04:59 PM

I am not Hodgman, but I agree with his philosophy on events. These are my views on the subject and do not necessarily represent the views of all Australians.

1) Is that your recommended method of managing events, or are you just showing an example of delegates?

Somewhat both. Events and delegates are 2 different things and each has their place. Delegates don’t replace events, but they offer an alternative and often better way of tickling tackling some things. Also, delegates are basically event-handlers, meaning they are not mutually exclusive, but when you do it this way it is less abstract and much easier to debug.
Abstract global event systems are bad.

2) This pattern is also sometimes referred to as signals-and-slots, right?

Erm, close enough…
Events, delegates, and signals and slots are 3 different things really, but some of that is just semantics and implementation.
Signals are basically events and slots are basically delegates. The main difference is that “signals and slots” refers to the whole send/handle events system whereas delegates are just the things that handle events.

3) Do you find it actually beneficial to use in games, or just desktop applications?

It is certainly more widely useful in desktop applications which are event-driven. Nothing happens until you click a button or type into the keyboard.
Games are different. It is definitely an error to make a global event system that tries to push your game into a heavily event-driven state. Events in games are better suited for handling script-related events, such as a player walking into a certain area of the map and triggering an in-game cinematic.
There are times and places for event-based systems in games, but outside of this example there are very few.

Event processing is one of the areas I have difficulty implementing neatly. mellow.png

Likely a sign that you intuitively realize that event systems in games are not to be used the same way they are in event-based desktop applications.
Event systems are to be used sparingly in games and only after much planning and pondering.
A global event system is an anti-pattern as was already mentioned. Humans are like desktop applications and dogs are like games. Both can eat chocolate cake, but the dog will likely die from it.


L. Spiro

#2L. Spiro

Posted 31 January 2013 - 04:47 PM

I am not Hodgman, but I agree with his philosophy on events. These are my views on the subject and do not necessarily represent the views of all Australians.

1) Is that your recommended method of managing events, or are you just showing an example of delegates?

Somewhat both. Events and delegates are 2 different things and each has their place. Delegates don’t replace events, but they offer an alternative and often better way of tickling tackling some things. Also, delegates are basically event-handlers, meaning they are not mutually exclusive, but when you do it this way it is less abstract and much easier to debug.
Abstract global event systems are bad.

2) This pattern is also sometimes referred to as signals-and-slots, right?

Erm, close enough…
Events, delegates, and signals and slots are 3 different things really, but some of that is just semantics and implementation.
Signals are basically events and slots are basically delegates. The main difference is that “signals and slots” refers to the whole send/handle events system whereas delegates are just the things that handle events.

3) Do you find it actually beneficial to use in games, or just desktop applications?

It is certainly more widely useful in desktop applications which are event-driven. Nothing happens until you click a button or type into the keyboard.
Games are different. It is definitely an error to make a global event system that tries to push your game into a heavily event-driven state. Events in games are better suited for handling script-related events, such as a player walking into a certain area of the map and triggering an in-game cinematic.
There are times and places for event-based systems in games, but outside of this example there are very few.

Event processing is one of the areas I have difficulty implementing neatly. mellow.png

Likely a sign that you intuitively realize that event systems in games are not to be used the same way they are in event-based desktop applications.
Event systems are to used sparingly in games and only after much planning and pondering.
A global event system is an anti-pattern as was already mentioned. Humans are like desktop applications and dogs are like games. Both can eat chocolate cake, but the dog will likely die from it.


L. Spiro

#1L. Spiro

Posted 31 January 2013 - 04:45 PM

I am not Hodgman, but I agree with his philosophy on events. These are my views on the subject and do not necessarily represent the views of all Australians.

1) Is that your recommended method of managing events, or are you just showing an example of delegates?

Somewhat both. Events and delegates are 2 different things and each has their place. Delegates don’t replace events, but they offer an alternative and often better way of tickling tackling some things.

2) This pattern is also sometimes referred to as signals-and-slots, right?

Erm, close enough…
Events, delegates, and signals and slots are 3 different things really, but some of that is just semantics and implementation.
Signals are basically events and slots are basically delegates. The main difference is that “signals and slots” refers to the whole send/handle events system whereas delegates are just the things that handle events.

3) Do you find it actually beneficial to use in games, or just desktop applications?

It is certainly more widely useful in desktop applications which are event-driven. Nothing happens until you click a button or type into the keyboard.
Games are different. It is definitely an error to make a global event system that tries to push your game into a heavily event-driven state. Events in games are better suited for handling script-related events, such as a player walking into a certain area of the map and triggering an in-game cinematic.
There are times and places for event-based systems in games, but outside of this example there are very few.

Event processing is one of the areas I have difficulty implementing neatly. mellow.png

Likely a sign that you intuitively realize that event systems in games are not to be used the same way they are in event-based desktop applications.
Event systems are to used sparingly in games and only after much planning and pondering.
A global event system is an anti-pattern as was already mentioned. Humans are like desktop applications and dogs are like games. Both can eat chocolate cake, but the dog will likely die from it.


L. Spiro

PARTNERS