Skip to content

Coding Standards

Authoritative Style Guide

Andromeda follows Epic's C++ Coding Standard for Unreal Engine 5.7:

https://dev.epicgames.com/documentation/unreal-engine/epic-cplusplus-coding-standard-for-unreal-engine?application_version=5.7

When local preferences conflict with Epic's Unreal C++ style, prefer Epic's standard unless there is a documented project-specific reason to differ.

Formatting

The repository root .clang-format file is the shared mechanical formatter for C++ source. Configure Rider, Visual Studio, VS Code, or command-line tooling to use .clang-format for C++ formatting instead of IDE-specific project code-style rules.

The formatter intentionally covers only whitespace, wrapping, braces, indentation, and include ordering. Epic's Unreal C++ standard remains authoritative for rules that a formatter cannot enforce, such as Unreal type prefixes, reflected-property design, Blueprint exposure, ownership boundaries, and API shape.

The config enables include sorting. Unreal reflected headers must keep their matching .generated.h include last; the include categories in .clang-format reserve the final include group for generated headers. When changing include formatting rules, verify representative UCLASS, USTRUCT, and UINTERFACE headers before formatting the full source tree.

Prefer formatting source changes in focused commits. If the whole Source/Andromeda tree is reformatted, keep that as a formatting-only commit so gameplay diffs stay readable.

Static Analysis

The repository root .clang-tidy file is the shared static-analysis policy for project C++ code. It intentionally starts with a conservative Unreal-friendly rule set: bug-prone code, Clang static analyzer checks, portability, performance, and selected low-noise modernization/readability checks. Do not enable broad generic style checks unless they have been tested against Unreal reflection macros and Epic naming conventions.

Use Rider's Clang-Tidy integration as the primary runner. Enable it in Rider under Settings -> Languages & Frameworks -> C++ -> Clang-Tidy; Rider will pick up the repository .clang-tidy configuration. Treat findings as advisory until the current baseline has been reviewed.

compile_commands.json is not required for the Rider workflow. Add compile database generation only if the project later needs command-line clang-tidy, clangd, or CI linting.

Architecture Principle

Use this split:

C++ defines the rules. Blueprints define content and presentation. Data assets define salvage data.

This keeps core behavior maintainable while leaving Unreal content iteration fast.

C++ Responsibilities

Use C++ for:

  • interaction and capability interfaces
  • salvage item data structures
  • scanner logic
  • station, placement, and workstation gameplay rules
  • save/load systems
  • consequence/event systems
  • shared gameplay contracts

Blueprint Responsibilities

Use Blueprints for:

  • actor setup and content variants
  • level composition
  • widget layout and styling
  • asset references
  • presentation-only hooks such as one-off animation, audio, or VFX triggers
  • animation timelines when they are presentation-only

Avoid Blueprint Event Graphs for core gameplay and UI behavior. For the vertical slice, widget behavior is C++ owned:

  • C++ populates prompt, scan, and result widgets.
  • C++ handles processing-result UI buttons.
  • C++ handles input-mode transitions while UI is open.
  • Widget Blueprints provide named Designer widgets through BindWidget/BindWidgetOptional.

Do not put core game rules, scanner decisions, processing outcomes, or primary UI data binding only in Blueprint graphs.

Use Blueprint presentation hooks sparingly when the C++ system explicitly exposes one.

Previous broader Blueprint uses such as:

  • animation timelines
  • quick prototype wiring

are acceptable for temporary experiments, but should be migrated to C++ once they become part of the maintained vertical slice.

Data Responsibilities

Use Data Assets or Data Tables for:

  • salvage item metadata
  • manifest claims
  • scan profiles
  • legal handling rules
  • payouts
  • consequences
  • story flags

The first implementation may use a simple data model, but it should be shaped so more salvage items can be added without rewriting scanner logic.

Naming

Project C++ types should use the Andromeda prefix when they are game-specific:

  • IAndromedaInteractableInterface
  • AAndromedaSalvageItem
  • AAndromedaScannerWorkstation
  • UAndromedaSalvageItemData
  • FAndromedaScanProfile
  • FAndromedaPackageRequirement

Avoid generic names such as UInteractionComponent unless the code is truly engine/plugin-generic.

Content assets live under Content/Andromeda, so asset names do not need to repeat Andromeda unless it improves search clarity. Prefer role names:

  • BP_PlayerCharacter
  • BP_PlayerController
  • BP_SalvageBayGameMode
  • BP_ScannerWorkstation
  • WBP_ScannerScreen
  • DA_DamagedReactorCoil

Use L_ for level assets. Reserve M_ for materials.

Scope Control

Prefer small systems with clean extension points over large speculative frameworks.

Do not build:

  • inventory complexity before the slice needs it
  • faction systems before item consequences need them
  • procedural generation before authored items work
  • runtime AI NPC systems for the MVP
  • combat systems

Code Quality

Expected standards:

  • clear ownership of gameplay state
  • minimal global state
  • no throwaway level-only rules for core gameplay
  • small functions with explicit names
  • comments only where they clarify non-obvious intent
  • editor-exposed properties grouped with useful categories
  • Blueprint-callable APIs only where presentation or content wiring needs them

Testing and Verification

For early Unreal work, verification is mostly compile and in-editor play testing.

Before committing gameplay code:

  • compile the project
  • check editor startup
  • run a short play-in-editor test
  • verify logs for relevant errors
  • confirm generated files are not staged