Final Portfolio/Showreel Feedback & Chosen Disclipline

This afternoon I delivered my final portfolio to all members of staff present and was given my grade for it. Here are my thoughts on the whole submission.


A common mistake during the Christmas 2016 prep run for this was talking too long about your work and treading over ground the lecturers are well aware of. So I made the decision to edit everything into a reel, its a little long for a standard industry showreel but has to cover all aspects of the course and a years worth of best work from each module. So eight minutes isn’t bad. I themed it 1980s style and did all the title card work in After Effects for some extra spit and polish.

Feedback was immensely positive and the few bits of constructive feedback I received were as follows:

  1. Where I collaborated on a project, clearly state which aspects I was responsible for.
  2. For future reels, cross fade music track to music track without any pauses between audio. Gary compared this to an animation where it stops suddenly and is jarring to the viewer.
  3. When rendering animation cycles or anything with a ground plane in future make sure objects are actually touching the ground (my cycles were hovering and casting shadows making it really obvious).
  4. My font choice for the lower banner is a little bit unreadable (I was worried about this and seems I was correct). Thankfully an easy fix to make.

The fact those few points were the only things to be raised, I’m absolutely bloody thrilled! I was graded a Distinction for the portfolio. It has been a fantastic first year and has really woken up a side of me I’d considered long gone, as sentimental as this might be, a big thank you to all of the staff over the last year who made this possible. I’d buy you all a beer but rules don’t allow it, so catch me in another year!

Now after seeing some of the truly wondrous talent at Animex, I don’t personally feel like I’m anywhere near the level of talent I need to be despite the grades. So I have a long year ahead but more on that in a moment.

Chosen Disclipline

Being a mature student with some prior experience I already knew when I joined I wanted to focus on modelling and texturing. That isn’t to say I’ve not picked up new things I have an interest in over the year, I’ve really enjoyed my After Effects from the more motion graphic kind of work to compositing and matte painting. I don’t want to lose or ignore these new skills but will likely continue them as a sideline/hobby and continue to focus on modelling.

I’ve gotten to grips with Maya, had great success with Substance Painter and am looking to purchase ZBrush over the summer to include it into my workflow. I’ve also had some great texturing success using curvature maps and generators to weather and age models. Over the summer I plan to get much better use out of my paid for training materials (Pluralsight) and brush up further on all of these tools. Hopefully I should return for the synoptic project ready to produce something the industry would be proud of! My time left to succeed is limited so if I don’t kick it up a notch now, I’m only hurting myself.

Year One – Contents Summary


This is a post bringing together all of my submissions to allow teaching staff easy access for marking. I’ll categorise to each module.

3D Modelling

3D Room – Feedback Re-submission

Low Poly Project – Submission

High Poly Pirates – Wk 4&5(unfinished)

Concept Art

Robot Concept Brief -Developed Design

Dystopian Vehicle – Final


Animation Ident – Final

Break the Cycle – Animation Project Submission

(Optional Animation Post/VFX)

After Effects Rigging – Animation with Expressions (Pt.3)


VFX – Final Idea Pt.4

(Optional VFX Posts)

VFX – Skin Replace/Glow

VFX – Matte Painting

After Effects – All Star Credits (Pt.2)

Game Design

Analysis of Game Design Pt.1

Analysis of Game Design Pt.2

Analysis of Game Design Pt.3

The Maze Game

Xmas Game – Submission

Another Xmas Game – WIP

Programming (Yeah I know the grade isn’t based on posts but it keeps my mind organised)

Exam Prep – Individual Game (Pt.3)

Walking Sim – Unity Asset Creation

Walking Sim – Adding Scene Interactivity

Walking Sim – Polish & Peer Review


Global Game Jam 2017






Analysis of Game Design Pt.3

Sadly it is time to ditch my beloved Sega for something a little more recent and on the cutting edge. Six months ago I bought a HTC Vive, and struggled to find good content that I would actually call a game rather than an ‘experience’. Then came along the gem that is Vanishing Realms. While it isn’t hugely famous like the other titles I’ve covered and therefore information may be a little sparse, I’ll do my best to cover this little VR gem. I’ll be covering the same criteria as before:

How available hardware impacted design.
● Intended audiences for the game.
● Critique the game. Talk about game
design, visuals, mechanics & performance.

Vanishing Realms


Hardware Available at the Time


This point seems a bit obvious given it’s plastered right above, the HTC Vive. I won’t do a write up of what the Vive is as I already have a quick review of the hardware from last year on this blog (which actually made me go buy one).

VR Experience

However I always wondered how such a fleshed out Vive game could be released alongside the launch of the hardware itself. We’re still waiting for major Vive titles as people get to grips with development for it. After some investigation for this post it all makes sense. The sole developer Kelly Bailey worked for Valve up until February 2016, contributing to every Half-Life game and Portal. It seems obvious now that he would have had early access to dev kit versions of the Vive long before it’s actual release. The more astounding fact is that he made Vanishing Realms by himself in eight months before its launch on Steam.

Target Audience

