Studio 2, Project 1 - Post Mortem

This is a post mortem for the solo Studio 2 minor project; Take it Personally. Where I designed and prototyped a game based around a real life experience.

One of the main problems with the project was probably the project plan. After around the half way mark of the project, I never really saw myself sticking to it. Whenever I completed a milestone I would tick it off as if it was a checklist and not a strict deadline. This was probably due to the fact that the project plan I done was a simple one. The layout just had the due date, task and location of completion. There was no complexity in the plan which made the milestones seem almost "in the air". No estimated time to complete, none of the specifics a part from the due date. Also another factor, is probably because it seemed kinda unnecessary. Since this is a small project and I was working on it by myself, having a full project plan didn't seem that important. If it was a team environment with at least one more person on a larger project then sure, a project plan would be necessary. It just seemed that for something this small, I was more concentrated on the project, than meeting up with the plan. A way to fix this would of course be to make it more detailed. More specifics on how long a task'll to take to complete, how will that improve/affect the project, what are the outcomes, what's the scheduled time for work? All the specifics which will make each task seem more grounded and written in stone, rather than floating around and not a necessity to complete on the assigned time.

Testing was something that I wish I done more of. In my project plan, I tasked up testing to begin on Monday of week 4. We didn't get around to it until Wednesday of week 5. Although I did do some form of testing between the 2 weeks with friends, yet taking down their complaints was just stored in my head and changed at the time. I didn't record them to see what was happening on screen, and questions asked weren't designed in a way to fix a specific problem. Then came around the official testing. We had the first hour of Wednesday, week 4 to test our prototypes. I had around 5 people test mine and in the end, came out with some good data. Improvements were made, yet they didn't really seem to change the game that much. Ideally, more testing sessions would be the way to go. I believe that me leaving it late to test, halted progress that could have been made on the design of the game. Fixing this would involve having regular testing sessions. Maybe after the prototype is ready to be played, have a testing session twice a week. This will give me enough time to make changes to the design, as well as the questionnaire to focus it on a more important part of the design. Improving the project plan would also make these testing sessions more important and a date set, rather than a suggestion.

Something that went pretty good, was the prototype. The main goal of the project was to design a game and create a rough prototype. I ended up making something that could be seen more as a flushed out product than a prototype. This was because I spent quite a lot of time early on doing the design document. This then gave me quite a bit of time to create the prototype, which I did do. I had a prototype, yet with time remaining I just kept on adding in details and other things. Coloured materials, better lighting, music, sound effects, etc. Since Unity is a program that i'm familiar with, adding these things in wasn't a problem and I believe it improved the impression of people when testing. Having a more flushed out product for a testing session, provided the tester with a better understanding of the intended experience, and focused their feelings more on what you wanted them to feel. For the future if I want to do something like this again, working hard on the GDD early is a big must. Then an art bible, which I done early on cemented the visual look that I was going for. Giving yourself enough time to make a working prototype first, then adding more features/juice if the time allows is how I would go again with it.

Gatho at 9:00

You're hosting a small party at 9:00pm. It's 8:49pm and you're not prepared. Quickly drive to pick up your friends who cannot drive, shop for necessities and calm your friends down when they message you. You don't have time to lose.

Developed: February 2018 - March 2018

My Role: Solo Development

Type: University Project


Gatho at 9:00, was made for a university assignment where we had to create a game based of a real life experience. I chose the feeling of being unprepared and rushing to get stuff sorted for a party. Although not directly a reflection of the real life experience, the game emphasises the feelings you have in a short, exciting experience.

There are various different "tasks" or "scenes" in the game, which the player has to accomplish in order to move onto the next one. I wanted each of them to have a different mechanic, to create the sense of disorder and increase the pressure on the player. Each of these scenes encourages pressure and anxiety for the player in different ways.

  • The Driving scene, has the player thinking fast, finding the right letter on the keyboard to finish as fast as possible.
  • The Friends House scene, has the player spamming the space-bar, hopefully increasing their heartbeat slightly and encouraging motor-functions which can be seen in the real world equivalent as in-patience.
  • The Messaging scene, has the player spamming any key on the keyboard to reply to their friend. This implies the sense of urgency and drills home the fact that failing to finish the game will disappoint the player's friends.
  • Finally, the Shop scene, has the player hastily looking for produce in a small shop. This can encourage anxiety, in-turn; having the player perhaps making bad decisions or missing obvious items.

Other elements in the game which can encourage the intended experience are:

  • Music. This was done by finding a fast paced track on Incompetech (Darkling) and then adding a ticking clock every 1 second. Not only does the music encourage fast behaviour, but the ticking implies that there's no time to lose.
  • Popping Text. Each scene in the game has coloured text which pops in and out. They provide information and context to the scene, as well as encouraging the player on how to act.

Gatho at 9:00 - Dev Diary #3

This dev diary will cover week 3 and 4. The prototype is pretty much complete, along with the documentation. Expanding upon the idea of trying to pressure the player and make them rush, I've added in a few new things.

In the friend's house scene, I added in some text: "Your friends can't hear you! Beep your horn!" This text pops in and out to emphasise it. This first of all, draws the player's attention to provide context on what's going on. And secondly, it encourages fast behaviour. The quick movement of the text makes it so the player feels like they need to go fast.


The same can also be said for the messaging scene. The same popping text can be found on the left hand side, yet along with something else. When the scene is loaded, the camera starts to zoom into the phone and rotate clockwise. This adds more movement into the scene, creating the feeling of going forward and not stopping (how the player should behave in the game). Because having a static screen for the messaging scene just didn't feel right. It felt out of place with the others where movement was occuring at all times.

