After a long wait it was finally time – the 3rd Year Group Project.

Our team was assigned to Guerilla Tea’s Titan1um brief – a side scrolling game featuring 3D characters and dynamic object cutting.

The brief was targeting iOS devices specifically – with Unity being the chosen engine.

Aquabear Productions:

David Gunn, Stefan Harrison,  David Hughes, Max Inkster, Kyle Maxwell, myself, Natasha MacDonald, Conor McHugh, Christy McLaughlin, John Robb, Neil Robertson.

Titan1um source – Unity, C#.

I would have to say our group got along really well, really coming together during the second semester to finalize our prototype.

After our code team broke down and implemented a basic form of mesh slicing, I was tasked with translating the screens swipe gestures into the scene. The mesh slicing code required the cut to completely intersect with the object, and the diagram below shows how I approached the problem.


As it turned out I ended up rigging our games main character T1m.

The character and mesh were created by Kyle Maxwell, then passed to be for rigging and skinning. Afterwards I passed the rig to Neil Robertson for animation.


This allowed me to make up for my failed skinning attempt on Volibear. T1m was a robot, but the mesh did not allow use of rigid binding for the skinning. Therefore smooth binding and re-weighting was required – particularly around the joints.


Given T1m’s bulky chest armor, we were concerned about his range of motion. Despite this Neil produced a rather amazing set of animations.


Procedural Terrain Generation – Diamond-Square Algorithm

For our Procedural Methods module, I decided to explore terrain height map generation – specifically using the Diamond-Square algorithm.

Source code – C++.

As this was based off last semesters Shader Programming submission, again the Rastertek code is not present.

Rather than start off by using code online, I decided to approach the implementation by researching the algorithm. Though I certainly made a few mistakes along the way, and its also certainly not the most correct or efficient method (if there is such a thing).  This proved to be an interesting piece of coursework.


Sadly I believe my own diagram is slightly wrong…

2 and 4 of the 2nd iteration of the diamond stage are the wrong way round.


One of the techniques introduced in the previous semesters Shader Programming was Post-Processing. I’d guess more than a few did not include any for that submission – as it was a requirement for this one.

I set my sights on implementing a depth based blur effect, and I believe I got pretty close to getting the depth information stored as a render to texture.

In the end this Photoshop’d image was a reminder of the failed goal.


Instead I opted to modify the existing blur process – by adding a radial component. This was achieved rather sneakily by abusing the existing texture coordinates.


The blur effect off and on.


Even considering I have opted to skip the down and up scaling stages of the blur method (and therefore rendering the whole scene again twice), the impact on performance was pretty severe.


Volibear Rig


It had been two years since Media Production for Games and my initial taste of Maya.

This module taught the techniques used to create a rig much like the ‘Jimmy’ rig we had animated for that years submission.

For this submission I decided to have a go at rigging Volibear – looking at the opportunities involved in getting the skinning right with all the armour he’s wearing.

Unfortunately I spent rather too long getting the skeleton and IK’s behaving correctly, leaving the skinning too late. This resulted in some pretty substantial mesh tearing – particularly with the upper neck armour plates.

However the skills gained here would later prove valuable for the group project – Titan1um.

Shader Programming – DirectX

Acting almost as a follow up the previous years Graphics Programming – this year we would be looking at Shader Programming in DirectX.

Source code – C++.

This module was taught using the Rastertek tutorials for DirectX 11 – and as that comprises the bulk of the code I have only included the reworked camera along with the pixel and vertex shaders.

Not to bash the tutorials too much – there were only intended to introduce the techniques. As it turned out the tutorials also tended to work under very specific circumstances, so the bulk of the learning for this submission was in the creation of the scene.

The submission slides again explain my areas of focus – the terrain and ocean shaders.

PowerPoint Presentation

PowerPoint Presentation

PowerPoint Presentation

PowerPoint Presentation

PowerPoint Presentation

Hubble Bubble – Rockspin


Hubble Bubble was the second GDS project during the 2nd year of CGT. It however differed as this was not a student made brief – but had been supplied by Rory Kelly at Rockspin.

The brief was for a 3D collection / exploration game, built in Unity 3D and targeting mobile platforms.

The team assembled to tackle this brief was a combination of three of the last semesters teams:

Andrew Allan, George Beard, Michael Cameron, Jamie Cross, Carrie France, Caitlin Goodale, myself, Gordon McKendrick and  Erin Mercer.

For this prototype George Beard was our direct contact with the client as well producing and being our 3D artist.

This was definitely a different experience than a regular GDS project – but to be clear both George and Rory were fully supportive of university work taking priority. A major advantage for the programmer was that three of us actually shared the same flat – making group programming sessions very convenient.

