qol, its really hard to sell items from your stash unless your inventory is empty.
but with mining for upgrades, you've set it up so that the high-end titan's strength can possibly rule the leaderboard? and by having that be so expensive -- i've barely managed to reach 1000 stardust with an autoclicker's help -- you're making the board about pain and clicking, not about 'builds' .. at least unless you add 'leagues' based the level in titan's strength, but that may be silly.
tldr; qol's mostly fine, but the constellation upgrades seem to be priced way to high (for someone who does not want to be married to the game)
TimBirms
Recent community posts
yes, there were 4 instances. i fixed them. then eventually wound up with dozens of axes and handsaws and on repairing the carpenter station was no longer able to access it, e.g. could never turn the logs into lumber to proceed
had to alter the amount of crushed rock (135->200) so that i could do the floor repair as almost no rock drops via the lowest tier after a while
also, switching to smithy after having queued up 30 or so mining jobs put me into a perpetual mining loop. not that i mind, but on switching back to explore, there's no queue showing, but i can queue and those jobs run .. and also the endless mining runs. i dont mind the free stuff.. but there's no game here like this :-(
note to self; yes, got that.
less-is-more .. may be a useful inner counter to the notion that more options are better .. especially so if you invest some time into factoring out the many numeric factors to also give then hint and help text and make them set/load/nameable 'configs' one can play with. from there you can't just check your own work, the configs will become a foundation for settings, scenarios, flavors and all of that. i mostly mean 'get rid of the hardcoded bool/num values and let players alter/save/export/share settings in plain text so you can get some balancing help from outside.
as for building generation .. idc. what maters to me is discoverability and if that in part means auto-generated help and hints and way to many things to look at, cool. as long as they wind up having good names and filters (like tabs as filterselectors for buildings) that are easy to operate so one never has more than a full screen of choices, then sur, go .. but _that is an aspect of the game that's going to hinge on 'genes' that make up the existing buildings .. and there will be a core set with aggregates and params bound to your 'buildings'. so, it really doesn't seem to give you anything to autogen buildings atm imo. i'd not even consider 'evolving them' until they become issues, and they work fine, no? at least fine from my perspective -- of not having had more than 300 residents.
military.. no.. i got tired of turning thing on and off to juggle workers .. and without a 'save' _and a _save-as that one can use to game the game a little bit by branching experiments from some working base-game, i can't say that it worked for me, but i never upgraded more than 6 or 8 or so aspects of it either - and was so outgunned that i could barely ever use combat options
as for my tastes havng .. save/save-as (gamestate), save-settings(-as) (doctrines), save-parameters(-as) (now hardcoded) .. with loaders that show 'new, removed fields, outof bounds-values' generically so that one can know on-load what's new and changed in the game - could free you from having to write too many change-notes while keeping players informed and potentiate what you can do so the complexity wont crash down around you.
if you supported just [tab when there are buttons] [arrows when there are sequences] [space to dismiss/close] [enter to confirm] most practical kb concerns would 'go away'. but i can dream :-)
nice round, catch you maybe next week, looking forward to it.
Hey, I'm glad you got the notes. was thinking of writing you a settings and savegame wrapper for making things persist -- basically just so that you can test this stuff. none of my tweaks were ultimately good enough as available free housing is still the most significant factor in population growth, and my efforts at reducing the enemy strength can't fix the algo which will have soon enough have you 'fight tanks with sticks' again; a few log(reducers) may help, but a test-simulator and tuned formula for battle-strength may in fact be needed to make military more viable (without the player being under or overpowered at any time since combat is ultimately just a thing you want to have to manage until you can treat it as a cash sink in case you dont want to leave, right?)
the best revision to my notions may be to have controls on the card to let you set '3⇵ of 11⇵ [x] active' to encapsulate [de-]activation/building and salvaging (those last 2 would want/need keyboardable popups i guess) and a '[x] show' or '[ ] hide' element so one can zap the clutter -- this way you could open up the idea of having resource icons as 'filter-tabs' and include a filter for 'hidden' elements. perhaps filtering by 'tier' makes [more] sense, idk.
keep up the good-work; 'd love to see this become playable!
this line shows more than meets the eye :-) but lets stay with the business at hand; please change the divider to 100 so it actually does what you meant -- and makes this sketch of a 'long-duration game without a save-manager and/or save-file-exports' actually runnable without tears.
T[r.MAX_POPULATION] * ((c.popularity + c.happiness) / 200)
in decay mode, it might be nice if modifiers actually meant something, but that's kind of less important.
ne = j * 0.02; // Hard decay ignores Food and Health or growth modifiers
as for the total disconnect between population and raid strength - which makes playing this sketch a loosing proposition, consider this pattern:
// OLD Code (Bandit Raid Example) const v = 3 + Math.floor(Math.random() * n.day / 2); // NEW Code (Proposed Fix) // Calculate base difficulty based on day let rawCount = 3 + Math.floor(Math.random() * n.day / 2); // Calculate a hard cap based on population // base of 5 so extremely small colonies still feel some pressure const populationCap = Math.ceil(n.resources[r.POPULATION] * 1.5) + 5; // The actual spawn is the lesser of the two const v = Math.min(rawCount, populationCap);
With this, on Day 100, enemies will be only 1.5x stronger instead of 2.5x).
This allows basic Soldiers to remain relevant for much longer.
// OLD Code const ee = 1 + P * 0.015; // 1.5% per day const fe = 1 + Q * 0.35; // 35% per Tier // NEW Code // Reduce daily scaling to 0.5% and Tier scaling to 15% const ee = 1 + P * 0.005; const fe = 1 + Q * 0.15;
The size of the militia is another issue that makes little sense of a survivalist szenario. Fix:
// OLD Code (Trigger logic in B0) const h = Math.ceil(n.resources[r.POPULATION] * u); // NEW Code // Base militia is at least 5 units, or your percentage, whichever is higher. // This ensures even a tiny colony has a squad to defend it. const h = Math.max(5, Math.ceil(n.resources[r.POPULATION] * u));
Also, please add a logic check that if enemyTotal > playerTotal * 2, the "Defeat" condition doesn't wipe the colony but instead triggers "Hunker Down" where you lose the battle immediately, lose resources, but you lose 0 Population as everyone will hide in the <span class="ng-star-inserted" <this="" simulates="" the="" workers="" hiding="" in="" <="" span="">CRASHED_DROPSHIP</span> while bandits loot the warehouse.
There are some UI items I want to mention as well: The "Red X" in the building control makes controlling buildings on/off really cumbersome. I think that one should be able to switch modes (tabs) in the cards showing the buildings so that one can activate/deactivate them from there. Some of the cards, like, say, the Hut, quickly make no sense at all and one would never want to see them - so they need to be made excludable before filtering comes into play.
I hope this message finds you well and that you don't get distracted away from this model before it can count as a playable simulation! Thanks and keep up the good work!

