VS2.3 First Contact: Direction, Results, and What We Are Fixing Next
VS2.3 is out, and first I want to say thank you.
Thank you to everyone who jumped in immediately, built vehicles, tested automation, exploded things, tried Classic Survival, reported bugs, and told us what worked and what did not.
This is exactly why Early Access matters. We do not want to build Space Engineers 2 in isolation. We want the game to meet real players as early as possible, because only then do we see what is truly clear, fun, confusing, fragile, or exciting.
The first response is encouraging. Players are not just reacting to individual blocks. They are already thinking in systems again: rovers, mobile bases, automation chains, warheads, survival routes, contracts, stations, and even requests for future things like rails and trains. That is a good sign. It means VS2.3 is touching the right fantasy.
We also saw more players coming back to try VS2.3, which is an encouraging signal. It tells us that this direction is interesting enough for players to return, experiment, and give us useful feedback.
Why VS2.3 matters
For me, VS2.3 is not just a content update. It is a direction update.
Our vision for Space Engineers 2 has always been straightforward: we want to build a living solar system that gives players concrete engineering objectives, where you advance, explore, build, solve problems, and colonize.
Of course, if players prefer a freeform sandbox, they can have that too. That freedom is part of Space Engineers. But we also want the game to feel like an active world that gives you meaningful reasons to progress.
That is where VS2.3 matters. It gives players more verbs: drive, automate, detonate, repair, survive, travel, connect systems, complete contracts, and make engineering decisions that have consequences.
This is the direction we want to keep strengthening: more connected systems, more reasons to engineer, and more situations where the player says: “I can solve this if I build the right thing.”
Colonization and the active world
The colonization system is important because it gives engineering a larger context.
Space Engineers should not only ask: “What can you build?” It should also ask: “Why are you building it, where will you take it, and how does the world respond?”
Contracts, stations, sectors, mining, trading, exploration, encounters, resources, terrain, weather, vehicles, automation, and survival should all become connected parts of one larger progression loop.
You build vehicles because terrain and distance matter. You automate because bases and ships need to react. You mine and trade because resources are distributed. You complete contracts because sectors grow. You return because the world changes.
That is the long-term promise: a sandbox that remains free, but also becomes more alive for players who want direction, progression, and colonization.
What first contact taught us
The release also showed us where we need to improve quickly.
The main theme I see is trust and legibility. Powerful systems only feel good when players can understand and trust what is happening.
We are watching and working through reports around terrain/mining issues, G-menu and grid toolbar confusion, Control Panel grouping, hinge placement, Classic Survival resource progression, hydrogen/flight behavior, cockpit interaction, crashes, and other first-contact problems.
Some of these are bugs. Some may be UX or tutorial gaps. Some are expectation mismatches. But all of them matter, because they happen exactly where players are trying to understand the new systems.
So our next focus is clear: reproduce the most trust-breaking issues, hotfix what we can, improve communication where the system is correct but unclear, and keep listening to real player behavior.
Player excitement tells us the direction is right. Player friction tells us where trust and legibility must improve next.
VS2.3 is a big step toward the kind of Space Engineers 2 we want to build: a game about player agency, engineering consequence, colonization, and systems that combine into things we did not script.
Thank you for helping us test that direction. Now we keep improving it.
Asymmetric Destruction
One of those improvements we are working on is Asymmetric Destruction.
The situation is simple: rovers and forests should not feel like two immovable objects arguing with each other. If you hit smaller flora with a vehicle, the result should feel natural, readable, and fun – not like the invisible spirit of a tree just deleted your suspension.
With Asymmetric Destruction, collisions won’t always affect both sides equally. Your multi-ton monstrosity of steel should be able to smash through flora without automatically taking the same damage back. So yes – plowing through trees like a manga villain should be possible.
This is not about removing consequences from driving. It is about making collisions feel more believable. If you crash into something serious, that should still matter. But if your rover is pushing through bushes or smaller trees, the game should understand the difference.
Question to you: What did VS2.3 get right for you?
Full Dev Diary: https://blog.marekrosa.org/2026/07/mareks-dev-diary-july-9-2026/
🛠️ Feedback & Support - https://support.keenswh.com/
🗺️ Roadmap: https://2.spaceengineersgame.com/roadmap-2/#current
🛰️ Discord: https://discord.gg/keenswh
📫 Newsletter: https://www.keenswh.com/newsletter
➡️ Connect and find us on your platform of choice: https://www.keenswh.com/connect/
https://steamcommunity.com/games/1133870/announcements/detail/707775747757970935
https://steamcommunity.com/games/1133870/announcements/detail/707773844292634050
https://steamcommunity.com/games/1133870/announcements/detail/671746315771712225
