Category: Gameplay Prototyping Module

7 – Finetuning Core Movement

Slippery Character Movement & Wall Collisions

If you noticed and compare the first video and the recent ones you’ll realise that I tweaked and iterated the movement mechanics of the character a bit.
As you can see in the first video Gameplay Prototyping 1 – Movement the player slides about whereas in the third video the player doesn’t anymore.

This was essentially an oversight caused by application of PhysicsMaterials as to make the player slide down the wall when colliding (and not get stuck!) the platforms needed 0 friction but this meant the player would also slide along the surface.

This would also have been a major problem when I integrate mobile ’tilt’ controls using the phone’s accelerometer, this is due to the fact that if the player slides around even if no input is being made it would require the player to tilt their phone to counteract the natural slide at all times – making the game very hard to control and frustrating.

The game itself will already be hard enough to control with the tilt so we need as little-to-no input lag as possible: if the player moves right they move right, if the player stops moving right they stop right then and there.

 
Picture

 
The first issue was to prevent sliding which I fixed by adding a PhysicsMaterial with a friction of 1 on the Player GameObject.
 
Picture

 
The above fixed the sliding issue but the player would still get “stuck” on the wall if they constantly move into it (which you would if we had the accelerometer tilt controls).

After researching I found that there was any way to restrict PhysicsMaterials to a certain side/face of the object, via Unity’s Platform Effector 2D Component, with that in place for all objects the core principles and movement mechanics of the game was sorted.

 

No-limits Movement Speed

As the initial movement code was barebones if the player simply held down the Left/Right key they would increase speed and travel to near-lightspeed.
Picture

 
Thus I created some limiters to the speed in the playerScript, hopefully since its tied to a variable I can link it to a possible future Power-Up, for example something akin to ‘Running Shoes’ from Pokemon.

6 – Wall Dragging/Jumping Pt 2

Setup

Picture

 
The setup consisted of two colliders, one for collision one for triggers. I’m not sure if you can merge these two but when I tried it you couldn’t so I just duplicated the same shape twice.

This also fixed the problem of the player losing all drag/friction when moving into a wall (aka you’re already on the wall but you move against it)

The mechanics around Wall Dragging were tricky to get around as I had three options:
1. Work with the linear drag rigidbody element to simulate a ‘slow-fall’ that happened only when attached to walls
2. Work with PhysicsMaterials with friction on colliders
3. Manually alter player velocity.y to simulate the drag instead

After looking at various options 2. didn’t work out and 1. was easier to implement so I decided to go with the first option

Picture

 
Above is the code for the Wall Dragging which is essentially builds upon the player.drag seen in the playerParachute post.

I also added a new boolean to check if the player is actually touching the wall, this is the second state introduced (the other being grounded) and will be used in Wall Jumping.

 

New Test Environment

I also added onto the existing Test Environment so that I could test Wall Jumping later
Picture

 
 

Compatability with Parachute Controls

Picture

 
Since the player is not grounded when Wall Dragging if the player wanted to Jump from the wall it would activate the playerParachute instead – to avert this and keep the one-button control mechanism ethos I added the wallTouch condition to the playerParachute code
 

Initial Wall Jump Style

Picture

 
In this initial version I simply exerted a force up. A problem that came from this was that you needed a stronger jumpForce to counteract the linear drag (as its drag in this system, not friction, after all) – however this causes a discrepancy: if you ever leave the wall which enacts linear drag you jump really high up but if you dont you barely jump at all.

I tried counteracting this by making the linear drag 0 when the button is pressed but this highlighted another problem: since the force is only exerted up  you simply just go up, not across (preventing Wall Jumping), meaning that the player will always be in contact with the wall (and thus have linear drag of 20f)

 

Pushback Wall Jump Style

To counteract this I realised I needed to exert not only an upwards force but also a force that pushes the player sideways as well.

