SpartanEngine

Overview

Spartan is a complete C++ game engine. Path-traced global illumination, hardware ray tracing, a bindless GPU-driven renderer and a racing-grade vehicle simulation sit alongside what a shipped game needs:

The bundled worlds show the range, from Plan, a playable racing game across the island of Zakynthos, to path-traced interiors and a car showroom. Its rendering technology ships in Godot Engine and S.T.A.L.K.E.R. Anomaly, it features in a published programming book, and more than 600 engineers follow its development on Discord.

[!IMPORTANT] Built for veterans. Spartan is one engineer's engine, so there is no support queue and no one-to-one help. There is documentation, a Lua scripting guide and a codebase written to be read. If you are a high-agency engineer who can take it from there, you can ship with it.

Showcase

Features

• ReSTIR path tracing with spatiotemporal reservoir resampling for real-time multi-bounce global illumination
• Clustered deferred shading with a GPU-built logarithmic-Z grid and cone-vs-AABB culling for spots, so many local lights cost near-constant time per pixel
• IES photometric light profiles (LM-63): spot lights emit the measured beam of a real fixture, from car headlights with regulation cut-offs to architectural downlights, with correct lumens and candela across direct lighting, volumetric fog and path tracing. A feature usually reserved for the big commercial engines
• Hardware ray-traced reflections and shadows via ray queries
• Atmospheric scattering and image-based lighting with bent normals
• Volumetric clouds (Nubis-style) baked into the sky panorama, with cumulus and cirrus layers, multi-scatter lighting and aerial perspective
• Froxel volumetric fog: one view-aligned volume for height and distance fog, sun shafts and underwater caustic shafts, with temporal reprojection and shadowing
• FFT ocean with a Tessendorf spectrum and multi-cascade IFFT in compute, driving a camera-following clipmap with choppy displacement, dynamic normals and crest foam
• Screen-space shadows (inspired by Days Gone) and XeGTAO ambient occlusion
• Shadow map atlas with fast filtering and penumbra estimation

Geometry, materials, textures, lights, transforms and bounds live in persistent, globally accessible buffers. No per-draw descriptor updates, no per-draw resource binding, no CPU-side draw loops.

• Zero-binding draw path: all per-draw data lives in a single bindless storage buffer, push constants carry only an index
• Single global vertex and index buffer for all geometry (inspired by id Tech), with vertex pulling that bypasses the Input Assembler and is shared by rasterization and ray tracing
• GPU-driven indirect rendering with per-meshlet frustum, Hi-Z occlusion and backface cone culling; the CPU issues a single DrawIndexedIndirectCount per pass
• Meshlet clustering via meshoptimizer, with mesh shaders when available and a vertex-pulling fallback
• Bindless everything: materials, lights, samplers, uber shaders, minimal PSO permutations
• Universal HLSL compiled for Vulkan (SPIR-V), DirectX 12 and Metal (Metal Shader Converter)
• GPU-side asset processing: mip generation (FidelityFX SPD) and texture compression (Compressonator) at load time, not baked offline
• Unified deferred rendering: opaque and transparent surfaces share the same BSDF and render path
• Async compute for SSAO and screen-space shadows, in parallel with shadow rasterization

• NVIDIA DLSS 4.5 Super Resolution (SDK 310.9.1) and Intel XeSS 2.0.2 (SDK 3.0.2)
• AMD FSR upscaling (FSR SDK 2.4.0) on Windows with Vulkan and D3D12. Select AMD FSR in Renderer Options (or r.antialiasing_upsampling 5). The SDK selects FSR 4.1.2 on supported Radeon GPUs and FSR 3.1 on other supported GPUs. Run dependency setup to fetch the signed loader and upscaler DLLs. Frame generation retains its existing, separate SDK.
• AMD FSR 3.1 frame generation (FidelityFX SDK 1.1.4) on Vulkan and D3D12, works on any vendor's GPU, with frame-generation-aware fps, latency and frame rate limiting
• TAAU: temporal anti-aliasing with built-in upsampling, Halton jitter and variance-clipped history
• Variable rate shading and dynamic resolution scaling
• Foliage impostors as the final GPU LOD, so dense forests stay cheap at distance
• Texture streaming within a fixed memory budget
• Custom GPU breadcrumbs for crash tracing and post-mortem debugging
• Physically based camera with auto-exposure and physical light units (lux, lumens and kelvin)
• Tonemappers: ACES, AgX and Gran Turismo 7 (default), with HDR10 output
• Post-processing: bloom, motion blur, depth of field, chromatic aberration, film grain and sharpening (CAS)

