Cipher Break is kinda half procedurally generated, the tunnel itself is built at runtime, and the game makes decisions about which way it should turn and what should appear next. However, the look, feel and sounds of each level comes from an authored JSON config file, which includes settings for each material used, which enemies should appear at each stage within a level and critically: controls to manipulate the created elements at runtime using data generated by playing the game.

I specify each material like this;

First, the material is named for ease of reference elsewhere in the file and game, materialName  is the name of a base material that is specified in the Resources folder in Unity, basically I’ve created a bank of blank materials, with different shaders applied. (I found out later that I could have just put the shaders themselves in the resources folder and applied them to a new material, but now I’ve done it this way, I see no reason to go back and change it.)

Next the properties object sets the various parameters that the material expects. In the example, the shader can have a texture ( _MainTex ) and  be colourised with _TintColor. The colour is specified as an Array of 4 values (RGBA respectively), which can be set to specify the colour of the material, for example  [1, 0, 0, 0.5]  would make a semi-transparent red . However, I can also set these to be strings, with expressions for the game to evaluate as needed, like “0.4 + 0.5″ and have it evaluate to 0.9. So what’s the point? Well, as you can see in the example "color" : ["{eq-b}","{eq-b} - {in-m}","1 - {in-m}",1]  there are a couple of things that are definitely not numbers. These are the way I specify a link to a particular variable within Cipher Break’s runtime.

When Cipher Break evaluates the each string, it searches with RegEx for any strings matching the pattern {(\w+)-(\w+)} , basically searching for anything between { parentheses } with a dash in the middle, returning 2 matching groups, either side of the dash. The first group is used to specify the set where the data is coming from, and the other is to specify which data from that set to return.

So, from the example –  {eq-b}  refers to the audio graphic equalizer and b refers to the beat, I could also use a number to refer to specific parts of the audio spectrum, so a material could react differently to high and low notes. As for {in-m}  this refers to the player’s input, with m being the user ‘missing’ -ie typing the wrong letter, this could also be h for when they hit, or it could even return the player’s hit rate, or some expression of how many characters they’ve typed during the game. The example above will make the texture go from blue to white on the beat, and flash red when the user hits the wrong key.

When the game is running, it takes one of these strings, pushes it through a regex matching function that is basically a big switch statement, replaces the variable placeholders with the real value, then feeds the result into a JS Eval-like function that actually does the maths and spits out the answer, setting the relevant colour component of the material. This is computationally expensive, however it’s offset by the fact that the materials are used over and over, meaning that I can update one and it affects the entire scene. Neat.

The great thing about this method, is that it’s flexible – I’ve recently be working on adding objects to the world to complement the tunnel, I can use the same principles used here to make these objects pulsate and change colour in time to the music and the users input, meaning the juiciness goes through the roof!

Here’s the latest game play video which incorporates these concepts, hopefully you can see what I’m talking about!