Art Blog 04 – Animation Rants

Hey Ho everyone

It’s the Judy’s blog time again which means lots of ranting. So feel free now to close this tab on your browser.

For starters it’s December which means CHRISTMAS IS COMING! Hooray for the festivities! We’re so festive right now here at Junkfish, we’re talking about the suicide rate during this time of year. 

Even Peter is in the festive spirit.


Usually he only does this at night.

It also means the first crunch period to get everything ready to a certain level before holiday time.
So yet again I’m not allowed to show you any awesome animations of the monster due to SECRECY AT JUNKFISH but instead I thought I’d talk about some tips I follow to create ‘weight’ in animation.

Weight is quite an important factor in the animation. There are two principles that can greatly help in creating a ‘light’ or ‘heavy’ body mass of a character. These are ‘Timing’ and ‘Follow Through’.

Timing can greatly help in showing the weight of the character and there are two basic strategies which apply with timing and the weight of the character. The heavier and larger the character is the slower it moves. By having this slow movement it gives a sense of the effort needed to move the heavy mass. The smaller and lighter a character, the quicker it moves. Because the character is lighter, it is able to move at a faster speed due to not being weighed down. Of course these tips can be altered depending on the character design and style of animation being used.

Another principle which helps me to create weight is ‘Follow through’. This means the movement which comes after a character has performed an action. An example of this is a character hitting a ball with a bat.

…not that follow through you horrible lot.

Follow through is when the bat continues to move after the action of the bat hitting the ball has been performed.

The heavier an object is the longer the follow though will continue. The lighter the object is, the faster the follow through will be.

A good book I read to help me gain a better understanding of weight and timing in animation is ‘Timing for Animation’ by John Halas and Harold Whitaker. They give a good in depth explanation of these principles.

I hope these rambles helped or at least mildly entertained you for a brief moment.

Have a lovely christmas!


Programming Blog 03 – Proceduro the Magnifico


Hello, hello, hello Junkfish minions! Peter has so kindly risen from the depths of generation, once again, to impart blissful knowledge upon yourselves. I believe I ended my last blog detailing that I would discuss some of the details relative to the procedural generation, and its associated tools, so I guess that shall be the topic of one-way conversation this time.


Before man could cut meat, he needed tools. Similarly, before I generated a room, I needed a tool to tell it where, why, and how. And thus, the Room interface was birthed! The Room interface is a script that should be slapped on to an empty GameObject in Unity, and holds a medley of 7 sub-headings, each of which allow different aspects of the room to be specified. The first sub-heading, “Room Settings”, allows the spawn amount of this room to be set, and what kind of room it should be, e.g. a corridor, a standard room, outside piece, etc.


Behold, the room interface!Behold, minions, the Room interface!


Sub-heading #2, “Room Models”, does exactly what it says in the title – allows the editor to choose the models that will be associated with this room. Probabilities of the models can be set, and different textures can be passed in to help prevent two rooms looking the same.

Like #2, the third sub-heading – titled “Room Objects (Not Random)” – is how the editor can define where very specific objects will go in a room. For example, I used this to place beds in one of the crew bunks instead of leaving their placement to chance.

The “Themes” sub-heading is one of the two sub-headings that are crucial to room spawning. Themes are intended to allow artistic changes to rooms based on their location, and also contribute to where a room is placed. If we were making a hospital, and the room was going to be in the ward, Themes could be ‘Dirty Ward’, ‘Clean Ward’, or ‘Closed-off Ward’, for example. Same rooms, different looks.

The next sub-heading ties into Themes very heavily – “Regions (Tilesets)”. In the hospital example, the Region would be the ‘ward'; where the hospital has many different areas that rooms could spawn in, but these particular rooms can only spawn in areas marked as ‘ward’. This, along with Themes, combine to provide some structure to the desired chaos as we cannot have rooms appearing willy-nilly all over the ship. It just wouldn’t make sense. Not at all.


