Rubicon Kickstarter Post-Mortem

Full disclosure on the statistics of Rubicon’s Kickstarter campaign:

Goal: $2,000
Runtime: 29 days
I set my goal to the absolute minimum I needed to do the project. My expenses were low: I only needed to cover my own cost-of-living and I focused on backer rewards that were mostly free for me to fulfill (emails, beta tester status, adding backer names into the game). After doing the math, I was surprised by what a low number I needed- a lot of video game projects on the site ask for $10,000+. I guess there are perks to doing everything yourself.

[backer pie chart]
[backer source list]

Promotion: VERY little Continue reading

Ship Customization

I want ship modification to be a major aspect of Rubicon. To that effect, I’ve been working to put together a customization system for the game. It’s harder than it sounds! How do you approach putting together a balanced economy of choices?

By looking to see how other people have done it, of course. I tried to boil down the system of provided resources, how players can allocate those resources, and the resulting in-game effects for Mechwarrior 4: Mercenaries. This is what I came up with:

mechwarrior flowchart thing

Continue reading


[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.

Watched your spiel about mixing arcade and depth. Have you tried Starfarer? :)

Finally got around to downloading and playing it. Man! I’m glad you pointed this game out to me. Though I’m going for more arcade-y gameplay, Starfarer has really similar ship construction rules and physics to what I’ve designed for Rubicon. Also, I’m going to try out a couple of their solutions for ship control on problems I’ve been wrestling with. For instance, having the screen actually follow the mouse around though staying anchored to the ship. I think this’ll help with keeping track of the cursor, particularly.

Hi Wick, The new build works on my 1.6ghz netbook :) I have noticed that sometimes the game exits the upgrade screen before I hit enter when I still have coins to spend. And, sometimes the ships guns range gets really short.

Glad to hear it works! Releasing your programs out into the wild is scary.

The upgrade screen thing -> does it immediately exit and go to the next wave or does let you do some stuff first? If it’s the latter, I bet that it just doesn’t flush “enter” keyhits during the game, and stores the event until the next time I check for it- which is during the menu.

The gun range thing -> yeah, right now all shots have some set absolute speed, so when you’re moving in the direction that you’re shooting, you get a doppler-like effect. The next build is going to have shots move at their speed PLUS the speed you’re moving at in their direction, so they’ll have a constant range relative to you.

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