Gone Crab has been completely released to the public and was quite the success. There are a lot of lessons I have learnt from this project and our success’s and mistakes. If you would like to play Gone Crab the itch link can be found here.

Gone Crab is a game that was built on the premise of “home”, or more specifically what home means to us (the creators). Our group decided to use the idea of a hermit crab needing to find larger shells due to outgrowing their smaller ones. We went with this because all of our members have had experiences with moving houses a lot during our childhoods so it was easier for us to achieve this experience. In Gone Crab the player will control a hermit crab around a tropical beach and must continuously find a new shell before they outgrow their current one. If the player has no shell they will fry in the sun and will be burnt to a crisp.

What Went Right?

1. Planning

The initial concept of this project was very clever and because of this there was a lot of momentum right from the start. The team was very on board with the project and we all had an idea of what our roles were going to be throughout the project. All of us had sufficient experience with source control and also Hack’n’Plan which is that platform we used for task allocation.

The designers got to work on the game design document in the very first days of the project, soon followed by an art bible. Our programmer made a technical design document for us as well which I was not expecting but it was very detailed and informative so we worked with it. Because of the amount of planning and reference documents that were available before starting to put it together, it was more efficient for time than without them. This also made it easier to communicate to the collaborators our intentions and thus resulted in consistent visuals that do not appear to be third party sourced assets.

We never came across something that we could not add with the exception of time limits. By prioritizing the tasks that needed to be done, we made sure that by the end date the most important things would be in place. By staying consistent and active on a communication platform and a project planning platform it can help get someone in the mindset of a work space and allocate more time to the project than to leisurely activities. This helped with time management because every time something popped up, I would just work on it rather than putting aside and having to plan for it later.

2. Collaboration

Animation and audio students were needed right from the start of the project. Pitches were held to their respective classes within the first week of the project. The pitch managed to gather 10 animation student and of those 10, 8 stuck with the project and made assets for us. Further down the road we managed to pick up 2 audio collaborators and a graphic designer. Overall the communication was really good between us developers and the collaborators. I was not running as the external talent liaison but I did sit in on one of the meetings and saw how it was being handled.

Fig 1. Collaborator Assets

It is mostly thanks to the collaborators and those managing the relationship that we have such high quality assets that fit really well with the game. Also due to the large amount of reference material along side the consistent communication, the collaborators definitely provided us with the assets we needed.

3. Polish

This project was scoped very large because we wanted to push our limits. The mechanics were rather basic and the overall concept was not complex, but the visual style and quality of assets expectations were high. Because of this we could assure that the core game would definitely be there and most of the final polish work would be visual improvements and because of this we could just stop when we run out of time without having to worry about missing functions.

Fig 2. Capturing the vibrant visuals

Even though we planned well for it, there were a few things that I was excited to implement but we later did not have time for. This includes things such as particle effects for the sands and the flocking for smaller soldier crabs, mainly small additions to make the space feel more alive.

What Went Wrong?

1. Roles in the final stretch

When the project was nearing completion there were fewer and fewer tasks that needed to be completed. Obviously this is good, it means we planned accordingly but because we had all worked full throttle through the first half of the project, production started slowing for the second half. This is just from being burnt out and the amount of work done in the first half made up for the lack of work in the latter half.

We could have added all of the extra work we missed if we had continued going full throttle but I don’t think it’s anything to worry about. We made it a lot further than I thought we would and planned accordingly. In the future I think it will be worth looking at how the work can be more stretched over the projects period so that the members don’t get burnt out.

Conclusion

Overall I think Gone Crab was a great success and helped me learn a lot of things I was unsure about and also showed me things I never thought of before hand. Because some of my previous group work has been not as successful I was confused on why things didn’t go so smoothly. Now after being with a really well managed team I can tell how to act as a designer in a small studio.

