Jak Boulton

Software Developer


My overall direction in life is to create unique and engrossing experiences for others to engage in and enjoy. This means bringing my skillset in software development together with the sculpting of art, creative vision and narrative design to formulate interactive experiences. I've been building games for over 13 years and have built a reputation as not only a reliable independant programmer, but also one who is consistently pushing to improve workflows, tools and codebases. When working as part of a team; I thrive in an atmosphere of collaboration where all members are collectively working toward a common goal. I'm here to build, consume and grow in the video game industry.
Besides my love for games and the games industry; my other personal interests include music, film, content creation and learning new skills.



I am an Experienced Developer with origins in C++, 6 years of experience using C# and the Unity game engine and a demonstrated ability to rapidly assimilate new technologies, programming languages and paradigms. I also have a Masters Degree in Software Engineering and a passion for building solutions to complex problems.

C# 100%
Unity 100%
C++ 90%
Rust 70%
Java 60%
Javascript 60%


Faint Embers is a project built as a University submission for a friend. We started with large plans based around a boss-battle heavy platformer, I created a basic prototype movement system which ended up being mostly scrapped as we slowly massaged the game into the interactive experience it is now. The game was built in three weeks, that's everything from design, artwork, music composition and code.

  • Language: C#,
  • Engine: Unity

The game was based on the life of an unfortunate boy who, after a series of horrific events, finds himself stuck in his own mind attempting to deal with a plethora of mental health issues. Overall, the project was a joy to work on and the team we gathered was very talented.


  • Writing: Ethan Bailey
  • Programming and Game Design: Jak Boulton,
  • Art: Rebecca Deakin,
  • Music: Stephen Sims
  • Voice Acting: Chris Goodwin

Shimmer and Shine: Early Math is a game based around exploring Zahramay falls and completing mini games such as racing, completing carpet puzzles and brewing potions. It was built for Fisher Price's Smart Cycle, allowing kids to play with the app by pedalling rather than tapping on the device. I was lead developer on this project and build the majority of the codebase from gameplay code to shaders and native functionality.

  • Languages: C#, Java (Android), Objective-C (iOS)
  • Engine: Unity,
  • Client: Fisher Price and Nick Jr.

Additional Information:

Star Dash Studios is a project built for National Numeracy, an infinite runner with the aim of educating the nation in mathematics. The main work I did for this project was the native implementation of the social features for both Android and iOS along with shader code.

  • Languages: C#, Java (Android), Objective-C (iOS)
  • Engine: Unity,
  • Client: National Numeracy

Additional Information:

Last Mouse Standing

Last Mouse Standing was a game I built alongside Michael Bowerman, Matthew Simkins and Jules Langran as part of the Develop: Brighton game jam in 2017, the theme was "Risky Business".

  • Languages: C#,
  • Engine: Unity

Additional Information:

Tee and Mo: Bath Time was Plugin Media's first published original IP app for mobile markets. It was a game aimed at helping parents and carers get young children to enjoy simple tasks that they generally have a difficult time enjoying such as taking a bath, going to the toilet and brushing their teeth.

  • Languages: C#, Java (Android), Objective-C (iOS)
  • Engine: Unity

Additional Information:

Paw Patrol: Air & Sea Adventures (formerly Pups Take Flight) is an infinite runner style game where the player is tasked with flying or swimming with their choice of dog from the show. While my level editor was used for creating the levels for this game, I generally didn't work on the main portion of the game outside of localisation and porting to Android. I did however rewrite and drastically improve the workflow for localisation for this project (and future projects) by creating an audio package system and editor script that allowed for rapid construction of downloadable localised audio.

  • Languages: C#, Java (Android), Objective-C (iOS)
  • Engine: Unity,
  • Client: Nick Jr.

Additional Information:

Toddle Topplers is a game I built alongside Michael Bowerman, Kayleigh Scullion and Kylie Halley as a submission for the December 2016 Ludum Dare game jam with the theme of "one room".

  • Languages: C#,
  • Engine: Unity

Additional Information:

Shimmer and Shine: Enchanted carpet ride is an infinite runner style game where the player is tasked with flying the genie duo on their carpet through an obstacle course. I developed this project from it's inception to release and was the lead developer on a large content release for the game. During the development of this game I also built an editor and toolset to allow level designers and artists to easily build levels, this was based on placing sections of obstacles as shapes and allowing various assortments of artistic props to cycle for each playthrough. This created a simple workflow for the artists and designers and we chose to use this editor in future projects!

  • Languages: C#, Java (Android), Objective-C (iOS)
  • Engine: Unity,
  • Client: Nick Jr.

Additional Information:

Get Well Soon was the BAFTA winner for Interactive: Adapted in 2016 and aimed to ensure children were familiar with the hospital environment.

  • Languages: C#, Objective-C (iOS)
  • Engine: Unity,
  • Client: Kindle Entertainment

Additional Information:

Dora and Friends is a game based around allowing children who watch the show to create their own stories in the Dora and Friends world, the are able to create their own character as well as interact with many objects and characters in the Dora and Friends world. I joined this project nearing the end and did alot of work on the Android development side (porting the game for Google and Amazon marketplaces); I developed an Android framework to allow more control over various native Android features such as the Audio Focus system.

  • Languages: C#, Java (Android), Objective-C (iOS)
  • Engine: Unity,
  • Client: Nickelodeon

Additional Information:

Enrichment Projects

The purpose of this post is to talk through a collection of the projects completed to gain a better understanding of a specific area of game development. Each project section contains a description of the project and the area of research / enrichment it was meant to tackle.

The Shaders of Firewatch

When playing many games; I wonder how certain visual effects have been achieved. In the case of Firewatch, I watched a GDC video explaining the various techniques titled The Art of Firewatch. This inspired me to spend some time writing some shaders to replicate the effects seen in Campo Santo's Firewatch. The first shader I wrote was a depth based gradient fog image effect, the term 'stylistic fog' was coined as it's simpler name.

The concept for the shader is fairly simple; build an image effect that uses a depth-texture, colouring each pixel based on how far it is from the camera, I used a gradient texture to define the colours used.

The second shader I wrote inspired by Firewatch was a procedural skybox using vastly abstracted atmospheric scattering. The aim was contain the following elements in the skybox:

  • A colour below the horizon line,
  • A colour above the horizon line,
  • A colour for the horizone line,
  • A Sun location and colour.

The shader turned out alot cheaper and simpler than I would have first thought; the most expensive parts of it are the two 'pow' functions. Here is the fragment shader:

half4 frag(v2f i) : COLOR
float3 v = normalize(i.texcoord);

float p = v.y;
float p1 = 1 - pow(min(1, 1 - p), _SkyExponent1);
float p3 = 1 - pow(min(1, 1 + p), _SkyExponent2);
float p2 = 1 - p1 - p3;

half3 c_sky = _SkyColor1 * p1 + _SkyColor2 * p2 + _SkyColor3 * p3;
half3 c_sun = _SunColor * min(pow(max(0, dot(v, _SunVector)), _SunAlpha) * _SunBeta, 1);

return half4(c_sky * _SkyIntensity + c_sun * _SunIntensity, 0);

Bullet trajectory simulation

We have all played a large number of shooters, there are two main methods used to simulate bullet trajectories; instantaneous raycasts or physics simulated bullets. Simulating using raycasts is easy enough to replicate but I was interested in how this was done using simulation - I've also been thinking about how this would work over a network and how this causes issues when there are issues with player connectivity or latency. The networking elements are outside the scope of this mini-project but I'll go through the methodology I used to simulate each bullet's trajectory.

I did some research into the 5.56mm bullet and the M16 rifle and created a basic model for the creation of a bullet prefab to setup the initial velocity. I'd then be able to check my simulation against real-life statistics to see if I have been successful. I used the fixed update to simulate the trajectory of the bullets, starting with integration, then a raycast to check for collisions followed by some debug drawing:

protected void FixedUpdate()
travelTime += Time.fixedDeltaTime;

// 1. Integrate (Heun's method)
float h = Time.fixedDeltaTime;

Vector3 accelerationFactorEuler = Physics.gravity;
Vector3 accelerationFactorHeun = Physics.gravity;

Vector3 velocityFactor = velocity;

Vector3 posEuler = position + h * velocityFactor;
Vector3 velEuler = velocity + h * accelerationFactorEuler;