One of the largest changes in terms of documentation and the actual prototype from previous weeks, was the shop scene. I playtested the game a bit with friends and found that the shop scene was the most confusing. That is kind of intended, as you don't want the player to just fly through the scene, but it just seemed a bit too confusing. So the original shop layout was changed from the vertical shelves to the horizontal shelves.


I believe this change is quite important. Before when you loaded into the scene, only 1 shelf was visible. Where as now, all 4 shelves are visible. This prevents players wondering where an item is, only to find out that there's a shelf at the back of the store. I also added in categories on the shelves. They just give a basic word description of what's on each side of a shelf so that players can ground themselves more and understand what's going on.

Gatho at 9:00 - Dev Diary #2


It's week 2 since the project began, and week 3 since uni started up again. Most of the documentation for the game has been completed, with an art bible and asset list still in the makes. Speaking of an art bible, i've been spending some time flushing out the visual look of the game. It will be 3D, low poly and set at night.

Here's an example image from the art bible, displaying the visual look of the shop scene. Dark, small, the sort of atmosphere you only visit for a short period of time. 

The images below show off the intended look for the driving scene. Dark roads, lit by street lights with no people around.


A prototype has also been started on. This will just feature the base mechanics of the game and all the essential elements that are required to sell the intended experience. The more time demanding features such as models, sound effects and complex lighting will not be made for the prototype for time sake. Although later on I do intend to return to this project and flesh it out into a finished product.

The above scene you see is of course the driving scene. You have to tap differing keys on the keyboard in time to make the car go faster, com


Also in the past week, I added a new scene to the game. This was done to make the existing actions seem less repetitive, and push the intended experience further. The point of failure in the game for the player, is disappointing their friends. So having this scene where the player needs to frantically reply to a message adds to that and instils the sense of fear and pressure to not fail. Like the other tasks in the game, this one requires speed, by having the player spam the keyboard to fill out the message.

Gatho at 9:00 - Dev Diary #1

Our first project in studio 2, is to design a game around an experience we've had in our life. A memorable one for me, is rushing to get prepared if i'm having friends over or going to theirs. That feeling of being pressured for time and quickly scrambling to accomplish a thing, is something i'd like to replicate in a game.

So, the basis of the game, is that you are hosting a small party at your house with friends, yet you're unprepared. They all arrive at 9pm and you still need to pick stuff up from the shop and give those friends of yours a lift since they don't have a car. The game has you going through a number of different "scenes" or states. Where the player has to do certain tasks in order to progress to the next one.

These layered tasks, ticking of the clock and general atmosphere will hopefully make the player feel pressured, rushed and anxious. Because if they fail, their friends will be disappointed, as this gatho was organised weeks ago.

So what sort of things will the player be doing to create these outcomes?

  • First, there are 3 different states currently. The driving state, shop state, and friends state. Each will feature different controls and objective that needs to be completed. The better the player is at each state, will decrease their time in it, in turn: finishing the game faster, which is the goal.
  • The driving state, is what connects all the other states together. When the player needs to travel between locations, they will see on-screen the car moving along horizontally. To increase the speed of the car, there is a skill-check at the bottom. This will require the player to time tapping a certain key on the keyboard to get a speed boost.
  • The shop state, has the player controlling a first person controller. They need to find certain items from around the store based on a shopping list in hand. The similarity of many products and shelving positions will hopefully make the player feel pressured and hopefully have them running around the store.
  • The friends house state, has the player looking out of their car window at a friends house. They need to spam the space key as fast as they can, which will decrease the time that their friend has to come outside. This emulates the experience of tapping your finger when anxious/rushed for time, increasing the player's heart rate.

In terms of other features which will encourage the intended experience, those are:

  • Background music which is fast. A ticking clock can also be heard. Sort of like music you would have in a chase scene, but not as "actiony".
  • The time remaining to 9pm on-screen. This will give the player a good understanding of how long they have left, so they know if they need to hurry along faster or not. Now, it's either that option or another one i've been thinking about. And that is having the player need to hold down a button to bring up the time on their phone. This could emulate the feeling of looking down and seeing the time when you're late, with the moment of dread just before hand in not wanting to see how bad it is.
  • The general transition between the states will be instant. For example in the driving state, when the car reaches the edge of the screen, the next state will instantly appear. This adds to the urgency. It can be seen in movies, where characters in a rush are cutting from one place to another instantly. 

Kings of the Arena

Kings of the Arena, is a 2D, top down hero shooter. You can choose from a variety of characters and battle out in multiplayer against others.


Developed: August 2017 - November 2017 (development halted)

My Role: Solo Development

Type: Solo Project


Design Decisions and Process

The overall experience I intended for, was competitiveness. If you're more skilled than someone else, then you should win. The desired "easy to learn, hard to master" concept was intended. Learning the abilities and projectile types is fairly easy, as there aren't that many. Mastering the game though, involves knowing how to combine those abilities, both your own as well as other teammates'.

Each character is designed in a way to excel at a certain playstyle.

  • Archer: Tank, heavy damage, high health.
  • Mage: Defence, shield ability, stun ability.
  • Cleric: Support, can heal allies, suck health from enemies.
  • Druid: Support/damage, can create AOE effect of increased attack speed, heavy damage ability.
  • Assassin: Offensive, low health, high damage abilities.

Since the game is designed with competition and skill in mind, choosing the right combination of characters for a team is vital to success. A more skilled team will hopefully be able to play one of each of the characters, using their desired roles effectively with each other to create a team dynamic that works well.

