vector movement - SS Graf Spee vs INS Ajax at Montevideo

[flykiller]

A program to handle this would be useful.

I've written a spreadsheet to keep track of the vector text stack. as soon as I type in (xd,yd) the results are displayed, and backtracking/replacing any number of (xd,yd) is easy. writing it was easy, and expanding it to accomodate any number of ships is cut-and-paste (through copying the output to a text file requires tedious reformatting).

doing it by hand takes about 30 seconds for each line for each ship. backtracking though is a bit irritating.

depicting the spreadsheet results on a graphic is easy. I use a baseline bitmap with all the necessary legend graphics off to one side. I just mark the new locations, then save the baseline. I then cut and paste the legend graphics in their new locations, resize the graphic to its display size (cutting off the legend graphics), and save it as a gif.

ten turns take about twenty minutes. uploading the graphic and writing the post actually take longer than everything else.

this works well enough for a bulletin board game, which is what I had in mind. programming it is probably very simple and might work well in a face-to-face game using multiple display screens. have to look into that - if anyone is actually interested in using such a program. I'm sure the user base would be very small.

 

[flykiller]

final.

I think graf spee fails here because it tries to outmaneuver the ajax. it can't, and in any case that's not it's job, it only has to get to the 100d before the ajax bridges. tonight I'll try to set up examples of how graf spee escapes even though the ajax is in a "powered orbit".

and Scott Martin, I'm still willing to try out Your Idea whenever you're willing.

 

[Andrew Boulton]

I was thinking more of a point and click graphical app.

 

[Richard Saunders]

Hello.
Dont know if this will work (dont have the maths & far to lazy).
Graf boosts outbound directly away from ajax, turn 2 turns in the same direction as Ajax (if Ajax turns clockwise so does Graf).
The Graf boosts at 45deg to line of flight (tries to keep the planet between the two ships).
If its a choice between speed and keeping the planet between them speed looses.
If someone would like to graf it please hold at turn 10, 20, and it may be blatantly obvious it dont work or it may work.

Another thought how many turns for the Graf to straight boost from Video to 100d, this will give the minimum time for the Ajax to move, work out how far the Ajax can move and this will give minimum distance for it to move (dont forget weapon range will increase distance covered by Ajax).
Bye

 

[BillDowns]

Flykiller, In examining the chart & data, it appears that the last 2 turns were the critical ones. Ajax just barely caught the Graf Spee.

Much earlier, when I came to course 270 and told you to run it for 10 turns, I made a mistake.

I should have made my course change to 180 at Turn 28. At that point, it is apparent that you have commited Ajax to the counter-clockwise powered orbit. That's when the turn south should have been done on Graf Spee's behalf. I believe that would have enabled an escape. Can you try that?

 

[whartung]

I'm sorry to butt in, I know I'm starting late here, but I've read the Vector Movement Made Simple, and just want to clarify something.

Given a starting vector, you are supplied the dx and dy, where dx^2 + dy^2 = agility^2.

You then apply that vector change to the current velocity vector.

However, to plot the position of the next turn, do you apply HALF of the new vector to the current velocity vector and plot that?

So, and Turn 0, coordinates are 100,100.

6G dx burn gives us a dx, dy of (6, 0), but the first position is 103, 100.

So, now I burn another 6G dx. So, my new velocity vector is (12, 0), but my new positon is 3 (current position) + 6 (current vector) + 3 (1/2 dx) == 112, 100?

Is that how this works?

so, now with my current position of 112, 100, and my vector (12, 0), I then apply a (4,4) (dx, dy) burn (~5.6G burn). That makes my new velocity vector (16, 4). Is my new position (112 + 12 + 2, 100 + 2) == (126, 102)?

Just trying to get a handle on the details.

Thanx!

 

[flykiller]

However, to plot the position of the next turn, do you apply HALF of the new vector to the current velocity vector and plot that?

yep.

x(new) = x(initial) + x(vector) + x(vector change)/2.

say, starting position (x,y)(100,100), initial vector (xv,yv)(0,0).

the ship applies a vector change of (xd,yd)(6,0) during this initial turn. this means that at the start of turn 2 the ship is at position (x,y)(103,100) and has a vector of (xv,yv)(6,0).

during turn 2 the ship continues applying a vector change of (xd,yd)(6,0). this means that at the start of turn 3 the ship is at position (x,y)(112,100) and has a vector of (xv,yv)(12,0).

during turn 3 the ship applies a vector change of (xd,yd)(4,4). this means that at the start of turn 4 the ship is at position (x,y)(126,102) and has a vector of (xv,yv)(16,4).

if during turn 4 the ship applies no vector change (xd,yd)(0,0) then at the start of turn 5 the ship will be at (x,y)(142,106) and will still have a vector of (xv,yv)(16,4).

