Games LIGHT CYCLES

Hi,

did you like the Light Cycle races in the TRON movie? There should be a game that takes the classic TRON formula and makes something fresh, lively and modern with it. That is what I am trying to create with this prototype. I have been inspired by Armagetron Advanced which is an excellent but stagnating light cycle game. I want to take it further by introducing new rules that explore the third dimension.​

Recent builds: Windows, Mac, Linux.​

 

This really reminds me of the snake game added to GTA V Online. I really like how the camera is really far away from the ball, so that the slow camera turning doesn't make the player disoriented in terms of where they're going.

Although I can see some people still having some issues with how the camera works. Therefore an overhead camera mode could be something useful to consider.

With the speed the balls are moving at, I don't think anyone is going to have time to even glance at the minimap (at least I wouldn't), because they would be too focused on avoiding the lines. Although it would be good to be able to see what the map looks like at the end of each round.

The colors aren't too bright, but vibrant enough for you to be able to tell the difference between everything, which is really important in fast paced games like this.

I also really like the kill streak system. It definitely adds an edge to the competitive side of things.

Best of luck on your project, I can't wait to see what this evolves into.

 

Looks neat. I would maybe like an even further-away and higher-up camera so that I can see a bit better what's coming up ahead?

 

Thanks for your replies guys! I will work on the camera distance and angles, will also perhaps add it to the options menu for everyone to tweak.

Do you think this game is suitable for putting on Steam after some polish? What would be the most essential features it needs? (I am thinking AI opponents, curved grid, online play, original music... which of these is essential, not just nice to have?) Should this be a free game, or would it be appropriate to charge a small fee on Steam? Please let me know your thoughts.

 

It should either be free, or $3 max, your choice.
Out of all the stuff you listed, online play, and original music are essential. It would be hard to make a game of this type, fun without original music. Especially one that really fits with the surroundings. And while I'm on the subject of surroundings, 3D environments would be nice, like simple 3D levels, instead of a flat plane in the middle of space.

In a game with little gameplay, everything you mentioned is pretty much essential, or else the player(s) will get bored pretty quickly.

You should also add a points system, or a points mode, where you get points continuously, and bonus points for jumping over lines, turning very close to the lines, and stuff like that, to make people do risky stuff a lot more often.

And most of all, spawning and dying animations and sound effects.

 

Thank you Denis! Very sensible advice on what would make the game a more well-rounded complete experience.

I would really be curious how people feel about TRON and lightcycle games in general? What kind of expansions of the classic TRON formula would you like to see? I have expanded the classic formula with jumping, an open arena, acceleration and slowing down.

What would you be excited to see? Is TRON too basic to be exciting? What about TRON on curved surfaces, like spheres and donuts, as done in Cycleblob or Milksnake?

Here are some screenshots from Cycleblob:




...and from Milksnake:

 

A particle effect from a previous game I made. Working on making the TRON trails look like this.

 

Tile based AI work in progress:

 

I think the combination of those particles, inside an unusual shape like in the two games you mentioned, would be amazing. Because it would really add the edge to make the players pay more attention.

You could also make the trails have different levels of brightness on different levels, so that on some levels it just serves as an eye candy, while on others, it actually helps light up the level and show thew players, what the level looks like, as they play more and more.

Tron in itself is an extremely fascinating and very fun concept, the whole idea of light which can be used to destroy others, whether it's attached to a Frisbee-like disk, or to a motorbike.

It's definitely one of those concepts, that are so simple, yet so addicting. Much like flappy bird.
The way flappy bird kept people addicted, wasn't for the fact that everyone wanted to get to the end. It was the random placement of the pipes, which forced the players to be focused non-stop.

You could do that in this. Add things which make the players put more attention to the level as a whole, maybe moving obstacles, like pillars moving from one surface, and into another.

I'm not saying make a Tron-Flappy Bird baby, I'm just saying add things that would cause the players to have to keep their focus up, more often.

Also, explore how music works on the brain (just in a general sense). Because although you might find a piece of music to be a cool addition to the game, it might make the players really stressed. For example, really fast paced music would be something that I personally would find quite stressful in a game like this. Mainly because it would slowly act up my ADHD, and listen to intense music and keeping up dodging things, would be too much for me. But I really think it will also apply to regular people.

