Atgxtg

I think it is mostly out of a combination of habit and a somewhat warped modern view on things, helped a bit by ignorance. RE: Habit - Why are we still referring to mail armor as chain or chain mail? It's the same thing. We got so used to calling it chain that it stuck. Likewise, we got used to the common notions about mail and plate. RE: Warped Modern Worldview - people generally didn't walk into a shop and chose between mail or plate based on game stats, weight or cost. Historically it was a bit more complicated. Fully articulated medieval plate (as opposed to earlier plate) was developed in stages, took a lot longer to make than mail, and was much, much more expensive. At least up until some technological advances were made that drove down the production costs to the point were it ended up cheaper and faster to produce than mail - at which point everyone who could afford armor did mostly stop buying mail for plate. For the most part it wasn't like mail and plate were competing technologies. As far as the relative weights, weight distribution, and costs of mail and plate, it varies quite a bit depending on which examples you use. Some of the Gothic and jousting armors were quite a bit heavier than mail - especially when some of the "suits" of mail might only have mail covering the upper arms and chest. There is even a good deal of variance between different types of mail armor based on weave, reinforcement and quality of fit. Basically armor got better over time. Plate evolved from mail. It is more an evolution of mail than a competing technology. When armor was made is probably a better indicator of protective value, ENC and cost than the armor's basic form. RE: ignorance. Since few people have actually worn armor, let alone relied on it for protection, we lack enough familiarity to spot the fallacies. If somebody were to claim than a VW Beetle could fly, or reach speeds of 20,000 kph, we'd know something was off right away.

Well you have to go waaayyy back but old Glorantha-based RQ used to deal with followers somewhat. Basically Rune Level (think highly experienced with high standing in a church) characters were so important that they would have a retinue.

Plus a lot of things can be ported over from similar systems. Most skill-based (as opposed to level-based) RPGs have enough similarities that porting over certain rules, sub-systems and tech is not only possible but fairly easy. For example, it would be fairly simple to port over most of the old FASA Star Trek RPG into BRP. The biggest sticking points would be from the % stats in FASA Trek and CoC7 helps to solve that. And FASA Trek acts as a gateway to porting over stuff from other Trek RPGs. So some very diverse and non-BRPish stuff could be ported over to BRP to make a BRP Star Trek campaign. And that's just one example. The only real drawbacks are that it's work for the GM to port all that stuff over.

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.

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.!

That is sooo funny! It's just the sort of thing a kid would do.

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.

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. 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. 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). 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. 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 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. 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%

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

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.

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.

LOL! Me too. I've actually been working of some stuff to let people do more with SIZ, and make it easier to wrap their heads around. Basically the problem is that the SIZ table progression is a logarithmic doubling progression rather than a linear progression. So I got a table that you can use to multiply values using the SIZ table. For instance, x2 = +8 SIZ, x3 is about +12 SIZ, x4 is +16 SIZ, x5 is about +18 SIZ. I also got a sheet for working up stats for giant sized creatures that does the whole cube-square law thing for you so you don't have to. If, for instance, you want to make an animal or object twice as big (length, height and width), you look up x2 on the sheet and see that you should add 24 points of SIZ and 16 points to STR and CON (for realistic giants -fantastic ones should scale STR at the same rate as SIZ).

Not quite. Since 1kg thrust is approximately 9.81N (say 10), then he N will be be about 10 times the kg,or about 26 points higher on the SIZ table.