These sort of "easy to learn, hard to master" competitive games are very common. Overwatch has characters, each with specific roles in mind, allowing for very strategic, team based games. Even a game like CS:GO, with no built in roles, players design their teams around each others specific playstyles. There's the entry fragger, support and others. Choosing who does what, where they go and how they interact with the team is what defines a bad team from a great team.

Promised Purjury

War is approaching and nearby Kingdoms are coming to you for assistance. Some of them truly want to be on your side, yet others are trying to deceive you. Pay careful attention to what they say and their Kingdom's statistics to determine whether or not they are telling the truth.


Developed: January 2018

My Role: Solo Development

Type: Make-A-Thing Game Jam



Design Decisions and Process

For this game jam, we were given 3 words that the game needed to involve. Kind, thwart and blip. The idea of being kind or thwarting someone made me think of Papers, Please. So I went with a medieval variation of that game.

The overall aim was to make the player feel pressured and on edge. This was done with the following design decisions:

  • Having a timer. It's in the middle of the screen, so it's always in their view. Allowing the player to know how long they have left until failing, causes them to feel more pressured. Keep Talking and Nobody Explodes, has the players on edge and feeling pressured the entire time. With a ticking timer as well, this does indeed cause the players to hurry and feel more on edge as the game progresses.
  • Adding in more sections that the player needs to check is another way to make them feel pressured. All of a sudden they need to review Kingdom relations and travel distances. Still within the 30 second time limit, their pace of reviewing information increases as more is introduced, increasing the pressure on the player. This can be seen in Papers, Please, where new requirements are added constantly.

Country Car

This is a remake of an old 1982 Atari game, Barnstorming, in the style of the famous American painter, Edward Hopper. You play as a car, driving out from the large city to your new country home. Avoid obstacles, while going through gas stations to get to your destination.

Developed: October 2017

My Role: Solo Development

Type: University Project



Design Decisions and Process

From early playtests, it was obvious that people did not know that they had to go through the gas stations to win the game. So to communicate this mechanic without directly telling them, a gas station was placed directly in-front of the player at the start of the game. This caused them to almost always go through it.

Re-creating Edward Hopper's realistic art style was something I struggled to figure out early on. Eventually though, I went with a low poly approach, theming it to the 1930's. This was done by making the textures less saturated and having an old-timely font. Overall, I believe that even though it doesn't feature realistic painted visuals, it still relates quite a bit to Edward Hopper.

The main correlations to the artist though, was done through the setting. All things Edward Hopper painted like trains, looking out of windows, countrysides, gas stations, etc, were implemented into the game. A main aspect of his paintings was looking out of windows, which the camera appears to do in-game. Lighting was another element Hopper fondly painted. In the game there are 3 levels, each with a different level of lighting and visual style. Dusk, Dawn and Midnight. This creates both a different visual style, as well as altering the game. At Dawn, there are more potholes and at Midnight, vision is limited. These small differences create distinguishable levels, for a project we only had a few weeks on.

Janky Jousting

Janky Jousting, is a local multiplayer game where you and another person joust to the death. The knight is hard to control and with the King watching, you must perform your best. This is a game that is fun to play with a friend or two.

Developed: May 2017

My Role: Solo Development

Type: Solo Project



Design Decisions and Process

When making Janky Jousting, I had in mind that I wanted to create a party game. Games like Gang Beasts and Mount Your Friends are special because the fun comes not from mastering the game, but from playing with your friends. I've played Gang Beasts with people both online and in-person, and in-person is by far the better experience. Being able to yell at and nudge the people beside you creates the sense of fellowship and excitement.

Here are the design decisions that influence the intended party-game experience.

  • Each round is quick and goes to the next one almost instantly.
  • There is a lack of precision in controlling the knight and defeating your enemy is not really based around skill. This allows for a more even playing field. Perfect for a group of friends/party environment, where quick play-throughs are common.
  • When the lances hit each other, no one scores. This can create the sense of "I was so close to hitting you!" for each of the players, increasing the tension in the room.

There are many other games that inherit the same features to create the party-game experience. Going back to Gang Beasts, the characters are "floaty" and often hard to control. You end up most of the time spamming all the buttons to try and defeat your friends. The winner is not nessecarily the best player, as being the best player isn't what makes the game fun. The fact that anyone can pickup and play the game and have an almost equal fighting chance, is what makes it great for a party or group atmosphere. In Janky Jousting likewise, you just need to know the controls and you're off!

Make-A-Thing January 2018: Promised Perjury

Promised Perjury was a game I made for the 4 day long, Make-A-Thing game jam this month. We had three words that we needed to create something around: blip, kind and thwart. Instantly the idea of Papers, Please came to mind. The word blip then made me think of radar or some kind of detection method. My initial idea was to create a game where you had to screen aliens coming down to Earth. Check their stats, make sure they're not enemies or associated with any and make sure that what they're carrying is legal. I liked the idea but instead having it as Kingdoms coming to you, to assist you in battle, sounded better. So I began working on Promised Perjury.

I knew how I wanted it to start. A King or Queen pops up on screen, they say a few sentences of dialogue about wanting to help you in battle; then you need to decide if you accept or deny. On the left hand side, there will be stats about that Kingdom. Name, ruler, population, are they at war, etc. The player would need to look at the message and the stats to make sure what the leader is saying, is the truth. When that was being done though, it didn't seem hard. In Papers, Please there are various books and documents that the player needs to refer to and for this, I wanted to do something similar.