A full vehicle dynamics model running inside the PhysX fixed-timestep loop. Not a gameplay approximation: racing-sim fidelity inside a general-purpose engine.

System	Details
Tires	Pacejka MF 5.2 with combined slip, thermal model, pressure, wear and multiple surfaces
Suspension	Convex hull sweep contact, spring-damper, anti-roll bars, bump stops, bump steer, camber and toe
Weight transfer	Geometric and elastic lateral split via roll centre heights and roll stiffness
Drivetrain	Engine torque curve, turbo, 7-speed gearbox, rev-match, open, locked and limited-slip differentials, RWD, FWD and AWD
Brakes	Thermal model with fade, front/rear bias and slip-threshold ABS
Aerodynamics	Drag, front and rear downforce, ground effect, DRS and rolling resistance
Steering	Ackermann geometry, high-speed reduction and self-aligning torque
Assists	ABS, traction control and handbrake
Integration	Semi-implicit Euler with consolidated net torque per wheel
Input	Controllers and steering wheels with haptic feedback
Camera	GT7-inspired chase camera with speed-based dynamics

System	Details
Platforms	Windows (DirectX 12 and Vulkan), Linux (Vulkan) and macOS 26.0+ (Metal 4), with prebuilt binaries in every release
Physics	PhysX with rigid bodies, character kinematics and vehicle dynamics
Animation	Skeletal animation with keyframed clips, crossfade blending, four-bone skinning and two-bone IK with ground-aware foot planting
Particles	GPU-driven compute emission and simulation, depth-buffer collision and soft blending
Weather	Rain that soaks exposed surfaces, fills puddles and keeps covered areas dry, feeding tire grip
Procedural roads	Catmull-Rom spline roads with extruded profiles, terrain conforming, instanced props and path followers
Scripting	Lua 5.4 via Sol2 with the full engine API and lifecycle callbacks
Visual scripting	Node graph editor that compiles to Lua, with every engine API function as a node and a tutorial world
Audio	3D positional audio, streaming, reverb and procedural engine synthesis via SDL3
Cinematics	Camera cut sequencer with entity tracking, spline-driven movement and exact cut timing
Entity system	Component-based with transform hierarchies, prefabs and XML serialization
Threading	Hardware-aware thread pool with parallel loops and nested parallelism detection
Editor	Hierarchy, asset browser, inspector, script, visual script and shader editors, gizmos, profiler and memory viewer
Profiling	Nsight/RGP-style timeline with graphics and async compute lanes, RenderDoc integration and a GPU/CPU memory fragmentation map
Asset import	40+ model formats (Assimp), 30+ image formats (FreeImage), 10+ font formats (FreeType)
VR (WIP)	OpenXR with multiview single-pass stereo on Vulkan and DirectX 12

Quick start

[!TIP] Just want to try it? Prebuilt binaries ship with every release; on first launch the World Launcher downloads the project assets and the worlds. Building from source? Getting started has the details.

  Windows

# then open spartan.slnx (use d3d12 for DirectX 12, or no arguments for a menu)
generate_project_files.bat vs2026 vulkan

  Linux

tools/linux_dependencies.sh && ./generate_project_files.sh gmake vulkan && make config=release_x64

  macOS 26.0+  Apple silicon, Metal 4

# needs Xcode 26, Homebrew (brew install cmake ninja) and the Metal Shader Converter
# from developer.apple.com/metal/shader-converter, then open spartan.xcworkspace
tools/macos_dependencies.sh && ./generate_project_files.sh xcode4 metal