“Door Data” doesn’t really let the user change anything, but serves as a point of reference for one of the other tools; a separate tool is used to place where doors should go in a room and this sub-heading allows the editor to view some information regarding these door placements, such as (X, Y) position and the orientation.


Aaaand on to the final sub-heading, “Debug Settings”. This one contains a third set of fairly important variables – the size of grid that the room models will fit in. This is used to place the room in the scene, stop it from intersecting with other rooms, and align all rooms up correctly. So it’s pretty important that this is set to the correct dimensions. It also lets the editor turn the visualization of these lines on or off, which is pretty cool too.


All of these contribute in their own ways to make rooms and help position them in a generated level, but this is just one of several necessary facets when it comes to crafting a room with the love and care that we, at Junkfish, so heavily emphasize. That being said, I’ll go on to talk about these others tools at a later date, and you have my word that the least interesting of these tools has now been glossed over. Even if it is the most crucial of the 4.


I’ll leave you lovely people with a cool screenshot of a procedurally generated level, covered in colourful lines and circles:


Coloured lines and coder feedback!

All of those green lines are bits of rooms; code art!


So until next time, minions, same brown hair, same Junkfish blog. Good day everyone, thank you for reading! Your host for the evening,


Art Blog 03 – Post processing


Ahoy! Adam here. 
It’s December already?

Just another little update on the art side of things. As the art team is busy working on some modelling and animation, I have been working on more environmental models. It’s not all that exciting showing you untextured models floating around in Maya so I’ll show you some cool image effects instead.

I came across Unity Pro’s post processing effects whilst attempting to experiment with different shaders. I decided to throw a few of these on the player camera to make things look a little more impressive.

I added some subtle effects like screen space ambient occlusion, some motion blur, colour correction and a little global fog.

Then added some bloom, lens flare and glow effect, though these were not very visible without objects with an intensive light source shining on them.

Here is how it turned out…

Still needs a lot of adjusting, but it already looks better. 

I then threw all sense of subtlety out the window!

Hooray for Fisheye!
I was now the Hal 9000 computer from 2001 : A Space Odyssey

Apart from that, I’m looking forward to getting some proper lighting in the actual procedural build as it’s filled with a whole load of low intensity environmental lights at the moment. We will also be seeing the room shells of the ship exterior and bridge soon.


Holidays are coming, and I’m looking forward to spending them in Bali with the family. :)




Design Blog 03 – Tabletop Maize

Hello again,

Today I’m going to continue with the design stuff and talk about a pretty cool step in the design process. It’s a good idea before you start into the long period of building your game to try and find out if it’s actually any fun to play. But how can you find out what your video game will be like before you make it? Well, you can’t. But what you can do is make it in a different form. A form that is incredibly cheap and can be made in a day – a board game! In addition to being cheap and quick to make, once you have a board game version of your game if you want to test out a new item or mechanic you can, with pen and paper, test it out with this version instead of spending time and resources adding it into the game with no idea of how well it will fit.

And so that is what we did. Before we started working on the project as it is now, we made a Maize board game. This was an incredibly fun task as a favourite pastime amongst the team is board game nights. The rules of the game have changed several times, due to it being too easy, or bordering on impossible. It’s all about finding the balance of difficulty and fun. They are likely to change again, but here are some of the features of the game as they stand now.

The Board

The first step was to find the main mechanics of the game and think of a way to represent them in a board game format. For the procedurally generated layout, I looked to games like Zombies and Carcassonne, which instead of having a set board, build up the play area from decks of tiles, shuffed each time so the map is always different. So Simon and I sat down with some paper and pencils and spent an inordinate amount of time cutting out paper tiles and drawing ruled (well, ruled at first, eventually we got lazy) squares and little details on them.

Getting ready to begin, before we developed our thousand yard stares.

                                                              It Begins

The board is built up from two decks of tiles; one for corridors and the other for rooms. Each tile has nine squares on it. The player character (pictured below) occupies one of these squares at a time.

A fine example of my drawing skills

                                         A fine example of my drawing skills.

