Alien Burger Maker

You are a chef in an alien burger restaurant. Make odd and unique burgers for the hungry aliens before the destruction of their planet.

Developed: June 2018 - August 2018

My Role: Project Lead, Designer, Programmer

Type: University Project

DESIGN DECISIONS AND PROCESSES

Alien Burger Maker, was a game we made for Liminal VR. They make short experiences to create certain emotions. For this project, we were told to make an energising experience. Something that people can play to make them feel pumped and ready for their day.

This was done through a number of different ways.

Gameplay

  • With the ingredients falling constantly, the player is always grabbing them and serving burgers to the aliens.
  • The addition of needing to squirt sauce onto burgers and add the top bun, encourages movement of the arm.

Progression

  • The game has more and more customers come to the window at once as the game continues on, increasing the speed and multitasking that the player has to do.
  • Ingredients spawn and fall faster as the game progresses, emphasising the speed.
  • At the end, the game finishes off with a grand finale. The restaurant launches into the air, drills through the planet and then watches it as it explodes.

Theme

  • The game has a wacky/abstract/hyper-realistic theme to it. This takes the player out of the world they know and puts them into one with different rules and unknown expectations.
  • It's a very colourful game. With the aliens, ingredients, environment, etc. This is a very saturated and fun game to look at.

Nesting Instinct

During an ongoing storm, you (a flying squirrel) and your babies have taken shelter in the nest. Although as the storm continues, your babies grow hungry. In order to feed them you must go outside into the storm.

Developed: April 2018 - May 2018

My Role: Project Lead, Designer

Type: University Project

DESIGN DECISIONS AND PROCESSES

Nesting Instinct, was a university group project based around the idea of home. The game presents home as a place of safety, yet requiring the player to leave their comfort zone in order to feed their flying-squirrel babies.

There are 2 distinct areas in the game. The nest and the outside. The nest is calm and warm, while outside is dark, cold and daunting. There were various different ways these 2 feelings were accomplished.

Nest

  • Soft, orange colours to emphasise that this is a warm place.
  • No ambient storm noises, just calm guitar music.

Outside

  • No music, just ambient wind, rain and thunder noises.
  • A dark purple atmosphere, with stark lighting.
  • Dark fog covering the ground, with red eyes fading in and out to give the player a sense of being watched.
  • An ominous, red moon.
  • Snakes hiding in some trees, which puts the player on their toes.

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

DESIGN DECISIONS AND PROCESS

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.

Capture.PNG

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.

Capture.PNG

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.

5.PNG
 
2.PNG

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

3.PNG

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.

download.png

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.

LeCAHQ.png

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.

Capture.PNG

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.

Capture.PNG

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.

111.PNG

For the music creation, I used Bosca Ceoil. An itch.io 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.

giff33333.gif

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.

1.PNG

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

1.png

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.

Tags
{
    "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.

[ExecuteInEditMode]
public class SpriteOutline : MonoBehaviour 
{
    public Color colour = Color.white;
    private SpriteRenderer sr;

    void OnEnable ()
    {
        sr = GetComponent<SpriteRenderer>();
        UpdateOutline(true);
    }

    void OnDisable ()
    {
        UpdateOutline(false);
    }

    void Update ()
    {
        UpdateOutline(true);
    }

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

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

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.

References

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.

 
1.PNG

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.

3.PNG

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

t1.PNG

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

t2.PNG

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

t5.PNG

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.