1. ## Design question

How should I design my local star systems?

My idea is to keep everything centered at y=0.0f to facilitate navigation and to make creating trade routes much simpler. My solar system designer will be a simple MFC-based tool that will allow you to place objects, planets, suns, nodes for trade routes, etc. By keeping everything centered at y=0.0f this essentially breaks my tool into a top-down 2D editor and is much simpler and easier to use.

Is there any real reason to place anything at locations other than y=0.0f? I could easily allow the user to place objects anywhere but displaying that using MFC is going to be a pain.

In my experience with X2: The Threat, Freelancer, X3: Reunion, and now Space Force it seems that placing stations and objects of interest at y=0.0f is much eaiser on the player.

Space Force tends to place their objects at weird angles to one another and makes it very hard to navigate and keep your bearings. Freelancer, X2, and X3 all do it the right way IMO and keep all items of interest at y=0.0f and keep the objects upright - or 0 degrees Z rotation. In the editor you will also be able to set auto-docking waypoint nodes around dockable objects and it is much simpler to keep everything on a 0 degree Z rotation. Granted I could use any orientation but my goal here is simplicity and I'm not purposely trying to disorient the player. My autopilot system (from a previous thread) can handle any type of orientation so this is not a matter of being limited mathematically but rather forcing limits for playability.

2. http://en.wikipedia.org/wiki/Pluto
That's about 10^13 metres from the Sun to just outside Pluto. Bear in mind that doubles are only good for 15 decimal digits, that only leaves you with 2 to play with at the outer extremities of the solar system. Nowhere near enough resolution to perform careful manoeuvres for example.

Frontier Elite II used flexible frames of reference, which jumped from place to place as you moved away from one massive object towards another. Up close and personal, the frame of reference became the star port or space station. Needless to say, sometimes it got it wrong which made landing at certain places extremely difficult.

3. Well since space distances are so massive there is no way I can represent one seamless universe. I've divided all of 'known' space in my game into systems so that you have 50 to 60 small systems each with planets, a central sun or two, jump gates, and stations along with ships and baddies. I really do not know of any other way to do this. My game is essentially use jump gate A to get to system B and do task C. But I'm trying to cram as much detail as I can into the models, systems, skyboxes, etc to make the systems exciting. My goal is fast-paced combat with pirates, police, and any other faction or group you want to get bad with.

But my idea is to keep everything at y=0.0f so that the player essentially only needs to navigate in 2D as opposed to 3D which I feel makes the game more playable.

I've also eliminated any planetfall operations from the game since doing this right is nearly impossible. When trying to do planetfall with real time terrain the game ends up being too broad in scope and the planet operations are not any fun. Sure you can fly anywhere you want on the planet but since I cannot simulate an entire planet complete with cities, objects, etc, it ends up being huge expanses of really pretty terrain. Cool, but not much fun.
To do it right I would have to simulate planets down to the detail of the likes of MS Flight Sim X and doing that is far beyond my capabilities.

I have no idea how Spore is going to accomplish this - or for that fact simulating not just one planet but thousands in a real time universe.

4. Originally Posted by Bubba
I have no idea how Spore is going to accomplish this
Isn't it obvious? Spore won't be out until systems have eight cores and Vista is a thing of the past.

But seriously, couldn't you load the universe in sections and only load/process those sections that are needed?

5. In my game yes. But not in a game like Spore. They say you can leave any planet and go to another and it will have developed the entire time you were playing your planet.

Now that's amazing.

6. The distances won't influence that much (except in the time it takes to travel), only the number of planets does.

Whether your universe is a million lightyears across or only one doesn't matter, if you place the same number of objects in it the only thing it does is create more empty space...

And most of space happens to be empty, so they probably will have only a fraction of stars have actually developing, living, ecosystems.
The rest may contain asteroids and planets that can be mined for resources, but all they need to do for those is keep track of the remaining resources on that body which is a simple check in a database when someone happens to ask for the information.

So now the problem of an infinite universe has been reduced to a problem of at most a few tens of thousands of bodies to keep track of.
Frontier II already could do that on your PC (though of course not at the same scale).

7. Let's get back on track here:

My game is not Spore or anything close. I'm asking a question about local sector design centered around y=0.0f. I've solved the problem of a real-time universe and the solution is I'm not simulating one. I simulate a sector at a time. This is very similar to Freelancer.

8. Anyway, even FSX doesn't simulate everything.
The weather, AI and ATC are only ever actually running in a bubble some 40nm (somewhat dependent on settings) in radius around your aircraft (except for center ATC which is running for whatever center you're currently connected to).
Anything outside that is dormant and will only come alive when it comes into range (calculated on the fly based on timetables defined in a system resource).

Similar restrictions are in place for ground and sea traffic.

And there is nothing else being simulated on the fly at all. No industrial output, if you crash there's no crash site the next time you fly over that area that is slowly reclaimed by nature or cleared up for rebuilding.
Cities and towns are stationary in size and layout.
If there's a construction site modelled somewhere it'll still be a construction site 2 years later.

A game that models large commerce systems will have to do more, but most of that can be calculated as needed (rather than continuously updated) and the rest is dependent on player interaction which at any interaction point happens only sporadically.

9. Design a multi-scale system.
The entire universe has a single sector at (0,0), each sector has a system at (0,0), and each system a star (typically) at (0,0).
For intra system travel each planet can be its own center for operations in its orbit.

That's how Frontier II solved it, and it works well enough.

10. Never mind. I'm going to design my systems around y=0.0f. Everything lies on the same plane in the sector. Multi-plane sectors are very hard to navigate through.

11. hmm, 3D coordinate systems within sectors is what Frontier II used.
Indeed unnecessarilly complicated for a game, but more realistic.

12. It is 3D but with everything on the same plane. You can fly anywhere you want but I'm 'guiding' the player to y=0.0f because that is where all the action is and it makes for a simpler way to find jump gates, asteroid fields, planets, etc, etc.

So you can fly to 5000,5000,5000 if you want but there won't be anything there.

13. I agree with your decision to place important objects on a particular y plane. Freelancer did this very well while still submersing the player within an exhilarating 3-dimensional environment. A couple things surface in my mind that you may wish to watch out for during development:

1) Obvious: Avoid any mentality that "If everything's going to be at y=0.0 I won't store that y value in an effort to save space" as if you ever do decide to have objects placed in space arbitrarily you will be kicking yourself.
2) Not-so-obvious: I will only assume that you will be using this editor to also place space stations, patrols, and squadrons of ships. Assuming this is the case, I would like to refer back to point a. Ensure that in your editor you have the ability to place objects on more than just the x-z planes. It will become quickly apparent to anyone playing your game that everything is flattened on to one plane if for every planet, each space station is aligned perfectly vertically.

One suggestion to implement y-editing simply is to design your editor with x-z-editing in mind while having a side-pane that displays the object in question projected on to the y-plane from the side. Then merely add the functionality to drag the object up and down.

Good luck.

14. The Y coordinate will still be part of the model's position and I like the idea of varying it slightly for planets and other interstellar objects just a bit so it doesn't look like the sector is flat.

I also like the interface idea of having an x-z plane map and then a separate y plane for the side view of the object and being able to move it up and down. Very very nice. In fact I'm probably going to implement that in my editor.

Excellent suggestion jverkoey. Thanks. My what we could do with a dev team eh? Doing this lone ranger aka with one head is so difficult. Two heads are better than one.