I’ve started work on some incomplete prototypes for a tilemap extension to Amethyst. My motivation for this is to make level editing for 2D games easy, and to allow voxel driven 3D games to be made in Amethyst.
The basic gist of this is that it’s a system designed to generate the simplest possible accurate physics collider shapes for a given tilemap. It makes few assumptions about your tile data structure, and does not assist with the task of rendering the tilemap.
To accompany this, I’m imagining a tile rendering pass, and a tilemap editor. This system will make little to zero use of ECS, most likely just storing the tilemap as a resource.
Why do we need this?
Tilemaps are a battle tested way to quickly build and prototype levels for 2D games, and additionally voxel games have rising popularity with the indie development scene.
Why aren’t you using ECS?
To quote @Rhuagh
Just because we have a great hammer doesn’t mean everything is a nail.
There are two compelling reasons to keep this separated from the ECS.
- There are a LOT of tiles in a typical level, for a single screen in Mario you can get hundreds. They would have a very good chance of overloading the ECS, causing cache misses for all of the non-tile data.
- Tiles should be kept as minimalist and compact as possible when it comes to data representation, which can be difficult to do with an ECS.
Can I help?
Please do! Right now my biggest blind spot is efficiently generating a minimalist collider mesh for a tilemap. I can identify continuous bodies of tiles, and feed them into a mesh generator, but I don’t actually know how to generate the mesh.