This is kind of hard to say, there is no age rating information anywhere for it. Or even any developer comments on intended audiences. I feel like the intended market is already slim to begin with, as uptake in VR systems are slow due to the high price tag however I feel the real audience is anyone that grew up with a love of classic role playing games such as tabletop D&D and digital titles like Legend of Zelda. It has a very pen and paper, swords and sorcery kind of vibe. However due to a lack of good titles for the Vive I would not be surprised if a lot of people bought the game just for something to try on their VR system, its how I came across it.


Game Design & Mechanics

Vanishing Realms plays like you would expect an old dungeon crawler to play. Explore, collect items and gold, fight monsters, get more weapons and eventually fight a boss. It’s a time old system taken straight from pen and paper of old. However Vanishing Realms changes this forever by putting you into the dungeon using a combination of teleporting and the Vives room scale exploration. You can kneel, lie down, jump and even throw items by simply doing it yourself. I recall a rather tricky wall of traps I had to carefully navigate around on my hands and knees, from an outsiders perspective I must have looked crazy.


There are several logic puzzles to solve in various areas of the game that rely on some of the mechanics already mentioned, there is a fantastic element of personal interaction in the game and thats before I even get to the combat. It takes a little while before the game presents you with an enemy, but once it does you’re confronted with hulking 6-7ft skeletons trying to swing swords and axes at your head in VR. It takes you off your feet a little bit and your very first fight will inevitably contain a degree of flailing. Once you adjust to it all, all movements are tracked. You can block by clashing swords, strike as you please when the opportunity arises, parry with a shield and then strike with your off hand, it is entirely down to you as a player how you choose to fight. The game later introduces a 2 hand weapon mechanic which requires a primary hand that guides the weapon and your second hand simulates holding the weapon at some distance down the shaft which actually determines strike distance. It’s fun and involved and once battles become more intense almost becomes a workout. I’ve smashed several light bulbs in my own living room after losing my sense of presence and getting invested in swinging a weapon or throwing a rock.


The overall visual style for VR is cartoony and simple. Given the short development time it doesn’t surprise me the developer went for a more simple style but also VR demands a lot from your graphics card even if the game looks relatively simple and low poly. So the decision for this was likely two fold to save time and keep the framerate high enough to avoid motion sickness.  The same goes for the texture quality in game, which doesn’t hold up under scrutiny when you consider it’s a modern title. However in no way none of these points are a negative against the gameplay, once invested in playing such things become irrelevant and you stop paying attention.


Otherwise the colour palette is what you’d expect from a medieval fantasy, stone greys, browns, blues and the occasional warm palette for fire lit areas. I’ve heard tales that some of the assets used in game are paid for pre-built assets and while I can’t confirm this one way or the other, it wouldn’t surprise me given the short development time.


VR performance is a mixed bag and usually is down to hardware. I personally ran the game on a modern Skylake i7, 16GB RAM and a GTX 1070 and the game ran flawlessly. However anything less and the game does run into some framerate issues, but this is just the nature of VR in its current state.

I also frequently had issues with dropped items being ever so slightly lower than the floor plane meaning I couldn’t pick them up and more often than not ended up ramming my Vive controller accidently in the floor while trying to do so. This along with a few clipping issues with bad guys were the worst of my problems, so nothing serious that crippled gameplay. I’m hoping in the future VR and the hardware required to even run it will start to drop and allow more widespread use of the technology, I would love to see more games like this as currently its a rare gem among a sea of short ‘experiences’ with little gameplay. I spent so long inside the Vive playing this that I came out with motion sickness for a whole day. Do I regret it? Absolutely not, it was an amazing time!


Analysis of Game Design Pt.2

How available hardware impacted design.
● Intended audiences for the game.
● Critique the game. Talk about game
design, visuals, mechanics & performance.



Available Hardware at the Time


Talking about the Dreamcast and its development could honestly take days. To shorten this I’m going to skip out on most of its earlier (failed) development cycle, all the in-fighting between Sega branches and stick to the final product. In my opinion Sega attempting to make the console four times amounting to a huge amount of wasted R&D money contributes to their financial trouble and eventual downfall in the hardware market. However don’t misinterpret me, I ADORE my Dreamcast.


Sega released the Dreamcast’s predecessor, the Sega Saturn on November 22nd 1994 in Japan and almost immediately began research into their next machine. Admitting right of the door that Sony had bested them at their own game with the launch of the Playstation. While technically the Playstation had less power than the Saturn, it was easier to program for, had more available development tools and Sony had already struck deals with some major developers before launch. The new kid on the block just burst onto the market with an unpredictable force.

The Dreamcast was eventually launched in November 98′ in Japan and was the first of the 128-bit console generation. Hardware wise I won’t get into specifics, but was the first console to use off the shelf parts more similar in nature to those from a personal computer. Games could be written directly for the hardware or using DirectX API libraries as the system also ran an embedded version of Windows CE. This made it easy to port PC games to the platform. Compared to anything before it the DC was a console powerhouse, and would only be rivaled by the soon to be PS2.