Yes. Although technically speaking, Force should be measured in Newtons not kilograms, I used the latter so as to put STR and SIZ on the same scale. That way you know that a vehicle with STR 50 and SIZ 50 has a 1:1 thrust-to-mass ratio, a base acceleration of 1G, and could take off vertically, if the thrust was used as lift. Since the thrust rating of real world jet engines is often listed in kg or lbs of thrust, I don't feel too guilty about rating STR in kg. Using kg instead of N will reduce the STR score by about 26 points or so. Now keep in mind that the STR score is to total thrust of the engine. So if a vehicle is using some of that thrust for other purposes (such as for lifting thhings) that STR wouldn't apply towards the vehicle's speed. Since we are dealing with real world terms, instead of gobbledygook, 1kg of thrust is approximate equal to 9.81N (that's 1kg mass, multipled by the acceleration of gravity), but a common approximation used in the real world for design purposes is 1kg thrust = 10N. The 10:1 ratio is simple to do in your head, and the 2% error won't really matter for our purposes. In fact, since BRP stat values encompass a range, most of the time the STR score you get with 10:1 will be the same as with 9.81:1, and even when they differ the difference will only be by a point. The 10:1 ratio is also why I rated POW in terms on kilojoules instead of joules - it lets me rate STR, SIZ and POW on the same relative scale (sort of). One of the little speed bumps I trying to work around is that since a value of 1kg would be about a -37 SIZ if the doubling progression were used beyond the SIZ 8-88 range, a modifier has to be added to some of the equations to get the correct values. For example, if a Vehicle had a thrust of 100kg (STR 16) and a velocity of 100m/s (SPD 16 on the SIZ table) it should have a power rating of 100000J (100x10x100) or 10000dJ (POW 95). I would like to work it out so I can just add STR to SPD to get POW but can't because a value of 1 doesn't equal a stat on 0 on the SIZ table. Another speed bump is that when engineers design veicles in the real world they use different reference areas to calculate the drag area of the vehicle. This means that cars, boats, airplanes, and submarines all use different reference areas and drag coefficients to determine their respective drag areas. This means that a car and a airplane with the same drag coefficients are not necessarily streamlined to the same extent, since they are not using the same reference areas. The car is using frontal area, while the plane is using it wing area. Sorry if I got too technical here. Most of this "nuts& bolts" stuff I am planning on hiding away. People won't have to know or use it to stat us or design vehicles. I, unfortunately, do have to know and use it to make sure it all working out correctly behind the scenes. But, since I do have the "real" info on hand, it can make it easier for someone to write up something specific if he has real world terms to work with and wants game stats.

If I am not mistaken, your idea is to subtract the defender's Protection Rating from the attacker's Damage Rating in order to determine a "default" injury level. Then the defender's Luck roll would modify the injury level. A problem I see with this is that the success levels of the attack and defense roll don't affect the level of the injury produced by the attack. You should perhaps use the difference between those rolls to modify the "default" injury level instead of the Luck roll?

This is nearly the same damage system as the one used in Usagi Yojimbo RPG. In that RPG the difference between the damage and soak determines how many wounds a character takes from an attack. In UY differences between the attack/parry, gifts and weapon traits can up the damage before comparison. Some suggestions: 1) You could simplify the Injury Table, and use success levels for the LUCK roll.Each level of success on the LUCK roll would bump the injury down a degree in severity. A fumbled LUCK roll would make the injury one level worse. The revised Injury Table would look something like this: Damage-Soak/Result -1 or lower = No Injury 0 = Scratch +1 = Minor Wound +2 = Major Wound +3 = Incapacitated (alive but unconscious-needs first aid to revise or wakes up after some time) +4 = Mortal Wound (eventually fatal injury. Character needs successful first aid within 2 minutes to stabilize or he dies.) +5* = Killed 2) Another idea-instead of the Luck roll reducing the damage, how about the luck roll can be used to replace a soak roll? That way you don't need two damage results per success level. Characters can try for Luck when they get a horrible soak roll. When they get a good soak roll, they won't be able to use LUCK to avoid damage completely. 3) If the LUCK points option is going to be used, then maybe characters can spend LUCK points to reduce the Wound Level one step. 4) Perhaps when a character gets injured he must make some sort of roll or have his own action delayed (say 3 SR or 5 DEX ranks), or possibly lost.>

