Irrlicht Engine

Bare with me I'm going to make a vague question as nonvague as possible here.

I've been reading Game Coding Complete and the book talks a lot about having the game as modules which communicate with and Event Manager which is basically an Observer design pattern. Now the biggest difference between my game and his concepts is Irrlicht which in itself is a module mostly the graphics part (some collision stuff too) Now Irrlicht really isn't designed to interact in the same way as his graphics module does making communication between let's say Enemy entities and their 3d representation aka nodes. There really is no need to have the Enemy AI to send out an event to the Event Manager for Irrlicht to listen to telling it to rotate the object. Or am I missing the point? Event driven communication kind of has me puzzled as how to design my overall architecture because certain things are turning out to seem kind of redundant to me. Like having the collision of two nodes triggering an event telling entities to solve the problem rather than have the game logic just let the associated entities of the nodes (I.E. PlayerEntity, EnemyEntity) do their own thing by themselves.

I'm missing a point here aren't I?

jaeg wrote:Bare with me I'm going to make a vague question as nonvague as possible here.

I've been reading Game Coding Complete and the book talks a lot about having the game as modules which communicate with and Event Manager which is basically an Observer design pattern. Now the biggest difference between my game and his concepts is Irrlicht which in itself is a module mostly the graphics part (some collision stuff too) Now Irrlicht really isn't designed to interact in the same way as his graphics module does making communication between let's say Enemy entities and their 3d representation aka nodes. There really is no need to have the Enemy AI to send out an event to the Event Manager for Irrlicht to listen to telling it to rotate the object. Or am I missing the point? Event driven communication kind of has me puzzled as how to design my overall architecture because certain things are turning out to seem kind of redundant to me. Like having the collision of two nodes triggering an event telling entities to solve the problem rather than have the game logic just let the associated entities of the nodes (I.E. PlayerEntity, EnemyEntity) do their own thing by themselves.

I'm missing a point here aren't I?

I'm not sure if I completely understand the issue you're having here, but I'll try to answer
There are a couple of advantages to an event-based model, the first one is that each entity can guarantee that it conforms with its invariant at all times since it will be the entity who receives the event notification, and it will be the entity who will act upon it in a way it sees fit. This means that no external entity can directly alter another entity, which reduces the chance of entities messing eachother up when something goes wrong
The second advantage (which grows directly from the first one) is that each of your entities will be able to function on its own, creating a completely modular environment which becomes quite easy to manage and modify
An event based model also simplifies means of communication between different systems; when you let entities modify eachother directly, each entity will need a direct interface to the entity it needs to modify (ie. when you'd look at it from an OO-standpoint, an object would need a reference to another object to directly modify it). An event-based system completely abstracts this away, since your event manager (or whatever system fills the role of distributing messages) will know how and where to send each event notification based on a certain input format (of you own design)
For systems like scripting this is an ideal solution since your scripting system will only need to conform to the rules set up by your event manager to interact with any entity you designed

Of course there are also downsides to event systems since it can cause quite an amount of overhead (that's probably why it didn't look logical to you in the first place), so designing a good event system requires some good planning and a lot of trial and error.

I hope this makes some kind of sense to you, I can't always explain this stuff all too clearly (it all sounds so logical in my head), so if you need any clarification you can just ask

Holy something you write long sentences! Any of you mean a finite state machine?

ACE247 wrote:Holy something you write long sentences! Any of you mean a finite state machine?

This would be considered FSM-logic, but the term 'Finite State Machine' is so ridiculously broad that it doesn't really mean all too much in this context

I Implemented just such a system as you describe (after torturing myself through the long sentences ) But I'm not exactly willing to share it as of now,(Sorry ) but for a similar example check at IrrWizard, its aged but works with Irrlicht 1.7.2 with some updating and implements about the same system.

Now are my sentence/s nearly as long?

Hey sorry,
I've already and went ahead and integrated a event managing system into my engine. It was required when I redesigned my entities to use components.