Throughout this studio I have been focusing more on how to better myself as a team member rather than focusing on my tool skills. Naturally when working on these projects I would slowly learn new things about Unity and other programs that I used so I didn’t have to worry about falling behind. After really applying myself to a group that had a very appealing premise and participating with all of the work, I feel more comfortable with group work than I did previously.

I have also gained more confidence in some designer specific areas such as my level design skills. Previously I had been very evasive on anything to do with level design but after this game I have realized more so the extent of level design. This is first project I have worked on that had a concept that would not usually appeal to me and turned out to be enjoyable to work on. Now that I have worked on Gone Crab I think I will approach other game opportunities more openly than I previously did.

In Gone Crab we did not initially intend for there to be a narrative aspect of the game, but we later found out through testing that people were struggling to get the grasp of the game without any context. For the most part our game was very relatable because it was about a crab in a beach environment, we could assume that most player’s will have experienced a beach or have seen a similar theme in other media. The main things we were having issues communicating to the player is their goal and the shell mechanics. We needed a way for the player to load up the game and immediately see their goal and also realize that they are not big enough to activate the event and would need to grow in order to complete the game. We also needed a way for the player to be notified of a shells size and what the different sizes meant for the player.

Fig 1. Showing the player their goal

Because of these reasons we opted to implement a simple dialogue system that would convey the player characters thoughts to the player. When the player tries to activate the end event the game will check the players size. If they are not large enough the player will be shown some dialogue of the character acting scared and intimidated of the larger crabs. The larger crabs guarding the goal also have an animation that is comparable to getting flipped off. This was not something we asked for but we figured it was a good idea to have the crabs seem more intimidating to justify why they are not approachable.

Fig 2. References of scale & demo of beach elements

Some elements that were added later in development include the beach balls, seagulls and the cans seen scattered around the beach. At first the cans were randomly spawned in at a random size but we later found out through testing that cans should be a constant size so that the player can use them as a point of reference for their current size/progress. The beach balls are used as a filler mechanic for the player to fiddle around with on their journey so they don’t feel like they are constantly bee lining to their destination without doing much else. The seagulls were used to compliment the tropical beach feeling of the environment along side the cans and beach balls. Given these three additions it makes it a lot easier for the players to relate to the space because it adds a sense of life to the area with human related items and other wildlife.

Fig 3. Shell tutorial

The shell mechanic was the core element of the game and was required to convey the meaning the most. Many of our playtesters said that they could notice the growth of the character, and those who didn’t would still find out later in the game either by coming across the cans or retracing their steps and seeing the size difference. Because of this players could also tell that the shells would not grow with the player and are being outgrown due to the outline around the shell. This allowed the message of outgrowing a home and having to move on to the next to shine through just as we intended. Of course not everyone is accustomed to our games controls so we needed a way to communicate this to the player. We used a fast pop up animation with a controller image displaying what the buttons do. The reason we went with this method is because it is fast and gets to the point so that it does not frustrate the player. Also using a stylized controller just as we have done makes the game seem less serious and further compliments the light hearted feel of the game.

In our fourth project we were tasked with using analytics so that we could learn how to better ask for feedback from play testers. We have previously used questionnaires to get feedback from play testers so that we could better think of how to improve the game. Our programmer was confident with his abilities and opted to make custom analytics rather than using Unity’s built in feature.

Fig 1. Analytics Data

There were two types of information that we were looking for, chunk data and overall data. The chunk data would be information that is recorded every set amount of time, the overall data would just be the information received at the end of each play through. Most of the analytics data we were aiming for was in relation to the procedural generation since we are using procedural generation for shell placement and environmental objects placement.

In the overall data area we were storing the length of a play session, whether or not the player finished the level, how many shells were collected (including values for each size of shell), how many times the player broke their shell from falling, how many times the player outgrew their shell and the total amount of time spent without a shell. Using this information we were able to determine if the player was finding enough shells that were the correct size for them at the time and also if the player was having trouble understanding the fall damage and outgrow mechanic. It also let us see if players were more likely to keep a shell until it breaks or if they pick up a new shell at every chance they get.

