Quote:Original post by Drakkcon
This is a flaw in my current project right now. The way I originally envisioned it, I would create the individual parts of my engine like middleware (they don't talk to each other), and then create an event system. The components would not be aware of the event system so I would wrap them with manager classes that would expose methods allowing me to create, destroy, and perform special actions with objects, referenced with a string and using std::map. These managers would raise events whenever you did any of these things.

This seems like a pretty clunky system now that I look at it (especially the name-based lookup). I'm not really sure how I would do such a thing now. I guess you'd have to make each class event-aware, but then how would you tie in 3rd-party libraries to your engine? I was reading the book "Game Coding Complete" and Mike McShaffrey recommends strongly that you do event based programming, but I really don't see what the benefits are.

First try really hard to put the whole "manager" concept out of your head, TBH. Just create the objects. Do any management that seems to be *necessary*, *when* the need is proven.

The idea with events is to help with MVC separation. Your button doesn't need to know how to do the task that's associated with it; it only needs know that it controls some object, and to tell that object "hey, I've been clicked!" The object does the rest. In simple systems, you can get away with just having the button call one of the owner's methods. In more complicated systems, this inhibits reuse (in particular, you eventually need a similar looking button to "drive" different kinds of objects in the Model). So for a while you can get away with some kind of signal-and-slot system, or function pointers, or something. But eventually you generally refactor to events. (I'm actually in the middle of refactoring something of that sort to a more event-like system at work. Though it's in Python, so "function pointer" is rather replaced with the moral equivalent.) It avoids having the button need to know about what it's talking to., or even about its conceptual owner. It only needs to know how to construct events and put them in the queue (or perhaps send them to a global Facade object for the model, which handles dispatch).

Quote:Anyway thanks for all your advice on my code, and also advice you've given to me in the past. Do you have a website for all the coding you do? They say "don't read source code" but I get the feeling that reading yours would be pretty educational =)

I only wish I were a tenth that organized :(

Quote:
The idea with events is to help with MVC separation. Your button doesn't need to know how to do the task that's associated with it; it only needs know that it controls some object, and to tell that object "hey, I've been clicked!" The object does the rest. In simple systems, you can get away with just having the button call one of the owner's methods. In more complicated systems, this inhibits reuse (in particular, you eventually need a similar looking button to "drive" different kinds of objects in the Model). So for a while you can get away with some kind of signal-and-slot system, or function pointers, or something. But eventually you generally refactor to events. (I'm actually in the middle of refactoring something of that sort to a more event-like system at work. Though it's in Python, so "function pointer" is rather replaced with the moral equivalent.) It avoids having the button need to know about what it's talking to., or even about its conceptual owner. It only needs to know how to construct events and put them in the queue (or perhaps send them to a global Facade object for the model, which handles dispatch).

I think I understand what you are saying here, but it's difficult for me to grasp because I have never worked on a large system before. One thing that seems appealing to me is to avoid using a global event manager, instead using an event manager for each subsystem that requires the use of events. I can think of three systems that should use events: input, gui, and game. It makes sense to me for keyboard input to be controlled by events (although I have no idea how you would handle "holding a key down"), gui programming is known for event programming, and many games are scripted with events in mind. But does this defeat the purpose of using an event system? If each subsystem only needs to communicate with itself and some logic (model?) would that defeat the purpose of using events instead of, say, callbacks?

Quote:
I only wish I were a tenth that organized :(

Oh, well. Personally, I have always wondered how people have the motivation to keep project pages and journals going.

Quote:
First try really hard to put the whole "manager" concept out of your head, TBH. Just create the objects. Do any management that seems to be *necessary*, *when* the need is proven.

Okay, this sounds good. I'll just use a manager when it's time instead of designing for it from the beginning.