In my last post, I talked about how my game engine loads assets from an asset file. To make it easy to tweak these assets, I built an Asset Editing System. This system lets users make small changes to assets and save them back to the asset file. It’s split into different “modes” for each asset type, like BitmapMode, SoundMode, SpritesheetMode, and others. In this post, I’ll explain the system’s main features and go over each mode. ...
After completing my initial demo for my school capstone project, I set out to transform my work into a proper game engine, prioritizing ease of use and flexibility. My first focus was enhancing asset management and map editing. During the demo’s development, I built a basic tilemap editor that allowed me to place tiles, define collision boxes, and add static entities like trees, stones, and houses—represented as textures with collision data. It worked, but it lacked a user interface, undo/redo functionality, and advanced features like object manipulation or in-editor simulation with a player character. The output was three binary files—tile_map.bin, decorations.bin, and collisions.bin—containing tile textures, entity placements, and collision data. ...
It’s been a little while since my last update on the Kaban Engine refactor, and I’ve been busy wrestling with input handling, integrating Nuklear more deeply into my codebase, and sorting out some UI quirks. Progress is steady, and I’m starting to see the light at the end of the tunnel—or at least a less foggy path forward. Here’s what I’ve been up to since last time! Input Handling: Borrowing from GLFW After ditching GLFW for window management (see my last post for that saga), I still found its input handling code pretty solid. So, I peeked under the hood, grabbed some of its input-fetching logic, and ported it into my engine’s platform layer. Nuklear needs specific inputs—keyboard, mouse, the usual suspects—and GLFW’s approach fit the bill. Porting it was painless; I just tweaked a few things, wrote some wrapper functions, and it was good to go. ...
It’s been about a week since my last post, and I’ve been neck-deep in figuring out GLFW, GLEW, and Nuklear for the Kaban Engine refactor. I also squeezed in some OpenGL tutorials because, let’s be real, my OpenGL knowledge was more “vague vibes” than actual expertise. Here’s how it’s been going—some wins, some headaches, and a clearer path forward. GLFW: Not My Cup of Tea I kicked things off with GLFW, excited to ditch the Windows API mess. Getting a window up was easy—honestly, I spent more time skimming the docs than coding. But then I hit a snag. Running in windowed fullscreen mode, the window insists on staying on top. If I’m on a single-monitor setup, stepping into the debugger is impossible because the window hogs the screen. On two monitors, it’s still a pain—clicking the debugger iconifies the window. There’s an auto-iconify disable option, but then I’m back to the “always on top” problem. ...
Since I “finished” working on the Clipper library, I decided it was time to refactor my game engine. The last time I touched it was almost six months ago, and when I opened the source code, my first instinct was to throw everything in the garbage and start over. One of the biggest issues I faced was the debug system. Originally, I had implemented a system inspired by Handmade Hero, and while I love how it was designed, it had dependencies on both rendering and asset management—something I wanted to eliminate. ...