The Creation of Procedural Shooter Sublevel Zero
Events
Subscribe:  iCal  |  Google Calendar
Busan KR   15, Nov — 19, Nov
Minsk BY   15, Nov — 17, Nov
Minsk BY   16, Nov — 19, Nov
Philadelphia US   30, Nov — 3, Dec
California US   4, Dec — 6, Dec
Latest comments

This is great. Keeping UVs at 90 degrees never occurred to me but it makes so much sense it seems obvious in retrospect

Unless I'm mistaken, this is how Shadow of the Colossus handles the fur on the Colossi

by Nate Lane
4 hours ago

Awesome breakdown Simon!

The Creation of Procedural Shooter Sublevel Zero
21 October, 2015
Interview

Sublevel Zero is an awesome indie 6DoF-shooter, that is heavily inspired by the classical Descent. The game features randomly generated levels, roguelike gameplay, incredible visuals and great music. We’ve talked with the developers of this small indie masterpiece from Sigtrap and discussed the production of this title. Luke Thompson (@six_ways) talked about Unity, the procedural nature of level design and the influences on game design.

About Sigtrap

Sigtrap is based in the north of England. I say that because we’re a little spread out, mostly between Manchester and Huddersfield. The company basically formed around the concept of Sublevel Zero – the idea was born in a pub, prototyped in a game jam, and we got a publishing deal off the back of that prototype. The company itself is technically myself (lead programmer) and Gary (artist), but there are 5 people on the game including Phi (procedural and AI code), Jey (sound design) and Will (composer). All of us have different levels of experience in the business – this is my first game, but everyone else has some experience behind them. Gary and Will have just finished their degrees in Game Design, and Gary had previously worked on Dream, a surrealist first person exploration game. Phi had just finished his first game, TinyKeep, a procedural dungeon crawler, with Jey on sound and Will on music.

Sublevel Zero

SL0_clip4

Idea was basically born in the pub! Myself, Phi and Jey had for about a year been involved in the Manchester indie dev scene, which is a wonderful group of people full of energy, creativity, and community spirit. We had just discovered we all loved Descent (and were perennially disappointed with the relative lack of new titles in the genre) and, with Phi and Jey just finishing TinyKeep, had the idea of a roguelike Descent-clone. We were all busy at the time, so thought we’d never have a chance to actually do it. Then the next Ludum Dare game jam came around, and the theme, miraculously, was “Beneath The Surface”. Having already roped in Gary and Will with the plan to do something relatively ambitious between the 5 of us, it was obvious what our game would be! Over 3 intense days we managed to create a surprisingly polished game which was very well received.

The Low Poly Love

In the original jam build we went with a low-poly, retro-inspired look on a whim as much as anything, and really liked it. Obviously it was rough, but we knew we had something good. So we polished up the jam build as a prototype, whilst also working on the visual, sound and music style of what we’d like a full game to feature. We never stopped iterating on these throughout the development process, and every couple of months the game would look and sound better and better.

Procedural Generation

SL0_clip2

The basis of the procedural idea was all the way back in that pub. We really liked the idea of a 6DoF game that would constantly surprise us, sometimes throwing out levels which stuck mainly to one plane, while at other times producing levels that were 3D in the truest sense. A game you could become familiar with, but which would always keep you on your toes as you could never memorise the enemies around the next corner. There was also the attraction of the technical challenge – to our knowledge, this kind of fully 3D procedural generation had not really been done before, and we were excited to work out how to approach such a complex problem from a coding, level design and art perspective.

SL0_Screenshot01_resize

Our system went through a couple of major iterations. The system we used on the original jam version was essentially as simple as we could make it, for obvious reasons. It put a pre-made room in the world, and started adding other pre-made rooms to the exits of that room, and so on. This felt quite organic, but had a major problem in that there was no control of the overall shape of the level. You’d end up with basically a tree, with any number of branches and sub-branches, only one of which led to the end of the level. So you’d spend most of your time fruitlessly flying down dead ends. The first version in the full game therefore when entirely the opposite direction – while still using pre-made rooms, the system would create a 3D network of nodes linked with curves.

SL0_Screenshot08_resize

Each node would get a room, and corridors would be dynamically created along the curves to link the rooms. This gave much more control over the gross layout of the level, but felt very twisty and broken up. It was weird that you never had a room that just led into another; there was always a (often quite long) corridor to the next, and the rooms might be at completely different angles to each other. Finally we made a hybrid system – on a small scale, rooms were strapped onto each other as in the original version, but then these clusters of rooms would be linked by dynamic corridors. So we have more high level and low level control of how things get laid out. It also means we get a degree of control over how ‘truly 3D’ each level is, with earlier levels tending to be a bit flatter and later levels tending to require more spatial awareness.

SL0_Screenshot02_resize

