Level loading: collection factory or collection proxy?

[teriyaki.pear]

Understanding the standard method to dynamically load levels is through collection proxies, does it make sense to use a factory when the number of levels grows beyond what is easily manageable in a flat collection? Or are factories typically used only for the creation of identical game objects (e.g. enemies, coins)?

Thanks very much for any advice.

[britzl]

@teriyaki.pear

does it make sense to use a factory when the number of levels grows beyond what is easily manageable in a flat collection?

What kind of game are you making? If it’s a grid based game then maybe store the level data in json or similar format and load a single level collection with a tilemap and some factories and create the level from the json data. If it’s more dynamic with a lot of variations to the levels then one level per collection makes more sense. And you can load them via collection proxies or dynamically loaded collection factories.

[teriyaki.pear]

I’m making a 2D platformer RPG - if I follow through, it should have many 10s of levels. Right now, I’m just making the levels in the Defold editor and loading them using collection proxies via the loader pattern. On some reflection, I’m pretty sold on the collection proxy strategy - very clean and clear code, and my resource usage per-collection is modest so I’m not concerned with optimization.

Storing the levels as straight-up JSON makes sense (isn’t that what the collection objects already do?). It also makes room for procedural level generation and simple updates from a remote server. Or are you suggesting building a small declarative language for level geometries on top of Defold’s?

Also, does your suggestion to use the JSON directly hold if I’m placing collision objects manually rather than using those generated automatically via the tilemap? Furthermore, is there a best practice for using CO’s or tilemaps when slopes are involved?

Thanks very much for the help, sorry for the scope creep on this thread - this info is good.

[britzl]

@teriyaki.pear

On some reflection, I’m pretty sold on the collection proxy strategy - very clean and clear code, and my resource usage per-collection is modest so I’m not concerned with optimization

Agreed. I think you should keep what you have.

@teriyaki.pear

Storing the levels as straight-up JSON makes sense (isn’t that what the collection objects already do?). It also makes room for procedural level generation and simple updates from a remote server

You can update a collection at run-time using our live update functionality.

@teriyaki.pear

Also, does your suggestion to use the JSON directly hold if I’m placing collision objects manually rather than using those generated automatically via the tilemap

Nope. Using JSON for level definitions works best if the levels are on a fixed grid and of limited size (think Candy Crush levels). You can build your levels using Tiled and export straight to Lua tables or JSON, parse it, set the tiles of the tilemap and parse any additional meta data in the level to create game objects etc.

@teriyaki.pear

Furthermore, is there a best practice for using CO’s or tilemaps when slopes are involved?

Slopes are notoriously tricky to deal with in platformers. 45 degree slopes or similar would probably stitch together quite nicely though when using tilemaps.