However this article is tied to Shenmue specifically and its development life started on the Saturn, pushing the system to its theoretical limits before being told to stop Saturn development but continue the project. This left the team in a multi year window where they didn’t know their target hardware. Yu Suzuki, Shenmue’s creator was quoted as saying he wanted the game to be a console title without limits and personally put down a prediction for the upcoming hardware specifications. While there is no evidence to support this, I wouldn’t be surprised if this flagship title for the system had some influence over the final hardware considering the $70 million dollars they poured into the games development. A monumental sum back in the 90s.

Intended Audience

The age rating for Shenmue at the time was Teen, or in the UK 12+. This was the first time anyone and I mean anyone had attempted such an in depth, open world, story telling experience like this in a game. In an era of beat em ups and arena shooters, it stood alone as a marvel of technology and game design. In my opinion, I take that 12+ literally, regardless of age or gender there was something in Shenmue for everyone. At its core it was a people drama based around discovery and revenge.

There was however concerns that an attempt to re-create a perfect mid 80s Japan wouldn’t resonate with Western audiences and in an attempt to fix this the game needed a full English localisation to ease players into the unfamiliar setting. Due to the size of the game this was an enormous task challenge at the time and famously some of the voice casting decisions were….questionable and dragged down the quality of the localisation.

Game Design & Mechanics

Trying to sum up Shenmue is going to be a challenge. Originally Suzuki wanted the game to be an RPG based on the Virtua Fighter series, with voice acting, elaborate combat sequences and a cinematic approach. The tie in to Virtua Fighter was dropped once development left the Sega Saturn behind but plenty of evidence of it stills exists online.


The final core game has you travelling across a large open environment, full of minigames, subquests and character interaction. Things we take for granted today but monumental in the 90s. The player character could interact with a lot in the environment, cupboards, drawers, fridges, vending machines etc, and hold up objects to the camera to 360 rotate around and look at them. This blew my mind back then. On top of this the game had a fighting, martial arts mechanic which would be required frequently, this is likely still a holdover from when the game was going to be based on Virtua Fighter. The in game weather was even based on meteorological records from the 80s for the exact dates the game is set, Again the attention to detail to craft this game world was insane.

All of these mechanics were used to discover where the murderer of your father has escaped to, in the style of traditional Chinese cinema. I was always fond of the time of day system, all NPCs had a scripted daily routine based on the time, stores opened and closed at their own set hours, sleep was required before a certain time and some dialogue interactions with NPCs were based on time of day meetings. I was always fond of the section where you took up a part time job to look for information and had to drive a fork lift truck during your contracted hours. All of this was such a monumental effort that the development team had to invent a new type of data compression to fit the game on the eventual 4 discs. Without it they estimated it would have taken up to 60 optical discs.

I’ve left it till last but this topic couldn’t end without bringing up the QTE (quick time event), Shenmue gave birth to this idea of quickly reacting to an on screen prompt for a button press during a pre-scripted cutscene/event. While I accept the mechanic in this one game, the idea became a plague that spread to many games over several years, we’ve only recently seen the end of it. The idea was to give you some input on what happens during cutscenes, to feel like you’re still part of the action. However more often than not they just became a frustrating exercise in reaction speed to ever increasingly complex inputs, that required frequent reloads until you memorised the pattern.

All told it isn’t surprising it held the Guiness World Record for most expensive game ever made for quite a number of years. Sadly Sega never made the money back on it and became one of the many reasons for their eventual downfall from the console market.


All the visual influence for Shenmue was based on a mid 1980s image of Japan, specifically the port city of Yokosuka where the US setup their naval base post WWII. Nobody had to come up with an art style, it was all based on real world architecture, fashion, pop culture and overall history of the time period. There isn’t much to be found online about its visual influence probably to it all being real world reference.


The game ran well on the specifications the Dreamcast finalised with, transitioning from game to cutscene in the seamless manner we come to expect today. However performance isn’t always about framerates. Likely due to the compression and the sheer size of the game, load times could be quite lengthy between areas. Never helped by the Dreamcasts famously noisy disk drive.

I should mention the sequel here, some of the development costs for the first game leaked over into the second as they were back to back projects. However the environment detail for Hong Kong in the second game were scaled up significantly and the Dreamcast lost a lot of frames. The sequel was released at the time of the Dreamcast’s demise and in an effort to help sales the game was also ported to the original Xbox where it ran considerably better. The Xbox version is also the only version with an English localisation as it was rushed to shelves for the DC before it died. It’s amazing to think the development spanned the life of two consoles, took both of them to their limits and still required more power. As projects go it was certainly ambitious.



Analysis of Game Design Pt.1

The class has been tasked with picking some famous games, or something you’re familiar with and talking about it from a game design perspective. There is so much scope here so I’m going to keep it to things that have meant a lot to me over the years, hopefully this will keep things interesting for you and me. I may even learn something new! Here are the topics that need to be covered:

How available hardware impacted design.
● Intended audiences for the game.
● Critique the game. Talk about game
design, visuals, mechanics & performance.

So onto the first game!

Sonic the Hedgehog


Available Hardware at the Time