This would help us determine the rate of progression for the shells because if players stick to the same shell then they tend to keep walking and not wander around the same area too much meaning they would often get too far ahead of their recommended area. On the other hand, if the player is always changing their shell, they spend more time wandering around the earlier areas and sometimes end up falling behind the recommended area for their size. After testing we found it was more likely for people to stick to the earlier areas, this was thanks to using nice visuals and other quirky mechanics that the player would stop and enjoy before continuing on with their progression.

For the chunk data we were storing the players position on the X and Z axes, their current shell size and the number of shells they have lost up until this point. These values were mainly used to further the points mentioned for the overall data. The position data would help us see how consistent the progression was and making sure players weren’t getting stuck or reaching out of bounds areas. We found that many players would be getting to the later areas and be waiting around a lot because the growth rate was not scaling with the player’s current size. We also found that after finding the largest shell on the beach, the player would need to wait a while before they could finish the game. This was because in order to obtain a shell the player needs to be at least 70% of its size, this means that when collecting a size 10 shell the player only needs to be size 7. But with the end event the player needs to be a specific size which was set to 11. This means the size difference between the largest shell and the end point was size 7 to 11, we fixed this by lowering the size requirement of the end event.

So we are going into our fourth project for Studio 2, this game must be based off the meaning of ‘home’ and more so what does home mean to us. This project will involve teams of 4, 2 of which are designers and the other 2 are programmers just like in Studio 1. This is good because the previous projects were either solo designer or a team of designers, so having programmers will mean we can scope a bit bigger.

One of the members had a really clever idea on how we could interpret that meaning of home in a game. The idea is that you play as a hermit crab from a third person perspective (similar to the player view in Crash Bandicoot (date)) and has to find new shells before they outgrow their current shell. The player can wonder around a secret little tropical beach filled with rocks, palm trees, shells, a lot of water and a whole lot of sand. For the visual aesthetic we are aiming for a carefree, tropical beach that can really make the player feel like they are in a paradise they can quickly call home.

Fig 1. Adorable hermit crab

Fig 2. Crabs Bandicoot

Their goal is to increase in size so that they can stand up to some bigger crabs that won’t let them get to a small boat. When a player has a home (shell) equipped they will grow in scale, if they get too big for their shell it will pop off. Without a shell the player will cook in the sun rays and must find a new shell before they sizzle away. New shells will be procedurally generated on the terrain and on the rocks around the player based on their current scale.

For the environment we have a handcrafted space including a sand terrain and some rocky cliffs around the sides. We will have rocks, shells and other items such as nature and more human items filled in with procedural generation. The environment won’t generate completely random, we’ve desired to go half and half on the level design. We will use trigger areas that we can modify in the Unity editor and will spawn the desired items in that area. This allows us to choose where we want each item to be generated so that there is still some reason behind the space rather than complete randomization.

Fig 3. Uncharted 4

Fig 4. Unknown Beach

Currently we have this example level that gives an idea of how big the level will be and how we are planning to go about layout. We also have an idea of what the player’s critical path is going to be since we can lure the player around with different sized shells.

Fig 5. Test level

Fig 6. Planned critical path

I have high hopes for Gone Crab, we have a great team that can really push this project to it’s potential. Although the end polish will heavily rely on visual work which I’m not as experienced at, any visual effect experience I can get is more than welcome.

I’m taking a minute to reflect on the project management (or lack thereof) in the third project known as Breathe. Before going on, it might be worth checking out my post-mortem for this project here so I don’t have to repeat what I have already said.

Breathe was not the most well managed project through fault of the whole team, and because of this it was difficult for each of us to schedule accordingly. This ended up making the overall work more compressed than it needed to be and also limited the quality of the final product. Breaking up tasks is so very essential to proper project management and sometimes people life myself need to learn the hard way before actively applying it to projects.

