Game-Engine on Lorbic

Part 6: Simulating a Living Facility: Room Derivation, Sunlight Spillover, and Positional SFX

Mon, 10 Aug 2026 10:00:00 +0530

Generating a raw matrix of integer tiles gives you a map layout, but it doesn’t give you a living environment. When I loaded my first level into Derelict Facility, the engine had no concept of what a “Laboratory” or a “Reactor Room” was. It just saw a flat array of walls and floors.

If a player flipped a power terminal inside a room, I had no clean way to know which room lights or doors to toggle without scanning the whole map grid on every frame. If an alarm fired down the hall, it played at full volume regardless of where the player was standing.

Part 5: From Terminal Cells to Sprite Maps: Font Fallbacks and Auto-Tiling

Sun, 09 Aug 2026 10:00:00 +0530

Building a terminal-based engine in pure ASCII looks cool for about five minutes. Then you try rendering a complex facility map with corners, T-junctions, and status icons, and raw character cells start feeling incredibly limiting.

Two specific problems hit me immediately when I tried switching to Raylib for graphics. First, drawing wall tiles manually by hand in level files meant placing 16 different corner variations by hand. Second, when I tried rendering a 🚨 warning emoji alongside FiraCode monospace text, Raylib just rendered a missing glyph box (? or □).

Part 4: Refactoring to SoA ECS: Bitmasks and Flat Component Arrays

Sat, 08 Aug 2026 10:00:00 +0530

When I started building Derelict Facility, my initial instinct for game actors was standard Object-Oriented design: create an Entity struct, add pointers for position, sprite, and stats, and store them in a slice ([]*Entity).

It worked fine for five entities. But as soon as I added automated doors, save terminals, and active power grids across a 1000-tile map, keeping track of separate heap pointers became a headache. My Go profiler showed GC pauses spiking while the CPU spent more time chasing heap pointers across non-contiguous memory than actually updating game state.

Part 3: Casting Shadows Without Trigonometry: The Beauty of Integer Math

Tue, 07 Apr 2026 10:00:00 +0530

At the end of generating a procedural map for the Derelict Facility engine, I had a sprawling interconnected maze of rooms and corridors. But there was a devastating problem: I could see everything.

The entire map was rendered at once. It looked like a top-down blueprint, not a dark, atmospheric facility. I needed to implement Fog of War. I needed to treat the player character like a lighthouse in the dark.

Part 2: Decoupling the Renderer: Terminal to Raylib in One Interface

Mon, 06 Apr 2026 10:00:00 +0530

The biggest architectural mistake you can make when building a game engine is letting the game know how it is being drawn.

When I started building the Derelict Facility engine, the output target was a raw ANSI terminal. The engine calculated A* paths, resolved line-of-sight, and then spewed escape codes (\033[31m) to os.Stdout.

Eventually, I hit the physical limits of terminal emulators: inconsistent character widths (especially for emojis), slow double-buffering, and a hard cap on frame rates. I needed to move to a real, hardware-accelerated graphics library like Raylib.

Part 1: Data-Oriented Design in Go: Why [][]Tile Destroyed My Game Engine

Sun, 05 Apr 2026 10:00:00 +0530

Most game development stories start the same way: install Unity, drag some sprites onto a canvas, and press Play.

I wanted to understand the metal. I set out to build Derelict Facility, a systems-level game engine from scratch in pure Go. No SDL, no OpenGL wrappers, no Ebiten. The goal wasn’t just to ship a game; the goal was to learn the memory layouts and I/O pipelines that modern engines hide behind friendly APIs.