Marek’s Dev Diary: July 9, 2026

What is this

Every Thursday, I will share a dev diary about what we’ve been working on over the past few weeks. I’ll focus on the interesting challenges and solutions that I encountered. I won’t be able to cover everything, but I’ll share what caught my interest.

Why am I doing it

I want to bring our community along on this journey, and I simply love writing about things I’m passionate about! This is my unfiltered dev journal, so please keep in mind that what I write here are my thoughts and will be outdated by the time you read this, as so many things change quickly. Any plans I mention aren’t set in stone and everything is subject to change. Also, if you don’t like spoilers, then don’t read this.

Space Engineers 2

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?

Share your thoughts in the comments below – I read them all, and they’re one of my favorite parts of making our games.

Subscribe and get an email whenever I publish a new post!