@WILL
Documentation will be a beast unto itself, sigh. But I'm committed to providing great docs.

@chronozphere
Thanks. 10+ years of continual growth and refinement.

It grow out of a need to make my own projects, a vision for a robust solution that gives you a platform for growth. It's higher level than using DirectX alone, but still low enough that you can build on top.

Also over the years I've been learning about component based development and how it can help with building and managing complex systems. Combine this with some agile methodology and you can streamline your development efforts. Ok, what does all that mean? I've asked myself these questions many, many times. It certainly sounds good, but how can it be applied on a practice level? Well, the idea is that as your software project continues to grow and become more complex, are you able to make changes without the whole thing exploding or you finding that it's just easier to start all over because that would be easier than making the needed changes? Son, I can not tell you how many times I've been in that position. I just started over because what I had was working, but there was no room for growth and to change things became to much of a mess.

The idea is that if you design your project around the notion of components where you have a tree for example that you can hang functionality on, this functionality is more or less an independent logical entity. The TPGActorList can be that tree and the TPGActor object can be that logical entity that can perform some functionality. The ActorList can send messages to actors and actors can respond to those messages. For example, you dropped a nuke and it's time for all actors in a certain range to die, you can broadcast a message that you need to go away because a nuke just went off. In this case they respond by terminating themselves. In cases where you need to send a message and wait for response, the SendMessage function will return the actor that responded or nil if there was no response. My point is that there is a logical way that you can now communicate with all the fruits of functionally hanging on the vine so to speak.

Now if you design things in such a way so that the actors can be independent, yet they can interact with the rest of the design then if something goes wrong where a particular functionality is not needed or need to be replaced, just remove it or change that actor without having to change the whole tree. By rapidly iterating, changing your design in the areas that need change without effecting everything else you can push development forward in a logical and consistent manager. Note that is can be much more complex than what I've outlined but the concept is the same. Your project can be broken up in a logical fashion where you have a tree and you hang functionality on it. You should be able to add/remove/change thing without adversely effecting everything else. Now when change is needed you can replace this logical functionality rather than having to tare down your whole tree and starting over.

In PG the ActorList is the stage or the playground and the Actor is the player. An actor can have children. Again the tree-functionality concept, where you can add functionally to each actor and those children will be updated when the actor's Update method is called and if the children need to render their Render method is called when the parent's render method is called. So very complex design is possible yet be handled in a logical and consistent manager.