engine_agnostic_architecture

Separate Godot-specific code from pure Core ECS logic in .NET 8 projects.

2|Updated Jul 2, 2026
One-click install
npx skills add https://github.com/Xyrces/godot-ecs-gamedev-playbook --skill engine-agnostic-architecture
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: engine_agnostic_architecture
Source: https://github.com/Xyrces/godot-ecs-gamedev-playbook/tree/main/skills/engine_agnostic_architecture
Command: npx skills add https://github.com/Xyrces/godot-ecs-gamedev-playbook --skill engine-agnostic-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents engine code from leaking into your game logic by enforcing a strict separation between a pure C# Core and a Godot-specific Client, making ECS gameplay easier to test, maintain, and scale.

Core Features & Use Cases

  • Assembly Boundary Enforcement: Keeps Core free of Godot references through project structure and dependency rules.
  • Dependency Inversion: Uses interfaces in Core and engine implementations in Client for audio, input, logging, and other platform services.
  • SyncBridge Pattern: Maps ECS state to Godot nodes for rendering, animation, and scene updates without mixing responsibilities.
  • Architecture Tests: Validates that Core remains engine-agnostic and catches accidental leakage early in CI.
  • Use Case: Ideal for building a .NET 8 and Godot 4.x game where simulation, AI, and world state stay pure while presentation and I/O remain engine-specific.

Quick Start

Ask the AI to audit your Godot ECS project and rewrite the architecture so Core stays pure C# while Client handles all Godot-specific rendering, input, audio, and scene synchronization.

Frequently Asked Questions about engine_agnostic_architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep Godot code from leaking into my C# ECS game logic?

To keep Godot code out of your C# ECS game logic, enforce strict assembly boundaries that separate a pure Core from a Godot-specific Client, using dependency inversion and architecture tests to prevent engine type leakage.

What's the best way to separate Godot rendering from pure ECS simulation in .NET 8?

The best way to separate Godot rendering from pure ECS simulation is using a SyncBridge pattern that maps ECS state to Godot nodes for rendering and scene updates, ensuring presentation and I/O remain engine-specific while simulation stays pure.

Can I use dependency inversion to keep audio and input platform-agnostic in Godot 4.x?

Yes, you can keep audio and input platform-agnostic in Godot 4.x by defining service interfaces in your pure Core and implementing those engine-specific adapters in the Client layer using dependency inversion.

How do architecture tests validate that my Core assembly is engine-agnostic?

Architecture tests validate an engine-agnostic Core assembly by checking dependency rules across gameplay, input, audio, and rendering layers, ensuring the Core remains free of Godot types and catching accidental leakage early in CI.

Do I need .NET 8 and Godot 4.x to enforce engine-agnostic architecture boundaries?

Yes, this engine-agnostic architecture enforcement applies to .NET 8 and Godot 4.x projects, requiring project structures that support strict assembly boundaries between pure C# Core logic and engine-specific Client implementations.

Why does my ECS state synchronization with Godot nodes keep mixing responsibilities?

ECS state synchronization with Godot nodes mixes responsibilities when SyncBridge adapters are not properly enforced, causing Core simulation, AI, and world state to tangle with presentation and I/O engine-specific code.