[spaceranger]

Hi folks, first time poster and FSO user.  I'm studying C++ game programming and will be looking into projects to work on later this year.  I'm focusing on game physics and display coding (OpenGL mainly).

I have a mind to see what can be done to expand the mission/map space for FSO to the scale of a real solar system, incorporating real-size planets and orbital elements, etc.  I'm an avid Orbiter player, and while I'm not looking to code a full fledged Newtonian astrophysics simulation (necessarily), my goal would be to increase the sense of immersion in space.

Obviously, this would take some work, I'm not intimidated by that (my intentions are long term).  In my initial exploration here I'm just wondering what experienced FSO coders can say about what an endeavour like this would entail, and any thoughts/opinions/caveats that come to mind.  One of the things I can see is that FRED would need a serious revamp ...

Hit me!  Encourage me!  Discourage me!

Cheers 

[General Battuta]

That would be really, really cool. Almost EVE-like. I'm not convinced it'd be feasible, though...

The question you should ask yourself is what it would add to Freespace gameplay. While it'd be admirable in something like Freelancer, the arena of a typical Freespace mission is probably a few dozen kilometers at most. If you have elite C++ skills, you could probably put the same amount of effort into something with more profound and immediate benefits.

Not to say that I think this is a bad idea, or to immediately shoot you down, but the Freespace code is a tricky beast to work with, and what you're proposing would basically be a total overhaul of the game.

And again I'll emphasize that I don't mean to be discouraging. Energetic new talent with ambitious new ideas is the lifeblood of FSO.

Some actual coders with more hands-on knowledge can probably give some more specific feedback. New coders are always welcome.

[Mobius]

Welcome to the HLPBB!!!

The idea is cool and interesting, but it would require changes that go well beyond coding. 99,9% of the times, FreeSpace planets are 2D bitmaps used as background textures. Same thing for the stars. Models representing planets are very, very rare, and aren't that popular.

When I FRED a multi-phased mission, meaning that the player jumps from one location of a system to another (in the same mission), I simply have to use a handful of SEXPs to "change" background. An example will be easily noticed in NTV, when rebel transports will progressively approach Cygnus Prime to deliver a number of marines.

That's it for the background changes. About immersion and physics - yeah, I'd really like to see radical (and optional, of course) changes to FreeSpace's physics. FS is more an arcade game than an actual simulation, so it'd be nice (IMO) to get as close as possible to a realistic space simulation... if possible. That'd mean improved physics and AI.

About realistic cockpits - As far as I know, implementing them (properly linked to the HUD) requires the dedication of several coders.

[spaceranger]

Thanks General!  I initially suspected the total-overhaul scenario, which I may be tempted to scope out before sinking any time into it.  I looking at 2 years of time for projects to work on, part-time, so I'm not daunted yet.

I've modeled a solar system for Orbiter (in progess, working on planet/moon/gas giant textures ATM, followed by bases, scenarios and atmosphere models) with over a dozen planets and moons.  I'll be coding the dlls for them over the summer/fall.  I'm NOT looking to do precisely the same thing to the same level of simulation detail as Orbiter.  But I'm not daunted by the math, at least.  There's very little chance that I'd do anything outside of scoping/R&D on an FSO project until around the end of the year, I'll get over the ridge and see what the terrain looks like over there first, so to speak.

I'd be looking to get the same sense of scale in the FSO experience as my central goal.  I'm familiar with procedural terrain generation a la Terragen2, World Machine, Geocontrol.  There's a number of changes to vessel dynamics that I assume would necessarily have to happen to support playability in this kind of open environment (i.e. travel time; no one will spend days just getting to a planet's moon, nor should they).  If celestial objects could be implemented as simple sphere primitives with a spherical texture wrapped around them, a la Orbiter, then it might also be feasible to implement a cheap atmo model of some kind (i.e. velocity damping shield/hull hitting burnup effects) and allow landing on flat splotchy spheres.  Or not, we'll see.  It sure would be fun to bombard bases from cap ships in orbit while ion cannons or w/e hit the cap ships from the planet surface (or a nearby moon), wouldn't it?   

This is why I'm keeping my initial expectations low, and assumption of work involved high.  We'll see ..

Cheers

[spaceranger]

Welcome to the HLPBB!!!

The idea is cool and interesting, but it would require changes that go well beyond coding. 99,9% of the times, FreeSpace planets are 2D bitmaps used as background textures. Same thing for the stars. Models representing planets are very, very rare, and aren't that popular.