Vector3 posHeun = position + h * 0.5f * (velocityFactor + velEuler);
Vector3 velHeun = velocity + h * 0.5f * (accelerationFactorEuler + accelerationFactorHeun);

// 2. Raycast (hit detection)
float length = (posHeun - position).magnitude;
ray = new Ray(position, (posHeun - position) / length);
hitInfo = new RaycastHit();
Physics.Raycast(ray, out hitInfo, length, collisionMask);

// 3. Debug
if(hitInfo.collider != null){
Debug.DrawLine(position, hitInfo.point, Color.red, 60.0f);
distance = Vector3.Distance(initial, hitInfo.point);
Debug.DrawLine(position, posHeun, Color.green, 60.0f);

position = posHeun;
velocity = velHeun;

I used Huen's method as the integration method since it's more accurate than just using Euler. The final step was to gather results and compare them against real world values.

In the image above, there are three line colours, the blue line is a basic raycast to get the data used to calculate the bullet drop. The green line is the trajectory visualisation and the red line shows the bullet collision.

These are just a couple of the enrichment projects I've done over the past three years, I generally do one of these projects once every few months (dependant on inspiration).

University Projects

Genetic Path Finding

Genetic Path Finding was my major project and dissertation I completed within my third year of University. I had an interest in AI and was widening my horizons with this project. The project is essentially a comparison between a genetically created program and A* that each attempt to reach the target location on a randomly generated map. I began by researching into a variety of different areas of AI and I came across Genetic Algorithms. This was only part of my project since I wanted to move a character based on a specific program or set of code generated by the algorithm, this is known as Genetic Programming.

  • Language: C++,
  • IDE: Visual Studio 2010,
  • Graphics API: OpenGL 3.3.

1.0 Research

The project began as all projects should; with research. I looked into a wide variety of topics to gain knowledge and an understanding of AI and path finding. The topics researched include; A*, group movement, Neural Networks (and back propagation), Genetic Algorithms (and Genetic Programming) and the main two graphics APIs for the graphical representation section of the program. This led to reading sections of some books, articles and journals written by great authors such as John Koza.

2.0 Design

The next logical step was to design the system, I had been given a very basic framework to work with which displayed a basic cube through a application wrapper using OpenGL. This was the initial starting point for the project before developing all the additions that brought the project to completion. The best way to understand my design is to look over the UML diagram created during the design phase of the project.

The classes in the upper-left of the diagram ( CGApp, CGAppDelegate and OpenGL) show the basic framework provided while the others show the classes I have either modified or entirely created myself while developing the project. I decided upon a naming convention early in the project which was to name prefix the classes that I had written with the letter 'P' (standing for 'project') since this was my third year project and dissertation.

The first class I wrote was the PController class, this interfaced with the OpenGL class in that there were the standardised Update and Render calls. The design I went with was to call these methods within each of the classes that composed the PController class. An example of this is that the map must be both updated and rendered at each frame interval, this would be done by the placing a call to the controller's update and render functions within the OpenGL class, the controller would then call the corresponding functions within the PMap class and the PMap would then call the corresponding functions within the PGround class resulting in a rendered ground object within the scene. This basic design was mimic for each of the classes that needed to be either updated or rendered within the entire program to create a consistent and easy-to-understand design.

The controller class also acts as a Mediator (design pattern) in that other classes can only gain certain information by asking the PController class. An example of this is that for path finding to work correctly; a simple representation of how the map is laid out is required. The PAIPath class computes the path finding within the project and so would ask the controller class to collect the information from the PMap class. The path finding algorithm used was the A* algorithm, however this was only used to compare against the program created through the evolution processes of genetic programming.

2.1 Genetic Programming

The genetic programming element, and arguably the main part of the project was designed and implemented, and this section explains the design and implementation of the system. A basic genetic programming library was used (originally written by Larry Gritz) with some modifications since it was written purely in C rather than C++. The Genetic Program class provides the interface that is used by the different scenes (the path finding scene and the painted desert scene), however each of the classes that setup a given scene are also responsible for the setup of the GP. This is completed by defining the essential group of elements for the GP, these are:

  • Objective: A statement of the problem which we are attempting to solve.
  • Terminal Set: The list of terminals which can be included in any symbolic expressions generated by the GP.
  • Function Set: The list of functions which can be included in any symbolic expressions generated by the GP.
  • Fitness cases: A problem dependant set of test cases which will be used by the fitness function to derive the raw fitness value for each individual.
  • Raw fitness: The method by which the fitness function will calculate the raw fitness measure for each individual.
  • Standardised fitness: An optional method of conversion between raw fitness and standardised fitness.
  • Hits: An auxiliary measure of the number of fitness cases which achieve satisfactory fitness.
  • Wrapper: An optional conversion between output values of an evolved symbolic expression and input values needed by the fitness function.
  • Parameters: Any of the major or minor parameters which control the GP run.
  • Success predicate: An optional condition which may terminate the GP run before the maximum number of iterations.

Once each and every one of these elements have been correctly setup and defined; the genetic program begins to create populations of potential individuals (in this case, collections of functions with terminals as inputs). Once an initial, random, set of individuals are created; they are each tested using the fitness function (defined within the setup). This function returns the fitness score for the individual based on how effective it is at moving the green cube from the starting location in the lower right position of the grid to the end point at the upper left grid position.

3.0 Screenshots

It was clear that with the description above alone, it would be hard to visualise what my completed program was doing and so a collection of screenshots along with explanations was pieced together to construct a more clear image of the completed program.

This image shows how the path finding problem was graphically rendered, there is a basic plane showing the grid-layout of the map with black cubes showing the walls. The green cube and path shows the program generated by the genetic program for this problem and the red cube and path shows how it would be solved using the A* algorithm. This was a failed attempt for the genetic program

This image shows how an evolved program can find a solution that almost matches the optimal path computed by the A* algorithm.

Alongside the main program and graphical representation a basic debug console was written within a small class that redirected the output stream. This was used mainly for debug purposes and it was interesting to output the results and the programs generated.

4.0 Implementation and Additional Information

The complete code can be found on my Github account, the project write-up including research, design and implementation in more depth can also be found here.

Mesh Stripification

Mesh Stripification was the first assignment for the graphics module completed as part of the masters year of my degree. It consists of converting a polygonal mesh into a series of triangle strips in order to save on the number of points and indices sent to the GPU when rendering.

  • Language: C++,
  • IDE: Visual Studio 2012,
  • Graphics API: DirectX 11.

1.0 Research

The project began with research into the various stripification algorithms and how they were implemented. Once a group of stripification algorithms were discovered it was clear that a data structure was required in order to stripify the mesh correctly, the requirement that could not be satisfied with the simple set of vertices and indices was a quick way of searching for edges that were touching eachother, this is when I discovered the Doubly Connected Edge List data structure.

This data structure was used along with a custom version of the  Stripstripification algorithm.

2.0 Design

There wasn't a great deal of designing to do since there was a data structure that was freely available that could be used and the Strip algorithm had already been designed, however the system was built using the DirectX 11 graphics API with a single class created for the loading, converting and rendering of the stripified mesh.

The design and general idea of the algorithm can be found here.

3.0 Screenshots

This image shows the program running, there is also a debug window used for the output of each phase of the stripification process.

4.0 Implementation

The complete code can be found on my Github account, the project write-up including, research, design and implementation in much more depth can be found here.

Cloth Simulation

Cloth Simulation was the second assignment for the graphics module in the masters year of my degree. It consists of simulating a particle lattice using forces and constraints that results in a cloth-like material when rendered. The normal method of simulating cloth - such as Nvidia's method found here - uses the geometry shader, however for this implementation I used a new feature in DirectX 11 called the compute shader.

  • Language: C++,
  • IDE: Visual Studio 2012,
  • Graphics API: DirectX 11.

1.0 Research

A great deal of research went into the DirectX 11 pipeline, how to use the compute shader, general cloth simulation and verlet integration in order to get the cloth rendering using the GPU at a good framerate.

2.0 Design

This was a fairly small project and so the design was already readily available within the Nvidia paper linked above and other resources on the internet. I created a new class to encapsulate all of the cloth properties and setup.

3.0 Screenshots

The above image shows the program running alongside the debug window showing the force controls and the time taken for the class to setup the cloth. During university I would often time my code and attempt to speed it up as much as possible.

4.0 Implementation

The full project and code can be downloaded from my Github account. The write up is also available, it contains a more in-depth explanation of the research, design and implementation phases of this project and can be found here.