MGL is a graphics library that implements an OpenGL compatibility layer on top of Apple's Metal API. It translates OpenGL API calls into Metal rendering commands, allowing developers to use OpenGL-style programming on macOS without relying on legacy drivers. The library includes a shader compilation pipeline (GLSL to MSL via SPIR-V), a math library (GLM), and windowing support (GLFW). It is designed for high-performance rendering and virtualization contexts, evidenced by comments regarding QEMU framebuffer blitting. The codebase is a monolithic C/ObjC library with a dispatch table pattern for API routing.
The Doomsday Engine is a modular game engine and source port for classic FPS games (Doom, Heretic, Hexen, Doom64) with client-server architecture. It provides enhanced rendering (OpenGL), audio systems, GUI frameworks, networking, and scripting capabilities. The engine supports extensibility via plugins and includes tools like Amethyst for documentation processing. The codebase shows strong separation of concerns with distinct libraries for core functionality, game logic, rendering, and UI. While actively maintained, it exhibits technical drift due to platform-specific conditionals, legacy code sections, and complex dependency management.
g3nd is the official demo/showcase application for the g3n Go 3D game engine. It is a single Go binary that presents a windowed GUI (built on the engine's own immediate-mode GUI system) with a categorized demo tree. Users select demos that exercise the engine's capabilities: glTF/glb loading, PBR materials, animations (skinning, morph targets), audio (OpenAL), particle systems, post-processing shaders, and GUI widgets (tables, trees, sliders, form boxes, dock layouts). The application registers demos via Go's `init()` side-effect pattern: each demo package imports itself and calls `app.DemoMap["category.name"] = &struct{}{}`. The core `App` struct manages the scene graph, camera, orbit controls, and per-frame `Update` dispatch. The repository also vendors a large set of test assets (glTF sample models, Blender files, audio, textures) under `data/`. The architecture is a classic Go application: `main.go` imports all demo packages for their registration side effects, then delegates to `app.Create().Run()`. The `app` package owns the window, GUI, and demo lifecycle. Each demo implements a minimal `IDemo` interface (`Start`, `Update`, `Cleanup`). The `util` package provides reusable GUI helpers (file selectors, light meshes). The demos are grouped by category: animation, audio, experimental physics, geometry, GUI, light, loader, material, other, shader, texture. The code is idiomatic Go with clean separation, but some demos are marked experimental and the engine dependency is a pseudo-version that may drift.
Blobby Volley 2 is a complete, cross-platform 2D multiplayer volleyball game implemented in C++ with Lua scripting for AI bots and game rules. It features local and networked multiplayer (client-server via a bundled, modified RakNet stack), a dedicated server for online matchmaking, replay recording/playback, and a custom immediate-mode GUI built on SDL2. The architecture uses a state machine pattern (State base class with derived menu, game, and replay states), abstracted rendering backends (OpenGL, SDL, Null), and a custom physics engine with integrated Lua-driven rule logic. The project is built with CMake and targets Windows, Linux, macOS, Android, and Nintendo Switch, with GitHub Actions CI for multiple compilers and platforms. The game's core loop processes player input (keyboard, mouse, joystick, touch, or Lua script) through an InputManager, feeds it into DuelMatch (which combines GameLogic and PhysicWorld for physics and rules), and renders via RenderManager. Network games use RakNet for reliable UDP communication with prioritized packet handling; the dedicated server manages lobbies, matchmaking, and state broadcasting. Replays are recorded as binary state snapshots (using GenericIO serialization) and can be played back in-game. The Lua API provides bot developers with real-time game state queries, physics prediction functions, and callbacks for serve and bounce events, along with older legacy scripts in data/scripts/old. While the codebase demonstrates solid engineering (template-based serialization, abstracted file I/O with PhysFS, cross-platform build systems), it carries technical debt from aging dependencies (RakNet, Lua 5.3, SDL2, TinyXML2) and heavy use of platform-specific ifdefs. Some components, like the custom IMGUI and RakNet integration, are tightly coupled and not easily extractable, but the GenericIO serialization layer and FileSystem wrapper are self-contained and could be reused in other C++ projects needing binary I/O or virtual file system access.
This repository is a work-in-progress decompilation of The Legend of Zelda: Twilight Princess for GameCube and Wii. It reconstructs the original game's source code from its compiled binary, aiming for byte-perfect reproducibility. The codebase is a hybrid of reversed-engineered game logic, reimplemented Nintendo SDK libraries (JSystem, Dolphin, Revolution), and a massive collection of asset resource headers that define model, animation, and collision IDs for every in-game object. The architecture follows the original game's custom actor framework (f_op/f_pc) combined with middleware from JSystem and the Nintendo SDK. The project supports multiple region and platform variants (GameCube, Wii, Nvidia Shield), with resource headers duplicated across version-specific directories. The decompilation is incomplete; many source files are stubs or placeholders (marked NONMATCHING), and the asset headers are auto-generated or manually copied from the original game's data. The code is written in C++ with Metrowerks compiler conventions, and the build system uses Python and Ninja. While not a runnable application on its own (requires a copy of the game), it represents a comprehensive reverse-engineering effort with active development and community engagement.
This repository contains the source code for the Poseidon game engine, which powers the remastered version of Arma: Cold War Assault (CWR). It is a large, monolithic C++20 codebase with a modular subsystem architecture covering graphics (OpenGL 3.3), audio (OpenAL), networking (UDP with custom transport), input (SDL), AI, world simulation, UI, and asset management. The engine supports dedicated servers, modding via PBO archives, and a scripting language (SQF/SQS). The repository also includes a suite of CLI tools (PBO packing, image conversion, model inspection, etc.), a Blender addon for importing P3D models, and Rust components for a master server and test harness (Trident). Extensive unit tests (Catch2) and fuzz harnesses are provided. The codebase is a locked snapshot with no active development, but it demonstrates high craftsmanship in areas like custom containers, memory management, and network protocol design. However, it suffers from technical debt including heavy use of preprocessor macros, global state, and platform-specific conditionals.
Scrawl is a 2D game engine that fuses a Python-facing API with a high-performance Rust runtime built on Bevy and PyO3. It targets developers who want Scratch-like simplicity (sprites, scenes, broadcasts, event decorators) and Godot-like depth (node tree, signals, physics bodies, animation). The Python package (`scrawl`) provides classes for Game, Scene, Sprite2D, RigidBody2D, Camera2D, Timer, Tween, and more, all of which transparently synchronize with a Bevy ECS backend via a shared command queue and dirty-flag system. A visual IDE (`scrawl_ide`) built with PySide6 offers scene editing, code editing, asset management, property inspection, an AI chat panel, and a game runner that launches the engine as a subprocess. The Rust side comprises 13+ crates (core, render, physics, audio, particles, navigation, animation, tilemap, UI, scripting, bridge, editor protocol), though several remain disconnected from the main binary (e.g., audio, particles, navigation). The overall architecture is dual-process: the IDE writes generated Python scripts to disk and spawns the engine binary, which uses named pipes for editor-server protocol. This is purely an application; there is no data analysis or machine learning component.
Craftium is a voxel-based game engine (Luanti/Minetest fork) extended with reinforcement learning capabilities. The core system provides a moddable 3D world with block-based gameplay, Lua scripting API, client-server architecture, and procedural map generation. The craftium add-on supplies Python bindings, Gymnasium environment interfaces, and RL training scripts to enable machine learning research within the game world. The system supports both traditional gameplay and AI experimentation through environment-specific mods that define reward functions, observations, and termination conditions for agents.
This repository is a reimplementation of the Deus Ex: Human Revolution Director's Cut (DXHRDC) game engine, created through manual decompilation and cleanup of the original binary, supplemented with debug information from a leaked Tomb Raider (2013) build (same engine family). It is not a matching decompilation and lacks automated resynchronization with the original binary. The engine requires original game assets (BIGFILE.* files) to run and provides core systems for rendering (DirectX 11 abstraction), audio (FMOD-based), animation (animation graph), game logic (object management, AI, player systems), input, UI (Scaleform via ImGui), resource management, and world streaming. The architecture is modular but monolithic, with a central game loop in cdcGameShell/MainG2.cpp. While the code shows evidence of structured design (interfaces, resource management, job system), it contains numerous TODOs, HACKs, and incomplete implementations, indicating ongoing work. Dependencies include DirectX 11 (or dxvk-native for Linux), FMOD, Dear ImGui, and miniz. The project is actively maintained with recent commits.
Dusklight is a reverse-engineered reimplementation of The Legend of Zelda: Twilight Princess for PC, built on the Aurora engine. It replaces the original GameCube/Wii runtime with a modern cross-platform renderer (D3D12, Vulkan, Metal) and adds extensive modding support. The codebase is dominated by decompiled game logic (actor framework, collision, audio) and massive asset resource definitions duplicated across dozens of region variants. A custom modding layer (dusk) provides UI windows, input handling, save editing, autosave, achievements, LiveSplit integration, and a service-oriented mod dependency system. The project is actively developed but carries significant technical debt from its decompilation origins: many functions are marked NONMATCHING, large portions of SDK libraries are stub implementations, and asset headers are copied verbatim across multiple build variant directories, creating maintenance risk. The modding infrastructure shows good engineering practices, but the core game code remains tightly coupled to the original binary layout.
This is the Source SDK 2013, Valve's official modding SDK for Half-Life 2, Half-Life 2: Deathmatch, and Team Fortress 2. It provides the full game engine source code, including client and server DLLs, map compilation tools (vbsp, vrad, vvis), distributed processing (VMPI), and a comprehensive set of game entities, AI behaviors, rendering shaders, and UI frameworks. The codebase is a large C++ monolith with heavy use of preprocessor conditionals to support multiple game mods (HL2, HL2MP, TF2, SDK) and platform targets (Windows, Linux, Xbox 360). It includes a NextBot AI framework with behavior trees, a VGUI2 UI system, a material system with shader fallbacks for legacy DirectX levels, and a replay system. However, the repository is effectively a historical snapshot: many proprietary systems are stubbed out, third-party libraries (protobuf 2.6.1, LZMA) are outdated, and the code shows signs of bitrot with deprecated APIs and dead code paths. It is not actively maintained and would require significant modernization for use in new projects.