When I FRED a multi-phased mission, meaning that the player jumps from one location of a system to another (in the same mission), I simply have to use a handful of SEXPs to "change" background. An example will be easily noticed in NTV, when rebel transports will progressively approach Cygnus Prime to deliver a number of marines.

That's it for the background changes. About immersion and physics - yeah, I'd really like to see radical (and optional, of course) changes to FreeSpace's physics. FS is more an arcade game than an actual simulation, so it'd be nice (IMO) to get as close as possible to a realistic space simulation... if possible. That'd mean improved physics and AI.

About realistic cockpits - As far as I know, implementing them (properly linked to the HUD) requires the dedication of several coders.

Gotcha, swap out the backgrounds and Bob's your uncle.  That is a really handy way to change star systems.

I'm looking to push a design envelope if I can, it's what intrigues me.  Yeah, cockpits are definitely a higher design priority, for the FSO mods overall.  I'm still working through the posts on that topic (whoa), so I can't comment much on those yet.

If I did pursue this, I might strip down the source code to the essentials first, to prototype and test, and then re-integrate what I stripped out as it makes sense/is desirable, updating the code as it comes in to support any changes in dependent files along the way.  I'd be aiming to scope the work for what I think I can do in 1 year, and then plan for 2 years.    My general rule of thumb ..

Cheers Mobius!

EDIT: And more to the points you're making:

- Yeah, I'd expect FRED would need to be revamped and I'm expecting that would suck rocks, to put it mildly.

- Making designing scenarios dauntingly complex would also suck rocks.

I've been considering both of these, but from a distance right now, as I want to review all of the source code first, in detail.  I've begun doing this and, um, yeah, it sure looks organically grown doesn't it?    Backward compatibility is a worthy and valid design goal, I'm thinking it'd have to get tossed to pull off what I'm thinking about.

Anyone think that designing your own engine would be easier than what I'm thinking about here?

[voidSkipper]

Oh god. If you're tossing up between increasing the play area size and working on the cockpit system, I beg you to invest your time in the latter. I'd kill for immersive, claustrophobic cockpits with no graphical artifacts.

[spaceranger]

Oh god. If you're tossing up between increasing the play area size and working on the cockpit system, I beg you to invest your time in the latter. I'd kill for immersive, claustrophobic cockpits with no graphical artifacts.

Hmmmm.  I'll take a look at it over this summer/fall as part of my research.  I'll make a decision after I finish my current Orbiter project and review all the FSO source code.

[Reprobator]

I think before having a full solar system in game, a good first step would be to code a full planet's orbit environment.
I mean being able to fly around earth and the moon and being able to get into it's atmosphere.
And to keep old gameplay style functional, having in some table an option to activate that would be awesome.
I'm no coder in anyway, and I'm almost sure the feasibility of what i say is quite compromised unless you have a lot of time to spare on that project,  but it would be a good first step.
I would like to say that it's maybe not necessary to have a full planet surface modeled for atmospheric part, maybe something like we can see in game like starshatter (a big looped terrain is enough)
I dream of battles in earth's low orbit, that would continue over the planet's surface with capships hovering over a big city and firing theirs beam canon over the building after a big dive in the battle! .  

[Nuke]

ive been working on a lot of lua based cockpit simulations and physics enhancements. i have a semi-decent half finished cockpit simulation, complete with working controlls and rtt panels. but lately ive been working on a script level atmospheric flight simulation, which inclueds newtonian physics as the basis. if currently supports planer and point sources of gravity, drag force, lift force, as well as an atmospheric modeling system which supports multiple layers of atmosphere with different characteristics. as well as barometrics and gravitational falloff. and to a small degree, orbital mechanics (though i sorely need some sort of orbit gauge like the one orbiter has). recently i added an attitude gauge for atmo flight, support for weapons, and just finished writing a table parser for lua. id post it but its still got a multitude of bugs in it. then theres the problem that the ai cant fly a real space ship. i also want to model control surfaces and implement angular physics.

ive also been given thought as how to expand the space in freespace (or any simulation for that matter). the problem lies solely on the sholders of floating point percision. i know that on most modern cpus that float and double seem to have the exact same resolution, but ou can also use a long doule to get more precision. the problem isnt the cpu though, its the video card that does most of the floating point math, and im not sure its precision. none the less assume a limit. freespace seems to do its physics entirely on the cpu. that means if you want to change all the floats to long doubles you can, but that means changing a lot of other stuff. you could start with a new vectore class, it would have two parts, an int for any big astronomical number and a float, for anythng less than 1000. when you do a vector operation, it would check to see if all the numbers are in a certain range, if theyre too big then it subtracts the excess from the input and stores it in the int, the rest modifies the float. extrernally it works like any other vector class youd ever used.

