Monday, 20 June 2022

Wanderland [ Lost Relic Jam ]

You have entered a weird world full of threads and silly cats. can you find a path through this strange place?

Or will you end up bound here? Forever tethered to your Wanderland.

Wanderland is a short adventure game I made in a week for the lost relic game jam. It is currently playable at this link:

The game features puzzles related to the key mechanic of being tethered to needles placed throughout the levels. And there is a simple story for the player to uncover over the course of the game. 

An example of the tethers in action.

The game is built using a custom framework/engine built on top of monogame.

I hope you enjoy :)



Thursday, 7 April 2022

GrimTide: Delay the inevitable [ Ludum Dare 50]

I recently created a game for the Ludum Dare game jam. A 3 day event where you have to make a game based on a theme. The theme for this jam was Delay the Inevitable.

My entry was GrimTide, it is a dark, surreal strategy game. Inspired by the likes of Minesweeper, Missile command, Creeper world and even some Factorio.

The gameplay is simple. A tide of red stuff is creeping towards your factories. You have to hold it back for as long as possible. 

  • Build factories on purple squares to generate resources.
  • Use proximity mines to protect your factories, and mortars to clear out the red stuff.
  • Prevent the red from creating new sources by shooting it’s spores out the air with missiles.
  • The tiles are randomly generated, so no two runs are the same.

The game was built using C# and Monogame. Blender and GIMP were the primary tools for creating the artwork.

GrimTide is available to play from the Ludum Dare website:

Source Code can be found on github. (for reference only)

Monday, 11 January 2021

Old Blender game links

I was recently made aware that the links to my old games had gone down. Here are updated links to the files. 

Tome is packaged with the blenderplayer so should be playable with the files provided, The other projects are just the blender files and assets, you will need an old version of blender to run the game properly. I've included the version of blender each .blend file was saved with, this should be the one needed to run the game.   

Tome (Blender 2.63)

Use the password mattline1 to download the onedrive links

Sky  (Blender 2.66)


Thursday, 30 April 2020

Batch rendering of faces for machine learning

A colleague was recently working on a machine learning paper for generating 3d facial models, in order to train the network a large number of facial images were required.

These faces required known camera settings, orientations and vertex positions. Whilst he was able to generate such images from Matlab, the lighting was not realistic (blinn phong lighting model) and this was causing accuracy issues when the trained model was applied to real faces.

In order to improve the lighting and accuracy of results I suggested he switched to using Blender Cycles. In support of this I wrote a python script to quickly import facial models, render them in a variety of lighting conditions and export the resulting images.

pre-generated faces, batch rendered by the script.

The script iteratively loads collada models from a user specified folder, renders them under 12 different lighting conditions and exports the resulting images to a user defined folder.

=== Code available here ===

And the .blend file used for rendering:

Thursday, 24 October 2019

PS1 Horror Game Jam weeks 1-2

Disclaimer: The pictures are works in progress. I will make proper models and textures when the functionality is done. Probably in the final week. 

There is a Discord community dedicated to development of PS1 style horror titles, which is super niche but also sounds like a lot of fun. Every now and then this community does game jams, I have joined in this time. For those interested, here is the link to the jam page:

The optional jam theme is 1 room. I had initially intended to follow this theme, and had envisioned a game where the player is trapped aboard a station and must escape by controlling the various systems of the station via terminals in the control room. However, Alien Isolation is very good, so ultimately I chose to rip that off instead...

WIP control room level

The premise of a space station remains, some event has rendered the place uninhabitable. The player awakens locked in a room, the objective is to leave the station alive. To achieve this they must find their way out whilst avoiding the monster that prowls around. Consoles placed around the station allow the player to control the various systems present, such as doors, power etc...

The station is full of hazards and obstructions. Items can be obtained to overcome these obstacles or warn the player of the existence of Hazards, as well as the means to traverse them.

Below is an account of the first couple of weeks of development:

Devlog Weeks 1-2

UE4 is the engine of choice for this project. I've used it for many years and it does it's job very well. I opted for blueprints for the game logic. Whilst C++ is normally my tool of choice, BPs have such fast development and iteration times that they're perfect for Jams.
Getting UE4 to look like a PS1 titles may take some work, but should be doable.


Somewhat standard, currently players can crouch, but not sprint. I'll likely add a sprint option, it would make a lot of noise to move using this. Currently movement is slow, by design.  