The player has a viewing distance of one tile and tiles are placed as the game goes on based on visibility, e.g as the player can see them. For example in the picture below, the end pieces are placed as the player has a line of sight to them but as he is not in the centre no piece has been added to the right as he cannot see it.



 As the game goes on the board gradually becomes a sprawling maze.

Not exactly sprawling....yet.

                                                 Not exactly sprawling….yet. 

The Player

Deciding how the game would actually be played was tricky, as our game is a real time first person game, and real time board games are rare to the point of being almost non existent. Some way was needed to represent the time the player would spend moving about and exploring the ship and also the random element of them messing up (e.g running into a wall, deciding which route to take, getting stuck or lost). The system that ended up being used for this was an action point system (Taken from the wonderful XCOM/Fallout games). At the start of each player turn the player rolls a d6 (that’s just a six sided die for all you non tabletop gamers out there), and the result of this roll determines their action points for this turn. These points can be spent on movement, picking up items, opening/closing/locking doors, etc. and are really just a representation of the time spent doing these things in the video game. The player’s turn ends either when they decide to end it or they have run out of action points.

The Monster

The monster (pictured below) is not initially on the board, and is instead represented by an alertness meter. This increases as the game goes on, mainly from event cards (explained further down), a few other things and represents the time during the game when the player is not being chased by the monster but gradually increasing its awareness of them. While the alertness meter is below 10 the player just takes consecutive turns, but when it reaches 10 the monster is placed on the board a set distance from the player and the chase begins.

Really pushed myself artistically for this.

                                        Really pushed myself artistically for this.

At this point the player and the monster alternate turns, and the monster on its turn rolls a d4 (four sided die, in case you didn’t figure it out yourself) and its action points are decided. Unlike the player however the monster spends all its points on movement and moves towards the player using the smallest number of squares available. The player can use this behaviour to help them escape, for example it takes the monster several points to break down a locked door, so it might not be the fastest route to the player, but because a door only takes up one square it will be the shortest route, and so that’s the one the monster will take. If the monster catches up to the player it’s game over, and if the player successfully hides from the monster it is removed from the board and the alertness meter is reset to 0.

While technically one player could play both roles, in the game the player will not be directly aware of how their actions are affecting the monster’s awareness of them, and so we like to have someone else play the monster, and keep the alert meter hidden from the player. This adds the element of mystery and tension that would be otherwise be missing from this version of the game.

Items and Events

In addition to the tile decks there are two decks of cards, Events and Room Cards.


Event cards are drawn at the end of the player’s turn. These are almost universally negative and represent the more random ‘things can go wrong at any time’ aspect of the game. The concept of these are based on similar features of two of my favourite board games of all time: Red November and Pandemic, brutally difficult, tense, and sometimes hilarious games. The in-game events represented by these cards are things like the player accidentally setting off an alarm, getting stuck in the floor or turning the corner and walking right into the monsters field of view. They also are mainly responsibly for incrementing the alertness counter. (In our two-player method of playing the game the monster player always draws these cards, keeping their effects hidden from the player). If the player has spent more than half (rounded up) of their action points on a particular turn, this is the equivalent of them taking a lot of action in a short amount of time in the video game, and in this case 2 event cards are drawn, otherwise only one is drawn.

Room Cards

Room cards are, as the name suggests cards associated with rooms in the game. When a room tile is placed down, two room cards are placed down with it. On these cards there will be one of three things:

       – Item Cards

       These cards are, well, items. They can be carried about by the player and activated at any time for an advantageous effect. Alternatively they could be one of the valuable key items the retrieval of which are the goal of the game.

       – Opportunities

       These are best thought of as positive events. They are not picked up by the player, but stay in the room in which they were found and can be activated by the player when they’re in the room. For example, an in-game equivalent would be a TV. Not something you’d carry around with you, but you could turn it on and leave it on as a distraction for the monster, buying you time. You would of course have to be in the room at the time to set it up though.

       – Hiding Spots:

       Hiding spots are a valuable resource in the game as they are the only way to be rid of the monster once it’s on the board. Much like opportunities they stay in the room in which they were found. When the player activates a hiding place card (which they must be in the room to do) their turn ends, the appropriate number of event cards are drawn and the monster gets a chance to move closer. On their next turn the player rolls a d6. A six is needed for a successful hide, but this roll can be modified. For example if the monster is 7-8 squares away from the player they will have a plus 3 to their roll, while if the monster is only 1 or 2 squares away from the player they will need to roll a natural six.