The start of the project was managed pretty well, we had a Hack’n’Plan setup with tasks allocated. But after the second week we stopped using it and this caused us to be at a loss of where the project was. I took the initiative and started working on the project without any allocated tasks. This was both good and bad, it was good because work was getting done, it was bad because only 1 person was working and the rest of the team was kept in the dark (outside of other communication platforms which we were all actively participating in). In retrospect the best solution for our problem would have been to talk to the team to get the Hack’n’Plan up and running again. Because 1 person took the initiative, the others did not know what that person was doing and what they needed to do as well.

We are already into the fourth project and the management is already way beyond the third projects. It feels like there are always tasks for myself and others at all times and I don’t feel like my contribution is too little. Moving forward in project 4 I want to help maintain the great management that is going and also start using proper scheduling again since I lost the habit after doing so many solo projects. Other than using Hack’n’Plan and my scheduling methods, having well written and organized documentation can really help the team realize what needs to be done and how to do it. In project 4 we already have most of our documentation done (GDD, LDD, Art Bible, etc.), in comparison to project 3 where we really only had a game design document which made it difficult to execute a vision we didn’t fully understand.

Over the last 4 weeks I have been working in a team for a client to create a music-video video-game as our third project in Studio 2. Our client had asked for an auto-walking simulator for his folk music composition which was heavily based on player interpretation. Since then the game has been finished and there’s a lot to take in from what happened. The itch page for this game can be found here, it is a HTML game so it can be played in your browser.

Fig 1. Breathe cover

The game involves the player character walking down a straight path, the player can not alter their speed or movement. The player can interact with certain environmental objects to cause small events similar to the way Hearthstone handles their battlefield clickables. When approaching a junction the player can click on the sign to choose a direction or leave it to have one selected at random. There will be new areas after each junction for the player to explore meaning a total of 5 areas will be explored on each play through. The first and last area are the same on every play through, but every area in between has a choice pool of 2. This means there are 8 areas at total to explore including the first and last one. The game is themed around Christianity just like the song and is trying to convey the meaning of ‘finding god’.

What Went Right?

1. Problem Solving

There were a lot of tasks that I walked into not knowing how to do. Some of the most notable areas include project management, tool skills, design challenges, technical challenges and source control. The horizon bending tool that was used on this project caused an array of issues due to its complexity. While trying to find solutions for these issues I was able to learn the horizon bending effect and also a bit of shader stuff. Whenever a problem came up in this project, it was more a question of what colour of duct tape I use instead of worrying about how hard it is to fix. It’s not in my best interest to act like this towards all issues, but I think weighing the odds is the best way to determine the right choice.

2. Expanding on tool skills

This project required tools and systems that I was not as familiar with before this project, because of that I was able to learn about those tools and make me more confident about doing that sort of work. One of those tools is Unity, I have been using the unity editor since the start of my degree over a year ago and have always been getting more comfortable with it. But there were some areas of unity that I either avoid or haven’t been introduced to yet.

I was able to apply myself to a new tool that I did not know about, it’s called world bending and it was one of the core features of the game. The rest of the game needed to be formed around this feature because it was already part of the project in the first days of its development. I have another blog post going over what it does and the challenges I experienced while using the tool here.

Fig 2. Horizon Bending

I have a better understanding of particle systems and lighting settings in Unity. I have used the particle system very sparingly over my projects because I can never get the right effect without it looking like a Unity particle effect. During this project I started using my own textures on the particle effect rather than the Unity default one and I realized how much more unique I could make my games look.

Fig 3. Leaf particle effect

I have also been looking into Unity’s project settings more and figuring out how modifying the graphics settings can be beneficial to the project. This project was built and produced for WebGL and because of that we ran into a lot of performance issues related to lighting and the tools we were using. Because we were using multiple light sources in a scene we needed to up the amount of lights that can be rendered, and at the same time reduce the rest of the graphics to account for it. There were other issues related to the horizon bending tool such as draw distance and such which required tampering with the tool itself and Unity’s settings.

