next »

[Charybdis]

Here's an interesting question:
When programming platform games, where are your agents' pivots?
I mean, is the "position" of the agent at its centre of mass, or do you prefer to have the pivot at the feet of the character?
I can see pros and cons for both ways.
I assume if it's using a proper physics engine then the pivot is at the COM, but if the physics are hacked then why not use the feet?
What do you do? Is there a preferred way?

[st33d]

The word pivot means a point on which an object turns. I generally call it an anchor.

I place it center-bottom of the image to be rendered because when rendering from the feet up it's easier to see errors colliding with the floor.

The code for my collision uses a rectangle and is generally ignorant of the rendering anchor because I feel that rendering and collision code shouldn't mix.

[Glaiel-Gamer]

It doesnt matter as long as you're consistent with the rest of the entities in the game world so I prefer the center of mass

[Evan Balster]

Center of mass, typically, though I've done it the other way once or twice.

[technogothica]

If you are rotating or scaling the agent in any way, the location of the center point may be important. If you are only translating, then any position will do.

My game uses a 32*32 tile grid, and I use the center of the tile as a spawn point for entities. So the center point of my characters is usually the middle of the sprite on the X axis and 16 units from the bottom on the Y axis. This just makes it easy to line everything up in the editor. Runtime effects like projectiles I usually use the center of the sprite.

My physics is very simple and does not include rotation of the collision rectangles (though the sprites do rotate).

[Charybdis]

Yes, these are the kind of answers I was expecting.
So generally, the answer is "it depends".
The reason I asked in the first place is because in my current game, the character needs scaling so I use the foot position. But the collision calculations come from the centre of mass and so the code was a bit uglier than I would like.
I just wondered if there were pros and cons I hadn't thought of.
Is this a common dilema in game programming?

[technogothica]

I just wondered if there were pros and cons I hadn't thought of.
Is this a common dilema in game programming?

Every decision you make in programming will come back to bite you on the butt sooner or later.

(You have no chance to survive make your time)

[BorisTheBrave]

I use box2d in my projects, and it allows the pivot point (called the local origin), to be different from the center of mass. So I generally allow the pivot point to be arbitrary, and code up the rest of my game to support it. I pick whether I am most likely to manually rotate around. For characters, it tends to be center-bototm, and obstacles the center.

[Overkill]

I usually make the "position" of each entity be top-left corner of their hitbox, and add width/height as appropriate for the various floor/wall/ceiling checks. For collision with other entities, this is really simple, since I can write the collision detection without too many repeated calculations.

Code:

return a.x + a.width >= b.x
    && a.x <= b.x + b.width
    && a.y + a.height >= b.y
    && a.y <= b.y + b.height;

My platformer game ideas usually don't have scaling or rotation that affects movement/physics, and does rot/scale more just for visual effects. However, I imagine if I did, I might move to a center-of-mass style calculation.

[rivon]

I don't use physics. Just ySpeed += gravity * deltaTime; every frame so I don't use any pivots or whatever. And the collisions are just rectangles colliding so no big deal.

[st33d]

I usually make the "position" of each entity be top-left corner of their hitbox, and add width/height as appropriate for the various floor/wall/ceiling checks. For collision with other entities, this is really simple, since I can write the collision detection without too many repeated calculations.

Code:

return a.x + a.width >= b.x
    && a.x <= b.x + b.width
    && a.y + a.height >= b.y
    && a.y <= b.y + b.height;

My platformer game ideas usually don't have scaling or rotation that affects movement/physics, and does rot/scale more just for visual effects. However, I imagine if I did, I might move to a center-of-mass style calculation.

That intersection code should read:

Code:

return a.x + a.width > b.x
    && a.x < b.x + b.width
    && a.y + a.height > b.y
    && a.y < b.y + b.height;

If b.x is at a.x + a.width, it is NOT intersecting. Unless of course you're resolving your collisions differently to the rest of us.

[Overkill]

Heh. Yes, I suppose the inclusion of an extra row/column isn't necessary.

When debugging I draw hitboxes using a rectangle of (x, y, x + width, y + height) including the bottom row/right column, and I manually finetune hitboxes for entities (because the boxes are smaller than their frames), so it works out fine. The intersection happens in the same area that is visualized when the hitboxes are designed, so it is pretty irrelevant here.

Anyways, sure, we can nitpick at this sort of thing. It is dumb, and if it needed to be fixed I would do so, but for now it doesn't matter -- it is consistent when hitbox debug rendering is visible -- and thus works as expected. And the hitbox necessarily is smaller than the actual frame of the sprite, so the sprite's exact frame size is never used to calculate the hitbox size.

But yeah, it really is sort of dumb. I agree.

[Charybdis]

for axis aligned bounding box collisions I like to do something like this:

(v2 is my 2D vector)

Code:

v2 to_enemy = enemy_pos - player_pos;
v2 half_size_sum = (player_size + enemy_size) * 0.5;
if( fabs(to_enemy.x)<half_size_sum.x && fabs(to_enemy.y)<half_size_sum.y )
{
   // collision occurred
}

Makes for neater code