Ninja Tilemap question

[mtburdon]

Hi all,

 

I'm looking into Ninja physics and specifically the tilemap example.

 

I'm curious as to how the points on the map are defined, I'm assuming it's with the following line

var slopeMap = { '32': 1, '77': 1, '95': 2, '36': 3, '137': 3, '140': 2 };

However there's no description as to where these numbers come from, are they generated/set using Tiled and if so how should I be going about this.

 

Also, is it possible to detect when the ball in the above example hits part of the map/tiles?

 

What I'm wanting to do is create a game where the player is a rocket going left to right inside a cave which would be a pointy map/land above and below the player, would this be the best route for implementing such a game.

 

Thanks,

Martin

[lewster32]

I don't know a great deal about Ninja but I do know that it basically has a load of predefined shapes for tiles (slopes of varying angles etc) and that you assemble these like lego into your map. It's designed rather specifically for platform games to handle the kind of smooth 'ramps and curves' collision you used to get in games like Sonic the Hedgehog, as opposed to Arcade's rigid reliance on non-rotated rectangles, but the shapes are specific and not arbitrary like you'll probably want.

 

I'd say for your rocket game you should decide if you absolutely need arbitrary collision shapes: if you do, use P2 or create your own method for collision detection; if not, use Arcade. I don't think Ninja will do the job particularly well. Interestingly before Phaser reached version 2 there was a way to define arbitrary shapes on sprite bodies for collision detection, but it was somewhat buggy and I'm pretty sure it was dropped, as I've not seen it mentioned since.

[mtburdon]

Thanks for your reply lewster32,

 

Sounds as if P2 would be the way to go then. One concern would be that I'm looking to make this a mobile game but Rich mentioned that P2 seemed to struggle a little on mobile in this post. Would this be much of an issue from your experience (or anyone else looking in at this post)?

 

Looking at P2 as the way forward, this seems a good example of sprites with non-square objects and collision detection. I notice in the code example it loads the 'polygon data' into the objects which I imagine is setting the objects boundaries, can this be done through Tiled as I'd be looking to create each cave/level using it?

 

Thanks for your help and insight, I'm relatively new to this!

[lewster32]

I think P2 used sparingly will work on mobile - it was chosen largely for its speed. So long as you're not going wild with it and trying to simulate many colliding objects I don't see you running into any serious problems with it on its own.

 

From my limited knowledge of Tiled, I believe Phaser has its own way of checking for collision against tiles which is separate from the physics engines sprites can use - but I may be wrong. If indeed you are creating your maps via Tiled then it seems to make sense that you'd be creating a relatively 'blocky' map anyway, in which case I don't see that there'd be a need for polygonal collision hulls - correct me if I'm assuming too much here?

[mtburdon]

You're right, I can make do with Arcade physics here and use a tile size of 16px.

 

Cheers mate

[lewster32]

No problem *waves towards the A19*

[clark]

Lets say you place 100 collision tiles with the given mask shapes. Lets say Tiled Editor.... Should all those shapes be placed on a single collision layer? And also, what is the relation to performance? 100 collision tiles is slower than 2 collision tiles? Or is the whole set of tiles turned into one big "thing" back in Phaser?

I have never approached a tiled game, so was just curious as to how it worked

[lewster32]

I don't know the specifics but I believe TileMap layers detect collision in a specific way which makes them much more optimised. I've heard people mention that it treats contiguous tiles as a single surface but I don't know for certain if it works that way or not. It seems either way to be very fast even with lots of tiles; what it struggles with seems to be multiple layers, suggesting that rendering and fill-rate is way more of a bottleneck than collision detection.