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.

IMG_0124

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.
Advertisements

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:

img_0092.jpg

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.

Creating a Camera Zoom

Following on from the (Blog Post name for design) blog post, I went back into Unity to create a method allowing the player to zoom in and out of the screen so they are able to view the whole map and make better decisions whilst playing. Adding this in now will also come in handy when starting each level of the game, as the camera will pan out to show the player the whole scene to give them an idea of what they need to do in order to progress.

To start working through this I looked at the camera in the hierarchy and changed the settings to see how it would affect the game view. Changing the size of the camera using the scroll wheel in the inspector zoomed it in and out of the target position (that being the player). So, all I needed to do for the zoom was to work out how to change the size of the camera using an input. All notes for working and constructing this script can be found on page 1-8 of the “Coding notes book”.

Before writing the script I needed to add another Input in the project settings so the PS4 controller can be used to zoom in and out of the scene. I decided to use the right joystick for this. So, the input “RightJoystickV” was a reference to the right joystick moving up and down and these movements would zoom the camera in and out respectively. In the script, I referenced the Orthographic size (camera size) in the update so this could be altered using the inputs of the controller. The code for this can be found below:

Screen Shot 2018-02-28 at 20.25.58.png

Now this was added, I could use the Inputs to change its size which I also added into the update method. I asked the engine if the right joystick was being pressed down, and if it was, the camera size would be increased at a rate of 0.2 each time the input was being met (zooming out). Below that was the second method to ask if the right joystick was being pressed up, and if so, the size was decreased at the same rate (zooming in). However, when testing, pressing the joystick down increased the camera size but continued to do so despite letting go of the joystick and even when pressing the joystick up, which should have decreased its size. The video for this testing can be found below and now meant I needed a new method for this.

After researching into what Input Axis can be used by the controller, the L2 and R2 buttons are a reference to the 5th Axis so can be used for the camera zoom. The manual states that unpressed = -1f in the Axis and up to 1f means it is pressed. So, for this I created the L2 button on the input menu and had to change scripting. The first if statement changed to ask if the input was equal to 1 (pressed), and if so, the camera sized increased. Then, if the input was equal to -1 (not pressed) the camera size would decrease and zoom back into the scene. This worked for zooming in and out of the scene but when zooming back in it carried on past the original camera size and away from the scene. The video and code for this can be found below:

This had my brain hurting for a little while, but finally realised it was an easy fix. In the zoom in method, I created a second if statement asking if the camera size was below 35 (the original size), and if so, the camera size was set to 35. This meant that whenever camera size went any value below 35 it was immediately set back to 35. The video for the final test can be found below:

As we have not yet put in the artwork for the scenes, the camera zoom will have to be changed at a later stage of production so none of the scene below the floor is shown.

Generating First Prototypes (Part 2)

Following on from part 1, I then had to create a series of events that opened the gate at the far end of the level so the player can progress to the end. The sequence is as follows:

  • Rock is thrown at tree
  • Bird is disturbed by the feeling/noise and flies to the gatekeeper’s roof
  • The bird begins to peck at the gate keeper
  • The gate keeper comes out of his house to notice Isiko there and opens up the gate

The finished version will have the animations of the the gate keeper coming out of his house, him pulling the lever and the bird flying around but for now I have used a bird sprite and colour blocks to simulate the rest of the prototype. The colour for these are as follows:

  • Brown = Tree/House
  • Blue = Gate

The first job for this was getting the the bird to move once the rock had hit the tree. I originally asked Syl if this could just be an animation that played once the rock had hit the tree but due to having to resize in Unity it would be difficult for her to correctly complete the animation. So, we will have a static bird animation game object that will be moved via scripting. As the rock is the game object interacting with the tree, I created a script that was attached to it and referenced the gate and the bird in it so they could be manipulated in that same script.

I first created a reference to the bird and did some research on what scripting could move the bird. Having used the method MoveTowards last year, I gave myself a small recap on how it works and decided to use this for the method. I first set up my game scene, placing the bird sprite next to the tree and creating an ‘end position’ where the bird would finish its journey on top of the house. The image below shows the bird and the ‘end position’.

Screen Shot 2018-02-26 at 19.37.46

To make this scripting easier, I create several bools to ask the game whether or not the bird and the gate can be moved during the event triggers. For the events to occur I first used collision detection when the rock hits the tree, if it hits, the bool for the moving the bird is set to true and therefore it can then move. The method for moving the bird and calling it in the update can be found below:

Screen Shot 2018-02-26 at 19.33.20

This method first references the bird’s position, then moves the bird, the start position being where it currently is, the end position being the ‘endPosition’ game object, moving at a speed which is registered in the start method of the script.

 