Again, as far as we’re aware, no-one else is really using a system like this, which of course is largely due to the unique constraints and requirements on procedural generation for a 6DoF game. All that said, the system is far from perfect and we have a lot of ideas (especially having got feedback from so many people now the game is out!) on how to tweak and improve it. We’ve got some pretty cool plans in place, so we’re really looking forward to implementing all the tweaks and updates we’ve got in mind!

The Recreation of Descent

SL0_clip9

The core gameplay is absolutely intended to feel like Descent, particularly 1 and 2. We all love the experience of flying around tight, twisting corridors in zero-g, with enemies attacking from all angles. In particular, Sublevel Zero focuses on the weight of the ship, rather than it being a pure FPS game but with fully 3D movement. There’s a definite and intentional feeling of being in a vehicle. Obviously there’s nothing wrong with the opposite, and there are great games such as Retrovirus and NeonXSZ which take that approach, but it’s definitely a core design decision for Sublevel Zero.

But that’s not to say we didn’t want to add anything to those mechanics. A subtle but important example is that in Descent, you can yaw faster than you can pitch. Given gamers’ proficiency with modern mouselook shooters, we wanted movement to be equal on all axes, and there’s a certain smoothness to the game that this adds. The ship is also a little bit more responsive than in Descent, while still retaining a feeling of weight.

Put simply – the feeling of flying a zero-g gunship is probably the most important part of the game for us; we’ve spent a lot of time and effort polishing that and we’re really pleased with the result!

Killing the Navigation

SL0_Screenshot06_resize

Fully 3D level design in a 6DoF shooter inevitably has more potential for disorientation than in the vast majority of other games. But we’ve worked hard on minimising that, with three main components.

The first and in some senses simplest system is the optional auto-levelling. This was featured in both Descent and Forsaken, and can really help some players get to grips with the space. It becomes limiting as the player grows in skill and learns to forget about ‘up’ and ‘down’, and people tend to turn it off before long, but it gives new players an orientation to hold on to.

In terms of level design, each pre-made room is focused on flow and giving the player cues on where they’re meant to go. This includes lighting, props and the shape of the rooms themselves. It’s been a really interesting journey, working out how level design works in a game such as this.

Finally, the map view. While Descent itself had an automap, we’re really proud of how ours works. Similarly to Descent it gets populated on a line-of-sight basis – when you’ve seen part of a room, even if it’s just a glimpse through two other rooms, it appears on the map. It gets filled in at the same time as your mental map does, so it helps players reinforce their spatial awareness of each level. But the major issue with Descent’s map was its wireframe rendering – as levels got more complex it became almost impossible to use in some cases, with a lack of depth information turning the wireframe into a confusing mess of lines. We opted for a simplified but clear rendering of the world in the map view, with shaders designed to pick out the outlines of rooms while also giving a solid sense of depth and volume, and picking out important things for the player such as exits, doors and keys. The result of all this is that as players become experienced with the game, they’ll usually only have to look at the map for a second or two to reaffirm their bearings and understand where they need to go.

The Choice of Unity

I wouldn’t necessarily say that Unity is bets known for mobile games, but that definitely forms a significant part of its market. The choice to use Unity was certainly a pragmatic one. Phi and I both have a fair amount of experience with it so could jump right in, and its cross-platform capabilities are absolutely second to none. It’s always a massive help to know that you’re not inherently limiting the platforms you can develop for. With any off-the-shelf engine you’ll encounter (many!) cases where it’s not designed around the specific thing you want to do, and you’ll have to work around that. Fortunately for the most part Unity has suited the project very well!

The Choice of Tools

We’ve benefited greatly from the Unity Asset Store ecosystem. While we don’t use it heavily, we have bought a couple of extremely useful plugins to reduce the amount of so-called boilerplate code we’ve had to write. All of our most demanding, unique systems are entirely our code (e.g. the flight mechanics, procedural generation, crafting), but the low-level AI code for instance is a great asset store behaviour tree plugin called Behave, which gave Phi more time to concentrate on actually designing the AI rather than spending weeks on the framework.

Marketing and Sales

Sales and media attention have been pretty strong, especially for unknowns like us! We’ve been blown away by the positive response – while it’s not a game for everyone, those who like it seem to really love it. We’ve already got a fantastic community; people who really appreciate the game and who have given us a lot of trust to fix any bugs they find and improve the game based on their feedback. They’re enthusiastic enough about the game that even when they find (fortunately very rare!) gamebreaking bugs, they’re quite happy to keep playing and let us get on with fixing it.

I think expos and shows have been pretty instrumental in getting the word out about the game. We’ve had lots of people, press and customers alike, discover the game at for instance PAX, and then evangelise it for us. It’s a great way to show the game off and also talk to people about the game in-depth. Whether that’s what helped us most I couldn’t really say, but it’s certainly been very important!

Luke Thompson, Sigtrap

Leave a Reply

Be the First to Comment!

avatar
wpDiscuz
Related articles