So I added in resource distribution. Each Kingdom will have a certain distribution of the 6 resources. Wood, stone, iron, wheat, livestock and gold. Their message could say something like: "We will supply you with weapons and armour!"

The player would then look over and see whether or not their percentage of iron is greater than other resources.

The Process

The first thing I encountered when making the game, was the process of creating the different Kingdoms. My first thought was creating a Kingdom class with all the data, then in the inspector, fill in all the Kingdoms. This of course is a bad idea, as something like that would be both confusing and easy to mess up. So my next idea was to use CSV's.


Laying it out in Google Sheets is great. You can easily visualise your levels (in this game there are 2, with each level having 10 Kingdoms). You can also colour certain cells, in this case doing so to Kingdoms whether or not they are telling the truth or not, as well as if a Kingdom is landlocked, which plays a role with some of them.

From there on, it was pretty much straight forward. Early in the project I worked on the pixel art and UI. Setting this stuff up early helped me in both encouragement to finish the game, and in giving me a platform to work from.

Designing the Game

In a game like this, where progression is based on an accept and deny button, you need to make sure that the player can't just blindly run their way through. Both in actual game mechanics and design. For mechanics, the player has the ability to make 3 mistakes before it is game over. For design, I had to make it so that patterns were kept to a minimum. The structure of the first level for if the Kingdoms were telling the truth or not was: Y, N, Y, N, N, Y, N, Y, Y, N.

I knew that the first Kingdom had to be telling the truth. This is the first thing the player comes into contact with and kicking them down straight away is not the way to go. Although the second Kingdom is not telling the truth. We need to introduce the fact that not all of them are good guys. Setting that Kingdom's iron percentage really low and saying that they will supply the weapons is hopefully an easy enough Kingdom to catch out. From there, no patterns were formed, and each Kingdom that lied, had a unique way that they lied. Some were subtle, some were more obvious than others. In level 2, Kingdom allies were introduced. Each Kingdom that came to you had a number of different allies. It was up to you to make sure that those allies weren't your enemies and also that the Kingdom wasn't at war with your allies.

Studio 1, Project 3 - Post Mortem

This is a post mortem for a project I worked on in a team, called The Gold Standard. Overall, the project went well. Our initial idea of the game and how it played out is fairly representative of the final product. Although, there were a few problems that occurred during the production.

Laying out the Levels

One of the problems I believe we had which occurred late in the production, was sitting down and documenting the layout of the levels. Us 3 games students each made many levels to reach the goal of 50. Our game was divided up into 5 stages, with each stage having 10 levels. I was given the first stage which introduced the mechanics of the game, while the other 2 team members had the other stages. This process of creating the levels happened during the last week of the project, due to systems of the game needing to be fixed beforehand. This rush of making levels caused them to be different in overall design and not really that well tested. We wanted to go for that strategic, edge of your seat experience for the player. Providing multiple possible routes, each having their own risk vs reward situation. In the end, the levels seemed bland. Each member of the team had their own way of which they laid out the levels and communication between each of us during this process was limited. We never had a document that we could refer to how the levels should play out. How many possible routes should there be? How linear or continuous should the levels be? We went out on a whim, producing levels that just looked kind of different from the previous one.

So how could this have all been avoided? Well the first thing I can think of, is a document. A level construction document was something that we started, but it just laid out which mechanics would be introduced when, not really that big of a help. The document would need to lay out: the flow of the level. How far into each level should the player come across a guard? Is it fair to have a guard see them in their starting position? In what way do rooms connect to each other? All these questions and even values should be discussed. Other things such as level time. How long should a level last? Min, max times? What is the maximum amount of time a player should be "inactive" from tapping on distractions? Most importantly, the document needs to tell the designers how they can make each level meet the desired experience that the game is trying to achieve. Communication is also something that needs to be involved. Talking between team members before, during and after a level's creation. Gaining feedback and making sure that the level meets the requirements for it to be a level. Playing each other's levels is also something that we didn't do, which we should have. In doing this, you can see how your 2 styles differ, and how you can make changes to closely seal the gap.

Source Tree Problems

We used Source Tree for the entirety of the project. It was working fine up until around half way through the project. A push or pull error led to one thing, then another, causing quite a bit of frustration and confusion for the team. The project ended up being accidentally deleted. To fix this, a new branch was made and after a bit, the project was back online, yet Source Tree was butchered in a way. Whenever we wanted to push or pull the project, we had to make sure that the correct branch was selected after making this local branch thing... it was pretty confusing. This took us a a bit of time to adjust to, yet there was something that we forgot totally. At the time the animators were pretty much done with their assets, except for a few small things. It wasn't until close to the end, when we realised that those few animators who were pushing changes, didn't push to the new branch. This was totally on us and we should have told them instantly. Luckily it didn't cause too many problems as the changes were very minor. This happened because as early game developers all we really need to know about Source Tree is pulling and pushing. We don't need to know the ins and outs of the program, so when a critical error occurs or something bad is about to happen, we're kind of in the dark. It also occurred because we never really had a schedule or talk about who will be working on what assets at what time. When multiple people are working on the same thing and they try to push or pull changes, it can cause problems. Many of these minor problems did occur almost on a weekly basis.

Getting around this problem would be done by management. Knowing who is doing what at what time. Having only one person working on one asset at one time allows for a clean push and pull to Source Tree. In the future when working in a team environment on Source Tree, we're going to be more clear about what we're working on. HacknPlan would be useful in this case. Making a task called "Working on ..." or "Implementing/improving ..." makes it clear what you're doing. Telling team members to also constrict what they change while working is great too. Going around messing with different prefabs and scripts when you don't know if you should is not a great thing to do. Making sure everyone just sticks to their task and test scene will hopefully prevent the issues that occurred with our Source Tree project.

