Size Attribute?

[Atgxtg]

Technical is good even if my background isn't in physics or mechanical engineering. Having an idea about your reasoning is exceedingly useful in evaluating how to approach using your methods in stating up mecha for my game.

I know what you mean. I don't have a background in physics or mechanical engineering either, and I had to learn enough to make some sense of it. What happened was that way back I was dissatisfied with the way most RPGs handle vehicle speed and maneuverability. In general they tend to give a cost for an engine with a speed of "x" and the big vehicles tend to end up faster and more maneuverable because they have more "space" available for engines. So I looked into how it really works and found out that the real world math is simplier than the way most RPGs handle it! Most of the difficulties that go with doing it up in BRP is because of the way BRP does things. Vehicle and critter design rules weren't something the authors were thinking of when they first came up with the game system and stat scales, nor was it a major concern of those who have tweaked the system over the decades.

The formulatic approach also helps with statting up large numbers of examples. I can plug in the real word data for dozen of real world vehicles and creatures and the formulas will spit out usable game stats. I think we got stats for over 1200 critters.

Knowing how the designer came up with one or more rules really helps when working on your own designs, or even when trying to figure out why an oddball stat score ended up the way it did. It also helps when tinkering with things that already have stats. For instance, figuring out what the improvement in speed will be if you up the engine output by 50% (about 14%) or if you add a 1000kg thrust (STR 42) jet engine to your automobile.

It also helps bigtime when you try to stat up stuff from TV and film. Often the shows give you quite a bit of real world data, but no way to translate it into RPG terms.

[Canis latrans popus]

It's an awesome project, because then the real world becomes the ultimate sourcebook.

[Link6746]

Still need acceleration data, but yeah.

[Atgxtg]

Still need acceleration data, but yeah.

I got some acceleration data.

In reality F=ma, that is Force is equal to mass times acceleration. So a= F/m.

