Whilst my main area of focus is in programming, I also have 3D modelling (3DS Max) and engine experience (UDK / Unreal 4, CryEngine).
I co-founded Wrench Games LTD with fellow Abertay students, and have helped to create many digital prototypes, and the companion App for the upcoming Blind Wizard Brawl card game.
In my spare time, I also take an interest in electronics, robotics, and 3D printing; creating gewgaws and thingamabobs that are sometimes functional and often fun.
HND Computer Games Development (Adam Smith College)
Bsc (Hons) 2:1 Computer Game Applications Development (Abertay University)
The blog was removed a while ago but it's time to make a comeback. Here are some of the things I've been up to this year.
An automated terrain carving tool that allows for easy creation of water based terrain features. The user simply defines the river properties in the box and and then clicks a point on the map, the code then works out the flow path of the water and carves the terrain out. It does not have water simulation as that was beyond the scope of the submission however it does a very good job of faking it, and runs much faster than a fully fledged simulation would.
I took part in a few more game jams, GGJ17 and an Interpol game jam (our game got through to the final round in the US). Kill spill was a wave based punching game in which the player has to fight of waves of enemies whilst being swamped in waves of physics based pixelated blood. The Interpol game was a game designed to educate new employees on IP theft by giving them a small mystery to solve in a town.
I was tasked with making an app for a new game over at Wrench Games, Blind Wizard Brawl is a print and play card game that uses either a web based or android companion app (iOS app coming soon).
I decided to learn YoYo's Gamemaker Studio for the project, and pumped it out in an afternoon. It's a very easy tool to learn and the export options are both diverse, and incredibly customisable.
You can see the web app here, as well as download the print and play cards, or the android app.
Simple brick bump map.
There are now enough graphics features in place to start implementing and testing other non graphics features.
The fbx loader is all but done, there is a small indexing bug to sort out, and need to implement a stop for duplicate vertices.
This project will no longer be for university but it will get updated frequently.
I will add occasional updates on my uni project here too as it should be interesting. I'm considering making a visualiser with some liquidy effects and some neat partical/cloud effects.
So I've made my way through a good bit of the books, they are a little outdated, but it's easy to find replacement code for outdated functions.
There is much more work involved in setting up the window compared to the setting up a fixed pipeline GL app.
I've created a new D3D specific .OBJ model loader, and I'm working on a .FBX loader too.
The screenshots below are the .OBJ loader, they are both single model files (they are for testing purposes from TF3DM, not mine).
As can be seen on the island, the model loader supports transparency, as well as multiple meshes and textures within the one file.
For the next update, I plan to have a functioning static FBX model loader, as well as instancing for render large numbers of meshes.
The FBX SDK is provided by Autodesk, to help developers load .FBX files into their applications. It is available for free at present from their website and has online documentation, as well as a forum for developers to share ideas and help each other.
In spite of this, I've found it to be not as accessable as I would've liked, due to the information mostly being geared towards app developers rather than game developers.
They use different terminology than game developers for a lot of things, for example a vertex is a 'control point'.
At present my loader, loads vertices / normals / texture coordinates / materials. It has some issues that I need to work out before showing, however it ought to be ready for the next update.
Instancing is very important if you plan on displaying large volumes of meshes, it involves telling the pipeline what to render and where to render the instances of an original model. A good example of this would be the Total War series where there are thousands of animated soldiers on screen at once.
The card wouldn't be able to handle having the data for each mesh passed in at once, and calculating and rendering them all at a sensible frame rate, so an mesh is passed in for each on screen mesh in it's current state, and that is then instanced.
An instance can have slight difference to the original, obviously the position will likely be different so that you can see the other mesh. They can also have different scales, rotations, colours, the list goes on...