C++ & Blueprint Guidelines

Canonical GDD content

C++ is primary; Blueprint is allowed where it is the right tool — [CONFIRMED]. This document defines the division of responsibility so the codebase stays performant, networkable, and maintainable.

Guiding principle

Systems, authority, and data structures in C++. Content, configuration, presentation, and designer iteration in Blueprint (or data assets). Networked/authoritative logic is always C++.

Use C++ for

• Core gameplay framework: GameMode, GameState, PlayerController, PlayerState, GameInstance, subsystems.
• Character and all gameplay components (survival, inventory, equipment, combat, build, interaction, crafting).
• Anything server-authoritative or replicated — combat/damage, inventory mutation, building placement/commit, loot, AI decisions, persistence.
• Networking-critical and performance-critical code (replication, hit validation, AI ticking, large data handling).
• Data type definitions (USTRUCT/UENUM, UDataAsset base classes).
• The persistence/save layer.

Use Blueprint for

• UMG / UI — HUD, menus, inventory screens, build UI (bind to replicated C++ state).
• Animation Blueprints — anim graph/state machine consuming C++/replicated state.
• Designer-facing tuning via Blueprint subclasses of C++ classes (set meshes, default values, references).
• Content composition — placing components, wiring up cosmetic/visual behavior, simple non-authoritative VFX/SFX triggers.
• Rapid prototyping — prototype in BP, then port proven, hot, or networked logic to C++.

The "C++ base, Blueprint child" pattern

Standard UE best practice and the default here: - Implement the class and its logic in C++ (UCLASS(Blueprintable)), exposing tunables with UPROPERTY(EditAnywhere/BlueprintReadWrite) and hooks with UFUNCTION(BlueprintCallable) / BlueprintImplementableEvent / BlueprintNativeEvent. - Create a Blueprint child (e.g., BP_PlayerCharacter from ALambeerCharacter) to assign content (mesh, anim BP, data assets) and designer values. - This keeps logic versionable/diffable in code while letting designers iterate on content without recompiling.

Data-driven design (avoid hard-coding)

• Items, weapons, recipes, building pieces, zombie/boss stats, loot tables, tuning curves → DataAssets / DataTables / Curves, not bespoke classes or magic numbers.
• Adding content (a new weapon, a new zombie type, a new recipe) should be data work, not engineering work, wherever possible.

Replication rules

• Mark replicated properties explicitly; implement GetLifetimeReplicatedProps.
• Use RPCs correctly: Server (validated, client→server requests), Multicast/NetMulticast (server→all, for effects), Client (server→one).
• Never trust the client for authoritative outcomes — validate on the server. (Critical for full-loot/raid integrity.)
• Replicate owner-only where data is private/large (e.g., inventory).

Coding conventions — [RECOMMENDATION]

• Follow Epic's C++ coding standard (prefixes: A actors, U UObjects/components, F structs, E enums, I interfaces; b for bools).
• Module/folder organization by feature (see 04-Source-Code-Structure.md).
• Keep ALambeerCharacter thin — behavior lives in components.
• Comment the why (non-obvious constraints, replication intent), not the what.

Anti-patterns to avoid

• Authoritative gameplay logic in Blueprint (cheatable, hard to diff, hard to optimize).
• Tick-heavy Blueprint for things that run every frame for many actors.
• One unique class per item/weapon/recipe instead of data-driving.
• Casting-heavy Blueprint spaghetti across systems — prefer C++ interfaces and components.