Very good... Very useful. Only one niggling little thing... the radius you gave the starflier doesn't seem accurate... Trent and Juni are dwarfed by it in the game... and a radius of 1.6m makes it a little over 9 feet tall... only 1.5 times as tall as a human. (of course, this doesn't really matter as there are no humans flying around in space)

Other than that, Great Tut!

I loaded all the light fighter models up in Milkshape, to get an idea of their relative sizes, and the smallest was the Drake (using my arbitrarily decided 1 square per meter) at 6m radius, the Starflier ended up with 7.4m, and the Hawk and Legionnaire tied at 10m

Thanks for the reply.

Admittedly I did not put a lot of effort into figuring out the true radii of any of the ships. For personal use, I just used the cargo hold size of the ship as its volume and then extrapolated an arbitrary radius from that. You certainly do not have to use my method on that; it's just something I came up with so that the lower end light fighters would have the lowest moment of inertia.

I would actually be interested if someone were to discover "true" volumes for each of the ships.


Also, something I just thought of. The radius value I am using is an arbitrary average radius of the body. The Starflier has a rather large chunk taken out of it so that really brings the average radius down.

The ships in the game are not all scaled equally so precise calculations would be counter-productive.

Good info btw, I may actually use some of your formula in my own.

Check out the latest beta's of the Freelancer S.D.K. 1.5 and Freelancer Explorer v2.x

Looking at all of the above makes me think, "gee, I made a ramp and you can just lower the gradiant"

IOW... my method for the XML Toolkit Mod can be tweaked to taste, or you could add arbitrary rules to it, like "add 10 Mass for Heavy Fighters", etc., etc.

And your equations aren't factoring in Armor, which seems a bit... wrong. What you want is an accurate description of mass that factors in the game design variables... not an idealized picture of the ship as if two ships with two different mission designs but similar volumes would have the same mass. A modern tank is actually a bit smaller in volume than a semi truck with trailer... but it weighs a LOT more

