Rocket Science

So much good stuff. Some of it has to do with the engine and Paper Zeppelin others have to do with Star Frog Games. Let's start with the stuff that is applicable today.
Like I said last time, the Rockets that I had constructed played like crap. The issues were many and the problems were inherit to the design. It's the kind of thing that I should have caught before I ever coded the things, but was happy to build stuff once I got into creating the different classes that live in Paper Zeppelin. So the idea that I had instead (spoiler alert - it works awesome!) was to create mortars that would fire and arc gracefully through the air. What I quickly ran into though, was that I had exactly zero idea what equation to use and what variables to feed it. Just so you know, we're about to go deep into the safari part of Mathemagic Land, so hold on.
If you want to know how far something has gone, the equation looks something like this. The specific letters may vary based on who is writing it though:

Distance = Speed * Time

So say you had an object that is going 60 mph, and was doing this for 30 minutes...

Distance = 60mph * 1/2 h

Which would get you Distance = 30. For those of you playing at home, it's important for your answers to make sure that your units (that would be the hour) match. I could have also done this : Distance = 1mpm * 30m...and got the same result.

This, along with some Trigonometry, is how most objects in Paper Zeppelin calculate where they are supposed to be any given moment. It's easy for the most part, and it works. It fails on so many levels with the mortars though. The mortars have a variable speed, since they get slower and eventually fall back down afterwards. The equation I have is for constant speed objects. There is no modifier in play here. Mortars shells deal with the forces of gravity, or a simulation of it.

Clearly I needed an equation that would let me also figure that out. The thing that I realized was that the initial speed was important. So I started with something like this:

Distance = iS - GT

...or Distance = Initial Speed - (Gravity * Time)

If you plug the numbers in though, you get results that don't jive with how the world actually works. The force of gravity is way too weak. The difference also comes out kind of linear. The change in speed is constant. With actual gravity, that's not the case and is actually accelerating. If you don't believe me, consider this - if you jump from your couch you don't have enough time to speed up to lethal speeds, since the time is far too short. If you jumped out of a plane, you would be going considerably faster by the time the ground gave you a big hug goodbye. My mortars were basically jumping from windows and slowly coming back and landing at couch jumping speed. What I really needed, was to make the equation logarithmic, which meant that I had to square something.

When you square something, you start to develop curves, which is exactly what gravity does. Consider when a ball is thrown. It arcs. The issue was finding the right place to square the equation. I'll save the details (since they actually took up a couple of notebook pages and are mostly just incorrect, but I found that I really wanted to square the Time variable and my final equation looks a little like this (by the way actual code notes!) :

D = iST - Delta(T^2)

Delta being a way to say Change in Rate. Anyway, it works, creates a pleasant arc for the mortar to follow. The trick is to figure out that since the only real factor of change is the Time, the change moment to moment will be minor and based on that. The constant values just plug right in at that point. However, this doesn't help me all too much, at least not yet. The issue is that I still have 2 variables that need solving before I can make the mortar shoot an object to the right height.
So the insight that I had was to assume that one of the values was something specific. If you think about an arc for a moment, there is a spot right at the top that isn't moving at all. It's almost an artifact of the math, but you can feel it on a roller coaster, that slightly sickening feeling when you hit the top of a hill at speed. But, since the engine is more than capable of finding a distance between objects and I know where I would like the object to end up, if I use that as my value, I can then calculate the Time something like this:

100 (Distance) = 0 (the initial speed) * Time - (0.2(T squared))
100 = 0 - 0.2(T^2)
500 = T^2
T = Square Root of 500

Let's follow the math steps (I told you it was going to be one of those kind of posts). We have 0 as the initial speed and we know the distance (the difference between the mortar position and the player(s) position). We also know the value of the gravity (0.2 pixels per cycle, or 60 pixels per second) and we are trying to figure out how long the object will take to get back to the ground. We end up with Time being the square root of 500 (about 22.36 by the way). So at 22.36 seconds, the speed that the object is going is the speed that the object should be fired at (negative, of course) and after 22.36 seconds it will get back to the top of the arc, be zero, and do exactly what the original equation promised that it would.
Like I said, it works now. Also, plays great and I'm happy with it.


*********

Right then. I was doing some math recently and doing some thinking about Star Frog Games. Previously I had come to the conclusion that this particular enterprise wouldn't be able to support me financially. I'm still of that particular mind more or less...but then I read something on the Radiangames website. He too is a developer or XBox Live Indie Games, but he does it full time and is way more prolific than I am, with the insane rate of 1 per month. He's currently my Dev Hero. Anyway, he had graphs and things about revenues, which are uncommon to find really, although I'll post my own when I have that information. The basic thing was that all told he sold about 2000 copies on the first month for most games. That tends to taper and average to about 1/2 to 1/3 that for following months. Again, no idea how long those hold though.
However, and this is the cool bit, that continues to stack. If you only make the 1 game per year you will surely starve to death well before anything cool happens. If, on the other hand you can manage something like, 4 games per year, the math works like this instead:
$665 * 12 *4 = $31,920 per year...which isn't very good honestly. I would think that on the second year you get some long tail sales which may increase that ever so slightly. But, if you can somehow find the time to do 5 - $665 * 12 * 5 = $39,990 which puts you well into the range of not being destitute.
So what I can hear nobody saying. Paper Zeppelin is now almost 5 months old and still isn't done. To that, you would be correct. The project that I work on between normal work and school for about an hour per night if I'm lucky still isn't done yet. But it moving along at a pace I continue to be okay with. But with those givens, the math works out, being generous, to around 150 hours invested so far. That's just shy of 4 weeks if I was doing this 40 hours per week. Consider for a moment, that everything that I've put together for Paper Zeppelin, that giant assed list over yonder => has taken about 4 weeks of actual work so far. Suddenly, a 3 month development cycle doesn't seem so impossible anymore. Nor does doing all of this, well, all the time.