chobotov/yohoho-test

1. Project type and shape

- This is a Unity 2022.3 mobile game project built around a small gameplay loop: move a player with a touch joystick, pick up items into a stack, and drop them into a release zone.

- The codebase is split cleanly between game-specific source under Assets/_src and imported dependencies/assets under Assets/Plugins and Assets/Imported Assets.

2. Main runtime entry and scene flow

- The project uses two main scenes: Entry Point.unity and Game.unity.

- AppController plus the lifetime-scope classes (AppLifetimeScope, GameLifetimeScope) appear to handle bootstrap and scene-level composition.

- EcsStartup is the likely bridge that initializes the ECS world/systems for the game scene.

3. Core gameplay architecture: ECS-first

- The game logic is organized into an ECS layer under Assets/_src/5 - Scripts/Runtime/Ecs.

- Data is split into components such as input, movement, rotation, unit, item, inventory, level, pickup, and drop.

- Behavior is split into systems that operate on those components rather than directly coupling objects together.

4. Input subsystem

- Touch control is handled by a joystick asset imported under Assets/Imported Assets/Joystick Pack.

- InputSystem converts player input into ECS-side input state/events, likely represented by InputEvent.

- This isolates platform-specific UI input from the gameplay logic.

5. Movement and orientation pipeline

- Movement is decomposed into separate ECS concerns:

- MoveVelocitySystem derives velocity,

- MoveSystem applies positional movement,

- RotationSystem handles facing direction,

- AnimatorSystem syncs animation with motion state.

- This separation makes the player controller easy to extend without putting all behavior into one script.

6. Stack / inventory gameplay

- The stack mechanic is represented by inventory-related components and runtime model classes:

- InventoryComponent in ECS,

- UnitInventory and Item in game domain classes.

- Pickup and drop flows are handled by dedicated systems:

- PickupItemDistanceSystem and DropZoneDistanceSystem decide eligibility,

- PickupItemSystem and DropItemSystem perform the actual transfer of items.

- This is the main gameplay loop boundary: proximity detection first, state mutation second.

7. Item generation and level content

- CreateItemSystem is the generator feature described in the README: items are produced on a timer.

- Level content is driven by LevelsConfig, ItemsConfig, and PlayerConfig assets under Assets/_src/2 - Data/Configs.

- CreateLevelSystem and CreateUnitSystem likely instantiate the level and player entities from those configs.

8. Game-domain factories and views

- LevelFactory, PlayerFactory, and ItemsFactory sit between the ECS/domain layer and Unity prefabs.

- View-facing classes like LevelView and UnitView represent the scene objects that ECS/entities are bound to.

- Prefabs in Assets/_src/3 - Prefabs provide the concrete Unity objects for the app controller, game level, player, and item stack.

9. Services and cross-cutting state

- LevelService and ScoreService are domain services, each with an interface and implementation.

- These services likely hold shared progression/state that is not purely entity-local, such as current level or score.

- GameState suggests a small runtime state container for overarching game status.

10. UI boundary

- MainCanvas is the primary UI root under Assets/_src/5 - Scripts/Runtime/UI.

- The README mentions a “minimal UI” for stack display, so UI is intentionally lightweight and probably reflects inventory/stack state rather than driving gameplay.

- Text rendering uses TextMesh Pro, imported as a standard Unity package asset set.

11. Imported libraries and why they matter

- UniTask is included and likely used for async flows such as timing, initialization, or scene/bootstrap sequencing.

- UniRx is also present, indicating reactive patterns may be used for UI binding, events, or state observation.

- These packages shape the architecture by reducing callback-heavy Unity code and making state propagation more declarative.

12. Visual/content assets are decoupled from gameplay code

- The repository contains large imported art packs: stickman character animations, a town environment pack, joystick UI assets, and TextMesh Pro resources.

- These are treated as external content, while the gameplay code in _src stays focused on logic and orchestration.

- For an architecture diagram, this is a useful boundary: game systems consume prefab/model/config assets, but do not own them.

13. Editor and assembly boundaries

- The codebase uses .asmdef files, separating runtime and editor code into distinct compilation units.

- There is an editor assembly for the joystick pack and a game editor assembly (YohohoEditor.asmdef), which helps isolate tooling from runtime gameplay.

- This supports faster iteration and clearer dependency direction.

14. Overall data flow

- Input comes from the joystick UI → becomes ECS input state → drives movement/rotation systems → player collides or reaches item zones → pickup/drop systems mutate inventory/stack state → UI and animation reflect the updated state.

- Separately, the level/item creation systems spawn content on timers or startup, feeding the same inventory loop.

- The architecture is therefore a scene/bootstrap layer + ECS gameplay core + prefab/config/view boundary, with imported assets feeding presentation and control.