lalacomun wrote:Now your goal is to handle multiple layers, like tiles, objects, collision etc...
Just a tip for your engine, i dont recomend having a "Collision layer" it uses more RAM and more HDD space, you may say that 1 mb of ram doesnt matter but when you are working with low resources hardware that meg of ram makes the difference
i recommend you that each tile have a simple boolean value that sets if its colidable or not, this way you can have something like "colliders" like the ES engine that sets what part of the tile is colidable ex: upper half of tile, left half tile etc...atleast thats the way i handle collision in my engine
That is not how our engine handles collision anymore. If you have a look at our livestreams, we have a pretty large selection of diverse collision geometry (ie quads, l-shapes, triangles). These are represented as an enumerated type within our tile attribute array. These are then extracted by the collision engine, where they are turned into real collision geometry before they are passed to their respective collision algorithms.
DistoredLance wrote:There are, of course, disadvantages with this approach. It's not quite as flexible when it comes to having multiple tiles with the same graphic but with different collision bounds, so depending on the scenario, a separate collision layer could easily be reasonable. You could do various things like bit-masking the collision type in the "tile index" (if you already had spare bits available) rather than fixing the collision types when loading the tilesheet if you wanted specific collisions per-layer, or just read in an additional value per map-location if you wanted this additional flexibility. If you're using the bit-mask approach, there's no additional memory usage, while the per-location method is a relatively small number of kilobytes. It's probably better for him to decide what the realistic needs of the game would be, rather than simply choosing a method for a constraint that might not necessarily apply.
This is very true. There are trade-offs to both approaches. We used to use a separate collision layer for the reasons you stated. Unfortunately, a separate collision layer is actually too expensive for us, as we already have 4 rather large map layers.
The bit-mask approach is actually a pain in the ass when you're building levels. 99% of the time, you want a particular tile to have static collision geometry. Having to manually set every single solid in a map every time you place a tree, wall, or solid object is a huge pain in the ass that burdens level designers.
If you do go with a separate collision layer, I recommend using a hybrid approach (as we used to). Give your tiles a "default" collider attribute that is applied to the collision layer when you lay the tile. Then if you wish to override this (as I said, 99% of the time you don't), you can manually do so. This will save you a shitload of time.