another idea would be to section off space into sectors, each one having its own floating point space. if a sector is important, if it has something big in it, or its adjacent to whatever sector the player is in its rendered. each sector is simulated seprately. somehow interactions between objects near the transition planes would have to be handeled some how. whatif a ship in one sector shoots at a ship in another nearby sector. large objects which would fill up multiple sectors would need to either be subdivided in real time, or lumped together and rendered at a different scale as sort of a background. rendering is its own chore. hiw do you depth sort mutiple scales of rendering overlayed, i havent a clue.

[Black Wolf]

FS is really going to struggle to work as a massive, system-wide simulation I suspect, simply because everything moves so glacially slowly in the conext of space travel. Even moving around planets and whatnot - there's no facility to speed things up to anything like the kinds of speeds you'd need to justify this kind of a massive project. It'd be cool, I suppose, in a sense, but I just don't see any practical way to use it. Not that I'm saying "Don't do it" exactly... just maybe think about how you do it. Take one of your examples, orbiting planets. This strikes me as kind of ueless, since there's no way FS ships can get up to the Km/s speeds required to orbit at any kind of sensible distance.

If you want to integrate some sort of "Full system" err... system into FSO, maybe something wherein you can define "locales" a planet here, an Arcadia there, a node, a cargo depot etc. etc. which could then be made to talk to each other and be dynamically updated as the player moves between them. So going to locale A and doing someting might trigger a change at locale B. This way you could tell Freelancer style stories, or set the player up as a merc or trader or spy or something. Kind of like Nuke's sectors, I guess, but less concerned with floating point precision and more with getting the player to interesting places so you can tell stories (and blow stuff up ), which ultimately is what FSO is for. After all, 99.99999% of space in a a system is empty, and utterly uninteresting to do anything in FSO because it's too far away from everything.

It'd still be a major project, it'd just be a different way of approaching it so that you'd get more real use out of it. You'd need stuff like a method of letting the player choose where he wants to go, as well as a way for the FREDder to design each locale, and decide where he wants to let the player go to, as well as a better integration of a system of campaign persistent variables (I mean, technically you could do this without code changes, just in FRED but I think all you'd be doing is creating an un-usable bug fest or years of debugging work).

Anyway, it's kind of dissimilar to your original idea, so I understand if you want to just ignore it. I just think a system like this would ultimately get used more than a big, open semi-newtonian system.

[Sushi]

The big issue is that FS is a tactically oriented space sim. It's designed for simulating battles at specific places, not so much for handling long-distance travel. You could probably hack something like that in, but it kind of goes against the fundamental nature of the game and would invalidate most of the assumptions made when designing it. You'd have to account for all of those assumptions everywhere in the code, and it would probably be easier to just start from scratch if you wanted solid results.

Cockpits are another story.

There are other games you could potentially contribute to if you really want to work on "big-scale" space sim stuff: Vega Strike and Infinity come to mind.

[Dragon]

I think it would be great to see system-wide simulation ,I imagined that in FSO 5.x.x (science fiction, the current version is 3.6.11) it will be possible to make a huge mission involving entire star system ,looking like this:
1. Take off from a capship orbiting a planet.
2. Fly to another planet and possibly fight some small battle on orbit.
3. Land on a planet and attack the installation on the ground.
4. Dock with the installation.
5. Recover something from it . (FPS support is scheluded for 3.7)
6. Destroy the installation.
7. Return to carrier. (still orbiting another planet)
8. Defend it from enemy attack.
<optional>
9. Fly to one of the planet's moons (can't land on carrier because of fighterbay damage in attack)
10. Land in a base on the moon.

I was expecting this to be possible when I will be an grandfather on emeriture ,but with the changes you want to make ,plus Nuke's atmospheric flight system and there's a chance of my proposition being technically possible in maybe... 3.7.9. 
To sum up: What you proposed would be completely awesome.

[Mobius]

You can do that with FRED. It's complex to script, but it's definitely possible (for the FPS part, create a ship model to flight in and use the suit featured in Blue Planet). I've personally never FREDded missions that take place in more than 4-5 scenarios, but I might be able to break that limit if I need to.

IMO, code changes would boost that effect... but don't forget that we already have the tools we need to represent those effects.

[wistler]

I don't know anything about coding but I would second further development into atmospheric flight, or different environments over a fully explorable solar system.

