Hard to believe none of us have replied to this post yet... we've been talking about it a lot. :P
Well, I was mainly gonna have us talk about it with him directly before doing anything, but posting first works too :P
It would be great to see you working on a solar system generator, since that's one of the big parts missing from a playability standpoint right now.
As far as scale, that is an inherent problem with Crystal Space. It uses the C++ 'float' type for coordinates, which becomes extremely inaccurate past a certain point. (at something a good bit less than 1000000000, you lose all decimal places and have to deal with integer precision or worse) There are two ways to solve this in CS, each of which has some pros and some cons.
First off, is there no way we can just create a new coordinates class that does doubles (maybe long doubles) instead of floats? Would doing this fix our problem?
The first way involves splitting the space up into sectors. This works fine on a small scale, but sectors are a technique that is generally more geared toward "indoor" scenes. Basically, you'd have a cube (the current sector) with 6 faces, each of which would be a "portal" to another sector. The reason that this fixes the float issue is that each sector would be based around the origin (0,0,0) and each portal would "warp" back to the other side of the next sector so that you never get further away from the origin than the size of a sector.
The problem with the first solution is that we have to split up space into a large number of sectors, and it gets rather difficult to track what is in which sector. Also, either we have to have a huge amount of separate sectors (so the size is relatively small) or else we'll still run into some jitter near the edges of a sector.
Another problem with sectors is having to transition the origin seamlessly. Loading zones are anathema to this game - we *will not* have them (I'm sure that morgul and whitelynx already decided this, but I'm making it emphatic, if not official
). This in turn means that things can happen on the edges of sectors (space battles and dogfights, for example). These, in turn, likely will go between the sector edges frequently, causing the coordinates to have to be recalculated a BUNCH of times. Inefficient.
The second solution is to put the player's ship (or character, or whatever) at the origin and translate the rest of the world to be correctly positioned around it. This is a great solution and lends itself well to deep space scenes, because once something is far enough away to cause jitter, the jitter will be small enough and far enough away that you won't notice it.
The problem with this solution is physics. ODE (and the CS physics system in general) tries to move each object around... somehow we have to then translate everything into ship-space coordinates for the renderer. It would be good to do some tests to see how well this method works with physics and whether we can adapt it to work on a large scale. If we can get past the problems with physics integration, this may well be our best solution.
Sounds like this would still require an absolute coordinate system, rather than having everything relative to a moving object. Could you elaborate more on this, probably in another thread?
As far as your ideas on seed-based system generation, that looks pretty promising! I'm not sure about using the stuff from Celestia (we'll have to check their license before you commit any of that to the repository) I have some mixed feelings as far as doing the calculations client-side. I think they should definitely be done on the client to improve speed and response, but the server needs to send updates to the clients every once in a while, and even more often if the given object goes outside of its "predicted" path for some reason. (like being rammed by a large ship or something) Keep in mind that regardless of how much of the calculation is done on the client, the server will need to have the final say on anything that affects actual gameplay.
I'd like to set up an account for you on our subversion repository so that you can commit your code there and we can help you out with it. We'll give you a sandbox directory in the repository, and I'll contact you over PM on the forums to get your login information.
Thanks for working on this! It's encouraging to see some other people getting interested in coding for Precursors.
Back to the main point of the post: I heartily agree with whitelynx's last statement. As time goes on, I'm looking forward to working with more than just 2 people (mainly one, since morgul is more a manager than a codester). Like I've said in other posts, I have mad C++ skillz, so
*please* contact me directly or via the forums with any programming questions you have. I'll also check in on your little playground area in the repository to see how / what you're up to, and make suggestions as I'm able (if that's alright with you, of course).
Also, we've discussed this, so I may as well make it official: if you can succeed at this, or at least demonstrate a significant effort, then we'll be more than happy to make you a full dev on the team. No, mad C++ skillz are not a "must-have" - we'll teach you what you need to know.