[?] Level Data - What could be wrong with this approach??

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

[?] Level Data - What could be wrong with this approach??

(12 posts) (5 voices)

Started 10 months ago by Duckwit
Latest reply from clarus

Tags:

Duckwit
Member

So I have been reading quite a bit about this on the forum, but nothing that could fully satisfy what information I am looking for.

I am nearing the stage where I need to start being able to create levels 'quickly' and store all there data some way or another.
For loading levels I had these properties in-mind -

The background would be loaded in 'segments' (480 x 320/960 x 640 Sprites), the segments would be loaded based on their type when passed with the rest of the level data into an actual GameScene. (So a segment of type 2 might be a grassy terrain segment, 3 and 4 might be different variations of this grass segment style, then 6, 7, 8 might be desert formations, textures would be loaded accordingly in the actual game scene)

The objects that there are to interact with. Again, each 'type of object' would have a specific 'ID', just an integer to track what type of object it is. Then I would also need a position for each object. Each object that is loaded when the gamescene is running (loaded based on distance from the player, e.g. when it is within winSize.width*2 it will identify the type, insert it at a position, and add the created object to a collision testing array for the player)

This seems too straightforward to me.

Have a LevelData Class that stores all the data for each level.
Each level would be a custom data structure that had an array of terrain segment ID's, and an array of data structures of objects (ID and position).

In gamescene it would identify what the objects are from the array, and their positions, generate them, and voila.

I've read a lot about storing this sort of data in .plists and such, but, WHY? What is wrong with this approach, is there something I have missed?

Posted 10 months ago #
Dragyn
Member

@Duckwit: I don't see a problem with your approach from what you wrote. I'm not quite sure what your question really is. Is it the custom class vs. plist? If that's the question, the reason most will recommend a .plist is that it is human readable (and tweakable), where a custom class you have created and stored isn't human-readable.

If you use a custom class that you serialize and save in your own format, you have to build the level within your code first, then save it out. So small tweaks result in a lot more work to re-generate the custom data file. And if you have written code that generates that custom level file, you might as well just call that method instead of saving it out at all.

The way I'd approach this (and have in the past) is to have a plist that contains either a dictionary of arrays or an array or arrays, and each one of those arrays is a level, with elements for all of the stuff you need to create the level. When you are loading a level, read the plist, find the level you want, and parse the data with your code to build the level in memory.

Posted 10 months ago #
clarus
Member

If I understand what you're saying, it's really a developer-preference thing. I'd rather edit my scene layouts in a plist than in code. Put another way, I'd rather separate the data from the code.

The advantage to having a reader class that turns your plist or database entries into objects is that if you want to modify the design and add parameters or something more complex, you just need to change it one place in the reader class (where you parse the data), and then add support for it in any object entries you care about.

So, say I want to add support for opacity and rotation parameters that I hadn't originally coded for. I can check for the new parameters in the reader class and, if found, apply them to any objects I create. Then, I can go into my plist and make the changes to any of my objects to rotate them or change their opacity by adding one or two key/value parameters that I can copy/paste wherever I want them (updating the values). Could you handle all of that in code? Sure. But, assuming you're creating a lot of scenes and objects, you'd probably be changing code in a lot of places. This way, the majority of your changes are in dater, which I'd argue is safer (assuming your code handles errors).

I'd say that using a data file (plist, database) to define your scenes/objects/animations/whatever and then changing the reader code in one place is also better for maintenance (less room for errors, easier if you decide you want to change how you handle something) and it's a lot cleaner for extending. But, that's just my opinion. When I work on projects, I want as much code reusability as possible for other apps, so for me, I'd rather create some classes that read all my spritesheets, scene descriptions and so on and builds things for me. Then I can just drop the code for those classes into another project, update or add data files to describe the scenes and I'm off to a good start. Again, it's a developer preference.

Essentially you're doing the same thing as people were suggesting with plists, only your code builds the data that you would have read from a plist (or database).

Posted 10 months ago #
Duckwit
Member

Wow @clarus and @Dragyn thanks for the responses! :)
It is definitely something to consider before implementation, so far I have not had any experience with .plist except for loading animations, not data values.
Thanks for the excellent advice so far - but is there somewhere that details how to interact with .plists from code?

Also one more question -
When I briefly went through my slightly drafty description above I had the idea that I would categorize the object 'type' by a number, in GameScene it would choose which graphic to use based on that number - BUT should I have the actual graphic in the .plist and load it from there? What are the advantages of doing so? (Is it more memory efficient?)

Thanks :D

Posted 10 months ago #
clarus
Member
You can read a plist as an NSDictionary, and then access the keys/values like that.

So, some generic code:
```
#define kExamplePlistFileName  @"HeresAnExample.plist"

NSString   *fullPathToPList = [[NSBundle mainBundle] pathForResource: [kExamplePlistFileName stringByDeletingPathExtension] ofType: [kExamplePlistFileName pathExtension]];

NSDictionary *myExamplePListAsDict = [[[NSDictionary alloc] initWithContentsOfFile: fullPathToPList] autorelease];

// Do stuff...
NSArray      *spriteSheetsToLoad = [myExamplePListAsDict valueForKey: @"SpriteSheets"];
NSString     *LocalizableStringsFileName = [myExamplePListAsDict valueForKey: @"LocalizableStringsFileName"];
NSNumber     *someNumber = [myExamplePListAsDict valueForKey: @"SomeNumber"];
NSDictionary *levelLayouts = [myExamplePListAsDict valueForKey: @"LevelLayouts"];

// ...
```
As an example, your plist could contain a dictionary or array of scenes that contain dictionaries describing how to create the elements you load for a scene.

