Gurps Vehicles

[RyanW]

Originally Posted by ciaran_skye

I think the new character-based system simply makes more sense.

Originally Posted by Stripe

I disagree with everything you just said.

You can feel the love, can't you. :)

I like a median approach. A robot design system that guides the user in creating a robot as a character. The Bio-Tech parahuman/bioroid design system is a good starting point, but robots are much more varied.

[Kage2020]

Chalk another one up for someone waiting patiently for a 4e Vehicles. Spaceships is all good and well, but I would prefer something a tad more crunchy. :D

Kage

[roguebfl]

Originally Posted by Jonas

At least give me the choice of using a program to do the grunt work or doing it by hand.

Other than the fun I have turning such things into programs myself. There is an advantage of my book format is you can 'see' the why you get the results toy get and were the assumptions are, and can tweek it to your own assumastion if you like. a Program hides all this.

[gilbone]

Originally Posted by ciaran_skye

I got the kitten and my mom's friend beat cancer post-Low Tech...

Win! I'm going to name mine Mr. Fluffysocks. Or maybe Reverend Pee.

[dataweaver]

Originally Posted by RyanW

I like a median approach. A robot design system that guides the user in creating a robot as a character. The Bio-Tech parahuman/bioroid design system is a good starting point, but robots are much more varied.

The alien creation rules from GURPS Space are probably varied enough.

[cmdicely]

Originally Posted by Darekun

Something that just occurred to me: Release a vehicle design system only as software, leaving the monkey work to a computer. Have the compatibility and such problems been worked out of the software?

You can't make house-rule modifications to software as easily as to a book.

I much prefer the rules in a book. I wouldn't mind having official software, too, but the book is vastly more important than the software.

The problem is that 3ed's vehicle stat blocks were taken over by a format that included data for reverse-engineering them with VE. Even the 4ed stat blocks include a lot of this stuff, like the list of subassemblies.

The list of subassemblies is part of 4e stat blocks because it is necessary to the 4e operational rules for vehicles (for one thing, subassemblies are hit locations.)

Reverse engineering information was useful because it allowed you to easily make variants on the existing designs. Plus, many of the components also had their own rules for use, so it was kind of important to know what components the vehicle had, not just its performance stats.

[Darekun]

Originally Posted by roguebfl

Other than the fun I have turning such things into programs myself. There is an advantage of my book format is you can 'see' the why you get the results toy get and were the assumptions are, and can tweek it to your own assumastion if you like. a Program hides all this.

Originally Posted by cmdicely

You can't make house-rule modifications to software as easily as to a book.

Well, they could implement it all in scripting; with a bit of Computer Programming, you can read what it's doing, and modify it.

Originally Posted by cmdicely

I much prefer the rules in a book. I wouldn't mind having official software, too, but the book is vastly more important than the software.

I'd certainly prefer a book myself, and the best VE software I've ever used I wrote myself. (SDI really is good for some things.)

However, there were face problems. Releasing it as software, so that the only people who can use it "three hours per prototype" style are serious gearheads who look under the hood, would solve that. Also, my tiered scheme was designed to support an equivalent of modders vs users in UT back in the day; each gearhead layer could provide modules/vehicles for the next.

Originally Posted by cmdicely

Reverse engineering information was useful because it allowed you to easily make variants on the existing designs. Plus, many of the components also had their own rules for use, so it was kind of important to know what components the vehicle had, not just its performance stats.

Well, it was useful to us. The main complaint I heard from GURPS players who didn't buy Vehicles was that it really cluttered up the stat blocks. So having it in a separate block would make it easier for them to ignore it and get the regular stats.

Also, even as a gearhead, I don't want the vehicle's combat stats and reverse-engineering data at the same time. Even if you have an "ops" character looking through it for gadgets, the pilot and gunner don't need to see it.

[roguebfl]

Originally Posted by Darekun

Well, they could implement it all in scripting; with a bit of Computer Programming, you can read what it's doing, and modify it.

not really the same thing at all. Given the level specialized skill involved you might as well be saying 'all you need is a hex reader and you can see how it works with any complied program'

There is a world of difference with reading a scripting language and understanding what going on, and reading a semi technical English written to explain what's going on.