Try combining different types of music and sound, with different levels, to create different feeling. For example, some levels might take place in complex shapes, and have very slow and soft sounding music, while others might be on simpler and bigger levels, but will have fast paced music, to act up the brain once there is little space to move for the players.

 

Thank you Denis, this is really helpful! It's great to brainstorm these things. I agree that randomly placed pillars and holes (which are not the same thing in my game) could prove hugely exciting. Also thank you for your hint about music - I always had fairly fast retro-futuristic synthwave in mind, but slower music might actually calm people down. Thank you for mentioning these ideas.

 

I am gradually coding my way towards procedural generated level geometries. But for now, I am testing this new hand made level:

 

Laid the foundation for procedurally generated TRON grids. Here is a Sierpinski carpet:

 

A record high! Never had that many games in one session before. This was almost 350 games in about 1.5h playtime against my flatmate!

 

Here is a little test ride through the maze from the previous screenshot:



And here is some gameplay on a plain grid:

 

Here are some upcoming grid designs:

 

Playing the new grids is possible now. Here are two new grids in game form and matrix form:

 

Looking great so far!

Question, how did you make the matrix form images? From what I can see it looks like a really clever way of using MS Spreadsheet and graphs, but I'm 99% confident that I'm wrong.

 

Thanks Denis

I am using Wolfram Mathematica, which is a massively powerful software for scientific computation of all sorts. The specific command is MatrixPlot.

 

Thanks to those for expressing interest and replying to this thread, it is good to know that there are a few more TRON fans out there!

An idea that I have been intrigued by recently are surface shaders. The tutorial video below was quite eye opening. The idea I expressed in a previous post - to run TRON on curved surfaces - seems to be best tackled with vertex shaders, just like in the tutorial video. It will take me quite some time to learn how to code vertex shaders, but in the long run I want to make my TRON run on a torus. I am not sure what that does to the gameplay but my inner nerd needs to see this. If anyone has insights on vertex shaders, knows great tutorials, or would like to warn me about rabbit holes please I would very much like to hear that.

 

Finally compiled a new build! It's the first time that my game is ready to test on procedural placed tiles. Collision detection, jumping etc. all seem to work properly now. Will give it a good test with friends and hopefully record a short gameplay video in the upcoming weeks. Here is what it looks like for now:



A nice advantage of this tile based approach is that more things can be controlled by scripts instead of manual object placement. For instance, the confines box (which ends the game if any player leaves it) is now procedural controlled and its margin can be set in units of tile length. In this example, the margin on the XZ plane (which you can see) as well as the hidden Y plane is 2 tiles:

 

After optimisation of the trail algorithm, the physics computation scales much slower, resulting in a great performance boost. Please find below the striking profiler comparison of the old and new collision systems. This optimisation has allowed me to play this game on WebGL for the first without any serious lag or problem.

 

In the previous posts, I modified the level geometry significantly. But after a test with a friend I noticed it does not change the feeling of the game too much.

I was wondering if you have any ideas or wishes about what gameplay elements you would like to see. I have my own ideas and list of priorities/difficulty of implementation, but I would really love to hear from you first.

 

A post-mortem for SUPERCOIL and its legacy for TRON

Here are some musings about my journey in game design and what I am trying to learn with this project. I made a game prototype called SUPERCOIL (see here, or click link in signature). It was a passion project in which I tackled a very challenging high level concept (making a scientific simulation playable - I am a professional scientist and this really excites me). I chose a scientific subject which was relatively basic for me, but having had no previous game design experience, I completely underestimated how hard game design is and overreached. I conflated several things that are in themselves very challenging:

• the extremely challenging problem of creating original and fun game mechanics based on my electrostatics concept
• making beautiful minimalist graphics that look unique, which I think I succeeded at
• creating a platformer-like "experience" and mood, by using lighting, camera movement and original music made by a friend, which I think is a partial success.

The partial success of graphics and atmosphere was uplifting, and got me a certain small amount of attention at a few festivals and an initially lively TigSource thread, a press article, and a reasonably successful trailer. But in the long run, the game never materialised. The reason is that I never managed to make solid game mechanics. I attempted to reinvent the concept through a 2D prototype and a puzzle spin-off prototype, but none of them really clicked. At this point I still like the idea, but can see no clear path to a great game.

The lesson learned here is, as I have found, the same that I learned from science, where I applied it better: Solid fundamentals are the most important thing, without them, a concept will crumble sooner or later. This is what I am trying to teach myself with TRON: I am prioritising making a solid game that works and is fundamentally fun. In my opinion, the most important fundamentals for this game are:

• Solid and clear game mechanics with a good control scheme - this is basically done
• Very good AI. This is what will make other people play the game (or not). This is in early stages, but given my background as a scientist, I think I will be able to pull this of well and this will most likely be the most fun part of the project. But so far, early stages.
• Beautiful presentation. Given my previous game and and its TRON-like beautiful graphics, you can imagine that my hands are itching to make this game look gorgeous. But I restrain myself here - as learned from my previous experience, good graphics before a solid game is a bad idea.
• Expansions of the classic formula - power ups, curved geometry. If by this stage, the rest of the game is great, then these things will be the icing on a cake and will produce the most gorgeous trailers. This will add a bit of novelty and eye-candy. But this only works if it is built on great fundamentals.

Anyway, these are my thoughts. Hope you find this interesting, and now we have a bit of a mission statement for this project. In my slow hobbyist pace, I will keep making this game boring and solid until it feels absolutely great, and once I have achieved that, I will have the basis to make it fly.

 

Some efficiency improvements. Greatly reduced the amount of raycasts to check for collisions against trails. While on the ground, the minimal amount of segments is laid down, whereas in the air more raycasts are performed. This should keep performance lean.

 

Another consideration could be using line segement - line segment c# functions (many online) instead of raycast and of course a quadtree or grid to minimise checks further. Ideally you should be doing around 1-3 checks per frame per player.

I think it could become necessary with lots of players, larger levels or busy levels.

 

Thank you hippocoder, this is interesting. line segment functions and quadtrees are concepts I am not familiar with. Will do some research. You are completely correct, while my method works for now, it will definitely be a problem in the long run.

 

Oh yeah, looking really nice so far!

another optimization idea:

Instantiate a 3D look up table (LUT) with byte[][][] array.

Each trail color represents one of the eight available bits in that byte.

Array resolution will need to be tweaked to be some fraction of your trail width. To make collisions always precise you would also quantize your players trails to conform to that resolution, at say quarter trail width the players would never notice or complain, in fact they would be thrilled to more often hit an edge case where their trail was running right next to another.

As your trails grow out into the available volume they are logically oring their bit volumes into the LUT and also checking for existence of any existing bits in the LUT (collision) before they do that, use same addressing code for both.

Basically you'd be making a painting canvas which you checked for existing pixels and painted in its trail if it was clear, but in 3D.

It's a fast game: your trails are growing faster than (trailWidth/frame) so you will need to interpolate through the array per frame, C++ would be much faster here with raw pointer operations in that array but C# I think is fast enough.

Ideally you would stick it in a separate thread but for proof of concept can just do it in render thread.

With this scheme you would have a fixed per frame computation cost regardless of how many trails you've laid down or how large your playing volume is, you would also not cause much if any GC. Nowadays RAM is cheap so allocating a few hundred MB for the job is totally doable.

It's certainly doable on a large scale if you stick to mainly 2D plane with just a little height for jumps, which are cool BTW! But of course if you constrained to just 2D plane it'd be super cheap and 'easy' with just a 2D array.

EDIT: As it's game over for colliding trail when two trails collide you would not need logical operator to or in your bits, you could just read/write your color indices directly, a little faster and up to 255 trails per game, not that you need that many lol.

 

Just a few more thoughts on optimisation.

My motivation for doing recent efficiency improvements was to get the game to run well on WebGL: If that were possible, it would be the most convenient way for you to play it as soon as I have a rudimentary AI going.

However, after the optimisation I wrote about earlier, the game still runs poorly on WebGL on an average Linux computer (you can try the WebGL build here). According to Unity Deep Profiler, about 45% of total time are still spent in raycasts, and about 30% of total time are spent just drawing my TRON trail (this is a custom mesh which I constantly keep updating, recalculating normals etc.). Further 10% are spent with PhysX processes.

Since the game runs fine as a Windows build on my old laptop, I will stick to developing for desktop for now, and once I have builds ready for you to play, I will use Unity Cloud Build to provide Win & Mac builds. I will keep the optimisation ideas proposed by hippocoder and SiliconDroid in mind for a later stage in development. I'm a scientist and the desire to optimise has been instilled in me since my undergrad education, but I think if I go down that path now, I won't end up with a game!

 

Hi all,

finally, here is a tentative build for Windows (64 bit)!!

