clarence

I have read "Constructs in BRP" now and I enjoyed it very much, it's very clear and concise. The major malfunction table above fits in perfectly. Any additions would perhaps be some pointers on how to implement other typical Powers from BGB?

While reading, I realized these rules would be a very fine addition to BRP Starships. Are you interested in contributing? I have material from Atgxtg and Jason Durall so far. Final work on version 2.0 is underway, and I would really like to include your rules.

Oh, I like this! And as a consequence, I discovered your "Constructs in BRP" - it looks very interesting. I haven't had the time to read it yet though. Any more bits and pieces here on the forum you have added to the rules that's not in the document?

LOL, there is a couple of them, and they work quite well I believe. I just don't need it enough to justify the cost for both emulator and a Windows license. I have used pc:s most of my life, switching to Mac a couple of years ago. Unfortunately my old spare pc crashed a few months ago...

Excellent work! I just wish someone could persuade NBOS to make either a Mac version, or at least one for iPad… It seems they are very pc centric with all their programs, which seems a bit odd to me in this day and age.

I agree with many of the other posters, that this would be nice to see finished! I hope you find some way to finish it, and that publishing works out.

You're welcome! It's been a pleasure putting it together. I'm happy you like it and I hope you will find some use for it.

Run it maybe. Probably not maintain it though.

Yes, only for a short period of time.

In fact I could see Tech Levle adding into the rating of some systems.

Added: Either takes up more space or is less efficient with low tech levels, and the opposite for high tech levels.

The chapter for Advanced Combat is taking shape, and I've copied/pasted quite freely from our discussion here. Two spreads at the moment. No hit locations so far - I think NathanIW might be at work with that.

Looking forward to this!

Yes, that looks about right! And a civilian crew could be somewhere between 4 (standard) and 1 (crammed).

What is also quite interesting, is the minimum number of people needed to run a ship. I would say that one person is enough to run a ship (including one weapon) up to about 100 modules in heroic sci-fi. After that maybe 10% of the crew is the minimum.

You might want to add an automation feature that drops the crew requirements down a step or two on the ladder per module.

That's a good idea, and can also be used to simulate high-tech cultures.

Cutting Edge 1.2 speed per 1%

"Standard" 0.7 speed per 1%

Economy 0.4 speed per 1%

Perfect!

One thing you might want to add is some sort of guideline for crew. As it currently standard, there is no reason a Dreadnought can't be crewed by two people. Perhaps some function of the number of modules?

Oh yes, naturally. I will try to come up with something (unless you have a suggestion?).

1 SPEED = 1% of total modules

Great, this will be added to the rules!

I have also started to make room for the combat rules additions in a separate chapter called Advenced Combat. So far, the sub-headings are Weapon Options, Damage, Armor, Fire Arcs, Ammo, Hit Locations. Does that cover most of it? Anything else needed? I have a spread free for it so far, but if needed, adding more spreads is easy.

The Size Rating Table is now residing right after the description of Modules, including the way to use them with all ship sizes, and how to utilize them to ease the design of large ships.

The example sizes of military ships is also included now.

If you want to take that approach then I suggest a table with Speed and handling as a percentage of the total modules. It will make it much easier. I think it works out as 1 SPEED = 1% of modules, but I'd have to check.

Yes, I've thought about that too. Just as a quick and dirty way of knowing approximate values, and then you can adjust from that point without too much fuss.

Because form follows function. If you know what the ship is supposed to do, then you should have an idea of what it needs to do it, and how big it should be. In the real world most engineers start by making some basic assumptions about a vehicle, such as mass and desired speed, and then fill in the gaps. Then they usally adjust the mass and other starting assumptions as they modify the design.

For instance, with real world fighter jets, engineers can assume that about 15-50% of the plane weight will be taken up by the engines, and another 35-40% taken up by frame and structural support (so it can take the stresses associated with hight speed and high G turns). So 50-90%, or, on average about 2/3rds of the fighter's total weight is already spoken for before the designers get to the drawing board.

Experience with the design process is the key here I think. And many players will only design one ship, or at least design ships very irregularly.