Hiding spot card in a room.

                                                    Hiding spot card in a room.

Wow that was a long blog, thanks if you read all of it but if not I won’t hold it against you, I did get a little carried away. Anyway all this talk about the game makes me want to go play it, so I’ll see you later.

Aww Sh*t.


Stay Frosty,


Audio Blog 01 – Monster Roar Sound Design


Jaime here, and today I’m going to talk about the sound design process for lil’ Sparky’s roars, grunts and general vocal noises. If you’ve not seen him before, Sparky’s our test monster that’ll not be in the game. But we love him all the same.


Sound design, especially for vocal work, requires a few things. First is a decent recording space and set up, and not a jury rigged vocalbooth made out of duvets, chairs, clotheshorses and various other sound absorbing things…

The other is the ability to record yourself being a bit of an idiot and not getting all strung up and panicked about it, which sounds easier than it actually is. Recording sounds is a bit like a performance, you have to think “what do I want this to sound like?” before even going in front of the mic and then try and hit that, or something that you can then manipulate into the final article.

Case in point, here’s the “spotted” roar as it was recorded:

It’s…. something. Usable eventually. The next stage was pitch shifting, lowering it down so that it resembled something a bit more monstrous.

The Holy Grail of sound design: transpose pitch

Generally speaking when I record something I usually mess around with the pitch just to see what else I can get out of it, even if I’ve already got the result I wanted from it. I recorded some debris sounds, grains being dropped and swirled around a metal container. I didn’t really get anything usable out of it, so dropped the pitch down 36 semitones and tried that instead. Here’s a before and after for you:

It went from being something admittedly crap to a fairly usable atmosphere. So even if you’ve got something that you might consider a mistake or useless always take a quick 5 minutes to mess around with it! Anyway…

The next step with the roars was breaking it down into 3 components: the main “body” of the sound, the lows and the highs. This is pretty easy, just duplicate the track 2 times then use EQ to filter out the ranges.

Top to bottom: The three tracks, the low roar EQ, the high roar EQ

The main reason for this is to allow me to fine tune the different elements of the sound. There are psychoacoustic properties in low frequency sounds that trigger a fear response in humans, so as I was working on a monster for a horror game it made sense to separate it out. The highs were also separated out so I could fine tune the air and breathing noise, especially in quieter grunts. Here’s an example of each element with the roar, then all those layers combined:

Now for the effects chains. They’re mostly similar, but I’ll highlight a few differences in each beyond the EQ.

Post EQ it goes: Vocoder > Saturator > Chorus > Compressor

First thing there is the vocoder. In Ableton you can set the carrier wave to be another audio file, such as lion roars or whatever you fancy. After some experimenting with those I decided to use the vocoder to add a bit of grainy-ness to the sound, so used white noise as the carrier wave and kept it fairly low in the mix. It also sucked a bit of air out of the sound, giving the other layers a bit more presence. Here’s a before and after:

Next on the list is the saturator. It might seem a little counter intuitive to have something boosting the high end on this track, but it brings out the vocoder a bit more without messing around with EQ. A little lazy but it works, and again it’s blended in a subtly.

Next is the chorus and compressor. The chorus is simply to make the roar a bit bigger, fattening it up to match the size of the monster, and the compressor is set to have a fairly fast attack and longer release. This is based off a recommendation I was given when dealing with dialogue, as it allows it to pop in quickly but decay fairly naturally. Here’s the whole of the main roar:

Next is the low roar element.

EQ > Saturator > Chorus > Multiband Compressor