Getting the Work Done

One thing that I believe went very well for our team, was getting the work we needed complete. Whenever there was a deadline for a certain amount of work to be done, both documentation and the actual game... most of the time it was good to go. We tested our game at every playtest, getting useful feedback to improve it upon. One of the big reasons I believe this happened, was due to laying out the tasks early on. At the start of every week and/or milestone, we laid out the tasks we needed to do for that week. This gave us an overall goal. Throughout the week then, seeing this large list of tasks encouraged us to work at it, rather than entering the tasks as we went. If that was the case, then I believe most of the work would have been done on Sunday night. Team meeting were also another big help. Every Tuesday and sometime during the rest of the week we tried to have a team meeting on Discord. In them, we would discuss what needed to be done for the week, who was to do it and to what standard we expected the work to be at by the end of the milestone. 

In the future, continuing on with this layout is certainly going to be good. Setting up the tasks day one of the first milestone sets that large objective ahead of the team. Seeing all the work that needs to be done, discourages trying to cram is all in a day before it's due. Team meetings are also obviously a good thing. Even though we had around 2 a week, I believe that we should have had more. In my mind team meetings create that "boost" of work. After one, you're encouraged to continue working on what you're doing , before that slowly drops down. Having a team meeting 3 times a week, one Tuesday, one Friday and one Sunday would evenly spread out that work flow. 

Dev Diary - Project 3: Creating a Useful Art Bible

As project 3 is coming to a close, we can look back on our documentation to see what worked and what didn't. Since we had 6 animators working with us this time around, creating an art bible which conveyed the visual style of the game and all the assets was vital. Looking back at ours, I can see what went to plan and what didn't.

In my mind, what's necessary for an art bible is...

  • Understanding your platform.

Knowing what device/s you're making the game for can help you in deciding on a style. For us it was voxels, so deciding between small, detailed voxels, and large ones depended on our platform. Since we were publishing mainly for mobile, we later decided on making the voxels larger so that there is less screen static. Unfortunately this was later on in the project and we didn't get around to actually implementing this new style into the game.

  • Conveying a visual style.

Many games have their own distinct visual style. For ours, we went with a saturated, red/brown/green look. In the art bible, referencing other games, movies, paintings and more is great for conveying that visual style to your art team. Explaining what you want out of each image and what you don't, can create a solid ground work for the final product.

  • A good colour palette.

In the same lines as the visual style, a colour palette can make a game what it is. You need to visually show the style of colours you want in the game. How saturated? Bright? Colourful? Having a colour palette followed by an example image of anything is also a great help. You want your art team to be creating the same looking assets that follow the colour palette and visual style closely.

  • Animation style.

Still following with the art style, animation style is quite important. It can determine quite a lot about your game. Do you have bouncy, big animations? Then you're probably conveying a fun or action game. Do you have tight, direct animations? Then this could be a serious strategy game. We didn't take animations into account until later on, yet doing so earlier will make the game you're working on more streamlined to a certain experience.


Dev Diary - Project 3: Music Creation

Our game is a stealthy, strategy game. So for this, appropriate music is necessary. Something similar to James Bond or Mission Impossible but not as loud and impactful. This is a game where you are trying not to be seen, yet are constantly on edge as a guard can spot you at any time.


For the music creation, I used Bosca Ceoil. An tool which is very easy to use. The image above is of the overall arrangement of tracks. Each track is around 3 seconds long and you can choose an instrument and notes to play. These combined creates your song.


I used a drumkit, "magical" bass and a special digital synth or something. Many of the instruments are quite abstract and sound quite similar. 

For the tempo, it's quite quick yet slow at the same time. It creates that sense of suspense for the player, with the osculating beats. 

My only problem with the song is that it's quite repetative. If you're playing the game for a long period of time, then hearing the same 4 tracks over and over again might drill into your brain. This is due to me not spending a lot of time working on it, as well as the program's simplistic nature.

Anyway, here's the final song. It will be used for background music in the levels, hopefully creating the experience we're going for.

Implementation into Unity

The way we have our project set up, the menu and actual game are separate scenes. This means that the song can just be applied to an AudioSource in the game scene. So when you click on a level in the menu, it loads the game scene and the song is playing automatically.

In the GameManager game object, an AudioSource component was added. The music track was added as the audio clip and "loop" was enabled so that it keeps repeating as long as the level is open.

Dev Diary - Project 3: Sound Effect Creation

For our game we have a variety of different interactables. TV's, washing machines, radios, etc. For all of those things, we need sound effects. Although not a necessity to the game, it does add polish and player feedback.


One of the sound effects that I made, was for the radio. We want short snippets that can be played upon tapping an interactable, so around 2 seconds is good.

For this effect I used 2 different clips. The first one, is turning on a radio with a bit of chatter, and the second one is white noise/static.

Like in movies when you hear people turn on a radio, sometimes there is that static noise before the music. This replicates it.

When I imported the clips though, the static was too loud and the chatter was too quiet. To fix that, I simply made the chatter louder and the static quieter. At the start of the chatter clip, there is a click noise which sounded good, so that was dragged forward and amplified so that it can be heard better. Also many parts of the chatter clip were cut or shortened so that the final clip included both the quick channel flick and foreign talking. This in turn, created a radio distraction sound effect.

Here it is, if you want to give it a listen.

Dev Diary - Research Report: 2D Sprite Outline Shaders