Sounds okay, except I think it would be better if we have one system for design, not one for small ships and one for large ships. Maybe we can trim off the stuff from the rating system that is most helpful and important, such as a total size, and size class.

Well, it's almost one system. The only difference is that it is meaningful to use a size rating for a part of a ship when doing big ships. All else could be equal I think?

One other little perk that I didn't mention is that since the BRP SIZ table also uses a doubling progression in the SIZ8-88 range, it is easy to convert from a rating to a SIZ or STR stat.

Sounds good. What does the conversion look like?

Oh, and BTW, congrats, that's actually one of the problems that go with rocket science in the real world.

I'm happy I'm not a rocket scientist : )

The "solution" to that problem is to pick the size of the ship first then fill in the spaces with components. That way the final size (and mass) never changes, so you don't have to constantly recalculate every time you add another module.

Ah, that was one of the things I wanted to stay away from when I started this. Too many ship design rules begin with the question of hull size - but I always wonder how I can know that. It seems more intuitive to just keep adding functions you need and see what hull size you end up with. I realized though that engines will take up approximately 10-20% (Speed 10 and upwards) of the number of modules, so that's probably simple enough for me.

I have designed a bunch of ships now with the different versions of scaling we've discussed here, and these are my findings:

1. It seems to me that a rating with a doubling progression is quite efficient for large ships. Perhaps a bit inaccurate, but I think it works as the design process is so much faster and simpler than counting thousands of modules.

2. For small ships (less than 200 modules approximately) the same rating seems to confuse the design process more than it helps, as the rating for individual systems have no actual use. For a whole ship though, the rating works excellently as a sort of Size Class.

3. I suggest we keep the design system as it is written in the rules now (with the addition of a Size Class stat), and add a sub-heading for designing large ships. Here the doubling progression is presented for individual ship-systems and how that benefits the design process for capital ships.

4. And slightly OT: Working out Speed and Handling is a bit complicated now, as each time you add a new engine module (to up the Thrust Rating), the total number of modules goes up, shoving the calculations for the final Speed/Handling value into constant flux. That makes it a bit unpredictable for players and GMs alike. Would it be ridiculous to just ignore the Engine/Maneuver modules in the calculations and use only the other modules' total for these calculations? (But include them in the total module count that determines Size).

How do you think all of this sounds?

Just one table. All that would change between systems is what you are measuring. For instance, a rating 5 cargo area would be 16 tons, a rating 5 crew area would be 32 people, a rating 5 lab would mean 32 labs, and so on.

Could you expand the explanation a bit? I designed a few ships with this system, but I'm not sure I got it right. I pick a rating and see how many modules I get? Why does rating 5 equal 16 tons, but 32 people - I thought they would be 16 both of them? It's a quite elegant system, but resolution is a bit low perhaps when doing bigger ships. And for hangar bays the rating-to-module relation will have to be modified, right?

One of the neat bits is that while you can determine exactly how many modules a ship takes up with this variant- you don't have to. With a doubling scale you can get a "close enough" estimate just by taking the highest rating and adding 1 or 2.

I don't understand : )

For instance if 1 module is 1 ton, 2 would be 2 tons, but 3 would be 4 tons, 4 would be 8, 5 would be 16 and so on. We could do the same with crew, weapon size and so on.

It looks very neat, but it seems to me you have to look up all those relations in tables (or just one table?). Might not be such a big difference from how it works now, but it seems a bit more direct with 1 module equals 1 person (weapon, ton and so on), and 1 capital module equals 10 people.

Okay, I'm going to write the full length text stuff for my own use and I'll make a short summary version for other people to use as they like.

Sorry Nathan, I didn't mean to cut you short. Write it the way you think will work, and if needed we can discuss the length then.

I've been doing some reading on civilians aeroplanes and ships. Categories currently in use are based on what the ship's purpose is and then there are a variety of systems to rate their sizes (mostly born out of tariff and taxation demands). For the military vessels, I liked Atgxtg's list because it starts with the smallest reasonable manned military craft and then doubles for each category. I think that works great and should also be applied to civilian craft.

