← Back to Projects

Guardian Magnite

WIP
C++SDL3CMake

Overview

Note: This page is under construction — the engine is an active WIP and this write-up is still being filled in. Details below are accurate as of the last commit.

A makeshift game engine built in C++ for a personal game project, named Guardian Magnite. Features are added based on what the game needs — nothing more. The goal is full low-level control over the development pipeline while keeping dependencies minimal. The engine is built alongside the game it powers.

Currently powering Crusaders — a space exploration and action adventure game.

Design Principles

  • Minimal by design — no engine feature gets added unless the game needs it. The scope is defined by the game it powers, not by what engines usually ship.
  • Full low-level control — the entire pipeline is written in house, from the game loop to rendering calls, so nothing between the game and SDL3 is opaque.
  • One real dependency — SDL3 is the only external library. Everything else on top of it is hand-written.

Core (src/core)

  • Application — the main app class: owns the window and renderer, runs the game loop (ProcessEventsUpdateRender), tracks running/minimized state, and exposes the window handle and dimensions.
  • Renderer — a thin SDL3 renderer wrapper: frame begin/end, draw color, clear/present, plus LoadTexture and DrawTexture (with source/destination rects, rotation, center point, and flip) and primitive DrawRect / DrawLine.
  • Texture — texture wrapper holding loaded image data.
  • Input — keyboard and mouse input handling.

Utils (src/utils)

  • Logger — Debug / Info / Warn / Error logging.
  • Assert — assert helpers for catching bugs early.
  • Timer — delta-time timer used to keep the game loop frame-rate independent.

Build

C++17 via CMake. find_package(SDL3 REQUIRED) and link SDL3::SDL3 — that’s the entire dependency surface.

Entry point in src/main.cpp:

Guardian::Application app("Guardian Engine", 1280, 720);
app.Run();

Status

Per the repo’s plan.txt:

  • Done — the core (Application, Renderer, Texture, Input) and utils (Logger, Assert, Timer).
  • Planned — an ECS layer (Entity, Component, Transform, Sprite), a main Game class that hooks into Application, and Vector2 math.
  • In practice — game logic currently lives directly in Application::Update() and Application::Render() until the ECS layer lands.

What’s Next

The planned pieces fill in the abstraction between the engine core and the game: an ECS for entities, a dedicated Game class, and basic vector math — added only as Crusaders actually needs them.