Exactly how reliable is World for a real game? (Big levels)

[Jasoco]

Like for big levels that will have many many many bodies and shapes.

Example 1: A normal side scroller with tile based maps. What, are you going to make a body (rectangle) for every tile that's impassible? Will this slow Löve down immensely? Or is the collision super fast? And does it calculate stuff not on screen? With a screen of 640x480 you have 20x15 tiles which ends up 300 32x32 shapes on screen at once. And if the map is huge then you could have thousands.

Example 2: The Braid Method. Braid's maps used a shape based mapping system where the ground and walls were shapes. They could be any size, any shape, and then the actual graphics were drawn over this layout. But this requires a lot of good art work and you have to make each map a big painting so to speak. So basically each level in Braid had hundreds of shapes, and many megabytes of hand painted graphics overlayed.

So what is the best method for using collision detection via the World and Body features in a game that might have huge maps?

It's just something I've been pondering for a while. I'm still learning the World features in hopes that I could replace my hand made collision detection with it, but my maps can be huge so I don't know how useful it would be. I also wanted to make a side-scroller, so I started trying to do collision myself before giving up after stupid problems.

[Robin]

Example 1: A normal side scroller with tile based maps. What, are you going to make a body (rectangle) for every tile that's impassible? Will this slow Löve down immensely? Or is the collision super fast? And does it calculate stuff not on screen? With a screen of 640x480 you have 20x15 tiles which ends up 300 32x32 shapes on screen at once. And if the map is huge then you could have thousands.

Yeah, it will slow down. There is nothing LÖVE-specific (or even graphics-specific) about Box2D. At the very least, think of something funky, so the world is not too large, and keep one shape and body for anything that could be counted as one object.

If you don't want to simulate the whole world all of the time, maybe using Box2D is not for that game.

[Fizzadar]

I'm using method2 for my game, seems to be working quite well so far, you can definitely have huge sections defined in very few shapes, and one large image. I also find it easier to design the entire level in photoshop, then in-game compile the shape positions on top.

[Jasoco]

I really don't want to design the level as one image. I prefer the old tried and true method of space saving tile-based levels. Which means I'd have to make the World comprised of hundreds of blocks to check against. Unless I create some complex algorithm to scan the tile grid and make polygon shapes for each large section of the grid that is impassible. Which would be way too hard to be worth it. I mean if I were an artist, yes of course I'd want to make beautifully painted levels to romp around in.

I just have to find the right method for collision in a side scrolling game. I mean, modern side scrollers have been around since 1984. And back then consoles were slow and limited on memory. I guess I just have to rethink my collision check method again.

See, I switched to LÖVE after using Power Game Factory for a few years. Which is a really fast side scrolling game creator written in RealBasic. So I'm just getting re-used to coding it all myself again.

[osgeld]

what about a hybrid solution, tile maps with shapes overlaid, then you would not have to do every tile for large objects and still get to use your tile engine

I have done this before in luaplayer for psp, basicly make out a map in your fav editor, screenshot it (or whatever) and load it up in the gimp and polygon it out using the web map tool

[tunzi]

What if you split all drawable or collidable static objects into on screen segments, and then maintain an active pool of objects based on the player's location in the level. That way you are only drawing or colliding part of a level instead of the whole thing. If your player moves over far enough switch to the next list of active objects. You could generate this list on loading the level or dynamically whenever the player moves half a screen length or so.

This should in theory allow for arbitrarily sized levels, but I am interested in hearing other solutions.

[Jasoco]

what about a hybrid solution, tile maps with shapes overlaid, then you would not have to do every tile for large objects and still get to use your tile engine

That was an idea too. But then you end up with odd shaped polygons. Is it feasable to make a huge solid level, floor, walls and ceiling one polygon?

I've been playing a lot of NEW Super Mario Bros. Wii (Awesome game BTW. BUY IT NOW!) and see how far side scrolling engines have advanced since SMB first did it more than 25 years ago. There's a lot of stuff I'd want to do in my engine. Moving floors, circular moving floors, rotating blocks in air, tilting platforms, the usual crushing ceilings, spikes, lava walls and waves, all sorts of ways to kill the player if I can figure out how to do it. Obviously finding out if the player touched something deadly is easy as checking the Player against one of the Spike or Lava shapes. I just want to know what the limits are to the number of world objects you can have.

