Forums » Help » Would appreciate some thoughts on collision

OK, so I'm looking at a game for mobile devices, sort of a ball-going-through-maze type game, with complex worlds to explore, by tilting the device.

Naturally, Weltmeister is the tool for the job with the worlds being tiled, but I'm having trouble dealing with collision and would appreciate some thoughts.

Specifically, I want to have walls that don't end on a tile boundary. To elaborate: instead of walls being full tiles, I want to have tiles that have a wall running through the tile, so that the only the centre third of a tile is a wall.

I thought about trying to manipulate the array that makes up the collision map setup (since that's aware of 1/3 and 2/3 boundaries) but it's only suitable where only one side is a solid, and I need both sides to be solid, as it were.

I did also think about making the collision map 3 times larger than the main map and using full collision maps that way but that feels clumsy, even though I can generate the map automatically from the main level data.

Anyone encounter anything like this, and anyone with any ideas about dealing with it?

The other issue of the player being a ball and thus not square for the purposes of collision detection, I think I can get around that by being very careful with the image itself, by trimming the entity edges and using offset to make the image be larger than the entity size and just make it look good in other respects (which gives the player a potential advantage in collision detection, which is a bonus really), but if anyone has any ideas about dealing with circular entities, I'd appreciate thoughts and suggestions.

Hi Arantor,

I did a similar thing some time back while starting to learn impact. I wanted to simulate those simple games you get with a maze and ball bearings. In the end I used box2d. Initially I traced the collision tiles but in the end I generated the maze externally and imported the maze into impact. (I also tried using a smaller tile size for the collision map which worked but I still found the box2d version better for the collisions with circular entities).

Hmm, thanks for your comments :)

I'm not really so worried about the circular nature of my main entity, I think I can side-step that, but my real issue is the nature of collision maps in general; I essentially need a collision map tile that doesn't exist and can't exist in the current environment - and as I understand Box2D support, I'd have the same problem - because it seems to work off using making boxes out of the collision map.

The other problem I have is that I have items which make the map dynamic which will cause the collision stuff to be handled differently - I think I'm going to have to do a lot of experimentation as to whether using smaller tiles will work or whether I need to re-engineer a new collision tile system :/

You could just check against the graphics using a pixel collision check, create a black and white mask for each level design and use a radial collision check for the ball?

Its a pretty efficient method of a low cost complex collision system ...sligt chnage to the pipeline as you kind of design the level in tiles, export then draw a collision mask after?

Not really out of the box stuff, dynamic areas wold either need some pixel manipulation of the mask or define the rules for the dynamic areas so that they work out of the box (i.e square collisions - bridges/doors) etc.

To make it easy the current box2d support creates polygons based on the collision map tiles. Its pretty easy to create your own collision polygons and as you already know what part of the graphical tile you want as a wall you can generate them automaticaly. When i started with box2d i wanted to trace the slope tiles , here is my rough attempt http://impactjs.com/forums/code/box2d-collision-polygons-for-new-slope-tiles but is does show how the collision polys are created.

