3
\$\begingroup\$

I'm building a custom game engine, in C++ using SDL, and I'm not sure how I should define the position of my game objects. I tried googling a bit, but I wasn't sure how to refine my search terms to get what I'm looking for.

Should I define the position (x, y) of my object to be the top left of the object, for ease of rendering? Since my game is tile based, it also makes sense to have the position of the tiles as the top left position.

Perhaps I should define it to be the center of the object, which seems to make more sense, logically? If we use width/2 and height/2 to calculate it, does the slightly-truncated integer for even-sized objects matter?

How do other games do this? Right now, my objects are defined by the top left corner, and it's annoying to do operations that find the center of the object.

\$\endgroup\$
3
\$\begingroup\$

Normally you will need three different sets of coordinates.

  1. Store within your object class the top left corner as a vector, e.g. <corner_x, corner_y>.

  2. For most tile-independent game logic, use the object's center <center_x, center_y>.

  3. For realistic movements and application of force on object's with mass, store the object's mass center <mass_center_x, mass_center_y>.

You will need 1) for operation's like aligning your objects to each other, tiling or dragging with mouse in your map editor. It could be enough if you have a truly a game with solely tiles like chess.

You will need 2) for all kind of (tile independent) animations, rotational velocities and simple accelerations, collision detection and distance calculations. You might need that one if you are interested to check if your mouse pointer is hoovering over your object etc. Chance is that you need these coordinates too and they should be updated only if necessary to ease some calculations.

You will need 3) for when you apply forces for acceleration and/or your object's are able to rotate. Most likely not your cup of tea here. But if you are interested in creating a flexible game engine, keep this option viable. For example, I crated a user interface where a user can set a boundary box by dragging his mouse over an object and set optionally a mass center instead of the standard x/2, y/2.

Edit: Truncation does matter and you need to account for this by storing it as a float point precision and update the position accordingly. If you don't do this, there is a good chance that your rectangles' sizes will vary +/- 1 pixel conditional on their position on screen which can look weird. That's why for tile based game's your idea of having topleft corner as standard coordinates is a reasonable choice.

\$\endgroup\$
0
\$\begingroup\$

Let the developer choose. Most engines with 2d capabilities I've used allow this.

\$\endgroup\$
0
\$\begingroup\$

Games typically don't hardcode it either way. You have a point, which is the position of the object's origin. The object then has a graphics model/sprite and a root physics body, either of which can define a shape around that origin.

One object may decide to define both its model and body as [-0.5,-0.5];[+0.5,+0.5], making the origin at the center.

Another object may decide to define its physics body as [-0.5,0.0];[+0.5,+0.8], which means that the center of the body is at its "feet" (the middle of its bottom), while the sprite may be given the range [-0.6,-0.1];[+0.6,+0.9] which makes its sprite a little wider than the physics body in all directions.

Physics will need to know some additinal details about its center-of-mass for most "realistic" simulations, but graphics shouldn't have any reason to care at all about how the origin relates to the shape actually being drawn.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.