1. If I understand your design, there is no need for the GameObject to know the Factory type. The only case where a GameObject would need to access a factory is when it needs to create another GameObject, which is common for objects that spawn other objects. However, since you are already using an event system, you can just define an event type such as "create object". This way, the GameObject type can spawn/create other objects by firing an event, without knowing about the existence of a Factory.

2. No, not a good idea to separate the GameObjects by "type", because, GameObject is supposed to be an abstraction, if you start typing it, you loose that abstraction and create coupling. Also, this would not be scalable if you where to introduce another specialized GameObject "type". It would require changing the factory to add another container for this new type. OOP-wise, it is best to keep the GameObject abstract.

3. You can optimize search and management of the GameObjects by using a more efficient data structure. A scene graph or a quadtree can reduce the number of queries when dealing with a lot of GameObjects spread into a given space. Also, for the specific case of removal, you can delegate that task to the GameObject itself. When the object is expired, make it fire an event: E.g.: new Event_RemoveObject(this) that passes itself as the event argument. When the event is handled, the event manager will know who to delete.

4. If you want to design for scalability, it is best to avoid inheritance. Taking the Tree case, other more specific kinds of trees don't need to be objects in their own right. You can use configuration parameters to define that. This is what is otherwise known as Component Based Design. Define the behavior of a GameObject from the set of its components. This makes for a very flexible and extensible approach.

5. Yes, you can use a C++ union to define a Variant type.

This is an example I have used before:

union Data { void * asVoidPtr; bool asBoolean; int asInteger; float asFloat; char * asCString; Vector3 * asVector3; Vector4 * asVector4; }; // Plus an enum flag that tell which field the // union is in use, e.g.: a "type tag" 

It should be enough if the parameters of your events are only primitive types and raw pointers. If you need more complex parameters like objects and smart pointers, then your best bet is to define and abstract Event class and specialize it as needed.

1. If I understand your design, there is no need for the GameObject to know the Factory type. The only case where a GameObject would need to access a factory is when it needs to create another GameObject, which is common for objects that spawn other objects. However, since you are already using an event system, you can just define an event type such as "create object". This way, the GameObject type can spawn/create other objects by firing an event, without knowing about the existence of a Factory.

2. No, not a good idea to separate the GameObjects by "type", GameObject is supposed to be an abstraction, if you start typing it, you loose that abstraction and create coupling. Also, this would not be scalable if you where to introduce another specialized GameObject "type". It would require changing the factory to add another container for this new type. OOP-wise, it is best to keep the GameObject abstract.

3. You can optimize search and management of the GameObjects by using a more efficient data structure. A scene graph or a quadtree can reduce the number of queries when dealing with a lot of GameObjects spread into a given space. Also, for the specific case of removal, you can delegate that task to the GameObject itself. When the object is expired, make it fire an event: E.g.: new Event_RemoveObject(this) that passes itself as the event argument. When the event is handled, the event manager will know who to delete.

4. If you want to design for scalability, it is best to avoid inheritance. Taking the Tree case, other more specific kinds of trees don't need to be objects in their own right. You can use configuration parameters to define that. This is what is otherwise known as Component Based Design. Define the behavior of a GameObject from the set of its components. This makes for a very flexible and extensible approach.

5. Yes, you can use a C++ union to define a Variant type.

This is an example I have used before:

union Data { void * asVoidPtr; bool asBoolean; int asInteger; float asFloat; char * asCString; Vector3 * asVector3; Vector4 * asVector4; }; // Plus an enum flag that tell which field of the // union is in use, e.g.: a "type tag" 

It should be enough if the parameters of your events are only primitive types and raw pointers. If you need more complex parameters like objects and smart pointers, then your best bet is to define an abstract Event class and specialize it as needed.