victor-wybenga/culminating-game

1. This is a Godot 2D factory-puzzle game. The repository is organized around three main layers: data assets in Resources/, reusable scene prefabs in Scenes/, and gameplay logic in Scripts/. That separation is the key to the architecture.

2. The game is heavily data-driven. Resources/Items, Resources/Recipes, Resources/Machines, and Resources/Tiles contain .tres definitions for all craftables, machine types, floor tiles, and recipe variants. These are the authoritative game definitions; the scenes and scripts appear to consume them rather than hardcoding content.

3. There are generic resource templates in Resources/Templates for core object types such as assembler, belt, power source, and recipe. This suggests a composition pattern: specific content like “Smelter” or “coalGen” is built from shared resource schemas, not bespoke logic per item.

4. The scene hierarchy is split between world content and menus. Scenes/Levels/* contains individual level scenes, while Scenes/machines/, Scenes/placeables/, and top-level scenes like belt.tscn, goalpost.tscn, miner.tscn, recipeMenu.tscn, and ui.tscn provide reusable in-game objects and interface panels. main.tscn, main_menu.tscn, level_selector.tscn, and end_screen.tscn handle the meta flow.

5. Core simulation logic lives in a small set of controllers. mapController.gd, buildingManager.gd, beltController.gd, powerManager.gd, and machines.gd likely coordinate placement, grid occupancy, item movement, power distribution, and machine behavior. These are the backbone systems that other entities plug into.

6. Item transport is modeled separately from machines. beltItem.gd, beltController.gd, Scenes/placeables/belt.tscn, and Scenes/spliter.tscn indicate a conveyor network where items are entities moving along belts and through splitters. This is a distinct data flow from machine processing: output items leave machines, enter belts, then get routed to other inputs or goals.

7. Production buildings are specialized but probably share common interfaces. miner.gd, generators.gd, powerPoles.gd, and the machine scenes for assembler, smelter, and coal generator imply multiple machine categories: extractors, processors, and power infrastructure. The README confirms the intended progression from simple miners/smelters to more complex fluid- and byproduct-based machines.

8. Power is a separate network subsystem rather than just another item chain. The presence of powerManager.gd, powerPoles.gd, GenericPowerSource.tres, and coalGen.tres suggests a graph or coverage model where generators feed consumers through poles. The README also frames power as a bottleneck that becomes more complex in later tiers.

9. Level objectives are explicit gameplay nodes. goalpost.gd, Scenes/goalpost.tscn, and the README’s “submit a certain amount of items/power” mechanic indicate that levels end by delivering required outputs to a goal structure. level_1.tscn through level_5.tscn and the “level selector” scene show a progression-based campaign structure.

10. The UI layer handles selection, recipes, and configuration. recipeSelectorMenu.gd, make_panel_buttons.gd, make_level_buttons.gd, ui_button.gd, rotate_button.gd, options_page.gd, and ui.tscn support in-game build menus, level selection, and settings. The README’s planned glossary/recipe book fits this same interface layer.

11. The player is a placement-and-management actor rather than a combat unit. player.gd and the build-related scenes suggest a character that moves around, places machines, and interacts with menus. This means the main loop is about layout optimization and routing, not action gameplay.

12. The repository also includes content-production assets: Assets/2d Assets/* for sprites and animations, plus buildings and recipes.pdf as design reference material. Those files are support artifacts for the game’s content pipeline, not runtime systems.

13. Architecturally, the important boundaries are: content definitions in .tres resources, scene prefabs in .tscn, and runtime orchestration in .gd scripts. If you draw the system, the data flows should show resources feeding scenes, scenes instantiating world objects, and controllers moving items/power between machines and level goals.