In this build, I have turned the red player's velocity to nearly zero, so that you (green player) can explore the different maps, get a feeling for the gameplay, jump, accelerate, jump+accelerate, die, get taunted, and have some fun. Please let me know how you find the game feel, and if there are any technical issues.

Controls of the green player are:

Left/Right: Arrow Keys
Jump (once per game): Up Arrow Key
Go fast (once per game): 'o' key
Go slow (once per game): 'l' key

Have fun, die a lot (even without opponent you will), enjoy the taunts, and pull off some proud manoeuvres like this killer combo by the red player!

 

I have been experimenting with a sort of mean, Mario-Kart-esque special move: If you trigger it, your next turn will be copied onto your opponent no matter what. The opponent will receive a warning sign. Playing this with a friend, I have to say this is a very fun and antisocial kind of move. If you play it well, your opponent will be caught off guard, but if you try to be too clever and focus too much on the opponent, this move will likely kill you.

Here is an illustration of how this works:



This move is still a bit overpowered and there should probably be a longer warning period for the opponent to adapt, but fun nonetheless.

 

I played it, feels nice, yeah I can imagine 2 player would be a blast!

RE core mechanics: I found my humanly possible key tap resolution/rate to be too slow to provide trail placement as accurate as I would like it. Maybe the trail should step down velocity a little as soon as it turns and then accelerate back up to full speed over a second or so, nothing drastic but just enough so that it would actually be possible with skill to thread that trail up a thin opening, at the moment I don't believe its possible without luck.

I know only cosmetic and you are concentrating on core mechanics first but.... I would really like to see a better shader on the trails, something to show off the 3D aspect of the trail, additive blend with edge lighting or something. Having growing 3D trail meshes is expensive, you should show them off more.

Earlier you mentioned:

I'm curious about the details of that, I enjoy hearing about the nitty gritty parts, are you pre allocating zeroed vert/uv/norm/index buffers at game init and then building triangles out into it and applying to model mesh and collider recalc per frame?

 

Thanks SiliconDroid,

I really appreciate that you gave the game a try! Your suggestion about temporarily slowing down for finer navigation is very reasonable, I will implement that and upload a new build. I have already experimented with some other shaders and the low poly 3D looks kind charming (I think) - a bit like very early 3D games, Virtua Figther etc. I currently have problems with orienting the normals, but as soon as that's sorted I will post some pictures

Glad you are interested! Will post some code and explanation after the weekend.

 

Sounds cool.

Get it properly UV mapped and get your normals right and then you open the door to any effect look you can imagine at fairly low runtime cost.

Sorry to go on so. But I've covered similar ground to that you are treading (runtime creation of tube meshes):

Spoiler: Tweet

https://twitter.com/SiliconDroid/status/690639341656346625

I found a good way was to use a vertex "template" helper group: Premade ring of objects representing vert translation and normal alignment. Just copy their worldspace tran/rot into your building buffers. Toggle the UV coords as you proceed to extrude your cylinder if you wish to optimally share vertex (1 vert/quad). This way you just position your template ring where you want it, get the engine to do the math for you and then stitch your triangles, you don't need to calc any tran/rot in script, the engine does it for you on the objects. Normals: simply copy in to your buffers with no math. The helper object representing a vertex just needs to be made to lookAt the circle center when you built your template helper group.

A high potential optimization (maybe you already do this but havent uvd it yet?) in your particular application would be to use repeating UV map to cover the long straight stretches of your trails with just a ring of vertices around each straight section end. Only that ring of vertex positions would then need to be translated and their UVs grown out into repeating UV space as your trail went forth.

 

Hi SiliconDroid,

thanks for your interesting ideas about the trail! A lot to catch up about. In case you are interested in looking at the code of my trail, I pasted it here. I have not yet been able to figure out why my normal are inverted, but for the time being, her is a comparison between my original unlit version and the Unity standard shader, which produces that polygon feel.

 

The normals are correct but you have stitched your pipe inside out. Reverse the vertex order for your triangles, in unity when you stitch clockwise you are looking at the face normal.

RE code paste:

Well it works and is nicely written, so you can keep it as is, but...... if you're interested in optimizing it some:

Currently you're extruding an octagonal pipe. Using 32 vertex per new segment, you can get that down to 8 by making triangles share face verts. Or six if you go for hex extrusion (which actually looks suprisingly round when smooth shaded and fully vert shared.)

