Need a tip who build own level editor: How you organizing data in your array?
my way is:
array properties: 0-based, X150 Y150 Z2, string array where:
Z1- for tiles - tileFrame_tileSequence_layer*
Z2- for objects - objectID_objectType_layer
problem is size of array. Nearly 704kb in one level, and if game contains around 100 levels - it will be awfulespecially for mobile devices.
so, what will be good solution for keeping tiles, objects in array??
Those are very big dimensions. 150x150x2 = 45000, which means that you're storing 45 thousand pieces of information for each of your levels. Unless you have an unbelievably complex game, the vast majority of those 45 thousand slots are surely empty wasted space. The mere presence of 2 slots in the z dimension doubles the size of the whole thing.
What will probably help you is to plan out your array in a spreadsheet like Excel. Forcing yourself to do it by hand, you'd never do something as unwieldy as making a spreadsheet with 150 columns and 150 rows. Also, mirroring your array in a spreadsheet makes it way easier to keep track of it and is good for your sanity.
My level arrays have about 12 slots in y and no z dimension at all. Let's say a level has 264 objects in it. Then that level's array will look something like this:
X dimension: 264 slots, one per object
Y1: object type
Y2: each object's x location
Y3: each object's y location
Y4: each object's variant type.
Y5: each object's starting animation sequence
Y6-12: other parameters or alterable values that need to be passed on to the game engine.
In my case, it's rare that an object needs to use more than a few slots of y.
your array sizes often comes from your Z values, limit those to the amount you actually need and use X and Y to store different things.
I usually do X = object, Y = data (x/y-position, alt value etc) and Z = different levels.
So every Z is a level that stores the object that should be created in X and loads it values from Y.
Using the z value for levels lets you keep the entire game in one array, but it also means you have to effectively load all levels into memory every level. It also will likely increase the final filesize, unless all levels are very similar in size.
Let's say you have 4 levels with 100 objects each and 1 large level with 463 objects in it. And let's say that you use 7 slots in the Y dimension. If you use individual files for each level, it looks like this:
100x7 (x4 files) = 2800
463x7 (x1 file) = 3241
Total = 6041
If you use 1 file with z for levels, you get:
463x7x5 = 16205
If the game you're making is windows only you could use the binary object and store your level data in different data types. For instance you don't need a whole 4 byte int to store a value that's only going to be 1000 maximum.
Else use the array object but pack the values you need in a single 4 byte int instead. You can use expressions to do this but it does get complex if you're not familiar doing this.
Essentially, say you have a level area made up of a 32 pixel grid. Instead of storing the X position store the grid position. Then just multiply that value by the grid size to get its absolute position. by doing this you may only have a value that is upto 1000 (32x1000 32,000 pixels). 1000 can be stored in 10 bits. So you could store the X and Y in 1 4 byte (32bit) value and still have 12 bits free to use. Now if you have only a hand full of objects types you can store that in the int too. Say object types of 10 (thats 4 bits which will have a max of 15). Then maybe an attribute flag ie "is platform" "is moving" those could be 1 bit each. So using this you could store X, Y, Type, Platform, Movement Flag in 1 single int.
So instead of 16205 (64820bytes) you end up with 863 (3452bytes). 5% of its original size.
To store values you can use bitwise operations. Fusion doesn't natively offer bit shifting so you can use * or / (2^[BITAMOUNT]). Else I plan on releasing an extension I made called "Bitwiser" which has expressions that allow you to embed values into another so should make more sense to a user thats not familar with bitwise operations.
The extension is Windows only but I'm porting to android and may port to HTML5. IOS Maybe.
depending on what he does it's not really that big of a deal. But splitting the levels into different arrays is good too but either way im guessing he put a really big number in his Z value in fusion which boosts the file size greatly. Using X/Y values with fewer Z is better from my experience.Originally Posted by Volnaiskra
thanks for reply everyone. That methods hadful for objects what will have multiple parameters. One more question: what about tiles? they no need to have have properties (maybe needed X and Y and target layer)
Just use your X and Y values for everything.
X1= Object name
Y1= X position
Y2= Y position
Y3= alt values etc
I've ported my bitwiser extension to Android and HTML5 and submitted to the extension manager. I've attached a basic level editor that uses bitwiser to pack the tiles X, Y and tile number into a value for a 1D array. Those 3 values take up 14 bits of a 32 bit value so you can store some more values in there to.
A full level would use 1200 bytes + the array file header. Where as if the values weren't packed the same file would be 3 times that size of that.
Wow, thanks but i cannot find Bitwiser object via extension magager.
Posting Permissions
Reply With Quote