As well as radial velocity, the other component of a star's relative motion is transverse velocity derived from "proper motion", without which you only have half the information you need (the towards/away component but not the "across" line of sight; and at large enough distances you need celerity or proper velocity too.
For what it is worth, a 3-D simulation of the universe is not something I can write code for at this point in time. Simply having a velocity for the star, and the direction of the star's motion in a 2D environment will suffice.
At present - I've been working on coding Vector movement rules for use with what amounts to a virtual table top mapping environment. Center of galactic mass is zero, zero and each star can be located as a Theta/Rho style polar co-ordinate. Each Star would then have its built up velocity listed as a Theta/Rho style co-ordinate such that the GM could have stars move within the campaign if that were desirable.
I've been working on a project on and off, and phase I seems to have been completed successfully. Phase II will be as follows:
Center of Mass for the star system will be deemed zero,zero. Planets that move will be measured in miles distant from the center of mass for the star system. Consequently, ALL planets can be listed such that they have a movement rate in degrees per 20 minute turn (obviously a decimal value unless the planet has a year that measures less than 360 days). From there, planets can move just as starships, space ships, and missiles can move in the Traveller Universe.
For vector movement involving ships, the process is:
A) Determine current location of ship
B) determine built up vector of ship, and add the vector to current location.
C) Add Acceleration vectors as listed below:
1) Ship acceleration in values of 0 to 6 G's.
2) Ship acceleration due to nearby planetary mass (if any)
3) Ship acceleration due to star's mass
D) Determine new built up vector by determining the distance from the old "Current location" to the New Current Location after steps B & C. This becomes the new built up vector for the next turn.
Step A determines what the ship's current X/Y value is. Step B requires that the vector of the built up velocity be added to the ship's current location to reach a new "final location" sans any acceleration effects. Step C requires that all applicable acceleration vectors be added to the built up velocity vector, to determine the final location of the ship at the end of that turn.
Why am I bothering with this? My goal is to - time permitting and INTEREST permitting (ie, do I feel like working on it at any given moment), to code software that will permit a GM to keep track of things in motion within a star system. These things might be:
A) Planets
B) Ships
C) Missiles
The program would track how close any given "thing" is to any other "thing". This would permit a referee to run a fog of war style combat between ships in a Traveller Universe. Being able to list all "participant" ships in a Datagridview and track their location in 20 minute turns would permit all of that to be done. Best of all, it would permit a GM to use the software coding (It would be in VB.NET) to run their own battles whether using CT, MT, MgT,T4, T5, T20, and GT).
Eventually, for my own use, I would code it for use with GURPS TRAVELLER as far as the sensor rules would come into play, and perhaps include coding for ship to ship combat with the weapons involved.
But that's just a pipe dream of Vaporware at the moment. I don't have anyone to use this software with. If I had someone who wanted to participate in something like this, I'd have to start devoting more time to coding - but then I'd be motivated to do so. A win/win in my book.