Interlocking Orbits

This week has focused on figuring out whether having planets move around the sun can be fun.

Moving planets complicate the trajectory plots in a couple of different ways. The simplest is that I need to move the planets while calculating the trajectories. The harder problems are that:

• Close to a planet, the trajectory ought to be plotted relative to that planet's local reference frame.
• When traveling long distances, the trajectory doesn't help rendezvous with moving planets since it doesn't indicate where they will be in the future.

Moving planets also complicate the construction of the solar system, because each planet needs a path that won't collide with any of the others. They may need to be spread out more from each other. To experiment, I adapted my orrery program to generate random solar systems instead of reading data about the real one.



This one really needs to be seen in motion to appreciate it. Here's a Windows executable.

This program is just generating random orbit parameters and then using brute-force searching to see if the new orbit collides with any of the existing ones. I could undoubtedly do better but it proves the basic concepts. I do some simple checks: if one orbit's minimum distance exceeds the other's maximum distance, they can't possibly collide. Otherwise, I figure their common period (m * n / gcd(m, n)) and then integrate along that period in small steps, checking the distance between the planets at each step.

The random orbits are all generated such that their periods are all integral multiples of a common base (the innermost planets' period). There are ten discrete possible periods in the current solar system, which helps me ensure that they will interlock. I'm currently using a bit of a binomial distribution on planet size and orbit eccentricity, so you'll see few eccentric orbits and few large planets.

The current problem of interest is what gameplay purpose planetary motion ought to serve. Does territorial control mean anything in a solar system? If the planets were stationary I could imagine having planetary defenses that would form a “wall” of sorts along the boundary of a controlled region. With the planets swirling around it's not nearly as clear how that would work.

There are points in time where it is definitely cheaper to go from one planet to another; this is why Mars missions are launched approximately every two years, for instance. I don't know if having a delay element like this in a game would be fun at all, though.

“Disneyland” Solar System

Following a suggestion from Kometbomb I've been experimenting with artificially attenuated gravity. Results have been encouraging. I have an attenuation factor that smoothly cross-fades a planet's gravity to zero at a finite distance from it. (It's the usual 3u² - 2u³ cross-fade, although maybe linear would be fine too.) This allows planets to have strong surface gravity without affecting distant areas, so I can pack them more closely together. It's like a Disneyland version of a solar system (or a bit like Super Mario Galaxy, as Owen suggests.)

The cross-fade attenuation doesn't start until some distance above the surface. As long as you stay under that height you can enter stable orbit around the planet.

At the moment I have all the planets sitting still. The next experiment will be to see if motion can be made to work. Planets will need to be arranged so they can't ever collide with each other, so things may end up getting spaced out more. If motion doesn't make it more fun I think the multiple planets will still be all right. I can see interesting gameplay being built from this.

Multi-planet prototyping

The past couple of weeks I've been working on a prototype of multi-planet gameplay for my lunar lander game. Results are not terribly encouraging, so far.

One of the big problems is figuring out how to miniaturize the solar system without getting totally wacky gravity. On Earth's surface (if I've done my calculations right) the acceleration due to the sun is about 1600 times weaker than the acceleration due to the Earth itself. Thus it doesn't much matter where the sun is in the sky; up is always pretty much the same direction.

I would like to have a smaller, denser solar system to cut down on travel times between planets. Unfortunately in my experiments so far this results in slanted gravity as the sun and other nearby bodies move across the sky.

Our solar system has about 99.9% of its mass in the sun. Thus, there's very little gravitational influence from one planet to another. As I distribute more of the solar system's mass to the planets this makes it harder to fly between them due to the perturbations. (It would also make their orbits unstable but I'm restricting them to only pay attention to the sun's gravity.)

I'm also hitting numerical precision issues as I expand the play area, so I'm trying to track those down.

I may end up falling back to having an “overworld map” for travel between planets, similar to Gravitar. This would lose some of the wow factor that continuous flight between planets would have, but you could operate on different time scales in the two modes and reduce boredom and precision problems.

Planning for 2011

In addition to working on sound over the holidays I did some unsuccessful further experiments with the game camera. I want threats to be visible on-screen whenever possible. What I tried was to collect up any turrets that are close enough to hit the rocket, and include them in the set of things that the camera frames. Unfortunately this introduces big discontinuities in the framing circle's position and size as turrets enter and leave. I have camera smoothing, of course, but even so it is much jumpier than I would like. Maybe I need different "frequency bands" of smoothing, with the threats coming and going on a much lower-frequency smoother. I don't know.

I'm in the middle of planning for the upcoming year. At my day job we are in the last couple of months of development on Infamous 2, so that will demand a fair amount of time. Nevertheless I'm going to attempt to devote an hour a night to work on my own projects; this is what novelists with day jobs do, and I'm not going to get much of anywhere on less time than that.

I'm giving up any TV watching that I used to do, as well as most videogame playing that isn't with my daughter. (By the way: it seems to me there is a major dearth of games that are great for playing with your five-year-old. Currently I'm working through Lego Harry Potter with her. This seems like a potentially underserved market.)

In the near term on the lunar lander game, I'm going to do some experiments to determine the feasibility of having multiple planets that you can fly between. This is the major purpose of rockets, after all, and it's a feature most people who've played it have suggested. The big questions are:

Will this work with the physics engine? I'm going to have several very complex objects moving around (the planets) where I used to have most of the complexity in the static part of the world.

How will gravity work out? Currently the gravity all comes from a single point source, so orbits are straightforward ellipses, and are stable. I'm not too worried about having multiple gravity sources for the player; the rocket flies around under power most of the time and doesn't care if its orbits aren't stable. The mothership can stabilize its own orbit with its thrusters; it's already doing that to some extent. I will probably have to fudge the planets themselves so that they don't affect each other, to ensure that they have stable orbits.

How will the camera work out? Currently the camera rotates so that "down" is down. If I have multiple sources of gravity then there will need to be transitions between orientations so I'll have to figure out how that works.

I will reduce the planets to simple circles for purposes of the experiment, to work out travel times, camera, and so forth.

Treasures of a Slaver's Kingdom is Now Free

Good news, everybody! S. John Ross' magnificent text adventure Treasures of a Slaver's Kingdom is now free.

• Play This Thing review by Emily Short
• My review (not nearly as well written as Emily's)

Enjoy!

Vorbis decoding working

OK, I feel like an idiot. Finally ran down the problem with my decoder, and it turned out to be due to accidentally reading the file as text rather than binary. One of the oldest mistakes in the DOS/Windows-programming book. As soon as the file read encountered the magic DOS end-of-file character it quit reading.

I still think the Ogg format's unnecessarily complicated, and I'm not sure Vorbis is the best choice for dialog lines. I don't want to pay ~4 KB per line of dialog in my game for a bunch of identical decode tables, along with the CPU and memory to unpack them every time I play a line. You could imagine putting all the lines in one Ogg stream and then seeking to the appropriate line, but that would require creating an index, something that Ogg itself doesn't provide. I may take a look at using GSM-style linear prediction compression if I can find a decent implementation.

Ogg = Lame

On further debugging I am forced to conclude that the Ogg container format is lame. This is not saying anything about the Vorbis compression format; I haven't delved into that other than to note that it has quite a bit of overhead for small files, at least the way Audacity encodes it.

Here is a good explanation of the ways in which the container format is unfortunately designed. For my purposes, the main problem has to do with how packet size is encoded. They didn't want to put a fixed-size 32-bit value in the packet header because they expected typical packet sizes to be under 256 bytes. Never mind that they have at least three other wasted bytes in their header, and they chose an encoding scheme that made their header variably-sized. The encoding scheme for packet length is this (feel free to laugh): first, a count byte. Then an array of that many bytes. Each byte represents a part of the size count; to get the full size, add them all together. You are expected to set the first N-1 bytes to 255 and the last byte to the remainder. It's sort of the inverse of compression, really. They should have thought very, very hard before making their packet headers variable size. And then if they really, really thought it was a good idea they could have used the UTF-8 style of encoding arbitrary-size numbers.

The decoder I was reading followed the spec in that it assumed that a non-255 value indicated the end of the array (it isn't paying attention to the count as far as I can tell). However, all the files I've encoded with Audacity have an early packet with a non-255 value in the initial byte, followed by a bunch of 255s, followed by a non-255 final byte. The initial non-255 byte is causing the decoder to prematurely think it's reached the end of the packet.

It's telling that Wwise (an audio middleware provider with which I am familiar) supports Vorbis compression but wraps it in a RIFF-style container format (what .wav files use) instead of using the Ogg container format. (Confusingly they retain the .ogg file extension, though.) It'd be nice if there was a standard for this; I'll have to investigate.

Ogg Vorbis

I have been debugging stb_vorbis.cpp, Sean Barrett's Ogg Vorbis decoding library. Somehow it is not unpacking the Huffman code tables correctly. Since it is broken on every .ogg file I've tried I think it must be somehow related to the way I'm compiling it.

Digging into the .ogg file format has been interesting. All the audio I record has identical code tables on the front (I'm encoding with Audacity), which amount to about 3.5 KB. Ogg is different from other compressed audio formats in that it doesn't have any assumed decoding tables; they all have to be embedded into the file. If you put individual lines of dialog into their own .ogg files that adds up to quite a bit of overhead (about 20% for my lines which are currently around 17 KB each).

A tidbit I learned: DVD audio is sampled at 48 KHz, rather than being the same rate as CDs (44.1 KHz). I'd wondered why PS3 games had 48 KHz audio; now I know why.

I've been thinking about how to complete my lunar lander project so I can move on to others. Part of the problem is that I haven't really settled out which direction I want to take the gameplay. More later; have to go to work now.