Screen Shot 2018-02-26 at 19.33.38

This asks if the bird can move, if so, the method to move the bird activates and moves the sprite.

The next step was to move the gate, which will use a similar method to moving the bird but will not recover a specific point to move to as a gate can only move in the Y axis. So, as the bird’s final position is the ‘endPosition’ game object, the update method asks whether the bird’s position is equal to it, and if it is, the gate is moved upwards at a uni per second. The scripting for this can be found below:

Screen Shot 2018-02-26 at 19.33.41

A YouTube clip of the introduction working can be found below:

Despite me knowing how the introduction is played and how it works, I needed a third party to play it and essentially break it so I know where the game can go wrong and how I can fix it. I asked two second years to play it for me, gave them the controls and an objective and said nothing else. The full notes of the testing can be found in my ‘feedback’ folder. But the two main problems were the rock being moved by the square button before being picked up and the players jumping onto the branches where they are unable to get out from. So, I head back into the scene to fix these.

The first problem was a small fix, I added a second statement along with the square button being pressed asking if the rock had been grabbed by the player. So, the method can only be active if both statements are met. The code for this is shown below:

Screen Shot 2018-02-23 at 17.33.45

The second fix would require a change to the layout of the map. As the branches are the same colour as the platform, the scene suggests that the player has to move off of the platform onto the branches in order to do something, despite this not being the case. So, after a talk with Adam, he suggest I change the platform in order for the player to better understand the situation. So, I added a barrier stopping the player from being able to jump off, suggesting to the player that something has to be thrown off of it instead of them moving up it. The final platforms are shown below:

Screen Shot 2018-02-26 at 19.39.56

I then asked two more people to play the prototype, both took a little time to figure out what to do, which will probably change once artwork is added to it. But, neither play-throughs required the game to be reset which means it is fully working. Now this is complete I can work on the next prototype that will introduce the customs into the game.

 

Generating First Prototypes (Part 1)

Once we had our game idea finalised I had to begin with generating ideas for prototypes as getting stuff into the engine for me is the best way to get the ball rolling and up my work ethic, sticking to the sketchbooks just doesn’t cut it for me. But, before all the scripting could begin I had to think about and arrange how the levels would work for Isiko. This then gave me a structure on how I could prototype and develop the puzzles for the game. The order of level design would go as follows:

  • Tutorial
  • Introductory levels
  • Combining customs
  • Combining customs with Industrial machinery

Each of these sections will be based around Rube Goldberg machines and will increase in difficulty as you go through the game. After reviewing games similar to ours it was apparent that the first third to half of them, gameplay wise, were simple, interacting heavily with the environment which eased the player into the game. So, I wanted the first sections of our game to follow this sort of pattern to give players more time to understand fully the concept of the game and how it works. I began then to work on interactive tutorials and how best to show the ‘chain reaction’ idea for our game. I created some mind maps for ideas and landed on a tutorial shown below from a sketch.

So, Syl got to work on creating the artwork for the scene and I begun to prototype in Unity. As I was working from scratch again I built a new scene using simple colour sprites to represent aspects of the prototype.

Screen Shot 2018-02-23 at 16.48.00

The screenshot above shows the simple scene made in Unity. Once this section works I will be able to simply overlay Syl’s artwork on top for a near finished section. The key for the scene is as follows:

  • Red = Player
  • Black = Platform
  • Yellow = Ladder
  • Green = Rock

So, I started with a simple Move script for so the player which featured a walk, jump and jump re-set method. I had previously used these methods so creating this section of the prototype wasn’t a hard task for me. However, one new line of code saved the move script from being faulty and stopped the player falling over, which was a past encounter. The one line of code was a restraint to the player’s rigid body and stopped it from rotating in the Z axis. It is shown below:

Screen Shot 2018-02-23 at 16.48.27

I then had to get the ladders working, which I knew used a similar method to the horizontal movement for the player but instead the input axis will be in the Y and not the X. However, I would first need a way of detecting whether the player is situated on the ladder, making sure the player doesn’t move up/down despite not being on the ladder. So, I gave both ladders a box collider, meaning they could be interacted with, and wrote a script to detect whether or not the player was on them. The script can be found below. I first allowed access to the “Move” script and added these collision methods to it. Their function is to say when the player is on the ladder it is able to climb and vice versa when not on the ladder. The bool (true/false) statement is found in the “Move” script.

Screen Shot 2018-02-23 at 17.03.00

