Recently, a friend of mine posed an idea for a game they’re developing for a local game dev showcase: a platform fighter where each selectable character is associated with a unique controller. For this project, I needed to create a system that could handle inputs from multiple unique controllers to play as different characters, including character selection and pairing input devices to controller types.

The controllers used in the project are N64, GameCube, WiiMote and DK Bongos. These devices posed a notable issue, since three of the four use the same hardware to interface with the PC, meaning they are read as the same controller type. Since we couldn’t tell the difference between individual pieces of hardware, creative solutions had to be made to associate controllers with their type.

Gameplay

As a platform fighter, the fundamental gameplay revolves around choosing a character using their associated input device, having your opponent do the same, and then using a range of attacks and special moves to damage your opponent. The gameplay is inspired by games like Super Smash Brothers, so the health is a percentage that increases with each hit, ranging from 0% (undamaged) up, with the amount of knock back the enemy takes exponentially growing along side their health. When a player is finally knocked out of bounds, they lose a stock, and when they have no stocks left, they have lost the fight.

When developing this system, I had to consider its purpose in the game, specifically that not all devices will control a character in a fight (with only one-on-one battles planned for release), and that the type of device determined the character’s sprites and moves.

Overview

This system comes in three parts, the InputMapHandler, CharacterControllers, and PlayableCharacters. Each of these parts controls a different aspect of binding unique controllers to characters. Because part of this system was developed to be independent to the game itself, specifically the InputMapHandler, generic types were used to have it fit into projects outside of this specific game.

Input Map Handler

The Input Map Handler is the beating heart of this system, it creates input maps from Unity’s InputSystem for each device connected to the user’s PC, from keyboards to controllers; the system pairs created input maps with each device, setting it as the only input device read by that map. Using this, individual devices can be enabled, disabled, or read from, allowing for a range of different devices to be plugged in and read from at will.

The Input Map Handler is generically typed, allowing a system to create one with any type created by an input map asset. In Unity’s Input System, assets can generate a C# class so input maps can better interface with C# code. The class generated by the asset will always inherit from IInputActionCollection2, which we can use in our generic type class to specify that the type used in arguments should be generated from one of these assets. // insert declaration of InputMapHandler

Character Controller

Playable Character

A new game project RPG inspired by Fear and Hunger (mechanically), Pathologic, as well as Dark Souls and similar Dark Fantasy games

Oslo (working title) is a game I’ve relatively recently started work on to expand my knowledge of GDScript as well as just make a playable project by myself. Since RPGs are an overwhelmingly common indie game genre I’ve been trying to fill in some of the gaps caused by other games adherence to the traditional genre conventions, as well as add some unique mechanics (to the detriment of my development speed).

This game will be developed in Godot, an engine thats fairly new to me but one that I have a boundless amount of personal control over, being able to edit the code for the engine as its open source.

When making anything in an existing genre you have to appreciate the titles that came before it, but I think so many games (specifically in the 2D turn-based RPG subgenre) think that the games that came before are teplates to be replicated and barely iterated on, especially mechanically. Some games make minor adjustments to the formula, such as the enemy moods in Omori, but some of the best indie darlings are ones that really shake things up, such as Undertale’s talk and pacify system.

Plot

You are Elias, a warrior from a small town sent in holy pilgrimage to Oslo (a heavily fictional take on the real town of Oslo, Norway) in search of ascention to ruler. You are an emissary for The Moon, an otherworldly entity presiding over obscurity and knowledge, to which your small hometown has become loyal to. During the modern era, all external deities are suffering as their strength wanes, causing a deadly disease to spread through your town called Moon Blight. Emissaries of an array of major entities have also come to Oslo in what is almost a tournament to give the throne of the world to their gods, settling the battle for power with only a single external entity ruling. Elias’ pilgrimage through Oslo will have him facing agains the many forces on the same journey as him, growing a party of travellers to accomplish your goals.

Mechanics

While all things in development are ultimately subject to change in the lengthy process, there are a handful of core mechanics I have in mind going forward.

Exploration