Unity quality options

Unity graphics options

Unity lighting options

Fig 4. Unity options

Animation is something I have always been fond of, but have never been ready to take the dive into. I had to make some very basic animations for this project and was able to refresh my skills in this area. I can’t make anything notable or enough to justifying not getting animators on board in future projects, but this is a good start to build on this skill so that I can start making more unique animations in my side projects . For this project I made a simple leaf falling animation in Blender, this animation would be mixed in with a particle system so I made a simple leaf model and animated 4 of them to get the intended effect. I think I’m at a points where I should just play around with Blender more instead of only using it when I’m needed to. That way I can start to make things I am more interested in and learn how to make proper animations.

Fig 5. Leaf animation

What Went Wrong?

1. Planning

Time management and planning were my biggest problems during this project. Because all of our previous projects during this trimester have been solo, I was not using proper time management or planning during them. This reflected on my ability to act as a team player and to be scheduled during project 3 since it’s a habit I should always be working on even in solo work.

The project overall was poorly managed at the fault of the whole team. Due to the constant unfamiliar tasks and lack of motivation, it was difficult for us to try and manage ourselves together and plan out the project properly.

2. Lack of Collaborators

From the start we thought that the project would be easy going, not too many difficult tasks to do. But once we tried to execute the idea, we figured out that it would not be as easy as we though. We were offered to meet up with outside collaborators but at the time we still thought we did not need any external help. It became apparent about half way through that the project would be better off with animators that could make us custom models and animations. Instead we found ourselves using sourced assets from the Unity asset store.

This overall meant that the game looked very unpolished and very much a ‘student project’. I think that if we could have changed anything about this project up until now, it would be to get animators on board.

3. Concept

So the clients concept was very good when we heard it and we were all immediately on board at the time. After a few days, we realized that the idea was a lot more complicated than we thought and that the way the client wanted the game was not something we were comfortable in creating. In short, the idea was to have everything up to player interpretation which we thought was fine.

The issue with this is that us as designers would have no intended experience to work towards, no common goal that every element of the game would be trying to achieve. After sorting out that issue by explaining that there was some issues with his concept, we were able to get it back on track for the most part. In retrospect I think the concept was something that the teams skill sets were not suited for and while that restricted our productivity it also allowed for a lot of new things to learn as stated in the “what went right” areas.

Conclusion

Overall I think that I had a large amount of work put into this project. Over the past projects I have notice my quality of work and commitment to each project getting stronger and stronger. That is definitely apparent in this one to me because I was able to put in so much work. It got overbearing at times due to the lack of planning and skillset but we made do with what we had.

Now I am more confident in my abilities using tools such and Unity, Blender and other visual features I have used along the way. I am also more confident in my ability to solve problems and finding the right solution for the task when needed. Because of this I would like to dive more into solo projects and try to create small interesting prototypes that I find entertaining in order to get more experience. Along with this I would also like to start scheduling myself properly and using tools such as Hack’n’Plan more frequently.

I will also be looking into getting more collaborators on board with future projects. As we start getting more and more into the professional field of game development I have found that creating our own assets and using online resources can be detrimental to the product. Having professionals in their own areas do asset creation is a lot more beneficial to the game and is an important habit to get into.

I made an interaction event for shaking a tree when the player clicks on them in project Breathe. Previously we have had a placeholder event that simply changes the trees material colour so that people knew what the interactions in the game would be like. We needed an actual animation or particle effect that would convey to the player that the tree is being shaken. I decided to use a simple animation that would cause 4 leaf models to fall to the ground and rotate as well. This would give the animation a feeling of tangibility since the leaves would stay present on the floor at the end of the event. I also decided to include a particle effect that would fill in the empty space. Because the animation only has 4 leafs it feels bare and empty, using the particle effect helps complete the event without needing high resource or performance costs.

