Not too long ago, I posted a video showcasing how our settlers' movement is simulated in the game. We've spent a significant amount of time implementing dynamic entity movement and building infrastructure around it. A lot of our efforts were fueled by our dislike of zigzagging. But there's more to it than that. Today, we're going to discuss why we built a physics-based world to simulate the movement of settlers and similar entities.
First, we need to understand a bit about zigzagging. Zigzagging is seen in many games, including some fantastic titles in colony simulation like RimWorld and Dwarf Fortress, as well as recent titles such as Stonehearth and Going Medieval. If you were to peek under the hood of these games, many implement character movement using a tile system. There are advantages: it's simple to build a navigation solution on top of it, and it's easy to dynamically update. However, during our early development, we noticed some issues with this approach:
1. Visual fidelity:
Traditionally, a simulated world is represented by more simplistic visuals. A tile map is a reasonably good abstracted interpretation of a world, especially for games focused on depth and complexity. However, issues arise when trying to bring colony simulation into a 3D-rendered world. Any discrepancies become much easier to notice and break the immersion of the game: settlers floating on top of a slope, making odd 45 or 90-degree turns, and even walking into each other. Some existing games use techniques by having smaller tiles or smoothing out the turning. This masks the issue graphically, but what about the gap between gameplay and visuals?
2. Gameplay:
StarCraft 1 also used a tile system for its maps. Units often got stuck, and micro-management was difficult. One change they made in StarCraft 2 was the introduction of steering behaviors and a navigation system based on that. What's more interesting than a smoother player control is the fact that Zerglings automatically surround enemies as a result of emergent behavior. By providing a more realistic simulation, we could see more emergent gameplay without special design. In Timber & Stone, settlers can easily get stuck on floating blocks, but what if settlers could jump because the steering mechanism knows the height is safe? What if settlers could smoothly avoid bumping into each other because the steering mechanism factors in crowdedness?
A physics-based simulation for the game world allows us to have a more accurate visual representation and more simulated detail without explicit planning. We want to give you, our players, a more immersive experience with better visuals and engaging emergent gameplay that feels natural.
However, an idea remains just an idea without careful design to make it a reality. In our next blog post, we'll delve into the details of how we made it happen, discussing the techniques and tools we used to bring our vision to life. And of course, we'll explore what this means for Satus' future and the exciting possibilities and challenges it opens up.
Stay tuned for Part 2, and as always, we appreciate your support and look forward to sharing more of our development journey with you!