Roadmap Update

Hey guys,

As you recall, in our last update we talked about how our publisher went insolvent and we have to work around a reduced Early Access budget as a result. Today I’d like to go into more detail on what that means for the roadmap, what our plans are for the initial release and what the implications of the new budget are.

As always, you can find the full roadmap over on our homepage at: https://vivid-storm.com/roadmap/

Base Management

This milestone focuses on building a home base and keeping your survivors’ needs met. At a basic level, you have your survivors with a basic set of needs: food, sleep, purpose, comfort and beauty. That means you’ll need to assign survivors work types they enjoy, provide them with bedrooms and dining areas, and farm crops to turn into meals and clothing. Failure to meet your survivors’ needs will lower mood and trigger mental breaks at lower levels. It expands on the base building we had in the demo with additional needs and more fleshed out mechanics.

Currently, the basics of survivor management are done. Survivors have inventory, customizable appearance and a basic framework for skills, needs and traits. We still need to refine some of the mechanics and expand them with additional traits and skills before we check off the milestone completely.

Since last update we finished off the agriculture milestone. You can now designate grow zones for specific crops, assign survivors to plant work and they’ll automatically go out and tend to the fields. The crafting system is in its finishing stages, once done you’ll be able to build workstations and assign crafting bills to convert raw food and resources into finished meals and items.

The milestone also includes a number of more basic systems, like pathfinding. Right now we’re using basic grid-based movement, and survivors have the ability to climb cliffs, stairs and ladders to move to different elevation levels. Long-term we plan to expand on this by adding slopes, climbing penalties and similar systems, but those will have to wait until post-launch. The lighting system has been done for a while and ties into a number of other systems: plants need light to grow, darkness reduces vision range and crafting requires you to see what you’re doing.

Still left to do are a number of more advanced mechanics like a structural support grid. Our building system already checks to make sure floors and walls you place are connected to something, but once combat mechanics are introduced we’ll need to include checks to see if the thing you just blew up was load-bearing. This can be performance-intensive, so we’re planning for some extra development time for optimization here. The other items left are roofs, an electric grid and a framework for rooms and environmental beauty. Depending on how much time we have by the end these may be more or less extensive for release day. We’d rather reduce the scope a bit and make sure the features we do include are properly polished and working than have a slew of half-finished features that don’t work.

The original roadmap included a milestone for weather effects that has been cut from the new version. They wouldn’t have had much gameplay effect but provided some nice visual ambience. Given that they’re not gameplay-critical for now we decided to remove them from the roadmap. Instead we’re going to bring them in as part of a larger weather-focused update in the future, along with related mechanics like temperature, fire, etc.

Raid Defense

This milestone deals with combat, vision and stealth. For the initial release we’re planning on a basic combat system with melee and ranged weapons, a simple medical framework and some initial faction mechanics. The vision system includes a classic fog of war implementation, requiring map exploration and a detection system for non-static entities.

We already started on a couple related features a while ago, notably the fog of war, but proper work on this milestone is only about to start now. For the combat system, we want to include some basic melee and ranged combat using a variety of weapons. We’ve experimented with some different approaches in the demo and have some changes planned based on that experience. We also want to include a loadout system to manage equipment: players can assign specific weapons, apparel and items to a survivor and they’ll autonomously pick up what they need from storage. This simplifies routine tasks like ammo management and should be familiar if you played some of our previous projects. More advanced mechanics like usable items, artillery, emplaced weapons and so on will follow post-launch.

The medical system is set to include some basic hit locations (arms, legs, torso, etc.) with a chance to hit internal organs. Depending on what is hit it will impart penalties on a survivor, cause pain and blood loss. While simple objects like plants will still use a simplified healthbar, survivors and animals will use this in-depth system for a more complex and interesting combat simulation. Eventually we want to extend this to include things like missing limbs, bionics, disease, etc., but for now we’re keeping it simple.

Non-player factions, their relation to the player and AI behavior are planned to be a big part of the game when it’s finished. For the initial release we plan to include wandering travelers who can visit the player base and spend some time before moving on. The player can trade with them, gather information about nearby points of interest or try to recruit them into his faction.

