Roaming Wild Gaming Blog

Tag: game-framework

  • Build Your Game Training Hub with GTW

    I am building GTW — Game Trainer Workbench, a free and open-source Windows application for creating, organizing, validating, and maintaining personal game-training tools for legally owned, offline single-player PC games.

    This project is motivated by how I actually play games.

    I enjoy RPGs, strategy games, progression systems, experimentation, post-game grinding, character development, and understanding how game systems work beneath the surface. Sometimes I want to reduce repetitive grinding. Sometimes I want to test a build, recover from a frustrating limitation, experiment with values, or revisit a game without repeating dozens of hours of progression.

    Existing trainers can help, but they often introduce a different set of problems:

    • They come from sources that are difficult to evaluate.
    • Their behavior is rarely transparent.
    • They may stop working after a game update.
    • They usually provide no meaningful explanation of what they modify.
    • Each trainer is normally a separate executable with its own interface and maintenance model.
    • When support disappears, the user has little ability to repair or understand it.

    GTW is my attempt to build the personal game-training platform I would want to use myself.

    The long-term vision is a single local application where I can:

    • Maintain a library of the PC games I own.
    • See which games and versions are currently supported.
    • Enable reversible training capabilities from one consistent interface.
    • Understand exactly what each capability reads or changes.
    • Detect when a game update invalidates an existing profile.
    • Keep unsafe or unverified capabilities disabled automatically.
    • Restore original values after an experiment.
    • Add support for newly acquired games through a structured development workflow.
    • Use powerful AI models to help investigate changes, analyze evidence, write tests, and propose updates when game versions change.
    • Review every AI-generated change before it is allowed to affect a running game.

    The goal is not simply to build another collection of trainers. The goal is to create a version-aware game-training workbench that can continue growing alongside a personal game library.

    Why C# and .NET 10

    The project began with an evaluation of existing Rust and C# memory-scanning foundations, including whether it made sense to fork an established scanner.

    Rust is an excellent choice for high-performance scanning engines, but GTW is broader than a scanner. It also needs a Windows desktop application, game profiles, module loading, compatibility management, diagnostics, testing, restoration, structured logging, and an eventual AI-assisted review workflow.

    C# and .NET 10 were selected because they provide the best overall fit for this specific product:

    • GTW is intentionally Windows-first.
    • Win32 memory APIs can be accessed directly through controlled P/Invoke boundaries.
    • .NET provides a mature environment for desktop interfaces, dependency injection, testing, structured configuration, and modular application design.
    • C# is well suited to code that must remain readable and reviewable as AI assists with future maintenance.
    • Unity integration can eventually benefit from the shared .NET ecosystem surrounding BepInEx.
    • Performance-sensitive scanning components can still be replaced or supplemented by a Rust engine later without rebuilding the entire application.

    The architecture preserves that option through replaceable interfaces rather than binding the application to one scanner implementation.

    Architectural principles

    GTW is being designed around a few strict principles.

    Write-disabled by default

    A capability cannot write simply because it knows an address.

    The application must first establish that:

    • The profile is valid.
    • The executable fingerprint matches a supported game version.
    • The location was resolved through an evidence-backed method.
    • The current value satisfies the expected constraints.
    • The original value was captured for restoration.
    • The session passed the applicable safety checks.

    Read-only sessions and write-authorized sessions are represented by different types. Write authority is intentionally difficult to obtain and cannot be created by ordinary game-module code.

    Version-aware rather than address-dependent

    A raw memory address is temporary and insufficient.

    GTW profiles describe how a value is located using evidence such as:

    • Module-relative offsets
    • Pointer chains
    • Signatures
    • Symbols
    • Human-readable descriptions
    • Validation conditions
    • Supported executable fingerprints
    • Provenance and test results

    A bare absolute address is rejected by the profile schema.

    When a game changes, GTW should identify the profile as unverified rather than continuing to write through outdated assumptions.

    Reversible by construction

    Every approved write captures the original state first.

    The current vertical slice can:

    • Read a value
    • Validate it
    • Write a new value
    • Verify the write
    • Maintain the value through a freeze loop
    • Stop freezing
    • Restore the original value

    The write implementation does not inject threads, install drivers, hide the process, or change page protections.

    Least privilege

    The read-only Windows adapter requests only the process permissions needed to inspect memory.

    Write permissions are isolated into a separate assembly and are introduced only after validation succeeds. The project explicitly avoids PROCESS_ALL_ACCESS, kernel components, process hiding, endpoint-security interference, and unrelated native privileges.

    Fail closed

    Uncertainty does not become permission.

    Unsupported schema versions, invalid profiles, fingerprint mismatches, ambiguous scan results, unreadable memory regions, incomplete reads, inconclusive session-safety checks, and failed validation all keep writes disabled.

    Evidence before automation

    AI is intended to assist the engineering process—not replace validation.

    The future AI workspace is designed to help:

    • Compare an old supported game version with a new one.
    • Analyze diagnostic evidence.
    • Review scan results.
    • Propose updated locators or module code.
    • Add and run tests.
    • Explain risks and assumptions.
    • Produce a reviewable commit or pull-request-style package.
    • Preserve rollback instructions.

    AI-generated code will remain inactive until a human reviews and approves it. A successful compilation will never be treated as proof that a trainer still works safely.

    What currently works

    GTW is already more than an architecture document.

    The current codebase includes:

    • C# and .NET 10 solution architecture
    • Apache 2.0 licensing
    • Versioned game-profile and capability schemas
    • Fail-closed schema and semantic validation
    • Executable SHA-256 fingerprinting
    • PE version information extraction
    • A harmless test process that simulates game values and breaking version updates
    • Least-privilege read-only Windows process access
    • Process-instance identity checks that protect against PID reuse
    • Region-validated and exact-length memory reads
    • Validated, read-back-verified memory writes
    • Restoration snapshots
    • Freeze and unfreeze behavior
    • Compatibility reporting
    • Exact-value, range, and signature scanning
    • Successive scan narrowing
    • A command-line workflow that can discover a value without knowing its address beforehand
    • Classification of discovered addresses as module-relative or dynamically allocated
    • Generation of reusable locator fragments for stable module-relative results
    • A fail-closed guard for known anti-cheat modules, processes, and services
    • More than 100 automated tests across domain, Windows integration, scanning, safety, and command-line behavior

    The automated testing is performed against a harmless target built specifically for this repository rather than treating a commercial game as a CI test fixture.

    What comes next

    The current project is a working engineering foundation and command-line prototype. It is not yet the polished application I ultimately intend to use.

    Major upcoming work includes:

    • Pointer-chain and signature-anchored resolution for dynamic heap values
    • A local game library
    • Installed-game discovery
    • A profile registry
    • A desktop interface
    • Hotkey management
    • Health checks
    • Centralized restoration and rollback
    • Structured audit history
    • Game-module packaging
    • Bounded AI-assisted module development
    • Optional Unity, Unreal Engine, and RE Engine adapters
    • Initial supported-game profiles

    The first practical milestone is a complete end-to-end flow where a supported game can be discovered, fingerprinted, matched to a validated profile, safely modified, restored, and automatically marked unsupported when its executable changes.

    Project boundaries

    GTW is being built for:

    • Games the user legally owns
    • Local use
    • Offline and single-player sessions
    • User-mode operation
    • Reversible experimentation
    • Transparent and reviewable capabilities

    It is not being built for:

    • Multiplayer cheating
    • Competitive advantages
    • Anti-cheat bypasses
    • Stealth or process hiding
    • Kernel drivers
    • Security-software interference
    • Unreviewed trainer downloads
    • Automatic activation of AI-generated code

    Known anti-cheat detection results in refusal, not circumvention.

    Open-source direction

    GTW will be released under the Apache License 2.0.

    The intention is to keep the source code, application, schemas, safety improvements, compatibility fixes, documentation, and essential functionality freely available.

    Optional financial support may be introduced through GitHub Sponsors and a simple one-time-support platform. Contributions would help fund development tools, AI-assisted engineering costs, testing, documentation, code signing, and legally acquired games for compatibility research.

    Support would remain voluntary. The public project would not be intentionally weakened to create a paid version.

    The guiding principle is:

    Everyone receives the software. Supporters help make its continued development sustainable.

    The repository is currently private while I finish the public README, contribution guidance, documentation reconciliation, and initial release posture.

    Repository: github.com/nhlutterodt/game_trainer_project
    Technology: C# / .NET 10 / Windows
    License: Apache 2.0
    Current stage: Active development and working command-line prototype
    Public release: Planned after the repository’s launch documentation and safety review are complete

    I am especially interested in feedback from Windows and .NET developers, software architects, reverse-engineering educators, game modders, security reviewers, technical writers, and open-source maintainers.

    GTW is still early, but the foundation is now strong enough that the larger vision feels achievable: one transparent, maintainable, AI-assisted workbench for the offline games I own today and the games I will add to my library in the future.

  • 2D World Pivot

    2D World Pivot

    Building a 2D Animation Lab: From Stickman to Shared Worlds

    An open-source journey inspired by MUGEN

    Illustration of stickman characters evolving into fully-rigged fighters

    How a Family Project Sparked a Bigger Vision

    This adventure began as a rainy-weekend coding exercise with my daughter and nephews. Our goal was simple: turn a stickman doodle into a playable character. Their creativity quickly outgrew our prototype, pushing me to rethink how portable our characters could be across different games.

    “Wouldn’t it be cool if our stickman could travel to any world we build next?” — My nine-year-old co-designer

    Remembering MUGEN & the Power of Community Mods

    Back in the early 2000s, the M.U.G.E.N engine gave budding game designers like me a playground to create custom fighters. It was open, moddable, and wildly creative. That ethos still resonates, and it’s the spirit I’m channeling into this 2D Animation Lab.

    What Makes a Character Truly Portable?

    Beyond sprite sheets, a portable character needs a rig—bones, constraints, and animation data that can be re-targeted. My lab focuses on:

    • Skeleton-based animation for resolution independence.
    • Procedural movesets that adapt to new physics systems.
    • An open asset format anyone can extend.

    Under the Hood: Tools & Techniques

    I’m building with TypeScript , HTML5 Canvas , and a sprinkle of WebGL for performant previews. The engine is framework-free (think micro-ECS), so contributors can drop in without wrestling heavyweight dependencies.

    Join the Lab

    If you’re passionate about open-source fighting games, procedural worlds, or just tinkering with animation rigs, check out the GitHub repo and share your ideas. The goal is to make the next-gen MUGEN together.

    © 2025 Neils Haldane-Lutterodt • All opinions are my own.
  • Creating Modular 3D Worlds: Key Techniques and Innovations

    Creating Modular 3D Worlds: Key Techniques and Innovations

    Building a Modular 3D World Layer

    An Interactive Exploration of Core Systems

    A. Procedural Terrain Generation

    This section explores the algorithmic creation of vast, detailed landscapes. The primary goal is to generate large-scale worlds with rich variety while balancing performance and quality.

    Heightmap Algorithm Comparison

    We compare three foundational algorithms—Diamond-Square, Perlin Noise, and Simplex Noise—on visual quality, performance, and implementation complexity.

    Algorithm Visual Quality
    (1–10)    		 Performance
    (Higher is Better)    		 Complexity
    (Lower is Easier)
    Diamond-Square 6 8 3
    Perlin Noise 8 7 5
    Simplex Noise 9.5 9 7

    Key Takeaway:

    Diamond-Square is easy but prone to artifacts. Perlin Noise is a classic choice. Simplex Noise delivers the best overall balance (fewer artifacts, better performance), and its patent expired in 2022—making it ideal for new development.

    LOD and Chunking Strategies

    Rendering an entire high-detail world at once is infeasible. Level of Detail (LOD) techniques break the world into chunks and adjust detail based on distance from the viewer.

    GeoMipmapping

    Uses precomputed, lower‐resolution versions of terrain chunks. Efficient but requires careful seam‐handling (“T‐junctions”) to avoid cracks.

    Quadtree Management

    Organizes terrain chunks hierarchically. Enables efficient culling and LOD selection, and is vital for streaming large worlds from disk.

    B. Sky & Atmospherics

    Realistic sky rendering sets the mood for outdoor scenes. We simulate atmospheric scattering (the physics behind blue skies and red sunsets) and compare two analytical models: Preetham and Hosek-Wilkie.

    Atmospheric Scattering Model Comparison

    The Preetham model is fast but simplified; Hosek-Wilkie is more accurate—especially at sunset—though slightly more costly. Below is a summary.

    Metric Preetham et al. Hosek-Wilkie
    Performance (1–10) 9 7
    Daytime Realism (1–10) 7 9
    Sunset/Sunrise Realism (1–10) 4 9
    Haze/Turbidity (1–10) 5 8

    Key Takeaway:

    Hosek-Wilkie offers superior physical accuracy—ideal for realistic sunsets or hazy atmospheres—at the cost of slightly lower performance. In most high‐fidelity applications, Hosek-Wilkie is recommended, though blending with other techniques for night skies can mitigate its low‐angle artifacts.

    Dynamic Effects

    Day/Night Cycles

    Animate the sun’s position over time. This drives sky color, light intensity, and an eventual transition to a night sky with stars or moon.

    Volumetric Clouds

    Ray‐march a 3D noise field for realistic cloud shapes. This is computation‐heavy; use adaptive sampling and resolution scaling for real‐time performance.

    C. Wind & Weather

    Dynamic effects like wind and weather bring a virtual world to life. Here we cover procedural wind fields, GPU‐driven particle systems, and an event‐driven approach for smooth weather transitions.

    Core Techniques

    Noise-Driven Wind Fields

    A 3D procedural noise field (e.g., Simplex noise) defines a dynamic vector field for wind. Other systems query this field at any location to get consistent wind direction and strength for foliage and particles.

    Particle Systems for Weather

    Rain, snow, and fog are rendered using GPU‐accelerated particle systems. Each particle’s movement is updated by physics (gravity) and forces from the global wind field.

    Event‐Driven Weather Transitions

    Coordinating sky, lighting, particles, audio, and materials requires a modular solution. The central WeatherManager publishes a WeatherChangeEvent. Each subscribed system reacts independently, ensuring a cohesive transition.

    WeatherManagerSystem
    Event Bus: WeatherChangeEvent
    SkySystem
    LightingSystem
    WindSystem
    ParticleSystem
    AudioSystem
    MaterialSystem

    D. Lighting & Physically Based Rendering (PBR)

    Physically Based Rendering (PBR) uses realistic material properties and lighting models that conserve energy. We cover HDR Image‐Based Lighting, Cascaded Shadow Maps, and the importance of maintaining real‐world scale.

    Key Lighting Techniques

    HDR Image-Based Lighting (IBL)

    Use HDR environment maps for realistic ambient light and reflections. A PMREMGenerator pre‐filters the map for various material roughness levels—essential for accurate PBR.

    Cascaded Shadow Maps (CSM)

    For large worlds, split the camera frustum into cascades. Each cascade gets its own shadow map, ensuring fine detail close to the viewer and broader coverage farther away.

    Critical Prerequisite: Scene Scale

    For physically correct lighting attenuation, the 3D scene must use a real‐world scale. In Three.js, 1 unit = 1 meter is the convention, ensuring light intensity values behave predictably.

    E. ECS Integration & Configuration

    The Entity Component System (ECS) pattern separates data (components) from logic (systems), offering maximum modularity. Below is a simplified diagram illustrating how entities, components, and systems interact in our world layer.

    Entity (ID)
    Component
    PositionComponent
    Component
    FoliageComponent
    Component
    RenderableComponent
    System
    Processes entities with PositionComponent + FoliageComponent
    FoliageAnimationSystem

    F. Performance & Robustness

    A visually rich world must also run efficiently and remain stable. Below are key strategies for optimizing data structures, reusing objects, and offloading heavy work to maintain performance on target hardware.

    Key Optimization Strategies

    Spatial Data Structures

    Use Quadtrees (for 2D/2.5D) or Octrees (for 3D) to quickly query nearby objects. Crucial for LOD selection, culling, collision detection, and localized queries (e.g., “what’s the wind speed here?”).

    Object Pooling

    Frequently creating/destroying objects (terrain chunks, particles) causes GC stutter. Pooling recycles objects for reuse, improving performance for dynamic systems.

    Offloading to GPU & Workers

    Heavy computations (noise generation, particle updates, vertex animation) go on the GPU via shaders. CPU‐bound mesh generation can move to Web Workers, keeping the UI thread responsive.

    Testing & Debugging

    Ensure robustness with unit tests for individual systems and integration tests for system interactions. Runtime debug tools (e.g., lil-gui) are invaluable for real‐time tuning and diagnostics.

    Interactive report rendered as a static blog post per WordPress.com constraints.

  • Thoughts on ECS Guide for Game Design

    Thoughts on ECS Guide for Game Design

    Foundations Architecture Performance Frameworks Implementations

    Foundations of ECS

    This section introduces the core principles of the Entity Component System (ECS) architecture. We’ll explore the fundamental building blocks—Entities, Components, and Systems—and understand the paradigm shift from traditional Object-Oriented Programming (OOP) towards a more flexible, data-oriented design. This foundation is key to grasping the performance and modularity benefits of ECS.

    🆔
    Entity
    A simple ID. It has no logic—just a handle for attaching components.
    📦
    Component
    Pure data (e.g., Position, Health). No methods—just state.
    🧠
    System
    Pure logic—code that operates on entities with specific components.

    Architectural Design

    Effective ECS architecture hinges on thoughtful design of its core parts. This section explores crucial design considerations for components and systems, including how to manage their scope, ensure data purity, and facilitate communication between them. We also cover strategies for handling global data that doesn’t naturally fit within individual entities.

    Component Design

    • Granularity: Components should be small and focused. Too large, and you lose composition benefits; too small, and you create unnecessary complexity.
    • Data Purity: Components must contain only data, no logic or methods. This separation is key to the entire ECS pattern.
    • Reusability: Design components to be general-purpose so they can be combined in novel ways to create new entity types.

    System Design

    • Single Responsibility: Each system should perform one specific task (e.g., MovementSystem, DamageSystem).
    • Execution Order: The order systems run in is critical. A PhysicsSystem must run before a MovementSystem. Manage this with explicit ordering or dependency graphs.
    • Communication: Systems communicate indirectly by modifying component data. For discrete events (e.g., ‘PlayerDied’), an Event System is often used to maintain decoupling.

    Performance Engineering

    One of the primary reasons to adopt ECS is for performance. Here, we compare two memory layouts: AoS (Array of Structures) vs. SoA (Structure of Arrays). You’ll see why SoA is far more cache-friendly.

    Memory Layout: AoS vs. SoA

    Array of Structures (AoS) – Inefficient

    Entity 1: [Position, Velocity, Health]
