> Yesterday I wrote some guidelines for a computer software package that
> could display 3d maps.
My roommate and I spent some time coding a 3d space viewer during
last year/early this year, and learned a couple of things that might
be relevant. Of course, the code is still very beta - no releases
from us anytime soon, although that was the eventual goal.
Apologies, while editing this I lost at least one level of
attribution below. Somebody's respobsible for it.
> > 1. 3d/rotatable (obviously)
> > 2. display name of the star-system beside the identifier on the map,
> > legibly, semi-regardless of the user's point of perspective.
One problem with this: dealing with a 'reasonably large' number of
stars, names quickly become illegible. The solution we've used is a
cursor that moves between stars, and displays name/other info in a
sidebar. You might also want to do something more global, like
turning on/off the names of all stars within Jump-N.
> > 3. use color and size to further distinguish stellar/system features.
> > 4. incorporate an adjustable cartesian grid with numbering displayed.
We didn't do this, because our default environment was 2300, and the
only thing that really matters is the relative position of stars -
we took our data and massaged it to figure out which stars were
within stutterwarp distance of each other, and then toggled off/on
displays of valid stutterwarp routes.
Think about it for TNE - do you really need a cartesian grid?
> > 5. IBM executable (assume SVGA or better)
Has good technical documentation come out on SVGA coding yet? Also,
although we have nice Tseng hardware, we're using something like
640x480, because at that resolution most cards have two pages and so
you can use screen flipping to animate it, meaning it looks _very_
smooth.
> > 6. Input data stored in TEXT file (this is important, because we need
> > to be able to write simple programs to generate this data, and it
> > would be nice to be able to hand-modify it with choice of editor).
[...]
> > But in this way, the users can illustrate their data any way they want,
> > and it won't clutter the map with a bunch of confusing (and often
> > inconsequential) symbols. If the user wants a blue interior to denote a
> > terra-norm world, then that's what it means to her/him. If the user wants
> > a blue interior to denote a hot-blue star, then it means that instead.
> > Different attributes will be important to different people. It's best not
> > to tie yourself down to a single UWP but instead keep the data based solely
> > on the mechanism of the actual map (i.e. what color(s) and size is this
> > "dot" going to have). In this way, as well, the program will be useable for
> > a wider variety of RPGs.
Actually, if we agree with your reasoning I'd use the opposite
implementation - our data set is really really huge (>2MB in some
database formats, I think), and if we wanted to view it differently
we'd have to load up a database manager, select a different set of
columns, map them into color values, save this out to disk as a text
file, and then run the viewer. At least one use I'd envision for
this (although maybe it just means I've spent too much time writing
code to support decision-support software) is players sitting there
interactively getting different views/display formats of what's out
there, changing as they go which subset of the data is shown
on-screen so they can look for patterns. So player ideally says,
"Color blue all systems containing terrestrial planets" and the display
ripples to its new configuration.
This is only a reasonable amount of extra work if you're coding just for
Traveller. Coding for arbitrary SFRPGs is a software engineering
problem that is certainly solvable, given arbitrary resources :)
> _ /| Jim Vassilakos
> \`o_O' [email removed]
> ( ) [email removed]
> U [email removed]
> Aachk! (USA) [phone removed]
Tom
// [email removed]
// "Inquire of the Mathematician as to the possibility of going to one
// hundred five percent on the Turing Machine."