My goal with the world of Oslo is to make a single contained map with a sequence of areas (e.g. town districts, a forest, encampments outside the town) that the player can learn intimately during their playtime. I really enjoy playing games that rely on the player learning their environment, such as the Dark Souls series, or the russian RPG Pathologic. Both of these games rely on traversing areas, sometimes multiple times, and getting a deeper connection with the world these areas exist in. A huge point of inspiration is the art of having the player return to older areas that are now changed by the events of the game, such as the spread of infection in Hollow Knight.

I want the world of my game to change and decay as the story progresses, breathing new life into old areas and adding a ludonarrative harmony between the way the world is changing in the story and the way the environment is changing around the player.

Turn Based Combat

Combat is one of the most active gameplay features in an RPG, and traditional turn-based combat can become dragged down by its simplicity, which is why most games of the genre try to add some unique element to it. I want to take this in a completely crazy direction by taking inspiration from a turn based fighting game called YOMI Hustle.

You will choose each character’s moves in a 2D top-down arena, which each have their own duration; selected moves will play out in real-time after you’ve selected what each character is to do. The goal of this becomes predicting your enemies moves and acting accordingly, similar to any real-time fighting mechanic, however, with the added feature of being able to carefully plot out and consider your moves in a turn-based system. You can benefit by choosing shorter moves that end quickly, hoping to catch the enemy mid-way through a move they can’t just cancel out of. This way you have an assured hit, dodge, or generally a definitive knowledge of what the enemy is about to do. The predicted moves for the enemies will be simulated, as will the currently chosen moves for the characters, so you can see the next ‘stage’ of the battle play out before you decide on your actions.

Skills and World Interactions

I want the player’s skills to affect their progression in dialogue as well as their interactions with the world, the same way that those skills would affect a real person. This feature is heavily inspired by Disco Elysium, which is a major mechanical and narrative inspiration for this project.

Dialogue options will be locked off or available depending on certain skills, as well as the level of detail you are able to interact with or experience the environment. This will help add depth to each of the player’s skills beyond simple combat interaction and give them a deeper connection with the world of the game too.

Summary

Visually standing out in the modern era of indie games is almost impossible with the sheer creativity many people are now striving towards when it comes to unconventional graphics, one growing field being the realm of PSX-style games, stylised after the PS1-PS2 era of video game consoles. An interesting way of achieving this effect visually is through the use of dithered rendering, a technique that crunches down the number of colours displayed on-screen while preserving the shading and depth. This tutorial goes over the basics of rendering using dithering, specifically using the bayer matrix. (as well as how to use shadergraph and a custom render feature in unity’s URP)

these are two scenes from a very work in progress game, currently called Twin Angels

Dithered Rendering in URP

Intro

Some time in early 2022 I got really into visual shaders for games, particularly Return of the Obra Dinn’s one-bit dithering technique, and tried recreating it for some smaller projects.

Flash forward to a few years later and I’ve continued to work on this dithering shader and found it really interesting and useful, particularly for a PSX style game. Most of what this post covers can be applied in a variety of different ways depending on what you specifically want to do, and can even be adapted for use as a surface shader.

if you’re interested in learning more about how Obra Dinn achieves its visuals here’s a really useful resource

The Basics

Before we dig into things its probably helpful to have at least a basic understanding of Unity’s Universal Render Pipeline and Shadergraph, particularly the latter as you’ll need to understand how to make a graph and the basics behind creating and connecting nodes (there are plenty of youtube tutorials on the subject if you’re uninitiated).

Dithering

Dithering is an old process of smoothly transitioning between two values in an image, essentially ‘faking’ more data than really exists. Its primary function was to avoid colour banding in compressed images (the big ugly flat surfaces of colour in low-quality pictures) by faking a smooth gradient using clusters of noisy pixels.

It’s a pretty simple effect, but by chequerboarding pixels of two different colours together, at a distance (or rendered as tiny pixels on a screen) they blend into one mid-point colour. Using this, all you do is reduce or increase the density of this chequerboard pattern depending on how far between the two colours a point is.

Using the Bayer Matrix dithering texture we can easily dither between two values. Using this ‘edge’ value sliding up and down in the example we can see which pixels in the matrix are darker than this value, which will be black, and which are lighter, which will be white. In graphics programming this is called a step(edge, value) function, which takes an edge and a value, returning 1 if the value is greater than the edge, and 0 if the value is lower.