Actually, a pixel check is not really on the cards, I'm looking at iOSImpact which doesn't allow for that, which means maintaining the pixel array manually (because we don't have the convenience of using another canvas) - and we're talking a HUGE array.

The levels I'm thinking of are in the 80x80 sort of range, with 24x24 pixels per tile. So 80x80x24x24 = 3MB of RAM even if we're talking one byte per pixel (multiply that by 6 because of how JavaScript handles numbers and add some overhead because of the arrays themselves, and you realise we're talking 20-odd MB of memory just to deal with that array.

Thing is, it's not even that efficient on a desktop, we just don't realise its effect on a desktop. But it is quite significant, really.

Things like doors are actually quite easy, they're doable via fixed-collision entities.


Also, @Stuart, interesting - my knowledge of Box2D is honestly limited, but I thought it worked by collapsing collections of tiles into polygons for performance, and I'd end up rewriting some of that on the fly, which doesn't fill me with joy - especially as I will be working with conventional entities as well.

Certainly there's a lot of food for thought here, and I think I'm going to need to experiment with it to see what I end up with...

Yes that is exactly what the standard box2d demo does but even when I added all the slopes as seperate polygons it did not seem to impact the performance that much. As I said before I created a collision map using a smaller tile size 8x8 and a graphical tile size of 24 x 24 simply so that i could address the centre parts of the 24 x24 tiles as collision areas. This way I was able to use the standard box2d polygon code or without box2d!. Good luck, please let us know how you solve it.

So I worked on this some last night; I was able to create a map of the custom collision tiles I need but as I discovered later, I was hitting a limit in the innards of Box2D (that seemingly isn't documented anywhere)

This morning I started plotting an interesting way to solve this - basically take the same approach that Dominic did with Box2D normally: I need to traverse the map and look for continuous lines both vertically and horizontally and build single Box2D shapes out of them.

(I note, I did actually create even the simple horizontal walls as polys, made the whole code simpler to read, heh)

So I did some experiments, the first map I threw at it required some 1470 wall tiles, but with condensing the long walls into combined objects I still managed to create 407 objects, and performance was less than stellar. And since that was just walls, without even getting into things like collectible objects, I think I need to rethink my approach.

I am not sure if the current ported version of box2D supports Chain Shapes but if it does that may be another option. If I get chance later I will take a look.
http://www.box2d.org/manual.html#_Toc258082973

Hmm, interesting but it looks like it would possibly still be subject to the maxProxies limit from what I can tell of the architecture without unravelling it entirely (I'm still annoyed that I had to go digging into the internals to discover this limit of objects, the sole documentation merely mentions the constant, doesn't say what it actually does)

What annoys me most of all about this is where I'm essentially trying to clone a 1989 game that did all this perfectly on machines with less than 1% of the typical processing power of a mobile phone and am running into limits of systems upon systems upon systems.

I think I'm just going to go back to detecting where the player is and manually dealing with where the player's trying to go, seems to me that it'll be less of what feels like trying to put a square peg into a round hole :/

Out of interest can I ask what game you are trying to clone.

Rock 'n Roll - http://www.mobygames.com/game/rock-n-roll

It's a tile-based roll-a-ball-around-a-maze but with much more intricate mazes. You can view the mazes in the core game at http://hol.abime.net/1266/gamemap if you're curious to see how complex things are, and if I could get the core engine up to handling any of those, I could just allow myself to go nuts and create all sorts of crazy levels without having to juggle whether the engine can cope or not.

(Of course, I'd change the graphics and levels before a release, but mechanically the game's very straightforward, and I haven't seen anything quite like it since.)

(You've tried a lot of things and this may be one of them)

I just looked at your gamemap link and first instinct concerning the (thin) walls was: box2d static bodies; forget the collision map.

Now to limit the number of b2bodies and entities, and understanding that you want to build the levels in WM, I&039;d first draw the walls on the bg map, then, in the Entities level, I'd trace over said wall tiles using wall proxy entities (EntityProxy extends ig.Entity, #_wmScalable, _wmDrawbox, with a custom WM-only draw, and an empty update method). At game load time, I'd fetch the proxies, build static bodies of same position and dimensions, and would then kill the proxies.

I hope this helps.

I remember playing that game when it came out..great idea to bring it back with tilt support.
Anyway I had a little spare time on the train this morning and after looking at your links I had a play around. I created a 240 x 240 collision map 8x8 tiles (btw you need to do this first in Weltmeister) and then a 80 x 80 base maze map 24x24 tiles for the ball maze. I could have created smaller tiles for the ball maze but i wanted to make it faster to layout. Heres a link to the sample I created http://www.spritesheet.net/democode/impactballmaze.zip its just the media / level,entity and main files so just add it to a fresh impact download.With the new zoom support it takes minutes to layout the collision over the maze design. I must be honest I have not created many mobile games ...yet so I have no idea what size of map can be supported.

Forgot to say, depending on the radius of the corners and the ball you may be able to miss out some of the collision tiles in the corners.

I did actually come to the same conclusion about the collision tiles in the corners, though if I'm entirely honest I was hoping to avoid manually creating the collision layer and doing it programmatically.

Thanks for the sample, it's certainly something to experiment with :)

I was going to create the blue maze 8x8 tiles as a separate tile set which would allow for automatic creation of the collision layer in the editor but placing a minimum of 3 tiles for each maze part seemed a lot more work that having the 24x24 set I produced which has all the possible maze parts and placing a single collision layer tile over the relevant areas.

I have created the collision map dynamically in the past which I am sure you have done to. Last time I did this I actually stored the sub collision tile data in the level collision map, for example based on the demo tiles the first 3x3 block of collision tiles would be all blank then the next 3x3 block would hold the data for the horizontal maze piece etc.(the order of the sub collision map data matched the order of the tile palette data) This may be a little overkill for the amount of tiles you need but it did allow me to easily include one way tiles etc in more complex sub collision maps. I would then read the sub collision data in from the collision map and assign to arrays and then using these arrays against a selected Map layer I automatically built the real level collision map. I may have the code floating about some place if it’s any use.

OK, so I finally found some time to work on this again.

What I did in the end was translate the 80x80 map to a 240x240 collision map and use the modified code you posted in the other thread to handle the sloped tiles (thank you very much!)

The big difference this time around is that instead of trying to handle everything as discrete tiles, Dominic's code in the Box2D plugin takes the massive lines of walls and creates one object out of them; I haven't done any testing on it but I was able to get the first level sorted out without hitting the 512 object limit.

And this way I get the ball treated as a ball, thanks for all your help!