The saturator and chorus were used for a similar reason to those mentioned above, but the multiband compressor is probably standing out as the odd thing here. If you’ve used them before you’ll probably be wondering “But you’re only using low frequencies, why use a multiband?”. Well, despite the harsh EQ there the sound still stretches beyond the 1kHz range, and I was happy with the way the EQ was set up. a normal compressor would affect everything in the sound, but a multiband lets me compress different frequency ranges (or bands, hence the name). The result is a bit of a boost to the low end, while everything else is kept balanced. Here’s a before and after:

Finally there’s the high end element. There’s nothing too new going on in here, although the compressor has a shorter release compared to the main body.

EQ > Saturator > Chorus > Compressor

And here’s how it sounds.

Now we can stick them together and…

It’s not bad! But missing a little something. I also added a few pitched down animal roars (leopards in this roar only, and elephants on all of them) fairly low in the mix. Here’s how each sounds, and then under the roar itself.

A bit better, but still doesn’t sound quite right. The sounds need a bit of space. While most game engines will have audio reverb zones in them, I still think that it’s important to use them as part of the sound design process as well. Not every reverb has to be a cathedral!

I used a spring reverb via Ableton’s convolution plugin, partly as I like the way spring reverbs sound. It’s a subtle thing but I just think they add a little bit more interest, so no real rhyme or reason! Here’s the before and after:

The next send is a little more interesting…

Ring Modulator > Chorus > Reverb

Ring modulators are…  strange. It would take me an age to explain them so go to Wikipedia and read up on it (Wikipedia). They can sound really nice when tuned properly, or absolutely nasty when the frequencies used are out of sync. If you ever get the chance to mess around with them, especially on a synth (Korg’s MS-20’s ring mod is gorgeous) then do so! The chorus and reverb are there to fatten out the sound a bit more. But rather than prattle on this is probably best left to your ears to judge:

Last but not least, mastering:

EQ > Limiter

This is a pretty basic chain, with a little corrective EQ going into a limiter. Sometimes I stick a multiband compressor here, but it seemed fairly pointless in this instance given how I’d broken down and mixed the sound. Here’s the final result:

Tadah! That’s a a monster for sure. Not bad considering it started life as a guy roaring into a mic surrounded by blankets, eh?

Of course, context is everything. So imagine stumbling on this dark, dilapidated ship like this:

Only to hear Sparky spotting you from behind. Fun times.

That was a bit long, so hopefully it was worth it! If anyone wants to ask anything the drop a comment or give me a shout on Twitter on either @teamjunkfish or @speedyjx :). Here’s a playlist of the sounds too so you don’t need to scroll though the page.

Over and out!


Misc. Blog 03 – Oculus Rift Testing

Hi everyone!






Right, now that I have your attention, allow me to introduce myself. I’m Andrew, the lead programmer for our upcoming game. I’ve mostly worked on subsystems so far, such as audio and AI backends for the other programmers to use. And whilst I find that aspect of game development generally interesting and rewarding, I expect most of you will not. Well, some of you might, but that’s for another blog for another time. So, no programming blogs for now. Instead, after reading other Andy’s captivating product review yesterday, I thought I’d integrate the Oculus Rift SDK with our current build and have a little test:



This video is Oculus Rift compatible; if you have one, fullscreen the video and watch in 3D! Currently, our focus is on making a good PC game, not an Oculus Rift game. However, we’re keeping an eye on it and may support it in the future!


Misc. Post 02 – Introducing Andy…

(The following blog is based on a real life story. No names have been changed to protect the innocent. Reader discretion is advised.)

Hey kids!

I’m Andy, one of the artists working here at Junkfish! Would you like some insight as to what I do here? Maybe you want to see my process for making things? Maybe you want to see me review a product? Maybe you just want to see how I annoy Judy!

Oh the potential! If you want, you folks can let me know (for my next blog) what you want me to talk about through a comment, or whatever… if you like.

For now I’ll just graze over a few topics in general.

