Week Six
Week Six began the start of me responding to a few different things that sprung up from the previous two weeks. If you remember from the last blog post I made a short list of things I wanted to iterate on as a part of the next development sprint.
Remove the sprint
Add a Dive
Add a Double Jump
Add Gliding
Add a Slam
Add Attack
If you remember from the last blog post, I spoke about how I had began my first round of proper feedback and play testing sessions in regards to the player movement. I uploaded the prototype to Itch.io that can be playable on Windows, with the option of using a controller or mouse and keyboard. I also managed to get the prototype shipped onto the Steamdeck, and I was pleasantly surprised when I was still getting the constant 60 frames that I am aiming towards, even with the underwater effects. I also had the game playable throughout development sessions and lectures so that anyone was walking by and that was interested could just hop on and have a quick go.
I paired these 3 forms of play tests with a feedback form, asking specific questions aimed at getting quantitative data on each aspect of my movement. Google Forms Link That way if the people who were playing my game had a issue with a specific mechanic, or aspect it would not effect the other data I was collecting.
My feedback form tries to collect three sets of information that are going to be useful to me within this project. How familiar is the person to the 3D Platformer Genre? - which will allow me to get more context into their feedback, if they play 3D Platformers all the time the feedback collected from that particular individual might be worth more of a merit than say someone who only plays First Person Shooters. How they feel about common mechanics found in collectathon genre? This will allow me to get a grasp onto how potential players feel about locking levels behind certain obstacles - and whether they prefer intrinsic or extrinsic motivation in regards to collectables. How do they feel about each movement aspect of the prototype? This allows me to be really specific on each aspect of the turtles movement, so I can get dedicated feedback towards that - it is split into, Underwater Movement, Above Water Movement etc…
Each of my questions were phrased around a certain aspect of the players movement or major mechanics found in collectathon style games. I will use one as a example. You enjoy collecting optional collectable items within video games. You could respond to that on a scale of Strongly Agree / Agree / Neutral / Disagree / Strong Disagree. The question was then followed up with a short paragraph where the player could expand on their specific decision. This gave them space to give me unlimited feedback on that particular part if they want.
I then asked everyone who played the game, for verbal feedback during the feedback as well as filling in the feedback form afterwards.
While I was waiting for this feedback to be given, and for more of the forms to be filled in, I jumped back into the engine and created two different extra types of jumps that would allow me to get a start into understanding how high the double jump should be in regards to the height of the character.
I created two different types of jump, the high jump, which was twice the velocity of the original jump and the long jump, that put the velocity that the high jump uses but directs it in the direction that the player is facing.
To High jump in this version you would need to hold a modifier button, and then jump - to high jump on keyboard it was Ctrl and Controller it was Left Trigger. To long jump it was the right mouse button for keyboard and right bumper for controller.
The way I created this was by adding two more concrete states - that I had to add to my PlayerStateFactory script, and fill in all the relevant transitional criteria, what happens when the player enters the state, what happens when they exit it etc.
Once I had this experimented with this enough to get a understanding of how the game-play would feel with these two extra types of jump, I decided to look at the feedback which would inform how I implement the actions I mentioned at the start of the post.
I decided that with the way I had prototyped the different types of jumps was not the best decision for a multitude of different reasons. There were two many different buttons for such a simple action - the jump. Two many inputs are going to confuse and frustrate players, especially when it is a Cozy 3D Platformer.
Looking at how other games have tackled this particular issue, to specify the issue I am talking about is giving the player different types of jumps, without overwhelming them.
Super Mario 64, has a progressional jump system, meaning if you jump at a exact moment after you have landed you jump higher, and then that process is repeated twice giving the player essentially 3 different jump heights throughout one button. That handled giving the player vertical motion choices.
Super Mario 64 gave the player horizontal control for the jump, by making Mario run faster, meaning if you needed to jump across a big gap, you just got a run up. This was then tackled later on in the game with the Winged Hat, that gave him a glide. As well as this Mario has a ability to do a slam attack, that allows the player to stop and instantly move towards the floor, this functions as an attack as well as a way to control and stop that horizontal movement.
Spyro, has a single jump system that allows the player to charge which therefore allows them to jump much further distances, this charge also works as an attacks, so it is one less button to click. This is then paired with a glide mechanic that gives the player that control over the horizontal movement, which can be cancelled by charging which cancels the glide and sends Spyro towards the floor.
In Vista World you can double jump, dive to give you that horizontal movement, and then jump out of it, which works similar to the slam in regards to stopping that momentum. You can also do a charge jump, that gives you that extra height without having to jump -> jump -> dive -> jump to get to that height. While playing I did find that I rarely used the long jump, as I could not dive out of it, and I did not have any control over the horizontal movement on that jump compared to if I just did the combination jump to reach that height.
In my game I have decided to condense the different jump heights into one singular button press by using the Super Mario 64 as main inspiration, where timing your jumps gives you extra height. In Super Mario 64 once you have done the highest jump, you reset the jump height, whereas in Out Of Water I created it so that if you time your jumps correctly you can indefinitely jump high until it runs out.
The way I created this was quite interesting as I used Dictionary, which is something I have never used before, essentially it is a value hidden behind a particular key - similar to an array.
I created two different dictionaries, one that holds all of the Jump Velocity Values for each one of the jumps and a Gravity Value for each of the jumps which has given me a lot of control of how floaty all the jumps are. I then set Getters / Setters similar to how I have been doing for the other variables throughout the entire project, so that I can access it through Ctx in the Jump State.
Then was getting these values actually working and effecting the jump heights, I just used the key [Ctx.JumpCount] so that say, if the key was 1 - it would add the relevant velocity for the 1st jump, if it was 2 it would give the relevant velocity for the second jump. This way allows me a lot of control over each of the individual jumps. After lots of tweaking, I decided on some values and then the final result can be seen below.
I had it originally set up so that once you have landed from your third jump, the jump count is reset - meaning that the next jump is going to be the first jump. I decided to change it so that you can indefinitely jump with the 3rd jumps velocity if you time your jumps correctly - then it resets. This can be seen below. This time window can be altered as all it is a Enumerator with a WaitForSeconds, that is triggered once the character has landed - shortening this time frame will mean the player has to have more skill to be able to jump higher, but can cause more frustration if it is too short. Footage can be seen below. I am happy with the way I have handled this, I give the player control over the vertical height of the jump, and partial control over how far they can jump by allowing them to enter the jump states while in the roll state, meaning they carry slightly more momentum with their jump.
I then decided to focus on giving the player even further control over that distance of the jump. I decided to recreate the Spryo Glide, which can be entered from the Fall / Jump States. Glide is again another concrete state that has substates of idle and move allowing the player control. If they want to glide across a gap, they can. If they want to slowly descent onto a collectible they can. The glide originally could not be cancelled, you only exit that particular state when you land. The basis for the glide state is a modified version of the fall state, I tweaked the variable values in the HandleGravity function, that is called through update, until I got a glide that did not feel too long.
I then decided to add another feature that has two functions, and a mechanic that is commonly found in platformers. The slam, it allows the player to stop all movement and catapult towards the floor. This is used to give the player control over the descent from the jump state or glide state if they are going to say glide over a jump. It is also used in many games as an attack - such as Super Mario 64 smashing into enemies.
The slam state is another concrete state, that is based on the Fall State but I have changed the values of the variables within the HandleGravity Function to double what the Fall State is, so the player can slam towards the floor if they so desire.
The way I originally implemented the slam state, was you could only enter it from the jump and fall states, but after altering the Glide state you can now exit the glide by slamming using Ctrl and X on controller.
I then decided to take inspiration from another popular video, Crash Bandicoot. The Attack Slightly speeds up Crash’s movement for the duration of the attack, and stops him from jumping. I decided that my attack state would also spin, for the time being. I created another concrete state, to hold the attack functionality with substates of idle and walk. I created this with similar logic to the jump, it requires another button press so you do not just hold it. I also utilised an Enumerator with a WaitForSeconds that lasts the exact time as one loop of the Spin Animation. That enumerator runs when the Attack state is entered, and only when that WaitForSeconds finishes, then you can attack again.
To sum up the other notable changes I have made : Removed the sprint functionality, and increased the walk speed of the character.