Sign in to follow this  
Breaka

Who keeps track of position ?

Recommended Posts

Hello, Architectural question: In designing a 2D game should objects like Player/enemies/random objects/floor tiles/etc KNOW their position on a map or screen. OR Should there be an object, Q, that keeps track of everthings location (screen coordinates and map coordinates)? So when it is time to draw an object, one just calls object.Draw(x, y) where x and y are provided by the object Q ? Thanks in advance for any input and opinions.

Share this post


Link to post
Share on other sites
na man, it's over-complicating. Objects should know their positions. Not just for drawing, but for physics, ect... Also, for example, how about velocity? That won't make much sense to keep the velocity separate. So all properties of objects should be inside the object.

You can store the phsyical properties inside a base class where all 'physical' objects are derived from, or inside a separate physics structure, and using compositions (have a physics object and a render object pointers for each objects). so you'd end up woth something like this

void CObject::Update(float dt)
{
m_pxRenderObject->Update(dt); // animations and whatnot
m_pxPhysicsbject->Update(dt);

//.....
}
void CObject::Render()
{
m_pxRenderObject->Render(m_pxPhsyicsObject->GetPosition());
}

Physics objects can be anything from just a position vector (for static tiles), a particle (a moving point) for bullets, a rigid body for enemies and characters.

my 2 cents.

Share this post


Link to post
Share on other sites
Hi,

I would advise against putting any rendering variables into your entity class. The reason being is now, maybe you draw using 2D screen-coordinates. But let's say a few months from now you want to put in 3D models? Or you want to make them sprites? Or you want to port to another platform? This could potentially mean drastically changing a lot of variables. An animation-renderer would require at the very least, some sort of variable to keep track of what stage of animation it's in and extra data to keep the different animation stages.

By separating the render from the logic, you can modify the renderer without ever touching the object's code. You should think of your entity class as anything involving LOGICALLY describing the entity. The renderer should then take this object and represent it on screen.

You *can* do this by composition, but be weary of the fact that the renderer may need to know some logical property of the object in order to render it. In oliii's example, can the render object easily refer to something inside the class that it is composed in? [edit: Could be as simple as passing the "this" pointer]

-j

[edit]: Also, want to be aware of things like:
-when render objects need to share a shared resource (eg. textures)
-does the code constructing this object know enough about rendering to make the render object? Does it know it abstractly enough such that you can change the rendering object without changing too much code?

Share this post


Link to post
Share on other sites
That isn't to say that you can't put rendering code inside objects. It's actually the easiest way to go and it's the way i do it. But as mentioned, if you ever want to change that code and your program gets big, you would have to change ALL of it, and that might be a lot. Since i'm personally using openGL and porting would not be an issue, i decided just to schlop the rendering into a virtual function of each object.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this