rrrrbit/blitz_

1. Project shape

- This is a Unity 2D endless runner with a strong separation between scene flow, gameplay runtime, world entities, and UI/menu presentation.

- The repo is content-heavy: most of the architecture is expressed through prefabs, ScriptableObject-like assets, shader graphs, and scene setup, with code acting as orchestration.

2. Scene boundary

- There are two main runtime scenes: menu_main.unity and game.unity.

- The menu scene owns title/menu interactions and transitions into the game scene; the game scene contains the core runner loop, world generation, player control, HUD, and effects.

3. Core game runtime

- The central gameplay layer lives in the Assets/Scripts/ root with classes named GAME, GAME_manager, GAME_globalData, GAME_objManager, GLOBAL, CAMERA, GLOW, and GAME_vfx.

- This suggests a manager-driven architecture: a global state layer, a gameplay state/controller, an object manager for spawned entities, a camera controller, and a VFX coordination layer.

4. Player subsystem

- Player behavior is split into movement, animation, and attack/action concerns:

- PLAYER_baseMvt.cs

- PLAYER_anim.cs

- PLAYER_slash.cs

- Trajectory.cs

- This indicates the player is not a monolith; input likely flows into movement/attack logic, which then triggers animation and slash trajectory visuals.

5. Input layer

- InputSystem_Actions.inputactions and the generated InputSystem_Actions.cs show the project uses Unity’s new Input System.

- Input is therefore a dedicated subsystem rather than ad hoc polling, which matters for diagramming because it sits between player control and gameplay state.

6. World object model

- The Assets/Scripts/World/ folder contains the entity layer:

- base types: GAME_obj.cs, GAME_objType.cs, GAME_relativeParticles.cs

- interactable hierarchy: Interactable.cs, Destructible.cs, OBJ_node.cs, OBJ_proxy.cs, OBJ_relay.cs, OBJ_burst.cs, OBJ_window.cs, OBJ_empty.cs

- The repo also includes corresponding content assets under Assets/Prefabs/entries/ and prefabs like node.prefab, relay.prefab, proxy.prefab, burst.prefab, window.prefab.

- This suggests a template-driven entity system where gameplay objects are instantiated from predefined archetypes and then handled through shared interaction/destruction logic.

7. World generation and background

- Background and stage ambience are handled separately from interactable objects:

- BG_spawns.cs

- World/bg objs/* such as BG_grid, BG_lattice, BG_stripe, BG_window

- matching prefabs in Assets/Prefabs/bg Elements/

- That separation implies the endless-runner environment is composed of spawned scenic layers and gameplay-relevant obstacles/entities, likely with independent spawning rules.

8. UI and menu system

- Menu/HUD code lives in Assets/Scripts/MENUandUI/:

- MENU_main.cs, MENU_death.cs, MENU_info.cs

- HUD.cs

- UI effects: UI_fadeOut, UI_flickerImage, UI_flickerTextIn, UI_textBtn, UI_plugButton, Flicker

- The UI is therefore a distinct presentation layer with its own animation/effect scripts, rather than being embedded in gameplay logic.

9. Visual style and rendering

- The project uses URP 2D and is visually shader-driven:

- URP settings assets and 2D renderer assets

- Shader Graph assets like glow.shadergraph, glitch.shadergraph, bgGrid.shadergraph, lattice.shadergraph, squashShear.shadergraph

- materials like glow.mat, glitch.mat

- Visual effects are not just post-processing; they are part of the gameplay identity through glowing/glitching UI, stylized background elements, and object-specific materials.

10. Animation and particle effects

- There are dedicated animation assets (slash.anim, animator controller) and particle prefabs (nodeParticle, relayParticle, burstParticle).

- This indicates a layered presentation pipeline: game events trigger animation and VFX, which are managed separately from the underlying gameplay state.

11. Data/configuration assets

- The repo includes build profiles (itch.asset, windows.asset), a physics material (playerpmat.physicsMaterial2D), a volume profile, render pipeline assets, fonts, TMP resources, and scene templates.

- These are important to diagram as the configuration/infrastructure layer supporting the runtime, especially since the project depends heavily on author-time Unity assets.

12. Likely runtime flow

- At a high level: menu scene → game scene → input-driven player actions → manager/world spawning logic → interactable object resolution → VFX/UI feedback → death/menu loop.

- The main architectural boundary is between state/control systems (GAME_*, GLOBAL, player controllers) and content instances (prefabs, object entries, background elements, UI prefabs).

13. What to emphasize in an architecture diagram

- Draw separate boxes for Menu/UI, Game Runtime, Player Controller, World/Object System, Background Spawner, and Rendering/VFX.

- Show Unity scene assets as the top-level composition units and prefabs/ScriptableObject-like entries as the content definitions feeding the runtime.