The binaries/ folder keeps executables at the top level. Windows vendor DLLs live in third_party/ (Direct3D Agility components in third_party/d3d12/), compiler intermediates and Windows symbols in build/, preferences in settings/, diagnostics in logs/, and engine-wide generated data in cache/. Existing preferences, logs, and engine caches migrate on first launch without replacing files already at the new locations. World-specific bake caches remain alongside their world resources. data/, project/, and crashes/ retain their existing roles. steam_appid.txt stays beside the executable for local Steam development. Ship the vendor folder with the executable; game exports and Windows release archives preserve its structure. Python bytecode caches are excluded from game exports.

Project generation creates one target, spartan, built for the selected graphics backend in three configurations:

Configuration	What it is	Executable
development	Optimized with full symbols, the default	spartan_<backend>_development.exe
debug	Unoptimized	spartan_<backend>_debug.exe
release	Optimized with link-time optimization	spartan_<backend>.exe

The same executable is the editor and the game: -game hides the editor panels, and a game.xml written by Build Game next to the executable turns it into a packaged game that plays its start world directly. The full list of command-line arguments is in Getting started.

With dependencies already installed, regenerate without downloading them:

tools/premake5.exe --file=tools/premake.lua --skip-setup vs2026 vulkan

# macOS
tools/premake5 --file=tools/premake.lua --skip-setup xcode4 metal

Engine and world boundary. There is no game layer in C++. source/world/WorldSystems.cpp installs the world lifecycle hooks: camera controls, vehicle render submissions, breakable trees and the optional world systems (ambient wildlife, ambient atmosphere, road details, layered road surfaces). Vehicle physics and state live under source/car, vehicle MCP commands in source/mcp/McpCommandsCar.cpp, and traffic, race drivers, route drivers, car resets and skid marks are regular components in source/world/components. The optional world systems are off by default; a world turns them on through the WorldSystems Lua table from its companion script, the .lua with the same name next to the .world (worlds/plan.lua for plan.world), which runs on every load before the roads are built. Worker model imports publish their entity hierarchy through World::EntityBatch::Commit() after construction succeeds.

Physics. Scene stepping and contact observation use game-independent callbacks; the game installs vehicle contact handling. Vehicle state is opaque to engine consumers, while the existing Physics authoring and Lua API remains compatible.

Asset ownership. World saves record native asset ownership in OwnedResources. Automatic cleanup only removes unreferenced files recorded there; unlisted files, shared libraries, sculpt data and generated caches keep their separate lifetimes. Legacy worlds acquire ownership of referenced assets when saved and do not prune unrelated legacy files.

Component attributes. Attributes exposed for editing go through the component's setters. Raw copy-only or derived fields are read-only; use the named authoring properties for edits.

Play lifecycle. Play startup captures all authored transforms before any component starts, with both phases spread across frames. Stopping play drains completed worker batches before restoration and removal. World unload cancels staged work and clears renderer scene references and temporal history while preserving device lookup tables.

Documentation

In the wild

Ready for games?

Yes. Older coverage, like "The BEST Game Engine You SHOULDN'T Use", describes an engine that no longer exists. Back then Spartan was a renderer. Today it has the scripting, runtime, packaging and Steam support to ship, and graphically it goes further than any other open-source engine.

The one thing that hasn't changed is support: if you need hand-holding, pick something else. If you don't, Spartan is ready.

Community

License

[!NOTE] Free for noncommercial use under the Spartan Engine License 1.0. Commercial use requires prior written permission and negotiated payment terms.

The commercial terms are aimed mainly at larger companies. Individuals and small independent teams who want to monetize their work will get exceptionally favorable terms, tailored to their project after a conversation. Just reach out and an arrangement that works for you will be found.

The license permits free noncommercial use, modification, and redistribution, including reuse of covered code in other projects. Keep the copyright notice identifying Panos Karabelas and the license with redistributed code; compiled distributions must carry them in documentation or accessible legal notices.

Commercial fees, royalties, or a combination are agreed case by case, with no automatic rate or revenue threshold. This applies to the engine and covered code copied into other games, engines, libraries, tools, or applications. Contact Panos Karabelas to discuss your project.

Third-party components retain their own licenses. Copies and versions previously released under MIT retain their existing permissions. See license.md for the complete terms.