Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Checkpoint 1 - Player Movement - Biscuit Run

DevLog: Biscuit Run

Checkpoint 1 - Player Movement

Implementation

A first iteration of my Player Movement for Biscuit Run was implemented in a sandbox level which prototyped the game’s colour theme. The PlayerMovement script already featured the two-character’s controls, which is so central to the game concept, and was uploaded to itch.io as a WebGL build for a student practical in order to give and receive feedback on our game project progress.

I had already been toying with a platformer player movement script and begun to identify features which were both useful and unnecessary for Biscuit Run. The first challenge was to set up the script to manage player keyboard inputs for each character separately and feed these into the script’s Move method. Making a Pong game clone recently set me up with the framework to do this and already I can see the value of starting with small projects and then building slowly. Every new little thing seems useful later, even if it just the knowledge of what won’t work. Following this trend, I set up the key-inputs I wanted inside Unity’s now familiar player inputs settings and settled on AWD & the arrow keys for their familiarity and simplicity. This is going to be a mantra and I iterate over various game features: “Simplicity”. The script references these custom input settings by name, thanks to Unity’s invisible back-room workings.
 

Screenshot of the script referencing my custom Unity player input settings.

Basically all Biscuit Run needs in terms of inputs is dual controls that for horizontal movement and jump. Considering one player will need to control each character with one hand, there didn’t seem to be a better option than these basic keyboard controls.

Even before getting feedback from fellow students, some issues became apparent…

Example of Player Movement in a sample scene

The jump is powerful. Really powerful. It is like someone put a Porsche engine in a matchbox car. These little characterObject rectangles just about fly. I hadn’t thought about the variables in the script needing to scale with character size, but apparently they need tweaking. Obviously the script doesn’t care how tiny the graphic it is controlling is, it just says “jump!"

Feedback

Example of testing Player Movement

“i see it has acceleration , does it have a speed cap?
seems fairly "floaty" at the moment. Is the the feel you were going for?”
“I like how with enough run up you can just barely clear this jump :D”

Lights were being shone on various aspects of the Player Movement. Some things known and some unknown. Yes, the characters seem to gain momentum and to be honest I hadn’t really wanted gradual acceleration in my game. But this is just the first iteration and the feedback is gold.

“it not like a bigger jump, if i rapidly hit the jump key sometimes it would do a double jump”

There is a bug where if a player double taps jump while the character is still on the ground, they achieve a noticeably higher jump. It’s not a bug if I chose to keep that as a feature though, right? ;D (I actually like this as a feature, but will it suit my game levels? - that is to be determined, and further tested to see how consistent the behaviour is. I want my players to be happy not frustrated).

“ there's an inconsistency where the players build momentum when they move but when you suddenly change direction they instantly click the other way”

There is definitely some feedback on the momentum aspect of player movement. I will be looking at altering how my movement script sets velocity to suit the kinds of challenges in the level, but some momentum would give a natural feel I think. After considering really rigid velocity rules, I am leaning towards keeping some momentum although regulated down to a minimum and shortening the jump so much that the sudden direction changes don't impact on the feel of the game, while still allowing for forgiving player controls.

“Also when standing on each other, if the bottom one moves, the top one stays behind -- up to you if this is intended behaviour or not. I've played games that work both different ways”

This observation made me explore this game mechanic, and lead me to actually question whether I would separate the two characters into separate channels or allow them to interact to overcome challenges. I like the possibility of allowing more diverse player strategies emerging by implementing this idea.

Regardless of what solutions I finally settle on in responding to the very useful feedback about floaty-ness, momentum and acceleration, character interactions, and the subtleties of the game mechanics, my next priority is to shorten that superhero jump!

Support this post

Did you like this post? Tell us