Looking around is controlled via the arrow keys rather than the mouse. This is very clunky, which is the point. This will likely be kept as the default behaviour, but I envision complaints about this so players will have the option of enabling mouse control via the menu. 

Interactable actors

The bulk of mechanics that were implemented over the past couple of weeks are based on interact-able actors. These are objects that implement 3 methods.

The player can interact with items such as this by looking at them and then pressing the interact button (OnInteract), or holding the interact button (OnHeldInteract). OnParameteredInteract is a little more interesting. A string parameter can be sent to and returned from the function call. This allows for more complex interactions.

A prompt popup for interactable actors, in this case a screen.

Interactable actors can call the interaction functions of other interactable actors. This allows for complex systems to be set up between objects in the level.


They open, they close, sometimes they're even a jar. Doors can sometimes be opened manually but are also able to be controlled remotely. They can jam, which will require the player to look for alternate routes, or find a way to open them.   


Breakers connect to other interactable actors. They can be used to activate and deactivate those actors. 
Notably, they can connect to other breakers, and are operable remotely. This allows for an approximate power system to be implemented with different breakers controlling each area/room. 


Vents block the way past, unless they are first cut open. To do this the player will need to have found an oxyacetylene torch. The purpose of vents is to gate the areas players can access early on. Also crawling through ducts is quintessential sci-fi horror, so it must be done.


Viewable actors 

Viewable actors inherit from interactable actors, however when interacted with they take the focus from the player. Each viewable actor has a camera, when the actor is focused this camera is used in place of the players. This allows for the player to interact with the scene in more interesting ways. 


Lockers provide a perfect hiding place for the player. When inside the monster can't see them. currently hiding inside always takes a second or so. However a system where players can choose to hide quietly but slowly or quickly but loudly could be interesting. 

As in Alien Isolation, the monster will potentially inspect lockers it is suspicious of. In this case the player will be able to hold their breath and hope it doesn't notice them.

Needs texturing, but PS1 style does make the modelling simple. 


Screens allow the player to interact with the various "systems" that exist around the station. This basically amounts to calling the OnParameteredInteract functions of other interactable actors. Each actor has a number of commands it can respond to, for example a door can be opened or closed. This can be done via text commands entered into the screen.

An example of interaction with a screen

Each of the screens in the station have a help menu available. This allows the player to see what systems the screen is connected to, as well as which commands are available from those screens.  


Allow for vertical movement round the level. Once activated the players movement is constrained to the ladder until they reach to top or bottom.  

Save/Load Stations

Like in Alien isolation, saving can only be done from specific save stations around the map. These are not guaranteed to be in safe spaces, so care should be taken when saving.
I will likely need to add a rollback function, to go back to previous versions of saves, otherwise players may end up in situations they can't escape from. The alternative is not saving the location of the monster, so you can't be instantly killed on a bad save... 

An example of a save screen, instructions on how to use in the top right. 


There are various hazards littered through the map that the player will need to be careful to avoid. Prolonged exposure to these will result in death. 


Some areas of the station have been exposed to radioactive elements, entering these areas without a hazmat suit will result in radiation poisoning.
The player can acquire a Geiger counter to be warned when they are entering dangerous areas.


Areas where the hull has been breached are infrequent but extremely dangerous. Exposure to the vacuum of space will very quickly result in death. 
The player can obtain a spacesuit to traverse these areas safely.  


The player can hold Tab at any point to get an overview of their objective as well as any items or suits they may have acquired. 

I still need to tweak the brightness of this menu... it's a little dark.

Plan for Week 3

The monster so far, oh the horror.
The plan for the next week is to build the monster AI, I have used UE4s behaviour trees & environment query system before so have a good basis to work from here. The AI perception system is not something I've toyed with yet, so I am planning to use this as an opportunity to learn it. 
The next post will probably include a breakdown of how the AI is functioning. 

I've yet to decide if I am going to go with a mutated monster of some kind, perhaps that gives off slight radiation so the Geiger counter can detect it. Or, I also like that idea of a haunted space station, complete with creepy Victorian era ghost. Perhaps with an EMF detector for knowing when the ghost is close. 

Also on the task list is getting sound done for the major mechanics as well as ambient noise. Sound is so important and too often I overlook it until the end. 

Monday, 1 May 2017

Leadwerks PBR #2

