Hi Guys,
A while back, I embarked upon a pet project designing a methodology for tracking locations of starships within the Traveller universe as relates to normal space newtonian movement. The plan was to see if I could do it using the vector movement rules from BOOK 2: STARSHIPS from the original Traveller rule set such that the rules could be used with ANY of the TRAVELLER incarnations. As many of you already know, the process for vector based movement was to follow certain steps:
1) have the current location as a known location.
2) from that location, add to the current location, the vector of the ship's current built up velocity vector.
3) from the location of the built up velocity vector having been added to the "current location" a third point is plotted with this point treated as the final destination point that becomes the "New current location" in step 1.
4) determine the built up velocity vector as being the vector defined by the old location versus the final "new ending location".
5) repeat the steps.
Ok, so how does this help with my project and why am I talking about it here? The nice thing about computers is that they can store all of the plotted locations on a turn by turn basis (where one turn is 20 minutes). Relatively simple physics formulas can be used to determine distances traversed in any given time period. The real trick however, was to simplify all of the calculations such that they can used either by hand with a calculator, or by use of a soft ware program designed to handle all the drudge work and record all of the locations. To that end, this is what I've created as the means to an end.
The original formula for converting polar coordinates to rectangular coordinates required the following:
Note: I can't use the symbol for theta here, so I will use (theta) as its substitute...
x = r cos (theta)
y = r sin (theta)
Converting rectangular coordinates into polar coordinates requires the formulas:
r = (x^2+y^2)^.5
(theta) = arctan Y/X
Now, why is this important? Built up velocity is scalar and is represented by a "distance travelled within a given time period". It is also directional. This lends itself to polar coordinates VERY well. Acceleration is also to some extent, an issue of distance traversed within a time period, as well as directional. For example, if you stated that you intend to travel 135 degrees at 3.5 G's (where the direction of zero degress is due east on your map), you'd be travelling in what amounts to a near fourty-five degree angle towards 10 O'clock. At 3.5 G's, you can determine how far you'd go in 1200 seconds based solely upon those 1200 seconds. So we have what amount to inertial movement (built up velocity) and accelerated movement - both of which can be described easily as polar coordinate movement. Oddly enough? Planetary movement is more easily described in polar coorinates than it would be in rectangular coordinates. Which is yet another reason why one should look at the use of polar coordinates for any given TRAVELLER based campaign movement system.
Which brings me to the final point. I had searched for two years, off and on, for a DIRECT method of vector addition using only polar coordinates. As it turns out, it is not possible. You need to use conversions between the two methods. So here is what I discovered or had to "invent" for myself.
When you want to add the built up velocity vector to a known location that is already in polar coordinates, you need to convert the original position into an X,Y coordinate. Convert the ship's built up velocity into an X,Y coordinate system as well. ADD the two X values together, and add the two Y coordinates together to get your new location created by the vector addtion of current location plus first vector. Once you've done that - the next step is to convert your acceleration into a vector - which oddly enough, is done by means of the formula: distance (or r) = 1/2 acceleration x time^2 (make sure you convert that value into the units you intend to use for the game, ie miles or kilometers). Then, add THAT vector to your previous work, and presto: a mathematical system for emulating the basic components of vector movement from Book 2: Starships.
There is one final step you need to do, and that is update your built up vector based on last position plus the vector of your acceleration (which in this case is equal to twice the distance actually travelled, because distance travelled is not the same as speed attained while travelling during acceleration). Once you update the built up velocity vector - you're all set to repeat the process for the next "turn" (ie, 1200 seconds of time).
I've tested this process by hand, and it works. There are some minor irritations because arctan produces some odd results when used with angles greater than 180 degrees (and I will get into that later). Suffice to state, it is NOW possible for someone to create a spreadsheet in excel that will do all of those steps I mentioned above for keeping track of ship movement within any given star system. It would be even nicer when you think about it, to create a program that does all of this for you and keeps it hidden. All the "wargamer" wants, or all the GM wants, is to know where any given ship will be based on a movement plot, or where a ship will be given a movement plot - at any given time.
For example: suppose you take the time to determine how long it will take for a ship to travel to a point, and based on distance, will take the pilot/navigator of a ship, some 324 hours to reach that point. 324 hours at 1 G acceleration is roughly 972 turns! Who wants to plot each and every move one turn at a time? With this "program" that can be built - one enters in the plot: heading, acceleration and duration. The GM or whomever is using this software application can state "move clock from current time to time + 120 hours. Computer faithfully executes the plot as given, and moves time ahead 120 hours (or 360 turns). It calculates the current position and gives it as a simple (theta)/Distance pairing. No mess, no fuss.
Why is this valuable? With this program, you can now, because it keeps track of ship locations - keep track of missile locations because they follow the same rules as ship movement. You can also determine how far away ships are from each other at any given moment. Lets say for the sake of argument, that someone wanted to run a play by email wargame like game. The one ship is on patrol and is hunting for an enemy ship. The GM has specific rules that he uses for sensor operations, and can now keep one "team" in the dark and giving them only information that their sensors would give them. Two ships running picket duty could give away their position while using active sensors while the prey they seek remains more or less in quiet running mode by using passive sensors. If the player of the prey uses enough wits and is lucky enough that the predators do not spot him, he might slip past them using strictly the rules of the game set the GM is using.
Want to run a piracy hunting scenario? This "software" would let people do it. Want to run a wargame where raiders are slipping into a star system relatively unannounced, and begins to prey on civilian ships where ever it can find them? This will permit the GM to run it, and players to play it.
Now for the finer points in all of this. What I don't have finished as yet, are the rules for keeping track of planetary motion. If a planet's orbit is a perfect circle, this movement can be simulated VERY easily as a function of how many degrees per game turn a planet moves. As there are 360 degrees in a circle, and by definition, a planet moves one complete orbit in a precise time - divide the time by 20 minute turns, and that helps define how much of an arc is described by a planet's motion in one turn. But, as you might guess, orbital motion generally doesn't follow a perfect circle. So, what I needed, were formulas for describing the motion of a planet along an ellipse rather than circle. I also needed to find formulas that describe planetary motion according to orbital mechanics. To that end, I think I've finally found the formulas that will do the trick. They are located at:
http://www.braeunig.us/space/orbmech.htm
and
http://www.en.wikipedia.org/wiki/Ellipse
I'm not TOO good when it comes to using math in those areas. But it seems as though the problem given in the orbmech.htm site, fits precisely what I need. The explanation of the example problem for 1.11 and 1.12 at http://www.braeunig.us/space/problem.htm#1.11 seems to be what I need for predicting where a planet should be at any given time. The information on how to plot a location of an elipse in polar coordinates based on eccentricity of the ellipse seems to be what I need. If I have to, I will attempt to boil down the formulas from the orbital mechanics website and problem 1.11 and 1.12 for use with a spreadsheet until I can get the formulas in my spreadsheet to replicate the answer given in problems 1.11 & 1.12. Then, I'd use that spreadsheet to see if I can get the answer for a planetary body whose distances and radii and orbital mean velocity will be significantly higher than the values given in the example for 1.11 & 1.12 to see if I can use the methodology for my virtual mapboard. If so, fine, if not, back to the drawing board. Thing is? If some of you more adept mathematical and mentally more agile types can give me what I need in far less time than it would take for me to plod about getting it - my "project" can see fruition all that much sooner, and can be placed at the disposal of the Traveller fans.
And thus, ends my update on my project. One reason I took the time to work on this project was because this is one tool that I myself would have wanted for use in a double blind scenario of pirates verus pirate hunters. Too often, people at TML would debate the merits of either pro-piracy or anti-piracy aspects and one person would say "hypotehtically, based on these points, piracy is possible" only to have someone say "Well, based on these presumptions, they trump your presumptions, so there" and back and forth it would go without resolution. With something like this? Gm's can now set the stage, set the parameters, and let loose the hounds (rockets?) Of war and let the whole thing unfold strictly based on the rules or rule set he is using. Now, a GM can set in motion, combat between two opposing military forces (say, re-enacting the fifth frontier war scenarios) where one side is comprised of Player character naval officers and the other side are NPC officers (or if using a double blind game - one side of player characters fighting their ships against another team of player characters on the opposite side fighting THEIR ship). Want to debate the merits of how many escorts a Batron really needs? Use this system for it and watch how much fun it can be as two opposing batrons try to find each other in the dark in a parody of blind man's bluff. Now for the first time, smaller picket ships will become important as the one element long missing from Traveller games is reinstated - the issue of TOO much intelligence. Now, ships will need to fight tooth and nail for every ounce of information they can squeeze from their sensors - with some commanders making mistakes they otherwise wouldn't have made because of them having "tabletop perfect intelligence".
A while back, I embarked upon a pet project designing a methodology for tracking locations of starships within the Traveller universe as relates to normal space newtonian movement. The plan was to see if I could do it using the vector movement rules from BOOK 2: STARSHIPS from the original Traveller rule set such that the rules could be used with ANY of the TRAVELLER incarnations. As many of you already know, the process for vector based movement was to follow certain steps:
1) have the current location as a known location.
2) from that location, add to the current location, the vector of the ship's current built up velocity vector.
3) from the location of the built up velocity vector having been added to the "current location" a third point is plotted with this point treated as the final destination point that becomes the "New current location" in step 1.
4) determine the built up velocity vector as being the vector defined by the old location versus the final "new ending location".
5) repeat the steps.
Ok, so how does this help with my project and why am I talking about it here? The nice thing about computers is that they can store all of the plotted locations on a turn by turn basis (where one turn is 20 minutes). Relatively simple physics formulas can be used to determine distances traversed in any given time period. The real trick however, was to simplify all of the calculations such that they can used either by hand with a calculator, or by use of a soft ware program designed to handle all the drudge work and record all of the locations. To that end, this is what I've created as the means to an end.
The original formula for converting polar coordinates to rectangular coordinates required the following:
Note: I can't use the symbol for theta here, so I will use (theta) as its substitute...
x = r cos (theta)
y = r sin (theta)
Converting rectangular coordinates into polar coordinates requires the formulas:
r = (x^2+y^2)^.5
(theta) = arctan Y/X
Now, why is this important? Built up velocity is scalar and is represented by a "distance travelled within a given time period". It is also directional. This lends itself to polar coordinates VERY well. Acceleration is also to some extent, an issue of distance traversed within a time period, as well as directional. For example, if you stated that you intend to travel 135 degrees at 3.5 G's (where the direction of zero degress is due east on your map), you'd be travelling in what amounts to a near fourty-five degree angle towards 10 O'clock. At 3.5 G's, you can determine how far you'd go in 1200 seconds based solely upon those 1200 seconds. So we have what amount to inertial movement (built up velocity) and accelerated movement - both of which can be described easily as polar coordinate movement. Oddly enough? Planetary movement is more easily described in polar coorinates than it would be in rectangular coordinates. Which is yet another reason why one should look at the use of polar coordinates for any given TRAVELLER based campaign movement system.
Which brings me to the final point. I had searched for two years, off and on, for a DIRECT method of vector addition using only polar coordinates. As it turns out, it is not possible. You need to use conversions between the two methods. So here is what I discovered or had to "invent" for myself.
When you want to add the built up velocity vector to a known location that is already in polar coordinates, you need to convert the original position into an X,Y coordinate. Convert the ship's built up velocity into an X,Y coordinate system as well. ADD the two X values together, and add the two Y coordinates together to get your new location created by the vector addtion of current location plus first vector. Once you've done that - the next step is to convert your acceleration into a vector - which oddly enough, is done by means of the formula: distance (or r) = 1/2 acceleration x time^2 (make sure you convert that value into the units you intend to use for the game, ie miles or kilometers). Then, add THAT vector to your previous work, and presto: a mathematical system for emulating the basic components of vector movement from Book 2: Starships.
There is one final step you need to do, and that is update your built up vector based on last position plus the vector of your acceleration (which in this case is equal to twice the distance actually travelled, because distance travelled is not the same as speed attained while travelling during acceleration). Once you update the built up velocity vector - you're all set to repeat the process for the next "turn" (ie, 1200 seconds of time).
I've tested this process by hand, and it works. There are some minor irritations because arctan produces some odd results when used with angles greater than 180 degrees (and I will get into that later). Suffice to state, it is NOW possible for someone to create a spreadsheet in excel that will do all of those steps I mentioned above for keeping track of ship movement within any given star system. It would be even nicer when you think about it, to create a program that does all of this for you and keeps it hidden. All the "wargamer" wants, or all the GM wants, is to know where any given ship will be based on a movement plot, or where a ship will be given a movement plot - at any given time.
For example: suppose you take the time to determine how long it will take for a ship to travel to a point, and based on distance, will take the pilot/navigator of a ship, some 324 hours to reach that point. 324 hours at 1 G acceleration is roughly 972 turns! Who wants to plot each and every move one turn at a time? With this "program" that can be built - one enters in the plot: heading, acceleration and duration. The GM or whomever is using this software application can state "move clock from current time to time + 120 hours. Computer faithfully executes the plot as given, and moves time ahead 120 hours (or 360 turns). It calculates the current position and gives it as a simple (theta)/Distance pairing. No mess, no fuss.
Why is this valuable? With this program, you can now, because it keeps track of ship locations - keep track of missile locations because they follow the same rules as ship movement. You can also determine how far away ships are from each other at any given moment. Lets say for the sake of argument, that someone wanted to run a play by email wargame like game. The one ship is on patrol and is hunting for an enemy ship. The GM has specific rules that he uses for sensor operations, and can now keep one "team" in the dark and giving them only information that their sensors would give them. Two ships running picket duty could give away their position while using active sensors while the prey they seek remains more or less in quiet running mode by using passive sensors. If the player of the prey uses enough wits and is lucky enough that the predators do not spot him, he might slip past them using strictly the rules of the game set the GM is using.
Want to run a piracy hunting scenario? This "software" would let people do it. Want to run a wargame where raiders are slipping into a star system relatively unannounced, and begins to prey on civilian ships where ever it can find them? This will permit the GM to run it, and players to play it.
Now for the finer points in all of this. What I don't have finished as yet, are the rules for keeping track of planetary motion. If a planet's orbit is a perfect circle, this movement can be simulated VERY easily as a function of how many degrees per game turn a planet moves. As there are 360 degrees in a circle, and by definition, a planet moves one complete orbit in a precise time - divide the time by 20 minute turns, and that helps define how much of an arc is described by a planet's motion in one turn. But, as you might guess, orbital motion generally doesn't follow a perfect circle. So, what I needed, were formulas for describing the motion of a planet along an ellipse rather than circle. I also needed to find formulas that describe planetary motion according to orbital mechanics. To that end, I think I've finally found the formulas that will do the trick. They are located at:
http://www.braeunig.us/space/orbmech.htm
and
http://www.en.wikipedia.org/wiki/Ellipse
I'm not TOO good when it comes to using math in those areas. But it seems as though the problem given in the orbmech.htm site, fits precisely what I need. The explanation of the example problem for 1.11 and 1.12 at http://www.braeunig.us/space/problem.htm#1.11 seems to be what I need for predicting where a planet should be at any given time. The information on how to plot a location of an elipse in polar coordinates based on eccentricity of the ellipse seems to be what I need. If I have to, I will attempt to boil down the formulas from the orbital mechanics website and problem 1.11 and 1.12 for use with a spreadsheet until I can get the formulas in my spreadsheet to replicate the answer given in problems 1.11 & 1.12. Then, I'd use that spreadsheet to see if I can get the answer for a planetary body whose distances and radii and orbital mean velocity will be significantly higher than the values given in the example for 1.11 & 1.12 to see if I can use the methodology for my virtual mapboard. If so, fine, if not, back to the drawing board. Thing is? If some of you more adept mathematical and mentally more agile types can give me what I need in far less time than it would take for me to plod about getting it - my "project" can see fruition all that much sooner, and can be placed at the disposal of the Traveller fans.
And thus, ends my update on my project. One reason I took the time to work on this project was because this is one tool that I myself would have wanted for use in a double blind scenario of pirates verus pirate hunters. Too often, people at TML would debate the merits of either pro-piracy or anti-piracy aspects and one person would say "hypotehtically, based on these points, piracy is possible" only to have someone say "Well, based on these presumptions, they trump your presumptions, so there" and back and forth it would go without resolution. With something like this? Gm's can now set the stage, set the parameters, and let loose the hounds (rockets?) Of war and let the whole thing unfold strictly based on the rules or rule set he is using. Now, a GM can set in motion, combat between two opposing military forces (say, re-enacting the fifth frontier war scenarios) where one side is comprised of Player character naval officers and the other side are NPC officers (or if using a double blind game - one side of player characters fighting their ships against another team of player characters on the opposite side fighting THEIR ship). Want to debate the merits of how many escorts a Batron really needs? Use this system for it and watch how much fun it can be as two opposing batrons try to find each other in the dark in a parody of blind man's bluff. Now for the first time, smaller picket ships will become important as the one element long missing from Traveller games is reinstated - the issue of TOO much intelligence. Now, ships will need to fight tooth and nail for every ounce of information they can squeeze from their sensors - with some commanders making mistakes they otherwise wouldn't have made because of them having "tabletop perfect intelligence".
