This page defines the practical scope of this repository for cub3D: what
belongs to the mandatory baseline, what is implemented as bonus work, and what
is intentionally outside the repository contract.
Project scope
The repository scope is split between the evaluated mandatory baseline, implemented bonus systems, and explicit non-goals
This section clarifies what the baseline engine must guarantee, which bonus layers are implemented here, and which expectations stay outside the repository contract.
01 Mandatory, bonus, and out-of-scope areas The three-way split matters because the codebase documents both the grading baseline and the optional extensions without pretending everything belongs to the same evaluation target.
Mandatory
.cub parsing texture headers, color headers, and map storage
map validation accepted characters, single spawn, enclosed layout
MLX init window, frame image, and mandatory textures
movement + collision first-person movement with wall blocking
DDA raycasting one ray per column and projected wall slices
directional textures north, south, west, east wall sampling
floor / ceiling color-driven background rendering from `F` and `C`
exit + cleanup close handling, error exits, and resource teardown
Bonus
retro render bonus output image, minimap buffer, and presentation path
minimap + zoom 2D navigation overlay and visibility context
interactive doors door entities with runtime state and passability
pickups + stats HP, armor, ammo, score, and collection state
HUD overlay status panels and bonus presentation layers
sprite pipeline runtime sprite registration, sorting, and projection
level flow bonus map sequencing and reload progression
extra input mouse look and bonus-only interactions
Out of Scope
bonus is not required for mandatory grading baseline evaluation does not depend on optional systems
headless graphics are not guaranteed `mlx_init` still depends on a working graphical environment
optional bonus assets may vary repository behavior can depend on actual runtime asset availability
gameplay balancing is not a core baseline criterion bonus tuning remains secondary to engine correctness
this guide is not a generic subject PDF mirror it documents this repository rather than every possible cub3D variant
02 Implementation notes These notes explain how the repository keeps mandatory behavior stable while still exposing shared bonus integration points.
srcs/ vs srcs_bonus/ mandatory and bonus source groups stay separated even though some runtime integration points are shared
no-op fallbacks shared bonus-facing calls can exist without breaking the mandatory build because compatibility stubs are linked in baseline mode
scope of this guide pages track the repository state rather than aspirational or unfinished feature claims
✓ Scope invariant Mandatory behavior must remain valid even when bonus code exists in the repository.
The mandatory path stays compilable and functionally valid even though the repository still exposes shared bonus-facing hooks and compatibility layers. Bonus systems extend the repository, but they do not redefine the minimum contract the baseline implementation is expected to satisfy.
The mandatory baseline covers parsing, map validation, MLX initialization,
movement and collision, DDA raycasting, directional wall textures,
floor/ceiling rendering, and proper cleanup on exit or failure.
The bonus side of this repository extends the baseline with systems such as
retro rendering, minimap, doors, pickups, HUD, sprites, level progression, and
extra input handling.
Some behaviors remain environment-dependent or explicitly outside the evaluated
baseline: graphical runtime availability, optional bonus assets, and gameplay
balancing beyond core engine correctness.
The repository also keeps some shared integration points between the mandatory
and bonus paths, so the baseline remains valid without being fully isolated from
bonus-aware compatibility code.