I should spend today testing it out.

Seriously, if you haven't seen NSMBW, check it out on YouTube. It is... amazing. And the Bowser battle at the end of world 8 is epic. More epic than Galaxy was. More epic than any Bowser battle before it.

What if you split all drawable or collidable static objects into on screen segments, and then maintain an active pool of objects based on the player's location in the level. That way you are only drawing or colliding part of a level instead of the whole thing. If your player moves over far enough switch to the next list of active objects. You could generate this list on loading the level or dynamically whenever the player moves half a screen length or so.

This should in theory allow for arbitrarily sized levels, but I am interested in hearing other solutions.

That's an idea too. I guess I could set it up to load segments at a time and remove the previous off screen ones when not needed as I go. Let me do some speed tests first. Whenever I get to that I will post my results.

[osgeld]

what about a hybrid solution, tile maps with shapes overlaid, then you would not have to do every tile for large objects and still get to use your tile engine

That was an idea too. But then you end up with odd shaped polygons. Is it feasable to make a huge solid level, floor, walls and ceiling one polygon?

not with the physics system, but you can define polys and see if anything is in between 2 points thats how my last ludemdare entry works (and that map is LARGE, like 28800 pixels wide), you can of course use the physics for everything else (in my case the player ship)

http://www.ludumdare.com/compo/2009/08/ ... ler-final/

[Jpfed]

The solution used for Adrift (a tile-based game that I'm working on with a friend, found here: http://github.com/jpfed/Adrift) is as follows:

1. Create just one physics body with 0 mass (treated as immovable by box2d). Any tiles that will not move can be attached to that physics body.
2. Have a 100x100-ish array of 1s and 0s for solid or not-solid tiles. Then, have a function that scans over the array, noting every horizontal run of consecutive 1s. For each horizontal run of 1s, you only need to instantiate 1 big shape that spans the run. Maybe you could use vertical runs if that's better suited to the kinds of levels you have.

You can do more sophisticated things, like sloping tiles, if you make polygon shapes instead of rectangle shapes. I have a code sample that does this, but I haven't put it anywhere online. I could put it up if you're interested.

Any moving stuff is treated separately from that.

As far as I know, typical modern hardware can handle 200 BODIES. But the one body, 200+ shape method for representing the static parts of the level is very cheap and runs on my old-ish computer without a problem.

[kikito]

If your levels are not going to be tile-based, but "shape-based" (like Braid) then an option for optimizing the amount of shapes on the level would be using boolean combinations.

Say that your level body has N shapes and you want to add shape x.

Assuming that you have a shape constructor based on the additions of two shapes, the algorithm would be:

Code: Select all

-- levelShapes is the current list of shapes that the level has
-- newShape is a new shape being added to the list.
function addShapeToLevel(levelShapes, newShape)
  local intersectingShapes= {} -- the list of all the shapes that intersect with newShape
  for i,shape in npairs(levelShapes) do
    if(shapeTest(newShape, shape)) then -- if a shape in the current level intersects with the new shape
      table.remove(levelShapes, i) --remove the shape from the current level
      table.insert(intersectingShapes, shape) -- add to intersectingShapes
    end
  end
  
  for _, shape in pairs(intersectingShapes) do
    newShape = shapeCombine(newShape, shape)
  end
  
  table.insert(levelShapes, newShape)
end

Now the "only" thing you need is two functions:

• shapeTest(shape1, shape2) that returns true if shape1 and shape2 intersect.
• shapeCombine(shape1, shape2) that returns the boolean combination of shape1 and shape2.

Both functions are implementable right now, but it might prove tricky - specially if you want to support circled shapes (you would have to transform circles into polygon shapes with many segments).

shapeTest can be implemented using "shape.testPoint" and "shape.testSegment", and shapeCombine would need ... some googling