Jump to content
  • Advertisement

Archived

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

yodaman

Entity/physics..

This topic is 5652 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

I want to make a entity class, but dont know how to go about incorporating the physics engine to it later... ex: class Centity { Vector3 org; Vector3 pos; Vector3 Direction; Vector3 Velocity; etc... } or should I just wait for the physics and do it more like: class Centity { Physics phys; ... } or even class Physics { ... void Accelorate(Centity *e); ... }

Share this post


Link to post
Share on other sites
Advertisement
depends on the complexity of your physics engine i guess.

if it''s relatively simple then u can incorporate your vectors directly into your entity base class and even provide the operators to manipulate them. then your physics class (singleton?) could manipulate them via a pointer list.

if you wait until you have finished the physics engine then you will find it difficult to do tests and such. And if centity is the only thing incorporating the physics class, should they really be seperate? and if there are more classes that utilise the physics class should these classes all derive from some base entity class?


Share this post


Link to post
Share on other sites
Alrighty, so Im thinking maybe I should just make it more like

class PHYSICS
{
...
Cvector3 Acceleration(Cvector3 *velocity, float time);
...
};

Make it more universal.

thanx.

Share this post


Link to post
Share on other sites
you need a bit of Object oriented design. It''s easier if you put on paper everything you need. You can ask simple questions.

For example.
is a cEntity a cPhysics?
does a cEntity have a cPhysics object?
does a cEntity have a cRender Object?
does a cRender uses a cPhsyics?

so, on paper, you draw all those objects, and draw specific arrows to represent their dependancies ("Is a" arrows, verus "Has a" arrows, and maybe "Uses a"). You don''t need to go too far in detail, just on the things you are not sure about. On paper, you''ll see exactly what you need, and how to implement them in respect to each others. You can even start writing an interface between objects (like for cPhysics objects and cRender objects). After a while, it will become very natural.

So if a cEntity "is a" cPhysics,

class cEntity: public cPhysics
{

};

if a cEntity is more global, and should "have a" cPhysics, a cRender, ... then

class cEntity
{
cPhysics m_Physics;
cRender m_Render;
};

a cRender "uses a" cPhysics a lot, so maybe store a pointer to it would be useful.

class cRender
{
cPhysics* m_pPhysics;
};


ect...



I''m not a specialist of OO design by a long shot(and I''ll probably get flamed), but when I first started C++ lectures, that''s the first thing we learned, even before starting coding. I''d better get back to it though, it''s very ''rusty''.

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!