The past few weeks have been rather interesting for me, as I have been responsible for taking the monster from its 2D concept and turning it into a textured 3D model. Would you like to see a little concept art of the monster?


There you have it kids!

No. Don’t worry, it’s not really a Jabba potato head. I don’t think I can quite show you anything until it’s finished and we have a kind of ‘reveal’, you know?

Maybe in a couple of weeks time I could talk about my technical process towards creating him, but I really have no idea if only the 3D artists among us enjoy that. Feel free to let me know?

I’ll talk a little about the monsters we’ve had in previous prototypes of Maize.

A hideous beast based on the very creatures crawling in your own back garden, what could be more terrifying? Check out those legs, we are masters of our craft, here at JF.

A little less of a scary creation, we call him ‘Sparky’, just because. He looks more like an overgrown, mutated turtle, but a bit more primal and animalistic than THOSE ones. This is the one running around our current prototype but it won’t be in the final game at all! This monster was designed to be a chunky train of meat, that would barrel down the hallways on all fours and just smash you to pieces, pretty much.


Casual posing with the Rift


As you may or may not know, we have an Oculus Rift here at the office. There’s no doubt that this is a very cool peripheral to use when playing games and I look forward to getting one myself when the consumer version is ready!

But how does it perform when trying to do artist work?

I implemented the Rift into my pipeline for creating textures within a 3D application. At first I thought the Rift was fantastic, never before had I had such an accurate sense of perspective and scale of my characters, or on the monster to be precise. As I rotated around the monster in the viewport, even I felt a little intimidated by the creature. I would describe it like being in the Matrix.

As I went to paint on some ‘gory’ details, I forgot what true reality was. The creature’s torn, bloody arm felt right up in my face. The Rift had assaulted my senses and right then and there I fainted for about half an hour.


15 minutes before the accident


I have to be careful when creating more ‘gore-less’ environments too. If you are not careful, one quick scroll of the mousewheel backwards will rapidly zoom the camera out. That’s fine, but in the Rift, when you feel like you are really there, you will almost be sure that an angry hawk has just abducted you.

I tried the Rift on a few other applications like Photoshop. Ultimately I was thoroughly unimpressed as the pixels still felt very 2D. Everything remained extremely flat, lacking the depth I so desperately crave. Also, I watched my DVD of Avatar but I did not get the same visual experience I had at the cinema.

Thanks for reading, we grazed over a variety of topics here. You can ask for what you want to hear for next time… if you like?



Programming Blog 02 – What’s That Coming Over The Hill…?

Hello to all you loyal Junkfish followers out there. My name is Gary, commonly known around these parts as “The Goat”. Don’t ask why because it would take up more space than this humble little blog post.

Today I am here to tell you what my blood, sweat and tears have been going into these past few weeks here at Junkfish: the abomination that is not going to give you an easy time while you are aboard the vessel in our up coming game “Project Maize”.

But before I get to that, let me talk about the sound of the ship. Working closely with our resident sound man Jaime, every step has been taken to create a daunting atmosphere; from the eerie sounds in the ambience of the environment to the all out raw aggression from the beast himself. One of our pride and joys here in the audio side of things is the usage of audio occlusion methods. This is used to make the sounds alter as the player moves around the ship by being filtered down by walls and other objects in the way. Using low pass filters and basic raycasting we were able to alter the sound produced by the source in real time. The effect increases with the number of walls between you and the sound emitter. However as you move back into a clear path the sound will become clear once more. Here is an example of the audio occlusion in action through the use of our state of the art TVs. (Excuse the video quality.)



Here you can hear the TV’s noise changing as I duck and dive between the corridors. Notice how the noise gets quieter and filtered down as the wall is between the player and the set. As the player moves further from the TV the static noise gets quieter until it is inaudible.

The next stage which we want to achieve for this effect is to have it come in smoothly around corners and walls emulating how real world 3D sound works in these situations. We’re also looking into improving the directionality of the game’s sound to make it easier for the player to locate certain things. The player roughly knows what direction the sound comes from as we’re using a standard sphere emitter, while we’re wanting it to travel down through the hallways and rooms towards the player like it would in a real place.