I'm going to come up with some examples for different size classes and just include them in the description.

Excellent!

You mean it's linear!

I never really considered it so. I consider a Battleship to be far more than a 128 times the size or mass of a fighter, even if it has 128 times the number of modules.

Well, I thought so : ) but I'm ready to change my mind. You mean modules actually grow bigger, the bigger ship you are building? What is the explanation for that? (It's wonderful how some things gets more complicated the more you think about them. Modules and scale are easy enough concepts that we seem to know when we write about them, but in fact we have quite different views of them...).

Would we be better off with a separate list for civilian ships or simply putting civilian examples in the description? For example, under titan, mentioning that the largest colony ships and habitat structures could be that size.

Please include them if you have some picture of it. I will probably have a list of civilian ships too, but a comparison is always good to have.

If you want to keep the x10, then maybe change medium from 1 per 4 to 1 per 5.

Yes, I also thought about that. It will make the system a little neater.

But if we allowed scale to be adjustable, 1 module would provide SCALE tons of cargo.

You could build all the ships on roughly the same number of modules, but bigger ships would just have bigger modules.

I finally got what you were trying to say - the example did it for me. This is a very compelling idea. Just let me take a swing at it at the drawing board, and I will get back.

I've been experimenting a bit with the different scales, and I feel that a Capital Ship scale of x4 might be a bit small. For Starship scale (formerly medium scale), designs up to about 200 modules are quite manageable. Above that, the smallest Capital ships should reside, and that landed me at yet another x10 up from Starship scale. That means, for example, 1 module for ten people, or 3 people for longer trips (actually 2.5, but with the earlier discussions on hot bunks etcetera, rounding up seemed like a good idea). By introducing half modules, some of the less desirable effects can be dealt with, as Bridges being too big for example. Rounding the total number of modules up I think is the way to go here too. What do you think about this? Does it wreck some of the other ideas we have played with here?

I also find that the modules always refers back to the basic Starship-scaled module. A 20 module long ship in Capital scale is 10 times (or 4 times if we go with that multiplier) longer than a 20 module ship in Starship scale. 1 Starship module = 10 Capital modules. Maybe I'm a bit too drawing-centered, but area seems to be a very natural way of working with this (except that dividing a module sketch into four pieces is much easier than dividing it into ten pieces...).

So I started writing the text of my optional appendix entry.

It looks like a good start! This could easily be fit in as another chapter in the text, if you want to. I just want to point out that with the current layout, texts need to be kept quite short.

titan [1280] (640-1920)

battleship [640] (320-960)

cruiser [320] (160-480)

destroyer [160] (80-240)

frigate [80] (40-120)

corvette [40] (20-60)

cutter [20] (10-30)

small craft [10] [8-15]

fighter [5] (3-8)

For military starships I think this looks very good. A short description for each of the ship types would be good though.

In what way? In terms of dropping the messed up progression and going with the doublnig progression. Yes. . Even the BGB deviates from it. If you look at the SIZ of battleships and carriers in the BGB you will see that they are only a small fraction of what they should be based on displacement. So I'd rather fix the SIZ scale once and for all, and come up with values that are playable.

But doesn't this mess up the direct module-to-size relationship we've had so far? Could it be linear up to size 1000, and then logarithmic (to deal with really big objects, not often coming into play)?

Look at it this way -- the modern supercarrier USS Gerald Ford will have a crew of 4,660 when it enters active service in 2016. A large part of them are occupied with the continual maintenance the ship and its systems will require, from cleaning and painting to inspection and repairs. Another large part of it will attend to the 75+ naval aircraft kept on board. These sailors will be supported by innumerable other functions, from cooks and kitchen help to keep them all fed and medical staff to keep them healthy to barbers, laundry people, and other such. By contrast, a destroyer has a much more spartan crew compliment -- typically 300, many of whom pull multiple functions.

