Serac is a game engine being built from scratch in modern C++23, with SFML currently serving as the platform and rendering foundation.
The project is primarily an exploration of how game-engine systems are designed, implemented, and optimized at a low level. Rather than building on top of an existing engine architecture, Serac aims to develop its own core systems incrementally—from mathematics and memory management to rendering, scene management, resources, and eventually tooling.
The emphasis is on understanding the machinery underneath a game engine and building an architecture that remains predictable, debuggable, and performance-conscious as complexity grows.
Status: Early development. The engine is currently in its foundational stage.
Most game development involves working with abstractions that are already built. Serac takes the opposite approach.
The goal is to answer questions such as:
- How should engine subsystems communicate with each other?
- How should memory be allocated and lifetime be managed?
- How should mathematical primitives be represented and optimized?
- How should resources move from disk to GPU memory?
- How should an engine separate platform code, rendering, gameplay, and tools?
- Where does abstraction help, and where does it become unnecessary overhead?
- How can performance characteristics remain predictable as the engine grows?
The project is therefore as much a systems-programming exercise as it is a game-engine project.
Serac is currently establishing its low-level foundation.
The repository currently contains the beginnings of a mathematics layer, including a Vec2 type with arithmetic, magnitude, normalization, distance, and comparison operations.
A minimal executable is also present for testing the engine as individual systems are introduced.
Current structure:
Serac/
├── src/
│ ├── main.cpp
│ └── Math/
│ ├── vec2.h
│ └── vec2.cpp
└── README.md
The implementation is intentionally small at this stage. Systems will be added only as their requirements become clear rather than creating a large framework of empty abstractions upfront.
The engine is expected to evolve around a set of relatively independent subsystems.
A possible high-level direction is:
┌─────────────────────┐
│ Game │
│ / Gameplay │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Engine │
│ Runtime │
└──────────┬──────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Mathematics │ │ Rendering │ │ Resources │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Memory │ │ Platform │ │ Tools │
└─────────────┘ └─────────────┘ └─────────────┘
This is a direction rather than a fixed architecture. The boundaries between systems will be established through implementation and experimentation.
Higher-level systems should be built on top of well-understood primitives.
For example, before introducing increasingly complex gameplay or rendering abstractions, the engine should have predictable representations for vectors, matrices, transforms, memory, resources, and other fundamental concepts.
Serac favors systems whose ownership, lifetime, dependencies, and performance characteristics are easy to reason about.
Abstraction is useful when it represents a meaningful boundary. It is not a goal by itself.
Performance will be considered during system design rather than treated exclusively as a later optimization pass.
This includes attention to:
- Memory layout
- Allocation patterns
- Cache behavior
- Data locality
- Branching
- Temporary allocations
- API overhead
- CPU/GPU synchronization
- Frame-time consistency
The objective is not to make every line of code maximally optimized. The objective is to avoid architectures whose performance characteristics are fundamentally difficult to understand.
The engine targets C++23 and will make use of modern language facilities where they improve correctness, clarity, or performance.
At the same time, language features will not be introduced merely because they are available. Engine code should remain understandable at the level of ownership, lifetime, memory, and execution.
Existing libraries and APIs are useful references, but Serac intentionally avoids treating them as black boxes whenever implementing a subsystem from first principles provides useful insight.
The project is therefore expected to contain both practical engineering decisions and experimental implementations.
The first part of the engine foundation is the mathematics layer.
The current implementation contains Vec2, representing a two-dimensional floating-point vector.
Vec2 position(100.0f, 50.0f);
Vec2 velocity(10.0f, -5.0f);
position += velocity;
float distance = position.distance(Vec2(0.0f, 0.0f));Vec2 currently provides:
- Vector addition and subtraction
- Component-wise multiplication and division
- Scalar arithmetic
- Compound assignment operators
- Magnitude
- Squared magnitude
- Distance
- Squared distance
- Normalization
- Approximate equality comparison
The mathematics module will eventually expand as the engine requires additional primitives such as Vec3, Vec4, matrices, quaternions, transforms, and geometric utilities.
The engine is intentionally kept small.
SFML is currently used as the underlying platform/windowing and rendering foundation.
It allows the project to focus on engine architecture and systems without initially having to implement operating-system window management, input handling, graphics context creation, and other platform-specific functionality from scratch.
As the engine matures, the role of SFML may evolve depending on the requirements of the renderer and platform layer.
The exact development order is intentionally flexible, but the engine is expected to explore systems such as:
Core
- Engine/application lifecycle
- Time and frame management
- Logging and diagnostics
- Configuration
Mathematics
Vec2Vec3Vec4- Matrices
- Quaternions
- Transforms
- Geometry and intersection tests
Memory
- Custom allocators
- Arena/linear allocation
- Pool allocation
- Temporary/frame allocators
- Allocation tracking and diagnostics
Rendering
- Renderer abstraction
- Render primitives
- Camera system
- Batching
- Render queues
- GPU resource management
- Shader management
Resources
- Asset loading
- Resource ownership
- Texture management
- Shader resources
- Serialization
World and Gameplay
- Entities
- Components
- Systems
- Transforms
- Scene/world management
- Event or messaging systems
Platform
- Window management
- Input
- Timing
- File system interaction
- Platform abstraction
Tools
- Debug visualization
- Profiling
- Asset inspection
- Development utilities
- Eventually, editor functionality
Not all of these systems are guaranteed to become part of the final architecture. The implementation will determine which abstractions are actually justified.
Serac is developed incrementally.
A subsystem is generally expected to go through a progression similar to:
Requirement
↓
Minimal implementation
↓
Validation / experiments
↓
Performance analysis
↓
API refinement
↓
Integration with other systems
↓
Documentation
This keeps the repository grounded in working code rather than accumulating speculative interfaces.
The project is currently in early development, so the build process is subject to change.
A C++23-compatible compiler and SFML installation are required.
The current executable is primarily a development/test target used to validate engine components as they are implemented.
Build instructions will be expanded as the project's build system and dependency management become established.
Serac is not currently intended to be used as a general-purpose game engine.
The project is under active architectural development, and APIs should be expected to change significantly.
At this stage, the most important output is not the number of features but the quality of the underlying systems and the understanding gained from implementing them.
No license has been specified yet.
A license will be added before the project is intended for public reuse or distribution.