You are calling mesh.RecalculateNormals(); this is a heavy func and will repeatedly recalc normals for the whole mesh when called, a linearly increasing cost as trail grows. You should really build out the normal buffer as you go copying in the normals yourself using object helper template scheme mentioned above. You still have to call mesh.RecalculateBounds(); but that's a cheap func.

Myself I would pre allocate a zero mesh with max size (65,536 index) in awake and build into that using scheme I mention above. Pre allocating means no GC at runtime because you write directly into buffers with no need for intermediate copying.

After mesh exceeds 64k you need to start new mesh. But 64k should be enough for max trail in your game, certainly if hex extrusion and you make your straights only have vert rings at start/end.

I've maybe been a little cryptic... To help you get your head round it the method is basically:

Assuming octagonal pipe:

Editor (or do it in code in awake, easier for tweaking):
Make a template object. One root object surrounded by 8 children with radius of trail.
This is your cookie cutter (CC) for copying directly into your vert/normal buffers.
Translate the children to desired vertex radial positions.
Rotate children so their forward vector is radially out (will be your normals).

Awake:

• Alloc int[65536] for indices (triangles)
  
• Alloc Vector3[65536/6 + 8] for vertices
• Alloc Vector3[65536/6 + 8] for normals
• Alloc Vector2[65536/6 +8] for UVs

we need 6* more indices because 6 for each new 2 tri quad.
each new quad only requires one new vert though.
the plus 8s are for end "fence post".
maximum pipe segs allowed = (65536/6) / 8 =1,365

Update:

• Position your CC root to be at the desired face point of your pipe.
• If going straight modify last set vertex else increment your buffer indexes to put new section on.
• copy 8 worldspace positions of children into vertex pos buffer.
• copy 8 worldspace forwards of children into normal buffer.
• derive UVs using flip-flop logic and repeating UV space (so you can fully share verts).
• stitch 16 tris, can use a preset template int[48] array that you apply vert offset to.
• updateMesh.
• Done.

For Collider:

Can just raycast forward from trail head to detect collision with other trail.
Recalculating collider for whole trail is too expensive.
Add seperate invisible collider sections as you grow (can be real low poly), no need to combine them they are invisible, only considered by physics. I would probably use 2 models, 1 for corner, one for straight that gets scaled and collider recalced as it grows.

Yeah it's alot of work but it will run WAY faster like this, webgl no problem.

 

Hey Droid,

thank you so much for the detailed answer! After my somewhat sloppy last profiler test, I somehow thought the trail is not that important for optimisation. I was so wrong. After all the concerns raised in your message I ran a more careful test, and as it turns out, the trail makes all the difference in the world. I ran a game with 20 turns, one jump (in which many trail segments are added), with and without trail (see below). As it turns out, without trails the game runs easily 100fps, but with trail it crawls to about 40fps.

I work very slowly and will try to work through your suggestions. One thing I was wondering is, if you do shared vertices, in my previous experience the surface is smoothed out, which is not necessarily what I want here (I think an edgy look is not bad). My understanding is that this is because normals at verts are averaged when you share vertices. Is it possible to get the rough shading look from the screenshot in my previous post with a shader, rather than by doing the wasteful unique vertices method that I have used here?




Another problem is that in my current trail, the smooth turning of the pipe in 90 degree turns as well as jumps/falls produce far more verts than going straight. The following screenshots illustrate that. This is perhaps something I need to tweak, as the majority of verts comes through pretty arcs that do not matter that much to gameplay.

 

Hi @Instability,

I recently myself saw a shader on the store that gives flat shaded triangles even with shared verts, I can't seem to find it with a quick search now though?? I saw it only a week or so ago. It mentioned it worked with shared verts and was fast. I plan to buy it for a voxel engine I have on back burner: https://twitter.com/SiliconDroid/status/768803076048351232

Yeah, for curves like your pic: provided you can keep each curved section below 300 verts (doable with shared verts i think) you could always instantiate them as separate little meshes and unity will batch them, could probably also make them colliders even. You're not taxing the batching system at the moment so you could get away with say 200 batches even on mobile, way more on desktop.

Of course you could always alloc a few mesh buffers for each player, like above post but no longer the 65k index limit.

With constantly growing trails, no matter what route you take you will have to limit the play volume just to ensure game finishes before lag kicks in.

