Entities, player, and interface
Entities
Section titled “Entities”Entity and mob implementations live primarily in src/Entity/, with block entities under src/World/. A block entity owns persistent or ticking state attached to one block position; an entity represents a moving or independently spawned actor. Check the scene and serialized references along with C# inheritance when changing either.
The porting plan documents a major architecture gap: GDCraft does not yet have the full shared Entity → LivingEntity → Mob hierarchy used by Minecraft. Movement units, rotation conventions, collision, and persistence therefore need careful auditing at each boundary.
More specifically, the source-style Entity : Node3D path and current LivingMob : CharacterBody3D path are distinct today. Mob adds goal selection, attributes, controls, and navigation on the latter path. A behavior implemented on Entity should not be assumed to affect every existing mob until that migration is complete. See entity simulation and AI.
Player systems
Section titled “Player systems”The player controller coordinates input and engine movement; specialized classes handle block interaction, inventory, and related actions. Keep action rules near their owner and trace both keyboard/mouse input and the caller that mutates world state. Before altering movement, compare the relevant Minecraft travel method and confirm the unit conversions used by Godot physics.
Menus, screens, HUD widgets, and game-facing presentation belong under src/UI/. UI should read model state and issue actions through the owning gameplay APIs. Keep reusable layout/presentation separate from simulation rules. Existing Minecraft GUI assets and bitmap font conventions are already in the repository.
Saving and loading
Section titled “Saving and loading”World and player persistence is coordinated by storage/serialization types rather than by rendering code. Trace a value from runtime owner through serialization and back during load. Any new entity, block entity, or item data must be checked for round-trip persistence; the fidelity ledger lists several remaining component-data gaps.
Inventory and item ownership
Section titled “Inventory and item ownership”Inventory state is not UI state. Containers own the stacks, menu slots express interaction policy, and UI controls present the menu. Item definitions and per-stack data also have separate owners. Read inventory and crafting and items and item stacks before adding a new workstation, item interaction, or stack field.