Yes, good observation! It's actually a complete, small community (or village) on those ships. For some reason this makes me think about Eddie Izzard's "Death Star Canteen" (

Try designing a capital scale ship using the large scale modules.

Designing and drawing modules on paper… always easier to think with a pen in my hand.

But the SIZ table, was built on a logarithmic doubling progression.

Do you think it is wise to deviate from the BGB definition of size? If it's really needed (perhaps for Puppeteer-like aliens, moving planets around before breakfast), it might be better to introduce more scales perhaps.

Ok, I think it will work quite well with a chapter named Advanced Combat to collect most of the optional rules. Some adjustments will of course end up in the other chapters as well, but the overall simplicity will remain, hopefully with a bit more consistency. If the advanced chapter is at the end of the text or following right after the existing combat chapter, I think is perhaps less important.

Correct and fine-tune to make it smooth and consistent.

Yes, I hope those fine adjustments will come when the rules are used in play. I think the worst unbalancing has been ironed out by my playtesting, but more people using it will make it better I'm sure.

But... if we doubled the height and width to 2m each, we could keep the length at 1m, and the 100m long captial ship would take up 100 capital scale modules instead of starship scale. Get it?

I will have to think this through a bit.

But...I've been toying around will keeping the doubling progression for SIZ for all mass scores. If we did that, the Earth would "only" be SIZ 541, and have 541 hit points. At Emcha scale that is only 54 points. Which is only around 10d10 on the weapon table. That we can do. Heck, we can sometimes do it with the examples I wrote up. To get to 10d10 I'd just need to make the weapon bigger.

541 size/hit points for a planet sounds very little! What size is Cthulhu and his distant cosmic relatives? And Death Star's cannon - couldn't it be a special case, a weapon working on an entirely different principle, and thus inflicting outrageous amounts of damage? Seems a bit like cheating, but blowing up planets with a big gun is quite fictive too...

I was thinking that if you had some sort of rec room/common area you could probably just get by with bunks. What I'm worried about is that captial ships in SciFi tend to have crews in the hundred or thousands, and at 1 modules per crewman (capital scale) we'd run out of room for engines, weapons, and all that junk.

A 300m long Constitution-class cruiser (Star Trek) with a crew of 430, for instance. But if we could use bunk beds and put 8 or 16 crew into a capital scale modules, we could cram the crew into 30-60 modules and leave 240 free for the rest of the ship.

Well, I think that as long as we consider the crew some kind of military personnel, (hot) bunks with 8 crew per Capital Ship module would be fine. (I have always wondered though what all those people are doing all day on sci-fi battleships…) Is 240 modules enough for the other stuff?

Or, if you wanted to,you could assume that Capital ships were twice as wide and twice as tall as small ships, and that would give you 1 capital ship scale module per meter. Which might be nice for design purposes.

Not sure I follow you here...

I was thinking more along the lines of the Wave Motion Gun from Space Battleship Yamato, or the super-dimension-energy cannon from Macross.

I'm still not following you. In the films the Death Star fires and then has to recharge. If you mean the second Death Star, you could probably mimic that with a big engine core (for damage power ups) and a relatively small weapon to get a faster fire rate. Or I could put in a rapid charge option, so you could recharge the weapon faster.

But since Death stars are hundred of kilometers long, they would have enough spaces available to build a really nasty main gun. The smallest ratings given for a Death Star is 120 kilometers, so assuming half the modules for being a sphere, we still would have 60,000 modules! (20,000 Capital Scale!). Assuming 4096 capital scale modules to make of the main gun, we'd get a superlaser that did 5d10 damage, before the spinal weapon bonus.

If we assume 4096 capital scale modules for engines () we'd end up with off the ladder (i'll have to expand it!) to something like 9d8 damage, or if you really want to be mean, 5d10+14.

Hmm, if we go with the big, 900km long Death Star II, that would be 450000 modules/112500 capital scale, and probably a 32768 capital modules for the superlaser!

Love the number crunching you've done here! : ) For continuous fire rules, I would say we drop it. It was a very vague idea to start with, and I don't see it working very well. What I can't stop thinking about though, is how many hit points a medium sized, earth-like planet has. : ) Death Star's spinal weapon would have to beat that, right? It is too much to ask of the rules to simulate everything from a small shuttle up to Death Star though.

