Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

9 Neutral

About Brunni

  • Rank

Personal Information

  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Brunni

    Arcade car physics

    Btw, I was thinking about making another post about the spring physics, but I'm puzzled about something. For now I use raycasts to keep the car off the ground from a certain target distance, based on what I described in my previous entry. Now I adjusted the spring stiffness and rest position so that the car drops out if there's either a significant upward impulse, or if there's a sharp bump. Too stiff (& damped) and the car will stick to the ground no matter what, too soft and it'll take off with only the bounce after landing. But this seems fundamentally wrong, as with this approach, the car will stick to the ground even upside down. That is, unless you make the spring soft enough so that the gravity force is stronger than the force that the spring has to bring the car back to the ground. Am I missing something?
  2. Brunni

    Arcade car physics

    Thanks for the link! I'll definitely check that out after I'm done with what I'm doing not (which is not physics). Some progress: CarGame-v6.mp4
  3. Brunni

    Arcade car physics

    OK got it, thanks I switched back to a box for now because the elongated capsule would allow the car to (attempt) climbing on walls 😅 (since I made the capsule to be above the ground so that I use the raycast from suspensions to rest on the ground, the spherical "nose" with a good force applied forward from below the car could allow the physics to rotate it on its back and start climbing. I think I'll switch to a "home" like (triangle for the nose + box). Another thing I struggled with was to get the physics engine to react ""kind of"" natural in this kind of situations: CarGame-v5.mp4 I played Mario Kart on my 3DS the other night… man how good their engine is (it's clear that they don't use a physics engine, and the more I go, the more I see that it's completely pointless, I just have to learn the maths behind the "body.ApplyForceAtPosition" and how a box rotates based on an imbalance of forces at different points in the body) Btw I've posted an article on my blog. I intend to continue as long as it feels useful, focusing on things that the video in my first post doesn't really explain in detail
  4. Brunni

    Spring physics

    This time I want to speak about my early experiences with building a Mario Kart feel for the game, implementing suspensions. I've been holding back because of many findings recently, at a point where I'm not even sure that we need them still Nevertheless implementing a spring will be useful in many other mechanics, and it's probably one of the simplest "complicated things", adding a touch of randomness to your game, and the entry point to bringing a kind of challenges that, whilst they may be frustrating, can sky-rocket the replay value to players. This is the very beginning, so we just have a box, representing our racing car. We'll apply gravity only for now. Gravity just means that for any time step, we're adding an acceleration of "G", the universal gravity constant (or the one that you choose for your game). Concretely, imagine that you subdivide the simulation time into small steps (milliseconds apart), and you compute and apply the forces at that time. The acceleration will affect the velocity, the velocity will affect the position. If you're not convinced, you can try this very simple script into Unity, which you add to a cube that has no rigid body. public class TEMP : MonoBehaviour { private Vector3 velocity =; private Vector3 acceleration =; void FixedUpdate () { acceleration = Physics.gravity; velocity += acceleration * Time.fixedDeltaTime; transform.position += velocity * Time.fixedDeltaTime; } } You'll see that your box accelerates down more and more, just like real gravity. You can try to look at the values to understand what happens. Basically the acceleration is the result of applying the same force constantly (with no other force opposing it). In Unity, the following will result in the same, assuming the cube this time has a rigid body with Use gravity unticked: public class TEMP2 : MonoBehaviour { void FixedUpdate() { GetComponent<Rigidbody>().AddForce(Physics.gravity, ForceMode.Force); } } So the spring is implemented on the same model, because it's what we call a reactive device. As a super simplified description, the spring has a rest compression (a percentage of how compressed it is, with 1 being that it's fully extended, and 0 fully compressed, that is of zero length) which it tries to get back to, opposing what it can of force to bring the objects which it's attached to together. When extended, the spring will apply force to the the item at the other end to pull it (it'll pull the ground too, but since we can say that its mass is infinite and it won't budge, it's enough to resolve it only on one end), the velocity of that item will gradually increase, and with nothing to stop it, the item will go below the rest ratio. When it gets lower, the spring will start to pull it back up, but since the object already has some velocity (inertia) downwards it'll take time to stop and start to go back up. Then again, the object will be pushed up until it reaches the green line, go past it, and then be pulled again. This can be implemented very simply by the following formula: F = -k * (x - d) Where k is the stiffness of your spring (the bigger this, the more the spring will "push" or "pull", so the more impulse it will give to the object toward the rest point, which will make the spring appear stiffer), x is the current length of the spring, d the length at rest (green line above). This will give us F, the force that needs to be applied to the spring at any time (that is in our timesteps, inside FixedUpdate). By implementing that, we'll that typical bouncing effect. In the current implementation, the object will never stop bouncing. For that we need to add what we call a damper. A damper simulates the energy loss due to the action of the spring, so that it might stabilize eventually to the rest point. The formula is: F = -k * (x - d) - b * v Where b is the damping constant, and v is the velocity between the two points connected by the spring. In our case, we can use the velocity of our rigid body, assuming that the ground is not moving. Try it, and play with the damping and stiffness constants until it feels right. I'd suggest printing the values so that you can understand what happens. In another article, I'll elaborate more why we use these springs and what to expect from them.
  5. Wanting to use placeholder models to test my game, I first started with downloading models, such as these: I've tried about everything, but I just couldn't get those to import with materials (or, materials would be imported, but be blank, with settings just grayed out in Unity, see below). So I went on and tried to create the materials on my own, assigning the textures as albedo. This kind of worked, but then I had none of the properties that the author had (probably?) defined, like the metalic'ness and all. I had an object that was a textured glossy plastic basically, nothing like pictured on the download page. I'm also puzzled as to why Unity would create materials but not import the textures, nor allow me to define them. There don't seem to be any log for the import, indicating maybe that it didn't find my textures. One of the models don't even have a MTL file, but they include the textures in a separate folder, and the MTL file doesn't reference them. Not sure at all what we're supposed to do with it? # Max2Mtl Version 4.0 Mar 10th, 2001 # # Multi/Sub Material__11 (1) to come # newmtl 08_-_Default Ka 0.6 0.6 0.6 Kd 0.6 0.6 0.6 Ks 0.9 0.9 0.9 d 1.0 Ns 0.0 illum 2 Then I proceed to import all that in Blender. Then again, no material. I could still redefine all by hand, as with Unity. So I went on and created a UV-mapped cube in Blender (2.79 64-bit, the current one), following this: But for some reason when exporting my FBX file I don't have a Materials folder (nor does Unity create one). I also noticed that Blender seems to do things differently depending on whether you use the Cycles renderer (my default) or the Blender renderer. My unwrapped textures got exported properly with the Blender renderer, and I guess it makes sense to use it if you're gonna delegate the shader and stuff to another software (Unity). In the end I managed to import my cube with one texture in Unity, either OBJ and FBX, by using right-click -> Import Asset… and choosing the OBJ / FBX file (do not care about the MTL, it'll get used automatically upon import), and this would only work if I had dropped my PNG texture into the project first. If I did it later on, I'd have to create another material, assign it to my object and fill the properties myself (Albedo texture, etc.), regardless of format (OBJ/FBX). To summarize, this kind of seems to work, and I kind of can make sense of it, but it seems hugely complex and really wouldn't make sense why some artists provide only the OBJ and no material info, but STILL provide a texture and embed UV maps. Am I missing something here? On your end, what's your usual workflow? Thanks
  6. Brunni

    Arcade car physics

    Really nice! looks like you have very heavy cars and you implemented the gizmos and all! Btw what does your collider look like? Is it a capsule, two spheres, a box, or something custom? (compound)
  7. Brunni

    Arcade car physics

    Thanks! I just went ahead and did it right away It's really just a start and I'll take care of it, including much more laid-back explanations about the algorithmic contents
  8. I always liked playing both Mario Kart (the most was on DS) and Crash Team Racing. There's just something fascinating with the mechanics of the game. I could play it endlessly, despite a small number of different circuits. Actually I like racers in general. Two years ago I made a racer looking like Outrun, which is another type of game which I loved as a child (at a time where games didn't yet have a defined standard, so it was OK to just play to hit the road and explore environments, without princess to save, big boss or other deadly stake). Link: But still, back to Crash Team Racing, I always wanted to make my own clone for fun, and I gave up due to lacking physics knowledge (and free time). This remained a dream though, and this time I committed to it harder, and learned, fiddled with every concept until I grasped it. It started with an inspiring video about Space Dust Racing. I think that's the one mentioned everywhere when it comes to developing an arcade racer. I think I kinda knew that it was lacking a lot of concepts that I'd eventually have to fiddle with, but many people were saying that the theory was alright, so I started. I also created a topic, which I'll now turn to a blog: Anyway as with many things the very hard part was the beginning. It's amazing when I think about how at first I was unsure about everything. About how I had to swallow my ego and realize that I wasn't able to implement a simple spring correctly, or to understand the true implications. Well I can say that I still don't truly understand everything, but it's enough to get what my car does and make it do what I want so so this blog may just start with a common and sweet "Believe in yourself" claim I hope to develop it into a fully playable game (homebrew quality though), focusing on the mechanics, and detail here some specific algorithmic areas. I'm not sure yet of the final form, maybe I'll want to get as close to the CTR as possible. Maybe I'll go for something else and think about special challenges that I could bring to the table. Here's how it looks for now Not playable demo yet, but feel free to leave your impressions, suggestions, and anything that you'd like to see in such a project CarGame-v2.mp4
  9. Brunni

    Arcade car physics

    Thanks a lot for your encouragement @Septopus I'll do as you said then, just need some time to prepare it In the meantime, I managed to get the sideways force implemented properly (got back to dot product and its amazing uses), fixed the suspensions which always cause issues, added friction (separated from the sideways force: it seems like you could go with one that does both, but if you really want the amazing drift mechanics like Crash Team Racing, you'll have to implement it properly. Thanks to that I could also lower the friction to a realistic minimum, and at the same time the force of the engine, so that the slopes provide a realistic slow down), made a more realistic downforce which allows to take loops reliably, put back the vehicle on its feet, computed the vehicle speed (in the flat surface plane, that is not counting the gravity component), added a dropout condition when taking sharp bumps and a few small things. Now I'll have to actually modelize a track. Then add a way to know if you're going forward, if you achieve laps as expected, and handle collisions with other players. That's probably when I'll start to model my car not as a soap box but with spheres or similar
  10. Brunni

    Arcade car physics

    A little demo of what I have so far It's all coming up so nicely. I feel like a student again haha, trying many things until I just get it right (and leave no room for something fishy or not figured out). I'm not completely blocked for now. I'll add the downforce (starting with a simple force parallel to the normal to the ground surface below the car, multiplied by the velocity of the car in its local coordinate system), then friction (so that I can push the engine much further, as it's currently almost free-wheel, and it can fight gravity better, allowing for fun, arcade slopes) and change the shape of the car collider obviously (sphere?). Will keep you posted thinking about starting a project topic btw, if you have something for that? CarGame-v1.mp4 Yup exactly! Thinking about doing exactly that. Like him I have a target suspension compression of 0.75 (well in my system it means the opposite of him, where 1 is fully extended and 0 compressed), so I'm thinking about increasing the damping a lot when we reach 0.25, this way the car body will never actually hit the ground. This is one of the things that are so easy to do when you do it your own way: I believe Crash Team Racing didn't even check for collisions on the bottom of the body, only simple sideways checks, and then restituting the same equivalent force to both bodies so that they split quickly, and for walls it's likely the same as they do in most FPS (one thing that I haven't grasped at all yet).
  11. Brunni

    Arcade car physics

    Thanks for the comments Sorry for the lack of reply, I'm actually working towards it, learning every bit one after the other. So far I've spent the last few days on the springs. I thought I had got it alright, but there's a problem with slopes where the simulation sometimes blows, and it doesn't even support stiff suspensions (k > 150) without oscillating badly, so I'm back at it In the meantime I've got the acceleration and braking working the way he describes in his video. It feels awesome, because no standard car simulation gets anywhere close to that
  12. Brunni

    Arcade car physics

    Hmm sorry for double-checking, but that "only way" means that having just a force that pushes the vehicle back upwards depending on the current compression ratio (== distance from the bottom of the vehicle to the ground) is enough? The standard unity assets use damping, among tons of things. But I don't truly understand this concept, only the formula.
  13. Brunni

    Arcade car physics

    Thank you for your kind comment Septopus Glad to see someone tried that too Yes that's what I'm intending to do, I like the self-taught process here. I have one specific question for now, it's "does it make any sense to implement a spring (suspension) the way he mentions? That is, only with a force proportional to the compression ratio of the suspension.". I've been toying a few days without it and the result is nowhere near satisfying. So I'm just wondering if that could even lead anywhere.
  14. Brunni

    Arcade car physics

    I would like to make a kind of Mario Kart (a little different though, but the base would be great) and therefore I'm trying to acquire the background required to implement that in Unity. I've seen this video mentioned in many places and it's indeed very interesting, so I went on and tried to implement it myself. First, with the car suspensions. The guy doesn't mention the damper (a notion that I haven't quite grasped yet btw), he just talks about applying a force relative to the suspension compression. Is there any way it could work this way, or has he just forgot to mention it? By implementing it without damping my car will "wobble" when on the ground, but then I don't know what constants I should use for the spring. Cheers
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!