Hi,
I'm currently starting to develop my own engine and I want to implement it using different components which run in seperate threads (maybe processes later).
My idea currently is to have e.g. a sound component (sound manager might fit more, as some entities might have components) and this component will handle sound. It runs on its own thread and on collisions of entities it will receive a message, which lets it play e.g. an explosion.
Messaging is done using Priority-Queues and messages are going through a dispatcher who may filter/change the messages or create new messages. To implement game logic I thought of using rules e.g. EntityTypeX hits EntityTypeY will result in: MessageZ -> MessageZ would be dispatched in MessageA(playSound) and MessageB(create Explosion at XYZ)
Do you think such a system would work for a game? Currently I see the dispatcher as a bottleneck but logic might also be seperated. Do you have thoughts on this? :)
Cheers,
I'm currently starting to develop my own engine and I want to implement it using different components which run in seperate threads (maybe processes later).
My idea currently is to have e.g. a sound component (sound manager might fit more, as some entities might have components) and this component will handle sound. It runs on its own thread and on collisions of entities it will receive a message, which lets it play e.g. an explosion.
Messaging is done using Priority-Queues and messages are going through a dispatcher who may filter/change the messages or create new messages. To implement game logic I thought of using rules e.g. EntityTypeX hits EntityTypeY will result in: MessageZ -> MessageZ would be dispatched in MessageA(playSound) and MessageB(create Explosion at XYZ)
Do you think such a system would work for a game? Currently I see the dispatcher as a bottleneck but logic might also be seperated. Do you have thoughts on this? :)
Cheers,
Edited by Marco Dennstädt
on
Thoughts? Write the usage code first? (sorry, I couldn't help myself :) )
Haha no problem :lol: , this is what I am actually doing right now, inspired by the videos :) The audio components now exists in it's own thread and can load and play wave files in a loop. When I got my input component working a simple implementation for communication between components is going to be implemented :) I just thought someone may have implemented something similar already :)
I don't think such approach is good. Dedicating whole thread to one system (like sound in your example) won't scale much to more cores, and won't be very flexible. Once you'll start putting more components in separate threads it will start to get very complex to synchronize everything correctly.
I think better approach is to do some kind of task system. Where your work is split into smaller chunks and then scheduled to run on any threads. Create as many threads as you have cores, and you'll be sure to use max computing power. So this way anything can be run on any thread be it sound updates, particle simulation, physics updates, etc... Of course some synchronization will be needed, but because everything will be uniform in this task system I think it will be easier.
Here's more reading about this:
http://fabiensanglard.net/doom3_bfg/threading.php
http://bitsquid.blogspot.com/2010...management-practical-example.html
http://jrouwe.nl/kzsfthreading/
https://software.intel.com/en-us/...king-to-scale-game-engine-systems
http://www.gdcvault.com/play/1012...onsored-Task-based-Multithreading
I think better approach is to do some kind of task system. Where your work is split into smaller chunks and then scheduled to run on any threads. Create as many threads as you have cores, and you'll be sure to use max computing power. So this way anything can be run on any thread be it sound updates, particle simulation, physics updates, etc... Of course some synchronization will be needed, but because everything will be uniform in this task system I think it will be easier.
Here's more reading about this:
http://fabiensanglard.net/doom3_bfg/threading.php
http://bitsquid.blogspot.com/2010...management-practical-example.html
http://jrouwe.nl/kzsfthreading/
https://software.intel.com/en-us/...king-to-scale-game-engine-systems
http://www.gdcvault.com/play/1012...onsored-Task-based-Multithreading
Hi,
ahh thank you! I will have a look at the resources :) An physics or graphics component internally could have threadpools, doing the same thing on different data which might correspond to the "tasks" you mentioned but more specific instead of generic tasks, which I (currently) think is an advantage, maybe reading the articles will change my mind :) Synchronization would be the task of the dispatcher and a component should wait when there is nothing to do, to leave cpu time for other threads.
ahh thank you! I will have a look at the resources :) An physics or graphics component internally could have threadpools, doing the same thing on different data which might correspond to the "tasks" you mentioned but more specific instead of generic tasks, which I (currently) think is an advantage, maybe reading the articles will change my mind :) Synchronization would be the task of the dispatcher and a component should wait when there is nothing to do, to leave cpu time for other threads.
Edited by Marco Dennstädt
on
The plentifully linked http://www.dataorienteddesign.com/dodmain/dodmain.html has some notions about the component based approach. If you haven't already I highly recommend at least glancing through the book. Component Based Objects specifically.