Outline shaders, especially for 2D is something that i'm very interested in. These can highlight objects that the player needs to interact with or follow. So I decided to jump in and learn how to make them. 


First, we need some properties to know: what the sprite we will be outlining, if we'll be outlining it and what colour it'll be.

[PerRendererData] _MainTex ("Sprite Texture", 2D) = "white" {}
[PerRendererData] _Outline ("Outline", Float) = 0
[PerRendererData] _OutlineColor ("Outline Color", Color) = (1,1,1,1)

Also adding in our pass definitions, telling the pass what to do and what not to do. We don't want depth, lighting, or anything that can alter the outline in the game space.

Then we need fill out our tags which will tell our shader how it will work and render the final image.

    "Queue" = "Transparent"
    "IgnoreProjector" = "True"
    "RenderType" = "Transparent"
    "PreviewType" = "Plane"
    "CanUseSpriteAtlas" = "True"
Cull Off
Lighting Off
ZWrite Off
Blend One OneMinusSrcAlpha

In our pass CG PROGRAM, we want to indicate our comnpilation directives. 

#pragma vertex vert
#pragma fragment frag
#pragma shader_feature ETC1_EXTERNAL_ALPHA
#include "UnityCG.cginc"

Then we are going to pass in our vertex data and run it on each of the verticies of the sprite. Since we're making an outline for a 2D sprite, this isn't going to be too flash.

struct v2f
    float4 vertex : SV_POSITION;
    float4 color : COLOR;
    float2 texcoord : TEXCORD0;

float _Outline;
fixed4 _OutlineColor;

v2f vert (appdata_base IN)
    v2f OUT;
    OUT.vertex = UnityObjectToClipPos(IN.vertex);
    OUT.texcoord = IN.texcoord;

    return OUT;

Now this is where we begin to create the outline. In the fragment shader, we basically first get the pixel's colour from the "SampleSpriteTexture" function. This is a custom function which returns the colour of the sent pixel coordinate. 

Then we check if we're supposed to draw an outline and if the pixel is not transparent. If so, then we get the colour of the adjacent up, down, left and right pixels of the current one. If any of those pixels are transparent, then we make this pixel the outline colour.

fixed4 frag (v2f IN) : SV_Target
    fixed4 c = SampleSpriteTexture(IN.texcoord) * IN.color;

    if(_Outline > 0 && c.a != 0)
        fixed4 pixelUp = tex2D(_MainTex, IN.texcoord + fixed2(0, _MainTex_TexelSize.y));
        fixed4 pixelDown = tex2D(_MainTex, IN.texcoord - fixed2(0, _MainTex_TexelSize.y));
        fixed4 pixelLeft = tex2D(_MainTex, IN.texcoord - fixed2(_MainTex_TexelSize.x, 0));
        fixed4 pixelRight = tex2D(_MainTex, IN.texcoord + fixed2(_MainTex_TexelSize.x, 0));

        if(pixelUp.a * pixelDown.a * pixelLeft.a * pixelRight.a == 0)
            c.rgba = fixed4(1, 1, 1, 1) * _OutlineColor;

    c.rgb *= c.a;

    return c;

So pretty much, if the pixel is at the edge of the sprite or surrounded by a transparent pixel, colour the pixel the outline colour. This is an inside outline compared to a shader that draws the outline outside of the sprite. Which one is better? It depends on what you're making and how much pixel real estate you wish to give up. For pixel art games, this one probably isn't the best, yet for games with larger sprites the issue won't matter that much.

Now, having this shader as it is wont do anything. So we need to add it into Unity...

Implementing it into Unity

First, we need to make a new Material and set the shader to "Sprites/Outline". This material can then be applied to sprite renderers. Yet... it doesn't do anything.

To fix this, we need to make a script. This script can be called SpriteOutline and it will transfer values that we enter such as colour and outline size to the material.

public class SpriteOutline : MonoBehaviour 
    public Color colour = Color.white;
    private SpriteRenderer sr;

    void OnEnable ()
        sr = GetComponent<SpriteRenderer>();

    void OnDisable ()

    void Update ()

    void UpdateOutline (bool outline)
        MaterialPropertyBlock mpb = new MaterialPropertyBlock();

        mpb.SetFloat("_Outline", outline ? 1.0f : 0);
        mpb.SetColor("_OutlineColor", colour);

Make sure that at the top of the script the [ExecuteInEditMode] tag is added. This makes it so that the shader can be visible while not in play mode.

For our variables, we have the colour that the outline will be and the sprite renderer, of the sprite we're affecting. 

The enable and disable functions get the sprite renderer component, as well as updating or not updating the outline.

In the UpdateOutline function, we transfer those valuables to the outline material. The "outline" float is either 1 or 0 and determines whether or not the outline is on or off. Then we just need to apply the script to the object with the outline material and...

It's complete. We can alter the colour of the outline in the editor.

Using it in the future

Now that the outline shader is done (and works), it's ready to be implemented. At the moment though, I don't have any games that would use this shader, but hopefully in the future that will be a possibility. 

Things like highlighting items, making enemies visible through walls, etc, will all be possible by this shader. It may need tweaking to allow for seeing it through walls and outlining away from the sprite (not inside it), but that's for the future. This was just a learning experience in seeing how these sort of things are made, how difficult it is and how well it works.


Dev Diary - Research Report: Grid Pathfinding

Something that i'm very interested in is pathfinding. More specifically grid pathfinding. So I decided to go and learn what it is, how it's done and how I can implement it into a project.

