[reposted from kickstarter update]

Working on Rubicon is just a CONSTANT re-crash course in trigonometry. Let me regale upon you the sordid tale of updating the physics!

The demo faked a lot of things in the interest of gameplay (things didn’t have mass, as per se; collisions used maximum armour to calculate momentum, all the ships had hardcoded acceleration/maximum speed). Of course, in order to have gravity/spring effects, I’d need to put the actual underlying machinery in place. It shouldn’t be too hard, I thought- coding 2D physics is relatively straightforward, and most of the time doing so was just killing all of the obsolete workarounds.

But wait! If thrusters provide a constant forward force, everything accelerates up to obscene speeds and it’s impossible to tell what’s going on. Fake physics for the sake of gameplay are required: once the ship approaches some set maximum speed, have the thrusters provide less and less force.

But wait! That makes it impossible to redirect the ship once you get up to that speed, since your thrusters no longer work. So that means that I need to only look at the speed vector parallel to the angle of thrust, as far as decreasing the efficacy of the thrusters.

So, net problem: I need to take an absolute angle (and force), compare it to the parallel vector of another absolute angle (and speed), and reduce the force according to how close that vector is to a maximum speed.

But wait! This makes it impossible to steer finely- if you’re thrusting at an angle close to the one you’re moving at, the new thrusting force is almost zero. So I need to keep track of speed-altering and angle-altering forces separately… and so on.

Leave a Reply

Your email address will not be published. Required fields are marked *

By Olive Perry | © 2020 Wickworks
Proud to be a member of PIGsquad, Playful Oasis, and Explorable Explanations.