Portfolio Update – Game Behaviour


I recently put up pages for two projects from the Game Behaviour module undertaken in the final year of my BScH in Computer Games Programming at the University of Derby, which I have now fully completed and received a very pleasant classification for.

You can now head over to the pages for Crispis and DropCakes, and The Frozen Firepits of Generic Dungeon Name for information on these projects, or to download the source code and executables. The former is simply a 2D physics sandbox built upon Box2D and a custom Entity/Component engine, and probably isn’t or much interest to many. The latter, however, you may find interesting if you’re into game design, classic roguelikes, fantasy games, and such.

The Frozen Firepits of Generic Dungeon Name (TFFGDN) was an experimental game design implemented for an artificial intelligence (AI) assignment; it did well, though the AI isn’t too interesting in my opinion. It’s a fusion of turn-based, physics-based mechanics similar to Snooker or Pool, and classic fantasy dungeon-crawler games where a party of adventurers of traditional achetypes such as Warrior, Wizard, Rogue, etc. enter into a monster-infest labyrinth seeking treasure. In its current state it’s not too thrilling; I had intended to implement magic and special abilities for player characters and enemies, which I think would make things a lot more exciting, but I just didn’t have time. I also feel like the physics could be tightened up a lot to increase the pace of gameplay, but I had to do a lot of fiddling with Unity just to get it working in the first place.

Come next week or so I’ll try to have some more information up regarding my dissertation project which was an investigation into AI for Don Eskridge’s The Resistance. Then I can get onto undertaking some small personal projects while I look for work.



Ho! Another delayed post; I said I’d get to this before the semester was up, but this semester hit really hard, and I just haven’t had the time or energy for it. Well, it’s not Christmas yet, so I guess that’s something, no?

The real killer module this semester was Game Development, which consisted of a single group project with three other programmers and seven(!) 3D artists. I started to put a page together for the game we created, “SplashDash”, today; I still need to go over what I’ve written with furrowed brow and fill out the Freerunning Implementation section, but there are already download links for Windows, OSX, and Linux builds, a gameplay trailer, and lots and lots of screenshots to see!


SplashDash is a 3D, freerunning, score attack game, drawing inspiration from games like Jet Set Radio, Tony Hawks Underground, Mirror’s Edge, and de Blob.

Robots have taken over the world and subjected it to their ideals of order and optimisation. They’ve whitewashed all the walls and broken the spirit of the human population, who now go about their daily chores like mindless drones. The player is a teenager gifted with the ability to bring colour into objects with a single touch, and must use it to paint as much of the city as possible in the given time limit to inspire a human revolution.

My main responsibility was the implementation of the player movements, including running, analogue jumps, wallruns, ledgegrabs, vertical wallruns, wallrun jumps, and wall rebounds. I also worked closely with the programmer and artist responsible for the animations to try and make sure things looked as smooth as possible, and though some animation glitches remain I’m pretty pleased with the way things turned out.

The freerunning implementation is, honestly, pretty unrefined, as I’ve never coded such complex 3D movement mechanics, nor used Unity before, and time constraints on the project meant that I could not afford a lot of research or iterate as much as I would have liked. I opted to go with a system which did not require any hints or triggers to be placed into environment, so as to minimize the workload of environment construction. Let’s just say there are a lot of raycasts and a lot of vector maths involved; you can read more about it (once I’ve written it) and my other contributions on the SplashDash page.

We’ve all learnt a lot from this project – mostly about working with Unity, its flaws, quirks, features, limitations, and best practices, but also more transferable skills. We had some communication and organisational issues (which I’ve written about at length for a post-mortem as part of the assessment, and shan’t post online yet) that I think are easily solvable once identified; some simply by picking the right tools and channels, and others by encouraging certain practices. The project was also a good insight into the importance of sorting out your methodology and workflows out early on in a group project – I feel that with time invested in the right places at the start, things would have progressed more quickly, and in a more organised fashion.


Anyway, I think it’s pretty effective as a proof of concept – or not, as the case may be. We all agree that the movement is the most fun part, and that a linear time trial or racing mode, on maps similarly constructed to the tutorial level, would probably be more fun (especially with some nice acceleration mechanics thrown in to reward good freerunning flow). But it is quite fun, all the same, and I think the concept deserves further investigation which, if I ever find the time to experiment with a proper non block-based painting system, I might just be tempted to conduct.

Edit: P.S: Mute the game and go listen to the Jet Set Radio OST while you play :P

London Posting

So a couple of months ago I made this post about what I planned to do with my summer. Well, summer was shorter and busier than I thought it might be, so my best laid plans kind of fell to pieces. I don’t mind of course – I found a decent placement for the year after all – but the chaos that’s dominated the last month or so has left me kind of disorientated.

So where do I stand? I’m in London now, working full-time for a company named ‘Feral Interactive‘, and have just come off of a three-week stint without internet, during which I’ve walked too many miles, watched too many TV series, and played too much Ys. Before that, and before all of the effort that went into arranging the move, I did manage to get through those WebGL tutorials, read a good deal of the Python documentation, and dig through the internet in search of information about network programming for games (without much luck). Mostly though, I just studied Korean and house-hunted. I also bought a small graphics tablet – a Wacom Bamboo Pen and Touch – but I’ve had no time to look into digital art, so I’ve barely gotten used to controlling the thing.

