This weeks checkpoint was ‘Basic Level Blocking’ and my priority leading up to the Peer Review session was to have a WebGL build of Biscuit Run containing a few features that I wasn’t certain would work out. I wanted these features examined ASAP before building too many scenes because they would be important features to block key levels around. This included anti-gravity and colour-coded platforms which could only be walked on by the colour-matching player character. (I.e. PlayerBlue can only walk, jump, and play on the blue platforms, and PlayerOrange can only stride, leap and froth on the orange platforms). Because of the scripting and level design required to make these two features functional, I had only one level built in time for my peers in the Peer Review to play with.
First things first though, and following on from the last peer review session, I had prioritised modifying the Player Movement, particularly the power of the players ‘jump’ and ‘floatiness’. This was achieved (after consultation) through modifying the Gravity and Sensitivity levels in the Project Settings: Input Manager. They were way too low and setting these to 1000 gave the movement crisper response and control. The super-human jump was moderated by changing the Gravity Scale on the player’s RigidBody2D, and the jump-force on my movement script. The result of these changes was a shorter sharper player jump. This then gave me the measure of how close to place the platforms.
Successfully adding options for ‘gravity flipping’ via scripts (whereby for one or both playerObjects would fall upwards and jump downwards relative to the scene view) allowed me to commit to constructing a scene from some of my sketches (below):
This scene was built with prefabs made from deformed square sprites with BoxCollider2D components added. Interestingly, even this basic method of scene building was fraught with glitches, where my players’ ‘feet-triggers’ would sometimes not detect the collision when moving from one sprite’s collider to another - the result being that they couldn't jump. I still don’t know why this was occurring- but I changed some things so that it went away ;D
Obstacles for this level include gaps between platforms and spikes. The spikes were made using triangle sprites placed in the scene as children of one triangle, so that they all can be moved in the game editor and placed as a group. One collider component was added to the parent triangle and set as a ‘trigger’ and then resized to cover all the spikes in the group. The rest (‘death by reset’) was done in the movement script.
The original spark of an idea that served as inspiration for my game was similar to this WebGL build level: a simple maze of platforms in two colours and two playerObjects. In honouring that inspiration, but only if I have adequate time and oodles of motivation, I may implement a level in which the some platforms change position in-game - perhaps as timed and scripted events (or player controlled ones). But the priority for Biscuit Run’s remaining 4 week timeline is probably building easy levels for early in the game. This level is a little hard to start with - as was reflected in the feedback…
The original spark of an idea that served as inspiration for my game was similar to this WebGL build level: a simple maze of platforms in two colours and two playerObjects. In honouring that inspiration, but only if I have adequate time and oodles of motivation, I may implement a level in which the some platforms change position in-game - perhaps as timed and scripted events (or player controlled ones). But the priority for Biscuit Run’s remaining 4 week timeline is probably building easy levels for early in the game. This level is a little hard to start with - as was reflected in the feedback…
I realised leading up to this peer review that the level scene I was showcasing would not be a typical one for my game - but a more advanced tricky to understand one, and the whole testing process really brought to my attention that I will need to implement levelling-up of difficulty incrementally if I wanted to give the game the flow I plan for it to have.
My own preemptive attempt at guiding my peers attention and feedback was written in about 3 seconds and went something like this
“This is a proof of concept for a scene. Control both characters through a maze. It's a Puzzle. The end point is currently just the opposite side of the maze as I haven't put a flag/finish Point in yet. Thanks.
It is a harder level. Most will be free flowing and fast”
The feedback that was relevant to this checkpoint includes:
On Gravity:
“i really like the trippy feeling of the orange player being completely inverted, but i think my brain will hurt after like 5 minutes of playing this lol”
“I like the concept with the opposite gravity”
This feedback reminded me of playing ‘In The Grey’ (which partly inspired the direction I wanted to take Biscuit Run). I think it was the feeling that I got in my brain from controlling and keeping track of two playerObjects which appealed to me in the first place. This feedback is a reminder of what I am trying to achieve: a pleasurable ‘trippy’ feeling, not the expectation of pain!
On Timer:
“I like the idea but i think the timer adds too much difficulty given you already have to think about what to do”
“I love the idea of a timer because it makes it more like a speed running game and it adds some pressure to the player to go fast and not take their time on each jump.”
This contrasting feedback reenforces the idea of difficulty progression. Starting easy - so you don’t have to think about what to do. Then progressing incrementally to levels that are challenging and still fun, where there’s a bit of pressure to go fast.
General Feedback on Scene/Level Design:
“I liked how player could go only go on their respective colour”
“very interesting concept. The levels are a bit confusing for my brain, perhaps the colours are a bit similar. Is there a goal for the particular level or just get to the other spawn for now?”
Each level will have a goal to reach for each character. The player has to get both characters to their respective goals before the timer runs out to progress. There will be infinite lives - because dying sucks.
I think that the difficulty of making sense of the platforms is exacerbated by the blue background - which was an error I made by not changing the background to plain black before uploading the build. (Note to self: do this before the next Peer Review session!).
“I also feel like there needs to be a death plane at the top for each colours to so even if the players fly out they will just respawn”
Hmm… this was an interesting bit of feedback. I had already built a ‘death plane’ that reset the players if they collided with it off screen. The feedback lead to the discovery of a bug. For some reason if the playerObject hit the ‘death plane’ after being reset they just passed right through it. I also realised that the script that reset the players’ positions didn’t also reset the gravity. It just left it set to however it was pre-reset. That’s not how it should be…
After my question “do you think I should have walls walling them in on most levels, or open air to leap to their death/respawn?” The feedback received was:
“I prefer open air but it really depends on the level and what you want the player to do..."
I wasn’t going to include this comment because it was just indicating a preference, but I decided to make note of it anyway because I believe that when designing we should always be open to user input in order rather than assuming we know everything. I do like open air.
“Love the concept itself, could do some really interesting stuff with it past simple jumping and dodging. Platforming seems to work fine except I don't like how fast the players fall but that's just preference. Looking forward to seeing it progress!”
I think this is saying that it’s not interesting enough yet but has potential. Fair enough! I hadn’t even put the goalObject in for this build! There is just a timer ticking away while players explore and then get reset. Currently I am keeping the falling speed, but will definitely ask for further feedback once the easier levels are up. I have noted that gravity will likely cause slower falling if I scale up the entire scene (and move the camera viewpoint back to see it all). I read somewhere in a forum that, when built to equivalent scale, a lego figure will fall to the floor in less time than a full-sized person will land from an equivalently scaled height. And this physics is likely similar to Unity’s built-in physics engine.
Shortly after the Peer Review session I added the goalObject (see the GIF below) and put together a script that would load a new level. (Thanks youTube tutorial!). At time of writing there are no new levels, but the script simply reloads the current level/scene.
Did you like this post? Tell us