</font><blockquote>code:</font><hr /><pre style="font-size:x-small; font-family: monospace;"> (x,y) (xv,yv) (xd,yd)
turn 1 (100,100) (00,00) (6,0)
turn 2 (103,100) (06,00) (6,0)
turn 3 (112,100) (12,00) (4,4)
turn 4 (126,102) (16,04) (0,0)
turn 5 (142,106) (16,04) -----</pre>[/QUOTE]and no need to worry about stepping in late, bulletin boards are not real-time.

(everyone else, I'll be doing the new graphs today, I'm rushed right now.)

10jun edited to correct addition error

 

[whartung]

If I'm derailing this, just tell me and I can punt to another thread or email or whatever.

And I appreciate that you're trying to simplify the process.

The distinction between how you are working your system and how Mayday worked is in this detail about applying half the vector.

In Mayday, as you may know, you had 3 markers. The past, present and future marker.

Game play was you would move your past marker to the present marker, move the present to the future, and then copy the vector from the, now "new", past and present marker to create the new future marker.

At that point, you were allowed to move the future marker within N hexes of its current position, with N being the value of your M drive in Gs. So, if you have a 6G drive, you could move the future marker anywhere within 6 hexes of its starting point.

This is a very simply and straightforward system. And, reckoning that the designer had thought this detail out, I never questioned its "accuracy". I figured it was close enough.

But you bring in the 1/2 vector detail, and that's clearly at least a bit more realistic, but at the price of complexity (vs the Mayday 3 marker system).

After playing with the numbers, this seems to basically be right on. At the beginning I thought it was off for some reason. For example, after 6G acceleration, for 5 turns, I was only 48 units away, rather than 75. But then I realized that you're 48 units at the BEGINNING of the turn, at the END you'll be 75 where you belong.

The 1/2 vector mechanic really adds a lot to it over the Mayday mechanic. I always thought the Mayday mechanic didn't feel right, but I couldn't place why.

Now, if you reconsider your scenarios in terms of using the TNE version of Traveller, and where you're limited by reaction mass, whoo boy, does that complicate the problems immensely.

Then toss in some nice planets to add some varying G in the wrong directions. Nobody ever said space travel was easy.

 

[whartung]

Yea, as a quick followup, looking at the move chart from above, the Ajax is burning fuel like there's no tomorrow.

In TNE, ships had their fuel measured in G hours (1G acceleration over 1 hour). So, if you had a 6G drive, you'd burn 6G hours of fuel to accelerate 6G in a single hours time. Turns were 30 minutes in the game, so 6G Turns was 3G hours of fuel.

The classic Far Trader had about 24 G hours of fuel, a scout had 40, and an SDB has 60.

Your turns are 1000sec, .27 hrs.

The Graf Spee looks like it burn 37 G Turns of fuel, which works out to about 10G hours of fuel.

Meanwhile, the Ajax, burning ~6G per turn, 6 * 37 = 222 G Turns, or pretty much 60 G Hours.

So, if you were a TNE SDB, you may have caught your prey, but you're on your way to a slow fight outsystem because you're out of gas.

Just changes the dynamic quite a bit is all.

For example, the Graf Spee could simply wait out the Ajax until it reached Bingo fuel and then get away. Totally different problem.

 

[flykiller]

The 1/2 vector mechanic really adds a lot to it over the Mayday mechanic.

well, it's a nice touch, but it may not add all that much. implementing it pretty much mandates the use of a text stack keeping track of all the numbers, but if you ignore it then you can use tip-to-tail (or past-present-future) method freely and easily on the bitmap, and this doesn't seem like a bad idea in face-to-face games. but I had in mind games over the internet, and implementing the 1/2 vector distance is no trouble over such a long time frame.

 

[whartung]

Well the problem was that I wrote a simple program that essentially did the tip-to-tail mechanic ala Mayday, and I really didn't get the "vector movement" feeling from the system when I was playing with it.

Part of that was that it was so absolute. I wasn't using hexes, just simple coordinates. So, you would just move the future point "wherever you want" (especially with a high G drive). With a normal vector system (say, like the Asteroids video game), there's a little sense of being not quite in control, since your current actions are so delayed (as you start burning down momentum etc.).

But with tip-to-tail, and "full G" course correction, I don't have that same out of control feeling.

But, with a 1/2 vector mechanic, you will certainly get that feeling. If I have a 6G drive, and I'm going speed "6", I can't simply "stop" the ship, not in one turn. It's going to take a couple of turns to do it.

My point is that it's a lot easier to "overshoot" and miscalculate things when your inputs aren't directly applied.

So, the 1/2 vector mechanic really adds that, whereas the full vector mechanic doesn't do as good a job.

