Skip to content
GDCraft voxel cubeGDCraft Wiki

GDCraft Implementation Wiki

GDCraft is an educational Minecraft-inspired voxel game built with Godot 4.7 and C#. This wiki explains the implementation as it exists in this repository and links each concept back to its owner in src/.

Use the wiki in three ways: follow the runtime path to understand the whole game, open a subsystem guide before changing code, or use the architecture maps and project roadmap to understand how systems fit together. The expanded guides cover inventory and crafting, item stacks, entity simulation, physics, and registries alongside the voxel engine. Claims about behavior should be checked against the current source: the project changes quickly and the roadmap records known gaps.

Read the runtime map

Start at scenes/Main.tscn and trace how the client creates a world, player, and gameplay systems.

Understand the voxel engine

Learn how blocks, sections, chunks, meshes, lighting, and world generation cooperate.

Extend a subsystem

Follow the project’s ownership rules for blocks, entities, items, world systems, and UI.

Track fidelity and work

Use the porting plan, curriculum, and fidelity ledger to understand priorities and known differences.

New to GDCraft?

Section titled “New to GDCraft?”

Start with running the source build, then create a first world. Keep the controls and HUD guide nearby during your first session.

Wiki map

Section titled “Wiki map”
  • Start here: runtime map, repository map, project conventions.
  • Visual code map: search for source types and follow curated ownership and data-flow links.
  • Core systems: voxel data, blocks and state, chunk rendering, lighting, world generation, ticking, entities, items and persistence, player and UI.
  • Gameplay foundations: inventory and crafting, items and stacks, entity simulation, physics and collision, and registries and tags.
  • Developer workflow: set up the project, find feature ownership, make a focused change, and validate it.
  • Reference: architecture glossary, fidelity status, learning roadmap, source map.

Ground rules

Section titled “Ground rules”
  • Read the repository guide before implementation; it defines the project’s architecture and asset constraints.
  • Keep behavior with its domain owner. Blocks own block behavior; biomes compose generation pieces; managers coordinate lifecycle and storage.
  • Treat docs/CURRICULUM.md, docs/PORTING_PLAN.md, and docs/FIDELITY_LEDGER.md as living project records, not substitutes for checking code.
  • This wiki documents the implementation; it does not imply that every Minecraft system is complete or behavior-identical.