A fast, easy to use, free, and community supported 2D game engine
Ha-ha, old-good propertiesForTileSetNamed: =)
It was the hardest part to understand, what this stuff is doing! ;)
I thought my "like SQL primary key" was good enough.
If anyone could provide a better comment for this method - feel free to drop me a line.
Thanks!
Yep, I haven't looked at that stuff in months, I had forgotten just how confusing it really was. =) It makes total sense once you know how it's setting up the automatic GIDs, but that's all hidden from the casual user. I'll have to think about that, maybe rename that function so that it makes more sense from the delegate owner's context...
rakkarage
Member
the gid is just an index into the tileset?
...
kTileSetTypeKey, kTileSetTypeNameKey and tile id all set to 0? u need all 3 0 values?
kTileSetTypeKey, kTileSetTypeNameKey and tile id all set to 1? u need all 3 1 values?
...
i have to set both properties to the gid i want to show?
ya sorry i am just so lost
thanks for all the help and the code
rakkarage
Member
https://github.com/rakkarage/cocos2d-iphone-extensions/commit/b050b3a096ea588741e7f9839395169ce1672d9b
maybe we can make the test use a meta layer like in the comments and in rays code?
i have tried to start it there following the meta comments
but i am stuck what to return for tileIdentificationKeyForLayer
edit:
https://github.com/rakkarage/cocos2d-iphone-extensions/commits/develop
so it writes a good tmx that displays fine (all layers) in the tiled editor
but it does not display right in TMXGeneratorTest in simulator for me... am i doing something wrong? (obviously :)
thanks again :)
what do i need to set these properties to in this case?
The GID is the TMX internal number that maps a tile atlas position to the sprite it draws. It's somewhat arbitrary, but does need to be "right" to map the tile atlases with what's drawn on the screen. a GID of 0 will draw nothing. If you are using multiple atlases then each atlas has a "starting" GID and then does math to determine it's tile GIDS from there. If that makes sense.
I'll see if I can add a meta layer late this evening to the example. To try and keep things non-confusing use the example's default value for tileIdentificationKeyForLayer in all cases. Essentially you are defining a constant in that method, with the option to "group" tiles using multiple constants -- this extra grouping is totally optional.
Stepping into the TMXGenerator code and watching exactly what it's doing will be more instructive than anything I can tell you here, short of giving you an example. If you can't wait I'd go that route until I can get you a better example. Hope that helps some.
It's always looks fantastic, when community work on something together.
@slycrel, @rakkarage
Thank you so much for doing this and spending your time to share your achievements.
Community rocks! <3
BTW, @rakkarage fixed another little typo in TMXGenerator.m: https://github.com/rakkarage/cocos2d-iphone-extensions/commit/3f8e9b9eef3063e1e76d082dab87a705ff956c50
I'm using GitHub network tab to monitor your commits guys. Don't forget to push & keep up the good work!
Cheers! ;)
rakkarage
Member
i tried leaving the optional grouping as the default and it produces a good map (in Tiled) but it draws (the invisible tiles?) funny
if i dont use the second tileset (or if i change anything else it seems) then the map draws good but the file gets messed up (no Meta layer in it)
and ya i am exploring the code and github (ya network is kool) and trying to understand TMXGenerator and everything but since the map looks fine in Tiled and just draws weird i figure i may be looking in the wrong place....
thanks everyone
For anyone interested, I've updated the TMX Generator Test in my fork of the extensions repo. I've added a number of things including a meta layer, new atlas for the meta layer, changed the properties to make more sense, added a moveable player (for meta layer testing) that spawns based on the spawn object. Also added some basic collision detection using the meta layer and some sounds for fun. (check out the SFXR/CFXR sound generator it's pretty cool)
You can get my changes right here. As always, feedback/usability testing is appreciated. =)
Blue Ether
Member
I've been poking through this. First, before I launch into a gripe fest that may come off as mean (but is not intended to be) let me say that this is a GREAT class (after making a few modifications). nice and lightweight. Works really well and makes it a pretty simple matter to plug whatever data I want into a TMX format and have Cocos2D load it up the same way it would any other map.
I definitely wish that CCTMXTiledMaps accepted XML strings in addition to TMX file names. I may need to make certain "modifications" to that class (shouldn't be that hard). Since I'm mainly interested in using this class for procedural generation and not user content generation, I don't really see the need for saving the result in user documents. I would rather have something to just generate an XML String and give me that. ;-)
ANYWAY, I have to grip a bit about the confusion here with regard to the "tileset properties."
First let me wal you through my unfolding perspective on the matter:
You made "propertiesForTileSetNamed" an OPTIONAL delegate method, but if that method isn't defined generateTMX returns an error. At first I thought that you forgot to add scope there so that the "if properties nil" check only occurs if the delegate responds to the selector. However it seems that the real issue is that this method should NOT be optional, because if it is omitted the map won't generate any layer GIDs other than 0. But on further inspection, the tileset properties code seems like it SHOULD be optional because it makes the entire process of determining GID a lot more complicated than it needs to be.
So I'm wondering to myself: why isn't there any way for this class to simply reference tiles in tilesets by their GIDs? I mean, as per your example, I'm creating a data array of GID values, which are all numbers. Why not just, I don't know, store that GID number directly, using the starting GID for the tileset, like how Tiled does it? Why does that number have to be squeezed through the grinder of a property dictionary? I mean, the tile property is part of Tiled, but it's an option, and it doesn't really work as you've using it here. This class makes it a requirement? The creation of a whole Dictionary with a key/value pair for every tile seems completely unnecessary. Is there something I'm missing here or maybe not understanding correctly?
Anyway, here's my simple gripe fixes:
NSString* tempStr = [self tileIDFromTileSet:tileSetForLayer thatMatchesKey:tileKeyVal property:tilePropertyVal];
if (tempStr)
GID += [tempStr intValue];
else
GID = [tilePropertyVal intValue];On the last line, I've replaced "0" with the intValue of the string that was returned by tilePropertyForLayer. If it was a string, then that value will be 0, so no difference. If, like me (and your example) you're returning a tileset index, then that works a-ok. However, the better solution would be to have a "tileGIDForLayer" method that returns the gid, and then maybe a SEPARATE "tilePropertyForGID" method which looks up any properties you want associated with a particular GID? That really only needs to be done once for the whole map though, not once per tile. I still don't understand what you're trying to accomplish with "properties" vs GIDs. I figure it must be some project-specific need that's not really in line with the TMX paradigm.
and also:
if ([delegate_ respondsToSelector:@selector(propertiesForTileSetNamed:)])
{
properties = [delegate_ propertiesForTileSetNamed:key];
if (!properties)
{
if (error)
*error = [[NSError alloc] initWithDomain:[NSString stringWithFormat:@"Unable to get properties from tileset name %@ when calling delegate method propertiesForTileSetNamed:", key] code:0 userInfo:nil];
return NO;
}
}Added brackets around the !properties check. Since the "propertiesForTileSetNamed" method is going to be optional, the !properties check would always pass and generate an error if the method wasn't defined. Which means, well, its not really optional heh. I happen to think that the dictionary generated by this method is completely superfluous, so I lean toward keeping the method optional of course.
My only remaining issue is that the asset copying code doesn't support tileset images in subdirectories. I keep my graphics in a subdirectories so they don't mix in with my maps. But, the way the file copying is set up it fails if the file being copied is in a subdirectory, because the subdirectory is in the file name and thats a nono. A fairly simple fix, but I'm not familiar enough with NSFileManager to work it out right now.
Still, this thing is a pretty solid foundation and I like it. I just want to see it grow into something better ;-)
Hi Blue Ether,
Thanks a ton for the feedback. I'm glad you're finding a use for the class -- That's the goal. I'll save some of the finer points of implementation detail discussion for when I'm more stable. (It's REALLY late here and I'm running on lack of sleep among other things...) However, I'm hoping that I can help you understand better why I chose to implement the GID's the way I did.
As part of that let me give you a little perspective on where this thing came from. When I wrote this (and as far as I know) there was and is nothing else out there like it, at least publicly released. I was very proud of it and wanted to post it to help people out. I did... and got no response. Hrm. So I kept on going and made it better. Posted the updated class again a couple months later, this time with way more functionality. Araker was kind enough to post that it would come in handy later, but other than that no response. 3 months after that (after it's old news for me, and as far as I knew only used for my own project) I get a request to clean it up a bit and submit it to the extensions project. I'm honored, but it's still old hat for me and not particularly under development for me -- I'm using it for my project and assumed nobody cares. I cleaned up a few things and posted it, creating the example along the way. It's a good idea, but I never billed it as production ready -- it's a solid beta if anything. So please take it as such. =)
My project generates 32x32 tile "chunks" of a larger world map, so I needed it to save these persistently. I also attempted to make this in-memory only the first go around and failed miserably on that front, so I backed up and wrote essentially a TMX file creator rather than an entire TMX creation system in memory. (Now that I've done this class I think I might have a better shot at the in-memory option and as mentioned above we will probably head that direction.) While I'm thinking about it, the atlas copying came about because I couldn't get the paths in the TMX file to work properly, so I cheated and had it copy the atlas wherever you wrote the map file. That's definitely an area that can and should be improved.
There's no specific reason that we can't give back an XML string instead of writing a file. However, (and I could be wrong!) to my knowledge there is no easy way in cocos2d right now to turn an XML string into a CCTMXTiledMap. You may have a way to do this (or know something I don't), but ultimately that was why I went with the file -- I'd have to do a lot of other code modification to get the base cocos2d to use something created in-memory. Yeah, I know I could hack some stuff in to do that... but I preferred not to. This is a side hobby not my main job, I wanted to stick with the mainline cocos2d as much as possible. It shouldn't be hard at all to add an XML return instead of a file written, let me know and I can look into that. =)
Anyhow, back to your core concern. This class is a class that generates TMX maps. GIDs, while accessible and available to cocos2d, are an "implementation detail" of TMX maps. You don't define GIDs in Tiled. They get defined when you save the map. So the catch 22 is, if you're generating the map with GIDs... you don't have them yet. Further, even if we were to customize those at the delegate level, you (as a delegate), have to know what a GID is, how they work in relation to the TMX map, and how they interact with atlases. I chose to keep those lower level and tie tile properties to specific tiles instead. Yep, it is not the most optimal... but using properties can cut out a lot of complexity regarding knowledge of GIDs and the TMX format in general. It can (apparently, heh) add a bunch of complexity on it's own. That said, I'm not convinced that I did a great job. It's usable, but there's plenty of room for improvement there, it is a bit clunky still. I'm not sad about the current property system, but I'm not thrilled either. As you can see above, it's not as user friendly as I'd hoped it would be. It should be easier to use and make more sense.
And you're right, there are holes in the code. Again, please treat this as beta, not some grand scheme I'm unleashing on the world. I know I have the bias of my project and have tried to keep that out as much as possible, even before any feedback. And the class is still young, it has plenty of growing to do. =) I'm kind of going the route of trying to make it work first and then optimizing it as needed.
You might be right though, it is possible to put the GIDs in the user's hands. In your case it sounds like that's a good idea, you already know what you're doing. I'm not yet convinced that that would be a good thing overall for the class, that forcing the delegate to handle GIDs would cover all of the cases needed to make TMX maps. But I'll revisit this and look at the code with GIDs specifically in mind and understand more fully what you're saying.
Oh, and THANK YOU for taking the time to post about this. I very much appreciate it! I haven't gotten enough feedback (good or bad)! And I'm taking your comments as constructive criticism. Don't let me know if they're more than that. :D
Slycrel, thanks a lot for your work.
I tried your changes and looks like there's problem in calculating GID in TMXGeneratorTestLayer#tileCoordForPosition:
It crashes in CCTMXLayer#tileGIDAt:
TMXGenerator Test[39806:c503] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'TMXLayer: invalid position'
*** Call stack at first throw:
(
0 CoreFoundation 0x0144a5a9 __exceptionPreprocess + 185
1 libobjc.A.dylib 0x0159e313 objc_exception_throw + 44
2 CoreFoundation 0x01402ef8 +[NSException raise:format:arguments:] + 136
3 Foundation 0x004dd3bb -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
4 TMXGenerator Test 0x00088704 -[CCTMXLayer tileGIDAt:] + 292
5 TMXGenerator Test 0x0000bb94 -[TMXGeneratorTestLayer collisionTypeForTile:forLayerNamed:] + 260
6 TMXGenerator Test 0x0000bcab -[TMXGeneratorTestLayer movePlayerPosition:] + 107
7 TMXGenerator Test 0x0000c9a2 -[TMXGeneratorTestLayer ccTouchEnded:withEvent:] + 2818
8 TMXGenerator Test 0x0009d761 -[CCTouchDispatcher touches:withEvent:withTouchType:] + 1633
9 TMXGenerator Test 0x0009e2af -[CCTouchDispatcher touchesEnded:withEvent:] + 111
10 TMXGenerator Test 0x000a0161 -[EAGLView touchesEnded:withEvent:] + 113
11 UIKit 0x00883ded -[UIWindow _sendTouchesForEvent:] + 567
12 UIKit 0x00864c37 -[UIApplication sendEvent:] + 447
13 UIKit 0x00869f2e _UIApplicationHandleEvent + 7576
14 GraphicsServices 0x02978992 PurpleEventCallback + 1550
15 CoreFoundation 0x0142b944 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
16 CoreFoundation 0x0138bcf7 __CFRunLoopDoSource1 + 215
17 CoreFoundation 0x01388f83 __CFRunLoopRun + 979
18 CoreFoundation 0x01388840 CFRunLoopRunSpecific + 208
19 CoreFoundation 0x01388761 CFRunLoopRunInMode + 97
20 GraphicsServices 0x029771c4 GSEventRunModal + 217
21 GraphicsServices 0x02977289 GSEventRun + 115
22 UIKit 0x0086dc93 UIApplicationMain + 1160
23 TMXGenerator Test 0x00002f04 main + 100
24 TMXGenerator Test 0x00002165 start + 53
)
terminate called throwing an exceptionThanks Stepan, I'll have a look. I did a bunch of testing on my iPhone 4 and in the iPad 4.3 simulator (in Xcode 4.2 beta), I'll see if I can reproduce that crash. It looks like it's hitting the "out of bounds" assert if I had to guess. Might have something to do with my width modifier I added in the middle of testing.
edit: @Stepan, I can't seem to make this problem happen. What are you doing to get this to happen?
@blue ether: I've been thinking about the overall paradigm some and overall we might be able to both simplify this and give direct access to GIDs.
By the way, I glanced through the code and you're 100% right -- we're making the properties optional and they really are not. Both because we're generating an error when they don't exist as well as you do get a blank TMX map if they aren't right. The latter could be argued for a case of wanting to set up only the atlases at creation and assigning GIDs later, but the former is definitely wrong.
Anyhow, been thinking that maybe to go along with the array motif the delegate has going, we could have a starting GID in the atlas properties. Then we could do the math and if there are no "overlapping" numbers between tilesets then it would work. This isn't future-proof, but likely to work for the foreseeable future. I'll see if I can work on this some this week to get a solution.
We do need to be careful about GIDs though. For example, the new tile flipping feature actually uses the first two bits in the GID to determine if they are flipped horizontally or vertically, which will change the GID numbers. For now I'm going to treat those as separate fields and add those in at save time (if flipping is used). But that could throw a big wrench in all of this GID specific stuff. Thoughts?
Blue Ether
Member
I'm definitely not as familiar with the intentions you have behind the tile properties. I've tried to understand it in your posts, however to me it still seems like an unnecessary layer of abstraction. I can see your point about trying to abstract out the gids, but ultimately Tiled needs to know what the GIDs are and the ultimately the user needs to code those GIDs in somewhere. In your example, the tile properties dictionary seems to map the gids to the gids. You plug in one gid and you get out another gid. The creation of a dictionary to do that seems like make-work to me. At the very least, I think it should be possible to use the TMXGenerator at a bare-bones level using gids.
I can see your point with regard to the flipping, but again I'm not sure the properties dictionary is the right answer. I would need to think more about that one though.
As for creating a TMX map from a string instead of a file, it's a fairly trivial change but yes it does involve making alterations to CCTMXTileMap and CCTMXXMLParser. The change is pretty straightforward, I've already made it locally. Basically just need to add some convenience methods. CCTMXXMLParser just does this:
NSURL *url = [NSURL fileURLWithPath:[CCFileUtils fullPathFromRelativePath:tmxFile] ];
NSData *data = [NSData dataWithContentsOfURL:url];making an NSData from the string inside a file. If you pass the string itself, all you need to do is this:
NSData *data = [tmxString dataUsingEncoding:NSUTF8StringEncoding];and viola, CCTMXXMLParser can parse the string the same way it would the file. The only tricky part was with regard to the parsing of external tilesets where it uses the file name to determine what subdirectory to look in. For a string-passed Tiled file, I had to assume that no subdirectory would be used. Ideally I suppose the method would take an optional "directory" parameter but it seemed like an unnecessary complication to me.
Also, I had to make another addition to TMXGenerator as I was working with it this morning. It doesn't support map-level properties, which I use for, among other things, identifying the map name. Easy enough, as your "propertiesAsXML" method does the trick, but of course an extra delegate method needed to be added as well as a parameter for the writeTMXFileWithName method.
+ (void) writeTMXFileWithName:(NSString*)filePath mapAttributes:(NSDictionary*)mapAttributes properties:(NSDictionary*)properties tilesets:(NSDictionary*)inTileSets layers:(NSArray*)inLayers objectGroups:(NSArray*)inObjectGroups
{
...
[outStr appendString:[TMXGenerator propertiesToXML:properties]];
...
}in the delegate protocol definition:
@optional
- (NSDictionary*) mapProperties;and in generateTMXMap
...
NSDictionary *properties = nil;
if([delegate_ respondsToSelector:@selector(mapProperties)])
properties = [delegate_ mapProperties];
// create the TMX file on disk.
NSString* mapPath = [delegate_ mapFilePath];
[TMXGenerator writeTMXFileWithName:mapPath
mapAttributes:mapInfo
properties:properties
tilesets:tileSets
layers:layers
objectGroups:objectGroups];
Blue Ether
Member
I forgot to go into my reasons behind the "TMX from string" thing. If you're using a seedable random number generator such as SMFT (which I highly recommend), then all you need to do is store what random seed was used to generate a given map, and you can re-generate the identical map from scratch every time without needing to save anything locally. Particularly if you're planning to support multiple user files and having a number of maps, it seems more optimal to me that they not be stored locally.
But I have to admit: I have already discovered that saving the files makes development and debugging much easier, as all I need to do is browse to the Application Data folder for the simulator and the maps produced can be loaded up and examined in Tiled. Which is really great. So for now, I've decided not to use the strings, keep the files, but instead pre-pend the save file ID to each generated map. I will probably re-address using strings at a later date.
@blue ether: Yes, in some ways the property thing is an extra abstraction, but an important one. As far as tiled is concerned, GIDs are atlas-specific IDs that are unique for the scope of the map, across all atlases. We can make this work using GIDs. Tiled for example never tells you that GIDs exist. They are a method of making the format work -- they aren't really a feature. Tiled's format changing GIDs to also store flipping data reinforces this -- it's uniqueness data as far as tiled is concerned, a way of identifying tiles on a specific atlas.
We don't have control of how these will be used in the future. I'd hate to write this class with a dependency that can (and as has just happened in july, did) change at any time. Instead I've used the properties for the coder to specify which tiles map to what and when they do so, independently of how the tiled format works. Still thinking though, I've not ruled out a GID involved change yet.
Thanks for the changes to add the map properties! That was initially on my list but hasn't ever been added. I am going to modify your code a little, and add the map properties as a sub-dictionary of the mapAttributes dictionary. I hope that works out ok with you. It seems a little cleaner to me that way, as the mapAttributes are the go-to place for everything at the map level. Here are the relevant code changes in the .h:
#define kTMXGeneratorHeaderInfoMapProperties @"mapProperties"and in the .m:
+ (void) writeTMXFileWithName:(NSString*)filePath mapAttributes:(NSDictionary*)mapAttributes tilesets:(NSDictionary*)inTileSets layers:(NSArray*)inLayers objectGroups:(NSArray*)inObjectGroups
{
...
// map properties
NSDictionary* properties = [mapAttributes objectForKey:kTMXGeneratorHeaderInfoMapProperties];
if (properties)
[outStr appendString:[TMXGenerator propertiesToXML:properties]];
...
}I also refactored the "mapSetupInfo" delegate to be named "mapAttributeSetup" to help clarify this a bit.
I understand the draw in creating TMX maps as a string. I'm happy to add that, it was fairly simple to do, I'll see if I can commit that tonight. I too initially wanted a memory-only map. Then I started messing with the maps in tiled and... it was very nice, especially for debugging this generator. I think both have their merits, so we should support both.
As far as the random number generator... I've been using arc4Random() and height maps, it would be nice to be able to re-generate landscape based on a seed. Thanks for the tip, I'll have a look at that.
rakkarage
Member
i have a couple tmx tilesets and want to replace a tile with setTileGID... how can i calculate the gid with the 'kOutdoorTileGrass' index i used to to setup the tile? i can do some math with CCTMXLayer._firstGid or something? but _firstGid is not even public? easy enough to add an accessor tho
i got a door working by checking and modifying the generation data and then incrementing or decrementing the gid but i think there is a better way?
thanks a lot
You will want to look at your propertiesForTileSetNamed: method. Within that method you should have properties associated with each atlas tile that you can use to find what you are looking for. I set up my properties with an enumeration (I think you have done something similar with your kOutdoorTileGrass define) and use that value for my properties. So, as an example from my project in propertiesForTileSetNamed:
- (NSDictionary*) propertiesForTileSetNamed:(NSString*)name
{
NSMutableDictionary* retVal = [NSMutableDictionary dictionaryWithCapacity:50];
NSMutableDictionary* dict;
// These properties map to the given atlas tile.
if ([name isEqualToString:kOutdoorTileSetName])
{
// atlas setup
// tile 0
dict = [NSMutableDictionary dictionaryWithCapacity:10];
[dict setObject:[NSString stringWithFormat:@"%i", tileBasePlains] forKey:kTileSetTypeKey];
[dict setObject:[self typeNameForType:tileBasePlains] forKey:kTileSetTypeNameKey];
[retVal setObject:dict forKey:@"0"];
// tile 1
dict = [NSMutableDictionary dictionaryWithCapacity:10];
[dict setObject:[NSString stringWithFormat:@"%i", tileBaseSand] forKey:kTileSetTypeKey];
[dict setObject:[self typeNameForType:tileBaseSand] forKey:kTileSetTypeNameKey];
[retVal setObject:dict forKey:@"1"];
...
}
}This is kind of what I was discussing with blue ether.... You can use this property setup to find the GID for any given tile by looping through the property array (of dictionaries) for a given tileset. Once you find the matching property for the tile you're looking for you can get the tile ID number, which tells you what atlas tile you are looking at. The tileset knows what it's first GID is, so you can take the first GID and add which atlas tile it is to get your GID.
I wish this was built in better, but short of micro-managing the GIDs there isn't any way to get this to happen. Revisiting this thought after a few months I'm remembering the (good) point that blue ether brought up, in that it seems a bit overly complex to do this way. It might be better to force management of the GIDs and have the generator do some bounds checking at generation and fail if it's not right. Right now the advantage is you'll alway sget a valid map, but have to jump through these hoops to get your GIDs back out. Writing a method to do this shouldn't be too difficult, let me know if you run into problems here and I can help more.
For anyone curious and following along, cocos2d 1.1 (and I assume 2.0 though I haven't checked) will have the in-memory only map generation added as part of CCTMXTiledMap. Additionally I can very much recommend looking at SFMT for random number generation. Technically I could swap to not storing my maps and using a seed to generate my maps nowadays because I am using SFMT. Thanks for the tip blue ether.
One last thought I've had a couple of times. For my maps I've considered a non-animated "flat" version where an image is generated based on the TMX map and then used in place of the TMX map as a static background. If anyone has done this I'd love to know if the performance gain would be worthwhile. I know in rakkarage's case he is modifying the TMX maps as part of gameplay (i.e. opening doors), so this probably wouldn't work for him without a bunch of code rework. I could see it being a beneficial performance gain in some cases. It's on my radar anyway, thought I'd throw it out and see if anyone has done something like this and their impression of it.
You must log in to post.