Level Loader
Monkey Forums/Monkey Programming/Level Loader
| ||
| Does anyone have source for loading simple tilemap levels into an array? Is it worth using sparse tiles in the level textfiles? Most of the map will be either empty or filled with stone. Open areas in the map will be carved out of a map previously filled with stone. There will be a map-scanning pass at runtime which replaces borders between stone and empty with the appropriate wall tiles. Is it worth doing a sparse level structure? The above is semi-sparse but it strikes me that since wide open areas are mostly rectangular it would be much smaller to store empty areas as rectangles of various sizes, either defined during design phase (using a rectangle tool for carving out large areas) or when the map is saved. Compare the tilemap sizes in typical platformers with the sizes of the same maps saved as the actions of various tools on the level structure, and replayed at runtime to rebuild the same structure. Does the space savings and level-load savings justify the somewhat greater effort of writing this sort of tool-action save and replay system? Would it be worthwhile getting the level size down to a few tens of bytes? Something like a list of uppercorner, lowercorner, tiletype Individual tiles and lines of tiles made with a line tool could be saved in the same format. Thoughts? Should I bother or just use a conventional tilemap for the filestructure? It strikes me that this sort of structure would be small enough that 100 or so levels could be baked into the executable at compile time. |
| ||
| It depends on the delivery of your end game download. If its in anyway compressed then the potential effort to write it would seem wasted. Saying that its always nice to code little systems like this, surely it could be useful in the future? |
| ||
| > Does the space savings and level-load savings justify the somewhat greater effort .. No, not until it becomes neccesssary which might be if your levels are very big and you have dozens of them. But until then use what works. Also, compressing the file should not affect the design process (like defining them in an editor). If you are really sure you have to compress the file, maybe RLE would be a good start which is also easy to implement. |
| ||
| My main issue is really loading level times rather than delivery. I would like to have level loading be almost so snappy as to be imperceptible, probably achieved with async loading during gameplay of the previous level. >Also, compressing the file should not affect the design process (like defining them in an editor). Well, if you have tools such as rectangles and single-tile placement, it should be very easy to reconstruct the level out of tool-use order. For many games, levels could be encoded with a very few rectangles and lines. I will take a look at your editor. BTW, I would like to ship with 100 levels. They won't be all that large, but again I want level loading to be extremely snappy. |
| ||
| > They won't be all that large, but again I want level loading to be extremely snappy. The few bytes will not improve the loading time dramatically, but of course you can test it and see yourself because it might depend on the platform. Unfortunately my editor is not aimed at doing tile based game, actually the opposite :/ But there are tons of tile editors out there. |
   |