While Sega had some limited success in the 80s with their Sega Master System, it was never able to compete with Nintendo’s NES/Famicom and their almost indomitable market share. In order to compete they pushed the development of their next console and the first entry into the 16-bit console war, the Sega Mega Drive. The MD was built around a Motorola 68000 CPU, which had seen success throughout the 80’s in mass market computers such as early Macintosh machines, Amigas and the Atari ST. The console market was about to meet the power of a PC for the first time. Sega even added a secondary CPU to the system to deal exclusively with audio, leaving less workload for the main Motorola chip.

Even with this new hardware in hand it wasn’t enough to topple Nintendo and Sega realised they were missing one major ingredient in the plan. A mascot to rival Mario himself. A team was assembled to develop a Mario killer game using all of the new found hardware at their fingertips. This was how Sonic the Hedgehog came to be. The game was defined by what functionality they could pull out of the new hardware. Programmer and Project Manager Yuji Naka had always been obsessed with fast cars and speed and wanted to bring this love into the game. So much so, the game speed was eventually dialed back during development as the prototype moved so fast it was giving testers motion sickness. It seems like the new hardware was delivering exactly what they wanted in spades.

Intended Audiences

There was much heated debate between Sega of Japan and Sega US over this very matter, clashing heads over how to appeal to two very different audiences for maximum appeal and profit. Japan originally styled the character in your typical Japanese style of cute features and large expressive eyes but already knew the product had to succeed in Western territories to help sell Mega Drive units. In light of this Sonic was also styled after such classic animation icons as Felix the Cat and Mickey Mouse.


However the initial submission to Sega US caused quite the stir with the then CEO Michael Katz who immediately wrote a list of ten reasons why the IP would never succeed in the west and had it forwarded to Sega Japan. One of these reasons was that nobody in the US even knew what a hedgehog was, turns out they aren’t native to any of the Americas, I learnt something new today.

Sega US went to work redesigning the character to suit a Western audience which in turn infuriated the original Sonic Team in Japan and this continued for some time. Eventually SOA’s design would be the final design based on the facts that the Master System and Mega Drive up until now had better sales than the West than in Japan, where Nintendo still had the major foot hold. Nearly all of the initial Sonic lore was created by Sega of America.

The other aspect to target audience was a split between Japan’s casual gamer market and the Wests more competitive gamer market. Yuji Naka managed to nail down the appeal to both markets by introducing the speed aspect of the game as a skill based test, hoping gamers would return again and again in an attempt to beat the stages as fast as possible with the worlds speediest hedgehog. Meanwhile casual gamers could take a slower approach as the game had no time limit, merely a time counter.

Meanwhile I find it funny that no thought seems to have gone into the age or gender demographic, or at least I can’t seem to find any information about it. I could say that Sega were lucky that the end product was popular with all ages but I’m sure it was considered somewhere during the development process and simply isn’t documented online.

Game Design & Mechanics

All of the staff working on the original game admit that its core influence for gameplay still originated from Mario, but with that added desire of speed I’ve already mentioned. You could boil Sonic’s mechanics to that or Mario in its simplest form, get from point A to point B in a side scrolling platformer. As for the rest of the mechanics I’ll have to quickly jump back to the character design process.


The original character submission long before the blue hedgehog was a rabbit, who would pick things up with his ears and throw them at enemies. This rabbit created by Naoto Oshima didn’t fit Yuji Naka’s vision and said the item pickup process broke the rhythm of the action, along with his goal to make the game playable with only one button. So the team went back to the drawing board to look for animals that could roll into a ball, their idea for an attack. What would Sonic be if they had never nailed down that core rolling attack at this stage, it wouldn’t be the game we know now.

To now elaborate, the core mechanic is get from point A to point B, while avoiding or destroying enemies using a balled up jump or roll attack, but wait theres more. I previously mentioned the desire to appeal to the Western audiences competitive streak, by encouraging what we’d know now as speed running levels. He had always wondered when playing Mario why the levels could not be cleared more quickly, and this was his foundation for that aspect of Sonic. So for the last time get from point A to B as quickly as possible, while avoiding or destroying enemies using the ball up mechanic. For the most part I think that sums up Sonic pretty well.

“I like fast things and I thought that it would be nice to create a game where the more skilled you become, the faster you can complete a stage. Games back then had no backup or saving system, which meant that you had to play right form the beginning every time…As a result, the very first stage would be played time and time again, making the player very skilled at it. So we thought it would be nice if this would enable the player to complete those stages faster and that’s the basis of Sonic’s speed. We also thought this feature would help differentiate Sonic from Mario.”

—Yuji Naka, Programmer and Project Manager of Sonic the Hedgehog.

From a personal perspective all I can say is it worked. I lovingly played Sonic until the days of the PS1 when the Mega Drive took a back shelf, constantly beating my own times and finding new paths to the end of the level. I still have my MD and occasionally run through all of Sonic for the nostalgia, emulation just isn’t the same.


I’ve already talked at some length about the creation of Sonic himself and where the style came from, so I’ll take this opportunity to briefly discuss the levels themselves.