I think the way FreeSpace is, is that its not really geared towards huge solar systems EVE online style. But then my knowledge is limited to say the least. It's a lofty goal and I'm sure everyone would support you if you had a crack at it   

[Mobius]

Let's don't confuse FRED with the code. Thanks to the coders, it'd be possible to have atmospheric flight...

...but system exploration is up to FREDders. Please note that the coders can't be bothered to recreate all canon systems of FreeSpace, not to mention the fact that we don't even have the basic info to represent those systems in a way everyone would accept (Sol system excluded).

[spaceranger]

Thanks for posting your thoughts guys!  Good stuff.

ive been working on a lot of lua based cockpit simulations and physics enhancements. i have a semi-decent half finished cockpit simulation, complete with working controlls and rtt panels. but lately ive been working on a script level atmospheric flight simulation, which inclueds newtonian physics as the basis. if currently supports planer and point sources of gravity, drag force, lift force, as well as an atmospheric modeling system which supports multiple layers of atmosphere with different characteristics. as well as barometrics and gravitational falloff. and to a small degree, orbital mechanics (though i sorely need some sort of orbit gauge like the one orbiter has). recently i added an attitude gauge for atmo flight, support for weapons, and just finished writing a table parser for lua. id post it but its still got a multitude of bugs in it. then theres the problem that the ai cant fly a real space ship. i also want to model control surfaces and implement angular physics.

Cool!  A script based atmo flight system?  Far out.  No need to post anything in that stage of development unless you want feedback, sounds like you've got a good idea of where you're going so far.  Why script based rather than code?  I wonder how it'll scale.  I haven't looked into FSO scripting yet.

ive also been given thought as how to expand the space in freespace (or any simulation for that matter). the problem lies solely on the sholders of floating point percision. i know that on most modern cpus that float and double seem to have the exact same resolution, but ou can also use a long doule to get more precision. the problem isnt the cpu though, its the video card that does most of the floating point math, and im not sure its precision. none the less assume a limit. freespace seems to do its physics entirely on the cpu. that means if you want to change all the floats to long doubles you can, but that means changing a lot of other stuff. you could start with a new vectore class, it would have two parts, an int for any big astronomical number and a float, for anythng less than 1000. when you do a vector operation, it would check to see if all the numbers are in a certain range, if theyre too big then it subtracts the excess from the input and stores it in the int, the rest modifies the float. extrernally it works like any other vector class youd ever used.

another idea would be to section off space into sectors, each one having its own floating point space. if a sector is important, if it has something big in it, or its adjacent to whatever sector the player is in its rendered. each sector is simulated seprately. somehow interactions between objects near the transition planes would have to be handeled some how. whatif a ship in one sector shoots at a ship in another nearby sector. large objects which would fill up multiple sectors would need to either be subdivided in real time, or lumped together and rendered at a different scale as sort of a background. rendering is its own chore. hiw do you depth sort mutiple scales of rendering overlayed, i havent a clue.

Yeah, floating point limits are key.  Dr. Martin posted on this topic somewhat recently on the Orbiter forums, full post is here (interesting discussion touching on a number of considerations):
http://www.orbiter-forum.com/showthread.php?t=7940&highlight=floating+point

The good Dr.'s post in particular:

Note that orbiter's current physics engine already takes some measures to improve numerical precision over large dynamic distance ranges compared to a naive floating point implementation.

The main problem is the loss of accuracy when adding floating point numbers of widely different magnitude. The way this is implemented in the processor is

1. step one: equalize the exponents of the operands by shifting the digits in the mantissa.
2. step two: add the numbers by adding their mantissae.

Step one is the one that can lead to a loss of precision, since it may shift any number of significant digits out of the mantissa. In the extreme case, if the exponents differ by more than the number of digits stored in the mantissa, you will shift out all digits and end up with zero. You can find out this precision limit by finding an eps > 0 such that
1+eps = 1

Orbiter tries to overcome the worst of the loss of precision by storing position variables in two separate numbers:

- a base position
- an offset position

At each time step, the position change is added to the offset part of the position variable. At regular time intervals, the offset is flushed into the base, and the offset is reset to zero. The update intervals are chosen such that there is a compromise between the loss of precision when adding a single step to the offset, and the loss of precision when adding the offset to the base. Effectively, this scheme simulates a floating point representation with a longer mantissa.

If higher precisions are required, this scheme could be augmented by adding more stages. This would make calculations slightly less efficient, since each time you need the actual position of an object, you first have to add the contributions from all stages.

A better solution would probably be a reference frame that is moving with the observer, rather than one that is fixed at the solar system barycentre, as suggested above. This would however make a lot of computations more awkward than they are now.

