If I want to create a 2D game map which features areas traversable by a player through standard up/down/left/right inputs, and then have areas that are NOT traversable... perhaps just a bush, or a sign post, or a rock.

What is the appropriate agent to enforce these rules?

It seems like the trendy thing is to ship off these responsibilities to Box2D, but that seems wrong to me. Is there a technique with lower overhead to produce the same effect? Is it as simple as inventorying and enumerating through every rock and making sure the player can or cannot walk to the space they are trying to walk to? That's how I am doing it now.

  • 1
    \$\begingroup\$ Bounding boxes and spatial partitioning. Though I'm fairly sure this question has been asked before. \$\endgroup\$
    – House
    Jan 8 '13 at 19:35
  • \$\begingroup\$ It depends on the style of game. There's a big difference in how you can implement things if you're doing things free form or if you're sticking to tiles. \$\endgroup\$
    – Tetrad
    Jan 8 '13 at 20:07
  • \$\begingroup\$ tile map, free movement \$\endgroup\$
    – Jasconius
    Jan 8 '13 at 20:52
  • \$\begingroup\$ Bounding boxes works fine for Silverdale, we have up to 100 entites moving around a map at a time and no slowdowns (no spatial partitioning needed!) \$\endgroup\$ Jan 8 '13 at 23:36

There are multiple different solutions, each with their good and bad points. Three ways:

  1. Using a dedicated physics engine, such as indeed Box2d. This is very helpful when you want to do all kinds of crazy calculations with your objects. However, when you don't really need the physics-part of the engine, it is often better to write your own simple collision engine.

    Pros: easy to implement.

    Cons: slow, can behave unpredictable at times.

  2. Using Bounding-boxes. This is in fact what you are using now. Store for each collidable object in your scene a box (or another shape, but a box is the easiest) and then check when the player moves if he/she will intersect with these boxes. If they will, then prevent the movement from happening.

    Pros: easy to implement as well.

    Cons: With a big amount of objects, calculating becomes extremely slow.

    Also worth noting: This system is more or less the same as part of what happens internally in Box2d.

  3. Using a Tile-based system. Divide the map you have in a square grid(can easily be conceptualized using a two-dimensional array). Before the game starts, fill in each of the grid's tiles that intersects with the position of one or multiple of your solid objects.

    Pros: relatively fast. Does not get slower when using more objects in your map.

    Cons: Less precise than the above(unless you use a pixel-size grid). Possibly more memory-intensive than the above.

  • 1
    \$\begingroup\$ Bounding boxes isn't necessarily slow -- not unless you get into thousands of boxes, and even then, you can use spatial partitioning to stay efficient. \$\endgroup\$
    – ashes999
    Jan 8 '13 at 22:24
  • \$\begingroup\$ True. spatial partitioning is a great way to circumvent this problem. \$\endgroup\$
    – Qqwy
    Jan 9 '13 at 0:27

You must log in to answer this question.

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