Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: spaceranger on June 11, 2009, 04:22:11 pm
-
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
-
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.
-
:welcomesilver:
Welcome to the HLPBB!!! :D
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. :)
-
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? :D
This is why I'm keeping my initial expectations low, and assumption of work involved high. We'll see ..
Cheers
-
:welcomesilver:
Welcome to the HLPBB!!! :D
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. ;7 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? :lol: 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?
-
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.
-
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.
-
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! . ;7
-
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.
-
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.
-
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 (http://vegastrike.sourceforge.net/) and Infinity (http://www.infinity-universe.com/) come to mind.
-
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.
-
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. :)
-
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 :nod: :yes:
-
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).
-
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 (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 ... ;7 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
-
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 .. :p
-
/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...
-
Please note that altering spacecraft speeds alone wouldn't work. Weapons' speeds also need to be changed.
That's what Sushi did. :)
-
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
-
Please note that altering spacecraft speeds alone wouldn't work. Weapons' speeds also need to be changed.
That's what Sushi did. :)
And why I used his old velocity mod as a base to mess around with things instead of doing all the changes from scratch... might as well since it's convenient enough XD :lol:
I probably mentioned vehicle speeds alone since it was the first thing I thought of when "top speed" was mentioned...
Then there's that huge argument about the big and slow FS ships in the atmosphere and references and canon and blah blah blah but I don't think it's appropriate here... :doubt:
-
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...
I made a mod in which fighters had max speed over 600m/s as standard.
The biggest problem turned out to be interceptors ,which were nearly impossible to balance ,it was very hard to shoot one of them flying heavy fighter ,but when I was flying one of them I quickly got shot down.
Standard fighters handled moderatly ,they had autoaim to compensate difficulties with aiming and were good at nearly everything. (of course I also used AI Profile with nearly all additional features on)
I recently abandoned this gameplay model ,mostly because of autoaim ,which was unrealistic considering the external primary models I was using ,though I commented out all values ,so reverting all changes wouldn't be a problem.
I'm now using values from Sushi's velocity mod ,I would like to employ Newtonian fight model someday.
(for example when The Minbari Project comes out with bugless ,fully functional build)
-
LOL yes I tried it myself once. Damn it man, in a 1v1 fight versus the AI at 400-1000m/s and above, it's a case of you, the player, getting flanked-sniped-instakilled! I couldn't even get a missile lock... but even if I did, the missile would just miss or aim the countermeasure instead...
I had Gatling weapons during the test so it was basically a guaranteed "IT HURTS!!!" session, and at the end of it I didn't even feel the... "feel" I wanted. And no auto-aim, to add (don't know how to do it + back then I don't think there was auto-aim yet or maybe I simply didn't discover it).
Well back on topic, I think that whoever really wants to "expand the space" in FS might need to put some serious thought into the flight and movement model first or something... at least that's now this simple mind sees it. Making FS look like X3 and/or FL is still a long way away I guess...
-
well im currently looking to see what can be done with the existing useable space, roughly 1500km^3. although it should technically be less, because getting close to the boundaries of that you get shakey flight which reveals the limits of floating point numbers. this is enough to orbit small moons, ice dwarves, planetoids, and large asteroids. so my atmospheric flight simulation uses 2 modes. a planar mode, in which only one gravitational object is present in the game, and its acceleration is always to the -y. this is good for simulating large planets with dense atmosphere, gas giants, ect. while i was out in the woods i tried to come up with a highly loded representation of (about 1/50th) the surface of mars. and it sort of works, although i didnt set up the detail boxes correctly. i also have an atmospheric model for earth (but it needs a terrain model). im gonna start a complex terrain thread in modding in abit.
the other mode is represented as point sources, it can have atmosphere like the other mode, and requires a planet model rather than a flat chunck of terrain. thouh he same kind of loding technique can be us to create really complex planetary terrain. it doesnt support it yet but im gonna make it possible to place several of these in a mission. anything with a radius less than 500km can fit ok in freespace, but thats a hard limit and it doesnt give you any room to manuver, you can make orbit and fly around a little. smaller objects can be simulated better. and while the physics are mostly correct you can use less realistic figures for its atmosphere model.
an optional third mode allows you to set an ambient density, this can be used in nebula missions, but also can be used to cap speed while maintaining newtonian flight. to sort of give you a more realistic capped velocity. ive also been giving some thought as to how to liit your acceleration in space. since you need alot more thrust to fly in an atmosphere than you need in space. ive been toying with a few ideas for how to accomplish this. one idea is to make some engines air breathing, where thrust output is dependant on atmospheric density. so engines would have an atmospheric performance factor. so it woul be thrust+(thrust*performancefactor*airdensity), so if youre in a vacuum you get the base thrust value, and as you get into denser air, you get more boost. though im sure i can get a more accurate formula somewhere, something youd use for tubofan engines. another idea is having boost thrusters that use fuel, giving the player only enough fuel to make whatever velocity you need in mission.
ive also added some physics to weapons, though with varying sucess. flak weapons seem to work the best, lasers dont let you change their speed once created, though they do let you add the ships velocity to them for some reason. missiles just tend to crash the game. i had them set up to accelerate constantly accelerate during their life span, but this causes an assertion somewhere in vecmat.cpp. dumbfires crash the game less, but still do.
also the problems with collision detection might be partially solved by writing to the old velocity values within the engine. if you subtract the curent frames velocity from the last frames velocity, then that gives you a line with which to check for collisions. i think that by simply making theese values visible to scripting, and then writing the frame old values to them, this should make collision detction work up to the point where floating point precision falls off. then theres the problem of disabling freespace physics entirely (which might already be implemented).
id like to release something but there are so many bugs right now its not funny, and would like to have more terrain and planet models available. i might just post some vids on youtube for now.
-
Well I am super intrigued by this. I wanted to use FS2 to make a mod somewhat based off of Independence Day 2, and Homeworld Cataclysm set in the year 2220ish. Because of the timeline the main ship will be more low tech and sluggish compared to FS2 ships. I am a pretty good modeller and texture artist and my plan was to create several Cockpit HUD scenes and you use key commands to switch between the views.
The trick I decided, was to keep most of the FS2 Fighter/Bomber ships performing normally with some major modifications - since my "other universe" is only 200 years from now, there is a special engine device that can be used on small mass hulls, its the Non-Spacial Grav Engine (NSGE). Since its fictional I cant really describe it - however its power give the smaller ships that Star Wars type performance... but its very fuel heavy. Once the fuel runs out you have to navigate your ship oldskool style (like Orbiter), and if you don't it will just drift...
The main flagship is operable, it requires several HUDS(cockpits), and most of its movement is adjusting drift speed and direction. Switch to another HUD and you get a 3d display map (like Homeworld) to plot your destination.
Here's where my mod idea comes parallel to this subject, make the space big - real big -, the fighters and bombers effectively can only navigate the immediate area - just like FS2, but unlike FS2 they will run out of fuel pretty quickly and they cannot travel long distances - cause it will take FOREVER. If you are concerned about the relation between movement and game speeds - just take the Fighter/Bomber displayed speed and divide it by half or more. The smaller craft will still perform like FS2 but it will seem their speeds are not very fast.
Why cant Fighter/Bomber not travel huge distances?? When their NSGE runs out of fuel, the flying ability decays swiftly - because the NSGE is no longer operating, the force it was extending from the ship retracts effectively slowing the small craft down a whole lot and then setting it into a vector drift. You the pilot must use the old conventional thrusters to get yourself back to fueling bay. When this happens the ship moves at such a crawl (fast enough to get to fuel bay however) that getting across the map would be incredibly tedious (maybe hours of drifting).
The main flagship however can use the Navigation HUD to plot a course, and it huge Long Distance Drives are empowered, this will increase the speed of the Frigate hugely (x100), and has a moderate acceleration speed and a equal to that deceleration speed. Getting across the map may take several minutes. During this time you cannot fly the ship, but you can use the HUDs to do RTS style stuff like research technologies, refining ores and such, and repairing fighters and bombers. I know its a huge fantasy of mine - but I do have some coding experience - mostly C# and I am really good at making game mechanics work - what I can't do is figure out how to upgrade the FRED and the game engine to use larger maps.
[ADDITIONALLY]
Oh and as some of you may have suggested - Sectors of space is the way to go - I've done 2d coding moving objects from one sector to another sector in relation of its directional path and its vector position before- doing it in 3d is definitely possible. I just don't know how to go about upgrading the Engine to recognize Sectors. A-1, B-2 etc...
The other thing about 3d models as Planets Moons, one trick I was thinking is that on the MAP view of things, your planet, moons, and such have a set position obviously, however - from the view of your HUD (cockpit) this position is changed drastically. What I mean is that - we a ll know 3d Model Planets and Moons typically look horrible up close, cause the textures gets stretched. However.. a planet the size of a Half Dollar on your screen looks pretty nice, and size double that or half of that look good too. Any sizes out side of that are either too small or too big (textures stretching). So instead create a slightly complex algorithm (method) to place the 3d model a set Perceived distance from the HUD at a vector originating from its actual Map position. Meaning, as you move closer to the Planet - it moves away from you. The 3d Model actually moves away from you as you come towards it - AT a slower rate of your top speed, so you will effectively get a little closer to it - just never enough to actually reach it. This is to make it look like that great distance you traveled brought you within planetary influence range. Does this make any sense??? May I should draw a picture... :D :D :D :D
-
To be honest, I don't think the FSO engine is a sensible base to start from.
You appear to want to change everything about the FSO engine to create your game, which is probably going to be much more work than building your own engine based on a more modern 3D rendering framework.
C# experience isn't much help with C++ either - superficially, they might look similar, but C# really has more in common with Visual Basic than C++.
There are a lot of fundamental limitations of the single-sector, floating-point basis of the FSO engine, one of which being the aforementioned simulation accuracy once you get a significant distance from (0,0,0)(World)
My advice is as follows:
1) Look for a good, easy to use 3D rendering framework - given that you're happy with C#, a DirectX-based framework would probably suit you pretty well.
2) Build a rendering engine that is designe to handle your simulation requirements.
Eg: A sector-based, that limits sector size to something that allows equal simulation accuracy throughout every sector. A logical extension of this is to use a portal-based engine for sector culling and for invisible traversing between sectors.
- An alternative approach is to make the player always exist at (0,0,0)(World) and move everybody else around - this allows for perfect simulation 'close' to the player, getting progressively worse further away. Obviously this approach means that you cannot have a multiplayer option at all, and also means that if the player is 'too far' away from important events, they won't work properly.
-
Good point, Tomo. You are quite right, I might still dabble with getting some ships into FS2 but yeh .. I don't thikn I wanna tackle the code here. I have discovered a really nice rendering engine and deals with incredibly incredibly incredibly incredibly HUGE distances, and renders stuff awesomely. Its called Celestia... http://www.shatters.net/celestia/index.html
The only problem is that I am trading off writing render code - to writing user control code - which will be pretty new to me. I was hoping to find a modifiable - engine that handles both the render and the user defined input but if it boils down to writing code I'd much prefer writing something I think I can actually accomplish and that is the user control (of the spaceship).
-
User control code is almost trivial compared to rendering code.
The simulation routines are the complex part - but those are the bits that you're forced to write because that's what defines the 'feel' of playing the game. Free-flight simulations aren't as common as the Quake/Halflife style of FPS simulations.
FreeSpace is an 'aircraft'-style simulation (as is the Star Wars franchise), rather than an 'accurate' simulation.
So if you don't want that style of simulation, you'll have more trouble adapting it than starting your own.
-
the thing that turns me off to a lot of other engines is the lack of source code. id love to use the orbiter engine (which from the outside seems to hbave an impressive sdk) but without the source its not as much fun. for example if you wanted to do something drastic, like weapons, or more accurate collision detection, id be sol.
-
Wait wait wait... they made an Independence Day 2?
Or did you mean Independence War?