Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / [Data Structures] Best way to represent level data in a 2d platformer

Author
Message
Koakuma
8
Years of Service
User Offline
Joined: 13th Aug 2015
Location:
Posted: 20th Nov 2015 23:46
So I recently started work on the design document for my second game with agk, and probably the first one that I'll actually publish.
I decided to make it a 2D platformer since I've always wanted to make one, but I have no idea what the most effective way to represent the level is.
Doing a little research on my own turned up results along the line of creating a binary file containing the name of the tileset to load and then writing out the level as a series of numbers with each one representing a tile. Collision would be handled by a second binary file containing properties for all of the tiles.
However, this method doesn't allow for multiple layers of tile. (Such as a lightbulb hanging from a ceiling tile, or having a magical circle at the end of the level to transport the player to the next level) This could be avoided by defining another tile and adding the sprite manually, but that is rather inefficient when considering that a forest might want random and highly varied undergrowth, etc. On the other hand, a 3D array would be able to handle multiple layers of sprite, but how would one represent that in a binary file? Separate blocks of defined level data?
Are there any data structures that can effectively handle all this?
Another issue that I think would arise is how laggy a 3D array would be when certain tiles have special effects. (Such as the circle to transport the player - You'd have to check for collision every frame, which means you'd have to iterate through the entire 3D array to find any/all circles and similar objects!)
The solution to that would be two arrays, one with non-special tiles and one with special tiles. The non-special tile array would only need to be accessed during level load/unload, while the special tile array would need to be iterated over every frame. Even so, that's still a potentially 3D array with potentially several thousand slots, many of which are potentially empty. That's a whole lot of iterating over nothing.
Is there anyone more experienced in 2d platformer programming that can give me some pointers?

The more options, the better. Thanks for your time.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 22nd Nov 2015 00:32 Edited at: 22nd Nov 2015 01:14
take a look at this code,it uses the loading and saving of types, if you wish to use it then use the attached media folder for the gfx...




and here is an example of how I load in the created level and put it to use, i would create a new project(in this case called zenoid) and copy over the needed functions from the editor, copy the media folders contents of the editors to the zenoid media folder, and copy the level saved out from the editor to zenoid media folder, what I basically did was make sure that the object I placed for the player had a group value of 1, the group value is defined in the editor under the text editor box coincidentally labelled 'group'! in the code below somewhere (in bold) I check to see if the group value is 1, if so then I indicate it as being the players sprite!





the above is the start of a 'breakout' clone, the collisions are already in there and it uses the box physics. hope you learn from this code!

If i have more time I will finish all this stuff and release it here with all the documentation explaining it all fully! just that health problems have thrwarted my plan somewhat!

***edit** you also need keys.agk for the first code, here is the code: name a new file in the project as keys.agk and paste the code below






The main reason I posted here was to also think that i may not get chance to finish it, so just in case, then perhaps someone like you or someone else can finish it off for me! I will nevertheless code as much as I can to try and complete it and document it all. God willing!Besides a minor bug here and there it is all good so far
Hail to the king, baby!

Attachments

Login to view attachments
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 22nd Nov 2015 01:19 Edited at: 22nd Nov 2015 02:02
actually here are both project folders zipped up to make it easier:
Hail to the king, baby!

Attachments

Login to view attachments
Koakuma
8
Years of Service
User Offline
Joined: 13th Aug 2015
Location:
Posted: 23rd Nov 2015 23:17
So you just define a one-dimensional array of "mysprites" objects and use that?
My game is likely going to be a lot more advanced in terms of tile placements, so I am looking at something along the lines of a 2D array so that I can keep track of where each sprite is by using the formula (i*16), (j*16), where i and j are the indexes into the array.
That way, I can easily edit the level map on the fly without iterating through the whole thing to find the right tile to modify.
shadey
14
Years of Service
User Offline
Joined: 25th Jan 2010
Location:
Posted: 24th Nov 2015 13:01 Edited at: 24th Nov 2015 13:21
study the code more, I use types and dimension them, look into the use of types,they are far more poweful than just old school multi dimensional arrays


a short example:





So this allows 1000 or 1001 (if you count array index 0) sprites with their own fields, If I wanted to say make all the image field have a value of 1 I would change it like so:



you first name the array index then after a . you put in the type field name, very simple but Look in the help/guides/arrays within AppGameKit for a maybe clearer explanation
Hail to the king, baby!
Koakuma
8
Years of Service
User Offline
Joined: 13th Aug 2015
Location:
Posted: 25th Nov 2015 01:44
No, I get that you're using types. My issue is with the fact that using the array like that makes it more difficult to locate a particular arbitrary tile based on an arbitrary point in the world, and other such similar issues.
Here's some of my program's current code, modified for human readability and compactness:


I was looking for a more effective way to do it, though, but I think this will suffice. The only part that I have to iterate over every frame is interactibleTiles[ i ], which means that a 90x90x3 level with 2 interactible tiles will be no more laggy than a 3x3x3 level with two interactible tiles, algorithmically speaking.

Login to post a reply

Server time is: 2024-03-29 10:31:09
Your offset time is: 2024-03-29 10:31:09