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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s