THE EDITOR
admittedly this was done a couple of days ago i lowk forgor

ANYWAYS now we have a level editor yippee!! I’m very happy with it, all you have to do is decorate a property in a class with ExportAttribute and badabing badaboom it’ll appear in the editor!

There’s still a lot more work to be done, I had my friend review the code and there are a good amount of changes I need to make, but honestly I think the base I’ve made for myself is shockingly good, I’m very content! The images below should illustrate how it all works, it’s 11pm, I’m going to bed.

Oh also, there might not be a devlog on this project for a while – GMTK is coming up and I’m gonna be spending a crap ton of time on that and you can bet your bottom dollar I’m getting hours and devlogs from that. That begins on wednesday, take a look at those devlogs if you’re interested :)

Daily Devlog 7/15/26 - UI… i guess

I added a bunch of UI components behind the scenes and more work on the editor. Didn’t get as much time to work today as I’d hoped but I do actually have something to show (even if it is just a textbox lol)

Daily Devlog 7/14/26 – Even MORE editor stuff + training

Alright, today was definitely less productive than yesterday, but I still got a good amount of stuff done.

First of all, the Editor code is very close to being finished! I refactored basically all of it and I’m really proud of how it turned out; genuinely some of the cleanest large-scale code I’ve written basically ever. Very happy with that! Tomorrow, I’ll actually have something to show for all of it 100%; cannot wait for that!

Second of all, I’ve been teaching my friend C#, raylib, and how to work with/contribute to the codebase! I’m not a great teacher so I can’t say it’s the smoothest thing, but progress is no doubt being made. Hopefully once he’s all caught up, we’ll be able to make this game 2x faster than before.

That’s all, see y’all tommorow!

see below the Read/Write functions for the EntityMap (the entities) of the level (at least a high-level abstraction of them ig)

Daily Devlog 7/13/26 – More editor stuff

Alright, today there really isn’t anything much to add. I will say, C# source (ok actually incremental but you get what i mean) generators are very cool. That’s what I’ve been using to avoid reflection when making classes acessable, editable, loadable and saveable in the editor and it’s been great. 1000% recommend over reflection any day of the week unless you definitely don’t need the like 100x performance gains.

Anyways, hopefully tomorrow I’ll be able to actually finish up an early version of the editor and show y’all what it actually looks like! See you all then :)

see below – lambdas, discards, syntax trees, LINQ, and pattern matching all in one function call. doesn’t get more C# than this.

Sprite packing, teaching, etc.

Honestly, everything I did is still backend, so nothing super interesting to report on. Lots of the hours here was teaching my friend proficiency with C# and general gamedev/SWE practices, but I still do have some stuff to share!

I have an irrational hatred of dictionaries.

So, while a normal human might be inclined to create a Dict<string, Sprite>, I made a whole seperate project that packs sprites into a texture atlas and makes a slightly absurd amount of properties so you can statically access every one! Honestly, it works very well and makes sprites super easy to use – I know manually writing out a .cs file is a little odd, but hey, if it works it works.

Side note, I switched to linux!

After windows decided to randomly lock me out of my laptop for an hour because it “detected odd activity”, I decided to finally bite the bullet and just install Linux. And it’s been pretty good! Honestly, everything is very tranferable from Windows, at least for a programmer, it’s a shockingly easy switch. Also it’s fun using the terminal more often and feeling like a hacker lol. Currently running Fedora w/ KDE Plasma for anyone who’s curious, although I think I’m going to switch to either Arch or Debian, I’m not super content with the dnf package manager or Red hat, altho I will say KDE Plasma is great.

Alright, I’m going to wrap this up early(ish) b/c I still have a days of coding ahead of me (I just realized that it stops counting after 10hrs)
Oh last thing – I’m going to start doing daily devlogs to track my progress a bit more accurately as me and my friend start to lock in more. Look forward to seeing you guys later today then!

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!

Devlog 0 – Movement, Occlusion, Debug Console, etc.

hey y’all, thanks for checking out my devlog! In case you’re wondering why this is titled “Devlog 0” and not “Devlog 1”, it’s because everything in this devlog is actually just rehashed from some random testing I did a while back for a game I never ended up developing further. Anyways, I’ll go over the three main parts. Bear in mind, a lot of the work in this build is backend and the end result looks like I made it in 10 minutes, but I promise there’s a lot going on behind the scenes!

1. Occlusion

Pretty simple, just drawing a shadowed area where the player won’t be able to see.

2. Debug Console

So this is definitely one of the things that I did not code right now. A while back I made this really handy debug console thingamajig and I figured I’d show it off here. The system was originally made in Monogame, and I coded a whole text input system just for the debug console lol. This project is in Raylib C# but they’re similar enough that I just ported the code over.

3. other random info

ok i kind of realized that I haven’t really explained what this project is about. To be honest I’m not quite sure – I’m going off the vague idea of a top-down heisting game (like Payday 2 or Entry Point on Roblox), but obviously I’ll have to see what’s fun. Right now I’m going to start working on guns, a level editor, and enemies. After that’s done, I’ll hopefully have a more concrete idea of what I want to make.

ok that’s it thanks for reading bybye