This is a minimal setup guide for first-time users.
Clone the Repository:
git clone https://github.com/oguzhanduguncu/engine_playground.git
cd engine_playground
Initialize Submodules:
git submodule update --init --recursive
Install SDL2:
Linux (Ubuntu / Debian):
sudo apt update
sudo apt install -y libsdl2-dev
Build:
mkdir build
cd build
cmake ..
cmake --build .
A research-oriented C++ engine playground focused on real-time simulation, deterministic physics, and time ownership.
This project explores how professional simulation and RTS engines structure their update loops, handle fixed timesteps, and avoid instability issues such as tunneling and nondeterminism.
Most modern game engines are frame-driven. This works well for visual responsiveness but introduces subtle instability and nondeterminism in physics-heavy or simulation-oriented systems.
This project exists to explore an alternative approach:
- Physics owns time
- Simulation runs at a fixed timestep
- Rendering interpolates instead of driving logic
- Audio lives in a separate real-time domain
The engine is structured around a single principle:
Time is produced by the engine core, consumed by simulation, and merely observed by rendering.
Subsystems:
- Physics: fixed timestep, authoritative
- Render: variable FPS, interpolated
- Audio: callback-driven, real-time safe
Using variable delta time for physics leads to:
- Frame-rate dependent behavior
- Unstable collision response
- Tunneling under high velocities
This engine uses a fixed timestep accumulator model to ensure:
- Stable simulation
- Predictable collision handling
- Deterministic replay potential
Discrete collision checks can miss fast-moving objects, a phenomenon known as tunneling.
This project demonstrates:
- Why reducing dt is not scalable
- How collision time (TOI) can be predicted
- How CCD can be integrated without breaking the fixed timestep model
- Not a game
- Not a full-featured engine
- Not optimized for production
It is an experimental lab designed to understand engine-level design decisions.
- Why physics should not be frame-driven
- How engines avoid the spiral of death
- How real-time systems differ from visual systems
- Why determinism must be designed from day one