Been a while since I have last been here, I completely forgot this site even existed...Anyways-

To not have a wall of text, like what I have probably written in the past, and to keep things simple, a few university buddies, alongside myself, have made a game dev team. A friend of mine approached me if I wanted to help him make VR games within Unity, roughly 2 months ago. At the time, he didn't really know I was already doing some sort of dev work within the engine, but I did show him some projects, which left him somewhat stunned (and me perplexed), and after gathering some members, he announced that we should have a game jam of our own, to practice using the engine.

The game jam's theme was "In a land of fire and ash, you must dodge obstacles in a flash.".
I originally had the idea to make a 2D top-down stealth shooter with Matrix-esque elements, but that was scrapped for the one I actually made: a 3D spaceship obstacle game.

The game is very simple & basic. You go forward in a pipe, having to avoid obstacles. You have 3 lives in each stage, a Motorstorm-esque boost system, and a timer. Reach the end of each stage, and then the final stage, to win. I only had about roughly 10 days to make the game, and we had to work individually while being allowed to help each other out if we were stuck. In the end, I'm not exactly sure if we had a concrete "winner", since a friend of mine made a good game, and actually fully followed the theme, while I wasn't able to do so (the "obstacles in a flash" part was present, but no "ash" of any sorts, really). In the end, we both agreed that his game followed the theme, while mine was "more technically advanced".

If you wanna give it a shot for yourself, go ahead. Roughly takes 6-8 minutes to complete the whole thing in one sitting. Controls are Arrow Keys (or WASD if you change the "Single Scheme" option), and Space to boost.
Splitscreen Mode has its own controls, Arrow Keys + M and WASD + T.

If you have a high refresh rate monitor (90, 120, 144Hz, etc.) you might have a slight advantage, because I only realized a few days later that I WAS in fact correct about being suspicious regarding the frame rate, because Mathf.SmoothStep (a math function the ship uses to smooth out the movement) is frame rate dependent.
The whole game was made on my laptop with a 144Hz screen, while my desktop PC has a 60z monitor. The ship being a bit more sluggish hit me like a brick a bit too late, but the game is still playable just fine!

Also, yes, I did in fact just write another wall of text. Figures!

Feel free to ask away about anything regarding the game or anything else! We are currently having a second game jam, which might also see a post in here, if I don't forget about the site again, that is. Who would have thought that university is time-consuming, right?

Game Link: https://drive.google.com/file/d/1U2aYkJDsgUmkHiKLieUQrmKms8eMOp-0/view?usp=drive_link

if you use frame dependent math, then you also must implement frame limit options that adjust for each one, that's why you see games with such options.

...however, is also possible your 144hz LCD has better GPU/CPU than 60hz one, and that's what caused the slowdown, being frame dependent depends on if your code used fixed time steps or not. but i don't use unity so can't help.

Interesting, I remember back in the early 80s a BBS software i used was reported by a user of that older software version was uinusable because it was running to fast on his newer computer.

I found out the software version he used had its timing linked to the processor speed, so his newer faster computer/cpu was the link...

What was needed was to install a timing utility that slowed down the cpu...

Sooooo, programming timing utilities should probably only use the system clock

which i have heard about a couple times over the years...