I begun by modeling a simple leaf in Blender that I could use to make the animation also in Blender. I didn’t go too in depth with the model because it does not require a high level of detail. I just used a cube, scaled it down to size, subdivided it, cut out the corners using the knife tool and then triangulated the faces so that there were no polygons with more than 3 sides. Unity does this automatically but I find that it is good practice to triangulate self made models before exporting.

Fig 1. Blender leaf model

I then did the animation for the leaves falling from a set height in Blender. This was my first time using this program to create animations but it was very straight forward. I looked at a few tutorials on YouTube and also looked for advice from online forums throughout the process. To begin I made the leaf move away from the center point with a rotation so that it would appear to be pushed out of the tree by force. The leaf would then move downward in a curved line with a rotation to make it feel weightless.

Fig 2. Blender leaf animation

Next I made the particle effect that would be used to fill in the empty space. I watched a YouTube video on how someone made a falling leaves effect to jog my memory on particle effects. I made a very simple leaf image that looks similar to the model and had a matching colour and applied it to a particle effect emitter. I then went in and tweaked the variable on the particle emitter to get the desired effect. I made it so that the leaves had some gravity applied to them to make them feel weightless similar to the animation because they would fall down in a curved line. I also made the particles have a random rotation over time so they would feel more natural and diverse.

Fig 3. Leaf particle effect

Fig 4, Particle effect variables

After tweaking the basic emitter shape, size, speed and lifetime I put the animation and particle effect together on the tree model to see what it looked like. There were some minor tweaks to be made on the particle effect but overall I am satisfied with the outcome. Here is a gif of the finalized tree interaction event.

Fig 5. Tree interaction event

Breathe has come quite a way since I last wrote about the progress of the game itself. During this week and last week I have done a lot of work on the game that was able to further the game towards the vision and also remove the blockers that have been present. Some of the issues that needed attention include:

• Unity’s skybox feature did not work with the Horizon Bending effect due to the angle of the player’s view.
• Using standard raycasting within Unity was causing undesired effects due to the Horizon Bending effect.
• Using spotlights with the Horizon Bending effect also caused undesired effects.
• Because all of the gameplay takes place in a single scene, we needed a system that could change the time of day and weather based on what area the player is in.
• The current player input required for choosing a path was not designed with the player’s experience in mind and was causing confusion.

Because many of the issues during this project have been related to the Horizon Bending asset made by Andriyanov, A. (2016a), I have been able to learn a lot about how it works while trying to fix said issues. Before going on about how I fixed the above issues I’ll explain how the effect works as simple as possible so it’s easier to understand the solutions. So what the effect does is modifies the shader of an object so that it appears to be bent. A misconception about the effect is that it bends the whole world, this is not entirely true. All of the objects that have the bend applied to them do not change position at all, they just appear to be in a different position because only their shader is being modified. This means that anything that does not have a material on it does not appear to be bent, this includes colliders and spotlights in this projects case.

Fig 1. How Horizon Bending works

One of the more urgent issues is that the skybox in Unity is locked to 90 degree rotations, and because of the Horizon Bending the player’s view is looking straight into the bottom corner of the skybox. We needed a way to have a custom background that acts as the sky.

Fig 2. Demo of how the player only sees the bottom of the skybox rather than the horizon (Top – Editor perspective, Bottom – Player perspective)

I did this by making a quad and stretched it so that it filled in the entire background so that I could just place a texture on it and it would appear to be a static skybox. Because the player has no control of the cameras rotation, having an entire skybox is not necessary. With this new addition I have ingeniously named “SkyPlane” (which is probably copyrighted) we can change the background at will through very basic code.

Fig 3. What the skyplane looks like

Fig 4. How the player sees the background