Level designer Hirokazu Yasuhara worked on all the levels single handedly and was responsible for the theme of each. The games colour scheme was influenced by pop artist Eizin Suzuki and the first level Green Hill Zone was designed to bare some resemblance to California in hopes of appealing to the Western market.

An example of pop artist Eizin Suzuki’s style.


There isn’t much official information outside of this, so from here on in this is purely observation and opinion. Each level has its own style and theme, often being worlds apart from each other but each lavishly detailed to the point its insane to comprehend it all being the work of one man.


The high contrast and vivid colours wash out as the game progresses and the zones get more industrial, until your final conflict with the main antagonist Dr.Robotnik, responsible for all the robots in the other zones. Visually its a nice touch and gives a sense of progression as your surrounding visuals get less natural and more grim. Even though ask any player and we all hate level 4 ‘Labyrinth’ more than any later stage, Sonic constantly drowning was the frustration of gamers for a generation.



Sonic had some performance issues during development but the final game ran absolutely flawless. The initial speed Naka wanted out of the game took some clever programming, early tests resulted in flickering, slow frame rates and glitchy sprite animations. This was solved early in development by Naka writing an algorithm to solve these issues, this was also responsible for smoothly allowing the games loop-de-loops and momentum based physics to work. I take my hat off to one programmer making all of this possible in 1989.

That about wraps up talking about Sonic, however I’m not done with Sega by a long shot. More on that shortly!

Global Game Jam 2017

This past weekend was the Global Game Jam 2017 and myself along with any other willing students from the college participated, there ended up being 30 of us total. Throwing away any weekend plans to do what we’re enrolled for, making games! From 5:30pm on Friday night to submission at 3:30pm Sunday, we spent the majority of awake time on campus grounds, grafting away to create something that pushed our current skills as far as they would go in the time allocated.

Thanks go out to my team of Kelly, Daniel Bishop and Adam Lyons for being brilliant team players and giving it their all, it was a brilliant weekend and I’m thrilled we managed to have an end result.


After classes I stuck around waiting for the keynotes to be delivered in the lecture theatre at 5:30pm. We sat through some sound advice from one of their sponsors ‘Extra Credits’ about distilling your idea down to its most basic element and focusing on that, something I learnt the hard way over my mock Christmas jam which barely managed an end product. Kelly made our motto for the weekend ‘minimum viable product’, to produce a single mechanic that worked and looked great.

*drum roll please*

The keynotes finished up and the theme for this year was:


*The panic sets in*

We were all a little lost for ideas at first, thinking that the theme was rather specific. However after ten minutes or so we started realising that there was a lot of scope outside of thinking the sea/ocean. Hands waving, sound waves, waves of enemies etc. Pairing up with my team we found a sofa and began brain storming, ending with three ideas we could go with. A surfer trying to keep his balance on waves, controlling light trying to reach a destination and using a sonar mechanic to try and navigate a dark environment. We all decided to try our hand at the sonar idea and fleshed it out into navigating a bat through a dark cave system while avoiding obstacles using its sonar. We weren’t too sure how to visually represent this with the skills we have to settled on using an animated spot light cone.

In an attempt to minimise the amount of assets needed we opted to create an endless runner and have a small selection of obstacles randomly generate. Controls would be a simple up, down and a button/key to send out your sonar.

All that was left for the first night with allocating roles/jobs. I already had a few ideas on how to quickly make the environment so I took up the job of making the cave system itself, Kelly took the role of programmer, Adam was going to focus on making the player character and the sprite sheets for it and Daniel would focus on creating the games pickups.

We packed up and headed home. I was determined to nail down a simple art style on the first night, I wanted both of the other artists to be able to pick it up and run with it if we needed extra hands to help with the environment. I love Animate for its ability to generate vector art very quickly and decided to use it for testing and to keep clean looking graphics that could be resized if required. I removed the stroke from everything and decided to build all assets using nothing but shapes and a palette of three colours. One primary and two shadow shades.

By midnight I presented this to the team online and was given a thumbs up to start using it in the morning. I should have called it a night there but instead I refined the idea and by 2am I had a full background and foreground to be scrolled at different speeds. They just required some refinement in the morning to tile correctly.



I arrived on campus and immediately began trying to cleanly tile my backgrounds. After an hour and a half of tweaking, testing, tweaking, testing I handed them over to Kelly to implement into the build. It’s amazing though, I set up all the background layers in Animate with exactly the same pixel dimensions and yet the end result didn’t tile perfectly, so all tweaking was done in Photoshop on a super high resolution version of the file.



Next I set about using exactly the same style to create obstacles. These boiled down to two types, rock formations and crystal formations. I created four of each giving us eight bits of terrain that could be randomly generated. These were all flipped vertically to give ground and ceiling obstacles.

This slideshow requires JavaScript.

At this point it was about 3pm, Dan had left to deal with family obligations and Adam was at a gym session, I didn’t have access to either of their work to continue it and had to take a moment to decide where to focus my time. Unless Kelly shouted that we needed more variation in the terrain the environment was complete.

