Tag: omnicar

It takes time to make a mod in Teardown. Sure, you can just belt something out and push it on to the workshop, but the mods that seem to endure are the ones that had more than just 15 minutes spent on their design.

I’m a visual person, so when I’m working I like to sketch out things to figure out a specific problem, or just to have a visual representation of a bit of code that I’m working on. It keeps me on track, and is a valuable tool to double-check that I’m attacking something properly to solve it.

Here’s a few of the drawings I made while making the Omnicar, with some brief explanation of what is going on.

Remember Trigonometry? I sure didn’t, so I had to get some brush-up courses and relearn a few things. (I picked up a good deal via Humble Bundle for Gamedev dot tv “Math for games” courses. Cost me $5 bucks, lol.) One of my problems was locking a plane of coordinates to an arbitrary moving target, which required a few calculations. This diagram is basic Trig, properties of Sine/Cosine and how they relate to a unit circle.

The degree markings are how they are represented in-game. In Teardown you get 180 degree plus/minus, switching over at the 0 mark. The quadrants just represent which is positive at that degree of the circle, which helps with troubleshooting things.

Oh hypotenuse, we hardly knew thee! Seriously though, this came out to be more useful than I originally anticipated. Figuring out angles using right-triangles is quite easy and Hypotenuse lengths are useful if you’re doing things around an origin point.

The heavy-lifting of calculating tangent coordinates. I wanted to put sprites on a row of these, so they’d stay with the car and be properly perpendicular. I had to do some other steps that I don’t outline here, but this diagram helped me quite a bit to get it going.

Do you like dynamically resizing sprites? I sure do. This was the hairy bit that I had to figure out with the existing tangent coordinate calcs. Bunch of values that I was working with on a test case, just to make sure that I had it all nailed down before feeding the Sprite Renderer coords and values.

I went through quite a few iterations on how to make the “skateboard” design drive more consistently. Initially the rear of the car would pivot and overtake the front, spinning it around at times. It was very “loose” in its characteristics, so I had to design something that would dampen the Y-Sway. I’m happy to say that I came up with something that worked out.

Using any of the API functions that contain the “Constrain” keyword can yield some rather hilarious results. At one point, I tried a test where it immediately turned the car into a whirlwind of broken parts ascending into the sky. That was quite funny, now that I look back on it.

Figuring out acceleration curves. From what I can tell, most vehicles in Teardown use a linear acceleration model. That works for most things, but I wanted something with a bit more finesse. Enter Quad Bezier curves! With a start, mid, end point I could make a curve to my liking.

The real trick was doing the rescaling needed to take arbitrary bezier 2D coordinates and make them relate to the speed I was adding to my vector forces. That, and making a timer mechanism that allowed me to control the duration of the curve itself, feeding the Bezier function “live” so it would return a proportional speed value in relation to the maximum speed limit.

Did I tell you it got complicated? Oh yeah, it sure as hell did. But it works, so that is what matters. Its pretty nice to be able to “nudge” the forward control and get a smooth rise in speed – so you can control things on the low-end but also do a full burnout to maximum.

Did I mention the bezier curve is adjustable? Oh yes, it is. I haven’t put a visualization of it in the UI, but its in there.

There’s more to come as I complete things. I think I’m at the 90% stage in the project, which means I’m getting impatient to finish and I want to work on something else. I’ll get there though and release it, I promise.

Until next time…

I get ideas from all kinds of sources. Sometimes, I see something neat in a movie, or I look at a website and there’s a cool concept that spurs another idea in my head. Well, I was puttering around and found this video via Hackaday of a lego-ball-driven car.

I have a project list, so I can jot down an idea and assign it a number. I don’t do these sequentially, typically I follow the classic pattern of Teardown (or any other game) modding:

I do actually finish some of them. I do like to rotate between different projects when I feel I’ve hit a wall, or I just am sick of looking at the same thing for months on end. That break usually allows for more thinking about how to improve things in general.

This particular idea was number 25. (As of this writing I have about 47 ideas and I add to that on an ongoing basis.) The concept was interesting to me for a few reasons:

1. There is a built-in vehicle system/entity in Teardown, but its a bit finicky and it is very easy to crash the editor if you don’t get everything just right.
2. The vehicle entity requires a setup that is Magica-native, in terms of a compound model with shapes nested in its structure. (Yet another thing I really don’t want to mess with. I like Qubicle anyway.)
3. Vehicles have some limitations when it comes to behavior of lights – they only turn on when you’re driving, for instance. There are some hacky ways around it, but I didn’t like any of those approaches.
4. Driving using regular wheels means accepting the suspension/turning design, it is very hard to change that substantially with the vehicle entity.
5. Omnisphere wheels are cool as hell, and enable neat tricks like “Crab Mode” when driving.
6. I could make my own light systems and control them however I wanted, including everything else, like chase cams, etc…

So omnicar it is!! My first attempt was rather — plain. But you have to start somewhere, right?

For all intents and purposes, this was the base chassis of the car. Those wheels? I know they look a bit clunky, but the Teardown engine treats individual voxel cubes as spheres for collisions, so I knew they would roll okay. I just had to figure out how to get that done.

This involved making a in-game test rig, where I messed with joints (an entity type that does what it says, links two parts together with varying degrees of freedom) to find the optimum solution. My first try was a cage-like system lined with rollers, but that didn’t perform too well.

The collisions would slow things down and generally it was really clunky. However, I did come up with something — I just had to apply “game logic” to my design process.

(To be continued…)