Skip to main content
Game Development

Return to Answer

github.org -> com
Source Link
miguel.martin
miguel.martin
  • 420
  • 4
  • 16

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity SystemEntity System if you need some inspiration (which is inspired from the Java framework Artemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an exampleexample in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity System if you need some inspiration (which is inspired from the Java framework Artemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an example in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity System if you need some inspiration (which is inspired from the Java framework Artemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an example in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.

Fixed one dead link
Source Link
edit approved Aug 17, 2015 at 20:34
Kyranstar
edit approved Aug 17, 2015 at 20:34
Kyranstar
  • 324
  • 2
  • 13

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity System if you need some inspiration (which is inspired from the Java framework ArtemisArtemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an example in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity System if you need some inspiration (which is inspired from the Java framework Artemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an example in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity System if you need some inspiration (which is inspired from the Java framework Artemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an example in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.

Source Link
miguel.martin
miguel.martin
  • 420
  • 4
  • 16

In a typical entity system you leave systems to have all the logic for your game and components to store data only, and your entities are just a simple identifier. Input handling would be much easier that way and not to mention the flexibility of your game.

There are plenty of ways to handle events, such as: the observer pattern, or signals/slots. You could do message handling with templates/virtual functions or function pointers, however it'd probably be easier to use boost::signals, even known it's not that great for performance. If you want performance*, I suggest you use templates and virtual functions or function pointers.

*I noticed that your code could really be optimised. There are alternatives to the typeid operator, which are actually faster than using typeid. Such as using templates/macros and simple integers to define a class's ID.

You can look at my Entity System if you need some inspiration (which is inspired from the Java framework Artemis). Although I haven't implemented a way to handle events (other than entity-related events), I left that up to the user, but after sussing out the entityx library, which I found on reddit. I figured I might be able to add an event system to my library. Please do note that my entity system isn't 100% complete on what features I want, but it works and has decent performance (but I could optimize, especially with the way I'm storing entities).

Here's what you could possibly do to handle events (inspired from entityx):

BaseReceiver/BaseListener

- A base class so you may store listeners/receivers.

Receiver/Listener

- This is a template class and requires you to override the virtual function `recieve(const T&)`, where T is event information. - Classes that want to be notified by events that send specific information when an event occurs must inherit from this class.

EventHandler

- Emits/fires events - Has a list of Receivers/Listeners objects that will be notified by fired events

I've implement this design in C++, just now, without the use of boost::signals. You can see it here.

Pros

  • Statically typed
  • Virtual functions (faster than boost::signals, well it should be)
  • Compile-time errors if you didn't emit notifications correctly
  • C++98 compatible (I believe)

Cons

  • Requires you to define functors (you can't handle events in a global function)
  • No event queue; just register & fire away. (which may be not what you want)
  • Not direct calls (shouldn't be that bad for events)
  • No multiple event handling on the same class (this could be modified so it does allow multiple events, via multiple inheritance, but may take some time to implement)

Also, I have an example in my entity system, which does deal with rendering and input handling, it's quite simple but it presents many concepts to understand my library.