I got it to the point where it does most of the work. There are a few tricky bits, but I've got working formulas for most things. Right now I am working on simplifying a few things, adjusting scales, and trying to find a better formula for armor and weapons, plus a few spot rules to account for the differences in tech (for example, sailing ships probably need longer turns in chases, and modern aircraft can often chase targets beyond visual range). But, if it helps, I got the vehicle top speed formula simplfied down to: SPD= (STR-DRAG)/2 or SPD = (POW-DRAG)/3 You read SPD on the SIZ table using m/s instead of kg. STR is kg thrust POW is in decajoules (I think). DRAG is the vehicles SIZ plus modifers for vehicle type, streamlining, and medium (air or water)

Sounds sensible. Since CF is emulating D&D to some extent,it makes sense to use the same scale and measurements as D&D. it works pretty good for a Japanese setting, too. Their building were based around floor mats that were approximately 3'x6', so all the buildings actually were all built on a 1 pace grid.

You could always use a 1 pace grid.That way it could be read as either 1 yard or 1 meter.

It has come in very handy for me, and perhaps for a few others.. Because I've brought this up before. In fact I posted a "revised and expanded SIZ table"on the forms a few years back that fills in weight and mass values for the "missing SIZ" stats on the BRP SIZ table, and attempts to correct the errors on the BRP SIZ table. I think Rosen even used the table for his SIZ stats in BRP Mecha. I'm the guy who has been working on a vehicle design system for BRP (off and on) and a BRP Bestiary (with Erasmus1966), and both use the x2mass =+8 SIZ progression along with stuff like the cube-square law to extrapolate good BRP game data from real world numbers and existing BRP stats. The cube-square law really helps when making up giant or midgit creatures. Basically if you double all of a creatures dimensions (length/width/height) you would add 16 to STR and 24 to SIZ. The 2 STR per 3 SIZ ratio holds true here and is why insects are so strong relative to their mass, and why giants can only get so big before thier body can't support or move the mass. I got a bit more real world formulas converted into BRP terms, too. Such as the relationship between SPEED, Thrsut (read STR in BRP) and Power (i.e. POW). It did take a little more effort to work that stuff out in BRP terms but the payoff is that I have a consistent scale for turning real world data, such as mass, thrust, velocity, and power into SIZ, STR, MOV, and POW. Eventually I'm hoping to boil it down to the point where a GM can just plug the real world data into a spreadsheet and it will spit out BRP game stats.

Itmight be worth pursuing despite the risks. Pretty much every version of BRP tweaks the basic rules in some way here and there, and not every in the BGB is really compatible with everything else. . Chances are, if you look over the other subsystems, you can figure out what needs to be tweaked to make it work without HPs. I was doing something along those lines with an idea I had to get rid of the damage rolls, relying on the attack rolls and a weapon modifier to get the damage.

I don't think that fixed HP makes major wounds any faster to adjucate. Are people really that bad at math that diving HP by two actually slows gameplay down? If someone doesn't like the Major Wound table, they could always use the Pendragon method. In Pendragon a major wound incapacitates a character unless he makes valor and hit point rolls to stay up. Later on, if he survives, the character rolls on the aging table. Using CON+SIZ to generate a modifier to soak wounds is interesting, but I think it might work better without any hit points. Instead of tracking HPs, the damage rolls could just determine the severity of wounds.

Esepcially since the SR table for weapons gives lengths. What I could see is giving each character a reach rating (1m for a typical human) and add it to the weapon's reach. If an attacker moves into the reach, the character can interrupt the SR order to make an attack then. Somebody who wants to get in close is either going to have to defend against the reach attack, attack the weapon (to knock it out of line), or wait until after the guy with the longer weapon has attacked, say by bringing in a buddy to draw an attack.

I have to agree with Nick, when I've worn armor it didn't slow me down directly, I just tired out faster, when eventually slowed me down. What the armor DID mess with was my center of balance. I had to be careful when I leaned over or to one side, since the mail shirt I was wearing made me top heavy. While I never topped over, I did have to steady myself a couple of times, and would have been an easier target. I suspect it was more due to the fact that all the weight was on my back that due to the amount of weight.

I was thinking that SR could be broken down into Speed and Reach. Could determine WHEN a character acts during the round, but reach could work much like in D20, determining what targets are viable.