The next issue is related to the Horizon Bending is the raycasting, as I mentioned earlier the colliders of objects do not actually change position with the bend. So where the object appears and where the collider is do not match. Because in our game the player must click on these object for the interactions to take place, we are using Camera.ScreenPointToRay which casts a ray from the camera to a point on the screen, and in out case the point on the screen is the mouse position. Luckily the Horizon Bending asset is more complex than we initially anticipated and it has an inbuilt function to handle this issue. There is a custom raycast function within the Horizon Bending asset that sends the raycast to the objects actual point in space, rather than where it appears to be. I’m not a programmer so I can’t say exactly how this works by reading the code, but basically if the player is casting a ray through the ground where the object appears to be, it moves the raycast to be along the horizon where the object actually is.

Fig 5. How the HBRaycast works. Andriyanov, A (2016b)

One of the environmental interactions that we had planned is the turning on and off of street lights in a dark night area. Getting the lamp to turn on and off using a spotlight and changing the bulbs material to be an emission was quite simple. The problem was with the Horizon Bending, again because light sources are not shaded objects, they are not affected by the base effect. But thankfully enough there is also an inbuilt function for this issue that positions the lights according to the bend. I could not figure out how it works at first because the documentation for the Horizon Bending effect did not explain it very well. When applying the necessary script to the light, it would create an empty object and make the spotlight a child of it. I did not know why it did this, so I zeroed the new empty game object in local space and set the spotlights position to be what I wanted. This didn’t work because what it actually wants is for the empty object to be at the location you want the spotlight to be and the spotlights location to be zeroed. I would assume that the spotlights local position needs to be zeroed in its local space because of how the script works. Below is an example of how the lights act without the in built script versus with them. Notice how the lights in the top gif do not bend with the rest of the world whereas the lights in the bottom gif do (the spotlights are the yellow cones).

Fig 6. Standard spotlights on the Horizon Bending

Fig 7. Spotlights with the light fix script on the Horizon Bending

The game is meant to have different weather/time of day for each area the player travels through. But because it is all in one scene, we needed a system that can handle the changing of lighting as well as the background. Thanks to the SkyPlane, changing the background is a piece of cake and changing lighting through script is fairly simple as well. But I needed a system to make it all work. This system has already gone through a few iterations to make it easier to modify in the editor. Basically at the start of the game or when a new area is spawned, the game controller checks to see what the weather is in the new area and sets the current weather to be that. There are 3 lighting variables that need to be modified, the ambient lighting, the main directional light that lights the scene and the directional light that lights the SkyPlane. Here’s a screenshot of how it looks in the editor:

Fig 8. Screenshot of the GameController script in Unity

Lastly I changed the way that the player chooses a path when arriving at a junction. Previously the player would need to hold down a direction (A or D / left arrow or right arrow) when in the junction trigger. If the player had not chosen before exiting the trigger, it would choose at random. The input for this method was confusing for the player because there is no indication for when they need to hold a directional key or when they have chosen. As well as there being no use for using key inputs since the game is already using mouse raycasting for environmental interactions. We decided to make it so that the player can click on an object in order to determine their choice. I used a junction sign that has 2 arrows on them, when the player hovers their mouse over an arrow the cursor will change to an arrow so they know what they are about to select. The game is still using the junction trigger that chooses at random if the player doesn’t choose in time. This will stay in the game because the game must be completed in a certain amount of time to sync with the song, so player does not even need to interact with the world in order to complete the game. It’s a music-video video-game, the video game part is optional.

The project is really coming together nicely, going down the more visual and atmospheric approach rather than focusing on elaborate mechanics was the right decision for the game. Here’s a gif of the new rainy area we just implemented!

Fig 9. A nice gif showing off the new rain area!

Bibliography:

Andriyanov, A. (2016a). Horizon Bending. [Unity Asset Store asset]. Retrieved 15 March 2017, from https://www.assetstore.unity3d.com/en/#!/content/55306

Andriyanov, A (2016b). Horizon Bending Documentation. [PDF file]. Retrieved 15 March 2017, from http://battlehub.net/HorizonBend/HB.pdf

