[epiar-devel] Navigation Screen
maoserr at gmail.com
Mon Jan 4 07:20:35 PST 2010
I think realistically (both for coding reasons and for actual physical
reasons), the infinite canvas idea is bad because it would be very boring
to fly to other solar systems on sublight drives (it would take a very
long time). Of course if we want to "shorten" the distances for game play
reasons, then it might be ok, but I am against doing that. I much more
prefer a sublight propulsion system that's separate from the FTL drive.
I much prefer an FTL drive that can travel to any "coordinate" on a map,
with key coordinates as the location of solar systems (I.E. no hard coded
restraint on travel routes). Then if we want to add a restraint on travel
routes, it can be implemented purely as an optional restraint. Certain
regions of space can also be marked as 'dangerous' to travel by FTL means
(I.E. have a % chance of destruction if you travel through it, such as
nebulas, asteroid fields, black holes - I would imagine this would be
almost 100%, unless you have some kind of anti-gravitron device), so that
restraints can be either route-based or space-based.
I would also prefer the FTL drive to not necessarily tied to the ship
(I.E. it can be tied to a passenger on your ship that allows you to travel
in certain ways, or any arbitrary item), so that you can swap FTL drives
for the same ship, and that the same FTL code can be used for jump gates
(I.E. it moves other ships rather than itself).
Right now, I'm just trying to think of the most generalized way to
implement this. I'd rather keep the game play options open for now, and
then lock in on what we want our "main" universe to be later.
On Sun, 03 Jan 2010 21:25:19 -0500, Matthew Zweig <thezweig at gmail.com>
> We probably should have discussed the Navigation Screen 2 months ago
> when we were determining the requirements for Epiar 0.2.0.
> To my knowledge nobody has expressed interest in implementing a
> Navigation Screen, nor have we had enough discussion on what kind of
> Navigation we want. Of course, the Navigation Screen is fundamentally
> tied to the way that Navigation works, so we should discuss both at the
> same time.
> I think we agree that the 'things' in our game cluster around 'solar
> systems'. This is where the players want to go in order to do whatever
> it is that our players want to do.
> There are three different Navigation ideas I've heard for getting
> players between solar systems:
> 1) The Infinite Canvas idea says that if you fly in the correct
> direction for long enough, you could arrive at a new solar system.
> 2) HyperSpace Gates could be stationary objects that could transport a
> ship from one system to another 'instantly'.
> 3) Faster-Than-Light (FTL) Drives could allow ships to transport from
> one system to another instantly.
> The traditional method for displaying solar systems has been a graph
> (the cs kind not the math kind). That is, ships in System A can travel
> to Systems B,C,D but none of the others. This works really well for
> designing galaxies (collections of solar systems) such that a player
> _must_ go through a certain system before getting to another.
> This method doesn't work really well with the infinite canvas method and
> even though it doesn't make physical sense it is a standard that users
> will understand. Another problem with the Infinite canvas idea is how
> much data do we store on the nearby systems while a player is 'between'
> solar systems.
> Also, I think the system graph for the FTL drives does not have to be
> the same graph as the Gate Graph.
> Are there any other ideas that I haven't mentioned here?
> Is anyone interested in implementing parts of the navigation or
> navigation maps?
> ~Matt Zweig
> epiar-devel mailing list
> epiar-devel at epiar.net
More information about the epiar-devel