We can use the result of this (the little dither square on the right) to interpolate between two values. The easiest example of this is a one-bit shader that interpolates between a background colour and a highlight colour depending on the brightness of each pixel. The basic idea is that this dithering texture is tiled across the entire screen, and then for every pixel in the rendered image we check if the luminocity is above or below that same pixel in the tiled bayer matrix texture, returning either black or white.

The luminosity of a pixel p is calculated in a few different ways depending on your specific purpose, but I went with (0.2126 * p.r) + (0.7152 * p.g) + (0.0722 * p.b). The reason the three colours are weighted differently is because of how the human eyeball percieves colour, with a weaker detection of red and a stronger detection of green and blue.

Here I have a shot of the lighthouse rendered normally, no dithering, against one rendered using a one-bit dithering filter:

(these can look weird on some screens, click to enhance the one-bit picture to see it better)

This effect has been popularised by games like World of Horror by Paweł Koźmiński and Who’s Lila by Garage Heathen (one of my favourite games ever), although both these games also include hand-drawn assets or additional details like edge-detection to enhance the visual appeal of the shader.

now that you get the basics behind dithering we can move onto the render feature.

Custom Render Feature

In URP in order to add our own shader to the render pipeline we need to create a custom render feature, an additional step to the rendering process we can program ourselves. You can refer to the github¹ files to see the basic structure for a custom render pass and custom render feature, which I will briefly explain here.

This is a complicated subject, and my work could definitely be optimised. However, it functions well, and is at least the best baseline way to introduce yourself to the render pipeline and custom render features.

I’m definitely not an expert in URP or render features, but I do understand the basics of it. Our custom little render process comes in two major parts:

1. the render pass
2. the render feature

You can skip right to setting things up if you’re following as a tutorial and don’t care about what these two scripts actually do, but I think its interesting.

Render Pass

The render pass is the little bit of code handled by the URP that tells it what to render at this stage in the pipeline. For our purposes (squashing the resolution down and then applying our custom filter) this is done in two Blit² passes:

1. the first renders the screen to a render texture, squashing the screen down to our desired resolution.
2. the second renders from that render texture to the screen again, passing it through our custom material, and adding the dithering effect. If these steps were performed out of order, the GPU would render a complicated shader across an entire, potentially 4k, screen size, and then crunch it down to our desired resolution. By squashing our image down first, we save rendering time for more complicated shaders, and maintain artistic vision by knowing exactly what the image will look like passing through the filter and onto the screen.

The DitherPass class inherits from ScriptableRenderPass, and we’ll use the override function OnCameraSetup(CommandBuffer cmd, ref RenderingData renderingData) to retrieve the RenderTargetIdentifier for the colorBuffer, which is the identifier for the render texture that the game will display on the players screen, and is what the scene is originally rendered to, and then use the override function Execute(ScriptableRenderContext context, ref RenderingData renderingData) to add our two blits, one from the colorBuffer to our pixelBuffer (the custom render texture with our squashed down size, that we will give to the render pass using our render feature), and the other from our pixelBuffer BACK to our colourBuffer, passing it through the dithering material which we will make in a moment.

If that was a little confusing it can be summarised as

• The screen is drawn to the colorBuffer by the game
• colorBuffer copied across and squashed down into our custom render texture (the pixel buffer)
• this squashed down image is then redrawn to the screen using our material, which applies the dithering filter

remember all these files are accessible on the github¹

using UnityEngine.Rendering;
using UnityEngine.Rendering.Universal;

public class DitherPass : ScriptableRenderPass
{
    // the settings made in the RenderFeature
    private DitherPassFeature.DitherSettings settings;

    // the two render textures that will be written to and from
    private RenderTargetIdentifier colorBuffer, pixelBuffer;

    // construct the render 
    public DitherPass(DitherPassFeature.DitherSettings settings)
    {
        this.settings = settings;
        renderPassEvent = settings.renderPassEvent;

        pixelBuffer = settings.renderTex;
    }

    // retrieve the colorBuffer 
    public override void OnCameraSetup(CommandBuffer cmd, ref RenderingData renderingData)
    {
        colorBuffer = renderingData.cameraData.renderer.cameraColorTargetHandle;
    }

