Creating an Atmospheric Physics-Destruction Building Game in Unity

Introduction

Hi, my name is Johannes Knop, I'm a Game Designer, Indie Developer, and Chairman of the Randwerk Cooperative in Berlin, Germany. ABRISS is the first commercial game on which I have worked, alongside my colleagues Friedrich Beyer and Till Freitag. We studied game design at HTW together, and we worked on many different projects there, including board games, VR, mobile, gamification and research, and some concept art projects.

The Story Behind ABRISS

A couple of years ago, Friedrich and Till had been working on a university project called Antitect, in which players would destroy building-like structures by combining parts, gaining back parts by destroying as much as possible for a high score. When we were all sitting in the first lockdowns of the summer of 2020, they approached me with the idea of trying to make this concept into a commercial game. A couple of months later, we had quite an impressive prototype for the puzzle-physics game, now known as ABRISS.

Something about making a building game that is about destruction is just such a clear concept: build to destroy. Everyone knows what it's about. Funnily enough, the new endless mode we introduced with the full release is much closer to the initial concept for Antitect again, so we kind of went full circle in a way.

Delving into Our Brutalist Art Style

We wanted the cityscapes of ABRISS to be of an undefinable scale so that it'd be abstract and surreal in a way that you wouldn't really know how big things were, just that everything would be massive. We named our style "Mainboard Brutalism" because I thought everyone had looked at a circuit board before and thought it looked like a city, and that's kind of what we were going for. There's also just a lot of ruined prefabricated high-rise buildings in Berlin, we've always seen things getting torn down to build new stuff, and there are some really cool brutalist buildings in Berlin like the ICC, so we're surrounded by it. But I think we also just messed around with the then-new volumetrics and thought it looked cool. The UI style is inspired by record covers and posters for techno and electronic music in general, so it's also connected to Berlin, and that's also where we get a lot for the sound design and music.

Approaching the Development of the Core Gameplay Loop

We've conducted a lot of tests, and I think the main loop has always been similar to its current state. However, there were a few additional steps in the past. I recall that you used to need to press some more buttons to advance, but now it simply involves building and the action phase. We've tried a bunch of parts that didn't really work out, like something similar to a balloon or just heavier and lighter versions of the standard parts, we left those out when we noticed we couldn't really build interesting levels with them.

Speaking of the Workflow

We've been using Unity 2020.3 with the HDRP Render Pipeline, and modeling was done in Blender. And that's pretty much it, no special tools or fancy middleware, just Unity and Blender. Personally, I really like to use Rider for programming, I just enjoy how the autocomplete feels. Also, we're using Miro to communicate most things, so our project management, mood boards, calendar, and everything is just happening on huge virtual whiteboards.

Some words on setting up properly working building mechanics, I think the most difficult part was trying to keep it minimalistic, so we didn't really want a lot of on-screen buttons, but then we would need to communicate a control layout that people aren't already familiar with, and that's not that easy. When we started out, holding to move things or connecting things to the side was not possible, and then later that was possible but was always slightly off, and then we introduced snapping, etc, all of this was quite hard to do.

Finding the Right Difficulty Curve

I think we started out too hard at first. With puzzle games, I feel you always have to go a lot easier than you think for it to be approachable, and we've had the additional problem that the physics aren't deterministic, so we can't be really sure that everyone who builds the right solution will get the expected result. We just had to test every level, and that wouldn't have been possible without our wonderful game designer friends or our community on Discord and Steam. There's really no way around testing a lot.

Approaching Optimization and Making Sure Players Get a Smooth Experience

Smoke and mirrors. We are subdividing blocks into smaller pieces only when they are destroyed, then replace that with CPU and GPU particles, and we also use a combination of multithreading and compute shaders with the Unity Jobs system, so there's just a lot less "real physics" happening than it looks like. People have been asking if it's voxel-based, but no, it is not. Just the built-in Unity physics. Also, when starting the action phase, time slows down, which gives us more time to compute the physics happening in each frame. Also: sometimes, the performance just isn't good, we just hide that the framerate is going down. There's no fast camera movement like in a competitive FPS shooter, and we try to spread expensive computations over several frames, so you don't get a frame drop spike you would notice. But also, there has been a lot of hardware coming out since we started working on the game, and modern machines are just crazy powerful.

Johannes Knop, Game Designer/Indie Developer/Chairman of the Randwerk

Interview conducted by Arti Burton