3
\$\begingroup\$

I'm currently making a simple platformer in GameMaker Studio 2 and I've had people telling me that I need to separate the two things into an invisible wall collider mover and animation sprites pinned on top of it. I've also had people telling me that's overcomplicated and stupid. But I've never heard the reasons why I would or should do it either way.

\$\endgroup\$
3
  • \$\begingroup\$ Could you elaborate? It's very hard to understand what your question is. Are you talking about collision masks? \$\endgroup\$
    – altskop
    Commented Jun 20, 2018 at 18:00
  • \$\begingroup\$ yes. collision masks. \$\endgroup\$
    – Amet
    Commented Jun 21, 2018 at 3:41
  • \$\begingroup\$ Could you explain what you are trying to accomplish? It's impossible for us to tell you what is the best of two options if we don't know what you are trying to do. \$\endgroup\$ Commented Jun 21, 2018 at 15:58

2 Answers 2

2
\$\begingroup\$

The approaches you described are both equally valid, but as always your best choice depends on what you want to achieve.

Defining "sub-systems"

Notice that collision and animation systems are always separated, as the former is related to game logic and the latter deals with rendering. For example, GameMaker objects have a Sprite and a Collision Mask field because a sprite is used to draw an object shape, while a mask is used for collision checking. Unity does the same, as well as other 2D and 3D engines, so one can't really say not to separate the two things.

Moreover, advanced engines use separate shapes depending on what kind of results are to be achieved:

  • Object rendering: being the model a 2D sprite or a 3D mesh, this resource is highly detailed and used only for rendering purposes. The model is always rendered according to the game logic, being it an index of an animation frame or a spatial displacement due to a ragdoll system, but it never influences the game logic back.

  • Simple collision checking: convex primitives are used to check for collision, for they are fast to compute. They usually wrap the actual model more or less precisely, and different shapes are chose depending on the game object being static/dynamic or the precision required. Example: a capsule collider can be used to model a character physics, which is usually separated from the rendered model, as you can see in this picture from the Unity Q&A forums.

  • LOD collision checking: a separate collision shape can be used to check for collision at level of detail (LOD), when needed. On the GarageGames blog there's a clear example of separate collision shapes used for a tree: bigger and simpler boxes to detect if a collision has occured, and more and more precise shapes depending on how much precision is needed. For animated objects, the shape used for LOD collision check can be seen as a hierarchy of convex sub-shapes moving according to the animation applied to your game object. They are never as detailed as the rendered mesh, but a good precision in modeling them does the magic and gives good results.

I first said that an object model never influences the game logic back, and that an animated object's collision mesh can be moved according to the model animation. This is so because animations are usually treated as a separate resource rather than bonding them to a given model. After all, a single model can play several animation, while a given animation can be applied to multiple models.

Pros and cons

The advantages of specializing different aspects of an object interaction/appearance are several, we can combine separated data to achieve good-looking effects, such as: altering a walking animation to fit some steps on the ground; using some parameters to make the character aiming their weapon towards a given angle with regards to joint constraints; changing the speed a wheel revolves according to the car acceleration... All these can't be simply accomplished if using only pre-made animations due to their intrinsic limitations.

Of course, dealing with all these components leads to a higher complexity that requires a non-negligible effort from the programmer, compared to a simpler animation system. Early Super Mario titles didn't need such complexity, sprites were drawn based only on the character states and facing direction, without having separate components. On the other hand, Contra allowed the player to aim towards different directions, so there was (probably) a script dealing with movement and collision, and another script drawing the right sprites for legs and arms; yet, I see no need for separate objects to detect whether the player was hit, as the main physics collider was fine to do the job.

If you want your animations to be more interactive with the surrounding environment, or just to make them smooth using the right math, you can go for the objects collection, treating these model members as "slaves" of the "master" object (in order to avoid action conflicts). Otherwise, if it's way too complex you probably don't need it.

If the animation is rendered without any concern for collisions with the character's visible shape, you can get rid of the objects collection and render only the sprites on top of it: this is an animation system as any other, you're just using sprites instead of objects to do the thing.

\$\endgroup\$
2
\$\begingroup\$

I'll develop this answer as soon as I get more time and tell me if I'm off topic, I'm not really sure about what your actually asking. It's also one of my rare attempts to reply to a question, I'm always trying to improve the quality of my answers

If I understand correctly, you are talking about hitboxes and sprite being drawn on top of them.

A simple hitbox can be represented as a rectangle/square shape used for collision detection.

Mario sprite outlined with an hitbox

I have some arguments for this.

Easy collision detection

If you use Axis Aligned Bounding Boxes (AABB) (see SO question here) you can solve collisions pretty easily ; it consists of checking if two rectangles intersects and such algorithm is implemented easily. (If you consider your walls & hitbox being rectangles)

If I follow your question, you might be talking about collision masks (more info about this topic here) or pixel perfect collision. This is feasible but such collision routine is much intensive than AABB collision and probably not that effective in terms of gameplay.

Consistent gameplay

Say you're designing levels with a sprite s. Suddenly your art style changes and you grow your sprites. You have to make platforms wider, adapt your whole level...

Animation?

What about animating sprites ? A frame could be wider than another one. This lack of consistency could be a problem for collision since your "collision mask/box" changes.

Aesthetics / Perspective

I hope this is not off-topic since you're talking about platformers, but say you're creating a top down game with a simple perspective like pokemon or zelda. You want to have a hitbox at the feet of your character so it doesn't collide with the bottom of the wall.

Zelda-like top-down perspective

Here link is not colliding with the bottom pixel of the wall, he's like into it.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .