Best way to determine "walkable" tiles?

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Best way to determine "walkable" tiles?

(9 posts) (3 voices)

Started 2 years ago by exorcyze
Latest reply from mhussa

Tags:

exorcyze
Member

I'm working on a tile-based game and really enjoying using Cocos2d. I have been using the support for TMXTileMaps and have things loading and displaying fine. However now I'm trying to implement "walkable" tiles. Currently in my map I have a single tileset that I can use for a given map, and then a second tileset that consists of 3 tiles - blank, "x" and solid. These indicate walkable, landable ( like a cloud style platform for instance ) and non-walkable.

I use the second tileset because many times there isn't a direct connection between a tile being present from the base tileset and whether or not it's walkable. And trying to break those up between multiple layers obviously isn't very ideal either, since it makes drawing the map more difficult.

So now the problem : By default, cocos2d does not add layers into the hash that aren't visible. This means I can't have a "walkables" layer with the special characters to indicate platforms and base that I can reference via getTileGidAt:. What would you guys recommend as the best / cleanest solution to this?

Thanks!

Posted 2 years ago #
bradparks
Member
You could just keep the "walkable" layer visible in Tiled, and in code, find the layer and turn it invisible after you've loaded your map....

e.g
```
TMXLayer *walkable = [map layerNamed:@"walkable"];
walkable.visible = NO;
```
But the best way would probably be to use the "Object Layer" feature of Tiled, that this post:

http://www.cocos2d-iphone.org/forum/topic/2874

is starting to implement as a feature... But it only works well with the QT version of Tiled that's available on the Tiled downloads page.... For the time being, the above layer.visible = NO approach should work fine....
Posted 2 years ago #
exorcyze
Member

Thanks Brad - I had thought about that. I wasn't sure if there would be any potential performance side effects, though I guess OpenGL shouldn't be spending any clock cycles rendering an invisible layer.

I had also been watching the other topic on object layers with great interest, as it would really be ideal to be able to visually place spawn points and other trigger mechanisms through that. I hadn't thought it would be the best way to approach the walkables though - I guess semantically it seemed to not quite mesh.

Thanks again for the feedback. It looks like that will my best option until / unless it's implemented directly in TMXTiledMap. The change would be fairly minor and I'd have no problem contributing it back if there were no objection? Riq, any reason we couldn't do this that you can think of?

Posted 2 years ago #

exorcyze
Member

I tested out editing TMXTiledMap initWithTMXFile ( starting at line 467 ) to be the following :

for( TMXLayerInfo *layerInfo in mapInfo.layers ) {

	id child = [self parseLayer:layerInfo map:mapInfo];
	[child setVisible:layerInfo.visible];
	[self addChild:child z:idx tag:idx];

	// update content size with the max size
	CGSize childSize = [child contentSize];
	CGSize currentSize = [self contentSize];
	currentSize.width = MAX( currentSize.width, childSize.width );
	currentSize.height = MAX( currentSize.height, childSize.height );
	[self setContentSize:currentSize];

	idx++;
}

It worked fantastically. Now I can have a clean layer-supported method of having walkable tiles. =)

Posted 2 years ago #

mhussa
Member

TMXLayers are a subclass of the AtlasSpriteManager, creating these objects for invisible layers to use as game data is not ideal. It may work but there's a load of extra guff which is sitting around it that won't be used. I seem to remember some posts recently mentioning minimising the use of AtlasSpriteManager objects for performance.

The data for invisible layers should really be stored and accessed as arrays. I've taken an alternative route and that was to parse the XML map data in ruby and create a data file which I get my game code to read. Longer workflow but was quicker than re-writing the TMX stuff.

TMX support as it stands is a very good starting point but the current design focuses on visible elements. I think it needs refactoring in the following areas:

1) Performance - only rendering on-screen tiles.
2) Game data access - tiled properties (layer+objects) and access to layer tile data used as game data.

If I get desperate I might add it but at moment I'm using "workarounds".

Posted 2 years ago #
exorcyze
Member

mhussa - Thanks for the input. That would've been my fear is the impact on performance. I'm running fairly small maps and didn't notice any change in the FPS using the method above, so I was under the impression that OpenGL would not spend time rendering a layer that wasn't visible. That said, I'm not 100% sure either way to be honest - it's just speculation at this point with limited data to feed it.

I highly agree that it would be ideal to be able to access layer data for invisible layers as just pure data, but I didn't see an easy way to do that in the current code base. Perhaps if I can get some time I can look at running more tests against larger maps, towards the size of 200x200 to really see if there's a significant performance drop. Of course there would also be the question of the effect on memory consumption using this method too.

=)

Posted 2 years ago #
bradparks
Member

I'm sure it takes up some resources to use an invisible layer... but for what it's worth, on a past discussion of TMX and large maps:

http://www.cocos2d-iphone.org/forum/topic/2609#post-16223

riq said that only visible layers are rendered to the display, and that tiles(AtlasSprite) are only created "on demand", so I don't think it'd be too big a hit... regardless, you could implement it this way, and if you see performance problems later on, or if the object layer support gets completed, you could switch pretty easily to a different approach if you just wrap how you determine "iswalkable"...

Posted 2 years ago #
exorcyze
Member

Riq - Any thoughts on this? Is it a change that should be made to the code-base? Or is there another way you could think of that may work better?

If the above sample is OK with you, I would be fine with submitting it into the code-base. I haven't looked into guidelines for that on the project, but I'm guessing you have them setup somewhere on the site. =)

Posted 2 years ago #
mhussa
Member

I've had a look at the map code and discovered it's already processing the non-visible (invisible?) data into the TMXMapInfo class. The XML parser unzips the invisible data but then later when the TMXTiledMap is instantiated it's ignored. I think it needs some access hooks to get the data. I'm not sure about the lifetime of the instance data but looks like a good place to access what you need without having to create visible map layers (which aren't really visible?).

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.