Engine

In my previous blog post, I explained what navigation meshes are and why they’re essential for my game. In this post, I’ll walk you through how I implemented this functionality in my game engine, breaking down the process step by step. Step 1: Creating Native Polygons The foundation of the navigation mesh is a set of “native” polygons that define all walkable areas in the game. I call them “native” because the mesh generation process relies on them. To create these polygons, I added tools to draw, edit, and save them within the engine. For now, this manual approach works well since the map is relatively small, but I’m considering automating this process in the future to handle larger or more complex maps. ...

Over the past few weeks, I’ve made significant progress on the navigation mesh system for my map editing mode, a core feature for creating interactive game levels. This post dives into why I chose navigation meshes, the details of what I’ve built, the challenges I’ve faced, and the next steps I’m tackling. For those unfamiliar, the map editing mode in my game engine allows users to design game environments, including ground tiles, entity placement, and navigation meshes. My current focus is on navigation meshes, which are critical for enabling entities to move intelligently within the environment. Let’s explore the motivation behind this choice and my recent progress. ...

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. ...