What is Project DSS?
Project DSS is a game about "fixing" *cough* utterly destroying *cough* all of those pesky printers that refuse to work properly. It is a game I'm building entirely by myself in my spare time.
The New Demo
I've been hard working on a new demo with much more content and some story building elements.
Please try it out and let me know what you think!
Well, it should be playable haha. I'm sure there are plenty of bugs if you search for them.
Here are some of the major things I've been working on.
- More weapons
- Weapon selection wheel
- Weapon / Ammo vendor
- New Level
- Player movement has been updated
- NPC conversations / interaction has been modified
- Double Jump ability
- Player guard/duck ability
Known Bugs:
The weapon store UI does not fit on the screen.
Player can't jump while shooting (more specifically, player can't jump after pressing and holding the shoot button. However, the player can still jump first then shoot).
Player will sometimes teleport to the ground after performing a melee attack in the air.
There is a delay when pressing the duck/hide button when standing and shooting (as opposed to running and shooting).
Some other details if you are interested...
Instead of using Physics...
One of the biggest changes (and challenges) for this new demo is the player controller. Before, and in fact for all of my other games, I was using Unity physics to move the character. For example, to move right, the code would be applying an invisible force to the character to literally push the player right. The code was something like:
Rigidbody2D.AddForce(transform.forward * moveSpeed);This works fine for realistic movements and is easy to implement (especially because gravity, friction, etc. is automatically applied). However, no matter what I tried I couldn't get the player to have a more "cartoon-ish" movement style that meshed with the art style. So ultimately I decided to code my own movement system.
Okay okay, so what is the big challenge of not using physics? Well, for me it was properly coding interactions between the player jumping and landing on the floor. Jumping was fairly straight-forward using the following formula for a standard trajectory:
f(t) = -16 t^2+ vt + h
Where t = time, v = velocity, and h = initial height.
The problem comes when detecting the floor. For each frame, the player moves in the downward direction. And for each frame, the distance the player moves compared to the last frame increases (simulating gravity) exponentially. Also for each frame, we need to calculate the remaining distance between the player and the floor. We tell Unity to stop the player from falling if this distance is 0. However, the distance is almost never going to exactly equal 0. Why? Let's say the player in frame i is 1ft from the floor. If the player is traveling at 3 ft per frame in frame i+1 the player will end up below the floor. If this happens, the player is all but doomed to fall for eternity.
My Solution
To solve this, I ended up setting 1) a threshold for the player's speed for falling and 2) a minimum distance threshold for the distance between the floor and the player.
Setting a maximum falling velocity will ensure that the player's distance traveled per frame doesn't cause a problem when checking for a floor.
Setting a threshold to determine when the player hit the floor adds some "buffer" to the calculation. For example, if the player's distance between the floor is less than 1.5ft, then stop the player from falling.
Other problems
There are still problems with this method. For example, if the users computer isn't fast enough and the frame rates slows down more than expected, the distance between frames can increase causing the 2 thresholds above useless.
Anyways, I would really appreciate any feedback you have! Thanks for reading!