0DA7FDF32E4C3DBC9982F6F89ADD4995AA34B00F (2048×1152)
Crytek's Sponza atrium rendered in Leadwerks using PBR

Physically Based Rendering (PBR) is a workflow and rendering method. It couples a set of shaders that approximate physically accurate optical effects with input that is based on the properties of real surfaces.

PBR has become the standard method for rendering surfaces over the last few years. It is the default rendering method for game engines such as UE4, Unity 5, FrostBite, Cryengine and more. It is also being used in film studios such as Disney and Pixar. 

This project aimed to implement this rendering method into the Leadwerks game engine to bring the benefits of PBR to it's users. The flexibility of the engine, coupled with recent updates to it's graphics engine such as environment probes and HDRi have allowed this to happen.


PBR is supported in both the C++ and LUA versions of the engine.

Physically based shading model

The system uses a physically based shading model based on EA's Frostbite engine and Unreal engine 4's implementation. The shading model uses Disney's principled BRDF for diffuse lighting, with the frostbite normalisation factors. 

Specular highlights are generated using a BRDF consisting of; GGX for the NDF, Shlick's approximation for Fresnel effects and Smiths shadowing for the visibility function.
For more information on the details on physically based shading models I recommend the work done by Sébastian Lagarde for remember me as well as the SIGGRAPH physically based rendering courses. 

Metalness / roughness workflow

To create content for the PBR system a roughness/metalness workflow is used. The system has been deigned to match the output from Substance painter/designer as closely as possible.

  • Roughness: determines how rough a surface is, black = shiny, white  = rough. 
  • Metalness: determines whether a surface is metal or not, white = metal, black = dielectric(non-metal). this should really be fully white or fully black.
  • Specular: Specularity can also be modified, specularity affects the intensity of specular reflections, this value relies on the Index of Refraction of a material. 
    • For shaders that don't specify specular, the value defaults to 0.04. This value represents an ior of 1.5, most materials have ior's near this value. If a texture is used then the value of the texture is mapped to a 0.001 - 0.08 range. 99% of surfaces have specular values in this range. This precedent is taken from the UE4 system.

Decal support:

Decals allow for areas of extra detail to be added to areas.

Decals modify the underlying surface properties, this includes roughness and metalness.  

Terrain / Vegetation support:

Vegetation and terrain are supported.
Image provided by Jen from the Leadwerks forums - showcasing the vegetation and terrain shaders

The vegetation shaders all work the same as the built in defaults, with distinctions for static, leaves and ground foliage. For best results I advise using shadows on vegetation objects, if performance allows.

Terrain also works in the same way as default leadwerks. Because of this metalness, roughness and specular cannot be controlled by textures. Therefore terrain is assumed to be dielectric, Roughness uses a combination of the Albedo's value and a set value of  0.05 and specular is set to 0.04 (this is the same value used when there is no specular map).


Also included in the PBR system is a Filmic tonemapping post process shader. This allows artists to take full advantage of the HDR system available inside Leadwerks. 


The project is available from GitHub

Limitations / improvements

  • Requires a gamma-correction post process shader. Not a huge issue, adding a pp is pretty easy but still something to remember.
  • Currently the built in environment probes are stored in a low dynamic range. This leads to clamping and precision errors as HDR values move towards extremes. this limits the usefulness of HDR. This is an engine issue I can't fix.
  • Probes also use simple mipmapping for different roughness values, PBR often performs a convolution on these values to better match reflection blurring due to roughness. A fix may be possible for this, but would require C++.


