| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Loïc Wisniewski
|
0fad1dd155 |
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one. #166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into sentences and dropping the literary register ("hulls" -> "ships", "That is our hands back" -> "That frees us for other work"). Same meaning, same voice. #167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the twenty have it, and they are the search for the World Ship. A quest handed out with its goal ALREADY met is now credited in silence unless it is one of those - no brief, no answer, both signals still fired and the index still moved, so it appears ticked in the objectives panel. The chain used to stop the game to set a task the player had already done, then stop it again to congratulate them on it. #168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still arriving, show it all; already whole, move on) was already the rule for a click since #149, but a key press reached the banner and did nothing - and this game is played with WASD and a mouse. Touch, click and key now go through one door. Modifiers alone and auto-repeat echoes are not presses. #169 - A LOADING SCREEN. A press raises a cover, and the load happens after it has been on screen for a frame, so the wait is something the player is watching. Deliberately still a blocking load: load_threaded_request() comes back FAILED for these scenes, reporting text-parse errors that load() does not produce, because the global class names and preloads they reach each other through are not resolvable off the loading thread. A progress bar is not worth a menu that sometimes refuses to start the game, and the web build ships with thread support off anyway. Further presses while loading are ignored - on the web a button fires on PRESS, so an impatient double tap costs nothing to make and used to build the world twice. #170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before the scene had finished arriving, so the game opened STOPPED (#128) over a convoy nobody had seen yet. It flies for three seconds first. #171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks whether a touch COULD arrive, and in a browser that is yes on any laptop whose panel reports touch support - so the web build put thumb sticks over a screen being played with a mouse, and switched mouse aiming off on the machine it exists for. The reading is now the last input actually used, it lives in GameState so the sticks and the guns cannot disagree, and it is two-way: nothing can strand a tablet, because the gesture that needs the controls is the gesture that brings them back. A touch suppresses mouse evidence for a second, so the click Godot manufactures out of a tap is not mistaken for a mouse. #172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet firing at something threw a sheet of parallel bolts past either side of it and only the middle hull could hit - worse the wider the formation. Guns now take a POINT and each hull works out its own heading to it, so the fleet's fire converges. The mouse already had a place and was flattening it into a bearing; a pushed stick names the point at the guns' reach along it, so touch loses nothing. The assist (#89) still bends a shot onto an enemy, now per hull and around that hull's own heading. The aim guide stops at the point and marks it. #173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet can not store any resources" is not a web bug. It is the third time the Godot editor's .tres writer has quietly dropped a property it thought was default-valued: InterceptorVesselDefinition losing `capabilities` leaves cargo_capacity at 20 and takes away the "cargo" claim that fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can be mined or carried. That is the symptom, word for word. test_definitions_intact caught it in the suite. What it could not do is catch it in a BUILD - an export is taken from the working tree at whatever moment the editor last touched it, which is exactly when the damage is done and exactly where nobody is running tests. The checks move to core/CatalogCheck.gd and now run at startup in every build as well as in the test, from the same function. On the web push_error lands in the on-page log web_shell.html mirrors, which is the only error a phone can read. The tree is intact today, so a fresh export should restore the hold. The point of the change is that the next time it is not, the build says so. Full suite green at 154/154. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3 |
||
|
Loïc Wisniewski
|
3fcc26c8bc |
Implement #160, #161, #162, #163, #164 and #165
#162 - a single tap bought a research node outright. One physical tap arrives TWICE: Godot emulates a mouse button from every touch AND a touch from every mouse button, both project settings are on, and the menu's dispatcher routes InputEventScreenTouch and InputEventMouseButton alike to the tree. The second arrival found the node already selected and took itself for the confirming tap. Measured, not reasoned about - one tap produced two picks and two confirms. What is ignored is specifically the TWIN: same frame, same place, arriving through the other input kind. Deduping on frame and position alone also swallowed two genuine taps in one frame, which the test caught. #164 - the build menu predicted a caption's height from the COLUMN WIDTH: wide column, assume one line. Right for most names and wrong for the long ones, so "Spacial Workshop" wrapped onto the price beneath it. Captions are now measured against the font that draws them, and prices sized from PriceTag.wanted_height(), which existed for exactly this and was not being asked. Prices are set before anything is measured, because the old order laid out first and priced afterwards. The ship lab: its buy button is gone and a second tap on an option buys it, the same rule as the research tree; the explanation drops into the room that freed; research points move up into the resource table, where everything else being spent already is; the second row of options is placed from the first row's measured bottom rather than a constant; and the vessel strip is spaced from the panel's own width, so the eighth vessel is no longer half off the right edge. #160 - the quest panel was drawn BEFORE the sticks and the pivot pair, so they sat on top of it. Moved after them, under the narration banner. Its title rule ran straight through the close button; the header band is now as tall as that button. #161 - the prologue widens the formation into a freight convoy by writing over GameState.formation, and nothing put it back. The player flew the convoy's 600-unit spread for the rest of the game - a shape nobody chose, which reads as the fleet having drifted apart. #163 - a quest to station a vessel at the outpost, after the one that asks for the outpost. Building one and crewing it are different acts, and an empty outpost holds nothing. #165 - the gas bomb's blast and a vessel arriving fast both damage a structure. The blast used to stop politely at anything the player owned, which made a bomb dropped on a besieged mothership a free way to sweep the attackers off it. Collisions are caught on ENTRY, not on the 0.7s strike tick: a vessel is only moving fast for the instant it arrives, and a ship sent in at 900 did no damage at all until this moved. Docking is free - the fleet sits on its own mothership constantly to bank ore - and garrison vessels are exempt outright, because they launch from their outpost and re-dock with it at speed. The suite caught that one: the ram rule was destroying the garrison as it launched. Suite 153/153. Four tests changed because what they pinned moved: the lab's buy button, the intro's formation, the research tree's tap delivery, and the build menu's own preview. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Loïc Wisniewski
|
4c920f10b0 |
#157, #158, #159: pay from the hold you flew in, and nothing is exempt from coming down
#157 was already satisfied - second_hull is quest 7 and extractor is quest 11 - so this pins the property rather than adding a quest: nothing costing more than a single hold may be asked for before the chain has grown the fleet or taught banking. It fails if either is ever moved behind it. #158 - a building's local costs may now be paid out of the fleet's hold. #12 made production cost resources physically DELIVERED rather than money out of the bank, and that stands: the bank is still not raided here. The hold is simply the other place resources physically are, and making the player park, open the transfer menu and move cargo across by hand was ceremony rather than a decision. But only WHERE THE FLEET IS, and that qualifier is the whole design. The first draft had no range on it and test_manual_supply_route caught it immediately: a crafter three thousand units away reached into the hold and spent ore the player had just withdrawn to carry somewhere else - which is exactly the complaint that got automatic banking removed in #24, arriving from the other direction. The range is Building.interact_radius, the same distance that decides whether the transfer button appears, so the rule is not a hidden one: if you could hand the cargo over, the building can take it. #159 - the mothership floored at 1hp, so a battered one sat there reading as dead and never exploded. That exemption existed to prevent a soft-lock, and the soft-lock turns out not to exist: the bank is GameState.bank_inventory and the hangar is stored_vessels, both of which outlive any building; the mothership is the one structure research never gates; it costs exactly what a single interceptor's hold carries; and ore comes from asteroids, which do not run out. So the way back is always mine, fly, rebuild - and that is what test_building_health now asserts, in place of the exemption that used to stand in for it. |
||
|
Loïc Wisniewski
|
2e0c666c2b |
#156: bank it before you are asked to spend it
The extractor is the first thing the chain asks for that cannot be paid for out of a single hold. Every hull carries twenty and the fleet is small; the mothership is where anything larger than one trip has to accumulate, and nothing in the game had ever said so. A deposit quest sits before it now, asking for sixty ore BANKED - which is a different question from the one GOAL_RESOURCE answers, since that counts the hold too, and the hold being too small is the whole point. So it needed a goal kind of its own. Sixty is three full holds, so it cannot be satisfied by accident on the way past, and it leaves enough behind to actually buy the extractor afterwards. |
||
|
Loïc Wisniewski
|
2206b55873 |
#145, #144, #143: a quest that could not be finished, and two boxes that overhung
#145 - the extractor quest could never be completed. Extractors are placed onto a planet from space and live in GameState.extractors, with their own position, stock and id; they are not in `buildings`. So the goal asked has_building_of_type("extractor"), which is false however many the player builds. Not the death the reporter guessed at - the quest was simply asking a question that had no yes. structure_exists() is the question anything wanting "does the player have one of these" should ask, and the quest model asks it now. The regression test builds every structure quest's target THE WAY THE GAME BUILDS IT and watches the goal flip, rather than knowing which array each one lands in - the knowing is what got this wrong in the first place. #144 - the build menu's status line is anchored to the top of the panel and its grid to the panel's centre, so the gap between the two is half the panel height. It was a written-down constant, correct only at 1280 tall; at 1080 the grid started four pixels ABOVE the status line and drew through it. Nothing about that geometry is written against a screen size any more. The band is measured from the header that is actually there, the pitch closes up to fit it (never below a row's own height, which is what makes overlap impossible rather than unlikely), and the column count rises until the rows fit - so a short window gets a wide grid instead of one running off the bottom. Ten structures now lay out as 5 columns at 900px tall, 4 at 1080, 3 at 1280 and 2 at 1600, clearing the header at every one, which is what the test walks. #143 - a hangar caption is "Gas Bomber\n2 available": two lines before autowrap and three after it in a narrow column, at a size fixed in the scene. Labels do not clip by default, so the third line was drawn over the icon of the row below. The size is fitted to the box the layout works out, and the box clips - the first keeps it legible, the second keeps it correct however the vessel names grow. Its box also overhung by exactly HANGAR_LABEL_GAP: the layout subtracted one gap where it needed two, above the caption and below it. Two pixels, but two pixels inside the next row's icon. |
||
|
Loïc Wisniewski
|
90c34f6c74 |
#141, #142: the chain teaches research, and asks for the pile before the build
Two gaps between the first quests, both of the same kind: a step the chain assumed rather than asked for. #142 - "collect 5 ore" was followed straight by "build the mothership", which costs twenty. The first thing the chain ever asked for was four times what it had just taught, with nothing in between saying so. A stockpile quest sits between them now. #141 - the crafter quest's brief said "spend ore on the Shipyards doctrine, then put a ship crafter down", which is two unrelated things off one line: open a menu the player has never opened, and place a structure. Researching Shipyards is its own quest now, and it is the one that says where the research tree lives. Every later quest that needs a doctrine still only mentions it in passing - once is enough. That needed a goal kind for researching a doctrine, which the model did not have. Both are pinned as properties rather than as positions in a list. The chain must ask for at least as much ore as the first structure it wants costs; and the first structure that is gated behind a doctrine must have that doctrine as a quest of its own. Only the first - demanding one per building would double the chain for no teaching. One thing that fell out of writing those: the pile is exactly the starting fleet's hold. An interceptor carries 20 and the mothership costs 20, and before the mothership exists there is nowhere to bank anything, so the hold is the only store there is. It fits with no slack at all, so there is now an assertion saying so - a pile larger than the hold would be a quest that cannot be finished, and nothing else would have caught it. |
||
|
Loïc Wisniewski
|
970eafc1de |
#140: the objective moves behind a button next to the map's
The standing tracker #132 put on the HUD sat in the right-hand column, on top of the dev wave button - and there is no free strip of that edge to move it to, because everything down it is already something. So the objective stops living on the HUD: a quest button beside the map's, and a panel when you press it. The panel shows the current objective, its progress, and the road behind it. Deliberately NOT what comes next - the chain is meant to open the game up a step at a time (#133), and a list of everything still to come is that discovery given away on the first press. It owns its own button, the way WorldMap owns the map button rather than being wired through BuildController, and it hides that button during the prologue for the same reason and in the same two places (at _ready as well as in _process, since #128 means a dialog stops the tree before the first _process frame ever comes). Both scenes carry it. On a planet surface there is no map button to sit beside, so it goes under the planet's name. The test now checks the button is beside the map's and clear of the wave button by rectangle rather than by eye, which is the bug the ticket reported. |
||
|
Loïc Wisniewski
|
1ece202731 |
#138: structures and doctrines cost more than rocks, and more the deeper they are
Both halves of the ticket, in the shape vessels have used since gas bombers and laser ships: a definition carries an ore figure and, when it wants more than ore, a dictionary that IS the price. `building_costs()` and `skill_costs()` answer it the way `product_costs()` already did, so there is one question with one answer whatever is being bought, and every payment path now goes through `spend_resources` rather than `spend`. Seven of ten structures and thirteen of seventeen doctrines now want gas, energy or dark matter alongside their rocks, and the totals climb with tree depth - structures 16/31/58/62/96 by depth, doctrines 15/30/73/96/143/258/530. The constraint that shaped the table is REACHABILITY, and it is the reason some prices stayed ore-only. Energy exists only where a gas burner stands, and a gas burner needs Power Systems - so nothing at or before that depth may be priced in energy, or it is a wall with no way through. Dark matter is rarer still and appears once, on the deepest node in the game. The extractor stays rocks-only despite its depth allowing gas, because the quest chain reaches it before it has sent the player for any. test_progressive_costs checks those as properties rather than transcribing the numbers, so rebalancing a price costs nothing while breaking the shape fails: nothing unreachable at its own depth, prices rising with depth, the ore field agreeing with the dictionary (repairs quote the field alone, since a repair drone carries ore and nothing else), and the quest chain never asking for a structure it has not funded. Two things cleaned up on the way: - The per-building cost constants in GameState are gone. Nothing but tests used them, and they were a second copy of a number the definitions already hold - exactly what would drift once a price gained a resource. - research_for_building() returns a display NAME, and the id-keyed half of the tree wants an id. That mix-up is silent - skill_depth() of a name finds no node and answers 0, so a deep structure reads as an ungated one, which is how the first draft of the test let an unreachable price through. research_node_for_building() is the id, and the name is expressed from it. PriceTag no longer rebuilds its labels when re-told the same price; it refreshes the held figures instead. The craft menu re-states prices every frame and the build menu now does too, so that was a dozen Labels being torn down and rebuilt sixty times a second. |
||
|
Loïc Wisniewski
|
397983b611 |
#129 (#131, #132, #133): a quest chain, and a World Ship out of reach
Sixteen quests that walk a new game through the things it contains: ore,
the mothership, exploration, a yard and a second hull, planetfall and
conquest, extractors, gas, freight, power, the lab, a new vessel type, an
outpost, and a survey.
The chain turns on the second quest. The fleet builds the mothership to
call the World Ship and hears nothing - and the array is not at fault. The
breach put them further out than that signal will carry, so every quest
after it is a search that has to be flown rather than transmitted.
Three pieces:
Quests.gd the chain, as data and nothing else. Two rules it obeys:
nothing may ask for something unreachable - research points
come only from conquering a planet, so every doctrine that
costs them sits after the conquest quest - and a quest names
one goal, with the research it implies said in the brief
rather than split into an errand of its own.
GameState how far along the chain the player is, and the answer to each
goal kind. Progress latches for free: the chain is walked one
quest at a time, so collecting five ore and spending it cannot
un-complete the quest that asked for five - by then nothing is
asking. It lives here so a quest finished on a planet surface
is still finished after take-off.
the HUD QuestTracker, the standing objective, in the wave alert's
idiom; QuestDirector, which reads the lines out.
Lines are QUEUED by GameState and drained by the director rather than
emitted at a banner, because quests advance in the autoload, which runs on
a planet surface too - where a line emitted straight at a banner would be
lost. Both scenes now carry a banner, a tracker and a director, so a quest
finished underground is announced underground.
The chain is armed by reset_new_game(), the same gate the prologue uses -
the only door into a real game - so instantiating a scene is not by itself
a reason to start briefing somebody.
|
||
|
Loïc Wisniewski
|
f9ed46746d |
#110: a dev-mode button that puts a wave on the board now
Waves are on a fifty-second clock, which makes anything that happens during one - the alert, the pathing, buildings taking damage, an outpost garrison earning its keep - slow to look at even once. It skips the warning as well as the peace: the point of the button is to see the wave, and waiting out a nine-second alert every time would make it useless as a tool. Gated on dev mode, the same gate the main menu already uses for the map editor, so it does not exist in a shipped build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Loïc Wisniewski
|
209169206b |
#108: the prologue - the convoy, the ambush, and the breach
Landed as one piece across #122, #123 and #124: the frame is useless without a script, and the script has nowhere to run without the frame. The director drives the REAL scene rather than being a scene of its own. It wants the real fleet, the real enemies and the real asteroid field, and it makes "then the game starts" cost nothing - the director stops steering, clears the flag, and what is left running is the ordinary game. The script is a list of beats, each with a deadline as well as its own completion test, so a beat whose condition is never met - a player who refuses to fly at the ambush - runs out rather than wedging the prologue. skip() ends the whole thing at any point and lands in exactly the state playing it through does, so the game has one way to start rather than two that have to be kept in step. The test pins that equivalence. "No action button available, only movements" is enforced where the buttons are decided, not by the director reaching in: the ability controllers set their own visibility every frame and would have put them straight back, and the map button belongs to the map. The joystick, the pivot and the fader stay. The convoy is ten hulls where a new game's fleet is one, so it needs an explicit fleet-size override - a plain number rather than a fake doctrine, because nothing about the player's own progression should be bent to fit a cutscene. It is carriers rather than transporters: transporters belong to hubs and are not fleet-eligible, so a convoy of them would be silently filtered down to its escorts. The ambush is chasers and only chasers. "Easy enough" is the requirement, and a sniper against a convoy the player cannot yet fight properly is neither easy nor a good first impression. The breach takes the wheel through one check in GameController, covering the stick, the keyboard and the released-again path together - three separate gates would be three chances for one of them to keep steering. The shake is written to camera.offset, never to its position, because GameController owns where the camera is and would smooth a shake away. The vessel that survives is chosen as the interceptor rather than whichever happened to be first in the list, and the prologue ends on exactly a new game's opening position. Also: PlanetAtmosphereController no longer spawns the opening fleet while the prologue is arming, and the tests that are about what the GAME starts from now say so by turning the prologue off. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Loïc Wisniewski
|
b50597b757 |
Garrison laser vessels and gas bombers, on a shared ability seam
#105 shipped with interceptors as the only garrisonable vessel, and the reason was a design fault rather than a decision: firing the laser and the gas bomb lived in the player's fleet controllers, so a stationed laser would have held its position and never shot. The shot is now a thing in the world rather than something a controller draws. LaserBeamEffect and GasBombEffect are self-contained, self-animating and self-freeing, added to the tree root - the same shape EnemyBigLaserBeam and ArtilleryShell already had on the enemy side - and they outlive the vessel that fired them. Above them sits one seam, on VesselCooldownFillComponent: ability_range(), ability_ammo_resource(), ability_ammo_cost() and fire_ability(). A beam and a bomb are now the same shape of thing to whoever pulls the trigger, so the garrison AI never names an ability - the test asserts that literally, by reading the AI's own source. A third armed vessel needs to implement the seam and nothing else. Ammunition is the CALLER's business, deliberately: the fleet spends from its hold, a garrison from its outpost's store, and neither concern belongs in the component. A garrison with an empty magazine holds fire rather than falling back on the fleet's hold. Outpost storage: 50 gas per stationed bomber and 50 energy per stationed laser, off the VESSEL definitions, so an outpost never learns which vessel needs what. It is a capacity, not a stock - hub transporters fill it exactly as they fill a gas burner's buffer, because building_logistics_deficit now takes the larger of the definition's static buffer and the garrison's magazine. Every other resource is capped at zero: an outpost is not a depot, and ore parked at one has nothing to do there and no transporter coming for it. Also restores two properties the Godot editor dropped from GasBurnerBuildingDefinition.tres when it re-saved the file: collected_outputs and capabilities. Without the first, nothing ever collects the burner's energy - test_gas_burner caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Loïc Wisniewski
|
0c595d775d |
#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> |
||
|
Loïc Wisniewski
|
8122e280b7 |
#104 (#97f): outposts are crewed automatically from the mothership
Vessels come from the HANGAR and never from the fleet. The fleet is what the player is flying, and taking a vessel out of it to crew a building would be the game undoing the player's own arrangement. "Whenever available" means "when one is sitting at the mothership", and an outpost asking for a hull nobody has built simply waits. They travel, down the same vessel_deliveries path a finished crafter order already uses to reach the mothership, rather than teleporting. What is already in the air counts against the shortfall. Without that the dispatcher sends the whole hangar to fill one berth, because the crew does not grow until the first arrival lands. Two directions, not one: lowering the order flies the surplus home rather than stranding it, and a vessel whose outpost is levelled under it lands in the hangar instead of being destroyed - the same rule a transporter mid-delivery already follows with its cargo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Loïc Wisniewski
|
3c632276af |
#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> |
||
|
Loïc Wisniewski
|
26f3728546 |
#100 (#97b): waves replace the roaming enemy spawner
The old spawner put one enemy on the map every 3-6 seconds for ever. There
was no rhythm to the danger and nothing to prepare for. Enemies now arrive
in waves: a long quiet, a warning, an attack, and quiet again once the wave
is dead.
The clock lives in GameState, because Main.tscn is destroyed on every trip
to a planet surface and a wave must not be cancelled, nor restarted from
zero, by a landing. The spawning does not: GameState cannot see the world,
so EnemySpawner reads the phase and puts the enemies in it. That also
settles what happens when a wave turns while the player is on a surface -
the wave is waiting in space when they come back.
EnemySpawner keeps its name deliberately. It is still the thing that puts
enemies in the world, and 88 test files already say
`get_node("EnemySpawner").set_process(false)` to ask for a quiet map.
Strength is a function of the FLEET, per the ticket, with the wave number as
a slower second term so a player who never grows still meets escalation. The
budget is spent most-expensive-first, so a large wave is heavier rather than
merely longer, and min_strength keeps the first waves to chasers whatever
the arithmetic says.
"No timer should be visible" is enforced rather than merely observed:
GameState offers wave_warning_pulse(), a 0..1 throb, and no
remaining-seconds accessor at all, so the alert cannot drift into being a
countdown. The test pins both - that no such accessor exists, and that the
alert's own text contains no digits.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Loïc Wisniewski
|
2f161621c3 |
#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> |
Renamed from GameState.gd (Browse further)