Vector tracker screen shot

[AndyW]

A screen shot of my work in progress. It's plenty buggy yet, but much of it works OK, it only gets dodgy when zooming in close.

In its present form, it handles ship maneuvers in 3D, but only displays in 2D (viewing the x/y plane from "above"). Damn it, Jim, I'm a farmer, not a programmer...

System details are supported, with the Sol system presently used to beta test the code. I anticipate being able to create other systems that can be loaded from a file library.

Planets and stars will exert gravity on the ships, though planetary orbits are not determined by gravity, but rather from the system data. If you notice from the screen shot, all units but one are destroyed. That is because they started near to the Sun, at or near zero velocity, and I did not attend to their upkeep, being too busy getting Crotalus to Earth. The Sun took care of that for me... Well, losing that Tigress put a crimp on the military budget, but what can one do?

As the shading (which can be turned on/off) indicates, the Crotalus is clear of the 100 diameter jump limit.

Other display gems are the azimuth ticks shown, as well as an inclinometer, and ranging bands, which are presently off.

Any un-destroyed vessel can be selected as the POV unit, which is then centered on the sensor screen, and the screen resized to include all units in play. Zoom functions will overcome that default setting.

The most recent source code is hosted at QB64 forum in the 'Programs' section under the title "WIP: Dog fight in space...sort of..."

You'll need QB64 to run this.

 

[Panzerkraken]

I installed it and played around with it some, very fun.

 

[ShawnDriscoll]

Interesting. Have no idea what questions I'm being asked. Ship goes off into infinity.

 

[coliver988]

not yet downloaded or played with, but reminds me of the old Star Trek game on the PDP-10 in college (the real reason I got into computer science!) Plus a much more nuanced approach to a 3D vector game I wrote 3 times over the decades when learning new languages: Apple basic, then Pascal, then PL/B (the latter was previous Databus and when standardized became Programming Language for Business, a sort of cross between COBOL and assembler)

I will have to download and play at some point - nice job!

 

[AndyW]

Apologies for it's somewhat cryptic interface, I've been concentrating on the numbers and graphics processes and neglecting the user friendliness.

There are a number of issues that I need to address, I'm presently trying to improve the planetary gravity and collision routine by implementing a ray tracing procedure. I always wondered what quadratic equations were for...

The Evade/Intercept routine also needs much smarter math in order to avoid the "boing...boing" rebounding effect when set to auto intercept. It simply seeks to close range but doesn't account for timely deceleration, and as a result it ends up seeking back and forth. Back to the drawing board on that one.

The basic workflow as I envision it is to pick each unit as active, give them each their desired vector (V) (azimuth, inclination & thrust(Gs)), and once all of that is entered, commit the movement turn (T). Once a vector is input the program assumes that it continues from one turn to the next unless changed. You can really get haulin' across the system if you leave "the foot on the pedal". Then of course, you'll need room to decelerate. I find it helpful to put in "c" on the vector input when I get about halfway to where I want to be. In that respect, it is very much like CTs interplanetary movement scheme. If a turn is screwed up it can be undone (U), but only once. After the first Undo it only rolls back the turn counter.

Mouse click on a particular unit data field (while avoiding the Evade/Intercept fields), or on a unit pointer on the screen, will set it as the active unit, or you can scroll through them with the arrow keys. The ugly buttons are mouse fields, but I find I prefer the hotkeys anyway. I'll have to spruce 'em up to look like panel controls.

Certain display elements can be toggled on/off to pick and choose what is needed and what is not. Grid, Azimuth wheel, Inclinometer, ranging and jump diameters, all can be turned on or off.

Eventually, when the basic operation is pretty sound, I'm going to make it possible to create other systems and ships for import. Probably with another simple input to data file ap. As it is, ships and planets are in DATA lists for development and debugging. They're not hard to tweak around with.

I'm not planning to add any actual combat mechanics to this, I think that's better left to player characters and dice rolls. This is just a CIC display, something to give the GM and PCs some feedback on what is actually happening without plotting vectors on a table top. I used to run space combat out of my head with no idea how it actually worked, and this is the sort of thing I wanted.

A list of the hotkeys:
'[up arrow] moves active unit pointer up
'[down arrow] moves active unit pointer down
' "+" zoom in
' "-" zoom out
' "X" zoom extents (default: keeps all ships in the viewport)
' "A" toggle azimuth wheel
' "G" toggle grid
' "I" toggle inclinometer
' "R" toggle ranging bands: shaded @ 250,000km/500,000km circles @ 1 & 3 light seconds
' "J" toggle jump diameters
' "V" enter new vector for active unit. Enter azimuth "c" to counter vector
' "T" apply vectors to game turn
' "U" undo previous turn
' "E" edit active unit data
' "Q" end program

 

[Bartleby]

This is super interesting, and inspiring.

What a great idea.

 