Depending on how much time the other features take up we may also include a hosting system allowing the player to provide lodgings to travelers and a basic raid system where hostiles attack the player base to kill what residents they can find or steal valuables from the player’s stockpile. Those features are not guaranteed for the initial release though.

Exploration

One of the core ideas behind the game is exploring a wider overworld. While we won’t be able to deliver a full-fledged world map with the initial release, we still want to include a basic expedition and progression system for now, using some placeholder UI and mechanics.

The idea for exploration is that the player can send expeditions to various points of interest. These points include various pre-collapse structures filled with useful items needed to progress through the game, and usually guarded by an array of enemies. Our concept for these is built around the idea of “parcels”, predefined structures created through an editor and placed procedurally around the map. This way we can combine the benefits of hand-authored structures with dynamic map generation that keeps every expedition unique.

Our focus for the initial release will be on getting the parcel editor up and running, and to set up the map generation algorithm to distribute them, along with various enemies and loot containers. We’ll also include a basic placeholder UI to select known points of interest and send out expeditions. In the future we want to replace this with a proper overworld map to traverse, but that is a major undertaking and will likely occupy multiple updates by itself.

The research system ties into this by allowing for the reverse-engineering of items you bring back from expeditions to unlock new structures, crafting recipes, crops, etc. For example while you may be able to research cultivation of basic crop types right away, unlocking more advanced crops would require bringing back sufficient seed material first. Looted weaponry may be taken apart to determine their make and unlock crafting of guns and ammunition, and so on.

Early Access

Finally, after the core gameplay is in we’ll need to take care of a number of things to make the game release-ready.

We have some ideas for an extended tutorial scenario, but to realize those properly we’ll need to have most of the mechanics already in place, meaning it will have to wait until we’re closing in on 1.0. Until then we’ll include a basic popup system to teach new players how to play the game.

One of our Kickstarter stretch goals was the inclusion of voice acting, and we’re planning to have at least a few basic voices in the initial release. These won’t be too extensive as we don’t want the gameplay experience to be disrupted by constant talking and repeat comments, but we do want to include a few audio notices for important events like spotting an enemy, being wounded, etc.

Mod support is something we’ve been planning on since the beginning and the game engine is already designed around it. But to support mods properly, we’ll want to include a mod manager to enable and disable mods. In addition to modifying and overriding game data we also want to allow mod makers to load custom DLL’s to inject their own code into the game. One thing that won’t be possible in the initial release is loading custom assets, that is new models, textures, and so on. That functionality is planned for the first major post-launch update.

Finally, some two months before release we want to lock down on features and shift focus entirely to QA. That includes the usual bug fixes and performance optimizations, as well as improvements to quality of life and usability issues as we find them during playtesting.

Release Timeline and Common Questions

Our current target for Early Access is mid-to-late July 2025, with the exact date to be determined.

I’d also like to take a moment to address some common questions. Many of you have been asking why we don’t just get another investment deal, sign up with this or that publisher, etc. Unfortunately, things are not as simple as pitching a demo and off you go with suitcases full of money.

For one, the game industry as a whole is currently experiencing something of a slump, and investors are much less willing to back a project than they were two or three years ago. Those companies that still do invest aren’t going to just hand out money for nothing. Be it a financier, publisher, govt grant, they all come with their own set of preconditions and they all want repayment. A typical publishing deal would see the publisher recoup their investment by taking all the game’s sales revenue until the initial investment was repaid, meaning we’d potentially have no income for several months post-launch. After that they’d take 50% of all future revenue, meaning only half the funds to get to 1.0. That is on top of whatever other conditions they might have like IP ownership, inclusion of telemetry, and so on. Other investors come with similar conditions. They also generally don’t pay out immediately but on a milestone basis, meaning if a single milestone gets delayed we might face financial troubles before the game is even out.

While our current budget is significantly lower than what we’d get in a prospective investment deal, the repayment conditions are far less likely to bankrupt us with hefty recoupment policies, nor do they involve revenue sharing, IP sales or similar. At this point the only thing we’d get out of a publishing deal would be a handful more features in the initial release, in exchange for half the 1.0 budget. That’s why we think the current arrangement is our best option, as it provides us with the best odds of long-term success, even if it means making a few cutbacks in the short term.

That’s it for today. Until next time, stay safe and keep surviving!