For about 6 months now, the four of us have been working on Schacht, further improving the experience.
That is, next to building up the company itself and digging through financial, legal or organisational matters of course.

The first major milestone of this development will be an upcoming content update for the Steam version of Schacht in October! 😀 😀 😀

This update will not only include some important bug fixes or improvements and tweaks of existing mechanics. There will be some new features as well – some more visible, some seemingly invisible.
Here are a few of the points we’re working on. Hopefully they will get you a little more hyped about Schacht and its further development 😉

Major Performance Improvements

This part of development definitely took up a lot of time, even though it is pretty much invisible ingame. Optimizing and improving the performance of the game was the major task for our engineers in the past few months.
To be fair, Schacht wasn’t build with something like good performance in the first place, due to its unusual development story.

The biggest tasks to resolve this problem were:

• switching from Deferred Shading to Forward Shading
• implementing Screen Space Ambient Occlusion (SSAO) including Stencil Mask optimization
• massively reducing the overall polycount by optimizing the existing assets

This led to an overall performance boost of up to 70% across a lot of different setups, from low to high end PCs.
These performance optimizations are necessary for the targeted 60 FPS in native 4K we are going to bring to the PlayStation 4.

New Checkpoint Mechanic

In the old system, the overall time you needed for one track was recorded in realtime and used directly to set your rank in the leaderboard. However, this implementation punished the players differently depending on the distance they covered from the last checkpoint they activated before they failed. We thought this odd treatment of players is a bit unfair, so we reworked the mechanic. Now if you die, you will still reset at the last checkpoint and a fixed penalty time is added to the time you had when you first activated the checkpoint. This will treat every failure the same, regardless where on the track a player fails, and in this way much more fairly.

(We will move the decimal point down soon 😉 )

Background decoration

To enhance the visual aspects of our game, we’ve created some background 3D models which will orbit around the tracks in Schacht. The art style draws inspiration from classical science fiction to achieve a more immersive atmosphere.

To recap the most important information from this post: there is a big update coming to Steam at the end of October.
Besides that we are making great progress on the PlayStation 4 version of Schacht!

With love,
your friendly neighborhood scientists

Earlier this year I was playing TrackMania Turbo, a fun game, which I enjoy quite a bit. The only thing that nagged me was the force feedback on my Xbox One Controller. At first everything seems normal, feedback is triggered upon impacting a wall, after a jump, and so on.

As you go on beating the highscore, you reset to the start point more and more quickly after an error, e.g. when hitting a wall. Suddenly after a reset the gamepad keeps vibrating even during the countdown and a good amount of the next level. It finally stopped after about 30 seconds of just vibrating and from there on it was normal again for a while, until it started happening again – and again, and so on. I switched to a Xbox One Elite Controller but the same thing kept happening time and time again. I tried different things, like plugging the controller in with a wire, re-installing the drivers, the typical things one does if something is not working correctly, but nothing helped. In the end, I disabled the force feedback and thought the game had a bug in its implementation.

Later on, the same thing started happening in a completely different game – Dirt Rally. However, it wasn’t so obvious at first. In this game, the force feedback is a far more integral part of the game, as it tells you how much your tires slip and so on. In this game, this happens only for short periods of time, e.g. half a second, until it fixes itself again. Nonetheless, it was still noticeable.

Same thing for Enter the Gungeon – the controller starts and keeps vibrating for longer than expected periods of time.

Now that I’ve experienced it in multiple different games, I thought this was a hardware or driver error and had nothing to do with the actual games.

Months later we started noticing this behaviour in our own game – Schacht. We tested it using all sorts of gamepads, including the PlayStation Dualshock 4 controller, the Steam controller, the Xbox 360 controller and the Xbox One controller. It all worked fine, except for the one controller again. At first, I didn’t investigate it further because of the assumption of the hardware error, but one thing kept me thinking: There are games where it works just fine. But I couldn’t see any connection between them, TrackMania Turbo, Dirt Rally and Enter the Gungeon, all different engines, different developers, and so on.

In our game I could then test more extensively. At first it works out fine, force feedback is triggered as expected, but then gets triggered delayed and then starts doing random things, like not doing anything at all, vibrating at random moments and so on. For me this seemed like some vibration events get lost after calling the functions. I changed the Unreal Engines XInput code so it only sends new force feedback values when we change them, and suddenly – it worked perfectly once again! I could’ve stopped there but sending the values only when they change includes sending no vibration at all only once, which in my opinion is not a good idea, because if this event gets lost for whatever reason we may wait a very long time until we resend another command, keeping the gamepad vibrating.

The solution was to send it in a regular interval, but how long should this interval be? 1ms? 5ms? 16ms? 100ms? To answer this question, I’ve created a small console application, which turns the motors on and off every 0.5 seconds, and allows me to enter the update rate in which XInputSetState gets called. And there I had it just in front of me: Everything above 8ms worked fine, the motors turned on and off in sync. With 8ms the motors randomly got out of sync, kept vibrating for a full second before turning off again or did not turn on at all. Reducing the update rate even further made the behaviour more apparent, setting it to 0ms (equals sending it as fast as possible) the gamepad started to vibrate for 30 seconds in succession or not at all.

You can try it for yourself:

XInputFloodingTest

Compile it, plug in a Xbox One Controller and start the program. It starts with an update rate of 33ms (~30fps) as a reference how it should vibrate (0.5 full vibration with both motors, 0.5 seconds no vibration at all, and so on). Enter a value in milliseconds and feel what happens (of course values above 500ms will miss updates since this is not the intended use for this application). This is only noticeable on the Xbox One controller, all others seem to work fine, independent of the update rate.

For Schacht, I’ve chosen an update rate of 33ms, anything faster would not be noticeable since the motors cannot start and stop this fast anyway.

Once upon a time, before the year of 2016, there was a group of students who wanted to make a cool video game. And they thought to themselves that a 3D game would be cool, possibly something futuristic with an abstract sci-fi art style. Maybe something that will remind of a groundbreaking film from the early 80s which took place inside a computer, with neon lights and polished darkness.

So they started working and did their best to make their families proud, to earn the respect of their fellow students and to achieve the credits, on which their future depended on. After one semester of production in the well-lit and modern equipped work-dungeons of the university, the students had created a fine prototype. It looked and worked exactly like they imagined and so they prepared a presentation to show it to the world.

But then, only one day before their presentation, something unexpected happened…

The exact same company that was responsible for the film from the early 80s with the memorable art style announced a video game too. A video game that looked like a clone of the game the students made. But the company being kind of the inventor, or at least the greatest defining and contributing source to that specific art style, simply had the higher ground. So the students nobly bowed to the big company in silence and decided to give their game a make-over.

So they moved on to define a new universe and to create the Schacht we know and love today. All that is left from that distant past are these screenshots.

Please enjoy.

Now that we’re here, let’s start at the beginning.

This is probably the oldest screenshot from Schacht in our archive. At this point, besides some already implemented game mechanics to test the concept, Schacht was hardly distinguishable from a default Unreal project.

Incidentally, the concept in which the player should have had to move mostly downwards through a narrow structure didn’t survive either.