How to Read This Roadmap: Missions and Features, Scheduled & Proposed
Welcome to the Stonehearth Development Roadmap, Version 2.0! From our first Roadmap, we learned that game design is an iterative process. To best reflect the team’s current goals for the game, and the way our schedule changes to accommodate your feedback, we’ve created a second roadmap in which:
- Missions are now written around large, aspirational gameplay goals (like “Engage with Hearthlings as Individuals” and “Classes are Distinct and Useful”) instead of individual features (like “Pets” or “Magmasmith”).
- Feature lists live under each Mission, and enumerate features we think will help our game achieve the Mission’s gameplay goals.
- Scheduled features are ones we’re targeting within the next three alphas. There are very few of them on purpose, because our schedule changes based on your feedback, and what we think will best benefit the game at that time.
- Proposed features are ones we think we’ll want eventually, listed in priority order. The proposed feature section may grow or shrink or become reordered as we build the game and assess our success at meeting our gameplay goals.
- To emphasize the fact that our schedule of work and even our goals are fluid based on the current state of the game, and your feedback, only Missions with scheduled features appear in the graphic. More of the graphic will appear as we progress through the Missions!
- Missions and features that are not yet scheduled may change in response to gameplay feedback, and we may add more Missions at any time.
- Gameplay must be developed in a well-rounded fashion, so we can evaluate systems as a whole experience. As a result, we may work on features from many Missions before finishing all the features in a single Mission.
TLDR: Our biggest goal as a team is to make an enjoyable game, and we want our roadmap to reflect this. We also want the roadmap to reflect the fact that the features which achieve our goals may change as our understanding of the game changes. Cool? Proceed to the detailed breakdown of Known Missions and Features. More questions? Jump to the FAQ below.
Missions and Features
Mission: Engage with Hearthlings as Individuals
Hearthlings are at the center of the Stonehearth experience. They should motivate your town optimizations and raise the stakes on success and failure. To do this, we should create relatable hearthlings with unique personalities to increase your attachment and reinforce you for optimizing multiple gameplay systems.
- Mood (Done!)
- Rescue (Done!)
- Traits (Done!)
- Interactions (In progress!)
- Starting hearthling numbers
- Social relationships
- Awareness of beautiful things
- Awareness of wealth
- Animal tamer
- and more…
Mission: Construction is Intuitive & Rewarding
Many of you build as an act of self expression. Our game has a uniquely powerful 3D building ability, but its full potential is obscured by a lumpy user experience. If we can fix all the existing UX and AI/algorithmic roadblocks, we should dramatically increase our resonance with players of all ages who love building. Subsequent sub-goals will involve motivating building via gameplay.
- Dependency Analysis (Done!)
- Topology service (Done!)
- Reduced object complexity (Done!)
- Pathfinder pathmaker service (in progress)
- Simplify scaffolding
- Tune AI in building
- Address building UX pain
- Gameplay-motivated building
- Item placement UX
- Hearthling opinion of rooms
- and more…
Mission: All Activities Enhance/Celebrate Progression
Growing your town should be the result of hard work. Each item in the game, whether it is crafted/bought/grown/looted, should contribute significantly to gameplay, either because it unlocks functionality, or because it represents your town’s achievements.
- Effort-based crafting
- Upgradable workshops
- Item cost review
- Refine base resources
- Material acquisition mechanics
- Revisit items
- Inventory gameplay
- Equipment, stockpiles
- Recipe acquisition
- Costing buildings
- Research tree
- Revisit tiers
- Daily update
- Net worth
- and more…
Mission: World Interacts with You
The world of Hearth is more than just a static puzzle to be colonized. It must be a rich, interesting, and living backdrop for your town and its inhabitants. It must impose challenges in fair and learnable ways, and it must react in response to your hearthlings’ actions. Each game in it should offer unique experiences based on your kingdom choices, and on the world around your settlement.
- Clean up water service backend (in progress)
- Water gameplay
- Plant and Animal lifecycles
- Northern Alliance
- Rabbit People
- Alternate Planes
- and more…
Missions below this line do not have any features that are scheduled yet. They and their features, as well as all proposed features above, are subject to change as we discover more about the shape of the game.
Mission: Core Interactions are Intuitive
Games of indirect control, like Stonehearth, are less immediately intuitive than games of direct control, where you select each character’s actions. On the flip side, they allow players to execute large, high level tasks with ease. Given these predilections, interacting with your town should be easy and intuitive. You get easily consumable information about what your hearthlings are doing and why. We should fix AI designs that cause them to behave in universally undesirable, if logically correct, ways.
- Fix unintuitive hauling actions
- Tune task priorities
- Re-examine task/job assignments
- and more…
Mission: Classes are Distinct & Useful
Each class must noticeably improve your town, unlock new gameplay options, and be distinct from every other class. We must understand the space of possible classes, and each class should fill a niche in this infrastructure.
- Unlocking classes
- Class levels
- Revisit farmer
- Revisit trapper
- Finalize crafters
- and more…
Mission: Surviving vs Thriving
Merely surviving in the wild should mean balancing and mastering a number of interlocking systems like food, rest, and danger. There should be many different ways to establish basic functionality based on your specific starting hearthlings and desired playstyle. Even without external threats, basic survival should be a challenge that can increase/decrease in intensity based on desired difficulty.
- Tune food
- Fog of war
- Attributes systems
- Colony density
- Difficulty levels
- and more…
Mission: Setbacks Challenge Growth
Your town will be challenged by external setbacks like combat and natural disasters that create opportunities for epic stories. These setbacks should vary in intensity based on the player’s desired challenge level, but should always be both enjoyable and interesting. Some setbacks should be unexpected, and others should be opt-in.
- Revisit combat
- Update combat UX
- Combat classes and tactics
- and more…
Mission: Art Goal – Add Atmosphere
Screenshots of Stonehearth are super green and full of jagged edges. Updating our game to have some of the basic artistic niceties of other games should offer massive improvements to tone as well as opening up gameplay options like darkness, fog of war, and more.
- Atmospheric scattering
- and more…
Mission: Performance, Optimization, Tools, Engine Enhancements
There are always a number of ongoing tasks that can make our engine more efficient. If working in the engine is easier, we produce more bug-free code. We also need to make tools for our artists, and make sure to pay the overhead cost of staying up to date with libraries and operating systems.
- Isolate rendering layer
- Bug-capture tools
- Animation blending
- Animation state machines
- More efficient traces
- Multiplayer tech prototype
- Memory allocation improvements
- Sampling profiler
- Multithreaded pathfinding
- Dependent libraries
- Refactor C++ for portability
- Copy on write for shared components
- Mac/Linux port
- and more…
We have a lot more goal-driven Missions in mind. For example, multiplayer, metagame systems, artistic improvements, etc. Expect us to add additional gameplay oriented Missions as we come to understand them.
Road Already Traveled
We’ve come a long way from the first version of our Roadmap, which inherited from the Kickstarter feature set. Let’s celebrate this work properly!
Goal: Establish Basic Engine
Completed Features: Saving and Loading, time controls, combat engine, lots of performance work, storage performance, backwards save compatibility, pathfinding
Goal: Base Classes
Completed Features: Worker, Farmer, Weaver, Footman, Trapper, Shepherd, Mason, Blacksmith, Cook, Potter, Herbalist, Cleric, Archer, Knight
Goal: Basic Houses, Castles, Bridges
Completed Features: Basic building, roofs, foundations, non-square polygonal floorplans, ability to see inside buildings, clay, wood, stone materials, multiple stories
Goal: Starting Monsters and Denizens
Completed Features: Ascendancy, Animals, Pets, Rayya’s Children, Roaming Monsters (entlings, stone golems, giant zombies, varanus, necromancer, orcs, kobolds, ogres)
Goal: Basic World Generation
Completed Features: Above ground resources, mining, underground resources, water, customizable embarkation, temperate biome, desert biome
Goal: Game Master Foundational Tech
Completed Features: Scenario API, Seed world with scenarios, scenario randomization, chaining and branching scenarios, new enemies, raids, and ambient encounters, new combat mechanics part 1, combat part 2, ranged combat, build lots and lots of scenarios
I feel like your progress has slowed way down since Alpha 19, and this roadmap shows that it’s going to be a long time before I see the next feature I want (Titans, Northern Alliance, etc.) in the game. How did this happen?
We feel your pain. We’ve pivoted our goals to be gameplay focused instead of feature focused, so if you’re used to tracking our progress in terms of features, it’s natural that it looks like our progress is very slow. If it helps, try asking, “What does the game need for the feature I want to be really cool?” and then look forward to that, as well.
You’ve pivoted from feature goals to gameplay goals? Again, how did this happen?
I’ve talked through this topic last August, and again last January, but if you’d like to hear it again, in greater detail, this is what happened: In August of 2016, our team began to work on end game content. We were incredibly excited about this—we had just shipped the engineer, who introduced siege mechanics, and we were set to do three titans, the magmasmith, the geomancer, and the Northern Alliance, all by Christmas. We were incredibly pumped because we’d been looking forward to making this content for three years, and we felt like we’d finally fixed enough bugs to make the game stable enough to really enjoy. Here’s the problem—as we got deeper and deeper into titans, which we wanted to be epic, unique entities that you had to defeat in various ways, we realized that we were essentially writing three different mini-games that would bolt on to the end of your Stonehearth experience. We didn’t want this; we wanted titans to feel like the epic conclusion to all your previous hard work; we wanted you to have lots of different ways of defeating them. But nothing we designed felt like it built satisfactorily on the systems that already existed. At the same time, you were giving us feedback about the engineer—about how it felt bolted on, and about how it didn’t contribute significantly to the complexity or balance of combat. These two things seemed related, but we weren’t sure, as a team, how to fix the problem. It was time to get some outside help.
After taking feedback from you in our forums, and from professional game system designers with credits ranging from Sim City to Bioshock Infinite, we realized that Stonehearth was great at evoking a mood of warmth and coziness, but that its fundamental gameplay loop needed to be a lot richer than it was in order to support a satisfying and emotional/tactical conclusion. Previously, we’d developed all our simulations in silos: building, farming, trading all were separate systems that did not interact at all with each other. All the system designers we spoke to were in unanimous agreement: we needed to tie them together through a unified system that would also provide micro-goals and moments of challenge and celebration throughout the game’s arc. Richard spoke most precisely about this, so we asked him to come onboard and pave our way forward.
So this is why you’ve been working on hearthling mood, traits, and interactions?
Yup! The hearthling mood system is the first pillar of this new gameplay loop. It is set up to be the mechanism by which your hearthlings will give you feedback on all the systems in the game and how you might want to optimize them. The trait system allows hearthlings to give you feedback on different aspects of the game based on their inclinations, and the coming conversation system will celebrate the things that you’ve accomplished and experienced, all from your hearthlings’ POV. This sort of work isn’t as showy as terrain or water, and it won’t pay its full dividends until every system you see in the above roadmap is revisited to match. However, without it, any new system we add will feel bolted onto the experience, and will not contribute to a satisfying end state. We still want to get to these things, but we need to do this stuff before that stuff will feel satisfying.
Why has it been a year since your last update to the roadmap?
As I mentioned above, we’ve pivoted from feature-oriented goals to gameplay oriented goals. Our original roadmap, which was very feature oriented, did not contain all this new work, and we weren’t sure how to update it until we had a better understanding of our new priorities. We’ve got that now, and a way to describe the fact that our work has been highly iterative, and therefore subject to continuous schedule-modification.
What other issues did you have with the old roadmap?
The largest difference between the new roadmap and the old one is that the new roadmap’s Missions are written around gameplay goals (like “Engage with Hearthlings as Individuals” and “Classes are distinct and useful”) instead of features (like “Pets” or “Magmasmith”). Writing our old Mission document in terms of features tempted us to create features just because we wanted to see them in the game, not because they actually advanced their true function. For example, let’s go back to the engineer, which is a class we’ve always imagined would make end-game combat more interesting by introducing siege mechanics, and that would make your cities more interesting by introducing clockwork elements. One of the reasons I believe this class had trouble last year was because we built it in a class-centric way: figuring out how the engineer’s items, workbench, and turrets would fit into the existing game, instead of first ensuring that combat and building were robust enough to support siege mechanics, and then creating a class which unlocked that behavior. In this roadmap, you’ll find the engineer under “Classes are distinct and useful” which implies that we’ve analyzed the possible gameplay space, understood how classes can contribute, and found a niche for each.
What happened to the % complete items? How do we know when you’ll be done?
Since the roadmap’s Missions are now experience goals, we’ll be done when the game achieves those experience goals. What features will actually achieve these goals? Well, we have proposals, but we won’t be sure till we implement them, so we can’t tell you our % complete because we honestly do not know. To best represent this, as we schedule features that satisfy each experience goal, we’ll add a square to the graphic under that goal. As we finish features, we’ll check off the squares. If we find more features are required to achieve the goal, we’ll add more features to the schedule, and add more squares. If we did this with % completion as we did in our old roadmap, the % would fluctuate a lot, and go backwards whenever we realized we had more work to do. For example, let’s say we thought we needed to do 10 things to finish “Hearthlings motivate player action.” If we finish six, we put that you’re 6/10 or 60% of the way done. If we get feedback that we need to try completely different features to achieve these goals, another 10 of them, suddenly the completion bar becomes 6/20 or 30% of the way complete. This new system better celebrates the work completed, without making statements about the amount of work remaining.
You say these are suggested features? Does that mean I might not get a feature I really want, or that you’ve previously promised?
Our first priority is to make a really good game. It might be the case that we consider a feature (very carefully!) and realize that it does not actually contribute to making this game better, or that our time is better spent on another feature that moves the gameplay experience forward more significantly. Removing features or rescheduling them for later is something we take very seriously, and we will only do it if we really think the game would be better either without it, or if we spent our time elsewhere first.
What if I want to suggest a new feature, like fishing?
We love hearing about features you’d like to see in the game, so suggest away! However, it might help to figure out what gameplay goal it satisfies, whether this is an existing one, or a brand new one we haven’t thought of yet.
No but really, when is this game going to be done?
This roadmap represents a ton of work, and the fact that we don’t yet know what all that work is going to be. Suffice to say, we’re going to be here for a while—years for sure—and progress may seem slower than it was before, because making a good game sets a higher quality bar than making a game with tons of flashy features. However, as a team, we’re confident that this pivot represents a path to a stronger, better, more enjoyable Stonehearth. Instead of giving you a date, we pledge to be as transparent with our process as possible, so you can be just as informed as we are about when we’ll finish, and to get you builds of the game whenever we have them in a sufficiently stable state, so that you don’t have to wait till it’s done, in order to enjoy what we do have. As always, thanks for taking this journey with us. Since starting to work on Stonehearth, our lives have changed multiple times, and we’re grateful to be sharing these moments with all of you.
Where is Multiplayer?
Don’t worry! We’re still very interested in exploring multiplayer, but multiplayer is a feature, and as we describe above, we are now building towards gameplay goals. We aren’t fully sure yet what gameplay goal multiplayer satisfies. Does it let you chill out with friends while playing Stonehearth? Is it a means of sharing creativity? Is it a way to crush your opponents online? We’re going to do some explorations to see what seems interesting, and those are filed under “???” because they could be any number of things. But If you’re passionate about multiplayer, help us out by explaining why you’re interested in playing Stonehearth with other people.
This is all well and good but why didn’t you do these explorations years ago? Why isn’t Multiplayer (or Mac/Linux or feature X) in the game YET?
Our team’s goal is to make a great game. Whenever we have to trade off between time and quality, we tend to pick quality. Whenever we have to decide between a feature that would be really awesome now, but may have to be re-written or revised later, and one that will set the tone for a great game going forward, we tend to pick the long-term solution, even though it may mean we have nothing to show in any given week or month. When we have to delay something we know you want, we do not do this lightly. We do this because we believe that you too, want a good game, rather than a mediocre one you could have tomorrow.
In the case of multiplayer, our game is still split into a client/server model so that we can support it as soon as we’re ready to put it in. We don’t have it in the game *yet* because as I said above our our goal is to make a really great game, and multiplayer in a community-builder is really complex! It’s so complex that when we started, we weren’t even sure if single player and multiplayer could exist in the same game, or if they’d need to be completely different modes with different gameplay metaphors. To prevent us from getting into a situation where we had two bad versions of the game, we decided to focus on single player and work on multiplayer when single player was complete. The good news is that Richard is a much better designer than anyone on the original team. As a long-term background project, he is now working on the problem of how or whether multiplayer makes our game a better game. When he has something that’s ready for feedback, you’ll be the first to know.
In the case of Mac & Linux, getting the game onto more platforms expands its reach, and therefore the quality of your feedback, but does not directly make the core of it better. We estimate we’d have to dedicate one engineer full time to the project to get it started and keep it up to date. As our team has 5 engineers on it, we’d be 20% slower on core features or have 20% fewer features as a result of expanding the game to that platform at this time. If you only have a Mac, I know this burns, but we believe this is the right decision for the game as a whole right now. If we manage to fund and hire significantly more engineers, this may change, and if so we’ll again, let you know.
Detailed Roadmap Trello Board
Our Trello board allows you to vote on missions and features you find exciting! We will periodically use this information to update our roadmap goals. Find it here: Stonehearth Community Roadmap.