Hey everyone! Stonehearth Alpha 14 is now officially on our Steam stable branch and on your Humble Bundle download pages. This week, the team moves officially to Alpha 15 development, so our Desktop Tuesday investigates what we originally wanted to do for Alpha 15, why we decided to focus on performance instead, and how we plan to maximize our time and efficiency.
- This video shows off Crushinator, a stress test environment Chris wrote to simulate performance load from a mid-to-late end Stonehearth game
- Crushinator fills the world with hearthlings, and gives them varied building/farming/crafting tasks
- As you can see from Crushinator, and from your own games, Stonehearth gets pretty laggy a 20+ hearthlings and with tons of things in the world.
- This is a problem because our original hit list for A15 (ranged combat, advanced building, etc) were all mid/late game features, and we’d never be able to prototype/implement/test them with the game running as it does. If we prototyped them out in test worlds, the game would still lag out before we got to see how they played in a real game, and we’d never be able to balance/playtest them.
- We decided to focus A15 on performance, so that we can unlock all the other things we want!
- So, why does having a ton of hearthlings make the game run super slow?
- Stonehearth is a simulation game, so each entity in the world is backed by hundreds–or thousands–of lines of code that determine how it react at any given moment
- Code turns into equations that are run by the CPU
- All the entities in the world share the CPU’s equation-solving power
- If you add more entities to the game, or more gameplay logic/code to each entity, the CPU eventually starts falling behind, and the simulation slows down. The game becomes unresponsive, or hearthlings stand around doing nothing.
- This is the definition of a hard and complex problem that affects every system in the game
- TLDR: adding more entities and complex AI to the game causes it to slow down
- The Solution:
- Everyone gets a bigger CPU or waits 10 years, for average CPUs to get faster (just kidding!)
- Team Radiant finds out what’s taking up the most CPU time, and re-writes those things to be more efficient. (Which is, of course, what we’re doing.)
- To find out what’s taking up CPU time, we run the game in a way that produces lots of lag (that’s Crushinator’s job, though we’re also happy to use giant savegames from you!), record everything that’s happening, and dump the output metrics into a profiler.
- We use lots of different profilers, but right now, our lua code is the primary culprit, so we’ll be spending a lot of time in our lua profiler, which Tony put together for us.
- The lua profiler shows us which functions are hogging the most CPU time
- Then we have to find new ways of writing those functions so that they take less CPU time.
- Then we run the profiler again and see if we succeeded, and run the game and all the tests again to see if the new code is as correct as the old code.
- It’s a lot like when you’re playing a puzzle game, and you think you’ve found the solution, and then you discover you should have been able to solve it in half the steps.
- Sometimes it’s fun! Sometimes it’s tedious and meticulous and hard. But if it’s what we need in order to get to work on more cool features, we’re all in.
Crushinator clearly is not as complex as an actual mid-to-late end game. So if you’ve got a save from Alpha 14 that’s laggy and slow, but otherwise bug-free, upload it to this thread and we will use it to discover what we can optimize.
In the meantime, if you haven’t yet checked out Alpha 14 on Steam, please do so, and let us know what you think!