Processes can be used for just about anything you need to run on either a frequency, or just update over multiple frames. For instance, my particle FX system, rather than being built into a large manager class, is just a process which gives an interface to a "Particle System".

It made sense to do particle FX this way, and you will find many other things it is useful for, I also use it for a nice interface to a sound that is playing, which I think they do in the book as well, can't remember.

Originally posted by BlueAlchemist
Hello everyone.

First of all to the authors, excellent book. This has been my first text on game programming and I'm very glad I chose to purchase this one. There are a lot of topics in here that I think would be of interest to all novice and intermediate programmers, not just aspiring game devs, such as the actor component and event system. Will definitely recommend to many others.

Thanks! I'm really glad you're finding it useful!

Now on to my question. I actually wanted to hold off and try to find more info on google but was unable to. Anyway, the Process and Process manager classes seem really interesting, and I see how useful they would be. However I'm less clear on how the process system would integrate with the event system presented later in the book. Should processes respond to events? Should they register events etc. ? Any further explanation, or even a couple of links would be greatly appreciated. Thanks.

They aren't integrated together at all, they are two completely separate systems used for totally separate purposes.

Processes are used to handle self-contained systems that are updated each tick. In fact, most things that need to be updated every frame should be a process. This gives it a very fire-and-forget feel, where you can spin up a process and attach it to the process manager, then forget about it. It will update and kill itself when necessary.

An event is used to send messages between systems that shouldn't know about each other. It's also used to broadcast messages to a wide variety of systems. For example, when a Sim dies in The Sims Medieval, a SimDeath event is sent out. It's caught by a number of systems that need to care about sim death, like the quest system, the role system, etc.

So, the answer to both of your questions is yes. In general, you shouldn't keep a bunch of pointers to processes around since you don't know when they might be killed. Instead, you have a process register for the events it cares about and then remove those registrations in the destructor. Most of the time, you shouldn't need this. If you've built your system correctly, most processes will be truly self contained and will pull the data it needs from appropriate systems.

As a concrete example, say you have a camera follower process that follows the player. When you spin up the process, it finds the player and saves a weak pointer to the transform component. In the update, it makes sure the transform is still valid and updates the camera's position based on whatever rules you've defined. You also have it register for an event that's triggered whenever the actor the player is controlling changes. On response to this, it looks up the new actor and replaces it's weak reference to the new transform component.

Another example is a timing event. I wrote a little simulation over the holiday break that has a day-night cycle. Every game hour, my time process will send an event which is caught in the Lua script. In fact, I never explicitly update my Lua script with per-frame update functions; it only knows how to respond to events. The way I update my script simulation is with the time process sending events down at specific times.

Hopefully that helps! Let me know if you have any other questions.

-Rez

Thanks for the extra clarification Rez, I will admit that I was (maybe still am) a little confused about the process manager working in conjunction with the event manager.

One thing that might be helpful is to look in the GCC codebase and see all the things that we do with processes. I'm sure we could have turned even more into processes

-Rez