Tiled world collision.

edited January 2014 in Help request
Hi, quick question. I am working now on a procedural generated top down game. The game is tiled based, each object uses a square of its own size for the collision.

When walk against a wall I don't collide against the borders of the tiles (as happened in my other side scrolling game - https://forum.orx-project.org/discussion/6668 ).

Any ideas why? My guess would be that this happens because the top down game has no gravity, but I am not sure.

Could I take that (no collision on the walls borders) for granted? It would save me a lot of time if I don't have to develop an algorithm to determine the collision meshes of the scenario.

Comments

  • jimjim
    edited February 2014
    Can you provide an image or something? I am not actually getting what you are looking for.
  • edited February 2014
    I'm not sure why you don't get collisions, as long as your shapes are correctly defined (including flags/masks), you should get collisions.

    Remember that you can display debug collision info in debug & profile builds using the config property Physics.ShowDebugInfo.

    You can toggle it quickly using the console by typing:
    set Physics ShowDebugInfo true
    set Physics ShowDebugInfo false
    
  • edited February 2014
    Thanks for the replies guys.

    Probably I didn't explain the problem properly. In the video I posted I had a side scrolling game. The ground was formed by several different 64x64 square graphics, each of them had a 64x64 collision box. When the goats (also a collision box) tried to walk on the ground they would stumble on it (as shown in the video). In this case I had to create a single collision box for the whole ground.

    But when I created a top view scene, where the walls where all 64x64 graphics with box colliders (one box collider for each wall), I can walk from one point to another against the wall and there is no stumble. Here is one example:

    I move from the starting point:
    https://drive.google.com/file/d/0B0UdeUM9pB-ndHJLLTJjT1VhXzA

    Up to the right wall (with a resulting force pointing toward the right bottom of the screen):

    https://drive.google.com/file/d/0B0UdeUM9pB-nRURTTjhKbmx0QjQ

    And the movement goes smooth. I would expect the sphere would stumble in the point the two wall colliders met (just as happens in the video I posted before).

    In this example, having one collider for each tile worked flawlessly, but I am wondering If I can assume this behavior is the expected one, or the one in the video is the expected one.
  • jimjim
    edited February 2014
    Now I get it what was you talking about. It happens when your ground is made of several box shape and you character or other object (also made of box shape) is trying to move over the ground. They get stuck on the corner where edge collides. It's a common box2d problem. But there are solutions.

    Using circle or polygon with clipped edge solves the problem.

    Another one is using edge shape or ghost vertices which uses edge shape. But these features are introduced in box2d 2.2. Hence they are not avaiable in current orx box2d implementation.

    The stumbling is common and you would notice it when a box shape is moving on a ground made of small box shapes. And is not noticable using circle or polygon with clipped edge. More information is given here: http://www.iforce2d.net/b2dtut/ghost-vertices

    So, both behaviours are common depending on your situation.
  • edited February 2014
    Thanks for the reply.

    The strange thing is... the ghost vertice is not happening at all in my example... I tried using a box collider and a sphere collider for the blue sphere.

    Anyway, I guess I will just have the scene editor to join adjacent boxes, it will be a little annoying to detect them, but better safe than sorry.

    Thanks jim.
  • jimjim
    edited February 2014
    I think the ghoat stumbled because the collision response impulse is lesser than gravity, that's why they were stuck. In you later project, there is no gravity or opposing force, that's why collision response works and no stumbling.

    But I don't see why you have to joint adjacent boxes?
  • edited February 2014
    For the top down game is indeed not needed. The project has two parts, a random map generator and a scenario editor.

    I wanted the editor to be more or less agnostic to the game style, so, if I ever want to use for a side scrolling game I could. Anyways, I will leave that for future releases =)

    Thanks again Jim.
  • jimjim
    edited February 2014
    No problem. For a platformer if you set your player like this then there should be no problem even if you use multiple box shape for ground, it wont get stuck no matter what. Using a circle instead of a box for ground collision.
    oneway-tinybounces.png

    Also, are you using static bodies for ground and wall? Like setting AllowMoving and Dynamic to 'false'?
  • edited February 2014
    Dynamic is set to false to both of them. Walls are solid while grounds are not solid.
Sign In or Register to comment.