Platform game level design

Hi Everyone,

I'm a new Contruct2 user who is getting started with this wonderful tool.

When creating levels for platform games, is the preferred method:

a) Make the level as one large graphic of which only a portion is viewed by a player and is scrolled back and forth

or

b) Assets are mapped to a level held within an array/table which are created/destroyed )off camera) as required

or

c) another method I've yet to be aware of.

Please don't slap me too hard! I'm stood at the bottom of the well looking up at you guys.

kindest regards, GamingHound.

A lot depend on how you implement the mechanics.

I guess both methods are ok, you just have to keep other basics in mind, such as not using too much large graphics for level elements.

im building an isometric which does a bit of both, have most of the layout created, and all the dynamics stuff gets created when i get in range.

A lot is about finding a balance with your graphics and performance (next to having decent code running ofc).

Method 2 is a lot harder for most people, but if you are able, that is a very good method, and gives you a lot of dynamic manipulation ability to the level.

Most just build huge layouts which serve as individual levels.

Many thanks lennaert. Much appreciated.

I like both methods, however let me tell you a tale about B.

C2 will always save the image/assets in reserve even if you remove all instances of the image.

What this means is that even if you "unload" all the images the visual image object will still exist. So there is no memory saving by unloading.

In the end level loaders are best served for level creation tools or community creation of levels. They don't serve much benefit else where :( so using the Layout editor is pretty much just a level creation toolkit anyways.

C2 will always save the image/assets in reserve even if you remove all instances of the image.

Very true, but just imagine it with enemies, using pathfinding and line of sight. Or defense turrets somewhere or just objects with lots of conditional collisions.

Optional you can ofc enable/disable certain behaviours at runtime.

But recently I was a bit surprised; I forgot which topic, but, the OP eventually mentioned applying a trick to decrease memory load before closing the app, he simply loaded an empty layout first which made a huge quick memory-usage-reduction.

So, the more you have on your layout, (even more so with objects doing behaviours) the more your cpu runs to handle it all, and imo, reducing memory access speed / throughput.

This type of approach could greatly increased performance on larger layouts.

Many thanks for that tip jayderyu.