Final Week Video Blog and Critical Analysis

Critical Analysis

Now coming to the end of this semester I realise how I should have done a lot of things differently and I am very disheartened with the final outcomes. I’m willing to admit that I did a lot of things wrong and feel it necessary to reflect on those. However though, I will start on the areas which I believed I did right.

The first area of recognition was teamwork. I chose to work in a team with Syl as we had done so the previous year and that partial teamwork had worked well. In the early stages, we worked efficiently in flushing out a fully fledged idea from her previous semester’s work and combining our skills in critical thinking, idea generation and concept art to enhance the idea to something more than just your average 2D-platformer. I was very proud that I was able to hop on someone else’s idea in a short space of time and generate more than enough ideas.

One of my semester’s goals was to learn the practice, then make the music score for the game. I had no previous musical experience and there is a lot to consider when producing musically electronically. I do have to give credit to a friend who helped me set up Logic Pro X and showed me the basics on using software instruments and samples. But, the bulk of the tracks I produced on my own with the same friend then helping me finish and master them. I was extremely happy with how the music sounded and it followed a style is necessary when composing music for a game or another piece of media. I feel that I have gained a valuable skill and it is something that I enjoy a lot and will continue to do past university life.

Having come from absolutely no programming experience before the end of my second year I can say I made progress in my overall knowledge of scripting for unity and the engine. I learnt more about physics and character controllers and at times during the semester found myself lending a hand to others using Unity which also helped me expand my knowledge. Despite the semester not turning out the way I wanted, I feel that I have a good enough knowledge of Unity and scripting so that I can produce games and experiences on my own in my spare time to expand my portfolio for the eventuality of finding an job in the creative industries.

Now to the faults. Testing was the biggest issue I had this semester. I did some testing near the start but didn’t let enough people play it and exploit the bugs of gameplay until eventually I felt it was too late and didn’t want people to do so. I got very wrapped in trying to put together all that what we wanted to do, implement the artwork Syl had created and show the range of skills I had acquired over the semester. I felt at a lot of times I didn’t want people to play it as I became very uninterested in making it after at many points wishing I had worked on my own project. I made a similar game to last year and I seriously felt like history was repeating itself so I debated with myself on why I chose to do this game and not something different and that I wanted to make.The choice was selfless and in the beginning was beneficial to us both but very quickly turned sour for me.

Looking back it seems I had a problem with admitting failure. A lot of the others were open about their hardships and errors and a lot of the time found help for when things weren’t going their way. However, I was not the same. As I was one with the most coding knowledge I felt like a lot of people expected more from me and I let that get in the way of creating a fun, interesting game where gameplay and not visuals were the focus. A lot of the time the game was broken and I didn’t want to admit it and I told myself to ‘do it later’ but as tasks and stress were piling up I lost sight of the goals we started with and how to reach them. I feel that I put a lot of hours into this semester with little payout which is the most disheartening aspect. I felt that I have let Syl down as I was the one who agreed to produce the game with her. But, I see life as one big learning curve and despite the fact that I made many mistakes and it hasn’t gone as planned, I did all I can and I know what mistakes not to make when making games in the future.

I’m back! – Video Blog and Review

Below is a video blog of the past couple weeks of work and some review of how my work is going so far:


I would be lying if I say these past few weeks have been a struggle. Since the last blog, I had put a lot of time into working on the game and fixing bugs that had been nagging me for weeks. I had very little break times and was spending more than 8 hours a day easily either in the studio or at the library working on development. Then came a Friday tutorial that acted as a testing day and the gameplay for Isiko got ripped apart essentially and left me feeling completely uninterested in finishing the game. First breakdown of the year as it goes. But, I had the weekend off and came back with a better outlook on the project. I started with smoothing out the gameplay and working on the major flaws, which since then have come along really well and there isn’t a lot more for me to sort in terms of gameplay. It will just now consist of UI, Music/Sound effects and their implementation and building the game in once piece. There is a lot still to do but I’m confident now we’ll be able to get it done in time and to a great standard.

Next steps

As of writing this, there’s just under two weeks left till hand in, so I need to spread my work load efficiently so we can get this done. Monday and Tuesday of next week I will be having long test sessions. This will be for understanding of the gameplay so we can find out if we need to change any of it throughout, testing the enjoyability of the game to see if we can improve it at any point. I also need to redesign the last level we have built and test the meaningful choice which will be included. The rest of the week will be working on any amendments that we need. I will hopefully too have the music done by then so I will ask the testers about that too and how they think it should feature in the game. By the end of next week I hope to have the gameplay full functional, both character controller and puzzles included by the end of next week so I can then spend the last few days ensuring the levels are built fully so they don’t break. There will be some sleepless nights I’m sure but I’m up for the challenge.

23/04 – Video Blogs and Review

Here are the videos for this week’s development blog:


Despite this being a slightly slow week for myself, there were a few aspects of the game which I had finally worked out and made significant progress with. A few sessions of user testing got me to change the gameplay for the better which has the finalised editions of gameplay looking and feeling a lot better. Artwork from Syl is coming in at fast rates so we have finalised scenes which are full and bug free, so the coming weeks we can concentrate on user testing and the later builds of the game. I finally got the inventory system usage working so there are few game aspects left to add into the build, those being the UI and everything associated with it. But, once they’re put in, user testing and building can be at the forefront of my efforts during the weeks leading up to our hand-in.

16/04 – Video Blogs and Review

Here are the video blogs for this week’s testing, building and development.


I was very pleased with the progress both Syl and I had made with this week’s development. Syl had a big push and made a lot of headway with all the player and NPC animations needed for the game which will soon be put into the game scenes. On my end, I got essential testing and feedback on gameplay so I was able to step back and review the current scenes I have and realise where I had to change them and make them better. There is still a lot to be done for gameplay but it’s in the right direction for it to be inviting and fun. The logic and scripting for the inventory system is done which I had been putting off for some time now. But, now with this done I can focus more on testing the actual gameplay rather than the features in the game. This week the game has become a lot smoother and is moving further towards a final product. On reflection for the week, I could have got more testing done for the latter levels that are currently in development and worked some more on music as this is another area I have been putting off a bit. More exciting content to come next week.


Prototypes: Introducing Floating Custom

The 2nd prototype is yet to be finished as the artwork is still being done for it, so I dived into starting the next prototype introducing the floating custom. Probably a good time to do so as we both still have a lot to do. Yikes.

This next section of Isiko is another introductory level, meaning the mechanics and interactions for it will still be simple enough for the player to understand how the next custom works without getting too frustrated with the game. The previous level had the rock starting the chain of events, but after having a chat with Syl, we decided that the custom will trigger the event as it will be easier for me to create and will be more interactive. My work for this section can be found on pages 14-20 of my sketchbook.

In this scene the game will be introducing a pulley system for the villager to get back to his hut. After which he can open the gate for you to finish the level. The custom will cause a boulder to move down the scene and move the pulley system, working similarly to the previous level so the player will have the knowledge of what to do. The image below shows the final layout of the scene:


The next step was changing the code for the new custom. I already had the scripting and scene set-ups for the custom triggers, so I just moved those around in the scene to new positions. Shown below:

Screen Shot 2018-03-26 at 15.26.06.png

As this custom will be floating upwards I had to change the transform point where the custom will move to when the player presses triangle on the controller. I put them slightly above Isiko so there would be no contact between the two game objects and made small amendments to the code for it to be the floating custom. As I want it to interact with other game objects I had to leave the rigid body on it and change the gravity scale to 0 so it could float up. I then added a simple Vector 2 velocity change in the y axis so it moved up the game scene. The code for this is shown below:

Screen Shot 2018-03-26 at 15.08.25

The next step was introducing the pulley system into the scene. I had yet worked on anything like this so went to the Unity API to see how I would go about doing it. I could have made the ropes that the pulley system used static and then simply moving them up and down but this would have made it look rather boring and unrealistic, so looked into how I could create a rope. I came across hinge joints in the manual which told me this allowed two rigid bodies to be connected together. So, I created an empty game object with a chain of blocks all attached to each other, creating a rope. For the pulley system to then work I worked out I could increase/decrease the size of the blocks using their local scales, moving one down and the other up. So, when the boulder connects with the pulley ‘cart’ one side will increase in size and the other decrease. My notes on this section can be found on pages 31-37 of my ‘coding’ book. The scripting and a video of this test can be found below:

Screen Shot 2018-03-26 at 15.08.42

For the pulley system to return up the scene, I created a separate method that was a reverse of the original, and used a timer to tell the engine when to return the carts to their original position. After the villager returns to his house he will open the gate for Isiko and the level will be complete.


Music Decisions and Creations (1)

A lot of African and tribal research has influenced the game so far so it seems fitting that the music be inspired by that also. But, I will want to have my own style and influence to it, rather than it just be a copy of tribal music. After having had a conversation with Alex Ayling when he visited our studio, we had the idea for Isiko to have two soundtracks to it; one for the game’s pre-scene which will be a fuller soundtrack, and the in-game music which will be very atmospheric and quiet to allow the sound effects to be more apparent. Both being inspired by tribal music.

Up until this point I had yet to study any tribal music so had little idea on its composition and the instruments involved. Alex again came in to talk to us about what we wanted our game music to be, so we sat down and compiled some tests on the composition of tribal music. A lot of the main instruments used (Marimbas, Bongos, Congas, Shakers etc) are usually off beat and less structured in comparison to western music. So, in Logic, we threw together a few tests using sampled tribal instruments to demonstrate how changing compositions can lead to different sounds using the same the same sampled pieces. Below you can find 2 different tests using the same loops and samples and a screenshot of how they were constructed in Logic:

Screen Shot 2018-03-20 at 16.01.36

I then took what I learnt from Alex and began to work on the soundtrack with help from my friend Tom who happens to be a music production student (very handy I know). We started with the basics, composing the kicks and bongos from a tribal music sample pack I had downloaded. Drums are a heavy feature to tribal music so it was important we got this together first so we could then build on it and have a strong base to work from. Below you can see how the drums were comprised:

Screen Shot 2018-03-20 at 16.17.04.png

The next step was to add effects and change EQs so the drums were sounding the best they could. I didn’t understand a lot of what Tom was talking about in regard to effects and EQs so decided to take a few notes for myself so that I can understand them better when I work on the music on my own. The notes for these can be found in the “Music” folder. So, just showing this for the drums, we took a lot of the low end frequencies out so they had less bass to them and altered the top end so they sounded smoother and less harsh, which I wanted for the nature of the game. I won’t go into full detail about all the EQ changes as it might get a little tiresome. But for now you can see an image of how they’re changed in Logic below:

Screen Shot 2018-03-20 at 16.20.29.png

After we had this the way we wanted, it was time to start layering the track with other tribal inspired samples and instruments. Marimbas are one of the most popular instruments in African culture, so decided to a sample of one and convert it into a software instrument so we could play around with its sound and the effects on it more. This then became the main riff to accompany the drums for our track. The sound of the marimbas had a slight resemblance to childhood nursery rhymes, which I think well represented the coming -of-age journey Isiko is on and the excitement/nervousness that comes with facing new experiences in life.

There was a lot of layering to this track, so I won’t explain every single step to it but a lot of improvisation was used for them. After recording a bassline and cymbal rises we wanted to record shakers and claps, which can be found in a lot of tribal music when tribesmen/women play in large groups for ceremonies. So, we used cooking spices and half empty coffee jars for the shakers and created the claps ourselves, this part was especially fun. These sections were also configured using effects and EQs so they fit well with the track. Below you can find a small snippet of what we were working on:





Design meeting (1)

After working on the game for some weeks now, some of the aspects from Syl’s initial design I didn’t think would work for our project. So, we had a small meeting between the two of us so to talk through some ideas we both have.


Above is the notes we had from our brainstorm. They were a lot to do with the building and layout of the game on my side and I will talk through all the ideas and how they will impact the game.

  • Creating a camera zoom / This will allow the player to view the whole game scene when they enter it. They can then use a button to zoom in and out so they can see it all again during the play-through. This will help them visualise the puzzle if they get stuck at any point.
  • Custom points / These will be there to indicate where the customs can be placed down. There will possibly be particle effects to show these areas.
  • Pre-Game Scenes / This will be of a similar style to Cuphead. Isiko can pick up the rock and customs in a pre-game scene then move off into the game. This will allow me to create separate scenes and will allow the game to work smoother than one long game scene.
  • Chapters / The pre-game scene will introduce story of the game, narrated over by the shaman. The Shaman’s narration will also feature as hints in the game scenes if the player can’t figure out what to do after a certain amount of time.

Prototypes: Generating Customs (Part 2)

Now that I have the animations in place for the scene, the ‘machine’ has to be set in place to create the game puzzle. I have the place for the customs set up and the code for them working. So, I just need to create the chain of events that allow the fruit to fall from the tree which completes the level. Below is in an image of the scene I have built in Unity to simulate the level and get my testing under way.

Screen Shot 2018-03-15 at 13.31.50

I placed the fruit in the tree, added a rigid body to it, turned off simulated so it can hang in the tree and created a new script that would allow it to fall. I attached the script to the tree and this is the game object that would be receiving the contact in order to start the chain of events happening. So, when the broken tree is hit by the boulders, it will fall and make contact with the tree, and once that occurs the rigid body of the fruit will activate and fall down to the forest floor, completing the level. The code for this interaction is shown below:

Screen Shot 2018-03-15 at 13.42.04

The next step was creating an event that causes the boulder pile to collapse and push the tree over. I already had the rock grab/throw from the previous scene so just needed to create interactions for the boulders to be broken. I created them in a pile named “Boulder Collection”, gave them all rigid bodies and placed a small stick in front of them on a slope so they wouldn’t move on game start. The stick wedged below them is a small hint to the player to show that they need to throw the rock there in order to start the chain of events. I created a script and added it to the game object “BoulderHold”. It can be found below:

Screen Shot 2018-03-15 at 13.45.08

So, this script will activate when the rock hits stick holding the boulders in place, once the contact happens both game objects will be destroyed causing the boulders to start moving. This is the start of the chain of events and will cause the broken tree to fall on the tree with the fruit on. Due to the positioning of the “BoulderHold”, the player will need to climb back up the ladder and out of the way in order for the event to occur.