Entity 2: [Position, Velocity, Health]
Entity 3: [Position, Velocity, Health]

    A system updating only “Position” must load and then discard all other component data for each entity.

    Structure of Arrays (SoA) – Efficient

    Positions: [Pos 1, Pos 2, Pos 3]
Velocities: [Vel 1, Vel 2, Vel 3]
Healths: [Health 1, Health 2, Health 3]

    A system updating positions reads only the “Positions” array sequentially—maximizing cache usage.

    Framework Comparison

    The ECS landscape is rich with open-source frameworks in C#, C++, and Rust. Below is a static table showing relative scores (out of 10) for key criteria. Hover effects and radar charts aren’t possible here, but this table gives you the same data at a glance.

    Framework Performance API Ergonomics Feature Set Ecosystem Parallelism Debug Tools
    Unity DOTS (C#) 9 6 8 9 10 8
    EnTT (C++) 10 7 9 7 7 5
    Flecs (C++) 9 8 10 8 8 9
    Bevy ECS (Rust) 8 9 8 8 9 7

    Practical Implementations

    Theory is one thing—how does ECS apply to real-world game systems? Below are examples of Movement/Combat, AI/Behavior, Player/UI, Inventory/Crafting, and Networking. Each “card” shows which components and systems you might define in an ECS for that feature.

    Core Gameplay: Movement & Combat

    Movement/Physics System

    Components:

    • TransformComponent (pos, rot, scale)
    • VelocityComponent (linear, angular)
    • CollisionComponent (shape, material)
    • RigidBodyComponent (mass, drag)

    Systems:

    • PhysicsSystem: Detects and resolves collisions.
    • MovementSystem: Applies velocity to transform.

    Combat/Health System

    Components:

    • HealthComponent (current, max)
    • WeaponComponent (damage, range)
    • ArmorComponent (defense)
    • AttackActionComponent (tag)

    Systems:

    • CombatSystem: Resolves attacks, calculates damage.
    • HealthSystem: Applies damage/healing, checks for death.

    AI & Behavior: Decision Making & Pathfinding

    Decision Making (Behavior Tree)

    Components:

    • AIComponent (personality)
    • PerceptionComponent (sensed entities)
    • BehaviorTreeComponent (runtime state)
    • GoalComponent (current objective)

    Systems:

    • PerceptionSystem: Updates what the AI sees/hears.
    • BehaviorTreeSystem: Executes the BT logic.

    Pathfinding System

    Components:

    • PathRequestComponent (target pos)
    • PathResultComponent (waypoints)
    • MovementComponent (to follow path)

    Systems:

    • PathRequestSystem: Initiates path calculations.
    • PathFollowingSystem: Moves the entity along the path.

    Player & UI: Input & Inventory

    Input & UI Systems

    Components:

    • PlayerInputComponent (moveVector, actions)
    • (Hybrid) UI is managed by traditional OOP code, not ECS components.

    Systems:

    • InputSystem: Reads hardware and updates PlayerInputComponent.
    • UISystem: Reads ECS data (e.g., Health) and updates traditional UI elements.

    Inventory & Crafting Systems

    Components:

    • InventoryComponent (item list, capacity)
    • ItemComponent (itemID, stackSize)
    • CraftingRecipeComponent (ingredients, output)

    Systems:

    • InventorySystem: Adds/removes items from inventory.
    • CraftingSystem: Checks recipes and inventory, then crafts items.

    Networking: Synchronization & Prediction

    Synchronization System

    Components:

    • NetworkIDComponent (unique across network)
    • SynchronizedComponent (tags data to be sent)

    Systems:

    • StateSnapshotSystem (Server): Captures state of synced entities.
    • StateApplySystem (Client): Applies snapshots to remote entities (with interpolation).

    Client Prediction & Reconciliation

    Components:

    • InputHistoryComponent (client-side buffer)
    • PredictedGhostComponent (for predicted entities)

    Systems:

    • ClientPredictionSystem: Runs player logic immediately on the client.
    • ServerReconciliationSystem: Corrects local state once the server’s authoritative update arrives.