Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
5 
Report this post
I am using ACE yes.. I did restart and it seems to have corrected the issue.. at least I know now.. thanks mate.
I'll have to look into that,, I appreciate the idea.
By contrast, if you run the game on a system which is intentionally designed to run simulation-heavy games with minimal overhead and minimal wasted processing power... it runs fine. Yeah, after 3 hours or so I have built-up "junk" information that slows the game down too; but that's actually true for every single simulation-heavy game I play. It's part of how computers work. Regularly saving, quitting, and re-starting will sort that out easily.
Before you go blaming the game, take a look at the literally hundreds of times this has been explained -- the game will follow YOUR instructions, and when you don't give clear instructions or create obvious "best options" for the game to choose*, it creates a huge amount of extra work for the game which causes a bottle-neck in processing and thus creates the lag.
*e.g. making sure you have storage for resources near where they're needed so that the game can easily figure out where to get the resources from rather than having to scan a huge area to find enough logs or whatever laying on the ground to get the thing made
I don't get lag when I play, and I'm not playing on a supercomputer. I'm not leaving half the game out either -- I build complicated buildings, have lots of items and 30 hearthlings, with lots of lights and graphics at default or higher. It's possible; hell it's easy to get there. All you have to do is get over this idea that "the game is badly made", accept the fact that computers are not magic and will not automatically be good at the things you want them to be good at unless you purposefully build them to be, and go do some basic digging to figure out where the game is running into performance bottle-necks on your computer. Then, you can either adjust what you're doing in the game to reduce that workload, or adjust your computer to better support the kind of games you want to play, or both. Although I'll be honest here... even on a supercomputer, Stonehearth will eventually lag out if you just throw endless jobs at it to figure out on its own.
Stonehearth is a management game. It runs an extremely consistent simulation which is intentionally designed to be easy to observe and learn from. If it's coming to a crashing, grinding halt then that's probably on you, failing to manage the situation in your game world, and leaving the computer (which has to figure everything out the hard way, and can't use things like intuition or learned patterns the way we can) to do all the work when its job is supposed to be to keep the sim running. You're the designer and the supervisor, not the computer; and if you don't do those jobs then the computer isn't going to cover any gaps. It's just going to follow whatever instructions it has -- and it's not going to question whether they're good instructions.
1st where did you got that data From?
2nd you got it quite Wrong - it's not the PC-Architecture that has to fit the software - it's the other way around. If you delevope a software you have to take into account the limitations of the targeded plattform and programm with those in mind...
Again, where did you got your data? what other simulation-heavy games are you reffering to? and is it REALY the norm that those games must have to "build-up Junk"? (what most would call memory-leak, something a programmer should avoid in any case)
for me it seems you try to blame the users... again it's the other way around - the developers have to take the dumpest user into account if they develope software (sure, somethimes you just can't include every stupid idea that might emerge...)
if the Software can't handle to many commands, it has to limit it to a amount it can handle- it's not the job of the User/Player to figure out how many orders can be given in a time.
thats just a Bypass of the Problem. Again you put the responsibility onto the users/players. The Game allows me to put my storage wherever i want. if it can't handle that why is it not limited to a area it is used/needed? It's the responsibility of the software /the devs to avoid situations the software can't handle...
Accapting that is not helping to reach a point in the Game...
You are correct Computers are in fact no magical devices, they are more of a massive collection of switches.. thats why the software that runs on it has to take the limits of those "switches" into account to not overstrain it.
Stop blaming the user for the mistakes inside the Software. Everything you typed here is just a cheap try to switch the one to blame. If the Software can't handle a Situation it has to be limited to NOT reach that situation in the first place. Thats the task the Devs have. If the programm crashes are stops working correctly tha fault is not withhin the userbase ore the players but the software.
1) the "data" is an educated estimate based on the profiler breakdown of CPU use compared to GPU use when playing Stonehearth when comparing it to run-of-the-mill AAA "cinematic experience" games where the GPU load is the bottleneck rather than the CPU. That's the kind of target game that "gaming" computer architecture is optimised towards, leading into...
2) there are functionally infinite different PC platform specs. It's not possible to optimise a game to run on "PCs", because a PC can be anything from a barely-functional processing unit with a 4GB graphics card and 40GB of RAM (i.e. "top of the line" on paper for most parts, but useless in reality)... all the way down to a rig similar to mine which is theoretically 10 years behind "current" spec but actually handles the simulation/CPU-bound processing requirements of any current game quite handily; and only starts to suffer on graphics if I try to push for max settings (since, in the vast majority of cases, the current benchmark for "max settings" is based on tech that's 2 generations beyond what existed when my PC's components were coming out of the factory)
Game developers already to an astounding amount of work to try and optimise games to take advantage of the hardware available; but if the PC user is running a setup that is flawed in itself (or which is optimised for something other than what they're trying to run with it -- e.g. a graphics-optimised gaming PC trying to run a simulation heavy game that doesn't use the GPU for sim) then no amount of optimisation is going to fix that.
Stonehearth runs almost flawlessly on my 10-year-old PC; that's damn good optimisation in my book. Meanwhile, everyone who complains about "poor optimisation" turns out to be making absolutely dumb mistakes with their computer that are obvious user error -- like keeping a dozen browser tabs open sucking up all their RAM; or running multiple virtual wallpapers at once because they don't even know that switching between wallpapers in something like Wallpaper Engine doesn't always clear the cache properly (i.e. it's reserving GPU and CPU memory that's no longer needed), or any number of similarly basic user errors.
3) extensive personal experience. I play simulation-heavy games; sim management is my favourite genre. Every single time I play a game like Stonehearth (or Towns, or Factorio, or Scrap Mechanic, or Space Engineers, or Minecraft, or Terraria, or 7 Days to Die, or... well you get the idea -- games with a lot of stuff going on, and lots of player agency), I see complaints about "poor performance" and yet I never have that problem.
And yes, junk build-up is a common problem in ALL videogames, but especially the sim-heavy ones. It's not always "memory leaks" either; that term has been twisted and abused to describe everything from genuine bugs to simple oversight to unforeseeable interactions between old games and modern systems (i.e. tech that didn't even exist when the game was made)... and I constantly, constantly see examples of player behaviour being called a "memory leak" when what's really going on is just that the player is creating more tasks for the computer to solve than it can keep up with. And, 90% of the time, it's because the player doesn't understand that they're overlooking entire sections of the game -- a great example in Stonehearth being the way that players leave materials where they drop, and wonder why the AI has a hard time building anything. Leading to...
4 + 5) yes, I do blame the user when the user is clearly at fault. I mean, Stonehearth is a management and design game -- the player's job is to be a project manager! You're not supposed to drop a template and walk away and expect it to all magically work! Stonehearth is a game about making decisions, about logistics and trade-offs (do I put my blacksmith workshop near the mountains where the ore is, or keep it in town and bring the ore to the workshop? Do I grow lots of a crop that grows fast and has a low food value; or do I grow the crop that takes ages but has a higher long-term return?) It's a game where the player gives the game instructions and the game follows those instructions; the game is not meant to be the one solving problems or figuring out the best way to do things. That kind of problem solving is a core mechanic, a key part of the gameplay! Leaving it up to the computer is a bit like playing an FPS where all the weapons auto-aim; all you're doing is deciding which one to use and which cover to move between.
Stonehearth is designed to be a work-out for your creative muscles, not a "town building visual novel" where you just select from a list of options. It gives you the freedom of a sandbox where you can approach the game however you like; the trade-off is that the game isn't going to guide you towards any particular path. You're free to do anything, including making a huge mess that ultimately grinds your computer to a screaming breakdown. The game neither knows nor cares, it just does what you tell it to do; and that is by design.
6) Stonehearth, and the computer running it, is not "just a collection of switches" -- computers are a little more complicated than that by now. Yes, the basis of computer logic is yes/no/and/if statements (which is already more complicated than pure binary yes/no or 1/0 switches); but let's be real here -- Stonehearth as a game is a collection of rules and options; which operates inside the rules that run your computer.
Now, you can't expect a computer to think like a human. You ALSO can't say "well the computer is just a dumb rock we tricked into saying yes or no", because that ignores the salient problem. The developers of Stonehearth designed a system to generate narrative, choices, and challenges while operating within some pre-defined rules. If the player refuses to grapple with those rules and figure out ways to work within them (leaving it all up to the rock that only says yes or no), then that's not a failure of the people who designed the rules-set of the game and it's not a failure of the computer (which is following its instructions to the letter because that's literally all it can do.) It's a clear failure of the player to engage with the rules presented to them. And blaming the computer, the devs, or anyone other than the player is a waste of time.
I say this as a player who frequently engages with such rule-sets, and the challenges they present, for fun. It's not ♥♥♥♥♥♥♥ hard to figure out a solution within the constraints provided -- especially when the game is explicitly designed to be solve-able and let you use a variety of tools to solve its problems
7) Limiting the software to prevent the user from creating a death-spiral would limit the user from playing the game at all. I mean, take the simplest simulation possible: one that allows you to add a single dot to the screen when you press a set key (and, to prevent an obvious straw-man: let's say that once you fill the screen with dots the game picks a new colour and lets you fill the screen with dots of that colour, cycling endlessly.) Now, press that key 10000000000000000000000000000000000000000000 times... I guarantee that eventually even that simplest simulation will crash eventually.
The problem is not in the software. A competent player can play Stonehearth with no issues -- I know this because I've done it hundreds, maybe thousands of times. And I've done it in mutilplayer; I've done it during the beta when there were genuine bugs; I've played Stonehearth under every condition you can imagine and probably some you can't. I've intentionally put the game under stress conditions to figure out where it breaks (and how); I've run it on multiple computers with varying success (and with very predictable results -- the computers that were not optimised for CPU-processing pipeline fared poorly; the ones that were did just fine.) I've done truly unreasonable things like pause the game (so the sim is paused) and disable the item limit and then keep spawning endless items to see how many items it takes to crash the game from purely going out-of-bounds on the number of items. I've had a town with 75 hearthlings that still managed 30fps (although I was using a very small custom map with an extremely simple set-up to minimise AI processing load); I've spawned in armies of 1000 enemies and had them all die at once (using a console command) and watched the AI processor use spike to the stratosphere as the game tried to allocate thousands of "loot and store" tasks at once.
When you understand the game, it becomes extremely easy to predict. It's a very consistent simulation; although it does have an (intentional!) layer of obfuscation to make the randomness look more random than it is and provide novelty. It takes a bit of work to really understand a game like Stonehearth; although once you do it's extremely easy to control the outcome of the tasks you set.
So yeah, I blame the players more than I blame the game or the devs -- because I spent years trying to break the game during Early Access, and years after that pushing the limits of the game without breaking it just to see what's possible. The biggest design flaw that I've found in the game in that time is simple:
it needs to have a "tutorial" screen that pops up when you load the game and says "remember: don't expect the computer to figure everything out for you because that's not how this game works. You're in charge, so do your job and design your town so that it works. Watch what happens, find the problems and fix them; the hearthlings won't (and can't) do that for you. When something doesn't work the way you expect, 99% of the time the problem is with your expectation and not with how the game works."
If everyone understood that about the game, then anyone who tried to call the game "broken" would be laughed at. Because, as it stands, Stonehearth is not broken -- in fact, it's one of the best games available as far as accounting for players' mistakes and trying to fix them quietly in the background. The fact that it can do anything at all to mitigate "garbage in, garbage out" (a fundamental rule of computing!) and help nudge the end result towards the player's expectation rather than the strict letter of the players' instructions is an absolute testament to the skill of the dev team.
TL;DR but you're ridiculous.. lmao imagine if every game REQUIRED you to play it a certain way for it to run correctly?? LMAO and you want to sell this to us as if the user is to blame.. Imagine someone playing Skyrim and complaining and someone saying "that's because you're playing it wrong.." hahahahahahahahahahahahah that has to be one of the dumbest things I've ever heard.
Weird I can play 99.9% of the games in my library anyway I want and this .01% of the games I have to figure out how to play the "right" way.. but yea definitely not a developer flaw.. 100% the user.. haha.. what a joke.
I never said that Stonehearth required a certain way to play correctly -- in fact, I pointed out in that quoted post that I've played it many different ways successfully, and that its strength is the freedom that it gives you to play however you like.
What I said was that Stonehearth doesn't stop you playing it badly.
And mate, I've seen a lot of people play Stonehearth badly. I've played in multiplayer with people and gone "what the hell are you doing, you've made such a mess over there that my game is lagging now!", and shown them how to fix it, and my game has gone back to not lagging once we restart the server. And, lo and behold, that other player no longer has lag in their singleplayer games; and can do things that previously weren't possible for them like running 30+ hearthlings where they once started stuttering at 20.
I don't know what you're going on with "99% of the games in my library I can play however I want" -- I have a Steam library that's skewed towards sandbox games, and still, half the games I own have a "correct" way to be played. There are certain reasonable expectations about things that don't work. In, say, Skyrim it's clear that just charging every enemy headfirst with no preparation or good equipment won't work. You can build a strategy around face-tanking if you have the right gear and skills and level-ups; but you can't just charge the first giant you see with whatever rags you're wearing and wielding a rusty knife and expect to come out ahead.
Stonehearth has its own rules about what constitutes "bad strategy", and one of the big ones is when players leave everything up to the computer and completely ignore the logistics tools they have (e.g. input and output bins), ignore the principles of efficient design (e.g. keeping things close together that will be used together frequently), and make complicated mazes that the hearthlings have to solve every time they want to get somewhere... and then wonder why the computer runs out of processing power trying to keep all that going?
What's ridiculous is when people complain about having to do management and logistics and planning and figuring things out for themselves in a town building sandbox game.
True most actual "AAA" Titles are more GPU hungry than older Title.
But the GPU is not only there for Graphics. the GPU can also Handle a lot of other tasks (like calculating).
So it is possible (i don't say easy) to use the additional prowers of the GPU to handle simulations quite good.
(mind me, this is theoretical and I'm sure the Game-Engine of SH is not programmed/designed that way).
That your older PC caa handle a Game better does not mean that older CPU-Architektures where better for Simulations (If your PC is 10 yo than it should also use the AMD64 Architecture).
the could be a lot of Reasonst for that, maybe another OS that does not use as much "ressources" as another one or you just have not as much Workload in General as others that face Problems..
True, the compination of PC components is almost infinite (at least it's not possible to test and optimize it for every PC build ever).
thats why there are "minimal specs" - sure, even then it's not possible to have a great performance, I would not argue about that.
I did't say otherwise. But what do you consider a "graphic-optimised PC"? Someone who has a low powered CPU but a High-End GPU?
Sure you don'T want to explain now that modern CPU's are "grapic-oriented" and therefore "weaker" than older CPU's.
As far as I know (and I sure can be wrong) you need both to a extent to play Games
btw. the Bottleneck nowadays (mostly) is neither the CPU or GPU but the Hard-Disk / Solid-State-Disk (for graphic expansiv games at least)
but i give you that: if the PC is build flawed (somethink like using 3 memory-Sticks (RAM) and one is alot slower then the others, or having a cheap CPU like a FX6300 with 2 TitanRTX -> you get my idea)
"it works for me so it's good"
it works great for me too but that doesn't mean it's good optimized.
I consider a Game as good Optimized if the mayority can play it flawlessly
(Just to clarify I didn't say that SH is bad or good optimized since i don't have that data)
yeah if someone is handling his/her PC poorly than most games would not work like expected (yeah even "modern grapic-optimized Games" need ressources like RAM ect. and would most likely perform badly)
I too play alot of simulation Games but wouldn't call each game you named a "simulation Game" (ec. Minecraft - a Game that is mostly known for the Hunger of Memory at least the Java-Version)
junk-building IS a memory-leak - if a programm or a game, creates an instance of a object and does not free the allocated memory after it's use we call that a memory leak (i don't mean if a player leaves "ingame junk" somewehere) sorry if you misunderstood.
What I mean with limitation is that a software is able to determin how many tasks are already running - it could for example quere new tasks in a list or discard new orders entirely, maybe with a warning massage.
Right it IS a Game and NOT a scientific Simulation. A User is not suposed to "learn" the limits of the Game (or the Game and his Rig). It may sounds naiv but the Game has to guide the User to a degree and if it's just to save the Game from crashes. Sure most Errors are thanks to the DAU but thats exactly the user a Developer should have in Mind... or try (I know, there always will be a DAU "better" then the last)
the way you descripe how you play is a good way to play Games like this but it should not be nessesary to play like that. the Game should also run if you - for whatever reason- like to have a large storage in the middle of your colony for everything. Sure, at a point I would assume that the Game will run slowly. (another Point the Game could warn the user - or give a hint)
You are right if you say that the user could grind his PC but to dismiss the option to warm the user beforhand and call it "by-design" is flawed. The game should care and even if it's just a warning in a tutorial..
The Basic is still just yes and no (binary) even now we work on a binary basic system (at least I don't own a qantum PC) - sure the CPU now has defined operations but it's still works just with the old 0/1 even our internet works with that binary system.
While you are right that a Computer can't think like a human (or is dumb [...]) you again dismiss the possibility that it would be possible for the software (if it was designed that way) to warn the player before he hit bedrock (means reaching a point that makes the game/save unplayable).
I don't mean if a User deliberate try to crash the Game (with or without external tools) or gives his PC hugh workloads to begin with - here we both would agree that this is a EIFOK.
You are wrong this time. A simple siimulation would not crash if all it does is overriding dot's. Why should it? Does your PC crashes on a regular basis? I mean your OS is a Programm in itself that runs a lot of operations again and again without crashing
normaly a crash sould be handeled before it happens - like intercepting it with a exception (try catch). (sometimes you have to find the exception first tho)
It is not the job of the Player to "unterstand" every inch of a Game - a Game is supposed to be entertainment not work (some ppl forget that just to easely).
Also, it's kind of strange that you allegedly tested a lot of scenarios that didn't break the Game yet you know what breaks the Game (how did you know if you didn't achieved thoise breaks?)
-- maybe you exaggerated to get your point across?
Still, if a Game crashes while you play it normaly (without manipulating it with tools/cheats ect) then the Game is at fault. Since all you do is stuff the Game allows you to do.
this is called exceptiopn handling (see above). Most crashes are access violations like buffer-overflow, out of bounds, null-references ect. Idealy the software handels them.
If you read this commend and my last you should see that I don't explicitly talsk about SH.
I get that you like it a lot and thats absolutly ok, i would and will not defy that.
No one here called it broken but "bad optimized" and, well, most games nowadays are in fact poorly optimized.
But what you call "a absolut testament to the skill" is "normal programming" I expect a dev to keep to the fundamentals. Do you prize the mathematican if he avoid deviding by zero?
Don't get me wrong I don't want to diminish the work of the Devs but there is no Dev out there thats perfect and no software thats flawless.
Therefore it's normal and good if Player/User point out if something does not work like intended and to blame them is alike with telling them that a programmer can't fix that.
So again: As long as a problem arises while the software is used as intended, the Problem lies within the software.
I'm not going to go point-by-point anymore because, frankly, there's only so many times you can say "you're right BUT" without sounding like you're just trying to avoid the fact that I'm right.
Stonehearth is a game about exploring a world, and trying things out -- the core game element is learning and taking what you've learned and combining that back into your next move so you can do better within the rules of that world.
You build a basic house. You figure out that it's taking ages for the hearthlings to carry logs over from the forest. You try building a stockpile and let the hearthlings move the logs before you start building, and hey -- it goes faster! Then you try finding more ways to make the job go faster; and along the way you learn things like "the more decisions I leave up to the hearthlings, the exponentially longer everything takes... therefore, conversely, the more I plan ahead and minimise the work they have to do the more I'm able to do within the set limits of my computer resources."
Or, at least, you learn that if you pay attention. Too many people just throw more and more orders at the problem; "shouting" at their computer to work harder and do more in less time.
I will point out a couple of things you're blatantly wrong about though:
- many, many people are calling Stonehearth "broken." Go check the reviews on the Store page. Now, I'm firmly convinced that 90% of these people are wrong, and further, that they've misunderstood the core of the game... but they exist, and their opinions are being heard.
- I'm not out here saying "well it works fine for me so nobody else must be having problems" -- I'm saying "it works fine for me and hundreds of other people who I've talked to, played with, watched videos of, etc., and I've seen a lot of evidence that the people who it doesn't work fine for also just aren't very good at computers." And I'm not an expert with computers by any means -- but one thing I am very good at is problem-solving and recognising patterns. It's part of the reason I enjoy this genre; I see the subtle patterns that the game operates by (e.g. how the AI favours closer tasks to further away ones, or how the semi-random timers for some events still have hard limits for minimum and maximum intervals and you can plan around those) as well as the more obvious patterns that the game actively points out to you (e.g. how more "advanced" items always have a higher value, so even if you have two items made from the same amounts of the same materials the one that requires a higher-level crafter to make will be worth more); and I've spent ages explaining these kinds of things to players. And, half the time, the response isn't even "huh?", it's "well that's stupid! The game should [be designed the way I want it to be designed so that I don't have to think about it too hard!]" (obviously I'm paraphrasing a bit there.) And I've seen that behaviour pattern so many times now that when I assume that people are complaining because of ignorance rather than because they understand the problem it's because I know it's a pretty safe bet.
And I should point out that, even knowing that, I still stick around to help the few people who genuinely want to learn and understand the game. I'm not here to mock people who are ignorant; I'm here to offer knowledge to those who seek it. I just have no patience for fools who throw a tantrum and blame everyone else for what ends up being their own mistakes (or for failing to learn from them.)
- "it's not the job of the player to learn the game"... actually, that's precisely how this genre works. The entertainment in a game like this comes from 2 sources: novelty, and mastery. Novelty is quick and doesn't last -- sure, it's cool to do something you've never done before (build a new workbench you haven't used; fight and defeat a new enemy; see a new part of the story; have a new combination of random elements you haven't seen yet interact in a unique way e.g. a hearthling with specific traits turns out to be an amazing soldier because of those traits)... novelty is like a sugar rush. However, novelty wears off quickly; and its absence is obvious -- "oh, I've seen all this before." Mastery, by contrast, takes time and effort; but the payoff is much greater. Once you've mastered something it doesn't stop being fun; it gets more fun as you try to push the limits of what you know is possible and find new challenges or new things to explore.
Learning how Stonehearth works isn't "beating" it, it's more like that's level 1 and the rest of the game unfolds from there.
The core point of this entire wall of text is that when people come in here saying the game 'doesn't work (well)' or is 'poorly optimised', they're showing that they don't understand what they're talking about. The game is extremely optimised to entertain people who enjoy solving puzzles and manipulating systems. The AI is dumb because that helps make it consistent; which makes it easier to understand and predict. That's not a bug, that's not "lazy", it's a feature! Stonehearth does not, really, sit there and go "I think I'm going to cause problems for this player" -- occasionally it throws some semi-scripted challenges into the mix (enemies, harsh weather, etc.); but it never actively sabotages the player's designs. It never creates inefficiency, or makes a mess on its own. That's always a result of player choices.
And here's my ultimate proof of that: if you set up a tiny self-sustainable town using your starting citizens, on peaceful mode, creating just enough food to keep them all alive (and I mean perfectly calculated maximum stock numbers on your cook recipes, with exactly the right amount of farming, and exactly enough furniture like beds and tables and chairs so that the hearthlings have obviously marked places to gather for eating or to go to sleep), then it will run indefinitely without lagging out. I've done it! I set up a tiny little village for 6 hearthlings (cook, farmer, carpenter, mason, and 2 workers), feeding them on veggie soup (auto-stock 12 bowls, with 2 7x7 farms -- one for carrots, one for turnips), with every hearthling assigned a bed and 2 dining tables with 3 chairs each, and 3 small crates each at the farms and in the kitchen (this was done before input bins even existed -- so I expect that the ratio of food to hearthlings is a little different now, and probably very different if using ACE.) I just left it running all day in the background while I did other things; and at one point a full 48 hours with no breaks. Every time I came back to it, there was no lag and no issues. The worst side-effect was that I sometimes had hundreds of notifications waiting for me.
The problem with Stonehearth isn't "memory leaks", it's player neglect -- the computer is fed so many tasks that can't possibly be completed, and it can't completely forget about them because the old tasks might interact with the newer tasks that the player gave while the game was still figuring out the previous ones. That's the big secret to the "memory leak" -- it's just what happens in old cartoons where an evil computer is defeated by opening so many program windows that it lags or crashes. Only in this case, instead of infinite numbers of low-memory programs it's one program with memory use that grows larger than the computer can handle because the player keeps adding more things to keep track of. It can easily be avoided if the player simply understands how to let the computer clear its memory, and by not assigning jobs that will never be completed and will stay around sucking up memory forever.
No amount of optimisation or good design can prevent an idiot user from doing that. And, in my definition, anyone who refuses to learn from their mistakes is an idiot -- hence why I classify people like the OP under that banner.
My core premise about "learn how to play the game" stems from the fact that the only reason the game becomes unstable is because people create those "crash the computer by giving it too much work to do" scenarios within the game. It's not just that work gets done faster when it's easier; it's that more difficult jobs/jobs that take longer will naturally put more strain on the computer! Add that up for every item, entity, event, building, etc. that the game has to keep simulating... and it's not like each of those simulations can nearly be packaged into their own little boxes either! Everything in Stonehearth is interacting with at least something else; and it's those interactions which really become expensive to compute.
There is no problem with Stonehearth's code that will cause an issue if you play the game in a basically sensible manner. The only time that the imperfect nature of the code becomes an issue is if you're already making some really dumb decisions in how you play. And yes, not everyone is going to be an expert in logistics or project management or problem solving at the start... that's why you learn as you play. You ask "what went wrong, and how might I avoid it?", not assume that the game is at fault. Because 90% of the time, it's not! And I say this as someone who learned how to play the game "the hard way", through lots of trial and error and observation. I didn't start out having no lag; but the things I knew from other games did give me an advantage in figuring out how to avoid lag once I knew where it was coming from. I then had to learn what causes Stonehearth to become laggy, and figure out if it was something the game was doing wrong or something I was doing wrong. Well, in the vast majority of cases, it turned out I had been doing something in a less-efficient or totally inefficient way. Once I figured out a better way... the lag decreased. And after literally years of repeating that cycle through the Early Access and beyond, I've found ways to avoid most if not all of the things I used to do which used to cause lag, without having to sacrifice the way I want to play the game. I can still do the things I want to do; I just have to work within the cause-and-effect rules.
So no, I don't believe there is a "problem" with the way Stonehearth is made. It's imperfect, sure, just like every other thing ever made. Nothing we make -- and especially not complex things like videogames -- is able to be built without compromise and mediation; there's no such thing as "perfect code." But I'm able to use Stonehearth exactly for what it's intended for, without any blockages or interruptions, once I know how to operate within its rules. The game doesn't crash or lag when I do nothing; in fact it extremely rarely lags for me at all, and the only time it crashes for me now is when I'm doing something ridiculous like deleting an item in the middle of it being used for a crafting task to test whether the game can recognise that the item no longer exists.
Would you say that a hammer was poorly designed if someone tried to use it to cut down a tree and that took a long time? Because that's the kind of situation I'm talking about here! Stonehearth is designed to create an experience that gets the player thinking, that creates stories and then creates tension/conflict and then lets the player resolve it. It's not designed to create a story without challenges -- if it were, then the devs could easily have left out all of the challenging parts and left the game in a sort of "creative mode" where everything just happens when you press the button. But instead, what we see again and again when people complain about lag or "the game not being made well" is that they're giving task orders with no thought to how those tasks will actually be achieved. They're playing a management simulation game like it's a building sandbox game with creative mode.
I didn't bother correcting you about the "infinite dots" thing -- clearly there was a miscommunication since I wasn't saying that the old dots were deleted when they were overwritten; I meant infinite new dots being drawn over the top of old ones... so imagine it slowly turns the screen from black to white by filling in first red, then blue, then green; but with every possible combination until the memory buffer overflows. And yes it would be easy to avoid that by having only the most recent result be remembered and clearing the outdated info... but that's not the point -- the point of the hypothetical simulation is to prove that even the most simple data can clog up and crash a computer if there's too much of it. And, as I explained just after (which you've conveniently ignored here), there's a good reason that Stonehearth can't always delete the old data about how different items and active tasks might interact even if the task or item no longer exists. As long as any part of a task wasn't completed, and the task itself hasn't been completed some other way, the computer doesn't know whether it's safe or not to clear that task out of its memory yet. Let's say you have a tree that you order to be chopped down; but the tree gets struck by lightning before the job is done. Now, you have a tree that no longer exists and a job that can't be completed; but because job allocation might be handled in a part of Stonehearth's program that is currently busy allocating other jobs, the "garbage collector" may not be able to get into that bit of memory and delete every reference to that job. That's how "junk data" can build up even when there's already a garbage collector running to help prevent that -- sometimes it's not possible to actually collect the garbage because that's not safe for the rest of the program. That's why it's important to shut the game down every so often -- as part of shutting down, the simulation is paused and the garbage collector can get into all those places it normally couldn't for risk that it might delete data that's actually still in use.
As far as Basic still being binary... yeah, but Stonehearth isn't running in Basic is it? The reason I brought up "computers are not smart" and still maintain "but they're not just ones and zeroes either" is to highlight the difference between how computers work vs how humans work. Humans have intuition, long-term memory and muscle memory; we can learn things and then recall them without having to look up every individual path of how we got to that conclusion. A computer, by contrast, has only short-term memory and a kind-of long-term memory with no links between. A computer can "know" a conclusion it's previously calculated, but it can't remember why it knows that, and so can't apply that same conclusion to a similar problem like we can. In fact, when that happens in a computer -- i.e. when the answer to a previous calculation is applied to a different calculation -- that's a bug! And such bugs are commonly exploited to achieve unexpected or impossible results within a program; e.g. how classic Mario and Zelda game speedrunners use "memory value storage" exploits to store some arbitrary value and use it somewhere unintended to get a "wrong" result they want. Stonehearth avoids that kind of thing by keeping every "answer" it comes up with in its own secure box so that it can't end up somewhere it's not supposed to... but that also means the answers can't "talk" to each other and go "hey, I've just done this calculation 3 times and the answer has always been X, I can skip the calculation and just use X to save time!" the way that humans could.
So no, I'm not yielding that you're correct on subjects that I didn't respond to -- I chose not to respond to them (and I'm not going to bother responding to any of the ones I've missed here) because, frankly, you're shifting the goal-posts and ignoring the key point that Stonehearth works within a set of defined cause-and-effect rules; and that when you play within those rules the game runs just fine.
Yeah, it would probably be a good thing to have a tutorial that reminds players "hey, it's a good idea not to give the hearthlings more jobs than they can actually do!"... which is exactly why I suggested that to the devs multiple times during the Early Access period. It turns out that they had higher priority jobs, like making sure the game had an end-game or trying to keep their studio afloat; and so they never got around to adding a tutorial specifically to teach people the most common-sense rules of design and project management. Now, in hindsight, it's probable that the game developers behind Stonehearth over-estimated the capacity of non-developers to understand that overloading someone (even a virtual worker in a game) with too many tasks is a bad thing. I guess that the devs expected players to be a bit smarter, and not (as Einstein put it) "do the same thing over and over and expect a different result."
And again; that's exactly where I started out with this game -- I've made every mistake, every poor logistics/planning choice you can possibly imagine. I didn't understand how anything worked. The only difference between me at the start of playing Stonehearth and the OP of this thread is that instead of blaming the game and assuming it was broken, I just assumed that I'd missed something and tried to figure out what it was. And it worked. And now, I know so much about how Stonehearth works that I actually started to find out about things like what a race condition is in programming, or how memory overflow happens, or how the computer might not know to delete a task once it's "done" because the flag for "hey this is done, you can forget about it now" might have been bypassed.
And yeah, sometimes you get unexpected edge cases. Some things are impossible to foresee. But that doesn't change the fact that those edge-cases can only happen when the player deliberately avoids learning and improving. Even when there are small errors, the game is resilient enough to keep running with them "stored away safely" so they don't cause crashes or lag. The only time they become a problem is when players create so very many situations that cause small errors that the small errors pile up into bigger problems like memory overflow, or unsolve-able paradoxes, or such.
So, again: Stonehearth works just fine (and is actually extremely robust and full of "safety net" features to protect against small mistakes or less-than-ideal player decisions) when the player makes any kind of effort to play within the game's rules. It's only when players ignore the obvious things (like "hey these trees haven't been chopped yet... I'll order them to chop even more trees, surely that'll speed up how fast I get logs!") that the game starts to run into problems.