Other Announcements
Next week, we’ll skip Desktop Tuesday on account of American 4th of July. Desktop Tuesday will therefore return the week after, on Tuesday, July 10th.
Thursday streams, however, which happen at 6:00pm PST on www.twitch.tv/stonehearth will continue as usual. See you there and see you in two weeks!
I enjoy seeing explanations and tests such as the inventory director, that is quite a performance improvement.
I’m curious what the biggest CPU hogs still are and where the next improvements are expected, but also what we can do as players to help make life easier for our hearthling buddies brains.
Has the team figured out any examples of a design pitfall that results in slowdowns at 40+ hearthlings?
Is the use of input/output storage helpful to hearthling AI prioritizing tasks?
I’d imagine that path finding is still significant, and seems to be an A* algorithm. Is any pre-processing done that takes advantage of roads to simplify the graph? If so could we be using roads to improve not just the logistical efficiency of our village but the computational efficiency as well?
As one anecdote, I’d observed long ago that having my windows just one block above the floor allowed hearthlings to travel through them instead of the door. While this might have been more efficient pathing, it wasn’t really a desirable behavior, and changing my building architecture to keep windows two blocks above the ground seemed to improve performance.
The timekeeping/timers/alarms system is a bottleneck. We are considering moving it from Lua to C++.
The coroutine/thread management is also a bottleneck for the AI (each entity runs their AI on a separate coroutine). We are considering moving this one from Lua to C++ as well.
The effect system (animations, VFX, SFX, etc.) uses a lot of indirection and strings. We could probably optimize common paths there to avoid that.
There are a bunch more. If you look at the video, there are shots of a spreadsheet where we track all this stuff.
Changing reachability is a major source of overhead. E.g. if you block off or unblock a large area, a lot of previously cached results are no longer valid and that forces a lot of recomputation.
Tons.
A lot of low level systems are in Lua for no good reason.
The AI is implemented such that every agent is truly independent, running on their own coroutine, which is cute, but horrible for performance.
For data transfer between the client and the UI we use JSON over HTTP, which is crazy in itself, but we also use a really terrible JSON library which unfortunately has infected too much of the codebase to effectively replace.
We use strings all over the place. It works better than I would have expected, but we should have been much more conservative with them.
The simulation is non-deterministic, so performance is inconsistent and hard to plan.
In the old restock system, that would have been harmful to performance. In the new one, it basically doesn’t make much difference.
Yes. We maintain a navigation graph. Doing that takes most of our non-Lua CPU resources.
@max99x I still have problems with slow gui over time. What can I give you as clue?
Thanks for offering to help! Right now we have a pretty good handle on the causes of UI performance issues though. You should see some improvements for the worst cases in the next couple releases.