But what is that you can hear tearing up the place in the next room…?


He doesn’t know who you are. He doesn’t know what you want. But he will look for you, he will find you and he will kill you! Nothing is going to stand in his way. Not even the most reliable protection known to mankind: Doors.


So I am sorry guys, but you’re just going to have to find another way to stop him. If you do manage to get away from him chasing you don’t assume you are out of the woods just yet. Because not only can he see you running about, he can hear you and he can also smell you! He will use all of these senses to search for you until he finds you again. If you make a noise he is coming to check it out and destroy whatever made it. That may be you! Are you going to be able to evade this creature tearing the place apart not be his next kill? But what are you running from I hear you ask? How is he going to kill you? What is he going to look like? Sorry, but:


Jonesy knows all.



Have a nice day and don’t have nightmares.



Design Blog 02 – Like Alien, but at sea…

Commonly it is assumed that creative pieces come to their originator fully formed, completely unique and ready to be produced. Perhaps for some mystical scholars this is true but it has never been the case for Junkfish – or for myself. We begin with a concept or desire and then, assuming it captures the teams imagination, figure out how to create what we want. We pool our influences from books, songs, film, artwork and personal experiences: borrowing and building upon works which we consider genius. This blog post is about some of those works and how they have (or will) influence our latest title: Project: Maize.

1. Alien (1979)

At its core Maize is a game about being trapped on a ship which contains a deadly monster and finding a way to escape. For anyone who has watched Alien the parallels should be immediately obvious; the crew of the Nostromo unwittingly bring a board a deadly alien and must figure out a way to escape or kill it.

With Maize we want to put the player in the shoes of one character of the film in particular – and perhaps surprisingly it isn’t Ripley.

It’s Dallas. Trapped, alone in the confines of the ship’s ventilation with only the tools he and the crew could piece together from their work equipment. We knew we wanted the player to be able to set up their own environment and choose between items that could aid them in escaping and we feel this scene captures that kind of mentality. Dallas takes the motion sensor, torch and a flame-thrower, he chooses to close the vent shaft behind him, so “nothing” can sneak up on him. He gives himself the best chance. However we also feel this scene and character is the most relevant to the ‘rogue-like’ nature of the game: even if you act the hero you actually aren’t. The hero’s playthrough would never end like this:


We intend to make sure that our players definitely can.

Whether this means the play-through can also finish in an intense air-lock exploding holy-s**t-its-followed-you-on-to-the-life-raft moment… only Jonesy knows, and he’s keeping shooshed.


2. The Labyrinth

Another large influence on the concept of Maize was the labyrinth myth, in which Theseus defeats the Minotaur. The concept of the labyrinth is simple: it is a place in which King Minos drops his sacrifices that is so complexly built they cannot escape before the beast within consumes them. Our procedurally generated environments are exactly this. However, as with Theseus, we want you to be able to cheat. Theseus takes a ball of string with him and uses this to map his route into and out of the labyrinth; we decided there was no reason our players couldn’t do something similar.

The kind of helpful map to expect in Maize.

The Minotaur has also influenced some of our monster behaviour design, it’s strong and it doesn’t much care for you being here, but we don’t want to give too much away about that at the moment. Its all under Jonsey.


3. Amnesia

Both of the previous entries have a hero that attempts to fight the monster and manage to succeed – although only Theseus actually tanks up and decks it. Amnesia: The Dark Decent persuaded us that this was not what we wanted to do. Amnesia‘s non-combative gameplay forces the player to acknowledge their vulnerability and use other means to overcome challenges. We want this for our game. We also believe that the inclusion of the kind of weaponry present in a lot of supposed ‘survival horror’ games could break the players suspension of disbelief (immersion). We believe maintaining this immersion is integral to the players ability to believe they are in danger, as such weapons would deal a double blow to our intended experience.

