What about wheelies? that would be easy to make.
True, though it is possible to get stuck in a wheelie so you could technically get infinite points (if it gave you points, that is).
Then make the car stop wheelieing?
An interesting idea, and maybe one that could backfire… but alternatively I could just change the collision shape a little to make it impossible to stay in a wheelie.
I don’t know if I’ll actually implement this either way, but at least I’ll try to get the mechanic working and then maybe just share the code or something.
I’m in third. Watch out Maniac Pumpkin and Noven.
would be a better emoji.
Wohoo!!! 617,000, with 31 flips on hard mode!
My goodness! You’re getting way too good at this . . .
It’s so fun I can’t stop, lol.
@thebrickccentric, I have a recommendation:
It might be hard, but a multiplayer version of this would be great! And There could be up to three players at once, who can all use Spacebar to switch display layers. This means that the cars can crash into each other and go in-front of or behind of others.
What do you think?
Please consider this,
-Ember.Y
That’s a pretty cool idea, and I especially like your idea for layer switching . . . I’ll consider it. Only issue is, while I can definitely get multiplayer games to work in the current framework, having them stay functional is a different story (somehow they have a tendency to stop working over time). I’d love to try it, though it would be ideal to wait until after grazer updates multiplayer.
Also I just added some simple background music (toggle mute with M); if anyone has a better idea for the music, let me know (I don’t love the current song, but it’s all I could find that somewhat fit while being unobtrusive).
Fullscreen now works, too.
I just wanted to say that this is the perfect example of a simple concept well executed.
The only issue that I’ve seen so far is that eventually after playing for a while, I started a new run ([G]) but found that the track stopped generating. This let me fall off and fall through space forever constantly spinning and gaining points (that’s not how I got my 690k score, which is legit; I stopped the game before it got to the point of cheating past my previous high score).
It might be good to add a way to stop this from happening (keeping track of the current lowest point on the track and stopping the game if the player gets too far below, or perhaps better stopping the game if the player has over a certain amount of airtime, etc.).
I also agree that multiplayer would be pretty awesome whether players could crash into each other or were just racing and could see each other’s scores, where crashing would set you back to the beginning of the track, and perhaps players could vote to create a new track.
Wow, I’ve never experienced that bug before but I’m also surprised that I didn’t even consider that a possibility… your solution ideas are good though and I probably should be able to prevent that from happening again.
Thank you for the ideas and feedback!
On account to that same bug, when I played through, I got most of my points through just distance traveled (no tricks or airtime hardly) and by 500,000 it was super laggy to the point I had to stop.
Does the track generate and stay built throughout the run or does it start to delete once the player is far enough away?
If it continually creates the ground and doesn’t delete any, I do think there is a limit to how much objects can be spawned in a given level, but I could be wrong on that. This would explain why the game could have been lagging so bad if it was keeping track of all of the objects.
You could make it delete when the player is at a certain distance from it and maybe have it regenerate behind you if you choose to reverse, that way you can’t drive backwards, fall off, and continually gain points.
Or detect the players Y velocity and if it reaches a certain number (falling) if stops your score and counts like you crashed.
Yes, the track does stay ‘built’ the entire time, mainly for the sake of consistency. Good thinking with regenerating it backwards; I will try that, as well as just storing the object data in lists and respawning it in when it comes close enough to the player…
Ok I have created a simple bit of code to check if the car is more than 128 pixels below the lowest ground object, and if so, you automatically lose and submit the car’s score (I wish I didn’t have to punish players for bugs happening, but there’s not really a way around it if the level doesn’t load in properly).
If you experience the bug again, let me know (also, thanks for not abusing the infinite fall, that was very considerate)
Well, seeing that Noven got to nearly 700k, I had to beat him by an even larger amount. So… I got 830K. By then, my computer’s fan was blowing HARD and my computer keys started to feel warm, so I stopped, submitting the score. ANYTHING to reduce lag would be very nice. MP’s idea is a good one.
Did you check the ground generating code? It might be useful to do a few runs from the editor to watch the code and see what’s causing the ground to stop.
I’ve played the game probably over 100 times, and it’s only happened once, so that might make things a bit hard.
But has anyone had that happen twice? It only happened once out of all of my runs, and when other accounts were used, it only happened once too. Considering that the game reloads each time your press R, there could be two reasons for the ground stopping:
1: It could just be a really REALLY rare bug caused by the code.
2: It could be a one-time crash with the game engine itself.
Anyways, I’ll keep playing. I’ll notify you if it bugs again.
So I’ve just implemented an improvement that I think is a fair compromise between your idea to delete the ground once it’s too far away and still maintaining consistency of the ground’s shape even when it gets far away…
I have the circular ground objects delete themselves if they go out of view, and the square ones disable themselves if they go out of view. When a square block comes into view, it enables itself and respawns its corresponding circular ground object.
I also changed the car’s raycasts (that check if the windshield is touching the ground) to only search for the square ground objects, so the windshield being crushed functions the pretty exact same but the amount of objects it has to check is cut in half. (As well, now the proximities in the wheels are only searching for the square ground objects.)
Hopefully these changes at least help somewhat with the performance (and maybe will enable someone to be the first to 1,000,000!)
I just added some basic achievements too (it’s up to you guys to find them out though)
That was my goal!!!
Sadly, I’m in Canada at the moment, so I can’t play many games. Once I get back home, I’ll be sure to continue trying!
Just for fun today I created a little multiplayer test for this, to see if it would be remotely possible with flowlab’s current multiplayer system, and I have to say pretty conclusively that it would be extremely difficult and likely not worth trying before a multiplayer update. Not only does flowlab really struggle to sync the position of fast-moving objects (and the position-prediction makes the movement very stutter-y) but even a simple thing like syncing the shape of the track would be pretty hard (not impossible, but close to it, and with many places for it to go wrong).
Anyways, if anyone wants me to just try a bit harder and see if I can cobble something together that’s even barely functional, I could, but if not I’m just going to wait until a multiplayer update comes.