The biggest problems are the +1s and there is a way to explain that in BRP Mecha, too.

We could do away with the +1s, if it makes the system neater/easier. I'm ok with that.

Yeah, there is a way to do it without using miniatures. You do up a little list of maneuvers, and they determine the relative facings. For example:

Close: The ship flies directly towards a chosen target. It can fire forward facing weapons at the target.

Open: The ship files away from it's chosen target. It can fire aft facing weapons at the target.

Circle: The Ship flies in an arc or complete circle around the chosen target. It can fire weapons on one side (port of starboard) at the target.

...and so on. I can do up something if you want.

I think we can wait and see if it is needed perhaps, and go with miniatures for arcs. Or what do you think - is it better to give both options? Or will too many options make the rules confusing?

Do you allow "hotbunking"?

Oh yes, in Capital Ship scale I would say it's ok. In other cases it might get too crowded (?). And 300 modules seems like a good size!

I was looking over the Size table, ad I noticed that there is roughly a 1:1 correlation between length and number of modules. Is that intentional?

Yes, but only as a rough guide.

What do you mean by continuous fire. Something like a a cutting beam that lasts the round, or something that lasts multiple rounds?

I'm not sure how useful it would be, but I was thinking multiple rounds. Death Star was my vague point of reference - not sure if that was what you had in mind originally...

Because your original weapons had +1s.

Ideally, I'd like to tweak this so that you could build any of the sample weapons from the ground up and get the same cost. I didn't quite manage it, but I haven't given up on the idea yet. That way somebody would be able to build any weapon they wanted to, and not need to base it on one of the existing weapons.

I get it! This flexibility seems like a good idea. How do the original damages relate to BRP Mecha - you see no need to adjust them?

Uh, yeah, sorry. I forgot to include that. Basically I kept it simple and like most games with fire arcs, ships have four. Forward (in front), Aft (in back), Starboard (right side), Port (Left side). That should cover it.

I don't know if you want to use hex maps, a square grid or just some sort of 90 degree wedges. I just went with the bare minimum I thought was necessary to handle fire arcs.

Four fire arcs seems logical, and keeping the system simple is very good. Is it possible to use the fire arc rules without some kind of miniatures?

This looks very, very good! It makes a great addition to the rules, and adding them in as options is perfect. The combat rules will feel much more well-rounded now. Looking forward to seeing more!

Some questions:

Why +1 for Blaster and Ion gun? Isn't it better to stick to the damage ladder, now that we have one?

The Spinal Weapon is great! I have some problems with the free upgrades though. Maybe only range and damage upgrades are applicable with giant cannons like these? Fire arc, Autofire and Point defense at least seems a bit off. Instead perhaps something like "Continuous fire"?

Are you planning for more info on fire arcs? I can make the final graphics, if any are needed. Are blank hex maps needed too?

@Hexelis: Thanks for the comment - it seems Atgxtg got you covered on that. : )

1. LOL, I just wasn't familiar with the exact wording. This was one of the things I wanted to stay away from - but as an optional rule I guess it's fine. Doesn't it get overly complicated and you need to involve hex papers and miniatures - and then you realize you actually need a 3d representation…?

3. I knew this one too It would be a great addition.

4. Excellent.

5. Ok, your idea sounds good: Some "free" shots, and then an ammo module must be bought if you want more. What is the easiest way to keep track of ammo during play if there are lots of them? Would an abstract concept work, like "1 Ammo Module lasts one major battle or four minor"?

1. I'm not sure what a fire arc is...

2. No problem. Costs aren't very fine tuned as it is now, so go ahead.

3. Forgive my ignorance - could you describe autofire? (My interest in weapons is really low…)

4. Yes, that makes sense to add. Perhaps as an optional rule?

5. Tricky question. For believability, yes. For playability, no. As the rules stand now, they are not tracking energy expenditure in any way, and it seems a bit illogical to track ammo. What do you think?

For Capital Ship weapons, I think the two options you mention are fine.