Hey Everyone, Alpha 18 is coming along! This week our work is pretty evenly divided between Alpha 18 features (continued work on building removal, fixes for landscape scarring, performance optimizations, gameplay instrumentation, and a little bit of tutorial work) and long term, multi-alpha projects (animation pipeline optimizations, continued world-edge artistic explorations, and a hearthling reachability service, which should help with even more performance issues). This week, let’s take a closer look at why Stonehearth can sometimes get laggy/stuttery/crash-prone on very large saves and late-game towns, and all the work that Yang has recently done for Alpha 18 to understand and reduce these issues.
Reclaiming Lost Memories
Recap from the video:
- This save is Konistrapolis, by community builder Kythandra! It’s an amazing city!
- We love all your giant saves and cities because they inspire us… and inspire us to fix things.
- Large towns like Konistrapolis can stutter/slow/even crash to desktop on older machines. Why is that?
- In a simulation game like Stonehearth, everything you see in the world: logs, trees, terrain, buildings, windows, furniture, people everything–has data associated with it: what model it uses, how big it should be rendered, where heartlings should stand when they’re interacting with it, etc.
- When you play the game, this data is stored in the Memory or RAM, of your computer. If you have a lot of things in your game, and the game’s memory usage begins to approach the total amount of RAM on your computer, or the amount of memory that Windows has allowed Stonehearth to be able to use, the game begins to stutter and lag, because it becomes harder and harder for the game to find the relevant data it needs to draw the simulation to screen.
- If the amount of memory used by the game ever exceeds the amount set aside by your computer for it, the game will crash to the desktop.
- Preventing these crashes is one of the reasons that we implemented inventory caps a few alphas ago: if you leave Stonehearth running and then come back three hours later, for example, your farmers won’t have accidentally crashed your computer by created three hundred thousand carrot baskets.
- Inventory caps are performance-changes-enforced as gameplay; we intend to revisit them in the future with more organic gameplay reasons to keep your town inventory under control.
- A much harder, but arguably better way to solve the performance problem is to go through the code with a fine toothed comb, looking for ways to reduce each item’s memory footprint.
- Wooden logs are some of Stonehearth’s most basic and plentiful items, and they use the same data structures as many of the more complex items in the game.
- Yang has created a test world that spawns 10,000 logs. To fix memory issues, she records how much memory they use, makes changes to the code to reduce the amount of data we store for them, and then runs the test again to see how much the footprint has decreased.
- If you run our debugtools mod, you can see that each log maintains a lot of information in a structure we call “components.” Components are very flexible; they allow us to manipulate the data on an object and make that object behave according to the simulations of the game: physics, usage, crafting etc.
- Yang has been slowly going through and pruning out unnecessary components. For example, the unit_info component used to let you store and change an items name, portrait, and description. This is important for people and pets and monsters, whose names and portraits might change. This information, however, never changes for objects like logs, so for all objects like them, she’s removed their unit info component and is instead storing this data in a much more efficient read-only structure called entity data.
- Yang has made similar optimizations to other components that used to be on all things but that, after her changes, are only on the few items that really need them. For example, items used to have a material component, but in Stonehearth today, an item’s material never changes, so this too, can move to memory-efficient read-only data.
- The model variant component, which stores the appearance of an object, is now just stored once for all objects of a type.
- The render info component, which listens on model changes, only does this for models that actually do change, like berry bushes.
- The destination and adjacency regions for interactable objects like trees and workshops also almost never changes, so this data too is now read only, and the full component only continues to exist on things like buildings and stockpiles, where the place a hearthling should stand relative to it is always changing based on the state of the building.
- Yang also turned all the booleans on mob component, which tracks placement for all objects in the world, into bits, so they’d take up less space.
- She’s also made the navgrids, the objects that make up the terrain of the world, only store speed modifying data whenever it’s needed, instead of all the time.
- These sorts of changes are like performing live surgery: carefully, painstakingly changing the way the code works, without changing it’s function or introducing new bugs. But in the end, it’s well worth it–Yang’s log tests yielded an impressive 20% improvement, for example, in the memory footprint of static objects, and a whopping 50% improvement in nav grid tile memory usage.
- Overall, we think the total memory improvements across all elements of the game is thus far about 10%, which means a total 10% increase in the number of things you can amass before the game starts to slow down for you.
- Yang being Yang is completely unsatisfied with her work thus far, and will soon turn her attention to even more complex areas, like building. “I keep hoping to find the golden goose” she tells me, “but in the meantime, I will keep selling the regular eggs.”
Other Announcements
This week, streams should happen as usual.
Next week, streams will happen on Tuesday and Wednesday as usual, but not Thursday, as the team will be out at PAX.
The week after, we will still be out of the office on Tuesday 9/6, so there will be no stream and no Desktop Tuesday on that day. Streams will resume on Wednesday, 9/7, at their usual time.
See you online in a bit!