   Communication between objects in a game
  Hello,I'm curious how you would create such a thing:Lets say all game objects (rocks, players, even hud element) are called Actors.In my case, an Actor is composed out of an Graphics, Physical and a Multiplayer object (since I'm making a multiplayer game).All of the following three elements are optional, for example, a speedometer hud element would have only graphics representation, etc...An Actor on itself does very little in my case, it just updates the graphical representation based on the physical body, if it has one.Right now I have a reference system set up, so for example, when I destroy the Actor it notifies the ActorManager to remove it from the world and destroy it.Now lets say we want to control a box with keyboard:We create an actor with the box renderable and the box physical object, lets leave multiplayer out of it.Now, how would you go to create this?A) Would you derive a class from actor and give it the keyboard control properties (eg, in the derived class the user controlls the physical object with the keyboard).B) Would you create some kind of "Controller" class, for example ControllerActorUserControlledMovement. This class could:B1) Take a pointer to an Actor and directly control it (friend class or via SetPos(..),SetVel(..), ... functionsB2) Use the reference systen to control the Actor, so the actor checks if the Controller sent it any messages. This would mean you would have to make a switch statement in the Actor object, and handle all cases, such as SET_POSITION, SET_VELOCITY, ...How do you guys make this kind of stuff? 
  What you're really talking about here is the difference between a hierarchy and a component system. The general advice is to prefer composition (i.e. your option B) over inheritance. It's more flexible and, to me, makes more sense conceptually. Look up "component entity systems" for some more info. This is a good start.   ;  Thanks for the advice and link, will look it up.   ;  I would say option B but probably combine it with Finite State Machine.That way you can also use it for AI and objects communicating with each other (through messages which are passed to the states).So the keyboard strokes could be translated as messages to the states too.I would suggest reading "Programming Game AI by Example"In general, the idea is to have a class, let's say "ObjectState"This has its variables that are used for its actions (unless singelton) and several functions:OnEnter - ran when state is enteredOnExit - ran when state is exitedRun - runs every update callHandleMessage - ran when a message is received.Every thing is generally a state, that means "Attacking" "Patrolling" "Idle".And messages help you interact, let's say a gun is being used, the gun gets a message "HELD" so the gun switches state to "Firing" until it gets the message "RELEASED"So you can have the player as a PlayerState which will listen/receive messages sent from another class which listens to the keyboard.   ;I went with option B1 for a game of mine and I quite like how this setup worked. Controllers could be assigned to an Actor to take care of various behaviors, such as reacting to user input or AI enemies that autonomously hunted the player down. For the AI I happened to use a finite state machine, much like Shanee described, which worked out nicely for generating some useful behavior as well.The main pitfall I found however is that a Controller is a nice abstraction, but needs quite some thought to fit certain scenarios like physics simulation or network prediction. Both these topics typically require quick access to the data and are liable to be changing things like velocity and position outside of your Controller. Whether or not this is an issue depends largely on what Actor properties you want your Controller to influence and how much these overlap with networking/physics. I'd recommend hooking everything up as much as possible before you take your Controller abstraction too far.