To determine which direction the sideways force would push, I needed to find a way to determine which side of the player was touching the wall.

At first I made a simple script that would flip the player’s sprites in the x direction depending on which way they were moving (and thus flip a collider object which would register walls) – but this conflicted with the 2D Dynamic Lights and Shadows plugin I downloaded so I had to do it another way.
Picture

 
 
Picture

 
First I developed a system to check if the player is touching any walls which I did by creating a new trigger collider object called wallCheckL (left).
I initially made two with for Left and Right but realised that if I integrate it within the existing (wallTouch) variable that I can just use an else statement instead of two ifs.
Picture

 
The code here works exactly like the code to set the (grounded) player state
 
Picture

 
With the new (wallTouchLeft) variable in place I modified the existing jump code, adding a horizontal force depending on which side the player is touching.
 

Video

5 – Wall Dragging/Jumping Pt. 1

One of the other mechanics was to allow the player to wall jump and attach to walls, a wall dragging/jumping mechanic often seen in other platformers – in our case the game will have spikes that ‘dig’ into walls making them slowly descend down.

playerSpikes Look Iterations

Picture

 
This was my first three designs with different designs, the first one is the improved version of the spikes seen in the gameplay mock-up in Post 1

Picture

 
The second design encompasses the entirety of the player as I initially wanted the player to latch and dig into walls

Picture

 
The third one is a balance between the two but highlighted a major problem that would affect the programming and design

Picture

 

Picture

 
The square edges would allow a small area of overlap where the player could essentially ‘balance’ – this would get them stuck in a sort of limbo area where they are technically using the playerSpikes but are also grounded at the same time.
 

Picture

 
Picture

My initial redesign had a ramp which provided a slant that would make the player essentially slide off any corners

Picture

 

However there was still a small discrepancy and chance: what the if the player lands directly on the point?

In order to fix this I iterated again, this time with versions that lacked the gap between the player and the spikes

 

Picture

 

Picture

 

Picture

 
I ended up choosing the third one as it was the cleanest and simplest solution.
Now that the ramps directly connect to the player the issue is gone or at least minimalised as much as possible.
 
I have a base version of the actual mechanics but its late and i’ll write about that tomorrow.

4 – Test Area & Parachuting Mechanics

Test Environment

In order to test new and existing mechanics I created a Test Level that would encompass various level design elements in the actual game.
Picture

 
 

playerParachute

Parachuting is one of the main movement mechanics as stated in the first post, in our case Parachuting slows the players Linear Drag and prevents fall damage.

The Setup

Picture

 
I created a simple vector that is 1.5 the size of the player (to keep it consistent) and created a polygon collider to encompass the parachute itself. Above is the setup in unity, note that the parachute sprite is transparent – this its default state as the parachute only shows when being used.
 

The Code

Picture

 
Above was the initial script on how the mechanics work, I created new booleans for the power-ups (HasParachute) and integrated the grounded boolean from the playerScript.
Basically, the player’s linear drag is increased if the player pushes and holds the “Jump” button down and is reduced to the default 0 when the button is let go.

 
Picture

 
A problem that existed was: “What happens if the parachute itself collides with a platform?”, in response I made it so if the player’s parachute hits something it will cancel the parachute effect and make the player fall normally.

I refactored the existing code and added new functions for deploying and cancelling the parachute so the collision function ‘OnTriggerEnter2D’ would just call the same function as holding the “Jump” button – this made the code much neater and prevented repeating code.

 

Video

 
Here’s a video of the Parachuting Mechanics. This video is also edited so hopefully it’s clearer to understand!

3 – Git

Not a big update today as I was working on other things, but today I set up Source Control/Git for the project.

This project will get tricky later so it’ll be good to start now rather than later so I can go back to working builds if something goes wrong as well as see what when I implement certain features.

For this project i’ll be using GitKraken as my desktop interface (much easier than using command line!) and linking it with my existing BitBucket account.