So we are 2 weeks into our third project and a lot has happened in terms of progress and challenges. Because we are working for a client, we don’t have as much creative freedom that we have had with previous projects. This has made some challenges that we did not account for. The initial momentum at the beginning of this project was really good, I explained in earlier blog posts that our client already had a firm grasp on the concept and how that helped us early on. Some issues related to this is that he is not a games designer, so naturally there were some gaps in his idea that only surfaced after we did an internal pitch to the class. Because of this our team has struggled to find a direction for the project because the clients vision is very basic from a technical point of view. But this also allows us to focus more on the visuals and atmosphere of the world which is something I started to realize this week.

Another thing that has been an issue is the lack of motivation in the team. Because we are working for a client, we have to make the game they want. While we were very on board with the concept when he proposed it to us, after trying to execute the idea, we found that we were not as into the idea as we first thought. Speaking for myself only here, even though the project may not be as appealing as I first though, I still feel obliged to create a quality product for our client. This is both because he came to us seeking a product so I don’t want to let him down, but also because this will have my name on it so I want to make sure it’s the best it can be.

Further more, another issue that became apparent is the different skills the members have and also lack there of. So going into any group work, there is always the possibility of members who lack skill in important areas. There has been some issues with source control which has led to a lot of the assets to be created outside of the source projects and imported via Unity packages. This has been working fairly well for the most part, it’s definitely easier than teaching someone how to use SourceTree. But it’s still creating some issues that is taking time to fix, time that could be used else where…

Fig 1. Some issues with source control or lack thereof

Leading on from my last point, because there are certain areas that some of us are less prominent in there is much more to learn! I have learnt ways of doing things that may seem unorthodox to a professional, but produce the intended outcome as needed. Particularly stuff such as lighting, skyboxes and animations where we only need a very simple outcome that does not work within the programs we use.

Fig 4. How the player sees the background

Fig 3. What the skyplane looks like

Overall the experience of working with a client has been rather smooth. This isn’t the first time I have done client work in a team, but it is the first time doing it at this level and scale. Our client is very optimistic about the whole project and is always pleased with the progress of the project when he checks in on it.

To further the development of our Project 3 game, we have been tasked with researching other audio driven games and looking at how we can enhance our games experience via sound. Because the song my team is working with is very light and slow paced, we are trying to avoid any jarring effects used in electronic music, rock, metal etc.

Fig 2. Remembering

Fig 3. Proteus

A game I found called Remembering is an artistic game using sound to determine the atmosphere. It is very similar to the game Proteus in how it enhances the atmosphere via sound. These two games are the most relatable to my current project because they are not heavily based on game play mechanics, instead they have created a living world that can be experienced without interaction if the player chooses. These worlds can be explored by the player but they ultimately have a destination if they wish to progress the game. The use of weather and atmospheric effects in relation to the sound creates a sensation I have only found in these games.

Fig 4. Inside

One of the games I chose is INSIDE, this game is by the same developers as the widely known game Limbo and puts the player in the shoes of an individual living in a dystopian world. It is a 2.5D platformer with very fluid animations, a beautiful atmosphere and dark and mysterious colour palette. This one doesn’t really fit into the ‘Music Video Game’ category but it is very unique in its way of using audio to drive its gameplay. There is one part of the game where the player must avoid large sonic waves by using the environment. From a technical point of view it’s very simple, if the player is behind cover when the sonic wave passes, they live, if not, then they are thrown off of the platform to their death.

For project Breathe I am going to focus more on atmospheric effects that enhances the players experience visually rather than through interaction much like Remembering and Proteus. It’s unfortunate that mechanics such as the ones in INSIDE cannot be used in our project due to the visions limitations. Something that can be taken away from INSIDE though is the consistency in the sound and how that is communicated through the mechanics. Our music is consistent and does not vary outside of layering unlike the first 2 mentioned games which have very obscure and non-musical-like sounds.