metaheavens/spaceship
Watch
1
0
Fork
You've already forked spaceship
 0
Code Issues 4 Pull requests Projects 1 Releases Packages Wiki Activity
spaceship/buildings/BuildingDefinitions.gd

26 lines
1.4 KiB
GDScript3
Raw Normal View History

#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
class_name BuildingDefinitions
extends RefCounted
Add planet scanner and octopus biome
2026-09-04 15:56:07 +02:00
const ORDER: PackedStringArray = ["mothership", "ship_crafter", "command_center", "outpost", "planning_center", "spacial_workshop", "planet_scanner", "extractor", "transport_hub", "ship_lab", "gas_burner"]
#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
const DEFINITIONS: Dictionary = {
"mothership": preload("res://buildings/MothershipBuildingDefinition.tres"),
"ship_crafter": preload("res://buildings/CrafterBuildingDefinition.tres"),
"command_center": preload("res://buildings/CommandBuildingDefinition.tres"),
#102/#103 (#97d/#97e): the outpost, and the garrison you compose for it Landed together because an outpost you cannot crew is decoration, and a garrison menu with no building to hang it off is nothing at all. #102, the building. Researched at "Forward Bases", two prerequisites deep and cheaper than any mid-game structure - the ticket asks for early, and the answer to waves attacking your buildings should arrive at about the time the waves can hurt them. It is drawn as a watch mast on a tripod with two open berths, deliberately the least machinery of any structure here: it makes nothing and refines nothing, it holds a position. 120hp, more than a crafter, because being shot at is its job. #103, the garrison. Two separate things live on its record, and conflating them was the first thing to get wrong: the ORDER, what the player asked for, and the CREW, who is actually there. This menu edits the order only; #104 fills the crew. Keeping the order as a wish is what lets an outpost ask for a hull nobody has built yet and wait for it, rather than the request evaporating - and it is why the panel shows "here / ordered" instead of one number. "Only ships that attack can be assigned" is expressed as capabilities rather than a list of types, so a new armed vessel is eligible the day it is added and an unarmed one never is by accident. Today that means the interceptor and the laser vessel; a shield, a hauler and an engine block cannot hold a position however much one might want them to. Two berths by default, and Garrison Bays raises it at outposts ALREADY standing - the same shape as freight_yards for hubs, because a bonus that only reached new buildings would mean demolishing and rebuilding to collect it. The panel builds its own rows from the catalog rather than from nodes placed in the scene, so adding an armed vessel later needs no scene surgery. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:02:20 +02:00
"outpost": preload("res://buildings/OutpostBuildingDefinition.tres"),
#106/#107 (#98a/#98b): the Planning Center Landed together: a board of standing orders nothing acts on is a notepad, and a planner with nowhere to read the plan from has nothing to do. The targets are GLOBAL, not per building. There is one plan for the whole game, and a second planning centre is another place to read and edit it rather than a competing one - per-building targets would let two centres hold contradictory orders and tell the crafters to satisfy both. The census is the harder half. Every vessel is counted exactly once wherever it happens to be: flying in the fleet, parked in the hangar, stationed at an outpost, or in the air between any two of those. Miss the in-flight ones and the planner queues a replacement for a vessel that is merely en route. The fleet is the one place GameState cannot see, so Fleet pushes its composition on every change, alongside the cargo capacity and distorder count that already went that way. Three rules keep the planner from fighting the player. It tops up and never rewrites, so an order placed by hand stays exactly where it is. Everything counts, including what is already queued, or it re-queues the same shortfall every tick and buries the player in hulls. And nothing happens without a planning centre - though the plan is remembered when one is destroyed, so rebuilding picks up where it left off. Vessels on order are counted separately from the census on purpose: they do not exist yet, so the readout can say "4 of 6, 2 building" rather than claiming six. The per-row note says where the vessels actually are, because a plan can look unmet while everything it asked for is sitting at an outpost. The build menu goes to three columns past eight entries. #54 already tightened its rows to 223px to fit a fourth, explicitly to avoid a scrollable menu, and a ninth structure needs a fifth row that will not fit at any spacing a button, a label and a cost can share. Three columns take nine into three rows - fewer than it uses today, not more. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 14:21:52 +02:00
"planning_center": preload("res://buildings/PlanningBuildingDefinition.tres"),
#116: the Spacial Workshop, and the drones that mend what waves break Modelled on the transport hub, deliberately and closely: drones belong to a workshop rather than to the player, are provisioned when it is built, are never a production order, and are upgraded at a ship lab like any other vessel. Anything that already knows how hub transporters behave knows how these do, and Drone Bays raises the count at workshops already standing - the same shape as Freight Yards and Garrison Bays. What a repair COSTS is the one new idea. It is a share of the building's own price, in proportion to how much of its health is gone: levelling a crafter and rebuilding it costs its full price, and patching one up after a wave costs a fraction, the fraction being the damage. The ore is spent when a drone LEAVES, so two drones cannot be sent to the same wall and spend twice for one load of repair, and a building demolished in transit sends its load home rather than swallowing it. "Required resources are sent to the spacial workshop": the workshop asks hub logistics for the ore its outstanding repairs will need, exactly as a gas burner asks for gas, because building_logistics_deficit now takes the larger of the definition's static buffer and what the world actually demands. There is a ceiling on that, so one badly-mauled base cannot pull the whole bank into a single workshop and starve everything else. Worst first: the structure closest to coming down is the one a repair is worth most on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-23 21:59:51 +02:00
"spacial_workshop": preload("res://buildings/WorkshopBuildingDefinition.tres"),
Add planet scanner and octopus biome
2026-09-04 15:56:07 +02:00
"planet_scanner": preload("res://buildings/ScannerBuildingDefinition.tres"),
#84: move 215 root files into a folder hierarchy Everything lived in one flat directory, so a diff gave no clue what area it touched and finding the file you wanted meant knowing its exact name. Twelve folders now, grouped by what a thing IS rather than what type it is - a vessel's definition, its component scenes and its upgrade resources sit together, because that is the set you read when you change one of them. buildings core controllers enemies logistics planets resources shaders surface ui vessels vfx world 332 files moved and every res:// reference rewritten - 306 files touched, including the autoload and main-scene paths in project.godot. Nothing renamed: this is purely where files sit, so the diff is a pile of pure moves and no behaviour is buried in it. ui_theme.tres, icon.svg and web_shell.html stay at the root, where Godot and the export preset expect them. Verified three ways, because a suite alone would not have caught all of it: the full 117 pass, the web export builds clean, and the game renders. The export is why that matters. The FIRST export after the move failed with "Attempt to open script 'res://GameState.gd'" - the old path - while project.godot on disk plainly said res://core/GameState.gd. That is this project's documented Android FUSE mtime trap: Godot served a cached copy of a file whose content had changed. A `touch` fixed it. Nothing in the test suite would have found that, because the suite runs from a copy on a native filesystem - the one place the bug cannot happen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-21 19:44:14 +02:00
"extractor": preload("res://buildings/ExtractorBuildingDefinition.tres"),
"transport_hub": preload("res://buildings/TransportHubBuildingDefinition.tres"),
"ship_lab": preload("res://buildings/ShipLabBuildingDefinition.tres"),
"gas_burner": preload("res://buildings/GasBurnerBuildingDefinition.tres"),
}
static func get_definition(definition_id: String) -> Resource:
return DEFINITIONS.get(definition_id)
static func all() -> Array:
var result: Array = []
for definition_id in ORDER:
result.append(DEFINITIONS[definition_id])
return result
Reference in a new issue Copy permalink