[David L Pulver]

Vehicle Design is moving on. A major revised draft was created, and has been undergoing extensive playtest and multiple revisions the last few months. Still some bugs to iron out. (This draft DOES include complete vehicular weapon design, based on a simplified version of the small arm design rules draft I worked out with Hans a while back.)

One of the reasons for delay is I've been concerned the rules are too complex. However, SJ Games tell me that feedback favored complex rules aimed at people who like tinkering with the system, and have indicated that's what people want, so complexity is good. The current rules are similar to the previous system in the complexity level. In fact, the combination of cramming material from all the supplements and aspiring to greater realism means it is certainly more complex than the original book on its own; some of the math formula are actually a tad beyond "cube roots" (like "raise it to the power of 0.2") in a few small instances - mainly in the formula for water vehicles, in order to properly handle how the combination of water resistance and wave making resistance affect speed, to give better results. (There are also a chapter full of guidelines for simplifying things, chucking the whole approach, and just assigning stats). As always, these rules are, however, just a simplified model. They''re complex and long because they try to do everything and get somewhat reasonable (one hopes) results in the process.

The VDS rules do generate the stat block from 4e. (They also add a few optional stats for extra detail, and because you need them to find out why vehicles were built that way.) They also add a number of rules variations and options.

For those who HATE HATE HATE! such complex systems and fear that they will pollute the simplicity and/or effect-based nature of 4e, don't worry about it. When I was designing 4e with Kromm, I made sure that the rules had simple stat blocks and advantages that replicated vehicular effects to ensure that people could build vehicles without such complexity. And SJ Games remain committed (as of their last correspondence with me) to making the VDS rules purely optional add-on, only for those who LIKE to play with this stuff. The authors of LOW TECH and HIGH TECH did not use VDS when calculating their stats; VDS is not intended to precisely replicate the values and stats in the Tech books, which are based not on formula but on the author's best guesses based on their own research. That won''t change in the future. Just like GURPS has several different ways to build magic spells, all yielding somewhat different results, so can it have multiple ways to come up with vehicle stats.

I hope to do a SPACESHIPS-type system for much faster design of vehicles (and indeed have a rough draft of that for cars and tanks), but SJ Games would not want me to proceed with that sort of thing until VDS is done.

(VDS takes a while since it's a huge project, taking thousands of man hours; it earns me no money at all while I work on it, so I have to alternate working on occasional other books and articles in the mean time to support myself.)

[David L Pulver]

Originally Posted by dataweaver

I'm hoping that when and if they finally get around to 4e's VDS, the one-line vehicle "stat block" will be front and center in it, not sitting on the sidelines or tacked on as an afterthought. That is, I want everything in the system to be geared toward filling in one or more of those numbers; anything that fails to do so should be stripped out of the design system if at all possible.

Many elements that have a huge effect on COST and WEIGHT are completely unrepresented in the stat block. Electronics, weaponry, stealth systems, damage control, etc. A good example of a simple things not represented in the stat block: seats. In many passenger vehicles - cars, ferries, buses , airliners - the seats occupy the majority of the total volume. Total volume has a huge effect on surface area, size, weight, and performance.

Now, seating is simplified in the stat block to one kind of seat (crew/passenger). However, in the real world, you can have seating that is cramped tightly together (like a subcompact car or light plane) or which is very spacious with aisles for drink carts, head room, etc. like a modern airliner. This represents about a tripling of volume and since most of the body space is the seating, is a huge difference.

If this distinction not in the stat block was not made, you'd fine that either your cars and light planes were two or three times larger (+1 SM, and much heavier and slower due to the extra drag of the huge body) or your airliners, trains, etc. were super-compact (half the size, and thus much higher performance, much lighter, and so on).

So, if the system is designed to follow the paradigm of "choose components and see what results" the level of detail on non-stat block (but important) things are indeed needed, because otherwise its garbage in, garbage out.

That said: the system is designed to generate the standard stat block as the final end result of the rules. And for people ONLY concerned with the basic stat block, an entire chapter is devoted to working around things and how to assign that stat block without going through the complexities of the rest of the system.