I then added the ladder movement to the move script, keeping all the player movements in one script, making my life easier for when I need to make amendments to how the player moves. I added the ladder movement to the update method and called two “if” statement asking if the player was on the ladder. If they are on the ladder, a climb velocity is created which is a speed multiplied by the Y input axis, which is up or down on the left joystick of the controller. Then, the new velocity of the player’s rigid body is a new vector, which stays the same in the X axis and is changed to the climb velocity in the Y axis, allowing the player to move up the ladder. I also made the gravity scale 0 when on the ladder so if the player didn’t move they would stay on the ladder and not fall down it. If the player is not on the ladder then the ability to climb is false and the player cannot move in the Y axis. The script can be found below.

Screen Shot 2018-02-23 at 17.02.41

I then had to add the rock to the game and work out how the player would pick it up and then throw it. Later on in development I will work on an inventory system as the player will, in later parts of the game, have multiple customs to use so an inventory will allow the player to use multiple customs using the same button, making a better flowing game. But, for now the rock will sit beside the player, showing that it is being held.

For this I created a new script that would be attached to the player allowing it to interact with the rock. I first added a collision method that asked if the colliding object was the rock, if so, “Grabbed” was true. This meant the rock was picked up when the player walked into it, rather than having a button to do so. The code for this can be shown below.

Screen Shot 2018-02-23 at 17.21.19

Now that the rock had been grabbed, I needed to create a method that moved the rock next to the player and one that allowed it to be thrown. So, for this, I created an empty game object next to the player that acted as the hold point, so, if “Grabbed” is true, the rock’s new position was equal to the hold point next to the player. Then, again in the update method, if the player pressed the square button on the controller a force would be added to the rock sending it off to the right. The code for these can be found below. Screen Shot 2018-02-23 at 17.33.45

The second part to this blog post will show the next part of the prototype and the testing/feedback on it. Stay tuned.

Idea Generation

After finishing first semester there was still a lot Syl and I had to figure out. We could go two different ways with what we wanted our project to be about; the first a fun and challenging game with a unique puzzle system inspired by deforestation, and the second again a challenging puzzle game that is designed to make the player think heavily about the struggles of deforestation on tribal culture. We did want to take the second route but after some idea generation sessions and a conversation with Adam, we were using the idea of deforestation too literally in our game universe so it wouldn’t be an effective way getting our audience to think about deforestation. So, we decided to take the first idea forward and simply make a fun and challenging game with a unique selling point.

Since the Indie game revolution in the late 2000s, 2D puzzle games have soared in popularity and have become a focal point of games design, which has seen many of these types of games to be made. So, for our game to stand out in the crowd we needed to find a mechanic that can both challenge our creative capacities and instantly grab the interest of the player. Currently, simply using the customs to solve puzzles in the game world isn’t enough to capture the audience, so we went back to the drawing board to find the missing piece of the puzzle, pun intended. A video of a table-top Rube Goldberg machine gave me a thought about how our game could function as a Rube Goldberg machine, as the customs that feature already are similar to some of the features in the machines. So, we begun to fling around some ideas of how it could work and we instantly became hooked on the idea. A mind map of idea generation can be found below.

IMG_1396

Following a conversation with Adam too, we begun working on how the Rube Goldberg machine mechanic work within our game world. I played and watched some play-throughs of 2D puzzle games similar to the one we want to make. One that stood out to me was Heist, which for the first third of gameplay gave little challenge to the player and instead the game acted as a way of the player feeling comfortable in the game world to understand how everything works. So, Syl and I decided to use this in Isiko so the players can feel more comfortable when entering the game world. The first levels of the game will also need to act as an introduction for how the customs will work so letting players ease into that will make for a better game experience.

Isiko Stages 

  • Introduction to how the game works – This will feature a Rube Goldberg machine that is interacts with the game environment and doesn’t feature customs.
  • Introduction to customs – Each custom will be introduced one at a time and has to be incorporated into a RG (Rube Goldberg) machine. These too still feature interactions with the environment.
  • Main game section – These will feature puzzles that will increase with difficulty and use more two or more customs in each. As the puzzles get harder they will be less interactive with the environment and more interactive with the industrial machinery.

Above is a rough guide for the stages of our game and how they will work. I have made this guideline for myself so I know what to prototype when and this will allow me to stick to a stricter and more productive schedule which will give us a longer and better gameplay feature. Puzzle design is the biggest aspect of our game so a lot of work has to be done for these to both work and be fun for the player. So, I needed to watch RB machine videos in order to better my understanding of them. A link to one of the videos I watched can be found below. I followed the videos and sketched out ideas that stemmed from them in my book as this was a way of quickly generating ideas and using existing machines to influence the mechanics is likely to ensure the puzzles work to their full capacity.