Who does all these ships?
I do, just me. On the rare occasions someone else has contributed to the design, that is always stated on the ships page.
What software do you use to make these plans?
The bulk of the work is done in nothing more exciting than MSPaint. This gives all the lines and details of both interior and exterior. I then, usually, use Corel PhotoHouse 2 to provide shading.
Why don't you have plans for any of the really BIG ships, like Star Destroyers?
Essentially the clue is in the question. Really big ships take a long time, and the bigger they are, the greater the amount of time is needed. As a ship gets bigger, more and more things need to interact with each other - the turbolifts all need to line up, for example, and various ships resources need to be mapped whilst balancing them with other, related resources. Once you get beyond a certain size, these become so problematical that the plan requires a disproportionate amount of time for the utility of the plan itself.
Additionally, on REALLY big ships, the value of a plan from an RPG point of view ceases to exist. Any time that a GM needs to have a shoot-out, or other game fucntion that needs a plan, they can just whip one up with a biro on paper - somewhere on these ships that configuration could easily exist.
How can I get a Chrome ship of my own?
You can get in touch with me via the contacts section to request a custom ship, but before you do I heartily recommend reading the Requests Guidelines so you are aware of the limitations, for example, that I won't touch green scaled ships over 150 meters, or blue above 50 meters.
Why don't you do side and front elevations as well as the plan one?
I am a D6 gamer, and the plans evolved out of D6's policy of generally showing only the plan and deckplan. The ships are intended only as an aid, not a technical manual, and for this they work just fine. One of the troubles with doing side elevations is that they take a LOT more time to do than just another picture, as you have to match up every feature so they match. For most ships a side elevation wouldn't give you any useful gaming information - most ships follow the Falcon style of being essentially flat. So, for most ships, the considerable added time required to generate side views, plus the limited utility of those side views means that the time spent doing them could be much better employed doing a new ship.
I think you should work like SWDA, why don't you?
Chrome and both the SWDA twins have the same ultimate goal - escapist fantasy. However, Chrome exists to support the escapist fantasy of role-playing where your escape is in playing a character having adventures in the galaxy, swinging sabres and punching wookiees, negotiating with Trade Federation buffoons and saving the princess, where the starships are very much background filler. The SWDA twins are different, they escape INTO the ships. Their escapism is a kind of technophilia - they get their thrills out of making their projects as 'real' as possible for their own sakes. The more detail they go into the more 'alive' the ship is, and ultimately, THATs why they do what they do. There's nothing wrong in that, as someone once said, whatever floats your boat. Chrome, however, exists to provide ships for my kind of gamers, and for them, the huge amount of detail in SWDA plans are at best pretty fluff, and at worst distractions. Not to mention that having a large number of ships to opt for is better, on the whole, than a very small number of mainly unfinished ships, for an actual gamer.
To put it in soundbyte form, Chrome ships support a fantasy. SWDA ships are the fantasy.
Why do you use these wierd scales?
My first deck plans were done in the early nineties with pen and ink. I had no plans at that stage to ever see them on a computer screen as the thought I could one day afford a PCof my own was very distant indeed. The first capital scale ship I produced (the Marauder Corvette) was quite simply a given size (975 pixels) when I scanned it, and it didn't occur to me to change its scale at all. This became a default, since I wanted every subsequent capital deck plan to be to scale with each other. The same was true of the starfighter scale, though I can't for the life of me remember what the first ship was.
How come your ships all have conventional items, like toilets and toasters?
I use what I call semi-iconic illustration techniques for all my plans. What this means in simple terms is that I use a set of standard 'icons' for various pieces of equipment and furniture, but these icons are not intended to be exact representations of what is actually there. I use these instantly recognisable depictions so that the function of this compartment is understandable without having to bother with a key.
There are two good examples I'd like to expound further.
Pretty much all of my plans have a section or two labelled 'Hygiene' and a depiction of a normal twentieth century toilet, sink and shower cubicle. I don't suggest that the ships actually have the classic ceramics. I know what they actually have in my game, but I couldn't speak for others or in any way what the 'true' nature of these essentials are in the Star Wars Universe.
In my game ships are usually equipped with a single machine, the autochef, which covers just about every aspect of food and (non-alcoholic) drink production. The process is fairly simple; the 'chef takes an order via keypad or voice command and assembles the necessary goop from stores. It then processes these basic food products to simulate (occasionally accurately) the order. The 'chef can use texturisers, colourants and flavourings to make many kinds of foods. It has trouble with things like bone, but as a basic food supply whilst on ship it functions well. (Unless you let a squib 'fix' it.) That's what it does in my universe. However, as with the hygiene units it basically just shows 'here is where food is prepared'. Substitute the 'chef for whatever you feel is appropriate in your game.
How can I tell how high the ceilings are?
I use a few constants in my plans which deserve a little explanation.
The thickness of the walls is almost always 30cms. This is because The Empire Strikes Back provided a highly unusual piece of hard data concerning the thickness of the walls of the Falcon, by virtue of the Falcon's ring corridor has been physically cut into at one point, and the exposed slice through it is visible is a few shots. I have adopted this as a standard except where irreconcilable factors dictate a thinner wall, or the curvature of the hull dictate a thicker one.
The deck / deckheads of ships is
set at 50cms with the habitable head height being a standard 250cms. This
is an international standard adopted by virtually every vehicle manufacturer
who intends for their product to be used globally. NASA, Boeing and Vosper
all use it for example, as do many architectural firms. The 50cm floor represents
space for structural support, support for whatever may be expected to stand
on it, and the wide variety of plumbing, ducting, electrical and miscellaneous
equipment that needs to traverse the entire ship.
This defines a 300cm section to provide habitable environs on a ship.
After creating the spruced plan
elevation of a ship, the next thing I do is to determine what areas of that
ship are likely to be able to include the 300cm sections. Often this is fairly
obvious, many couriers exceed this measurement by some way, though not enough
to justify two decks. When it isn't all that obvious, I can do a few things
to determine the habitable zone. Firstly, I can simply do a side elevation,
and if necessary a front or rear elevation. I say simply, often these take
far more time and effort than the deckplan itself. Secondly in situations
where even this could prove to be ambiguous, I build the ship in LightWave
8, which then allows me to slice and dice a three dimensional model into its
300cm deck zones. This also allows me to render the slices directly, giving
very precise footprints for the plan.
In several cases there are places
on maps where the head height is greater or lesser than the 300cm. Most of
the time this would include things like the autochef being situated in a sloping
section of the hull, so towards the rear of the unit, head height is definitely
not attained. In every case where this would represent any kind of serious
impediment to movement, it is so noted on the plans.
I work on the assumption that
most people on a ship will be quite able to navigate around minor obstructions
with no difficulty, and so momentary drops in height are not recorded. This
is consistent with the deckplan standards on modern vehicles.
One final point on this issue is I will not be bothering to make notations of any changes in this 300cm standard. What I mean by this is if a person looks at a ship which is created for, for example, the Ssi'ruuk then I assume that the person will make the logical leap that the deckheads will be a lot higher on their own. I don't feel the need to mollycoddle to that extent.
I'm not sure what this label refers to...
Labelling norms have given me some headaches however I have developed a system which works over the years. I try quite hard to avoid putting labels inside the ship itself, instead using small wedge arrows attached to the labels to identify items. Basically each arrow points at more or less the centre of the feature it represents. Each wedge arrow is placed as close to the edge of the 'live' deck as possible. Sometimes there isn't enough space to give each arrow a very clear line to the item, in which case the wedge is usually set back a little from the edge. In the example below I've drawn in the spotting lines, to demonstrate this.
The 'Ventral Hatch' label is very close to the 'Command Cabin' label, and due to space restrictions it has to point 'through' the Command Cabin itself, therefore the 'Ventral Hatch' label is aligned with the very middle of the round feature, and is also set slightly further back from the black and grey wall. Both of these signs serve to indicate that the 'Ventral Hatch' wedge is indicating the round feature rather than the cabin.
The text of a label is placed as close as possible to the arrow which 'owns' it. This can occasionally force the arrow even further away from the edge of the 'live' deck in order to accommodate two or more text labels with sufficient room that their ownership is clear. In the example below I've again drawn the spotting lines to demonstrate this.
This shows a situation where the location of the 'Triple Bunks' label has been located in the normal fashion. The placement of this label has, however, occupied the space needed to place the 'Primary Systems Board' label in its correct place since if the 'Primary Systems Board' were flush with the 'live' deck the two labels would overlap. To over come this the 'Primary Systems Board' has been brought further out allowing it to sit over the other label. Note that the 'Triple Bunks' label could not have been moved up since it would have then had to point through the 'Primary Systems Board' label.
How come you don't have stats listed with your stuff?
I am a D6 gamer, short and simple. The D6 system is a near-perfect RPG system. Why?
D6 has one core rule, just one, with many iterations.
D6's probability curve is almost perfect, it's a much tighter curve than D20's system, the D10 system, the GURPS system and indeed any other game system I am aware of.
These two factors alone ought to be enough to sway any serious gamer away from D20, they mean you can simulate any event without consulting a book and when you do you can simulate the results with precision. Speed, accuracy, simplicity. So, if there WERE any stats, they'd be D6.
The site exists primarily as a medium to make my work available to other SWRPG gamers. Without stats and caps these ships exist in a 'free' form, any RPG player or GM can use them with whatever system they choose, with any stats they feel appropriate, they're not biased towards using mine.
Within the D6 system I use a proprietry notation system that emphasises compact stats, essentially a long string of numbers. Unscrambling them isn't something I wish to force on anyone, and I've no direct motivation to translate them, especially to do it twice, for each system.
So, in the end, I made the Stuffyards RPG free, it's just easier that way.