We also won’t have eyebrows.

These three influences were integral to solidifying the concepts of Maize within our own minds and in how we shared our idea with the rest of the team. Hopefully they give you a few clues as to the direction we’re heading in with the game. This article doesn’t cover everything we looked at, so expect future design blogs to reveal more influences in the future. Ideas are always evolving.

Until next time,


Misc. Blog 01 – Once upon a FooFoo

Day 67 aboard the S.S Junkfish

Rations: Low on water and chocolate biscuits
Temperature: Freezing, hot water bottle losing heat

Stephanie here! I’m one of the code monkeys aboard this gracious vessel. I am not being forced to write this blog. I love to write, honestly. (How many lights are there Steph? – Jaime)

Today I’m going to write about our last game, FooFoo, as well as some of the things we had to work around to get it onto the Samsung App Store so that you can all avoid them too.

So, FooFoo. What is it? Where did it come from? How did it come to be?

FooFoo started out as a simple idea for Samsung’s Student Developer Challenge 2012, where we had to make something that worked around Samsung’s S-Pen devices. The first round of the competition was a 24 hour code jam! (As always with free pizza and juice)!

Being a programmer I happily discovered how fun it is to work in Eclipse and how amazing the Android emulators are… OK ‘fun’ being a loose word to describe it. In 24 hours we managed to get a simple level editor working along with the S-Pen’s input. Not a lot when you think about it! The artists and audio dude did get some assets knocked out as well though.

The next deadline was due a couple of months after the code jam, and the lecturers had thought we had dropped out what with everybody having their honours work to do. On the code side Eclipse kept running out of memory when loading in our levels and we had hit a pretty big wall. However, by some splurge of willpower, we fixed that one bug and everything fell into place! We showed FooFoo to our lecturer just before we handed it in and he couldn’t believe where it came from!

Soon after we had gotten the news that we had made it to the final 15 with the final event being held in London! All I can say is thank you to Samsung for booking us a train down to London, I don’t think I could have handled a bus back up!

The finals were held in the BAFTA building where each team gave a presentation explaining their game, what it could do and its market potential while guest judges played the game. Watching the other teams present we were pretty much sure we weren’t going to place so when our name was read out as one of the prize winners we could not have been more surprised!

After the awards ceremony we did a little bit of patching up on the game (uni work had to happen!), with progress ramping up again in July so we could show it off at Dare Protoplay. This also happened as half the team took part in the main Dare to be Digital competition, so some of us were running double shifts! Thankfully both games went down really well :D!

Then, of course, we moved on to Maize. But we didn’t want to leave FooFoo unfinished, so Bean and I carried on the FooFoo legacy and managed to get 2 full worlds completed with multiple gameplay mechanics introduced.

Though getting the critter up on to the Samsung store was a battle and a half! We encountered some errors that will stop your app from being accepted or updated on the Samsung App store, things you probably never thought about! (We sure didn’t!)

Some things that we ran into when going through the approval process included:

  1. Samsung having camera devices that allow apps to be downloaded and installed onto them. These cameras use the zoom button to control their volume. If your app’s volume is not controlled by this zoom button (not just the usual android volume button) it will fail!

  2. Having your app crash when the back button is pressed. Surprisingly!

  3. A major one, but DO NOT LOSE YOUR KEYSTORE FILE! If you have created and built a project in Unity you will be given a default keystore file, this is used for when you want to update the store with an updated version of your app.

  4. On that note: make a back up of your keystore file. It’ll save you a lot of hassle!

  5. Also, check to see if your app crashes when the device is rotated. Our game didn’t have any rotation mechanics, so we overlooked testing this one ourselves.

When developing FooFoo we had encountered many trials and tribulations, but seeing the public (especially kids!) spend ages trying to solve each level really makes it all worth while!

You should all totally go and download it for free now! You can grab it here!


(ppsssstt: You can grab the soundtrack from here too: – Jaime)

Cheery bye!


(P.S I saw a beautiful pug walking home from work, best day ever)