    // execute the two blits and apply the material
    public override void Execute(ScriptableRenderContext context, ref RenderingData renderingData)
    {
        // get a command buffer
        CommandBuffer cmd = CommandBufferPool.Get();

        // queue render from colour buffer to our pixel buffer
        cmd.Blit(colorBuffer, pixelBuffer);
        // queue render back from the pixel buffer to the screen, using our material
        cmd.Blit(pixelBuffer, colorBuffer, settings.ditherMaterial);

        context.ExecuteCommandBuffer(cmd);
        CommandBufferPool.Release(cmd);
    }
}

Render Feature

The render feature is the part of the code that sets up our render pass, and handles both actually adding the render pass to the pipeline and its settings.

The DitherRenderFeature class inherets from ScriptableRenderFeature which lets us override two important functions: Create() and AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData).

We will use a struct called DitherSettings to hold all of the settings and necessary data for our render, including the RenderPassEvent, which tells the pipeline what stage this render occurs (e.g. after rendering transparent objects, before post processing, etc.), the material we will assign our shadergraph shader to, and the RenderTexture in the project files that has your desired resolution. This struct will be serialized in the inspector, and can be seen in inspector for your URP render asset once its added.

In the Create() function we’ll create our DitherPass using its constructor, and passing it our settings, as well as setting the renderPassEvent to the one in the settings.

once again you can find these files on the github¹

using UnityEngine;
using UnityEngine.Rendering.Universal;

public class DitherPassFeature : ScriptableRendererFeature
{
    // the settings for our render pass that will be passed in the constructor
    [System.Serializable]
    public struct DitherSettings
    {
        // when during the rendering process this pass will happen
        public RenderPassEvent renderPassEvent;
        // the material that the render will use
        public Material ditherMaterial;
        // the render texture of our squashed-down resolution
        public RenderTexture renderTex;
    }

    private DitherPass ditherPass;
    public DitherSettings ditherSettings;

    // creating the render pass
    public override void Create()
    {
        ditherPass = new DitherPass(ditherSettings);

        ditherPass.renderPassEvent = ditherSettings.renderPassEvent;
    }

    // adding the render pass to the renderer
    public override void AddRenderPasses(ScriptableRenderer renderer, ref RenderingData renderingData)
    {
        // only adding it if the material AND render texture are set up, so that there are no errors
        if (ditherSettings.ditherMaterial != null && ditherSettings.renderTex != null)
        {
            // adding our pass to the render pipeline
            renderer.EnqueuePass(ditherPass);
        }
    }
}

making custom render passes is how you do any custom post processing in URP, so its useful information even if you don’t intend to use dithering in every project

Basic Setup

Once you have these two scripts in your project, and hopefully have set up URP so that you have a Universal Render Pipeline Asset and Unviersal Renderer Data objects, you can add your render pass to the Universal Renderer Data object.

By clicking ‘Add Render Feature’ and selecting your custom render feature from the dropdown, you’ve added it to your render pipeline. Hooray! but unfortunately you haven’t actually set anything else up yet, so either nothing has happened or your project has started throwing errors.

The next thing to do is to create a Render Texture asset to assign to this render feature in the inspector, as well as set up your Render Pass Event (which should preferably be before rendering post processing).

You can create a Render Texture by doing Assets > Create > Custom Render Texture. Since this will be the squashed down resolution we want, its probably good to set it to something like 640 x 360, or 480 x 270, basically some multiple of 16 x 9 (the standard screen ratio). If you want to try some different ratios, like 4x3 for that retro aesthetic, thats probably better done by adding black bars either side of the screen than by actually messing with the output resolution, since on a full-screen application it will warp and stretch otherwise. Its very important that you make sure your Render Texture has no anti-aliasing and Filter Mode is set to Point, since if either of these things aren’t true it will look strange.

Warning: if you want your application to be resizable, or in a resolution smaller than 640 x 360, you’ll notice some visual disturbances. Hopefully you’re smarter than me and can fix those, since I’ve chosen to live with them. God save us all

Take Heed: For some arcane reason, setting your Render Pass Event to ‘after post processing’ makes the whole thing not work; this means that post-processing wont be applied through the filter and will instead be overlayed on-top. God save us all.

