When Harry Met GameDev: Faking It Is Good Enough

WhenHarryMetSallySo it’s been a while since I’ve written anything here. There’s a number of pretty good reasons for that—the major one being that I got busy with my thesis project and got out of the habit. But let’s not talk about that and instead move on to getting back into the habit.

One of my little pet projects over my Winter break this year has benefited enormously from a piece of advice distilled out of Bungie’s presentation on Halo’s AI. There’s a bit more of a discussion of the things the slides cover here.

My project has nothing to do with AI. It’s actually a test bed I’m using to get more comfortable with doing 3D in XNA and also to prototype a game idea that’s been sitting on my whiteboard a while (I’m trying not to let things just sit on my whiteboard, but more on that later). The important takeaway from Bungie is that complicated systems can be effectively faked and gamers will be convinced provided the illusion is good enough.

Breaking Down the Problem

ss-orbs-2Orbital Mechanics are complicated. Oh, the basic gravitation equations you can get out of a textbook are simple enough to work with, but the issue rapidly complicates itself—building stable orbits, working out the numbers to make the system look the way you want it, et cetera—it all becomes terribly complicated and time-consuming very quickly.

If you’re building a simulation or game where accurate physics are the core of the whole thing, then it makes sense to spend the time on this. If, however, the orbital mechanics are a secondary or minor aspect to the whole thing, it just doesn’t make sense to devote a ton of time to it when you could be spending that time polishing the important part.

So, for the purposes of the game I’m prototyping, accurate orbits aren’t very important. They should look convincing enough to avoid knocking the player out of their contract with the game, but there’s just no need to suck up time dealing with the complexities of the real physics, as nice as doing so might be. If I were a knock-out orbital physicist or something, it would probably be no big deal to make it work. But then again, I probably wouldn’t be making games either.

It’s worth noting at this juncture that much as the lessons learned from Bungie’s AI team doesn’t have to apply only to AI, the process I’m running through here isn’t useless outside of an orbital space game thingie. I’m going into details as to how I’ve applied the process, but it’s the mindset and such that really matters. Anyway! On with the show.

Understanding Reality


If you were getting excited that we were going to be able to avoid knowing anything about celestial physics just because we’re faking the whole thing, I have BAD NEWS. Nothing could be further from the truth.

Something I learned as an artist, though it in some ways took a while, is that any time you want to replicate something, you must understand it. If you want to produce the appearance of metallic surfaces with paint (which is not metallic) then you’d best understand how light interacts with metal surfaces on some level. Otherwise your efforts are likely to be laughable (yes, working from a reference is some level of understanding!). And so it is in this case. The first thing we need to do is understand some of the salient points of our subject. Frequently, a Wikipedia-level run of research is likely good enough, but don’t assume it always is.

In this case, my long-term interest in space and astronomy means I already knew what I needed to know for this. It basically boils down to a reasonable understanding of Kepler’s Laws.

Faking Reality

So, on to applying what we know of the reality in a fashion that doesn’t require a deeper understanding or time commitment.

The first step, which we’ve sort of skipped over, is answering an important question (probably during research): Does it make sense to fake it, or do we need to really do what we’re aiming for? This really comes down to what your game does in relation to the reality of it all, so I’m going to skip over the details. The answer for this project is no; it really isn’t necessary to worry about accuracy.

For this foray into planetary orbits, we first set down to work out a basic methodology to develop further. At this point, we’re looking at the most basic of basics: Given a stable orbit, what should it look like? Well, when a layperson draws the orbit of the earth or moon, they are most likely to draw a circle around the sun or earth, because earth’s orbit in particular is very close to a circle(the eccentricity is only like .0015 or something—I forget exactly). So, the question is, how to get a circle? Well, one option is to actually calculate out the points of a circle and move the planet around. But that’s a pain and kind of unnecessary with modern hardware. Instead, let’s do it the way a 3D animator would be likely to do it: we’ll take a point, translate it out to the radius, and then we’ll rotate it from the system center. Fantastic, that’s easy, looks great.

Kepler_laws_diagramExcept, of course, that our understanding of actual orbital mechanics tells us this isn’t quite right. Kepler’s First Law specifies that what looks at first glance a circle is in fact an ellipse. Well, what is an ellipse, more or less? It certainly looks like a squished circle, doesn’t it? Can we alter our circle into an ellipse of arbitrary squished-ness? Sure, we just have to apply a scale in one direction and not the other after we’ve made our circle. Sure enough, this works and looks just fine. Except we’re missing something… oh, right, that other part of the First Law. The body being orbited around is at one of the ellipses’ foci. A quick search tells us how to find the focus if we’ve forgotten, and we translate the squished orbit a little to place it correctly. Awesome.

Of course, we notice an issue at this point—the orbit speed. Kepler’s Second Law means on a practical level that when an orbiting body is close to the thing it’s orbiting, it moves faster. Now, of course, there’s specific formulae that let us figure out exactly how fast. But that’s less important than just realizing that it varies inversely-proportional to the distance involved. So we can vary the speed that we’re changing that rotation transform according to our distance from the focus we translated to. And we get pretty decent-looking results, even if they’re probably not exactly correct.

As with the Second Law, we notice we’re smacking into the Third a bit. Larger orbits take longer to traverse than shorter ones, but the way we’re set up right now, two identical orbits with different radii will move the same speed. We’ve already pretty much worked this out, though; we can use the same basic solution we took for the second and use it for the third, this time varying according to the radius of the orbit(compared against a ‘reference’ radius that defines our 1.0 value.

There’s a final refinement that doesn’t come from Kepler’s Laws, but is something I see frequently in games and simulation tools that let one play with orbiting bodies. sometimes you get an orbit that is stable, but it doesn’t scribe an ellipse so much as it wanders around in a vaguely elliptical fashion, sort of carving out a flower shape. This is pretty easy to add by dropping a second rotation at the very end of the whole affair, that takes out elliptical orbit and slowly rotates it around the focus. Again, pretty sure it isn’t actually accurate at all, but it does look about right.

So there we have it. Good-looking solar system orbits for a game without mucking around with anything beyond basic knowledge of the physics we’re trying to emulate and some clever approximations that make the job look vaguely right. Most people won’t even notice the difference, and now there’s all this time to iterate on actual gameplay. And it’s a principle we can generalize and apply to all sorts of complicated systems we might want to represent in a game. Huzzah!

This entry was posted in Everything I Know I Learned From..., Game Design, theory. Bookmark the permalink.

Leave a Reply

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