Of course, if I were a little more anal, I'd have also figured in Hardpoints and arrived at some sort've numbers for weapons and other equipment that roughly described the ship with a full load (since Mass of equipment and cargo doesn't effect flight physics for squat, unless Alcander scores in that dept).

Anyhow... I like my system because it's simple, but not simplistic. I treat the whole ship as a realistic object, and the turning changes are a penalty applied to ships in direct proportion to the cargo, armor and power available in the rest of the game-balancing equations. I don't think what you're doing is wrong , mind you, but I don't agree with your rationale.

His formula allows for you to come up with your mass figures however you want.

mass = ({model size in cubic metres(ingame)} / 35) + ({# of hardpoints} * 5)

Btw this is just a quick example formula (don't use it! ).

Check out the latest beta's of the Freelancer S.D.K. 1.5 and Freelancer Explorer v2.x

You've surely noticed that weapons and cargo have mass themselves, and though I've not tested it with a full load of lead in a Drom, I did toss some armor on my starflier (the heaviest I'm including) and sure'nuff, it slowed 'er down some... at least in the turning radius department. kinda hard to get exact measurements, but if you exaggerate things, for instance, by making justice mk 1s weigh a ton and a half each, and then equipping 4 onto your shiny new patriot, should get some interesting results... in fact, I'm gonna test that in just a sec. results shortly.

Ok... this seems to be yet another place where DA has failed us... though to be fair they did have microshaft riding pretty hard on them. I am awed as I imagine what this game could have been with another 6 months or so of development time.... but I digress.

I bought myself a brand new patriot, went out, and timed a full 360 turn with no guns: approx. 4 secs.

Landed, purchased the now 1000 mass justices, loaded 4 on my ship, and lauched. Pulled another full 360 turn... 4 seconds. *maybe* 4.5. Point is, what should have increased the mass of the ship by 4000 (which if my understanding of physics is anywhere as near as complete as I think it is, should have greatly increased it's inertia... yet, turns were as crisp as ever, stopping as soon as i smacked the spacebar, the only motion being the rotation of righting the ship.

So equipped weapons do diddly to the handling. Not that it's a great deal, as weapons have only 10 mass anyway, Simply adding 10 to the ships actual mass per equippable hardpoint should be ok, tho. (while we're on the subject of mass, has anyone ever seen any visible effect from the fact that the sabre has 75 mass?)

@ Louva-Deus...

Mass should not be directly proportional to volume. As was said, a main battletank masses a lot more than a semi tractor-trailer but is actually smaller... more density of materials. Several inches of steel as opposed to a few mils of sheet, for instance.

My suggestion:
m= ((hit_pts/100)+(# hardpoints * 5))

why /100? well I used the Eagle's stats. I think 150 is a reasonable mass to start with, and this formula gets pretty close to that with the Eagle.

m = (9900/100)+(10*5)
m = 149

Of course, maybe 150 is nowhere near a good number to aim at for a very heavy fighter. simply adjust the formula.

It was just an example.

Check out the latest beta's of the Freelancer S.D.K. 1.5 and Freelancer Explorer v2.x

Thanks for the comments, guys.

Personally, here is how I have done hitpoints, mass, and turn rate rescaling

hitpoints = ( (2 * old hitpoints) + 12600 [Titan's hitpoints ) / 3
This dramatically increases the hitpoints of the lower ships, while leaving the higher ships with less and less bonuses, until the Titan which gets no bonus. The Starflier still has the least hitpoints, but it is more survivable now.

For mass and turn rate I skimped on the physics a little bit and made a table equating mass to turn rate
light fighter: 110 dps @ 100 kg
elite fighter: 95 dps @ 116 kg
elite 2 fighter: 80 dps @ 138 kg
freighter: 60 dps @ 183 kg

Each mass value is (110 dps * 100 kg)/(desired turn rate) so there is an inverse proportion going on here.

I further modify these values by taking into account the level necessary to purchase the ship. I also use an arbitrary scaling constant that right now I have set to 75.

Mass = base mass * (1 + necessary level/scaling constant)
For example, the Clydesdale, a freighter, will have a base mass of 183 kg, with a necessary purchasing level of 4.
Mass = 183 * (1 + 4/75) = 192.76 ~ 193 kg

The higher you set your scaling constant, the less effect the necessary level will have on the scaling. Likewise, the lower you set your scaling constant, the more effect the necessary level will have.

Turn rate is inversely proportional to the level required.

Turn rate = base turn rate / (1 + necessary level/scaling constant)
The clysedale again, being a freighter, has a base turnrate of 60 dps
Turn rate = 60 / (1 + 4/75) ~ 57 dps


This is probably not the best solution, but it does ensure that there is a more constant relationship between mass and turn rate.

EDIT: By the way, Argh, although it really wasn't relevant to the original post, taking hit points into account is probably a good idea. We can probably derive new hit points from the mass, so freighters will typically have more hitpoints than very heavy fighters. I will think about it some more.

Edited by - Uejji on 6/11/2005 7:50:08 AM

Somehow using the 'rank level requirement' does not sound like a good idea to me.

Check out the latest beta's of the Freelancer S.D.K. 1.5 and Freelancer Explorer v2.x

I'm intrigued that this conversation's gone this long. I've been rather surprised, to be perfectly honest, in how much interest there's been in my equations- I've gotten half-a-dozen emails about this topic, plus this thread. Given that what I'm seeing from these attempts to arrive at a "better" formula (note that "better" is in the eye of the beholder- in game design, there are no absolutes), I think I'll go ahead and explain the rationale behind my system a little more fully.

To address the previous posts, indicating where the formulas were heading and steps being taken to fix their most obvious flaws... here's a more lengthy response to certain details, and explanations about how I derived my formulae.

**************************************************************************************************
Mass

Making things have more hitpoints by their derived Mass is getting it backwards. A Freighter is mainly empty space. A VHF, on the other hand, is a flying tank. One simply cannot build a "realistic" balancing system that is using a poor starting model.

**************************************************************************************************
Volume

Real volume would have very little effect on the physical properties of a spacecraft.

Instead, if one is shooting for realism, one must think very carefully about the engineering aspects of a given design I don't go that far, because I don't really think there's much point in a game where the objective is to arrive at game-balanced ships, as opposed to completely "realistic" physical modeling, but one could do so.

**************************************************************************************************
Scalar Relationships between Mass and Volume

Let's look at two ships with equal volumes. Let's call them Combat and Transport, for the sake of clarity.

Combat is a short, squat design with a stubby nose that's clearly built for fighting.

Transport, on the other hand, is long and slender- basically a space-frame cage with cargo modules.

Combat's true mass may or may not be the same as Transport's- we have to figure from a "full weight", so in all probability Transport's real mass is probably somewhat less, because even when it's full of (insert weighted-average commodity here) it's not carrying much physical armor plating, IRL. While it will have some, to be sure, given the violent nature of the FL universe, it won't carry much. This is because armor's expensive , and every gram of armor is another gram of cargo that cannot be carried.

I don't expect that this relationship will change in the future- physical armor systems for IRL combat vehicles continues to become more sophisticated and expensive, not less, and if we're using physical armor systems (it's a "system", because it's almost certainly composed of various composites and active/passive devices to defeat attacks) it's probably just as expensive in the FL world as it is today, even though they surely have better manufacturing systems (after all, if low-level spacecraft are so cheap that you can buy one after flying a few missions, either pilots are paid amazingly well, or they cost a lot less than a car).

At any rate... I think it would be very fair and realistic to assume that armor, in the FL world, is probably higher-mass, per cubic meter, than the equivalent space in consumer goods or bulk commodities (with exceptions made for metals or other very dense things, which is why you have to look at that relationship as an average- we cannot assume that every transport is full of uranium).

Now look at the practical engineering aspects. Transport's long, thin design is a good one for cost-effectiveness IRL, if we're talking about spacecraft in zero-g. A skinny ship is cheaper to build for a given acceleration pressure than a fat one. This is because you need less internal bracing to handle the acceleration forces when moving in a straight line. Remember, we're not talking paper airplanes here- these are very massive objects, and differentials between the acceleration of various parts of the ship is going to put a lot of stress on the internal bracing. And the bracing needs to be redundant, or the ship will literally tear itself apart when taking the kinds of turns that FL ships are apparantly capable of. How this is achieved is irrelevant- we shouldn't even try to come up with a rationale for why the Starflier can pull turns that must push 30 gs

On the other hand, a fat ship is going to be able to spin (note- if you've read my previous work on FL's physics systems, you know how much I stress that spinning is not true turning behavior) much more rapidly, if we're being ultra-realistic. This is because of precession- assuming that both ships have their center of mass near the true center of the ship, Transport is going to have the forward sections acting like a big pendulum during a turn- and the faster it changes vectors, the more stress it's going to put on its bracing, over a much longer length. To use an obvious real-world example... if one takes a long straw of X volume and whip it through the air, precession (and air pressure, but that doesn't matter as I'll demonstrate) will cause that straw to bend as it accelerates along a curve. If one cut that straw into very short sections and magically attach them to one another, the resulting object has the same volume, but it will not be affected by precession to the same degree.

Given that FL's ships are probably made of some pretty miraculous composites, we can fudge all of this however we want to. But no matter how strong the materials are, the effects of precession are a constant.

Given that Transport's mainly empty space, given its mission, it obviously cannot spare a lot of volume on the bracing needed to withstand these forces. And given its design... that leaves even less room for such things. Therefore, Transport's real turning behaviors (spin + velocity changes) is never going to be as good as Combat. Which is perfectly realistic- you wouldn't expect that a mere transport would be able to out-turn a vessel purpose-built for combat.

All of these sorts of considerations are inherent in the calculations I used. It just looks simplistic .

**************************************************************************************************
Balancing Ships

To clean up the proposed equations and produce an ultra-realistic method of determining their physical properties, one should include the following factors:

1. What is the mission of the ship?

Design follows mission. Transports are going to be built to be as cheap as possible- shippers are trying to make money, and pennies-per-mission can make a very large difference in a company's bottom line. Don't base calculations on ideals- spend time coming up with factors that put real-world design considerations into the picture.

2. What is the physical layout of the ship?

Is it designed in a way that we can assume that it's well-braced internally? Note that all of the Freighters DA designed are squat shapes, not slender like the Large Transport. These are ships that (despite their trimmings) are supposed to look like they are capable of approaching the real turning behaviors of fighters. But DA was pretty realistic about things, and they are more sluggish in their responses, which is perfectly "realistic", given the game's rather flimsy physics.

3. Are gameplay factors taken into account?

Every important gameplay variable needs to be in the equation, if you're going for "perfection". In the final analysis, this shouldn't be a dry exercise in pointless number crunching. It should actually produce in-game behavior that is beneficial to gameplay. If it doesn't... it's a complete waste of time. I have zero tolerance for game designers who equate "realism" with good gameplay- these are not the same things. If the objective here is to produce a system that arrives at better game-balancing for FL's ships... then one needs to keep that factor foremost.

My system does arrive at fairly good game-balance. It seems simple because the final equations are elegant- it doesn't mean that they aren't producing the correct results, in terms of gameplay- I've factored in comments from players, etc., into my equations. If you've read over all of the equations, you can see that there are multipliers being used on most of the steps that I don't bother explaining. These are "fudge factors" that I arrived at... after lengthy testing in the game engine... that more-or-less reflect the gameplay that I wanted to achieve.

I didn't even try for physical realism, because most players simply don't care... and quite honestly, physical realism would result in worse game-balance, not better. Who wants to play a game where the best combat ships are all spheres? Freelancer is a game that's about style > substance, and in making the Toolkit Mod, I basically made the decision to totally ignore a great number of the physical properties of the spacecraft, in favor of gameplay balance.

But, if you're after a Holy Grail that turns a pretty cartoony space game into a physical simulation... here are some ideas that specifically address the points made above. Some of these things deliberately include more "fudge factor" numbers, which could only be verified through gameplay testing. I do not think that the resulting equations would translate into "better" gameplay, from my perspective, but I'm sure there's an audience for this sort've thing, and I don't think your quest is "wrong"- it's just not what I would do

The first thing we need is a list of variables:

Mission_Value: Mission_Value is a "fudge factor"- it's a constant picked from a range, describing the nature of the ship's mission. Let's say it goes from 1 to 10... 1 is a combat-only fightercraft, 10 is a freighter with absolutely no consideration taken for its combat effectiveness. You have to have it somewhere, if you're going to make things "realistic", and there's no way to arrive at an absolute value for this without referring to other game variables, which isn't realistic at all- resist the temptation to derive it from the ratio, say, between the amount of Power generated and the Mass. It's totally independent, if you sit and think about it, and it's not in DA's game design anywhere, but they surely had something like it in their original equations.

Precession_Value . This doesn't need to be super-accurate- SomeNumber is a constant that could be adjusted after gameplay testing.

Precession_Value = SomeNumber * (max_length - max_width) * Mission_Value

Mission_Value is used immediately here, because combat-only vessels are, naturally, going to have more internal bracing than other designs- it costs more money and eats cargo space, but it allows the ship to perform more effectively in combat. We'll figue Precession_Value into Spin later, and factor Mission_Value into Hold_Size and Hitpoints.

Volume is theoretically going to be calculated perfectly. I do not know of an easy way to do this, but a good rough approximation would be to calculate the volume of a spheroid that was as long as the max_length and as wide at the center as the max_width. This will result in Volumes that are preposterous in some cases, of course.

Hold_Size needs to include Volume, but some sort've equation has to compensate for the fact that a minimum amount of the Volume must be dedicated to non-cargo space, and Mission_Value must be factored in- the more Volume used for cargo, the less that's available for armor.

So, just as an example (note that this obviously doesn't reflect gameplay testing, so the numbers are pretty likely to be wrong)

Hold_Size = (Mission_Value * Volume) * SomeConstant

Therefore, Hold_Size will be accurate given the Mission_Value. SomeConstant is the "minimum" amount of a given ship's Volume that would realistically have to be dedicated to non-cargo duties. It's almost certainly a value much less than 1.

Hitpoints (i.e., "armor" is derived using the Mission_Value, much like Hold_Size, but in this case it's an inverse relationship.

Hitpoints = (Volume / Mission_Value) * SomeConstant

In this case, we're penalizing ships which have a high Mission_Value- they have less Armor. Such direct tradeoffs are both realistic and appropriate from a gameplay perspective.

Mass: this all-important variable has to reflect the Hitpoints and Hold_Size. Note that at this point in the equations Volume's already been "used up"- it's no longer important. Same thing goes for Mission_Value, although that will be used later, when we're looking at steering.

Mass = (Hitpoints + Hold_Size) * SomeConstant

SomeConstant is some number that's less than 1. Mass should be rounded up to the nearest unit, but you don't have to do so, technically- it's a float out to 6 places. The results, more-or-less, should be that ships with a lower Mission_Value will have a higher Mass, no matter what the starting Volume is.

Finally, we're ready to talk about how well the ships steer. Let's calculate Steering Torque. We need to figure Mission_Value and Mass into this equation.

Steering_Torque = StandardBenchMarkValue - (Mission_Value * Mass * SomeConstant) or MinimumFloorValue

StandardBenchMarkValue is an arbitrary standard for the steering variables. In the case of the Toolkit mod, I used the value 17500... it doesn't really matter what you use as the benchmark, though. SomeConstant is yet another fudge factor, arrived at after gameplay testing, to arrive at ships that move reasonably well and meet the game designers expectations. And, of course, there must be a minimum floor for this result, or we could end up with negative numbers at the very high end! There's probably a way to avoid that that makes sense, but I didn't ever see one.

Angular_Drag = StandardBenchMarkConstant

We do not want to modify Angular_Drag, ever. It should be left alone, because the ratio between it and Steering_Torque is what's important, and we cannot have anything like a reasonable ratio calculation unless we leave that alone

Rotation_Inertia: Rotation_Inertia is the way that DA combined Precession_Value (if they even bothered thinking about that, which I doubt) with Mass to arrive at more realistic steering behavior. They really didn't mess with Rotation_Inertia with smaller ships, but we could do so.

Rotation_Inertia = StandardBenchMarkConstant * {(Precession_Value * Mass) / SomeConstant}

Once again, SomeConstant is there to give us a fudge factor, so that the final results make sense within the gameplay context. We don't want our benchmark becoming ridiculously high, or players will rightly complain that even the smallest Fighters constantly oversteer.

**************************************************************************************************

Now, we could go farther than this, and derive the Power requirements, probably just deriving it like so:

Charge_Rate = (Mass * SomeConstant)

Capacity = (Charge_Rate * SomeConstant) + SomeNumber

**************************************************************************************************

...and that's "all" there is to it.

I think that such a system, once cleaned up and tested, would work just fine, but I don't think it'd be a "better" system than what I'm already using.

Why?

1. Precession means that many ship designs simply aren't valid. This flies in the face of reality, where engineers have to come up with various solutions to such problems, and who knows... maybe, in the FL universe, they have "inertial dampers" or something that will cancel out this fundamental physical property. If we leave it in, we're being slaves to 1950's "hard sci-fi" mentalities, where people assumed that the technology of the day would continue to apply to futuristic problem-solving. I think that anybody who's in game design should abandon such thinking- our objective is to make games that are fun, not annoy people with our pretentions about what technology will or won't be capable of. If such an idea makes a really good central premise, it's worth using... but in this case, it doesn't.

2. Ships that aren't designed for combat are going to have almost zero chance against ships that are, as opposed to having some chance. This doesn't serve gameplay well. If you don't figure it all very carefully, then it means, for example, that players in Freighters will have to run away from every Encounter, and can never take Missions- they're just able to take cargo from point A to point B. Therefore, players will tend towards ships near the middle of the bell curve and lower, because... let's face it... FL is a game that's primarily about blowing things up

3. If you do this very poorly (say, you get too obsessive about using real-world numbers), you're going to end up with ships that are so completely unsteerable that very few people will play your mod for more than a few minutes. I dunno whether you've ever tried out any ultra-realistic space simulations before, but they aren't much fun to play. The last one I tried was an absolutely awful game called Indepedence War- which was a completely un-entertaining experience. Adding complexity and making it harder just to do the basics of space combat, such as moving around, is something that good game designers should avoid, in my opinion. Players very clearly don't like it- there's a reason why X2 doesn't have FL's mod community or large following, and it's not just because the game engine's a little more difficult to work with.

This doesn't mean that X2 or Independence War were "bad" games- but it does mean that they weren't designed very well for a popular audience, and apparantly just make their money off of the fringe out there which wants an experience that's more "sim-like". But if you're thinking that ultra-realism will make your audience larger... think again. From Wing Commander through FL... the big winners have consistantly been game designs that stress "fun" before "real".

First of all, the purpose of this thread was in the interest of the ship physics values themselves, not in mass, volume or hitpoints. I threw in what I had done personally as an afterthought. The entire purpose is to say, "Here, plug in your mass and volume values that you figured out your own way."

Secondly, my feelings are not going to be hurt if you choose not to use what I've laid out here. It is not about 100% true Newtonian physics, it is about being able to scale to such a degree that we can come pretty close to it if we felt like it. If you don't want that, fine; set the drag coefficient up to 400 or so. The ships will still have the same turning rate, but they will simply behave less realistically. That's why I left the drag coefficient as a variable, so you would have more control over that.

Argh, If you feel that my system is in competition with yours then you are taking this thing way too seriously. All I know is that I've used your system, and I was unsatisfied. If people are satisfied with your handling model, they will use it. If they're not, then they'll use something else. I've simply taken a different approach and application that so far has worked better for me in what I am trying to do. The joy of it all is that modders are able to employ whatever model they feel works best for them, and by giving several formulaic choices, we are still granting a level of confidence but more freedom to decide.

But since you are convinced in the superiority of *your* system, and *your* formulas, and *your* methods, please feel free to continue employing them in *your* mods. :>

By the way, you seem to be confusing precession with second moment of inertia/area. Not that it really matters.

What I'd really like to see is a breakdown of what each stat does. What follows is a summation of the handling stats of a Patriot: (Straight out of the SDK)

mass = 100.000000 ;Obvious what it is, kinda vague on what it actually does
hold_size = 25 ;does nothing, inherently
hit_pts = 1300 ;again, nothing unless we make it by including it in our formulas
steering_torque = 24000.000000, 24000.000000, 58000.000000 ;Explained fairly well elsewhere, Pitch, Yaw, Roll. Works pretty much the same as engine thrust: pushes against the Drag.
angular_drag = 15000.000000, 15000.000000, 35000.000000 ;as above: this is the number you divide into the torque to get the radians/sec turn rate.
rotation_inertia = 2800.000000, 2800.000000, 1000.000000 ;Not sure if this does anything when you START your turn, but it for certain affects how quickly you end your turn... provided you're not in mouse flight. In mouse flight, your bringing the cursor back to center decelerates the turn (in theory, if you did it fast enough, you'd see the effect of inertia, but in practice, that's tough). In "free flight" when you stop telling the ship to turn, this affects how fast the turn actually stops.
nudge_force = 30000.000000 ;not a clue in the world what this does.
strafe_force = 20000 ;this, I know to be how much push is applied to the linear drag to produce sideways motion.
strafe_power_usage = 2 ;How much *Thruster* energy is used to power said sideways motion.
linear_drag = 1.000000 ;This adds to the Engine's linear drag and is the reason we divide by 600, and not 599 to get the speed. Also, without this, the ship would coast forever in engine kill mode. Set this High, and it stops so fast you get whiplash.

From the Engine (included for completeness):

max_force = 48000 ;This is what we divide by the linear drag to get the speed.
linear_drag = 599 ;adds to the Ship's linear drag. Only affects handling while the engine is on. Engine kill and it goes away.
reverse_fraction = 0.200000 ;well documented elsewhere: a number < 1 which determines how fast a ship can go backwards, compared to its forward speed. @ 1, the ship goes backward just as fast as forward, at 0, it makes a good brake.

edit: this means this ship has these stats:
turn rate: 1.6 radians/sec (just over 90 degrees/sec)
top speed (without thrusters): 80
Reverse speed: 16
lateral speed: 33
very "crisp" turns, but an asteroid impact will bounce you like a pinball.

Which is exactly how it is ingame.

I think I explained most of it pretty well... still have no idea what nudge_force does... I'm sure someone here does tho.

Hey... I just thought of something... Maybe nudge_force is how much force applied to the poor, unsuspecting asteroid when you slam into it? I'mma try changing those values and find out... Well, I gave the patriot the nudge_force of a Dreadnaught... and nothing really happened when I bumped into that Rhino... So I donno.


Edited by - myrkul999 on 6/13/2005 12:01:57 PM