There are 2 main different types of pathfinding. A* and Dijkstra. A* checks all the surrounding tiles of a starting point and sees which one is generally the closest to the end tile. Then that tile is checked and so on. With Dijkstra, each tile around the start point is checked to see if that tile is the end tile. If not, those surrounding tiles of that tile are checked. Below, A* can be obviously be seen to be the better of the 2. It's more efficient, and that's what i'm going to be going into with this research report.


We start with our start tile and end tile. What we want is the shortest path between the 2 tiles.

Then we check each of the start tile's surrounding tiles.

The top-left number is the G cost. This is the distance from the starting tile.

The top-right number is the H cost. This is the distance to the end tile.

Added together, these numbers form the F cost of that that tile. The F cost will be used to determine which tile's should be included, and which ones shouldn't.


By looking at the F cost of each of the surrounding tiles, we can see that the top-left tile has the lowest cost. So then that tile gets selected and the surrounding tile's values are calculated.

In this case where multiple surrounding tiles have the same F cost, we can just go with the tile that has the lowest H cost. 

Here, the new tile we selected has surrounding tiles that are not the lowest on the board. From the original starting tile, we can see that the top and left tiles have the lowest F cost. They also have the same H cost too, so we can just select both of them.

In doing this, we are creating an array of tiles which could hold the possible shortest path. We just need to keep on going with these calculations, until we reach the end tile.

After some time we finally reach the end tile and out of all the red tiles, the shortest path can be found.

So how can this be used in the future?

This grid pathfinding is very useful. In the future there are games that I will probably make, which will require a system like this. Strategy games, puzzle games and even other types of games that don't use grids, which this system can be translated to. Unity already has many assets and scripts online for grid pathfinding, yet knowing how to do it yourself is always good.

Games like Civ 5 and other 4x games use grid based pathfinding to move units. These sort of games are very complex, yet at their roots use this sort of pathfinding system.

Games in the future that i'll want to hopefully make are 2D strategy games. Things similar to Civ (yet less complex) and realtime war games which use individual units. These sort of games can be as complex as you want them to be, still with a level of strategy required.

Dev Diary - Project 3: Collaborating

This project was the first video game where we were assigned team members from other disciplines. We had six animators on our team, who helped out in creating the 3D voxel assets for the game. Later on in the project, we were contacted by audio students who helped out by creating music and sound effects for the game.

Working with the animation students...

Working with the animators was pretty good. Since we had them in our team from the very start, they were in our Discord and attended some of our meetings. We had an asset list of all the things we needed made and generally, they were on time. The models they made were of high quality and matched the requested colour palette. 

Their involvement in the project didn't end there. An animators workflow document was written up for them to follow, which explained how to set up SourceTree and how to import the models into Unity. This probably got them more comfortable with both software's and made the process of importing the models easier for us. With all the pushing and pulling from SourceTree, the animators didn't really mess up once. There were no un-merged, or disconnected branches from their side, which for us is great.

Working with the audio students...

Working with the audio students was similar to the animators. We had three audio people come in at around the end of the project, as it was great timing because we didn't really have much to do with sounds in the game.

They just asked what sort of theme we were going for with the music. Then we talked a bit about the sound effects we needed for the appliances. It was generally a quick conversation and they went on their way to produce them. With the audio people though, we didn't get them to do the whole SourceTree then Unity process as this was very last minute. If they were in the project from the beginning though, that would be the case and just like the animators, they would probably not dissapoint. 

Dev Diary - Project 3: Teaching the Player

The first stage of the game is there to teach the player how to play the game. Each level at the start presents a new mechanic/system to the player.

Level 1


Level 1 introduces drawing the accomplice's route and collecting the primary valuable. Why wasn't the first level just drawing the route? Well because the goal of every single level is to collect that valuable. Having the first level dedicated to just that objective with no other distractions in the way, implies that this is what the player needs to do. Having the primary valuable in a separate room also shows that the path can turn. If the valuable was in the middle between the entrance and exit, then that ability may not be known to the player.

Level 2


Level 2, we introduce guards, in turn also distractions as well. This level shows the player how guards interact with distractions and how they move along patrol routes. The guard is mostly always in range of the distraction, so when it's touched, the guard will mostly always go to it. Since it's in a separate room, it makes this level quite easy.

Level 3

Level 3 had multiple distractions. It shows that solutions to a level aren't visible in the first few seconds. The player will need to think when and which distractions to tap, so that the guard doesn't see their accomplice.

Level 4


Level 4 introduces secondary valuables. With previous elements and systems that were introduced, in play, this secondary valuable is something that is quite easy to get and the path to it is easier than if you were to avoid it. This is just to show the player what a secondary valuable is, and how it can improve your score. In the future, these valuables won't be as easy to achieve and will most of the time be along the path with most risk.

Dev Diary - Project 3: The Third Playtest

For the playtest this Monday, we were tasked to get all 50 levels completed. We got around 40 of them done, which was enough for testing. For this playtest, we wanted to know if the level progression was good and if the structure of levels, creates the experience that we're going for. 

Questions we asked were:

  • Do you feel as if there was a steady increase in difficulty as the levels went on? (yes/no)

We wanted the levels to feel as if they were getting harder. The first stage is there to teach the player how to play the game, and the next 4 will increase in difficulty.

  • How often did levels present multiple paths with different levels of challenge? (never-always)

This is a strategy game, so presenting the player will multiple ways to complete a level, each with a different level of risk vs reward is something that we're trying to achieve. Having just one obvious path would make the strategy aspect of the game obsolete.

  • Do you feel that passing a guard was based more on the following... (skill/timing/chance)

