top of page

Movement Shooter - Dev Log

    This movement shooter engine is a passion project that I've been working on. Currently, the project is in a state where I'm testing movement mechanics. I will soon be incorporating gun play into the game. Read more about the development below!

 *  If you don't want to read anything and just want to play, click on either one of these! The itch.io logo on the left will bring you to the itch page and the discord logo on the right will bring you to my testing server!

Starting Point

    My goal with this project was to get a 3D movement system up and running. I wanted use this project to explore the new Unity Input System. First I started off by watching a tutorial (of course). The tutorial above helped me improve on how momentum felt in my game.

Old Code New Systems

     The original code from the tutorial I followed used a private struct to hold the inputs coming from the player. Along with this the inputs were detected via the old unity input system. To do this I used my own input holding system that isolates the player's inputs and makes them publicly available to all scripts. I did this so I can keep all my inputs in one place and keep them isolated from the movement script itself to prevent any unnecessary value changes.

Untitled-4.png

Fixing Collisions

     One of the biggest issues about the code from the tutorial was that the movement never accounted for any kind of collision with things like walls or enemies. This would've been a big issue because the subgenre of game I wanted to make is heavily reliant on the player's collisions with the environment.

​

    The issue was most visible when colliding with a slanted wall at high speeds. The bug was that once the player collided with the wall, the direction they were moving in wouldn't change. Once leaving the wall (assuming they have enough speed) they would continue to move in the direction that they entered. The reason why this happened was because the script for movement was made using Unity's character controller, instead of using rigidbody physics.

​

    I was able to solve this issue separating the player's velocity value into two different vector3 values. There was the playerVelocity which held the direction the player is supposed to be pushed in and then the worldVelocity. The worldVelocity is continuously calculated to show the player's actual velocity in engine. Then I detected when the player was touching a wall and if their playerVelocity didn't match their worldVelocity, adjust the playerVelocity to match the worldVelocity.

Adding Mechanics

     The first mechanic I created was wall jumping. There are plenty of tutorials out there for basic wall jumps but I wanted to make on that functioned a bit differently. In this game I didn't want the player's forward momentum to be halted for the jump. If the player is moving forward and they wall jump they will continue to move forward, outwards from the wall, and upwards from the position they jumped from.

     This mechanic created two major bugs. The first bug that I had to fix was that the code was initially set up in a way where wall jumps would actually send you in the opposite direction of your current velocity.  This was easy to fix. The directions the player was jumping just had to be inversed in my code.

     The second bug was that the player was jumping farther from some walls then others. The distance wasn't consistent and it seemed to change for each position. The issue that was causing this was that when the player was colliding with the wall, they were actually still being pushed into the wall. This was the same issue as the Fixing Collisions piece above. The sollution was to just bring the player's playerVelocity to the worldVelocity value.

Build #1

Adding Mechanics

     After the wall jumping mechanic was dashing and interactables. I made it so the player has the ability to dash in any of the 8 horizontal directions (forward, forward-right, right, etc etc...) and can dash downwards. The downward dash originally only functioned to give the player more control over their vertical positioning, but I later changed it to become a ground pound move. I did this because I wanted to make an easier and more accessible version of the b-hopping mechanic that is prevalent in this genre of game.

​

Build #2

FAZf9J1VEAMt-bg.jpg

     The first interactable I built was the boosters. My main inspiration for these were the springs from the game Sonic Adventure 2 Battle. In that game when you collide with them they would cinematically bounce you through a portion of the level. I really liked this concept but there was no skill involved in using them. They essentially just turned a portion of the level (that could be fun gameplay) into a scripted event. My boosters allow the player to maintain full control in the air after they're launched. I wanted the player to be fully in control of their movement during all aspects of gameplay. This mechanic gave me a more flexibility the complexity and verticality of my level design. Levels would no longer have to take place on mostly flat surfaces.

   ​  Also as you can see in the image above there are green lines emitting from these boosters. I built these in a way where each booster has it's own personal target, and the player would get sent in the direction of their respective target. I built them this way to make dropping them into levels easier. 

Menus

    Menus were important to establish from the start. One of the most important things I learned about making small games in college was to never leave the menus to last second. Originally the concept for the menus was to make a manila folder themed slides. Whenever the player clicked on a settings tab another page would open in front of and slightly to the right of the previous menu page to give the feeling of depth. 

menu24.PNG
menu22.PNG

   This concept was later scrapped because it felt too amateur and wasn't what I wanted this project to move towards thematically. Instead I've now adopted a phone styled theming for the UI. I did this because I wanted to explore the idea of letting the player interact with menu as if were it's own miniature game. The current plan is to have the a hand following the mouse on the screen and when they go to touch any buttons, give the illusion that their hand is making contact with the menus on the phone. This functionality has yet to be added but it is planned for the near future. I went with a modern smart phone and cassette tape player fusion for the UI because I also wanted to eventually play around with letting the player pick which song they're listening to while they play. Each level would start with it's own default song and if the player wanted to listen to something else they could just pull up the menu and change it. 

Build #3

Build #4

     Along with fixing a lot of bugs I made some changes to the original movement script that would allow me to future proof making new movement mechanics. With these changes I am to add to the player's current velocity or completely reset/override it and send the player in a new velocity. This functionality is available publicly and can be accessed by any other script I write. This is how I made mechanics like the boost pad I mentioned earlier. Using this functionality I was able to get a grapple hook functioning in an evening filled with coffee and loud music. The grappling hook was made in a way where it would move the player towards the center of the grapple point. The grapple point is an interactable in the game that is the only place the player can grapple to. While this would be completely acceptable, I've been striving to make all of the mechanics in this game have some form of agency so that the player is always in control. Once the mechanic was proven fun, I added a couple of deeper interactions to it.

    The player is able to do a multiple things during the grapple state. The player can create a bungee effect using the COTNROL key while grappling. The CONTROL key is how the player uses the downwards dash I previously touched on. If the player is airborne this will cause them to go flying downwards, and if they're maintaining the grapple state they will be forced back up at a magnitude equal to how far away from the grapple point went. Along with the bungee effect the player can also use their mouse input to effect the grapple. While grappling if the player swings their mouse downwards they will be sent farther and higher with their grapple. This works other way around with moving their mouse upwards as it would cause the player to descend and slow down. The two pieces of media that influenced me to make these interactions were the Spiderman series and the character Pathfinder from the game Apex Legends. At some point in your life, you have probably wanted to swing around New York just like the red and blue web slinger. I wanted that feeling in this game and this was my way of doing it. Additionally I've recently started playing a new character in one of my current favorite games Apex Legends. Apex is a class based, first person shooter, battle royale and the character's name is Pathfinder. Pathfinder's influence comes from his main ability, the grapple hook. How the grapple hook works in Apex is that it factors in both your mouse input and your keyboard input. With these inputs you're able to curve the trajectory your grapple sent you and it always felt really satisfying, so I tried to do something similar with my spiderman swinging motion.

Adding MORE Mechanics

bottom of page