Other design solutions include inheritance and templates. Note you must make seriously consider each solution before design the program. For example, you should not use inheritance unless the objects are related.

Kuphryn

I once wrote a Pong game in Java and had similar classes. I had them all inherit from a base "GameObject" class which could be placed in a list of game objects and contained all collision detection and physics code along with ''virtual-like'' functions for drawing, collision response.

Now, come to think of it, I believe I may have made no distinction between the paddles and the ball(s) at all, and had them all as instances of the same GameObject class. However using inheritance enhances the design aspect of things in that you can better tune object specific behavior.

class GameObject {   protected:   Vector position;   Vector velocity;   Vector totalForce;   float  mass;   float  boundRadius;   // for bound box   Vector boundMin;   Vector boundMax;   // you may have objects composed of smaller objects.   GaneObject *parent;   // for a link list implementation.   GameObject *next;   public:   bool collidesWith(GameObject &other);   void setPosition(Vector &pos);   void setVelocity(Vector &vel);   void exertForce(Vector &force);   virtual void update(float deltaT);   virtual void draw(DrawContext *dc);   virtual void collisionResponse(GameObject &other);   };

There are many more members you can throw into this class, of course. But once you''ve got this, you can create your more refined objects that inherit from "GameObject."

I detest the "game object" or "global object" class idea, as it suggest relationships between entities that actually have none. Furthermore, it is often a compile-time device better implemented using templates.

In mickey''s example, Ball, Paddle and the individual particles in ParticleSystem are physical objects and may or may not interact with each other in consistent fashion. These classes should therefore all inherit from a new class PhysicalObject, and a utility function bool collision( const PhysicalObject & p1, const PhysicalObject & p2 ) can test for collisions between these and future physical objects. You can actually make collide and a few other functions static methods of the physical object class (so they can access private variables, etc).

A physical object can accept forces as stimulus, which change internal properties like acceleration, which alters velocity which in turn changes position. Input from the user can then be viewed as one such stimulus, so there only needs to be some "glue" code to convert user input into stimulus.

I believe what Oluseyi is saying (if I''m wrong...I''m sorry )
is..

ball, paddle, etc...all are _phsyical_ objects. They can interact together, hit each other, etc.
Therefore they should all inherit from an PhysicalObject class.
Drawing isn''t really related. You don''t relate objects based on whether they can draw.. I mean, the menu can draw itself. so can the ball and paddle and background and so forth. Are these all related? no! the ball and paddle are (they are phsyical objects within the game) but the rest ain''t. they are UI objects (and maybe they would be in a UI hierarchy) but they aren''t related to the ball and paddle.

So, really, what you want is compile-time-polymorphism, provided by templates. You want to draw each object differently - but you know at compile time what each object should draw itself like. So instead of having a virtual method that draws each object (and is dispatched at run-time)..instead have a template function that you specialize to draw each object differently.


-----------------------------
Gamedev for learning.
libGDN for putting it all together.

More like this:
(btw use source tags so that the template parameters don't disappear on you...)


something like that. Uncompiled, tho.

-----------------------------
Gamedev for learning.
libGDN for putting it all together.

[edited by - risingdragon3 on November 4, 2002 10:01:01 PM]

[edited by - risingdragon3 on November 4, 2002 10:02:17 PM]