In-Game Map

[Shark]

I don't think map objects should be displayed using circular/elliptical icons. I think that should be reserved for the location pointer and system elliptic. I think you should stick with polygons for planets, stations, stars, etc.
Also, the grid doesn't really serve a purpose when you can rotate the map.

[scheherazade]

icons are a good scale solution.

imageine a real-scale system.

if you were to see the whole thing on map at once, the planets would be invisibly small.


the icons are modelled after actaul standard military notation.

you'll see the same icons used here and now in reality.

plus daniel thought they'd be neat

-scheherazade

[hellcatv]

yep reminds me of that ole game Harpoon

[hurleybird]

Heh. My dad used to play that game like 5 years ago. Ultra realistic (to the extreme) but not very fun.

[Shark]

I don't think map objects should be displayed using circular/elliptical icons. I think that should be reserved for the location pointer and system elliptic. I think you should stick with polygons for planets, stations, stars, etc.
Also, the grid doesn't really serve a purpose when you rotate the map.

I meant, you should stick with polygonal icons (as opposed to circular/elliptical ones) for planets, stations, stars, etc.. I don't have anything against icons. I just think the circular ones should be replaced with squares, rhombi, triangles, etc..

[fizze]

yep, definetly we need icons... what about nice SVG ones ?

anyway, the in-game map needs a major redo, which is begin done, I think.... hehe


the jump-point-system overview thingy (name ?) is terrible enough, but its usuable. the in-system map view is just bogus to me. too much information.
and those icons arent explained anywhere. so I only use the map for setting routes.

anyone played Ascendency ? i liked the display there.

[scheherazade]

the map in the CVS is touched up from the last release. its more readable.

also, the icons have text names below them, so they don't really need much explaining.

after i finish the planet generator i'll get back to touching up the nav screen.

one problem with it is that there is too much data.
ideally i'd like to make it so that you can see the entire galaxy at once, BUT, that would mean that 109324908720985720398 nodes and links are visible at once. and that means shit runs nice and slow.