Mirrors & Shadows – OpenGL

After the win32 api game, the rest of the Graphics Programming module focused on OpenGL, with a focus on procedural shape generation.

This submission actually covered two modules – Graphics Programming for the scene and Operating Environments for the threading of the texture loading and sphere generation.

Source code – OpenGL, C++.

With all of the modules tutorials completed, with an not inconsiderable amount of time spent getting a sphere and skybox right – a space scene seemed inevitable.

Anticipating that at least a few others would be making similar submissions, I started looking into some of the suggested topics not covered by the module.

I chose to further investigate and use the stencil buffer within my scene – and after a few failed attempts found that the stencil buffer had not been initialized…

Stencil buffer

Working finally, but with a few issues…

Not reflecting the skybox does a pretty good job of highlighting the transparent plane, and secondly how to fit this into a space scene.

Finding a suitable and decent model to import into the scene via Milkshape was proving rather difficult – mostly as the models I liked usually had too many vertices and often multiple texture files.

Eventually I came across a decent model of a Shadow Vessel from Babylon 5, complete with its scale like texture – and this got me thinking…

How to make a jump point texture!


Finding a usable jump point texture proved impossible – often low resolution or with a ship in shot. Fortunately I was able to create a pretty decent image in Photoshop.

I choose to position the jump point in the center of the scene reflecting along the z axis. This diagram details the layout of the scene, the skyboxes actually overlap entirely.


Scaling aside (its meant to look good, not be accurate) I was rather pleased with the final submission. One of the features I was most proud of is that the skin of the Shadow Vessel is animated, well actually there’s two models each animating in a different direction. This is hard to see but this does enhance the rather scary looking model.

Breidablik – Playstation 2

Source code – C++.

The source does not include the provided PS2 Framework – except primitive.h .cpp as they have been heavily modified.

The final submission for Console Development, the main challenge over the first was the requirement for an implied 3D effect.

Now this could be achieved in a number of ways, I chose to tackle isometric and create a Bauldur’s Gate style game.

As I would later admit in the concluding remarks for this coursework – it was completely out of scope…

Sadly the Playstation 2 DevKits have now been replaced with PS Vita’s – so it can no longer be shown. It featured a single screen of isometric map (I had planned for four…), with the player controlling a knight/paladin – having to defeat three skeletons.


Each had a full set of animations: idle, walking, attacking, action and death.


After completing the 1st semester module on Pathfinding for Games – I chose to implement  A* pathfinding for this submission.

To aid in debugging I created a visual representation of the pathfinding grid:

green for open, red for blocked, white for the player and black for the skeletons.

This image shows what cells have been checked by the A* algorithm when a move command has been issued to the end of the pier. Purple indicates the cell has been considered, and blue cells represent the shortest path calculated.

The main benefit of the A* algorithm is due to the built in distance calculation – directing the wave expansion more efficiently towards the target.




The first of two GDS projects during our 2nd Year of GGT, initially we gathered quite a large team. However due to Group Project work the group size was reduced down to three – which later proved ideal for this small project.

Our final presentation slides explain Junk rather nicely!





My own work for Junk centered around implementing Box2D, and the physics bodies for falling objects.

In an unexpected last minute twist (not like its happens frequently…) we discovered that our prototype played a little too well. We actually left one running during a team meeting and watched the high score climb… Right before the final presentation we came with the idea of flipping round our concept – no longer a Tetris eliminate a row style game, but to stack the objects to the objective without creating any horizontal rows.

The result was a superbly difficult game – with only a handful of testers actually winning during the GDS showcase.

Dark Souls: Windowed Edition – winapi

An early submission for Graphics Programming – we were tasked with creating a 2D sprite game before moving on towards OpenGL.

I had been playing alot of Dark Souls at the time, so decided to go about creating a simple representation of a boss fight.


Though simple I attempted to recreate Dark Souls stamina system as accurately as possible, with stamina being consumed for attacking and blocking incoming damage – and regenerating only while not blocking.


Overall mechanically this was a very simple game – I believe I spent more time in Photoshop cutting out screen shots of a knight and creating the sprite sheets…

Disc Wars! – Playstation 2

Disc Wars! was a Tron themed 2D sprite game created for the first submission for Console Development.

At the time we in the process of learning and developing a framework for the Playstation 2 using the Linux development kits.

Most of the work for this submission was based around playing around with the frameworks sprite class. At this point we had not covered loading in textures , so I explored playing with the drawing information being passed to create gradients and patterns.


The player controls the grey triangle – with forwards/backwards and rotational movement only. The black line within the rings indicates the current direction of incoming discs – which must be dodged by the player. During  the game the center rings will pulse and rotate before settling on a new direction – changing the direction of all the discs in doing so.