While it could be seen as non essential artwork (especially for a jam) I set about making menu screens for the end product, along with navigation buttons using the existing style. I wanted a persistent background for all menus and had considered taking a screen capture of the current build, however I didn’t want to pester our coder over something so trivial at this stage so mocked one up using all the assets at hand.


I darkened this down using a layer over the top, stared at it for a moment and thought ‘damn I can’t install fonts on the college computers’. I really wanted to get something a bit wacky to use as a title font to give the whole thing a playful vibe, THANKFULLY I brought my own little ‘Road Warrior’ an old Lenovo ThinkPad. I jumped between the two machines, bringing rasterised text back and forth until I got something I liked the look of. Yes the font is bat related.


Some quick compositing and a few circles later I was staring at this:


It needed the bat to fill in the left third of the screen and some navigation controls. Since Adam was still away I focused on the buttons. This boiled down to another colour re-skin of a single crystal, up-scaling it and playing with fonts on my laptop again. Here are all the buttons. Also pizza arrived, so work stopped while 30 students descended on 10 pizzas like a horde of angry piranha.

Adam had returned and was finishing up the bat so I made a few alterations to the title screen to give us a blank canvas to be used for credits, how to play and game over. Off to play with more fonts for the game over screen.


YES! The bat was complete and looked amazing. I asked for one particular frame of the animation and used that to complete the title screen. I took a break, my eyes were starting to burn out for the day. There wasn’t a lot of time left, I made a few colour tweaks here and there and tried to make a game plan for tomorrow. Mostly sourcing sound effects to add some polish to the end product. I got home with good intentions of hunting for sounds that night but decided sleep was more important.




A bright an early rise to go digging through the depths of the internet to find some suitable sounds. More specifically and I had a list of things I wanted to find:

  • A bat screech
  • Sonar ping
  • Item pickup noise
  • Button hover
  • Button press
  • Wing flap
  • Menu music
  • Main game music

With the two resource sites mentioned above I found everything I needed after a lengthy time digging. Gathering the rest of the team, we picked through everything and decided which sfx we wanted to use. These were handed over to Kelly to add into the build.

From this point on I mostly floated about trying to help the rest of the team, play testing to find issues and making odd tweaks to certain graphics at the request of Kelly. Adam had spent the whole day working on a death animation for the bat and at the very last minute it turns out we couldn’t use videos in Unity without having quick time installed, we need to rebuild on another machine and add this in future. We were all gutted we couldn’t use it. The team submitted at 3:30 to GGJ, put our feet up and took a look at what the rest of the teams had come up with over the weekend.

Proof we submitted!


Here is the link, files are hosted from my own Dropbox.

Sonar Slalom – Dropbox

Here is the link direct from GGJ as a backup: GGJ 2017 – Sonar Slalom

The game can be downloaded straight from GGJ, downloaded both data and exe files and put them in the same folder.

Brilliant experience and I’m thrilled we had such a polished looking end result. Kelly is already fixing some collider issues for future versions and we still have ideas we’d like to implement. Bring on the next jam!


Personal Game Jam Weekend – Day 3

Sunday morning dawns and the artists rise to contemplate whats left they can help with. The decision was made to create a title screen for the game. While the purpose of the lab was never determined, and in our own minds the lower levels of said lab spiraled into all kinds of dark illegal experiments, we took the simple approach of cosmetics testing.

Using this we remembered an ad campaign many years ago of an actual rabbit photo-shopped with heavy makeup, in an effort to deter such activities. Taking some inspiration from this we wanted to make something similar as a title screen.


The end result was a very odd blend of blatent cartoon and real, however on reflection I actually took the same approach with some of the lab assets. I’m sure somewhere in the back of my sleep deprived and cold brain I made this connection and ran with it.

While I was tidying up and making edits to some of the level assets at request of the coders, Dean drew the rabbit and made the background. Later I jumped in to vector trace his hand drawing, colour the bunny and find a suitable font.

This slideshow requires JavaScript.

This was all then handed to Kelly who added the navigation buttons in Unity and added it to the scene manager.

That was pretty much it for the artist contributions to the project, so here is the first level in action.

As I’ve already mentioned we only achieved a single level in the time doing the jam, we had even intended to add instructions or some kind of plot introduction to inform the player of controls and what to do, but ran out of time. I’d say we achieved a bare bones skeleton of an end product and for a first jam with three other people that had never touched a game engine, I’m still happy there is even an end result to demonstrate. For the inexperienced its an amazingly short amount of time!

On reflection I’m pleased I organised this and gave it a go, it’ll be good experience for when we participate in the Global Game Jam in January with the college. I know Kelly had some issues getting her points across and arguing features/methods with the other coders, in comparison I had an easy ride drawing tiles with a guy I’ve known over half my life. Despite this it does make me appreciate that the social aspect of creative development can have its own challenges, although that holds for most industries. IT can get pretty heated between service staff!

I’d like to revisit this with Kelly in future once we’ve developed our skills further, maybe refine the control system, add more content and attempt to simplify some of the code. For now I’m about to prepare for the festive family barrage that is Christmas. Happy Christmas everyone and I’ll start updating again in the new year!

