Devlog 1 - Level Editor, Collision, Sprite Management and more!!!!
(god that’s a lot of hours i hope most of it was afk)
Alright, it’s been a while since my first devlog but for good reason! I’ve done a metric ton of stuff since then, literally none of which you will actually see as a player! Anyways, I’ll split this up into sections as usual.
Level Editor
Alright, this obviously comes pre-packaged with tilemap & tileset loading, file saving, compression, ids, and all of that, but I’ll try to just focus on the interesting things – firstly, my
Autotiling system!
Because most of the walls in my (top down) game are going to be quite simple, I’ve decided to go with a 16-piece tileset for most of them. Basically, there are 16 different tiles representing what each tile looks like depending on what’s around it – one for having one filled tile to the north only, another for having a tile to the south and east. These tiles can be uniquely represented by essentially assigning a binary flag to each of the four cardinal directions – North -> 1, East -> 2, South -> 4, etc.
Now normally, you’d use a table, maybe a switch case, to match these up with their respective tiles… but I’m lazy and didn’t want to code all of that. Instead, I just decided to force the tile set to be in order so the id mathematically correlates directly to the tile’s position in the tileset! To visualize this, look at the (row-major) ordered tileset image I’ve included. The first 8x8 square is 0 – no filled tiles around it, the second is 1 – representing the tile to the north being filled… you can check this for every one, it all works out.
Collision
Ok, this one’s a lot more simple. The tilemap is stored in the code fundamentally as a grid of ids – 0 = air, anything else means full. To check if a player is colliding with one of these tiles, we just see what grid tiles the player would be colliding with, calculate the grid positions of those places from the world positions, and if those places are full we have a collision! There’s a bit more to it than that because you have to actually handle the collision afterwards but that’s the gist.
Sprite Management
Ok, this one’s pretty simple. At first, I was thinking of assigning each sprite in my game a UUID. But then I realized I wouldn’t using the first U (they don’t need to be universally unique), and sequential would be better, so now I have a sequentially id’d way to get sprites, woohoo. I still have to hook it up to some automation (it would NOT be fun to manually add a new id constant for every sprite in the future), but the core is done.
Alright, I omitted a lot of stuff but I’ve already spent an unusually high amount of effort writing this, so I’ll stop there. Next devlog will hopefully be a lot smaller – refining the tilemap system and adding entities to the editor so I can add props and whatnot. See you all on the other side!