[sudnadja]

I've done something like this too, in a sort of home-brew sort of way:

https://i.imgur.com/ekBfwRm.gifv (that was a test flyby Assiniboia followed by a regina approach. Shaded areas are detection ranges.

Pursuit started:


Those are with (more or less) Book 2 ranges and movement rules, though it is in 3d and gravity is computed continuously. Planet and moon movement are also the result of gravity rather than "on-rails" settings.

Have you tried your system in gameplay yet?

 

[AndyW]

I've done something like this too, in a sort of home-brew sort of way:

https://i.imgur.com/ekBfwRm.gifv (that was a test flyby Assiniboia followed by a regina approach. Shaded areas are detection ranges.

Pursuit started:


Those are with (more or less) Book 2 ranges and movement rules, though it is in 3d and gravity is computed continuously. Planet and moon movement are also the result of gravity rather than "on-rails" settings.

Have you tried your system in gameplay yet?

I really like how your approach leaves a track behind, I might try to play with that in mine. With my screen constantly redrawing in relative zoom modes it might be memory intensive to do. I've considered taking the planets off the rails, but gravity computation is a high learning curve for me. That said, I did have the Zho Trader doing an elliptical; albeit unstable, orbit around Sol the other day, so perhaps it would work. At the moment I'm wrestling with a proper way to compute ship-planet collision and possibly landing.

I haven't tried it in game play, it's been a good many years since I've run a game. Most of my core players have scattered or passed away at this point. With the improvements that QB64 has brought to BASIC programming, I've taken up the gauntlet of this project again as a sort of bucket list project. It never worked back then from a combination of QuickBasic's limits and my own.

One of the things I considered doing was to run it on a second display from my laptop that the players could see and interact with. I think it could enhance the experience for the PCs & GM to have visuals and be able to work with actual plausible data, calling out maneuvering orders or, "Cap'n, contact at heading..." etc. etc.

 

[AnotherDilbert]

My limited experience with vector movement is that you have to plan ahead to get where you want. Hence I like to plot projected future movement.

A simple example in 2D:
Ship A (red plot) has just jumped in and intends to intercept Planet (blue plot), while Ship B (green plot) starts at the planet and tries to intercept Ship A. (All object are moving upwards). Current positions are bigger red circles.

Axis are marked in thousands of km.

The top half of the plot, representing the future, will change as the ships manoeuvre.

 

[Bartleby]

Another Dilbert,

This is super cool. I absolutely love this.

For your example, am I seeing the ship arrives from jump at the closest position and then "catches up" to the moving planet?

Could you do an example where a ship arrives from jump in anticipation of where the planet will be, so their travel time is shortened?

 

[AnotherDilbert]

Could you do an example where a ship arrives from jump in anticipation of where the planet will be, so their travel time is shortened?

I does not matter much since we have to match both position and vector:

We change rendez-vouz from turn 29 to turn 28. (Ship B course unchanged.)

 

[AnotherDilbert]

If we instead jump in with matched velocity with the planet, we again take 28 turns to intercept:

Note that we only accelerate horizontally; the vertical speed is constant.

 

[AndyW]

This is exactly the kind of stuff I need to code for. Thanks for the illustrations. Now if only I had learned more in algebra class than how to duck the erasers the teacher used to throw at me...

 

[AnotherDilbert]

No advanced maths involved, just LBB2 plus manual course planning. The plots are Excel-diagrams.

My point is that you should probably plan many moves in advance (both yours and probable enemy moves), then adjust as you play each turn.

Keeping past and projected position (X,Y), speed (X,Y), and acceleration (X,Y) for each round for 20-30 rounds should not consume excessive memory. Worst case it is 6 values of 32 bits per ship per round, or about 1 kB per ship.

 

[Bartleby]

So very cool. Thank you AD.

 

[AndyW]

Pushed the latest update to this. [link] needs QB64

Implemented a single vector ray trace routine to check ship/planet impact. Still a little gimped up, but better than just flying through unscathed. That was a struggle that stymied me for several days. Ships flying into planets will reliably destroy them, but planets hitting "stationary" ships is still buggy since planet moves occur after ship moves. A fast moon can potentially zip through if my ponderings are correct, though I've not verified that in testing.

Also, tired of starting in the same place with the same arrangement, I wrote a random ship placement routine. Centered around a random system body to give some orientation.

Later I will attempt to code for landing ops, at which point planet rotational and orbital periods will determine a ships position.

I contemplating taking a breather from this to write a system generator, after all, we can't be stuck in Sol system forever...

 

[AndyW]

:CoW:

Well, I said I would take a break from the vector tracker to write a system builder to support it....yeah I'll just whip this thing out and be able to import pre-gen systems at the drop of a hat...

HOLY CHRISTMAS! This thing is a brain teaser. I've gained a great deal of respect for those who have accomplished it.