Now since Force is STR and mass is SIZ, and since the SIZ table in BRP is logarithmic we can turn that into A=STR-SIZ, with about a -10 modifier on the SIZ table since a Thrust: Mass ratio of 1 should give an acceleration of 1G. (That is why I am torn between using the SIZ table for SPEED or setting up it's own table with 0 = 10. The former lets us use ONE table for everything, but with modifiers, while the latter requires an second table but gets rid of most of the modifiers).

Now for spacecraft that is all we need. Unfortunately most vehicles operate in an atmosphere, and that makes it a bit more complicated. What happens is that as the vehicle goes faster and faster, it has to use more and more of it's thrust to overcome (wind) resistance and has less and less thrust left over to accelerate. When it finally reaches the point where all it's thrust is devoted to maintaining it's speed and the vehicle has no spare thrust left over to accelerate, it is traveling at it's maximum speed.

So to be entirely realistic ACC should drop as the vehicle's speed increases. But for game purposes I'll probably work up an acceleration rating at a nice midpoint and use that. Probably at about the 65% Thrust/60% top speed mark, since that is about the 3m per MOV mark used as the cruising speed for vehicles in BRP. I think (warning! I haven't slept yet today so my math could be off) that word work out to:

ACC= STR-SIZ-16 in m/s on the SIZ table.

Oh, FYI I sorta houseruled 1 ACC=1m/s (or 1 yard/sec for those who don't like the metric system). It matches up fairly well with the ACC scores for most vehicles in the BRP core rules and gives us some sort of benchmarks to work with. I also got some method for converting 0-60 acceleration times into ACC scores, somewhere.

I could put notes on how to work out ACC at 20% increments of top speed (corresponding to the 1-5 MOV multiplier) as an optional rule in a sidebar for those who want that level of detail.

But I haven't had the chance to check this against the ACC values of real cars yet. Plus I'd have to rework the formulas to use POW instead of STR, since most ground vehicle engines are rated in terms of power rather than force.

Edited November 7, 2013 by Atgxtg

[Atgxtg]

Still need acceleration data, but yeah.

I got some acceleration data.

In reality F=ma, that is Force is equal to mass times acceleration. So a= F/m.

Now since Force is STR and mass is SIZ, and since the SIZ table in BRP is logarithmic we can turn that into A=STR-SIZ, with about a -10 modifier on the SIZ table since a Thrust: Mass ratio of 1 should give an acceleration of 1G. (That is why I am torn between using the SIZ table for SPEED or setting up it's own table with 0 = 10. The former lets us use ONE table for everything, but with modifiers, while the latter requires an second table but gets rid of most of the modifiers).

Now for spacecraft that is all we need. Unfortunately most vehicles operate in an atmosphere, and that makes it a bit more complicated. What happens is that as the vehicle goes faster and faster, it has to use more and more of it's thrust to overcome (wind) resistance and has less and less thrust left over to accelerate. When it finally reaches the point where all it's thrust is devoted to maintaining it's speed and the vehicle has no spare thrust left over to accelerate, it is traveling at it's maximum speed.

So to be entirely realistic ACC should drop as the vehicle's speed increases. But for game purposes I'll probably work up an acceleration rating at a nice midpoint and use that. Probably at about the 65% Thrust/60% top speed mark, since that is about the 3m per MOV mark used as the cruising speed for vehicles in BRP. I think (warning! I haven't slept yet today so my math could be off) that word work out to:

ACC= STR-SIZ-16 in m/s on the SIZ table.

Oh, FYI I sorta houseruled 1 ACC=1m/s (or 1 yard/sec for those who don't like the metric system). It matches up fairly well with the ACC scores for most vehicles in the BRP core rules and gives us some sort of benchmarks to work with. I also got some method for converting 0-60 acceleration times into ACC scores, somewhere.

I could put notes on how to work out ACC at 20% increments of top speed (corresponding to the 1-5 MOV multiplier) as an optional rule in a sidebar for those who

[Link6746]

This will prove invaluable for my post apocolyptic campaigns. I'm also going to state right here that tomorrow I'll get some detailed info of acceleration lag at high speeds. My father's a grease monkey who has a 200MPH run at the dry lake beds here in his bucket list.

How I understand this:

Torque: Provides the capability for the top speed

Horsepower: Helps get to top speed. (Additive to current speed, up to top speed)

Weight: Drags down top speed and acceleration (subtracted), but increases ability to make turns with the same types of parts

Drag Coefficient: The higher the drag coefficient, the greater loss of acceleration at higher speeds

What I suggest:

For drag coefficient, I'd suggest finding a way to turn it's results percentile and reverse the resulting percent (out of 100%, how much is NOT there), in order to make it divisible by 5. Then you have a simple Drag Factor that is in increments of 0-20 or so, easily convertible to a stat.

Cornering, IMO, should be rated at different maneuverability ratings that require different levels of checks (auto, easy, normal, hard, impossible) of the drive/pilot skill necessary for different situations. As for a linked stat, perhaps DEX/AGL, and using weight to provide a bonus or penalty over a certain amount of speed to do this?

With these things, it would be very easy to make a decent vehicle system. My thoughts on this:

Separate acceleration stages to Stage (equal to Meters/n, where n=<generic speed division in meters>), and have the Vehicles Gear determine Acceleration stages and Speed caps using the rest of the calculations to provide a unified conversion setup. Essentially this provides the ability to use vehicle stats to translate things into and back out of game terms, and sounds much more complex than I think it will be in practice, while remaining a sort of advanced vehicle system.

Edited November 8, 2013 by Link6746

[Atgxtg]

This will prove invaluable for my post apocolyptic campaigns. I'm also going to state right here that tomorrow I'll get some detailed info of acceleration lag at high speeds. My father's a grease monkey who has a 200MPH run at the dry lake beds here in his bucket list.

The lag is simply because acceleration is based off of excess thrust or excess power, and the faster a vehicle is going the less excess it has.

How I understand this:

Torque: Provides the capability for the top speed

Horsepower: Helps get to top speed. (Additive to current speed, up to top speed)

Uh, not really. Torque is turning force. Horsepower is a measure of power, not force. Force and power are two different but related things.

While force is easier tpo use for speed calculations than power, torque isn''t as easy to use, since it has to go through several gear ratios and the wheels to get it "converted" into a linear (straight line, i.e forward) force.

Weight: Drags down top speed and acceleration (subtracted), but increases ability to make turns with the same types of parts

Neither is true. Mass drags down acceleration, not weight. That might seem nit picky, but it is important to remember when dealing with spacecraft or alien planets with different gravity than earth. A 50,000 metric ton spacecraft would weigh nothing in deep space, but would still have a mass of 50,000 metric tons. Matter of fact, weight actually increases acceleration and top speed slightly, since it allows the tires to get better traction and be slightly more efficient at transferring the engines torque into forward motion.

Top speed is mostly determined by the drag force the vehicle has to overcome. The drag force is dependent on the vehicles size (as in length, width, height) and how aerodynamic (or hydrodynamic) the vehicle is. So packing more weight into a vehicle generally won't slow it down as long as the weight doesn't change the surface of the vehicle. Now it you put more weight on the vehicle than it was designed for, you can wear the engine, drive train and suspension out faster and break something, but it shouldn't affect top speed-it will just take you longer to reach the top speed. Oh, and the vehicle will steer like a cow. If you put a LOT more weight on the vheicle than it was designed for, you might break something immediately, or even put so much force pushing against the ground (i.e. weight) that the wheels won't turn, or just spin in place (like an old wind up car).

Drag Coefficient: The higher the drag coefficient, the greater loss of acceleration at higher speeds

the Cd is a measure of how streamlined and aerodynamic the vehicle is. By itself it doesn't really mean anything. You have to multiply it by the vehicle's reference area to get the equivalent drag area of the vehicle.

For example, a modern automobile might have a Cd of 0.32, while the airship LZ-129 Hindenburg might have had a Cd of around 0.032. It looks like the Hindenburg, it ten times more streamlined than the car, but that's not really the case. You see they use the frontal area of a car as the reference area to determine the equivalent drag area of a car, while they use Volume^(2/3) for the reference area for an airship. So the two Cds don;t mean quite the same thing.

Now if you factor in the frontal area of both vehicles, and air density, you can get the drag areas for both vehicles to get something worth comparing. Like so:

Car: Reference Area=2.5 square meters, air density 1.23; Drag Area= 0.984 square meters

LZ-129 Hindenburg: Reference Area: 3420 square meters, air density 1.23; Drag area= 109.44 square meters)

So the Hindenburg will experience about 111 times the drag force that the car would experience as a given speed.

What I suggest:

For drag coefficient, I'd suggest finding a way to turn it's results percentile and reverse the resulting percent (out of 100%, how much is NOT there), in order to make it divisible by 5. Then you have a simple Drag Factor that is in increments of 0-20 or so, easily convertible to a stat.

I don't think that would help. By itself it is meaningless, you need to factor in the shape and reference area. Secondly, 5% increments would be too coarse. Just the Hindenburg car example, needs more than a 100:1 ratio to work. And that's just the tip of the iceberg. It is even possible to shape an object so as to increase it's drag. A parachute, for example.

What I got now, is for vehicles to start of with a drag rating equal to their SIZ, but which can be reduced by buying points of streamlining (1 point of streamlining reduces the effective SIZ by 1 point). That about as simple as I can get it in game terms while still being somewhat realistic.

Cornering, IMO, should be rated at different maneuverability ratings that require different levels of checks (auto, easy, normal, hard, impossible) of the drive/pilot skill necessary for different situations. As for a linked stat, perhaps DEX/AGL, and using weight to provide a bonus or penalty over a certain amount of speed to do this?

Cornering depends on the vehicles lateral acceleration, stability, and what speed it is going at. The key thing here is what speed it is going at. This might surprise you but a signel engine prop plane can pull a tighter turn than a fighter jet! But that is becuase the jet is moving so fast.

With these things, it would be very easy to make a decent vehicle system. My thoughts on this:

Separate acceleration stages to Stage (equal to Meters/n, where n=<generic speed division in meters>), and have the Vehicles Gear determine Acceleration stages and Speed caps using the rest of the calculations to provide a unified conversion setup. Essentially this provides the ability to use vehicle stats to translate things into and back out of game terms, and sounds much more complex than I think it will be in practice, while remaining a sort of advanced vehicle system.

Sounds very much like what I did for the optional staged acceleration. Basicalyl what I did was work out acceleration at multiples of the vehicles MOV in m/s. For example a car that has a base ACC of 8 and a MOV 100 would get an ACC scores something like this:

0m/s-99m/s ACC =10

100m/s-199m/s ACC 10

200/ms-299m/s ACC 9

300-399m/s ACC = 8

400-499m/s ACC =5

500m/s ACC= 0

The reasons why I did it that way is because not only does it match up with the x1-x5 varible for MOV, but the percentages are fixed for each step. That means we can reduce it down to ONE ACC score and mutipliers for each speed range that would be universal for every vehicle. Specially.

0x MOV = 100%

1x MOV= 99%

2x MOV = 94%

3x MOV = 78%

4x MOV= 49%

5x MOV = 0%

[Link6746]

While I didn't like having my post picked apart like that, I will admit my father is a terrible teacher (My attention span regarding mechanical work doesn't help- I realized I wasn't interested in fixing cars long ago, but I've picked up just enough to get in trouble with).

My reasoning for cornering ratings was mostly to do with the fact that you could put things like flaps or jets or four-wheel turning things on a vehicle to improve it's turning radius.

Thus DEX/AGL could provide a base representing the equipment on the vehicle, which could be modified by various factors, providing several levels of turn speed and their requisite difficulties for different skill ratings on a chart.

[seneschal]

Uh, sorry guys. You both lost me somewhere on Page 3 during the discussion of acceleration vs. force, neither of which is exactly the same as torque or thrust. I'm not torqued at you. My grasp of math and physics is worse than yours.

When are you publishing that monograph on high tech vehicles again?

I'm not that hard to please. As long as it has full BRP stats (and deck plans) for the Death Star, the Yellow Submarine, and Herbie the Love Bug, I'll be perfectly happy.

Edited November 9, 2013 by seneschal

[Atgxtg]

Uh, sorry guys. You both lost me somewhere on Page 3 during the discussion of acceleration vs. force, neither of which is exactly the same as torque or thrust. I'm not torqued at you. My grasp of math and physics is worse than yours.

LOL! Sorry 'bout that. My fault. But it does help to illustrate why I want to covert it all into game terms and such. It helps to avoid or at least simplify a lot of math.

[Erasmus1966]

Don't feel bad Seneschal... I've worked with Atgxtg on a major project for the last year or so and I STILL get confused when he gets all Math-y

[Atgxtg]

Don't feel bad Seneschal... I've worked with Atgxtg on a major project for the last year or so and I STILL get confused when he gets all Math-y

Yeah, but you loved it when I put all the mathy stuff into a spreadsheet and set it up so we automate the process and spit out critter stats. I introduced the assembly line to stat writups.!

[seneschal]

Mass produced critters??? Send in the clones!

[Canis latrans popus]

Yeah, but you loved it when I put all the mathy stuff into a spreadsheet and set it up so we automate the process and spit out critter stats. I introduced the assembly line to stat writups.!

[Erasmus1966]

True - Mustn't grumble lol

All that database/spreadsheet stuff we did helped me get my new job too, methinks

Ahem - sorry

When we say 'Mass produced', Atgxtg means we applied sound scientific and mathematical principles (well, it was HIS math and science almost entirely - I just did the storage, coding and data entry )

[Atgxtg]

Mass produced critters??? Send in the clones!

LOL!

Yeah. What I did was use something called the cube-square law to scale existing creatures up or down to give us attributes for similar types of animals. For example, I used the stats for the Allosaurus as a baseline attributes for all large theropods (big carnivorous dinosaurs). So if I wanted to come up with stats for a T-Rex, I would up the SIZ to reflect the increased mass, then apply two-thirds of than adjustment to STR and CON to reflect the greater muscle mass and resistance that goes with the T-Rex being larger. Then I might go in a fine tune some stuff to reflect known differences between the species (the T-Rex has a stronger jaw and a better bite, for instance), but generally the "assembly line" stats are close enough for gaming purposes.

The assembly line uses a default baseline creature for each basic animal body type (dog, cat, horse, etc.), and we just plugged in mass scores for the various animal species into a spreadsheet (or database) that actually does the crunchy math stuff that nobody wants to do, and it spits out BRP game stats. The same holds true for my vehicle stats. I put the formulas into a spreadsheet. plug in real world data for existing vehicles and the spreadsheet spits out BRP game stats. I find that method a lot easier and faster than trying to write up stats for hundreds of animals and vehicles manually.

One nice perk of using a formulaic approach is that anybody who uses the same method will get the same results. So anybody could plug in the data for a new creature or vehicle and get the same BRP stat scores as anybody else. That will give us a lot more consistency when dealing with lots of examples. A given value in kilograms or kilowatts will always result in a certain SIZ or a certain POW score.

Another perk is that by using real world data and formulas, it's fairly easy to convert the results into stats for different RPGs. If you know your cheetah or car can go 100kph then all you need to know is what 100 kph translates into for a given game system.

Edited November 13, 2013 by Atgxtg