Personal Game Jam Weekend – Day 2

Day two arrives. The priority was to achieve as much of the minimum requirements as possible in the hope we could add a bit of spit and polish to them during the final day or maybe even an extra feature.

Then came the issue none of us had thought about, organisation. Sharing of assets, version control etc. While not ideal everyone ended up working from my dropbox, the coders sharing one main build while using another two PCs to test new code before writing it to our main file.

While it doesn’t all apply to me I’m going to quote from Kelly’s post.

“Since none of us had done game jams before or built an entire game from scratch, there was quite a massive learning curve. In my personal opinion, it was also difficult working with such a variety of people with multiple skill sets, each at their own level of ability. This made me feel a little sub-par. I think it was also an overall difficult endeavour since it was taking place at our house, which meant there was no real downtime in between the game development. Sometimes people were staying up all night working on something, while others tried to sleep, which meant not everyone was involved in the activity at all times and there was some catching up. I think, in a professional or school environment, this might be a lot easier.”

While I wasn’t feeling sub-par to anyone (granted I wasn’t coding) it was exhausting having no real down time or way to escape from it in my own home. The other major issue was that our central heating had died three days prior and the house was freezing all weekend. Thankfully everyone still agreed to do it despite this set back.

So moaning aside I sat down to start creating assets. As the grid based movement/level had been decided on we settled on all assets being 512×512 and would be scaled down in engine as needed. Keeping an animal testing lab theme in mind Dean and I put our heads down.

Here is the sheet I kept adding new assets to, to make sure they all worked with each other (was just a PSD I kept open to play with assets/tilings). Oh I forgot to mention, we used a combination of Photoshop and Animate for all assets.

animallabNot all of these were made on the first day, however the majority were. Since I’m backdating this, I’ll add all of the game assets to day 2 and leave tomorrow to talk about tidying up loose ends and the splash screen. Here is a slideshow of every asset we created, used and unused.

This slideshow requires JavaScript.

We created multiple types of lab assistant, multiple recolours of animals, crates, lab equipment, computers, desks, shelves etc, in an effort to piece together a tile set that could be reused across all the levels. While we did set out on the morning with a plan of the basics (floors, walls, an assistant, an animal, one obstacle and a start and finish marker), this quickly escalated into creating further assets due to finishing promptly.

Since we reached a point where both artists were sitting on their hands at the very end of day two, we drafted out a couple of extra plans for levels two and three. Sadly we never got to these, but here is the planning in action.



Personal Game Jam Weekend – Day 1

To add something relevant over the holidays Kelly and I organised our own personal little game jam challenge with a few friends of ours with skills to contribute. One is a computer programming graduate (Alison), another is a Java developer (Ray) and lastly is our second artist (Dean), who did the same Uni course as me 12 years ago. While the majority of the group had no experience with Unity we thought it would be a laugh to see how far we could get in two days.

We had considered picking a theme ahead of time but then worried people may start sneaking in work before we began. To keep it random we asked Ray’s other half to text us a random theme at 6pm on the Friday, this came through as “rescue the animals from the lab”, which was a little bit specific for a jam but it didn’t matter. Time to get to work.

We had bought a flip chart and stand for the occasion and spent the first night sitting around throwing ideas at it and trying to make a plan of action for the morning.


Before the group even got to whats above we had to figure out some core mechanics:

  1. What style of game would work?
  2. What would be plausible within the time frame given lack of experience?
  3. Since the theme was rather specific, what goals would the player have to achieve to save the animals, i.e what is your win condition?
  4. 2D or 3D?

After much debate and several cups of coffee, we settled on sticking with 2D and making a top down stealth game. The notes above in the photo were other gameplay suggestions we considered before stealth. Each level would be a different animal trying to escape on its own through a level, while trying to avoid obstacles and staff, also toying with the idea of each species having its own unique ability which may help it in certain situations. A mouse has less visibility, a cat could see in the dark etc. Jokingly Dean suggested a bear (who tests on a BEAR) could steal a staff uniform and walk out, we had a chuckle and continued the joke for two days.


Using a top down perspective we could keep the controls relatively simple, it kept art asset creation simple and the most difficult part seemed to be the coders figuring out how to make a line of sight for the enemy/staff sprites. So in theory, it all seemed plausible.


When moving the player/animal sprite if you crossed the line of sight (we wrote FOV in the notes above) of the enemy sprite you would lose a life, or the level would reset. Whatever we had time for. We covered some other ideas for obstacles/game progression on this page.

Slippery floors – the animal won’t be able to stop and will continue moving in the direction they were travelling in when they walked over the wet floor.

Sticky floors – this lowers the speed the animals can move at, which might put them at greater risk of being discovered.

Multiple Lab assistants – there could be one or more assistants on patrol through the lab levels, on the look out for anything strange going on.

Security cameras – could act in the same way as the assistants, with a specified field of view that the critters have to avoid passing through.

