Neon Chrome mostly runs on procedurally generated levels as the standard levels in game are all products of algorithms. In addition to standard levels the game includes hand crafted areas in the form of boss fights, hidden special levels, and story levels. However, most of the shooting is done in the procedurally generated levels. There are actually four different level generators in the game which of two are really distinct. Of all the four generators three are more interconnected and differ only at the baseplan style level. In this post one of them is described. We won’t delve into the finest detail but this should be an interesting read for those who are into stuff like this.
In the first phase we randomize a bunch of squares. For performance reasons we need to keep the level size within some constraints so we first we remove the squares which do not fit inside the level. After this we push the squares apart with some simple steering behavior until they’re not overlapping anymore. Again we cull away the squares which are outside the level perimeter after this. To make the whole level accessible we need to check that all squares are connected someway: naturally with edges touching or with a connector tunnel we build. At this point we may also cull away some squares which are too far way from the main group of squares. We also make a graph by using Delaunay Triangulation and a Minimum Spanning Tree.
When compared to most dungeon generators, Neon Chrome generators create relatively few narrow corridors. This is because we think that narrow corridors work only in really small amounts in the context of a game like Neon Chrome. They’re nice choke points but we want only a few of them. In any case this is our floorplan. We’ve also selected the entry and exit rooms for the player but they’re visible only in the final images.
If the method above sounds familiar you may have read about the dungeon generation of TinyKeep which was a source inspiration. Many similar techniques like Delaunay Triangulation are used here. The other generators work a bit differently from this one. Two of them work on a simple grid approach and one is built on BSP-trees.
Now we start building the actual floor in the building where the player will do the shooting. We classify the rooms with the supposed movement direction which is derived from the graph connecting the rooms. In the next image the “tile view” of the floor can be seen. We’ve also determined the outside walls. Some rooms are combined by removing the wall between them giving the player larger open areas.
Now we’ve randomized and pasted a selection of room interior prefabs into the floorplan. These interior prefabs include “placement slots” for enemies which are all visible at the moment. We first tried to create a generator which would work without prefabs, but in the end we decided that handmade prefabs combined with procedural layouts and random population would be our way to go. Next we’ll raise up the walls and then start populating the floor with enemies.
The heatmap describes the relative power of enemies in each room, the starting room usually has no enemies as can be seen here also. This floor seems to have a relatively even power distribution with two rooms that are a bit hotter.
During the final stages we’ll replace the white boxes with arrows with interactable items like autodocs, enhancement sarcophages and decoration and finally add the baseboard lighting for some extra atmosphere and then we get to play!
Thanks for reading! Sign up for our mailing list for release news and possible beta invites. Also, tomorrow on Friday 4th March 16:00 CET we’ll be streaming Neon Chrome at twitch.tv/10tons!