The event-based system is necessary as far as input goes. You can’t update player states at random times within a game loop—that does not play weill with physics, rendering, etc.

On the start of a logical update, read input (or in a general sense, process all events, which will include input), update player states accordingly, update AI states, run physics, poll and process any triggers you may have, and then update sound.
Since rendering is not coupled with logic that is not included here, but a full cycle would perform the logical cycle first and then render.


L. Spiro

Yeah I was planning on doing it all in this order

while(gameIsRunning) {
State = Game.UpdateLogic(deltaTime, Input);
Input = MasterGameView.UpdateViews(deltaTime, State);
}

I hope your actual plans are not this simple.
Logic should only be updated if a given amount of time has passed. Rendering should happen every cycle.
I provide details and implementations here.


Engines/games that are overly dependent on event- and message- based systems are bound to fail.
Events and messages are good for certain aspects of engine design, but when used to drive the whole game, things quickly become an unmanageable mess.

The Nintendo DS SDK shipped with a sample Yoshi game which was based off this concept.
You would create a task, set a priority on it, register it with the task manager, and forget about it.
The system was design so that you could plug your tasks into the system and let the engine take over instead of trying to manage them yourself. But the problem was that instead of having to manage each task yourself, you have to manage a list of priorities. When you wanted to add a new task you would have to look back through all the task priorities and figure out what priority to set to your new task to make it execute with the right timing. It quickly became task-spaghetti and was a big pain to debug. Easy to find out where the task is executed, but difficult to breakpoint on the specific task you want to study, and it difficult to find out what created it and with what parameters. And since you can’t predict ahead of time how many tasks you will want to register, you may run out of priorities and have to move a whole bunch up or down, careful not to disturb the delicate balance of task priorities.

Deciding on task priorities is non-trivial when working in a team, since every member has to be fully on the same page at all times, and 1 or 2 years later it can be guaranteed that at least some, if not all team members, have forgotten all of the priorities they had assigned to tasks, making long-term maintainability virtually impossible.
Not to mentioned that what other programmers have done is completely transparent to the rest of us. My coworker may have slipped a priority in between 99 and 100, causing him to move a slew of task priorities down to make room, but unless I was fully tracking the priority list I wouldn’t have been aware of that when I added a task at priority 99 and screwed everything up.
The point of the system is to reduce to amount of code that you need to manage yourself, but frankly I would rather be looking at a plate of code that we are managing ourselves where it is clear what is happening at any time in any game state than to just send my task off into oblivion with a given priority that I hope mixes well with what everyone else the team was thinking.

Events and messages suffer from these same problems. If you are not careful, you will end up with all these managers bouncing events and messages back and forth and you won’t be able to debug it, you won’t be able to keep track of all the types of events and messages you have added and avoid conflicts, you won’t remember the reasons behind choices you made years ago because they are all just numbers, etc.


And finally, making bots that move via the same input mechanisms as humans is not the way to go.
As an AI, your first step is to determine where you want to go. This part is generally very easy. Then you have to determine how to get there.
By using the same inputs as humans, you have to reverse-engineer the input system to figure out exactly what to hit to get the desired result, and this can be non-trivial if your input system includes acceleration over a duration of button-holding and other factors.
Then the fact that your input system should always be changing as you play-test and tune your gameplay. If you don’t refine it over time, you are doing it wrong.

It is much simpler to just give the bots their own ways to generate the impulses that will guide them to their desired destinations.

The system you proposed to send input packets back out from the AI’s is overly complex and unnecessary.


L. Spiro

I largely agree with L.Spiro; be wary of relying too much on message/event passing. A warning sign is if you find yourself writing lots of manual marshalling/demarshalling code for the parameters contained within the events. Instead I'd recommend defining interfaces, for example IControllable for actors that can be controlled via AI or user input. You might think events are better for avoiding too tight coupling between classes, but in the end you still need understanding of the object that's at the receiving end, so if control happens through an explicit interface, you'll have much easier time debugging, and the compiler can also help you better.

I believe the concepts (like logic and rendering separation) presented by Game Coding Complete are valid, but it should make it more clear that the implementation in the book isn't the only way to do it. Particularly, if it leads beginning game programmers to believe that using messages/events everywhere is essential, it's really doing a disservice.

I've also seen some game engines define their whole public API through messages, for example a Light would respond to a SetLightColor message which in turn would call the internal SetLightColor member function. This can be somewhat justified as it makes it easier to multithread via a thread-safe message queue, but is still IMO misguided as typically the bottlenecks where multithreading helps lie in the mass processing of low-level tasks (such as culling and animation), instead of high-level API calls.