We started coming up with ideas that were well beyond our time frame and ability, ideally we should have stopped there to save some time but in the moment it seemed like a good idea to flesh it out as much as possible. We considered some of the animal abilities being able to cause distractions and alter the enemy/staff patrol routes and to accomodate Dean’s joke bear we added a bit of silliness, where further levels would delve you deeper into the lab to find all kinds of weird animals or science experiments that were trying to escape.


Figuring out the timing and controls took a bit of debate, the group eventually decided on a grid based movement system to easily lock all the player and enemy sprites onto a certain path. The coders believed it would be easier to add in line of sight this way and despite I argued for a more direct input control (because its what I’ve done in Unity so far and inbuilt) I was over-ruled.

Another few ideas were thrown around regarding gameplay, such as animals having to free other animals along the way and making a snake like chain (making it harder to avoid enemy sprites) and needing to rescue so many of a single type of animal to unlock their use for later stages.


So a few hours passed and we drew up a plan and a list of priorities. From this we created a list of minimum requirements to make this a game:

  • P1a: Player models and basic movement
  • P1b: A first level designed and ready to utilise
  • P2a: Basic game assets, which would include but not be limited to pawns (animals, lab assistants, etc), background (going with a top-down view), and obstacles (crates, desks, general level dressing)
  • P2b: A spawn point, exit point, and any objectives we wanted to include throughout the level
  • P3a: Basic enemy movement (either lab assistants, guards, or cameras)
  • P3b: Field of view detection
  • P4a: In-game menus and transitions
  • P4b: Interface/HUD or any game information the player might need

End of night one and everything seemed to fit together along with seeming plausible within the time frame. The team divided into Kelly, Ray and Alison coding, myself and Dean making the art assets. I’ll write up day two soon and also give a link to Kellys blog to see her side on code (as she has already posted everything) in contrast to my side on art.

Kelly – Logan House Game Jam Day 1


Unity 2D – Spaceship Camera Follow

I’ve been waiting for camera follow for weeks, I know I could have googled it but there were other priorities and hand ins going on. With this I can finally expand the size of the levels. However once I saw how small the code was I felt stupid and should have googled it after all, or just had a stab at doing it myself.


Yup thats it. The one feature I’ve been waiting for, is simply one variable and one function, simple! We keep the camera position updated every frame to match the position of the ship and maintain its Z distance away from it, great bit of script to keep around and remember, would be really useful for platformers as well.

Now I had to flesh out a level. Before I had some terrain with collisions above and below, with a collectable star that required picking up before the player could exit the level, however the sides were open and you could float out into space and never return. That idea needed to be created on a larger scale to accomadate for player movement and for the environment to barricade the player into the level. I present to you, the end result.


Okay changes made are:

  • Fully contained level (more assets from
  • Multiple star pickups before level can be exited
  • Additional asteroid obstacles
  • A scrolling background of stars (this slowly moves even if the player is stationary)
  • Coloured the goal to make it more unique (still needs to not be an asteroid in the future)
  • Spaceship now had a thruster animation using a particle emitter

The extra landscape was all drag and drop in, change the size and add colliders so nothing new to report on. The additional asteroids are prefab clones of the original, with direction, speed and rotation altered for variation and the goal asteroid was tinted in Unity. That covers all of the simple changes.

I’ve never had a background on my scene this entire time, mainly because I wasn’t sure what would happen once we added a camera tracker or what kind of scene I’d end up with. Maybe the exercise could have ended up as a long side scroller like R-Type or Gradius. I turn to Kelly (the wife) who is sitting there with a textured rotating carousel behind the scene and remember why I’m the artist and shes the technical one. Naturally I coaxed her into going through the creation of one step by step.


Its kind of beautifully simple when you break it down. It is literally a textured cylinder with a modified version of our rotation script to add the other axis. Which spins around forever in the back of the scene.


All axis were thrown in there as a public float, so this now could be used for almost anything that needs to spin in any direction. Wish I’d thought of it!

As for my multiple star pickups. I’d placed all the stars, they all had the pickup tag from the last exercise and I tested multiple times to see if I could collect them all within the time limit. I ask another student to test it, they pickup one star, hit the goal and level complete. Brilliant planning on my part, just missing the code to make it work. Another student had worked out a way to auto complete the level on the pickup of all stars however I wanted all pickups and a goal location. From a combination of their code, the old roller ball tutorial, some banging my head off the desk and finally help from Kelly and Ant, this was produced.


Now all the star pickups are placed into a list, once entries in the list are below one and the goal is collided with, the player teleports to next level. Brilliant, feature implemented!

There was still time left in the lesson so I jumped onto moodle and dug through some of Ants previous video tutorials. I had seen a ship thruster video a few weeks back and decided to try and implement it. There wasn’t much to it outside of tweaking a few settings and parenting it to the ship. Towards the end of the video it covers turning off the emitter when the ship is stationary, I didn’t make it to this section so for now our little spaceship is burning a lot of fuel!


Sadly this is it for class time on the 2D Spaceship project. Its now almost Xmas, assessments due next week and then programming gets math heavy come new year (trying to scare us all over the holidays). I’ll have to add a few more levels to this in my spare time otherwise I’ll never get piece of mind that I finished!