Alamia, M. (-). Article - Physically Based Rendering - Cook–Torrance. 
Alamia, M. (-). article_gamma_vs_linear.
Alamia, M. (-). Physically Based Rendering.
Brent, B. (2012). Physically-Based Shading at Disney.
Carmack, J. (2013). The Physics of Light and Rendering. QuakeCon 2013. 
Chan, D. (2015). Real-World Measurements for Call of Duty: Advanced Warfare. Siggraph 2015. Sledgehammer Games/ Activision Blizzard.
Christian. (2011). The Blinn-Phong Normalization Zoo. Retrieved from The Tenth Planet:
Gotanda, Y. (2012). Practical Physically Based Rendering in Real-time. Game Developers Conference. tri-Ace, Inc.
Gotanda, Y., Hoffman, N., Martinez, A., & Snow, B. (2010). Physically Based Shading Models for Film and Game Production. Siggraph 2010.
Hable, J. (2010, December 5). Everything has Fresnel.
Hable, J. (2010, November 7). Everything is shiny.
Hoffman, N. (2010). Crafting Physically Motivated Shading Models for Game Development. Siggraph 2010. Activision.
Hoffman, N. (2013). Background: Physics and Math of Shading. Siggraph 2013.
Iwanicki, M., & Pesce, A. (2015). Approximate models for physically based rendering. Siggraph 2015. Activision.
Judge, K. (2011, August 23). Shader Code for Physically Based Lighting.
Karis, B. (2013). Real Shading in Unreal Engine. Siggraph 2013. Retrieved from
Klint, J. (2006-2016). Leadwerks Engine.
Lafortune, E. (n.d.). Mathematical Models and Monte Carlo Algorithms for Physically Based Rendering. Leuven: Department of Computer Science, Faculty of Engineering, Leuven University.
Lafortune, E. P., & Willems, Y. D. (1994). Using the Modified Phong Reflectance Model for Physically Based Rendering. Department of Computing Science, K.U. Leuven.
Lagarde, S. (2011). Adopting a physically based shading model.
Lagarde, S. (2011). Feeding a physically based shading model. Retrieved from
Lagarde, S., & Hardui, L. (2013). The Art and Rendering of Remember Me.
Lagarde, S., & rousiers, C. d. (2014). Moving FROSTBITE to PBR. Siggraph 2014. Electronic Arts(EA), EA Dice.
Lazarov, D. (2011). Physically based Lighting in Call of Duty: Black-Ops.
Lazarov, D. (2013). Getting More Physical in Call of Duty Black Ops 2. Siggraph 2013. Activision.
Meinl, F., & Dabrovic, M. The Atrium Sponza Palace. Crytek. Retrieved from
Neubelt, D., & Pettineo, M. (2013). Crafting a Next-Gen Material Pipeline for The Order:1886. Siggraph 2013. ReadyAtDawn Studios.
Pharr, M., & Humphreys, G. (2012). Physically based rendering: From Theory to Implementation. Morgan Kaufmann.
Seymour, M. (2013). Game environments – Part A: rendering Remember Me.
Wilson, J. (2013). PBR Practice.

Friday, 21 April 2017


A little project I've been working on. Still wip, will probably do a proper video once it's come along a bit.

Using SDL for controller input
It's all C++

Wednesday, 17 February 2016

Physically Based Rendering in Leadwerks (C++)

As part of my final year university work I’ve been looking into Physically Based Rendering(PBR) and its implementation. PBR is a method of generating images that takes physical values into account, this means lighting behaves much more predictably and accurately.

This link gives a fantastic, and in depth look into how PBR works in Remember Me. Notably, PBR systems aren’t all the same, often times they use different algorithms to generate images, and there are many ways to generate reflections for them.

This PBR uses a runtime rendered cubemap to generate reflections and ambient diffuse lighting on objects, nice for avoiding the flat lighting in shadowed areas problem. It then uses a physically based BRDF to generate specular highlights.Currently static models and animated models have shaders, there is also preliminary decal support. All light types are supported with shadowing. The materials use metalness/roughness maps.
There are a number of example assets in the zip file.

You’ll need the C++ version of Leadwerks for this one, the reflection generation code is written in C++ and relies on a number of OpenGL calls to function properly. This does mean however that you can generate a new reflection map at any point.

I was aiming for a similar system to what was used in GTAV. For that game a low poly, diffuse only environment map is generated each frame in order to render reflections. However for my work the performance isn’t quite high enough to generate a reflection map per frame yet. Reflections are generated as cube maps, that map is then sampled with GL_SEAMLESS_CUBEMAPPING enabled, the lowest mipmap is used for diffuse lighting then higher mip values are used for the specular reflections.

(If you are using the lua version of leadwerks, you may be able to use pre-blurred cube-maps and get acceptable results)

Here’s an example of the shaders working on a complex PBR asset. Built by Andrew Maximov,



I’m looking for feedback on how robust the system is, so here is a download link, you're free to use this as you please.

I’ve had to use the alpha channel for gloss values so transparency is a bit borked. Decals suffer from the alpha problem as well.
I’ve looked into binding reflection textures to the lighting shaders which would avoid the alpha hijacking. But it doesn’t seem to work if any post processing or water is used. If anyone can point me in the right direction here it would be appreciated.

