Game Programming - Component-based Class Designs (does that imply nested classes?)

INTRO

Hey guys, this is my first post here on this site and I'm looking for some knowledge and enlightenment on a particular topic. The post might be pretty lengthy (especially for a first-timer) in describing everything, but please bear with me. I appreciate all the time you spent reading this and your help in advance.
-----------------------------------------------------------------------------
PROBLEM DESCRIPTION (PREFACE)

Currently, I'm trying to construct a 2D game engine. Using C++/SDL/OpenGL, one thing I have to create is something called an Actor and a Controller. Before going into describing my problem, I will be prefacing the definitions of those two terms (Actor and Controller) in order for you to better understand my troubles.

The Actor class is essentially supposed to represent any game object in my game world and could be anything from the abstract to the physical things. A primitive physical example of this would be, say, a box in a simple window (my game world), and an abstract Actor example could be the "camera" that gives you the view of the game world. In short, with all of this explained, you can think of an Actor as the "body" or "empty shell" if you will.

The Controller class is a parallel to the Actor class. Using an analogy...if the Actor class is the "body," then the Controller class is the "mind." From its name, you can guess that a Controller would "control" an Actor in performing certain things, such as (in a two-dimensional sense): moving the Actor, rotating the Actor, etc.
-----------------------------------------------------------------------------
PROBLEM DESCRIPTION (GETTING THERE AND MORE)

My problem lies in the creation of the Actor class and I've done quite a lot of thinking over the idea behind it. From the start, I know that every Actor will have a position (x, y) and an orientation in my game world...that much is definite. The fact that there are "different" types (abstract vs. physical) of Actors, threw me off into an inheritance design scheme of creating child classes of Actor to represent different types/modifications that could be applied to a game object (e.g. DrawableActor, RotatableActor, TransformableActor, etc.) but this is the absolute wrong way to go about it, because it wouldn't give me that universal Actor design that I want in order to represent anything and everything in one shell. I thought all was lost but then I happened to stumble across this lovely piece of work that gave me hope: http://gameprogrammingpatterns.com/component.html
------------------------------------------------------------------------------
PROBLEM DESCRIPTION (POST-PREFACE)

That link introduced me to the concept of Component-based Design which would be the solution to my problem, but after reading it, there were still things I was unsure of (due to my lack of intelligence) and I am coming to the cplusplus community for assistance. It's a stupid question really....are the component classes that the author is speaking of in that document, nested-classes within my Actor class or are they standalone classes outside the bounds of my Actor class? Also, if they are nested, would they be labeled as private? public? protected? What I have of my Actor class is pretty much this so far:

class Actor
{
private:
float orientation;
float x, y; //2D coordinates

public:
//component classes? something MUST belong here
};

Again, I apologize for the length of this post and I thank you again for making it all the way through. Looking forward to hearing from anyone.
Last edited on
He's just explaining a pattern, how exactly you implement it is something for you to figure out.
When you say that, I mean, are you saying that the whole idea of component programming can be applied via nested classes AND/OR outside classes? (Not sure if I said that correctly)
A nested class is pretty much the same thing as a normal class, the only difference is the namespace it resides in (well, I think it might have friend access by default, but that's a rather minor detail).
Topic archived. No new replies allowed.