- martins

Those shifty digits ...    I like his "naive floating point" phrase, I want a bumper sticker with that, or a t-shirt.

RE: Real space scales and travel time

Spending hours/days/weeks/months flying between systems is the last thing I'd want to push on an action space combat sim.  I want to increase immersion, but not the whole sandwich.  There's more than one way to address travel time (warp drive, jump drive, worm holes, <insert sci-fi drive here>), and I think there's room for supporting more than one way, can't see any reason not to (yet).

Dragon's scenario sounds EXACTLY like the kind of thing I can envision.  I certainly don't see a dogfight spanning the distance between Earth and Mars, that stuff would be local to orbital stations, planets and moons.  Maybe asteroids too, but not something like the SW:ESB asteroid field, I'm not that cracked (yet).

The Battletech/Aerotech paradigm of large, fragile Jump ships carrying military ships/transports popping to and from stellar Lagrange points and then sending the ships in-system is another example of approaching this.

Cool!  OK, back to research and study ...

Cheers

[spaceranger]

FS is really going to struggle to work as a massive, system-wide simulation I suspect, simply because everything moves so glacially slowly in the conext of space travel. Even moving around planets and whatnot - there's no facility to speed things up to anything like the kinds of speeds you'd need to justify this kind of a massive project. It'd be cool, I suppose, in a sense, but I just don't see any practical way to use it. Not that I'm saying "Don't do it" exactly... just maybe think about how you do it. Take one of your examples, orbiting planets. This strikes me as kind of ueless, since there's no way FS ships can get up to the Km/s speeds required to orbit at any kind of sensible distance.

If you want to integrate some sort of "Full system" err... system into FSO, maybe something wherein you can define "locales" a planet here, an Arcadia there, a node, a cargo depot etc. etc. which could then be made to talk to each other and be dynamically updated as the player moves between them. So going to locale A and doing someting might trigger a change at locale B. This way you could tell Freelancer style stories, or set the player up as a merc or trader or spy or something. Kind of like Nuke's sectors, I guess, but less concerned with floating point precision and more with getting the player to interesting places so you can tell stories (and blow stuff up ), which ultimately is what FSO is for. After all, 99.99999% of space in a a system is empty, and utterly uninteresting to do anything in FSO because it's too far away from everything.

It'd still be a major project, it'd just be a different way of approaching it so that you'd get more real use out of it. You'd need stuff like a method of letting the player choose where he wants to go, as well as a way for the FREDder to design each locale, and decide where he wants to let the player go to, as well as a better integration of a system of campaign persistent variables (I mean, technically you could do this without code changes, just in FRED but I think all you'd be doing is creating an un-usable bug fest or years of debugging work).

Anyway, it's kind of dissimilar to your original idea, so I understand if you want to just ignore it. I just think a system like this would ultimately get used more than a big, open semi-newtonian system.

Very good points I meant to address in my last post.  Yeah, changing the environment this way will necessitate changing other factors of the game, such as how engines work.  I'd cheerfully remove any sort of top speed barrier.  Definitely a major project.  That's OK, I'll be looking for a major project that interests me come year-end.  I'm going to take a good look before I leap though ... who knows?  I might just end up modding Crysis2 instead .. 

[asyikarea51]

/random

I wouldn't have thought too much about top speed if it didn't affect actual fighter-fighter combat... it's extremely hard to hit anything going past 600m/s in FS in most cases...

[Mobius]

Please note that altering spacecraft speeds alone wouldn't work. Weapons' speeds also need to be changed.

That's what Sushi did.

[spaceranger]

I hear ya both.  I'd aim to manage combat speeds by rigging the energy/thrust economy such that the sweet spot for vessel combat performance is around where we see the vessels at in Star Wars movie space battles.

The problem with that is if you're maintaining a stable low orbit around an Earth sized planet, you'll need to be going ~7000 m/s to keep from plummeting into the atmo.   A SW style fighter combat just won't happen at that speed, even if everyone's moving at the same speed in the same direction to begin with.

My goal would be to turn things like this into a feature rather than a bug.  One example would be to put most scenarios far enough away from a planet where such velocities aren't required and keep the objectives local to that area (to discourage "camping" via fleeing, etc.).  If you think about the open scene of Star Wars EPIV, the Tantive heading for atmo can be considered a tactical move in this type of environment.

Yeah, it's a can of worms, sure.  That's one reason I'm giving myself so much time to consider it.  I'm glad I kicked off my part by going up here first to hash out the notion.  Lots of food for thought.

Cheers