The apartment I have here is small, but nice. It’s essentially two rooms with an entrance down a back-alley – what would be the kitchen-bathroom extension on a terraced. I don’t really spend much time here, what with my working hours, but what I do spend here is comfortable. Once I’m settled I want to get to work on the things that got put off this summer. I’m four chapters in on this maths book, but I’ve yet to get around to doing any OpenGL programming and still haven’t regained any confidence in drawing. To be honest I’ve also considered just taking advantage of the Korean presence down here in London – making language study my extra-curricular priority for the year. Work is tiring, life is complicated. Time will tell.

Right now, I’m watching 원스 어폰 어 타임 임 생초리 (Once Upon a Time in Saengchori). Next? Maybe I’ll hammer out another chapter of this maths book.

Something smells good. I think I live next door to a takeaway.

Three Weeks Freedom

Lectures an tutorials are of course important, but it has to be said that the journey to and from the university, and their inflexible schedules are rarely convenient things. More and more of late I’m finding I’d rather be off investigating things for myself than being forced down particular avenues. I’d love, for instance, to be looking into WebGL and x86 assembly right now, having greatly enjoyed the time I spent with MIPS last semester. Meanwhile, I feel that modules like Team Software Development have long since served their purpose in teaching me in the value of effective teamwork strategies, and now now do nothing but eat into my time. It was with great relief last weekend that I entered the start of a three-week break from such activities.

Three weeks to get well ahead with my assignments, three weeks to get some more job applications off, three weeks to resume my studies of the Korean language, three weeks to look into WebGL or x86 assembly, three weeks to properly maintain my online presence or pursue my artistic interests. So many choices.

One week of that time has already elapsed, and I elected to spend it in the labs, where the PSP dev kits are, working on an optimized, billboarded, particle system for our Console Development 2 assignment. This is the module I’ve enjoyed the most this semester, and the module within which I feel that I have learned the most. Which of these is resultant of the other? Well, personally I think that it’s reciprocal. I’ve not only learned about PSP specific programming and optimization, but also finally found the opportunity to gain an understanding of threading – it’s a lot simpler than it seems on the surface – and undertake a complicated project in straight C. I’ll explain more about this assignment when it’s all tied up.

Speaking of threading, this has also been a feature of my Operating Systems and Mobile Development modules. My OS assignment is pretty much complete, and of little interest – it’s a simple benchmark of communications between processes and threads using the Windows API, and I plan to clear up the written part in the coming week. As soon as my PSP work is done I’ll sort out the write up for that too, leaving me only three modules to worry about when I go back for the last three weeks of the semester.

My Mobile Development project is a 2D game for Android. I’ll make another post about this in the coming weeks, but for now know that it’s a simple points-orientated game about drilling, I’m using the incredible libGDX framework, and the game may someday see itself published if my friends at Pillowdrift decide to take it on once I’m gone.

By gone I mean off on placement at whatever company wants me. I’m still looking, and I’m not worried about the time yet – the deadline is the end of summer and I’m sure I’ll find something excellent. If you’ve found your way here via my CV, a belated welcome to you! I hope you’ll take a quick look at my work under the Projects tab. Anyhow, my housemates and another friend are setting up shop as an indie company next year, and while I wish them the best of luck, I’d rather siphon the experience of industry veterans and prove myself in the real working world. I’ve told them they can have my Mobile Development project, polish and publish it if they wish, so I’m trying to keep the project as tidy and flexible as possible.

Seems there’s only one module I’ve yet to talk about, and this one comes with pictures! No really, I’d happily put up pictures of my other projects but I don’t have access to everything since I’m at my parents’ place right now. Interactive 3D Graphics Programming has taken me through the pains and pleasures of shaders lately, including a brief expedition into PIX to determine the root of some HLSL failures. As best I can tell I now have per-pixel diffuse and specular ambient, directional, point and spot lights working, and a system in place for managing them, attaching them to nodes in a scene graph for transformation. I recently added a similar method for attaching cameras to nodes and now need to re-implement my controllable camera nodes. By re-implement, I mean replace with controllable transformation nodes and attach cameras to those. Specular lighting looks fantastic on my terrain, though the terrain itself is a little bumpy, and I probably should decrease it’s shininess value. The one thing that’s been bugging me with my framework for this project is my use of DirectX constant buffers. Currently I only allow for a single constant buffer per shader set, and all of it’s data is copied across every time something draws. A better, more efficient, more flexible system would be to have multiple constant buffers updated hierarchically in my scene graph. In this way lighting data and other items would only be copied across when they are actually changed, saving a significant amount of time. Implementation of this system is of course dependent on the impending deadline, and seems unlikely, as I also need to implement render targets, collisions, player physics, and a demo. Still, you don’t learn the pitfalls until you try things, and I’ll remember this for future projects.

Let’s wrap this up with some screenshots from my DirectX engine, DacquoiseX. The model of Princess Peach is an adaptation of retrotails‘s over on Google 3D Warehouse, and I intend to use it for my current PSP project, recreating a scene from the ice levels from Super Mario Brothers 2 in 3D, with peach standing on the back of a black whale, spurting watery-foamy-particle-goodness from it’s spout-hole. The demo for this project? Well, that’s gonna be a bit stranger…