Monday, October 15, 2007

Throttling Experiments

This week I returned to my lunar lander project.

The Lunar Lander family of games is ancient (i.e. as old as me), but I've always found them both difficult and dull. I'm attempting to improve the user interface to address these problems. I'm also using a circular world rather than a rectangular chunk, so it's possible to go into and out of orbit.

Orbit comes with its own set of challenges. One of the biggest is time scale. Orbit period increases with the two-thirds power of the orbit altitude, so if you've got a world with a low-altitude orbit of a minute, say, then when you get one radius away from the surface the orbit will take 2.8 minutes. Depending on how frugal the player needs to be with fuel, they may have to wait quite a while between burns. I've got some basic time acceleration implemented to counteract this, and will probably enhance it further as I learn more about what's needed. For instance, the time scale could vary with altitude so that orbits take the same amount of time under acceleration, regardless of size.

At the moment, though, I'm engaged mostly in improving the interface for throttling near the planet. Currently, you steer with the mouse and hold buttons to fire the main rocket. The steering is simple; moving the mouse left or right rotates the rocket. Stop moving the mouse and the rocket stops rotating.

If you were perfect and knew exactly what you were doing, you could land a rocket with a single burn without adjusting the throttle. Nobody's perfect, though, so it's necessary to either stop and restart the engine, or equivalently to adjust the throttle to lower and higher thrust levels.

It might seem obvious to put the throttle on the other mouse axis, but having unrelated inputs on the mouse axes introduces unwanted coupling: it's hard to steer without adjusting the throttle, and vice versa.

Putting the throttle on the mouse wheel works pretty well, if the mouse wheel scrolls smoothly. It makes it harder for the player to use the other mouse buttons, though, since their focus is on precisely positioning both the mouse and wheel. In this mode I offload other things to the other hand, on the keyboard.

Putting the throttle on the keyboard has been problematic. I tried absolute throttle settings on the 1-9 keys, but it's very hard to keep track of where you are. Most of the time when you're landing you want “a little bit more” or “a little bit less” throttle; these are relative adjustments, so the absolute settings are a bad fit.

Another keyboard interface I've tried is to hold A or Z to increment or decrement the throttle setting. Again this is tricky because the adjustment happens at a constant speed. At times this speed is too fast, while other times it's too slow.

The final throttling interface I have is to just use the left and right mouse buttons. Holding the left button generates 1.1 G's of thrust, and holding the right mouse button generates 0.5 G's of thrust. Holding both together generates 1.6 G's of thrust. This interface is nice in that the thrust values are well-known; the player can get an intuitive feel for how strong they will be in each circumstance. On the other hand, because there is so little throttle control, the player has to resort to pulsing the rockets to simulate intermediate thrusts.

Of all of these, I'm most familiar with the last one, but the mouse wheel one is probably my favorite. It allows smooth control of the rocket.

Finally, it looks like putting the throttle indicator up in the top-right corner is a bad idea. When landing, the focus is entirely on the vehicle and its trajectory toward the ground; it's hard to look anywhere else. I am trying to think of ways to communicate necessary information about throttling in this context.

4 comments:

Scott said...

Nifty. I've been thinking about a similar idea. A space game with dynamic zooming that allows you to pilot between planetoids, land on them and explore. Though the emphasis was to be more on space piloting and combat.

James McNeill said...

Yes, it does sound like we're thinking along similar lines.

I've been restricting myself to 2D because I think it makes the controls and display much clearer. As a result, ground exploration is likely to be somewhat dull. I'd had some ideas about that (layered terrain) but haven't successfully integrated them with the rocket flight in my head, so they are on the back burner.

The dynamic zooming is something I've also been working on. Ideally it would always show you just what you're interested in but that may be too much to ask. At the moment my zoom encompasses the vehicle and its unflown trajectory, so when you're sitting on the ground you are close in, but as you take off it expands. There are a couple of problems with this. One is hyperbolic trajectories, where the unflown trajectory is infinite. Another problem is that if you are trying to take off to rendezvous with something in orbit, you need to be able to see where that target is in orbit before you launch.

As far as between planetoids goes -- currently I'm working everything out with two-body dynamics (where one body has essentially zero mass relative to the other). This allows a vehicle to go into an orbit and just stay in that orbit with no course corrections, for instance. I would like to add space stations and possibly an asteroid in orbit around the primary planet; these wouldn't affect the gravity field appreciably.

Multiple planets introduces both more complex gravity, and a much bigger time scale. The extra interest probably makes it worthwhile, though. I've got a separate orrery program that animates the planets and a few thousand of the brightest asteroids. The solar system looks empty until you add the asteroids, comets, and Kuiper Belt objects; then it becomes completely full of possible destinations.

Scott said...

I never intended my planets to be close enough that you would effectively be in the gravity of more than one. I also wasn't thinking of having a realistic time scale in that you would be able to fly between planets and stations in a minute or two.

A game based on the reality of space would be rather boring. Lot's of emptiness, no pretty nebulas filling the sky, lots of sitting around waiting, and no space pirates!

James McNeill said...

Yeah, there is a lot of waiting time in real space. I'm with you in wanting to emphasize fun over realism, although I am probably tilted toward a bit more realism.

I've done some experiments to try and figure out ways to "flatten out" the time scale. I tried adjusting the exponent for the gravity law so it was something other than inverse-square, but that makes orbits break down. There might be some other way to monkey with the basic physics so that the orbit period increases more slowly, without altering the basic geometry of trajectories.

Sizing planets is also an interesting problem. My current zero-elevation orbit time is 100 seconds; all other orbits are longer than that. I want the planet to feel big, especially if there is ground-level movement, but I don't want orbits to take too long. I have to be careful not to make the near-ground maneuvering go too quickly for human reaction, too.