Tetsujin no Llama

My brief ramblings on "Ashiwi Country" in Pyramid #74 aren't even a little game-useful, but: It's oddly appropriate for me that this article shows up in the around-Christmas issue. After getting married and earning his PhD, my father was in the Air Force for a while, a consequence of going to school on Uncle Sam's bill via ROTC. He was stationed at Kirtland AFB (next door to a Navy base, apparently, which has always seemed a bit odd to me) near Albuquerque and absolutely loved the place. My parents moved away shortly before I was born, but my father retained a certain amount of New Mexican bric-a-brac, which was most visible in the form of Christmas ornaments. As a result, I've always associated Christmas, to some extent, with the desert Southwest. I didn't get to see the Southwest until many years later, when I was part of a summer of archaeological work on the Zuni reservation. I gotta say, the people are lovely and the scenery is pretty spectacul

This is too brief to be "designer's notes" on my article in Pyramid #72 , but it's something I wanted to mention. I note at the beginning of the article that "almost from the beginning of fantasy roleplaying games, there’s been a desire to" play dungeon crawls as monsters rather than human-ish adventurers. What I had in mind here was the 1976 game Monsters! Monsters! , developed in part by a guy at Metagaming named--wey hey!--Steve Jackson. So this is kinda going full circle.

To expand a bit on my comments here on how it's difficult to write new rules for GURPS: It's not hard to add entirely novel rules to GURPS. The problem, in my own writing and gaming, is finding a need to add entirely novel rules. Mechanically, it's not necessarily hard to write new rules. GURPS is heavy on "find the appropriate trait, modify for circumstances, and roll that number or lower on 3d6." And there's always room for special cases. For example, Tactical Shooting and Technical Grappling add a wealth of gritty detail to shooting things and grabbing people, if you're into that kind of thing, and even with the basic magic system, basic psi, a magic-as-advantages approach, RPM, and variants to be found in Thaumatology , there's always room for new approaches to extra-normal abilities. No, what I'm talking about is finding topics on which new, general rules can be written where none existed before, or broadly applicable rules for notab

My sometime coauthor, the lovely and talented Peter Dell'Orto , has recently dropped some hints about his in-progress GURPS book. That is, from a certain point of view, nice of him, and I thought I might do the same. On the other hand, I don't want to get ahead of The GURPS Machine in providing information about upcoming books, so I thought I'd tell some extravagant lies and possibly insert something which might be true. So: A hardcover edition seems unlikely, but we're talking about a 3d printed version. The most recent GURPS news has indicated that there are books in progress for the Powers, Dungeon Fantasy, and Transhuman Space series. Mine is, in fact, for all three: GURPS Dungeon Fantasy: Transhuman Space Powers . It covers a range of implants, bioshells, and other content from the Transhuman Space series in DF format. It's got the correct modifier for "shooting a man in Reno, just to watch him die." Working titles for my book include GURPS Ult

Clever readers will have realized that everything I've posted up to this point doesn't actually do anything. There's a bundle of classes and data representing everything from a pile of treasure down to details of decor, but what to do with it? Ultimately, all one needs to randomly generate a hoard is something like the code below, which generates a hoard of random items worth $2,000. For a bigger or smaller hoard, just change the value of hoard_val. package hoardomatic; public class goMonkeygo {     public static void main(String[] args) {         Double hoard_val = 2000.0;         Hoard avarice = new Hoard(hoard_val);         System.out.println(avarice.hoardReport() );     } }

And finally, data. Without the XML files, this is all, in the words of Han Solo, a really short trip. These (redundant, poorly structured) batches of XML are representative of the nature and structure of data required. Here's what they contain. BulkGoods.xml: Detailed breakdowns of additional properties of bulk goods, notably the unit of measurement and containment type. These include W for wet goods like wines and pickles which must be stored in waterproof containers, D for dry goods like spices which can go in boxes and bags, and N for things like hides and raw fibers which are measured by bulk quantities but don't require containment. Containers.xml: Detailed breakdowns of additional properties of containers, notably containment type and storage capacity. Curses.xml: Curses are like lightweight enchantments or embellishments, with a name and a CF, which Items use to modify the cost of enchantments. Embellishments.xml: Properties of mundane embellishments, including nam

Last class. Gems have their own bundle of properties, so they get their own class. Gem String gem_name: Name of the gem. Double val_constant: The value constant for the stone, the V in the(C^2 + C*4) * V value formula. Double carats: Weight of the gem in carats. This one is similar to the previous two, but it takes on itself the task of randomly selecting a node from Gems.xml to turn into an object.    package hoardomatic; import java.io.File; import java.io.FileInputStream; import java.io.InputStream; import java.util.Random; import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import org.w3c.dom.Document; import org.w3c.dom.Element; import org.w3c.dom.Node; import org.w3c.dom.NodeList; public class Gem {     private String gem_name;     private Double val_constant;     private Double carats;         public Gem() {         // TODO Auto-generated constructor stub         Node gemnode = getRandomNodeFromTable("Gems.xml");       

Enchantments are structurally very similar to Embellishments. The big difference is how costs are accounted for by the Item containing them. Enchantment String Enchantment_name: The name of the enchantment, usually just the name of a spell, though it may include a degree (Accuracy 3) or notation about which version of an enchantment the item has (Bravery (Cast only)). Double cf: The embellishment's CF value. Not actually used, but it's there because I started enchantments by copying the embellishment class. Double flat_cost: The base cost of the enchantment. Double wt_mod: Weight adjustment, if any, which spells generally don't have. String motif_option: Not used. String ench_code: A code similar to the embellishment codes, indicating what kind of item the enchantment can be on. Most are generally applicable, but a few are limited to weapons or armor. This class works very much like the Embellishments class: it takes a node provided to it and populates the encha

This represents an individual decorative or functional embellishment on an item. Embellishment String embellishment_name: Name of the embellishment (for example, "Fine material" or "Tassels"). Double cf: The embellishment's CF value. Double wt_mod: Weight adjustment, if any. This defaults to 1 and is expressed as a decimal multiplier to the base item's weight. For example, 0.9 for an embellishment which reduces the weight of the item by 10%. String motif_option: Some options don't lead to item having a particular decorative motif (for example, improved materials). Some do (for example, relief carving). Some could go either way (for example, painting; an item could simply be painted, say, entirely green, or have figures painted on it in green). This defaults to "N". String emb_code: A single string corresponding to the range of attributes which items may have. The constructor I'm using takes a node (from Embelishments.xml) handed

Here's where most of the work happens. It also contains lots of untidy code which is a consequence of making it up as I go along: stub functions which are unimplemented, implemented but unused functions which don't do anything useful, and references to libraries that don't actually get used. No matter; the bits which do get used do what I need them to. Item String item_name: The name of the base item (broadsword, Dwarven theodolite, arrow, etc.) Double base_cost: The cost of the unembellished item, used as the basis for CF-related price calculations. Double base_weight: The unembellished weight of the item. Integer quantity: Usually 1, but ammunition and bulk goods often have a larger quantity String curse_name: Defaults to an empty string. An item may have no more than one curse. Double curse_cf: The CF of the curse, which applies to the cost of enchantments. String unit. The unit of measurement. Defaults to "each," but may be a unit of weight, length, etc. S