PLUS if you can rotate and pan, (which i'll add eventually) it means that there is no ez way to speed things up. (like stepwise disqualification)
i'll have to make like an 8-way tree and just volume bin the entire galaxy,
and then search every time i wanna display.
that way i can keep the coordinates on hand in some sorta managed memory.

it'll STILL run like shit if you view the whole thing... but at least the speeds zoomed in will be faster.

anyways... off to do more school work.

-scheherazade

[mkruer]

Awe crap that means I will have to wait for a 67-bit chip now.

[hellcatv]

if you precomputed how the universe looked and saved it as some sort of vector format it would probably not take nearly as long to render as it does now

part of the problem is that it has to go through those maps every frame and figure things out

[scheherazade]

if you feel like pointing me to something that explains how to permanently store a model in memory and then just transform it by changing the projection matrices, then i'll change-up the map to run nice and fast.

but even so, i donno how you'd interact with it, since you can't just forget it. you gotta have the game itself know where things are so you can klik on them and slect them, etc.

could maybe do a thing where you see the entire thing as a model, and hten highlight a region, and then its blown up and is interactable.

-scheherazade

[zero_kelvin]

[Disclaimer: I spent 5 minutes thinking this up so if it's crap you know why.]

Okay we have a problem. We need a simple yet detailed map that can show where we are in space-time relating to other objects ocupying (sp?) said same space-time.

We may wish to know where we are if the hyperdrive fails midway between systems- like in Elite and I hope this function gets added - or if we're planning a trip from system to system, or if we're in-system and need to know how to get to Bob's Space Trucker Stop with Bar and Grill.

Why not have one map, four layers? Game automatically overlays layer over layer and removes bottom or top layer depending on whether you're zooming in or out (seamless map change). Player is constantly marked as an inverted cross with a slightly lighter centre pixel.

Layer one - long to mid range star map viewing ranging from the galaxy to a grid map about 10 light years wide - x,z grid lines marked out in 1 light year spacing at full zoom in. Stars are marked as filled in circes with their colour representing the real-life star type - yellow sun, white dwarf, maybe dark gray for neutron stars.

Layer two - Range is 9.9999999 etc light years to 1 light year. Selecting a system brings up general usage info from the Ryliean Intergalactic database (convenientally translated into a local terran language) like system population, star type, chief exports, chief imports, blah blah blah. Colouring like Layer one.

Layer three - long to mid range in-system map. Range 1 lightyear to 5au. Planets and moons are filled circles proportional to in-game size (so when you come across that 100x sized Jupiter planet you can go "Munterfrucker!"). Man made objects are roughly shaped icons corresponding to their in-game shape - e.g. toroidal stations are a donut.

Layer four - range 4.9999999 etc au to 0.5au.

Through out these map interfaces/zoom levels a few things remain constant -

* The player is always marked with an inverted cross with brighter center pixel.
* Tracking options can either be the viewing region is adjusted by the player, or "fixed" on the player.
* The map is not automatically updated when something happens out of the players applicable radar. For example, say someone builds a death star euqivelant and blows up earth. The player should encounter the debris and wreckage when they enter the system near earth but their map should show earth until they press the "update"/"rescan" button.

That's just my thoughts and it took longer to write them then to think it up so don't go saying it wasn't thought out properly cause I know that.

[Shark]

In Homeworld, there was a smooth transition when you hit the space bar to the "Sensors Manager". It would be cool if you could hit the space bar once again to get another smooth transition to the map.

[scheherazade]

no matter how many layers, you still need those layers to show something.

and that something is 10032490872509827 points and links.

the problem is more in depth than you make it seem.

the 'something' that you display in itself requires calculation. no matter what scale it is taken to.

to make things fast, we would need a static kind of data representation. something that you can not interact with that could serve as a zoomed-out general view.

up close nothing can be static because you need to be able to interact.

and secondly, if you wanna do a galaxy-wide search, then nothing can be static.

therefore, it comes down to just finding the least expensive solution out of the expensive solutions...

-scheherazade

[zero_kelvin]

I don't know how the vegastrike system stores models positional x,y,z data so I'm probably off-base here but is this a bad idea?

I'd think there's no need to display, or even calculate where every object in the galaxy is every time someone looks at their map.

The only thing the player needs to see on maps are objects that he's either explored and recorded, or bought from a map merchant or a dude in the pub, so the only thing the computer needs to calculate is:

Zoom level = 5ly^2 viewing window with player looking at central coordinates 134,560ly by 44,564ly.
From database of planets, pull up spacial objects within the 25ly square area and display/prep to display on map if either within radar distance from player or if in map from exploration/purchased supplemental.

I won't say it's easy but I don't think you'd have to do something like calculate for every object in the galaxy every time someone wants to look at their map.

Create a database table of x,z coordinates for stars (measured in light years), another table for system objects (measured in astronomical units), and another database containing basic properties of the different objects with an option for an "include" file for specialist places like, for example, Ye Olde Swarthy Pirate Base near the second moon of the third planet orbiting the secondary star of Titi Ceti.

If these tables were looked up with zoom factor, player position, and history of exploration taken into account then it could be detailed but not too complex to display.

[scheherazade]

well, i'll give you a point per point reply since its the easiest thing to do.
here it is :

The only thing the player needs to see on maps are objects that he's either explored and recorded, or bought from a map merchant or a dude in the pub, so the only thing the computer needs to calculate is:

Zoom level = 5ly^2 viewing window with player looking at central coordinates 134,560ly by 44,564ly.

From database of planets, pull up spacial objects within the 25ly square area and display/prep to display on map if either within radar distance from player or if in map from exploration/purchased supplemental.

************************************
Zoom level in this fashion would only work in an isometric (parallel projection) universe. I.E. there would be no prespective shift to the view, because prespective can disqualify things in range, and qualify things out of range.

Essentially, for a flat map it would be ok, but for a map you can rotate and mess with, it would visualise in a confising and hard to read fashion.

so we need to use a prespective based map, so that 3d is really 3d. I.E. distant objects are smaller, etc.

ex.
.........../
-------/------------------- range bound upper (your 25 ly range)
......./
...../ Visible Area (field of view)
.....\
.......\
-------\------------------- range bound lower
...........\
field of view

secondly, it is the 'find things in the region' part that is hard.
because.
to qualify things in that region, you have to look throught all 128947098357 systems and check if they are in that region or not.
you can do this once for every time you move the map.
but continuously moving the map would be a pain.

also, you have to assume that in time you will explore a large area, or buy a large area of map. so you have to make the system handle big stuff.
because. currently, it ALREADY handles small amounts of stuff great! so its not a problem.
this whole issue is around making it handle lots of stuff.

************************************



I won't say it's easy but I don't think you'd have to do something like calculate for every object in the galaxy every time someone wants to look at their map.

Create a database table of x,z coordinates for stars (measured in light years), another table for system objects (measured in astronomical units), and another database containing basic properties of the different objects with an option for an "include" file for specialist places like, for example, Ye Olde Swarthy Pirate Base near the second moon of the third planet orbiting the secondary star of Titi Ceti.

If these tables were looked up with zoom factor, player position, and history of exploration taken into account then it could be detailed but not too complex to display.

************************************
that is a great solution for a parallel projected map.
the X Y Z table solution is what i first thought of doing actually.
have an ordered X list
an ordered Y list
ordered Z list

then grab the in-range X items
, then out of those, the in range Y items,
and out of those, the in range Z items.

except, with a prespective projected viewing area, its impossible to grab things like that.

imagine when you look at the far side of the room.
at your face, the farthest up you see is maybe 5 inches,
but at the far side of the room it can be 16 feet.
so the X and Y range depends on the Z distance.
so you can't just say "things between here and here",
because 'here and here' actually changes with distance.

you would have to solve for a proper X and Y set, for any given Z.
and since Z is continuous, you can't simply do this for a couple sets.
you could sectorize Z, and have a step-wise field of view
like so :
............__
...........|
.......__|
......|
..__|
..
..__
.....|
.....|__
..........|
..........|__

but it still means you have to do this table-lookup business N times (N = z sectors).

and if you have 1 z sector, it is essentially an exhaustive search.

also, you can solve for in-range.

read a places Z value, and then see if it is within the visible X and Y,
but again, you have to do this for every system, so its again 329087209857235 systems to go through.

you can instead bin the viewing volume, (i.e. divide it up into sectors, and dump things into sectors).
then check if bins are visible, and if they are, then check their contents.
this cuts down on the calculations a lot, but also gives a step-wise looking result. (but the best solution i can think of).

a REALLY fast solution which would require no lookup is building a model of the universe, and just displaying it like a space ship.

but this won't work, for 1 reason, the same reason that makes it fast.

it is static.

meaning you wouldn't be able to klik on a system and select it (which would CHANGE how it looks), which is a requirement. (could not have this requirement, but then things like 'find the shortest path from here to here' wouldn't be possible)
************************************

so in any case, your idea is perfect for an isometric view.
the problem is that i want a proper camera-ish view.
a-la homeworld.
but in any case, i'll get it working fast.
after i finish this planet tool.
i want seamless landing to be possible first

-scheherazade

[pincushionman]

I'm not sure exactly what is being argued over with the zoom levels, but here are my 2c. This will be rather lenghty.

I don't know what is referenced in that ungodly large number, but here are my ideas to reduce it.

galaxy map:

Only the stars that have systems in the jump network need to be displayed. If it is decided that stars out of the network need to be displayed, they can be displayed in a static model. Otherwise these stars would clutter the map, and while it would look cool, a map is supposed to be useful.

Galaxy map is always loaded, since it is the topmost "level."

If you mouseover a particular star, it could display the controlling faction, and the quantity of each type of planet/installation, (not ships in the system) and would highlight the connected jumproutes and stars, for quick and dirty route planning. Does not have to be particularly high resolution in terms of the position of the stars.

The galaxy map can be panned, zoomed and rotated, either in isometric or perspective, whichever the devs feel is best implemented. But it cannot be dynamically zoomed down to the system level. It would be silly, since the scales involved are so vastly different. If a system is selected, the appropriate system map could then be opened.

System maps:

Divided into zoom levels. All info in system is loaded, but zoom levels isolate important information to make map easier to view.
1: star; planets and primary installations (those that orbit the star itself), and ellipses representing the orbit of said planets and installations.
2: planet; moons and installations orbiting it, and their orbits.
3: moon; installations orbiting it, and their orbits.
And so on, if there are submoons or the like.

At any zoom level, the only information visible are the objects in that zoom group (at the same zoom level but within its branch), the orbits one level down, and all objects higher in the zoom tree. Selecting an object or the object's orbit, the user could then center the zoom on that object. The user could also zoom up, automatically selecting the object's parent as the new zoom center.

The "zoom" I'm referring to should not be confused with the actual camera zoom, just that when the user selects a new zoom level, the camera automatically centers the view on the selected object and zooms the view to include the largest orbit in that zoom group. The user then has camera control.

That may be confusing, so I'll give an example:

One star
four planets
one planet has two moons and three stations
each moon has two stations.

Currently centered object is the moon of that planet. While this remains the current zoom center, the user can view the following information:
The moon, the position and orbits of its two stations (that is its zoom group)
Its parent planet, the orbits and positions of the other moon and the three stations (the group up one level along the same branch)
The orbits and locations of all the planets and the parent star (the next zoom group along that branch)
and continue until the parent star's zoom group has been reached.

The user CAN NOT view the following:
the orbits and positions of the stations orbiting the other moon (while on the same zoom level, they are on a different branch of the zoom tree)
the orbits and positions of moons and stations orbiting other planets (while they are technically in a higher zoom group, they are also in other branches of the zoom tree).

If the user zooms down to one of the orbiting stations, nothing really changes, because in this example, there are no full branches below. If he zooms up to the planet, he can no longer see the locations of the two stations orbiting that moon, but he CAN see their orbits and he CAN also see the orbits of the two stations orbiting the other moon. He still CAN NOT see moons and stations of other planets.

The user can zoom
"up" (to an object's parent's group, moon->planet)
"down" (to an object orbiting the current center, planet->moon)
"sideways" (to another object in the parent's zoom group, selected moon->another moon orbiting same planet)
and "diagonally up" (another object in the parent's parent's zoom group, moon->another planet).
To go "diagonally down" you would need to zoom up and sideways, or diagonally up, then zoom down to what you were looking for.

Not sure how to best implement ships into this, but the only ones you need to display are the ones in short-range sensor range and important ships (caphsips, hostile fighter groups, etc.)

Having this hierarchical zoom tree probably wouldn't look as cool as showing everything, but it would make it far easier to browse (having a drop-down hierarchical menu that could show all objects in the system by name would allow quick navigation too) by reducing the amount of information thrown at the user. Also makes it easy to zoom and re-center if you get "lost" in the flythrough view. We could get away with it because the distances between planets are huge compared to the distances between moons, displaying objects too close together will clutter the display. Also reduces the number of rendered objects.

The current system is fully viewable/browsable with up-to-date information, since it's already in memory anyway.
If a user zooms from the galaxy map to another system however, things change:

The system is represented as a low-resolution vector map, fully browsable as above, but does not show the current position of any objects. The convention for displaying objects is: the closest body to its parent is shown to be due "south" (rimward, down when the map is first loaded) and the other objects are drawn spirally counter-clockwise in 45 degree increments. Objects in the same orbit are shown equally spaced around their parent. Ships are NOT shown.

The reason for doing this is threefold: One, it makes it easier to find an object in another system by making its position in the map arbitrary but consistent; Second, it reduces the load time of the system map (there will still be a short load time) because the file only needs to have the names of the objects and the shapes of their orbits, not all the information needed in the real system file. Third, to do otherwise would imply that information can travel instananeously between systems, which, according to the MoI, is not within the technological capabilities of the known sentient races (It is highly likely that the Ancients were also hampered by this limitation, but I do not rule out the possibility that they may have had FTL communication technologies).

This makes the viewing in more manageable chunks (only one system; or the whole galaxy, but no system info) because you really only need to think about one level of the two or the other at any given time (to plot a route, you need to know where you're going, which systems are connected to each other to get there, and who controls those systems; all this info can be gained from the galaxy map). You only need in-system info for your current system and your destination system, but if you want to know about the crap in the systems in-between, you can look it up. And when you're flying in-system you don't need to know anything about the nearby stars either, so that information also doesn't need to be active.

I hope that was clear and understandable. But I know it was not.

-pincushionman

[scheherazade]

sounds right on.

a lot of that is what i'm ultimately working towards.

except i would like seamless galaxy->system transition. which can be done ez too.

its just a matter of getting to it.

although, there are no stars in the galaxy map. its just systems w/ links.

the 329873295687250 refers to all the systems we have.

its really a lot, so i just do that.

i *think * also currently the stats are read form xml every time anyone asks. not sure. but if i bin the volume then i can store any data i need locally.

it'll get done. and will be pretty fast. at least when not fully zoomed out

ill come up with a way to make full zoom-out not really needed anyways.

some nice browsing option.

but i'll have to make it less WC ish. the way i did it now was to emulate the privateer browsing style, but i guess we really jsut need it better.

-scheherazade

[pincushionman]

that huge number...is it the number of systems or links or what? I guess I don't understand which problem we're dealing with.

-pincushionman

[scheherazade]

both. there are a LOT of systems, and each has a couple links.

it isn't a high order problem, the 'n' is just really high.

so the issue is reducing n in a sensible way.

-scheherazade

[Shark]

If you mouseover a particular star, it could display the controlling faction, and the quantity of each type of planet/installation, (not ships in the system) and would highlight the connected jumproutes and stars, for quick and dirty route planning. Does not have to be particularly high resolution in terms of the position of the stars.

I think mouseovers are a bad idea. It will slow things down too much. Also, I would be willing to sacrifice panning in exchange for speed. Simply zoom out and select an object closer to where you want to move the camera.

System maps:

Divided into zoom levels. All info in system is loaded, but zoom levels isolate important information to make map easier to view.
1: star; planets and primary installations (those that orbit the star itself), and ellipses representing the orbit of said planets and installations.
2: planet; moons and installations orbiting it, and their orbits.
3: moon; installations orbiting it, and their orbits.
And so on, if there are submoons or the like.

Could you add the system elliptic as well (might be useful at some point in the future)? The elliptic should be a plane of some sort. The elliptical orbits can just be an elliptical line. They should also be less "thick" than the elliptic.

The "zoom" I'm referring to should not be confused with the actual camera zoom, just that when the user selects a new zoom level, the camera automatically centers the view on the selected object and zooms the view to include the largest orbit in that zoom group. The user then has camera control.

I think centering and selection should be done seperately. I mean, simply selecting an object shouldn't automatically center the map on that object.

[hurleybird]

Perhaps clicking with middle mouse button could center?

[pincushionman]

I think mouseovers are a bad idea. It will slow things down too much...

Maybe it would show this when you click on it instead. Just something so you don't have to load the system map just to find out general info on the system.

Could you add the system elliptic as well (might be useful at some point in the future)?...

I say it should be a grid. I think someone else brought that up earlier...but I could be wrong.

I think centering and selection should be done seperately. I mean, simply selecting an object shouldn't automatically center the map on that object.

No no no!...I mean, Yes yes yes! (?) Zooming /= centering /= selecting. You select the object (LMB?) THEN you press ANOTHER control (perhaps a button on the map or even arrows that appear above or below the selected object? I say the MMB stays camera control, that's consistent with a lot of 3D viewers/editors) which THEN recenters the view and changes the FOV to show the important stuff in that zoom group. I totally agree that constantly recentering/rezooming when you select an object would only result in pisssing all the users off.

-pincushionman

[Shark]

Perhaps clicking with middle mouse button could center?

Yes.

[mkruer]

Perhaps clicking with middle mouse button could center?

Yes.

That would be the Biggest improvement right there. I would add to it by asking for a drag function that will allow you to move the map in the direction of the drag.

[Shark]

That would be the Biggest improvement right there. I would add to it by asking for a drag function that will allow you to move the map in the direction of the drag.

This would be better than panning, IMO. Maybe hold the ALT or CTRL button and left-click to drag the map. The cursor should turn into grabby- hands.