This implementation uses normalised Blinn-Phong for the distribution term, Schlick’s approximation for Fresnel, and Smith’s shadowing function for the geometry term.

there was weird overlapping going on but putting an image here seemed to fix it... so here's my avatar! will fix this soon.

Thursday, 3 July 2014

Custom GLSL shaders in BGE: View independent reflections

Reflections are an important part of creating realistic materials, unfortunately they are difficult to render in realtime. The specular component is a vague approximation of a light reflection but for metals or glossy surfaces it isn't really good enough.
Using raytracing is an elegant solution, however it is beyond the abilities of modern graphics cards to render accurate realtime reflections with this method and maintain playable framerates.

Thus we get image based techniques for rendering realtime reflections. There are 3 main techniques for displaying reflections, sphere mapping, dual paraboloid mapping and cube mapping.

Sphere mapping is the simplest method of generating reflections, it is also the easiest to use in the blender game engine as it is natively supported by the material editor.

A sphere mapped Suzanne
The main drawback of sphere mapping is the fact that it's view dependent, meaning, whatever angle you view the object from, the reflection will always be the same.

This is where view independent reflections come in!

Two techniques exist to render view independent reflections, the current industry standard method is cube mapping, but there is also a technique named dual paraboloid mapping.

Dual paraboloid mapped Suzanne's
The benefit of using dual paraboloid mapping is that you only need two textures to achieve the effect, rather than the six required for cube mapping.

2 Textures representing the reflection on an upper and lower paraboloid
Dual paraboloids do have disadvantages compared to cube maps, they are more prone to distortion and are less well used so resources on them are limited, if you are interested in learning more, these are the resources I used when implementing them:
Dual paraboloid reflections - Kyle Hayward
The art of texturing using the opengl shading language - Environment Mapping - Jerome Guinot

Finally we have cube mapping, as previously mentioned cube mapping is the most common technique you will see for displaying image based reflections. Compared to dual paraboloid maps, cube maps have less distortion, a more consistent pixel density and are also easier to generate.

Cube mapping

Cube maps do however require 6 separate images making them the most expensive to render in realtime. Blender has support for cubemaps (via custom GLSL shaders), it does however have a few issues with it's implementation the most notable being the inability to change the cube map with bge.texture (as far as I can tell).

A blender cube map
Information on cube maps can be found everywhere, here is a link to the site I used to create the shader. There is also many advanced techniques that can be used to enhance cube maps, notably these include box projected cube environment mapping. Remember me and Ryse son of rome also used a technique called Parallax corrected cube mapping, the details of that went a little over my head however!

===================== File Download ========================

This was quite a broad overview of these techniques, there is plenty more to discover if this interested you.

Again, there will be a post up in the coming weeks continuing on from this.

Thursday, 26 June 2014

Custom GLSL shaders in BGE

Has it been over a year since the last post!? Whoops.

As you may or may not be aware the blender game engine has support for custom GLSL shaders. These allow greater potential variation than the material panel by giving an artist access to how the game renders at a lower level.

I've been having a go at writing these recently:

First off we have a standard Phong shader, This uses Lambert diffuse and a stretched Phong for specular highlights. There's a version with clipped alpha support as well.

Next up cube mapping! For non-planar reflections, cube maps have pretty much become the standard in real-time applications. Blender's support of them is unfortunately a bit limited, I was unable to get variable roughness with cube maps as there is no support for choosing the mip level with them. I was also unable to swap them around with bge.texture, making changing the reflections based on the location in a level difficult to achieve.

Finally we have something a little more interesting, normalized Phong! This is a simple tweak to the Phong shader that provides quite a pleasing result. it takes principles seen in PBR (physically based rendering) systems and applies them to a simpler model.

Essentially what this shader is doing is using 1 texture to control specular intensity and gloss values, but it does so in a physically correct manner. this makes for small, bright highlights on shinier objects and more matte, dimmer specular on rougher objects.

All the shaders you see above are gamma corrected so they should look fine on most monitors, I may modify them to accept external values for the gamma. It would be trivial then to make a gamma slider option, that'd be all professional and whatnot.
Unfortunately they don't have shadow map support and only seem to recognize up to 8 lights, that said future versions of blender have been pegged to be getting some updates in the shadows area (hopefully), not sure about the light limit.

===================== File Download ========================

Hopefully someone will find them useful!

There will be another post up next week continuing on from this one.