Jump to content
  • Advertisement
Sign in to follow this  
GenuineXP

Event-based System: No Need for a "Scheduler"?

This topic is 4170 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I recently took a look at a few articles about engine design and noticed that a few alluded to providing a sort of kernel (usually as a singleton). Part of this kernel was a task or process system that could handle multiple tasks and scheduled them much like an OS' scheduler does. My engine thus far has no well-defined "kernel" and no such task system. Rather, most things are event-driven, including the "game loop" which is broadcast as several types of "cycle events" (including timing information). My question is, is such an event-driven approach a replacement for a task scheduling system, or is it merely a compliment? Should I look into adding this sort of feature? If so, how (in general) should it be implemented (i.e., a simple priority queue and timing parameters)? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
Without a scheduler, you cannot ensure that an event which has to occur at time T will happen before an event which has to occur at time T + ε. If you do not wish to allow an arbitrarily small ε resolution, then you can survive without a scheduler.

Share this post


Link to post
Share on other sites
I've seen a lot of designs that go way overboard with this idea. Suddenly, all their rendering, physics, and net code are tasks in this scheduler.

Share this post


Link to post
Share on other sites
To be fair, I've seen event systems go similarly overboard.

Personally I've not used a scheduler, but I'm looking into it. My main problem is with multithreading. In a single thread it's plausible to imagine how events go from one action to another, wandering about until the event is complete. Once that order of operations is no longer guaranteed things break down very, very quickly.

Share this post


Link to post
Share on other sites
In my experience, scheduling needs are wildly different between different engine areas. Make a Scheduler class that you're pretty sure will do the things you need a scheduler to do, and when some module needs a Scheduler, it can make one. If it needs a different kind of scheduler, it can make one of those instead. But for God's sake, don't make it a big ol' ugly singleton to which all modules must hew.

Share this post


Link to post
Share on other sites
So would you say a scheduler is more essential in a multithreaded environment? My engine is not multithreaded (though I've put some thought into thread safety just in case this changes; I don't think it will... multithreading hurts my head). I figured that an event-based approach could work as an alternative to a multithreaded system by trying to distribute the "load" in each game cycle. (i.e., don't just repeatedly call some update() method in every game object or something to that effect. Instead, do things only when they need to be done.)

At the moment, it doesn't seem like I need to guarantee the order and timing in which events occur, but I can understand how this may become a problem in the future. I did encounter a similar issue, but solved it with a lesser guarantee (certain events are only fired within a certain cycle phase).

Anyway, it seems that a scheduler may be a good idea, especially for future use, so long as it has different flavors (specialized subclasses rather than a monolithic singleton) and is used only when it is necessary. Is this the right idea?

Now that I think about it... when would it actually be necessary to use a scheduler rather than depending on good ol' events?

This is a bit off from the original topic, but I mentioned that I don't have a well-defined kernel in my engine. That is, there isn't "one class to control them all". Is this bad? I do have an Application class which provides factory methods to create what I call "primary interfaces to sub-systems" (for example, a Graphics object for graphics and a Mixer object for audio).

Thanks for the help. I appreciate it.

Share this post


Link to post
Share on other sites
If you don't need a scheduler now, then don't write one. The longer you wait, the better you'll be able to determine what you need from it. No point in writing a scheduler because "you've heard people say it's important". Their engine isn't your engine, and if your engine doesn't need one (yet), then what would be the point in writing one?
Sooner or later you might run into issues that require a scheduler which can better guarantee correct ordering and timing of events, but there's no point in enforcing that sort of thing when it isn't needed.

Quote:
I mentioned that I don't have a well-defined kernel in my engine. That is, there isn't "one class to control them all". Is this bad?

I'd say it's a good design. But I expect the answer to that question to vary wildly.

But in the end, the best design is the one that works. If your system works, and you haven't encountered any major obstacles because of your design, then it can't be that bad. [grin]

Share this post


Link to post
Share on other sites
That makes sense. I'm sure I'd have trouble coding a scheduler when I'm not even sure exactly what I need it to do yet!

Thanks for the help.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!