As far as a game mechanic for play, yes, it's much more difficult. You need to understand your position and your future vector. On a hex map, or anything with a low enough resolution, it can be difficult to do the 1/2 vector calculation, and be able to place to the counter properly. In a miniatures system, you have much more resolution to pull this off, so it may be less of a burden.

For example, Brilliant lances had a counter to tell which hex the ship was going to go in to next so that you could have 12 degrees of freedom rather than being limited to the 6 of a hex map. You'd alternate the counter each turn as you zigzaggd along the map. Of course BL was never really praised for its "ease of play".

 

[flykiller]

bill, here's some results when the ajax starts at full orbit vector.

as I thought, graf spee simply rotates its egress vector away from the ajax, and escapes.

if on detecting graf spee moving out the ajax reverses course entirely to intercept the planned escape, graf spee rotates its egress vector again away from the ajax, and again escapes.

looks like a single ship cannot blockade a 100d limit, unless possibly its weapons' range is >4LS.

 

[BillDowns]

So, basically, I just missed the blinkin' window

 

[snort_en]

IMTU I try for a bit of realism. The Graf Spee will have a forward velocity of about 8000 m/sec in the planet's rotational direction when it reaches space (this is based on the speed of a modern day orbital launch-it takes a lot to overcome the rotational speed of the planet so realistically the speed when entering orbit will be the rotational speed plus a little extra with the thrust). At a minimum distance an orbit remaining directly above the starport would be 1700 m/sec so I wouldn't go below that for Graf Spee's initial velocity.

The Ajax I suspect would be in orbit at the 100d threshold directly above the starport. So Ajax would be traveling at a speed of about 47000 m/sec in the direction the planet's rotation.

At 2d the GS will have a 50 to 1 arc/distance advantage (Ajax has to travel 50 times farther for each % of orbital arc traveled. But once you get to only 17d the ratio drops to below 6-to-1 at which point the speed and acceleration/deceleration advantage shift to the Ajax.

Not being a space combat tactician for my day job this is all a guess. The optimal escape position for Graf Spee would be directly opposite the Graf Spee at 17d. Both would be accelerating and decelerating in a way to maintain a relative orbit to each other.

So Ajax is at 100d, speed 47000 m/sec

While Graf Spee is at 17d, speed remained constant 8000 m/sec

Now try to figure out if the Graf Spee could escape given those starting positions and speed.


After thinking about it though, the Graf Spee has the advantage until the 17d mark. It could constantly accelerate inside that distance until it reaches a desired speed. So it orbits faster and faster until it plans it's escape then it pops out when it's advantageous. There would be a best speed at 17d where the 180º positions of the two ships would allow the Graf Spee to escape with ease.

It's even better if you include 3D maneuvering. The Graf Spee could constantly do a barrel roll type maneuver to maintain velocity while moving away from the Ajax.

So I guess after all that I'll agree with the assessment that 1 ship could not blockade a planet.

 

[Douglas Berlier]

Very interesting! It looks as though ajaxwill get a shot off then overrun the Gaff Spee..I am reading along as this goes. Very interested in its application to computerize Brilliant Lances.

 

[flykiller]

just curious. did anyone ever use any of this?

 

[Hal]

I didn't much pay attention to this when I was not in my "Traveller" mode as a GM. However, reading this a little more closely, I have to wonder...


Would a single ship attempting to blockade a planet, rely upon only one set of sensors while on blockade duty, or would it use its ancillary craft to maintain a watch in that portion of the world's hemisphere that it can't directly monitor with its own sensors? Seems to me that the blockading ship was designed incorrectly if it doesn't have secondary and tertiary craft carried aboard. Picket ships are if nothing else, designed to act as early warning craft, even if somewhat "expendable".

It would also be a shame if a blockading ship didn't carry a few sensor drones or even a few satellites useful for just what was mentioned above. Different strokes for different folks.

 

[flykiller]

the scenario was based on a historical event and was simply illustrative. one may observe any number of flaws and alternatives, and that was one of its purposes. your point about monitoring the dark side of the planet relative to the blockade ship is very apt.

I had hoped to illustrate something that could be used in on-line games to depict ship-to-ship combat.

 

[Hal]

the scenario was based on a historical event and was simply illustrative. one may observe any number of flaws and alternatives, and that was one of its purposes. your point about monitoring the dark side of the planet relative to the blockade ship is very apt.

I had hoped to illustrate something that could be used in on-line games to depict ship-to-ship combat.

Gotcha. I don't blame you for trying. It would be nice if somewhere along the line online gaming did have the vector movement software written

 

[flykiller]

vector movement software

I was thinking more along the lines of bulletin board play-by-post. as for software the old game of asteroids was more sophisticated than what I'm doing, and already there are several software games that handle dynamic interactive ship combat.

I ceased work on this some time ago, but lately have taken it up again in an effort to finish or at least launch it. would anyone be interested?