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!

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.

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.

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]

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.