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 piqued 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, there may be spoilers inside!
Friday 26.12.2024
Space Engineers 2
This week was quiet because everyone is on Christmas vacation.
Looking back to last week, we also did a few kickoff meetings and started discussion on features for VS 1.1 and forward. Some of them are:
Camera offset in 3rd person - I'd like to adjust the 3rd person camera so that the character isn't positioned in the middle of the screen, obscuring the focal point. Ideally, the character's head wouldn't be directly aligned with the crosshair. Many 3rd person games offset the character to the left and down to achieve this, but it misaligns the character's forward vector and the crosshair. This can create issues like aiming at the center of a door but colliding with the side due to the character's offset position. We need to find a solution that improves the player experience by providing a better overview of the area in front of the character or ship, without sacrificing aiming, clicking (for building or shooting), or ALT-camera rotation functionality.
(This is a quick prototype where we moved the camera 0.5m to the right side of the character instead of the default position behind it.)
UGC Ingame Workshop - this will be the first stage, allowing players to share blueprints and worlds between each other. In the VS 1.5 we will release VRAGE Editor and modding, so more options will come. We will have an in-game Workshop browser so players don’t need to leave the game when they want to upload something or download/subscribe. I think this will be super useful especially because in SE2 we have the Blueprint Building, so blueprints will become very used. We will be also releasing a bunch of blueprint modules for building modular ships - actually many of the ships you saw in our trailers were already built out of these blueprint modules.
Flora Generator - some of the devs are already starting to work on VS2 (Planets and Survival). We already have planets and survival mechanics in the game but they are disabled because we want to present it until when it’s fully polished. This kick off meeting was about quick alignment on flora generation. We will be using SpeedTree to generate the variations of trees, and then they will be hand tuned by artists, making them wave in the wind, and also break into fractures if a player collides with them. It is important to have solid LOD because there will be many trees and we can’t allow them to kill the performance, so many tricks will be used for rendering trees in the distance - impostors and merging them to the underlying overlay texture. Another topic is grass and small bushes where we will use similar techniques as in SE1, but will improve it a bit. I also hope we can get larger view distances for grass, so let’s see.
Ore Detector - The engine will maintain a list of ore locations on planets and asteroids, integrated with our procedural generator for asteroids. This list will be used by the game to display ore locations on the HUD and to spawn ore voxels at those coordinates. We will need to determine what happens when an ore location is fully mined—whether it should be removed from the list or retained.
Optimized compile times (VS1.1) - We need to investigate why the game takes 20 seconds to compile, even when only small or local changes are made. Given that this is C# and JIT, compilation should be nearly instant. We suspect the issue lies with library dependencies—libraries that don’t need to be copied may still be copied unnecessarily. I'm confident this can be resolved. Instant compilation is always a priority for me because it enables faster feedback loops (build, test, iterate), resulting in more efficient development. Additionally, it reduces frustration, as few things are more annoying than waiting minutes for a project to compile.
Destruction optimizations (VS1.2) - We are embarking on another round of optimizations, continuing our ongoing effort to improve efficiency with every update. This process often involves addressing obvious inefficiencies. For example, the game currently spawns an excessive number of fractures when ships collide, overwhelming the physics engine with collision detections. Addressing such issues will be a key focus in this update.
Art
Our artists have started working on new blocks. The typical process begins with game designers providing a block design to confirm the functional requirements. Once this is approved, concept art is created, followed by the LOD0 model, which is tested in-game. After confirming its functionality, the subsequent LOD models are developed.
For SE2, block creation is more demanding compared to SE1. In addition to the standard models, we now require block fractures and corresponding LODs. We also create an occupancy mask, which indicates the specific areas of the 25cm grid occupied by the block. Collision shapes are then developed for physics interactions.
To maintain performance, we enforce polygon and texture limits per block to avoid overly complex designs. We also monitor Texel Density (TD), which measures the number of texture pixels (texels) per unit of 3D surface area, ensuring consistency across all game assets.
Our animators are set to begin refining animations, focusing on improving placeholder assets. This includes reworking the jumping animation, which currently appears unnatural as the character jumps and lands on the same foot. They will also revamp first-person animations once IK (inverse kinematics) is implemented.
Friday 22.12.2024
Space Engineers 2
This Thursday, Dec 19, we had the alpha reveal, with trailer and stream, where we talked about the SE2 roadmap, dev history, why VRAGE3, live gameplay, Q&A, and everything else.
I think it went well, the community seems to be appreciating our choices with a 25cm unified grid system and is excited about what will come in SE2.
What was preceding this day?
We were pushing hard to have a safe build of the game, so we can show gameplay without crashes, bugs or some imperfections.
One of the last moment fixes were the first-person animations, finally working as we wanted. But we had to disable the character shadow in first-person mode, because it’s clearly unfinished - what you would see is a very stiff posture, feeling unnatural. It’s better to disable it and polish during VS 1.2
We were sprinting with our work on the trailer - iterating, making some changes here and there, to make sure it’s the right introduction to SE2. All our teaser/trailers are now told via lore optics, not just pure game mechanics. We want players to feel they are part of The Bering Project, one of the pioneer space engineers in the Almagest System
Funny thing is that many players think the narrator is an AI voice, but it’s actually a real human actor, we just radio-distorted his voice, to create the impression of speaking from different time and location
One of the last features that got to this build were fixes and improvements in the Blueprint Building - just small details like improper scaling and cropping of blueprint preview on the toolbar or color of the icon, but details create the first impression
Another last-moment bug that popped up from hell was that when I entered the cockpit and switched to first person, the camera was inside the head of the character, so a weird dark shape was rendered almost through the entire screen. Very strange. Luckily, the team fixed it and merged it to the VS1 build very quickly.
The team is already working on a build for VS 1.1 and VS 1.2, so everything that has to be merged to VS1 (that will be released on January 27) needs to be manually merged and it’s a painfully laborious process. So we need to be careful with picking what gets to VS1, versus, what has to wait for a later VS.
My preparation for the live gameplay was about writing a list of features I want to show and then playtesting them, making sure they work as intended and I don’t get stuck in some bugs or confusions. Nothing surprising came out which is good. But during testing I realized that showing the fracture destructions in interiors is much better than in exteriors, because the fractures will start bouncing from the environment and it creates a feeling of a very reactive environment full of space debris. So I decided to show it inside Green Station.
I am already focusing on January 27, when we will release the game on Early Access. We need to make sure the alpha build is as stable as possible, no breaking bugs. There’s still a strange issue with shooting with the debug gun, where the impact sounds, or destruction sounds, play kind of randomly… it’s weird, we need to investigate it.
Other than that, my focus is on the next VS 1.1 which is the UGC In-game Workshop - allowing players to share their blueprints and worlds. I hope this will be a big thing, because SE2’s is about blueprint building, so sharing it should improve efficiency and range of creations.
Then there’s VS 1.2 which is about many improvements, like new ship controls or improvements in animations (jump, inverse kinematics, uphill/downhill movement, etc). I am looking forward to the new ship controls, because we already had a prototype in game but had to revert it because we knew we didn't have time to fully polish it. But it felt so good. I was able to fly a ship without that feeling of moving the mouse over my desk. It was so fluid and I felt like I am finally controlling the ship - with broader and more detailed strokes, as needed. I want it back.
Friday 1.12.2024
Space Engineers 2
Today is the feature freeze day for SE2 VS1.
So we are branching out to a new dev branch where features for VS1.1 will continue, while some people will keep testing and bugfixing VS1 - meant for release in Jan 27
I am happy that Blueprint Building got finished just before the deadline, so players will be able to use partial copy paste, assign to toolbar and blueprint screen. This was really important for us to be able to present as intuitiveness improvement in SE2. There are still few UI imperfections and it’s crashing when you click on Place Blueprints, but those are major issues we will fix in a few days.
The team has finished the PCU measurements, which means we now know how much CPU and memory is each block consuming on average. There was an issue in the measurement where light blocks were estimated to be thousands of PCUs, but it got fixed and now the numbers are around 10 PCUs or so.
Friday 29.11.2024
Space Engineers 2
We are finishing VS1, the code freeze is on Sunday, only 2 days.
I'm happy with the team. Everybody is pushing and trying to deliver their tasks. I love this team spirit and collaborative atmosphere! Some of us are online even at midnight, iterating, pushing things to perfection. I am so grateful!
This week I focused on sound design polishing, animations polishing - mainly first person: we try to make sure that the hand and the paint gun is stable when moving the camera around. It’s still not working as I want so it’s possible we will have to postpone it to VS 1.2. But both programmers and animators are trying hard, so I am glad for this.
We are doing last moment changes, changing app icon, adding the SE2 logo into the main menu and loading screen, and adding the main menu background image. We did some updates on the What’s New screen that shows at the game start and tells you what is new in VS1 and what is our plan. I'm glad this screen is very aesthetically pleasing. It will be the first thing players see, so it has to be good.
We did the splash screen, and I really like it. The art style is brutal, and it sets the mood even before the game starts.
We were doing last tweaking and polishing on controls and UI/UX - making sure the context sensitive tips are there and showing the right thing.
We were polishing the destruction experience - including the Debug Gun Tool, the damage it causes, particle effects and sounds, and how the fracture system works. I think it’s good, but I definitely plan to revisit this soon, we need to add more debris for armor damage/bending, improve the projectile hit particle effects, and overall make it as much instantly gratifying as possible 😃 We also need to look on the physical impact that the projectile causes, because I think it’s good for lightweight objects (e.g. catwalk) but could feel better for larger objects (e.g. refinery - giving more visible feedback).
Friday 22.11.2024
Space Engineers 2
Karel Antonin (our music composer and production lead) and I were going through tracks for the OST, reviewing them, commenting on what needs to be changed or extended, and discussing what's still to be done. We talked about the contributions of various musicians, what we want to add in future versions, and how the orchestra is going to record it all.
Looking at where we are now with the music, I wanted to share the story of SE2's soundtrack so far: For Space Engineers 2's soundtrack and in-game music, I wanted to capture the story of people who carried their ancestral heritage across 10,000 light-years to The Amalgest System. We drew inspiration from various ethnic styles: the soul-stirring melodies of Eastern Europe, the mystical sounds of Arabia, the intricate patterns of Indian music, and the primal rhythms of Northern European tribes. To bring this vision to life, I turned to Karel Antonin, who has been composing and leading music production for our games for almost 15 years, from Miner Wars through Space Engineers and Medieval Engineers. Under Karel's direction, each piece of music became a bridge between Earth's ancient cultures and humanity's far future, blending traditional instruments with modern synthesizers to show how our musical heritage might evolve across millennia. Working with talented musicians and a full orchestra, Karel composed music that feels both ancient and futuristic, where you might hear folk melodies transformed through electronic textures while still maintaining their emotional core. This vision continues the musical journey we began together all those years ago, growing and evolving with each game we create.
Today we were reviewing in-game sounds with Lukas Tvrdon, a sound designer I have collaborated with since Miner Wars. I really enjoy this part of game dev because sounds are about adding feel to the game - many times it's about that feedback you get from interacting with the game world. You can add a lot of value just by designing fitting and satisfying sound effects. We found many bugs, for example the engines and thrusters are still way off, with secondary sounds that should not be there. We really need to polish this. Other things remaining for VS1 are GUI click, louder jetpack boost and removal of secondary sounds from it, different sound for paint gun (the current effect sounds like spray, but we want something that is a blend of spray and laser/electronic tool), collisions between character and grids are not being played, ship drill sounds are not implemented yet, and it would be good to add some sounds for HUD, like when selecting a tool/block on toolbar, deselecting via tilde, etc.
My work desktop has a 42.5" screen and I am used to playing games in 4K. I do the same with SE2. I think SE2 is meant for 4K and large screens. Everything looks so sharp, crystal clear, both details and contours. Disclaimer: right now we optimized for 1080p, so 4K doesn't run as fast as it could. We will be addressing it in future milestones.
One thing I appreciate about our CI pipeline (continuous integration, build process, auto testing, deployment of new dev version) is how stable the game is and that it's very rare to update the build and get a crashing game. Basically, it's very safe for me to update the game to the recent dev version and test something, without being afraid that I'll get a broken game. The reason is how well our team designed the CI pipeline: every time someone commits changes, the system runs a series of tests on them first, and if some are not passing, you have to fix it before you can commit it to shared code. Also every night more thorough tests are run. Yes, sometimes it's a pain to go through this process, but the benefit is that all 70 people who are committing changes every day are not breaking it for each other. In the past when we didn't have such a system, it was very common to update the game and simply not be able to do anything because someone broke it a few hours ago. That was very inefficient and simply "bad user experience" 😀
Wednesday 20.11.2024
I have been wanting to start writing weekly dev diaries, but while SE2 was in stealth, I couldn't do it. Finally, last week we announced it and now I can share with you snippets of what we are working on.
Space Engineers 2
We are finalizing VS1, code freeze is in 10 days only. I was reviewing some tasks, for example:
particle effects for footsteps on grid and asteroids
splash screen (the image you see before the game starts)
menu main screen (the one where you see the skybox, asteroid, and the engineer)
updating the texts and visuals for the "What's New" screen that you see before the main menu
reviewing sound effects, making sure they are aligned with the visuals and settings and that the sounds feel good and satisfying - we are almost done, but still need to finish GUI click (add some cyber layer to it), block rotate (make it slower to align with the actual rotation animation), block delete (faster)
discussing how we will implement custom cutscenes in-game (by running imported multi-character animations)
reviewing the animations, especially first-person (there are still little tweaks we need to do). For example, the hands still don't have their first-person animation, and the third-person doesn't look good in first-person, so the hand or paint gun are waving like crazy. What is good is that there's no headbob (secondary head movements) in first-person mode. So in first-person mode you really are a camera that moves perfectly through space, no up or down, or tilting.
testing the destructions via the Debug gun tool - this is something we will have to return to later and improve the effects for armors. Also, it doesn't spawn proper impact particles yet; they are coming from the block's center and not where the projectile hits the surface.
I discovered that there is a small 1-2 cm gap between the character boots and the surface he is standing on. This shouldn't be happening; we solved this a few months ago. It's super important for me because I want it to feel like you are standing on armor, touching it, interacting with it. I am not sure yet what the problem is, if it comes from physics or character controller, or from the animation or recent changes to the character model (we were improving the bottom of his boots). We will check it out.
We are using Jira for project management - it's basically a database of tickets (tasks and bugs). Right now, since we are 2 weeks from the deadline, we prioritized only two types of tickets: QA (bugs) and Marek's priority. Everything else was moved to future milestones. There are approximately 100 Marek's tickets right now, and I don't know how many QA tickets. I hope we make it on time 😀
I really enjoy just running around, observing the beauty of SE2, the skybox, asteroids, grid armor, lighting... and listening to my heavy footsteps, and then jumping and hitting the surface heavy, because the fall sound is a bit louder, and it feels so satisfying 😀
On Monday we finished the planning for the next few milestones: VS 1.1, VS 1.2, VS 1.5 and VS 2. I am quite happy with this because good planning is absolutely important - making sure we are aligned, we are working only on relevant and important tasks, that we didn't forget about something, and realistic time budgets are set.
A few days ago we doubled the strength of inertia dampeners (relative to SE1). This means that when you stop thrusting, the ship will start braking automatically, using the thrusters that are in reverse position at 10x their power. It's not really realistic, but it improves the feel because now your ship can stop much faster, so you feel more in control, have less chance to crash somewhere, and the maneuverability is simply better. My colleagues seem to like it, so I hope players will like it too.
We made some last moment changes to the story - the brothers' names are now Miroslav Sokol and Ivan Sokol. The reason is that I am from Eastern Europe and I want to feel a personal connection to the characters. I've always been inspired by the rich sci-fi traditions from our region - there's something special about how Eastern European authors imagine the future. The brothers are from an unspecified Slavic background, which could be Czech, Slovak, Serbian, Polish, or any other Slavic culture. I want their story to reflect that unique perspective and heritage that shaped my own imagination growing up.
AI People
This week I didn't work much on AI People, just a few hours brainstorming with Shantesh (game designer) and Jan Feyereisl (AI researcher/developer), where we discussed how to improve the goal system for NPCs, so that they can keep goals for some time, evaluate their completion (and what to do when this evaluation is incorrect due to hallucination or imperfect context), handle multiple goals and their prioritization and scheduling.
State of the game: we released the alpha about 2 months ago. Until then the priority was to release a playable game that is a proof-of-concept of LLM driven AI NPCs that can interact with the environment, each other and player. That was it. The gameplay is then basically just playing with them, or creating new scenarios and writing story plots for them. Recently we moved to the second stage: turn it into a proper game with a solid core loop and meta loop, challenges, objectives, and progression. That's what we are doing right now, building an MVP (minimum viable prototype) of this new gameplay. It's looking optimistic. During today's team playtests when some team members saw the new MVP, they were quite happy because just from observing it, it feels like a game - you can imagine what you will be doing there. It's not an unknown concept so far.
We are steadily speeding up the iteration cycle for this MVP, from months to days. How does it work:
we have a list of concepts we think will move us to a good game
we implement one, test it in MVP, and then move to another
it's clear that if we can iterate and test one thing every week, the overall MVP progress will be much higher
The other thing we discussed is the genre of our game, and finding some existing games as role-models: so we can say AI People is like X, but without this and that. Right now it feels our game will be an action RPG like Fallout 2 (but without complex skill system and heavy RPG mechanics), mixed with strategy and farming (Stardew Valley, Age of Empires), and life sim (The Sims - where you take care of your Sims). So our game is a top-down adventure/action RPG where you explore, solve quests, but also manage your friendly NPCs, and neutral and enemy NPCs.
We also discussed the need to set the game into some lore and story, and not keep it generic anymore. People need stories and fantasy, they need to feel they are in an imagined world, and not just some generic placeholder.