now you hopefully have a working render feature! In the next little section we’ll make a test shader using Shadergraph to make sure its all working good.

The Shader

Although we probably could write the shader out in HLSL, its more fun to play around with using unity’s Shadergraph, since it helps to visualise the shader as it progresses through each node.

The basic idea behind our dithering shader is 4 steps:

1. Round all the colours down to the nearest multiple of our ColourDepth (higher ColourDepth means fewer colours, ironically).
2. Get the remainder of this division, which serves as how far along the gradient between the current and next multiple of ColourDepth is.
3. Apply the dithering texture to this remainder, using it to smoothly interpolate between each step of the ColourDepth multiples.
4. add this back to the result from step 1.

Here’s the lighthouse scene again, this time showcasing each step of our shader, first without any effects applied. As you can see, the second and third stages are really dark, this is because we’re using tiny number values, which are visually represented as very very dark colours. Games like Buckshot Roulette just use the result of the first step, creating cool colour banding (callback to how dithering was originally used to alleviate colour banding in compressed images)

Shadergraph Setup

Shadergraph is unity’s node-based shader editor. If you have installed and set up URP, you should be able to make a Fullscreen Shader Graph by doing Assets > Create > Shader Graph > URP > Fullscreen Shader Graph.

In order to make this shader work with our custom render pass, we need to first give it a Texture2D parameter called MainTex. This name is really important, as the reference name for this variable, _MainTex, needs to be accurate in order for the render pipeline to give our material the correct information.

This MainTex parameter is the texture for our render, and contains the result of the screen’s render. To create a simple test shader, just put this node into a One-Minus node, and then have that output to the base colour out value.

Then, you can make a material using Assets > Create > Material and drag the Shadergraph asset onto that material. You can then assign this material in the render feature settings on your URP asset, which should hopefully output this inverted colours render. (without, and then with the shader active)

Constructing The Shader

For our shader to work we need to setup several parameters. Firstly, as mentioned before, a MainTex texture2D parameter, but also a DitherTex texture2D. We will have to assign this texture in the inspector for our material, and we’ll assign the mayer dither matrix image.

In addition to these two textures, we need a ColourDepth float, which determines how heavy the colour rounding will be, and a ColourClamp float, which cuts off the very top and bottom of the dither texture, making it flatten out faster. I wouldn’t recommend setting the ColourClamp to anything higher than .1, and setting it to anything higher than .5 breaks it all.

Here’s the graph in its entirety, but I will break down each part of it in a moment.

lets start with the dithering texture itself

Working With The Dither Texture

This little bit of the graph works by dividing the size of the MainTex texture (and therefore the size of the screen) by the size of the DitherTex texture. Using this value as the tiling input in a Tiling and Offset node, we effectively repeat this image across the entire screen. This will be really useful when we need to use it to interpolate between stages of the rounded colours.

after this, we use the ColourClamp variable to clamp the upper and lower limits of the dither texture, making it flatten out quicker.

now we can move onto handling the colours

Colour Magic

First, we round the colour of the pixel down to the nearest multiple of ColourDepth. The equation to round a value down to the nearest variable is floor(value / multiple) * multple, which we do to the sampled RGBA value from the Sample Texture 2D node.

also, if you replace floor in that equation with round, you’ll round to the nearest multiple, and ceil to round up to the nearest multiple. Don’t do that for this though, rounding down is important

In our shadergraph, that equation looks like this:

Ignore all the lines disappearing off the bottom of the screen, thats for stage 2.

Now that we have the rounded colours, we need the remainder of this division, which we can calculate using a modulo node. In order to sample our dither matrix, we need a value between 0 and 1 that represents the percentage of the way through the gradient each point is, which is calculated using value / maxvalue = percent. In our shadergraph, this means dividing the result of our modulo operation by the ColourDepth parameter.

Now that we have our percentage, we can run the result though the step node, and then multiply the result by the colour steps, which is our parameter ColourDepth.

Now all thats left is to add this final result to the result of our colour rounding, and we have a finished graph.

You can now happily enjoy the many fruits of your labour. I hope you make some cool scenes using this shader, and learned how to create a custom post processing path in unity!

Footnotes