I try and optimize to the max (still learning slowly), I have to for mobile VR, If i were to tackle a game like yours I would probably make the trails have some finite maximum length, like snake but longer where the tail follows the head. A total cop out I know, but constantly growing out real 3D geometry gets expensive no matter how you do it.

 

Thank you Droid,

I wonder if there is any benefit in instantiation of many meshes rather having one big mesh (like I do), as long as the total vert count stays below 65k? I mean say I instantiate hundreds of the cookie cutter meshes as you suggested, versus coding one giant mesh, is there a difference to be expected? Note that I do collisions differently, so while my big mesh is useless as a collider, that part is OK with me.

I have been working on a new build which includes a minor temporary slowdown after turns to better place sequences of quick turns. Also, hopefully, I shall be able to solve my inside out tube inverted normals problem and use a more interesting trail shader in the next build. It's a work in progress.

I must say the default Unity GUI is infuriating. If you want to hide and unhide interactive elements, there is so much that has to be accounted for (layering of canvas elements in the hierarchy, interactivity, alpha, layout groups ... and anchoring!). It's like the GUI has been designed for RPGs, not simple games. All I want is a basic menu with a few buttons, it doesn't need to scale or animated. I decided to (at least for the time being) use the old Unity GUI (IMGUI) for my options menu. It looks terrible but it works:

 

Really interesting game! I like it very much. Where can I play it?

 

I tried to use simple box triggers rather than raycasts for collision detection. Now AI players can raycast forward, to their right and to their left and see how far away obstacles are. The advantage is of course that from a simple framework of (say) three raycasts (forward, left, right), I can make a simple AI which will work in any level geometry (with obstacles, holes etc.). Soon I will have a build up which will allow you to play against a simple AI.

 

Nice, It's the route I take also, raycasting whiskers, as you say it gives an AI that can navigate no matter where you drop it, a huge advantage, especially for procedurally generated level geometry.

 

Finally I have a very first draft of an AI! You can download the build here. It should be pretty self-contained and playable, there is also a small box with the control scheme in the top left corner. I would be very excited if you guys tried it out, since this is the first genuinely playable build with an opponent.

This is single player mode only. The AI is a very first iteration: It decides turns simply by comparing distance in front, left and right direction. At this early stage it cannot use “abilities” (jump, go fast, go slow). There is also an important bug when the player jumps: trail collider is not interrupted, you cannot go under arcs (will fix this soon).

​

 

I made some improvements to the previous build, you can find the new build here.

 

Experimenting with a mirror reflection shader:

 

New builds available! Windows build here, Linux build here, Mac build here.
You can now toggle between regular diffusive tiles and reflective tiles (like in the screenshot) through the pause menu, which can be accessed by pressing X. Then you have the option to toggle "shiny tiles: true/flase", which will update in the following round.

 

Dramatic game!

Animated gif here.

 

New builds available: Windows, Mac, Linux.

The camera perspective shown in this animated gif (which frames the opponent in the centre of the screen) is now default. There is an option to switch back to the standard camera (accessible in the pause menu which is activated by X). I think the new camera is great for seeing the big picture and aggressive play.

 

just played latest build, looking good but the default camera although giving a more overhead view most of the time, sometimes it blinded me out, I couldn't see what was coming.

 

Thank you, I see what you mean. A target focused camera is actually surprisingly tricky. I am considering to go for the GTA V option, i.e. offer target focus optionally, say while the T key is held down.

 

I have watched some very interesting videos (linked below) on Game Feel recently, which inspired me to work a bit on explosions, destruction and screenshake. I overworked the death animation, which looks like this now:

animated gif here if not showing



I think the smoke cloud and flying pieces feel crunchy, but they kind of obscure the grid, which I don't like. This will require some work and tweaking.

I also found a nice Unity tron game called Ultimate Motorcycles, which has a very nice mechanics. If you go parallel to a trail, you get gradually faster (there is a nice graphical effect too). I really like this mechanics and might try to implement it myself.

animated gif here if not showing


There are many small details that could be added to improve game feel, like better sounds, a little camera shake when the cycle lands after a jump, camera effects to accentuate the acceleration mode / slow down mode, a smoother turn animation, and many other things.

The game feel talks are all on youtube:
[1] Jan Willem Nijman (Vlambeer)'s "The art of screenshake"
[2] Martin Jonasson & Petri Purho (Grapefruit)'s "Juice it or lose it"
[3] Mark Brown's "Secrets of Game Feel and Juice"