Tension and stealth is the other part of the game that we want the player to experience. Having close calls with the guards vision cone creates that sense of excitement.

  • What elements of the levels did you observe in the Planning Phase? (distraction radius'/guard vision cones/secondary valuables)

The Planning Phase is still something we need to work on. It is the moment where players can sit back and observe. Know the ins and outs of the level, where the guards move, to what extend their vision cones touch certain objects, etc.


So how did it go?

For this playtest, we unfortunately only had 2 testers, yet their results are still interesting.

  • Do you feel as if there was a steady increase in difficulty as the levels went on? (yes/no)

50% yes, 50% no.

This is probably due to the way we made the levels. Each person on the team was assigned a stage (10 levels) to complete. Since we were doing these in our own time, not generally sharing difficulty curves with each other, the increase in difficulty probably stopped at the end of stage 1 and fluctuated from there. There was never a talk about how each stage will increase in difficulty, or how to create that increase. More guards? Larger levels? More complex guard patrols or less distractions? More distractions? These things were never quantified, never looked at and tested in the terms of difficulty.

Do we have time to do this? Probably not. It is something that we should have done quite a bit earlier on.

  • How often did levels present multiple paths with different levels of challenge? (never-always)

Both testers were halfway between never and always.

A bit like the previous question, we never quantified how difficult something is from something else. Creating these multiple paths with varying difficulty is something that I done a bit with my levels. We talked about it a bit as a team, but with the close deadline, that was probably an afterthought. 

  • Do you feel that passing a guard was based more on the following... (skill/timing/chance)

50% skill, 50% timing.

With the visible guard patrols and execute button added in from the previous playtest, timing where guards will move and when is something that is easier to do now. I don't think it's 100% not chance though, as there are still bugs with the guard vision cones, but there is an improvement.

  • What elements of the levels did you observe in the Planning Phase? (distraction radius'/guard vision cones/secondary valuables)

50% for distraction radius', 50% for guard vision cones and 0% for secondary valuables.

Last playtest, we changed up the Planning Phase quite a bit. An execute button was added, better accomplice route, glowing primary valuable, guard paths, etc. Still though, some of these elements are not the best. We found out in the playtest, that holding down on the guard to see their vision cone was awkward. Your finger covered up the guard and sometimes even the vision cone. To solve this, we could add in a button on the side of the screen to make all guard vision cones visible.

For the secondary valuable not being seen, that is still a problem. We want those objects to have a shiny effect but not like the primary valuable. If we make it shiny, yet less visible, then there's the chance that it may not be seen. Yet at the same time you don't want it being more visible than the primary valuable. 


Some other changes made were...

On the day, we added in a "speed up" button. This button when held down, increased the time scale of the game to 2. Why? Well because in the earlier levels and some of the later ones where there is a large amount of open space, watching the accomplice move through it is a bit boring. The player doesn't really have a lot of stuff to do then, so having them hold down this button to increase the speed is good. It also creates moments where holding it down might make them run into a quickly turning guard, putting that risk vs reward sense into it somewhat.


questions for the future

From this point, there are still questions we'll need to ask for potential future playtests. Even though this test returned results, that does not finalise what we need to know.

The next playtest will most likely continue with asking questions about the level structure. Since they are our weakest part of the game at the moment, they will need much more iteration and improvements. This will require the team to coordinate and document what dictates a level's difficulty. 

Questions for the future may be:

  • How often did you have close encounters with the guards? (never-always)

This question will further give us insight on whether the intended experience is being met. The guards coming very close to the player, almost detecting them is what you want. It creates intense moments and excitement. 

  • When repeating levels, how often did you try out an alternative path, rather than just repeating the same one over again? (never-always)

The player taking alternate routes through the level is something that we want to happen. When one route fails that might mean that either: the route is bad or that you didn't tap on the distractions at the right time. We want to encourage this behaviour both to create variety and that risk vs reward feeling when going for secondary valuables.


Dev Diary - Project 3: The Second Playtest

By the second playtest on Wednesday, the game had many improvements. The accomplice route was fixed/improved upon and many of the smaller bugs to do with guards and UI were fixed. For this playtest, we wanted to know if the planning phase had enough information and clarity for the player to know how to accomplice the level. 

Some of the improvements we added in from the first playtest were: tapping on distractions cause a radius of effect to pop up, and the entry/exit tiles "pop", to get the player's attention.

After the testers finished the level/s, they went to answer the questionnaire. It asked such things as: What elements did you observe during the planning phase? Do you feel that the planning phase prepared you enough for the execution phase? How clustered was the planning phase?

Overall, around 2/3 of the testers agreed that the planning phase prepared them enough for the execution phase, with the screen not being that clustered. One of the main concerns was the testers did not really remember the guard patrols and sitting there in the planning phase watching, was quite boring. So we added in a faint red line for each guard, displaying their patrol route. This game the testers more clarity of where exactly each guard moved and even if they're in range of distractions.

The problem though, is that the screen started to become to clustered. We were still planning on adding in a particle effect for the primary valuable since that is what's needed to complete the level, yet with that done, the planning phase looked like a mess. Guard vision cones/patrol lines, entry/exit tiles, distractions and now the primary valuable made the screen hard to read. An idea was that the guard vision cones were only visible when the player was holding down on that guard.

This was perfect. Not only did it reduce the screen cluster in the planning phase, but it gave the player something else to do in the execution phase. They now have to control both: tapping on distractions and tapping on guards to look at vision cones.

At the end of the day, the planning phase of the game changed. The screen became less clustered, guard movement became more precise visible to the player, and the execution phase was given a new mechanic for the player to play with.