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.


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.