This is an implementation of Krapou's Star Wars D6 ship generation/pricing system. It is used to calculate the prices of ships in the (now out-of-print) WEG Star Wars books in an effort to produce more accurate prices than Grimace's D6 ship system (which is still excellent, but not intended specifically for Star Wars).
The script has been tested and verified to work on Mozilla Firefox 2.0.0.19 or Microsoft Internet Explorer 6.0.2900.2180 or newer (older versions of Firefox 2 and IE 6 can probably handle it just fine too). It is likely to be compatible with most modern W3C HTML DOM-compliant browsers, such as Opera.
No. The simple truth of the matter is that almost all of the ships in the D6 Star Wars roleplaying game were given statistics essentially pulled out of the air, and then given prices based on dead reckoning. Many ships will be priced too low, some too high. Though this system can guess the price of a ship, and in some cases can guess it very closely, because there was no real rule set in place when the ships were designed in the first place a guess is the best you'll get.
Then there's the fact that the ships in the game often factor in availability and mass production into their prices (instead of leaving this up to the gamemaster). Some ships will be priced higher or lower based on concepts that might not even hold true in your own campaign. Many ships were not even given prices at all, under the claim that if it's "Unavailable for sale" it has no price. In reality, everything has a price; just because you can't normally buy it doesn't mean that expense wasn't involved in its creation and that there's no demand for the product. Aside from prices being important to figure out just how much fiscal might a particular empire might be able to field against another empire, prices are relevant for the collector or salvager as well. Finally, as you begin increasing the offered price above the actual perceived value, the prospect of a sale—even for something with extreme sentimental value which is not being offered for sale—would increase.
Finally, some of the ships in the game break this system in a bad way. A look at the Starjacker from Tales of the Jedi Companion, pp.116–117, will go to show you. The ship is priced at only 20,000 credits. Under this system, inventing an 8-emplacement, 8,000 credit price for the plasma drill, it comes out to... 2,473,570 credits. It also throws red flags on manoeuvrability and hull strength, since both are way too high for a typical ship. The reason it's so manoeuvrable is because it needs to dodge asteroids and the reason it's so tough is because it needs to survive when it doesn't dodge asteroids. But for this system, its low power hyperdrive and relatively slow space movement speed aren't enough to redeem it. It takes a lot of fudging and a significant drop in its length and manoeuvrability in order to make it more reasonable.
That said, the prices this system generates are internally consistent. If you were to calculate the prices for every ship in the game, all of the ships would have prices that reflect their actual technology. A ship that is more expensive is usually better, although it is very easy to generate a ship that is overkill and thus way more expensive than it needs to be... the Starjacker being a prime example.
You can play around with this generator and it's probable you'll pick it up as you go along (assuming you already know how to play Star Wars D6!), but it can be faster to learn from the system itself. A copy of the system can be found on Krapou's Star Wars page under the "Play Aids" section (a backup copy is also available from this site).
Some limited help is present in the form of "tooltips". You can mouse over any field on the main chart, or any column header in the weapons tables, for a pop-up description of what that field will do. (Though Firefox 3 and Internet Explorer 6+ handle it fine, Firefox 2 has a bug where it won't reveal the full "tooltip" text. This can be corrected by using the Long Titles add-on or by upgrading to Firefox 3.)
This page can scale down to 800 pixels' width or so, but looks godawful. I would advise against trying to run this script as an app on a cellphone or anything (not to mention that it probably wouldn't work anyway). You need to have at least 1000 pixels of horizontal viewable area on your screen resolution for optimum viewing. You may also get some space savings by scaling down your browser's font size (Ctrl+MWheelUp) and resetting it after you're done (Ctrl+0 in Firefox, or Ctrl+MWheelDwn in IE)—as should be expected, this works much better in Firefox.
Though this is a pretty faithful implementation, there are some implementation notes you may want to be aware of:
Some ships in the various WEG Star Wars rulebooks are on Starfighter scale even in spite of their massive size (e.g., the Starjacker), or on Capital scale even in spite of their small size (e.g., the Blast Boat). A checkbox is included to allow you to invert the scale of your ship. If, for instance, it is reported to be a Capital ship even though it should be on the Starfighter scale, you just click the checkbox and hit Appraise, and your ship will be on the Starfighter scale thereafter. This doesn't modify the tables, however, so your ship will still have to conform to limits (e.g., minimum crew) based on its hull size.
No changes are made until you hit the Appraise button. This includes weapon selections and the like. For instance, if you choose 2× Laser Cannon, hit Appraise, and then click the "Lnk" (Fire Link) checkbox, the damage code won't increase until you hit Appraise again.
The system will deliberately ignore most errors and calculate a price anyway. However, strictly speaking, any occurrence of red text means your design is invalid.
The system computes all prices using ranges and floating point values, then rounds to the nearest CP, instead of doing a table lookup and choosing the next higher option that satisfies the desired requirement. For instance, it is entirely possible to design a ship with 32 crew, even though the Automation Cost table in the Starships Pricing system does not include a "32" row.
All of the tables are considered to continue indefinitely with the same ratios as the final row, in an effort not to restrict your freedom to experiment. Because the tables were designed with certain limits in mind, breaking these limits will produce technically illegal designs, even though the system will allow you to do it. Exceeding the limits by too much will produce designs that are clearly broken (e.g., 150 000-metre-long ships will be quite manoeuvrable in spite of their size).
There's no form validation in place. If you enter bad values, like being silly and entering a length of "bigger than a breadbox", don't be surprised that the calculations break down. This is pretty firmly in "don't do that" territory. Also note that it doesn't constrain the pips fields to values between 0 and 2, but you should do so to be legitimate.
You can't remove a line from the weapon, launcher, or equipment tables; once it's there, it's there. You can, however, set quantity to zero (or set your selected weapon to the blank entry) to disable that row. I know, it's somewhat disconcerting not to be able to delete rows from the weapons table. However, you wouldn't believe how difficult it would be to rig up a system that deletes a row. I would have to figure out which row you clicked the delete link on, find all of the cells in that row and wipe them, look through all of the arrays in the list and clear the references to non-existent HTML DOM elements from that row, find all of the delete links and re-adjust them so they know which row they're now on... and write this same code several times over for each of the different table types! It would also be very painful to implement a method that also works in Internet Explorer, as IE doesn't implement the method that would allow me to find the row on which a link was clicked...
Fire links weren't part of Krapou's base system. The way it works in this system is as follows: if two weapons are linked together, base damage increases by +1D. If four weapons are linked together, base damage increases by +2D. If eight weapons are linked together, base damage increases by +3D... and so on. Thus, the progression is at a rate equal to the logarithm base 2 of the number of weapons. Fractional numbers are converted into numbers of dice and pips, rounded to the nearest pip (e.g., three linked weapons is 1.58496, which is closest to 1 ⅔, which means +1D+2). To convert floating point to pips, compare in order: if the fraction is less than one sixth (0.1666), no pips. If the fraction is less than one half (0.5), one pip. If the fraction is less than five sixths (0.8333), two pips. Otherwise, round up to the next die.
This is a house rule contrary to the "Combined Actions" rule (see The Star Wars The Roleplaying Game Second Edition - Revised and Expanded p.82), which states that each combined item adds just +1 pip, but was designed to closer satisfy the typical designs (e.g., the X-Wing has four fire-linked laser cannons for 6D damage). I also created this rule because large-scale collaboration should be possible on extremely imposing tasks, but it should take exponentially larger numbers of people to receive additional benefit.
Fire links, at least under this system, are free, since there are advantages and drawbacks to linking weapons (linked weapons inflict a more concentrated blast that can pierce heavier shields and armour, but against weaker shields and armour you'd inflict more damage overall with weaker individual blasts). If any of the above bothers you, you can have better flexibility by defining a custom weapon instead, since the Quantity, Fire Control, and Turret, and Link fields do not automatically adjust the price like they do for the pre-defined weapons. Alternatively, you can simply ignore the Link checkbox, since it's not part of Krapou's system anyway.
Shields are assumed to be full-fledged deflectors, meaning that they include ray shields and particle shields and thus protect against energy weapons (lasers, blasters, etc.) as well as projectiles (explosions, torpedoes, micrometeors, etc.). Krapou's system does not handle the rare cases where the ship has only ray shields or particle shields. To handle this, I simply included a radio selection in the shield notes box. "D" stands for "deflector" (both), "R" stands for "ray" (energy only), and "P" stands for "particle" (physical only). If you choose any option other than "D", the cost of the shield emitter is halved.
Krapou's system still doesn't cover certain elements of WEG's The Star Wars Roleplaying Game. In addition to some of the house rules that I built into the generator, here are my thoughts on how you might work around the others that I felt would be too significant a modification to build into the generator specifically.
Nav computers are not handled by the system. You can assume a "reasonable" nav computer is included for free in starfighters which is capable of storing a number of jumps equal to the ship size. You could alternatively make up your own price system for nav computers and tack it on as additional equipment. Note that astromech droids can contain several nav coordinates, so building in cargo space for them—an R2 probably weighs around 60 kilograms (0.06 tonnes)—can allow you to dodge this limitation. My house rule is 250 credits per hyperjump to store, minus 250 credits per the ship size. A size 5 ship can store 5 jumps for free, and if it stores less it gets a cost break and if it stores more it gets a surcharge. Removing the nav computer entirely gives the same price break as the number of jumps removed (so a size 3 fighter with no nav computer gets a cost break of 750 credits). 1,000 credits times the shipsize gives you a nav computer with unlimited storage. A naviputer with unlimited storage for a smaller starfighter is cheaper than an R2 droid, which is about right: the droid is more versatile, even in spite of only storing ten jumps.
Fire arcs are not part of the system. Krapou's system does include turrets, which allow a weapon group to fire in any direction and increase the weapon group's cost by +50%, but there is no underlying rule for specifying in which direction a non-turreted weapon fires. The basic house rule I make is that whatever the limit of emplacements is for a ship of your size, up to one third of that limit can fire forward (so on a size-3 ship with a maximum of 100 emplacements, up to 33 emplacements' worth of weapons can fire forward). Since most fighters are significantly undergunned for economy reasons, this usually only becomes a factor with larger ships.
Gunnery crews are not handled under the system either: weapons do not identify how many crew they need for operation. My simple rule is this: all fire-linked starfighter-scale weapon groups have a crew of 1 for the entire group. All singular starfighter-scale weapons have a crew of 1 per weapon in each group. The starfighter pilot can serve as gunner for any or all starfighter weapons aboard, but must conform to the "Multiple Actions" rule (SWRPG:2E-R&E, p.78) to fire any weapon, so a dedicated gunner is usually preferable. Capital-scale weapons absolutely require gunnery crews and cannot be operated by the pilot; the gunnery crews required for the capital ship weapons are simply inferred from existing ship designs.
Skeleton crew requirements are not included. Essential crew is the number of crew required for normal operation. I assume that the skeleton crew is equal to the "Minimum" crew stated for a ship of that size (1 for ship size 4 or less, 10 for ship size 5, 250 for ship size 6, etc.), or alternatively make a value judgement like one-fifth of the essential crew if that doesn't make sense.
[Click here to go back to the generator.]
This ship generation system is copyright ©2009 Jeremy T. Gibson, and is distributed under a modified BSD-like licence. See licence.txt for details. It is based upon the works of Krapou and Grimace.