I'd say making a "Bump Map" where each "pixel" represents a tile would be a very nice solution.
Like this:
1101
1001
1011
0011

zeros-passable
ones-not passable

Quote:Original post by KG_Brad
You're making an MMO that's a sidescroller? I've never seen any before, so hopefully you're the first!

Maple Story, and it's pretty good for about 5 hours (until you realize just how damned long it takes to level).

Quote:Original post by Captain P
With 100 moving objects, you end up with 10.000 checks per frame already.

It isn't quite 10,000. It's about half that. That's because if Object A has been checked against Object B, then Object B doesn't need to do the check again against Object A. So for 100 objects the number of checks would be 5050.

Quote:Original post by catch
I was thinking of doing a grid-based system. My game (2d) has tiles that are 256x256. The server maintains a list of tiles in the game space, and within those tile squares there is a list of object IDs.

Only those object IDs, if there's more than 1, are tested against each other (and there are more filters from there, certain flags... such as stationary objects or non-collidable objects).

The problem with this method is when objects start to overlap multiple tiles. Do you add them into multiple tile lists? Possible, but tricky and time-consuming to manage. Or you can check in a fixed radius of tiles around each object, but that puts an upper limit on the size of any object within your world.

You could try putting objects that don't fit into another list, one covering several tiles at a time. But you'd still end up with cases where they don't fit all the time, so you'd have to do it again recursively. And then what you've got is a regular quadtree. [grin]

As a side note, pixel-perfect collision is overrated and creates a nasty dependancy between your gameplay and your art. You really don't want an artist to draw you a nice new sprite with a big fancy hat/haircut and suddenly find that the collision area stops you walking into confined spaces. If you must do pixel based collision, then use an entirely separate, non-visible, set of images.

Quote:Original post by Sc4Freak

Quote:Original post by Captain P
With 100 moving objects, you end up with 10.000 checks per frame already.

It isn't quite 10,000. It's about half that. That's because if Object A has been checked against Object B, then Object B doesn't need to do the check again against Object A. So for 100 objects the number of checks would be 5050.

Depends on how you approach it. When you're moving objects and immediatly check if they can move, you'll get 10.000 checks, because you can't ignore any objects: there's no guarantee about their current position. A can move into B, and get pushed out. B can then move into A, and B needs to be pushed out as well. It needs to check against A in order to do so.

Only when you're moving all objects first, and then check if they're stuck and need to be moved out, you'll get a lot less checks, true. I'm not sure what implications that would have on the design of a collision system, but it's worth a look. Thanks. :)

Quote:Original post by OrangyTang

Quote:Original post by catch
I was thinking of doing a grid-based system. My game (2d) has tiles that are 256x256. The server maintains a list of tiles in the game space, and within those tile squares there is a list of object IDs.

Only those object IDs, if there's more than 1, are tested against each other (and there are more filters from there, certain flags... such as stationary objects or non-collidable objects).

The problem with this method is when objects start to overlap multiple tiles. Do you add them into multiple tile lists? Possible, but tricky and time-consuming to manage. Or you can check in a fixed radius of tiles around each object, but that puts an upper limit on the size of any object within your world.

You could try putting objects that don't fit into another list, one covering several tiles at a time. But you'd still end up with cases where they don't fit all the time, so you'd have to do it again recursively. And then what you've got is a regular quadtree. [grin]

As a side note, pixel-perfect collision is overrated and creates a nasty dependancy between your gameplay and your art. You really don't want an artist to draw you a nice new sprite with a big fancy hat/haircut and suddenly find that the collision area stops you walking into confined spaces. If you must do pixel based collision, then use an entirely separate, non-visible, set of images.

I had thought of that same issue. My initial thought would be to yes, check the surrounding tiles if they contained an object. I'm (hopefully) not looking at much of a density problem, so the checking overall would be fairly small.

I wouldn't worry about recursive tests since testing will occur by the other objects shortly anyway, and I'd process per actor, per update, so I don't believe there would be a loss in visual accuracy. The order of checking would also make so each tile would only check four surrounding tiles, not all 8.

I'm sure there's faster or more organized methods. This is what I came up with.....


+1 on the per pixel thing... I think a combination of sphere/square bounds tends to be accurate enough, especially if you allow rotations (for boxes).