Things you may want to consider - layouts for different device orientations, different devices (iPad vs. iPhone). You can have different plists you load for those things or specify the different layouts in the same file. I'd tend to have a different plist for the device models because there's no sense in loading data for an iPad if you're running on an iPhone. iPhone/iPod touch would most likely use the same plist.

One thing that I find helpful is to create some helper categories, particularly for NSStrings that can turn strings like "50.0,75.0" into CGSize, CGPoint (also allowing you to specify percentages of the screen area as a position), similar ones for CGRect, and then ones for converting enum names in the plist into the enum values so I can put more readable data in the plist.

The basic idea is that you have a dictionary of data you put together, and then you have code to turn that into your objects (CCSprites, etc.) You can then reference those objects in code by using tags you add them with, probably specified in the plist entries.

You could also create an entire scene in code and save that out as the data you later read in if that made sense. You can only save basic types in a plist so you have to serialize that data into NSStrings, NSNumbers, NSArrays, etc. before writing it.

Getting back to your last question. Most likely you want to use something like TexturePacker or Zwoptex to create spritesheets of the images you use for sprites. So, maybe you'd reference the spritesheet filename in the plist and the name of the frame to use for a sprite, but the actual image data wouldn't be there.
Posted 10 months ago #
Duckwit
Member

Thanks for the detailed response @clarus - One more quick question if you don't mind:
Can plists contain just simple 'normal' types like int/float? All the types you mentioned were objects - so ..

Thanks :D

Posted 10 months ago #
clarus
Member

You need to include them as numbers in the plist. In code, those will be read as NSNumbers and then you just access the value as [someNumber floatValue], [someNumber integerValue] etc.

If you create a property list and then edit it with Xcode, you'll see the available types in the popup lists for each element you add. Any string values you add will be read as NSStrings, numbers as NSNumbers, arrays as NSArrays and dictionaries as NSDictionaries.

Posted 10 months ago #
WatchTheBanana
Member

I'd recommend taking a look at the Cocos sample "ParallaxTest" first before writing your own (though I like to write my own classes too just so you know them inside and out, but this one is pretty good).

Uses the CCTileMapAtlas class and TMX files, there is a pretty decent editor too called "Tiled" which is free (http://www.mapeditor.org/).

You can have tiles of any dimensions you like and they are loaded in sprite sheet form so the whole thing runs pretty fast. The class has read and write access to the map data too so you can look for certain tiles and manipulate them in code.

Posted 10 months ago #
Dragyn
Member

@WatchTheBanana: Good call on Tiled. The one thing I noticed, though, is that Tiled won't handle one piece of @Duckwit's question: Interaction objects that are not part of a tile map. So if a "normal" tilemap is used, there will still need to be a secondary data source for the interaction objects that go with it.

Posted 10 months ago #
WatchTheBanana
Member

@Dragyn, Regarding the interaction:

You have lots of choices off the top of my head (no expert with this class, just started adding it to a game myself):

Method 1:
Say tiles 0 to 9 are solid tiles (the first 10 in your sprite map image along the top). 10 to 19 are types you can walk through/past. In your collision detection you get the number of the tile and let your character walk through.

Method 2:
Tiled and the class support multiple layers. Use a second layer for objects you can walk through say.

Method 3:
Each tile can be given one or more "tile properties" (in the Tiled app, right click a tile in tileset window, select "tile properties"). You can give a tile a "walk through" label, or a "enemy 1" or whatever you like.

Posted 10 months ago #
alechko03
Member

Hello Everyone!

Great explanations here. I definitely use the Plist to load my levels for all the reasons you mentioned. I am a little stuck though...
So basically...
-I have the plist file with the info of the levels.
-Each level has different objects of course, they are box2d object.
-For each one of the objects I also have a class which defines the objects physics properties and box2d stuff.
- I also have a DataController class which parses the data from the Plist and puts the various properties into variables (strings,arrays...)
- The whole physics world is in a GameScene class. Here I also plug in all the elements of the game with a method for each to instantiate them in another class.
- The last class in the chain is the LevelLoader. With this class I already know in which level the user is in, so what I want to do based on the level that the user clicked is to load all the elements from the plist and construct the level.

First of all I would like to know if my whole structure for the game is correct...

I am at a stage where I am able to a load the correct level through levelLoader based on the level the user clicked. I also able to load the corresponding background image of that level. I am also able to load a game object through a function which was defined in GameScene (GameScene.h is imported into LevelLoader).

The Problem: I am trying to think how can I load all level objects that correspond to the certain level, all from the plist.Considering each object is different with different properties. Like I said earlier I want the LevelLoader to load all the objects with their properties from the plist according to the level the user is.

Hope all this is clear enough to understand, if not post a reply and I will gladly answer. If somebody wants to see the code involved let me know.

Thank you in advance.

Posted 10 months ago #
clarus
Member

I'm not sure of the problem. Your entries need to have more than just box2d info if your code doesn't already know the type of object you're creating, which sprite to use, etc.

Use a dictionary for each entry in the plist (so an array of dicts or a dict of dicts for a scene) and have keys for things like position, opacity, and so on. Most importantly have a key that indicates the type of cc2d object you're creating (sprite, label, etc.) Then, just run through the entries and create the objects according to the type of the entry, with whatever relevant keys are present. For example, you might make things like opacity optional, and use 255 if it's not there.

I think you just need to add more info to the plist, then sync the reader class with those changes and you'll be good to go. Let me know if I'm misunderstanding.

Posted 10 months ago #

RSS feed for this topic

Reply

You must log in to post.