After a few months of prototyping different things Ive come to realize that the BGE has a few crucial limitations for games of this size.
The main issue I'm facing at the moment is the lack of physical distance in the game engine. The BGE is limited to a 5km view in realtime (with 1-1 unit sizes for physics calculations), or 500,000km when edited as Campbell described to me on the BA forum (quoted below)
"as for floating point limits - if you have a 20m ship best scale by 0.1 and make it 2m. Real camera limit is 500,000 (set the grid size in the 3D view to 100.0). But these are not ideal solutions I think a proper solution could store a much bigger world in a database and load in parts to an area closer to 0,0,0"
500,000 is quite a distance, maybe enough to fit in a decent sized planet or a star, but to fit in a visible 360 degree sky of stars, stretching out into the reaches of space? Not a realistic goal currently.
So to get around this I need to come up with an efficient and fast system for displaying the far reaches of space, but in a smaller local area. Heres my first idea (drawn and described below) which I will code in python sometime soon to test.
The basics behind this, is that you have the ships position as point 'O' marked on the image. This is basically the 'origin' of the game universe. Point 'S' is the position of the star, which is at point (Sx,Sy,Sz) in the universe, in relation to the origin ship. The sphere around the point 'O' is the extent of the visible universe in the game. This is the sphere which the background star map is mapped onto, and its vertex parented to the ship (this means that it will always remain the same distance from the ship, but wont rotate with the ship as it tumbles through space) The most important part of this idea is point 'I' which is the intersection of the line from 'O' to 'S' through the edge of the sphere. At this point 'I' the image for the star will be displayed, its scale relative to its distance from point 'O', and this will/should update when the ship moves to a different location relative to the star.Then, as a star or planet gets closer its image will increase in size, giving the appearance that it is getting closer, until it is inside the visible area of the sphere, where (with a basic LOD system thrown in) the star image will change into a physical object which the player can then 'interact with'.
The only issue is making this system efficient for thousands of stars, not to mention planets and other space objects (most of which can be ignored at appropriate distances anyway)
Along with this, there has been a lot of interest in finding the 'edge' of the BGE, which has been discussed here (http://blenderartists.org/forum/showthread.php?t=156488) I ran my own test on this, leaving a 'ship' object flying at max speed for several hours, sending its position information to the blender consol (I quit the simulation when it got to 10,000,000km), I didnt reach an 'edge' (I actually didnt come anywhere near reaching an 'edge') and the BGE also didnt slow down at all (as there are roumors that the BGE becomes laggy when you move a large distance from the centre)
So in conclusion, the 'edge' of the BGE will not be an issue for this Protostar game.
Ive also contacted MatrixNAN (one of the guys currently developing the BGE into a Pro engine) about these issues and he replied to my comment:
"I have a couple of questions.
For the BGE the view distances are very low, limited to 10,000 units, 10km for the 3D window, half that (5km) for cameras in-game. For most games this is fine, but for a big space scene or game with large scale objects (like ships of several hundred meters long) its hard to think of how to get it to work. Especially when you have hundreds of stars and planets in the background, ranging from several hundred km away to thousands and thousands of km away. Do you guys have any plans on making the BGE work better for huge scenes?
For a space scene there's usually not that much in between stars, so its not like it would be that intensive object-wise, its just viewing the large distances involved which seems to be a problem. "
With this:
"AD Edge:
Yes our game uses very large scenes so BGE should be able to handle much larger scenes than it has in the past. DXT is next month Campbell will be doing it. "
So that is at least something, they might be working on this issue and it might make my life easier in the future. But for now, time to start prototyping Protostar. ;)