The first problem I encountered was the positioning of the custom when placing it down on the movable platform. It caused the platform to move down but then rolled off the edge onto the game floor, meaning it no longer acted as a counterweight, which meant the fruit hit the movable platform and fell off the map (this will be water when art work is in place). To fix this, I gave the platform a polygon collider (instead of edge) so I could manipulate the edges of it. I moved the edge on the far left up slightly past the bounds of the sprite so the custom will stay on the platform. An image showing this is shown below:

Screen Shot 2018-03-15 at 13.54.19

I then ensured the masses of the objects were different and slightly realistic so the events would occur properly. The masses of the objects in order of heaviest to lightest is shown below:

Broken Tree > Custom > Fruit > Boulders

Once these were all in place and all the correct bools were in place in the scripts I ran the level and the fruit was able to fall to the game floor. The video for the test can be found below. All that is left for this prototype is the artwork.


Prototypes: Introducing Customs

Now that I have the introduction to the game tested and working properly in sprite build, it is time to move onto generating more ideas and then prototypes for the next stage. As you will have read in my previous posts, following the game’s introduction, the customs will be introduced individually in a puzzle format that abide by the game rules. So, the first one to be introduced is the counterweight and the player must complete a puzzle using it to progress through the game.

Having spent a lot of time recently on designing the puzzles for the game, generating ideas for this section came more naturally and readily to me. So, I was able to start prototyping in Unity a lot quicker than before. This gave me a lot of confidence moving forward into the next stages of development.

The ideas for this prototype can be found in my ‘Ideas Generation’ Folder in the section ‘Level 1’. For this I looked at previous studies of Rube Goldberg machines, also found in the beginning of my sketchbook, and noted down exactly what I needed for this section of the game. As this is still early sections of the game, it needs to be simple but still give the player an idea as to what will feature in the latter stages of the game. The prototype which I will be working with can be found in the image below:


For this next prototype, I simply moved and added to the previous scene I had built so I could get it up and running quicker than before. This section would again feature the rock throw, meaning I just needed to add a set up for putting down customs in different locations of the map. I started this with adding three transform positions and adding triggers next to these positions so the engine knows when a custom can be placed there. A screenshot of where these customs points are in the engine is shown below:

Screen Shot 2018-03-05 at 19.26.53

As I have not yet created an inventory system for the game, the custom put down will be simulated for this prototype. I started with placing the custom outside the visible scene and created a code that would allow it to be moved to the custom points. For this, I used the ‘OnTriggerStay’ method which means the custom can only be placed down if the player is within the box collider next to the custom points. I created three separate if statements in the update method for each custom point so the controls wouldn’t overlap each other. The code for this is shown below:

Screen Shot 2018-03-06 at 13.28.56

The next stage for this prototype was adding the movable platforms that the customs would interact with. I created these using the 2D hinge joints, features of the Unity engine. I duplicated the platforms, renamed them and added the joints to them so they can be moved with other game objects. I first tested the hinge joints by dropping the ‘rock’ game object down the scene and the bottom platform ended up spinning continuously. So, to fix this I added minimum and maximum angles it can rotate on. Shown below:

Screen Shot 2018-03-05 at 19.42.37

I now had half the scene set up but decided to come back to finishing it as Syl had sent me the animations for Isiko which I need to implement. In our year 2 project, animations gave me a lot of grief so I know I would have little trouble setting them up in this project. I used the same method as before, setting up the animator which is attached to the player and individually adding the animations into it. My notes on getting the animator working properly can be found on pages 12-20 of my coding sketchbook.

Screen Shot 2018-03-05 at 19.19.05

The image above is the animator tree for Isiko. He will begin every scene in an Idle state and then can walk left or right from this. At this stage, we do not yet have the animations for when Isiko turns around (transition between left and right walk). Having looked at Night in the Woods gameplay which features this transition, we decided it would be best to add one of our own for smoother gameplay. This feature will be added in at a later stage of development.

After walking left and right, Isiko can climb up and down ladders, meaning there had to be transitions between all 4 moving animations currently in the animator. I created bools for the transitions between these and created a new script named ‘IsikoAnimations’ to handle these transitions. One of the lines for this is shown below, and all other transitions are handled in this script.

Screen Shot 2018-03-05 at 20.37.02.png

I made sure all the transitions had the correct conditions and tested out the transitions between the animations. The movement along the X axis had no problems, but once Isiko climbed up the ladders there was a delay in the transition between them, making it look like Isiko was still walking whilst moving upwards. I fixed this by un-checking the ‘exit time’ box in the animation transitions. This meant once the conditions were met, the animation would change instantly and not on a delay. So, the animation tree was working fully and I will be able to add in the remaining animations with ease.