In need of a Good Will Hunting

Hey One,

I'm not a rocket scientist, but I have an MS in Physics and recently wrote a web game with simple orbital mechanics, so I've just been over this problem. :)

The short answer is: you're not going to get a physically accurate simulation without doing the math over short time intervals. However, there are some things you could do that might be "good enough."

First, I'm going to assume that you're using a fixed board. If the planets can move during a game, or even from one game to the next, these techniques will fail, because they all involve doing the math ahead of time.

Second, I'll assume you're using a hex map. That's not critical, but it gives better results than the alternative.

The general idea would be to pre-compute the gravitational potential energy in every hex, and print that value into the hex as a number. You would color code each planet, then for each hex, calculate which planet exerts the most gravitational pull and color-code the hex to match. In some cases, you may find that the net gravity is small enough that you want to ignore its effects. Do not color such hexes.

In this system, you would use the concept of Energy to dictate where ships can go. You'll also need "turning charts," that dictate how many hexes forward a ship can move before rotating 60 degrees. The forward value would depend on the ship's speed -- the faster it's going, the farther it has to travel before turning.

At this point, you can develop a set of movement rules that involve the kinetic energy of the ship's current speed, the gravitational potential energy of the hex it occupies, and energy the player allocates to movement from the ship's power plant. I don't have time to work through the full breakdown at this point, but here is the outline:

1) Your ship's kinetic energy (KE) determines its speed. Physically, the formula is

KE = 1/2 * ship's mass * ship's speed squared

so you'll probably need a chart for ease of reference. Note that, when you do compute the gravitational potential energy of the board, you'll have to assume some mass for the ship. But notice also that the KE computation includes the ship's mass. It turns out the relationship between the ship's speed and the planetary gravitational potential is independent of the ship's mass, because it cancels out, so you can just assume all ships have a mass of 1 for your calculations.

2) At the start of each turn, record the ship's KE + power from engines. Call this the Movement Energy for the turn.

3) When the ship moves from one hex to another, there will be a difference in gravitational potential energy. If the ship is traveling to a hex with a higher energy, subtract the difference in gravitational energies from the Movement Energy. If the ship is going to a lower energy hex, add the difference.

Example: My ship starts the turn with movement energy 5. I'm in a hex with gravitational energy 3. I move to an adjacent hex with gravitational energy 6. This costs me 3 movement energy, reducing my movement energy to 2.

Example: Next, I move into a hex with gravitational energy 4. Since I'm dropping to a lower energy hex, I regain 2 energy, raising my movement energy to 4.

4) If my ship occupies a colored hex, it *has* to move because it's experiencing a gravitational force. If players want to remain stationary, they have to expend energy equal to the energy difference between the hex they are in and the next lowest hex that represents a legal move based on the current turning radius.

5) Players can opt to "free fall" through the gravitational field, in which case their ship must move into a hex of identical color whose gravitational energy value is less than or equal to the hex they currently occupy.

Even with these drastic simplifications, there are some sticky rules. For example, suppose you and I both start a turn with speed 5. We both allocate 5 units of power to our engines, but you accelerate down a gravity well and I thrust away from it. Since I'm moving to hexes with higher gravitational energies, I'll lose total Movement Energy. You, in contrast, will gain it as you are moving to hexes with lower energy.

Common sense tells us that you should move farther than me this turn, even though we started with identical speeds and engine power. This implies your movement system will have account for player acceleration during the turn, which is tricky. Star Fleet Battles had some optional rules for this, but it's the only game I know of to do so.

This is a tough problem -- very interesting, though. Probably the easiest solution is to write it as a compute game and port it to Dralius' table-top projection platform. :)

Best of luck!

Mark

Far to complex for me to comment on the formulae without my brain melting, but very interesting. However, it would make for a great injection of realism in a miniatures game.

Miniature gamers like calculating attack vectors, but would they really embrace complex mathematics and would the required inclusion add to the gaming experience or suffocate it?

I like the idea of using the tabletop projection platform, but not everybody will have access to it.

You could simplify the hardware/software provision and boost the theme by linking the game to a calculative app. The app could display a space grid with objects that could be shifted around to form a representation of the board area the player wishes to move through.

So the player would access the app, shift the game objects (planets and gravitational affectors, represented as objects) to represent the environment. The player would then add the ship to its current location and draw a line of travel to the point they wish to journey too. The app would then display the relevant move data.

This would add to the theme if the app had a spacey graphic design because the players would feel like they are plotting a spatial course for their ship - drawing the player into the theme of the game instead of potentially pulling them out of the theme as they pen and paper calculate a course.