Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

mickey

design issue, ideas on how to make my classes interact to each other?

This topic is 5761 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, it''s class Ball {}; class Paddle {}; class PartcleSystem {}; class Input(); class MainApp { // all the above classes are here }; okey, aside from making them friends or storeing pointers to them, is there any other way? class Ball needs class paddle to check for collision, as well as the particle system so it could trigger some particle effects.., classpaddle then needs CInput so it could move.., thanks,

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
What they all seem to have in common is that they can collide with each other. Use inheritance for that, or make them all friend classes or something.

Share this post


Link to post
Share on other sites
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."

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
quote:

You can actually make collide and a few other functions static methods of the physical object class (so they can access private variables, etc).



hiya Oluseyi,
am not sure if i understood you correctly, you''re telling me to use static functions so i could access the non-static private members... but this isn''t possible? Also, what do you exactly mean by a ''utility'' function?

okey sorry, i''m confused, you detest NitroSR'' concept but you''re also suggesting me to make all my entites to inherit from a new class PhysicalObject? i mean, what''s the difference between what NitroSr said and what you''re suggesting me to do?

okey if it''s okey i''d still like to hear more ideas, thanks!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
hiya risingdragon3,

okey thanks! but do you guys mean by this "compile-time-polymorphism, provided by templates" is (or something like this)

template void Render(T object)
{
object.Render();
}

so i should make all my game objects inherit from a base class(physical object) and use global templates functions to have their own specific behaviors?

thanks,

Share this post


Link to post
Share on other sites
More like this:
(btw use source tags so that the template parameters don't disappear on you...)

  
template <class T> void RenderObject(const T& Object);
template <> void RenderObject(const Ball& B) {
...
};
template <> void RenderPaddle(const Paddle& P) {
};

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]

Share this post


Link to post
Share on other sites
hi guys, okey here''s my plan, pls take some time to look over it,


  
class Mesh
class Object
{
// has a render function

// has a pointer to a mesh object

// contains functions/variables for world transformation

}
class GameObject(ie, PhysicalObject) : public Object
{
virtual Update();
virtual ProcessCollision(const GameObject& obj);
virtual ProcessInput(const Input &input);
....
}
class Ball : public GameObject
{
// just override the necessary virtual functions

}
class Paddle : public GameObject { }


so you see, class Object can be used on other heirarchies like a menu system, so for my objects inside the game, GameObject should act as the base class for all the objects inside my playing area..,

However my Particle effects classes are inside my Particle Emitter class(Has A), therefore there''s no access to it other than Particle Emitter, so what do you guys suggest of this? and besides, it''s not really a ''game object''..,

many thanks,

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!