T5 Announcement!

[MJD]

Tables can lead to some odd effects in designing, such as everything being done to neat values. Ie, all 1000 ton ships, never any 972 ton ships, because using tables the rounding makes neat values more efficient.

Not necessarily bad, but it makes for a game universe with very samey vessels at times - especially small ships where the lost percentage of tonnage would be rally important.

Who'd build a 180 ton ship if they had to put 200 tons of J-drive into it anyway? With formulae you have more flexibility which can be a good thing - or lead to the exercse in madness that could result from using Fire, Fusion & Steel.

 

[AndrewW]

Who'd build a 180 ton ship if they had to put 200 tons of J-drive into it anyway? With formulae you have more flexibility which can be a good thing - or lead to the exercse in madness that could result from using Fire, Fusion & Steel.

200 tons of J-drive in a 200 ton ship? You wouldn't have space for anything else, not even fuel for it...

Now if they put a drive sized for a 200 ton ship into it that's different.

Agreed, that's why I would prefer formulas for these things like they did with capital ships.

 

[MJD]

I meant a 200-ton-ship's-worth-of-drive....

 

[rust]

I like tables as a way to provide inspiration for random background events
of a setting, they help me to invent and introduce events I would not have
thought of myself, and which are different enough from my personal style
to surprise my players (who know me well enough to predict many of my
own ideas).

I do not like tables when it comes to stuff like physical data of planets and
to technological designs. They can be useful shortcuts if something has to
be designed in a hurry, but they often prevent me from designing what I
really want and what really fits best into my setting.

So, while my mathematical skills are definitely underdeveloped, and I still
need my pocket calculator's manual to handle more complex formulas, I
very much prefer to do the extra work and see it rewarded with a result
that is both original and tailored to my setting's specific needs.

In my case this led to a love - hate - relationship with GURPS Space and
GURPS Vehicles. I truly hate the formulas and the time it takes me to use
them to design something, but I love the additional detail and plausibility
of the results that add depth to my settings.

 

[Fovean]

I'm with rust... I rather like tables for patrons, events, encounters, etc but prefer formulas for design, especially GURPS First In for stellar & system generation, and the old percentage-based system from the original High Guard for ships.

I'm trying to tweak the ship design percentages to make my system work for vehicles and small craft up to capital ships, then look at integrating the combat scales. MegaTraveller I think had the right idea but was ridiculously complex and seemed broken too - I hated designing a decent ship only to have to go back and redesign it because it didn't work within the rules!

It is a lot more work, using formulas instead of pre-made charts/tables, but the detail is worth it to me... each additional detail I generate opens up two or three story ideas for the background, or the ship in question.

 

[BP]

Almost all the MGT tables of a design nature I have seen were obviously developed by formulas. Besides, as rust pointed out, tables limiting our design options - some appear to have a mistake or two - i.e. inconsistencies introduced by miscalculation or editing errors.

Values from formulas can at least be verified very easily and reliably. Table lookups cannot, with tedious reverse lookups (that may have multiple 'hits').

At least for MGT, the formulas we are mostly talking about hardly qualify for such a name. They are mostly percentages and simple times x equations, nothing more. If one can't do those - looking at simpler games might be in order, or sticking to off the shelf designs. If you have a table fetish - then any spreadsheet program can make a table for you supper easily. And there are a great number of folks out there who would do this a the drop of a hat if just asked.

As long as the Golden Design Paradigm for MGT is make it playable - not lets make a simulator - formulas are great for all design systems.

And that means less errata to fix (messed up tables), less layout to hassle with and fix (tables fitting on pages, etc.), and more page space available for explanations and examples, etc.

Anyway - count that as a vote for formulas over tables for design calculations.

 

[The Chef]

i'm terrible with maths, so i prefer "it weighs this much and costs this" sort of thing... doing a ship now for the 1bcr torny, had to start over again as i'd missed off armoured bulkheads and a hardened bridge.

 

[AndrewW]

i'm terrible with maths, so i prefer "it weighs this much and costs this" sort of thing... doing a ship now for the 1bcr torny, had to start over again as i'd missed off armoured bulkheads and a hardened bridge.

The formula's don't need to be complex, generally simple calculations will do. For M-Drive use .2 * hull * desired thrust. Then if TL 13 * size by .9, if TL 14 & size by .8, etc.

 

[BP]

Hi The Chef - somewheres along the post ways I gathered 'maths' wasn't your strong suite

Glad to see you are still giving it a go at the '1bcr torny', despite all the 'maths' involved. Myself, I'm comfortable with all kind of maths - from Boolean to Quanterion and several types in between. But I still like Keep It Simple Stupid in my gaming. For starship design, things are more tedious given the options, exceptions and the need to recalculate things constantly (due to inter-dependent design tweaks and human error).

I used custom made spreadsheets to do all my iterations - and this is really easy when formulas exist. It sucks using tables - since there is no real way to validate the design mathematically, and one has to 'accurately' type in hundreds of table entries instead of a few simple formulas. Mostly, I reverse engineered the tables into formulas with conditional exceptions to handle the 'irregularities' that exist (mostly errors I suspect, or some foolish tinkering just to be more randomly 'realistic').

BTW: For standard designs (under 2001 tons) - drive tons/MCr are based on the 'value' of each Code - i.e, A=1, B=2... Z=24. (see below). So M-Drive, for example is just:

• M-Tons = 2 times Code, minus 1
  M-MCr = 2 times Code, plus 2
  *EXCEPT for Code A M-Tons which drops the minus 1 (in CT I believe there was no exception to its formula)

For the 'multi-cation' impaired amongst us, the 2 times Code could simply be stated: Code plus Code.

• Note: multiplication and division, and a lot of other 'maths' (like common calculus) are just shorthand for lots of addition or subtraction - really! Math is ultimately a tool for being a lazy writer.

Now if the M-Drive tons/MCr was simply calculated from the G rating (like 1-6) and tonnage, then no codes would be neccessary at all!!!!! This would greatly simplify things. (And is actually how it was originally done anyway, the tables just disquise that.)

I'll repeat, Codes are really only there to make the tables work (and look cool in the old USP coding scheme - which many people don't seem to like anyways). Reality is that tables add a lot of work and potential for error - despite the 'idea' that they make things easier.

When CT came out, calculators were fairly rare, so tables were common. Fast use of slide rules was more the domain of the some technical bunches - many disciplines didn't use them at all. Further, most Americans had recieved such poor math education due to flawed nation-wide policies that they couldn't even handle simple multiplication, and so, tables ruled. Plus tables can look very imposing and officious.

 

[PFVA63]

The formula's don't need to be complex, generally simple calculations will do. For M-Drive use .2 * hull * desired thrust. Then if TL 13 * size by .9, if TL 14 & size by .8, etc.

This actually brings up another issue with equations in games like Traveller, in that they tend to be too simplistic. In real life things rarely ever follow a simple linear relationship. Since High Guard covers such a large range of vessels I'd really rather expect some economies of scale in some instances or dis-economies for other aspects.

Regards

PF

 

[BP]

Yep, PFVA63, to be more 'reality imitating', things would need power functions, logs and exponents and such like - for better or worse, that is just too much for most people.

I think simple, intelligent use of multiplication (for power functions) and derivatives (pre-calced so people only saw the multiples and adds, etc.) could more than satisfy a non-linear design mechanic while being very simplistic to implement.

Sadly, probably beyond the maths of the creators - at least from the concept of writing for a broader public.

 

[AndrewW]

The formula's don't need to be complex, generally simple calculations will do. For M-Drive use .2 * hull * desired thrust. Then if TL 13 * size by .9, if TL 14 & size by .8, etc.

This actually brings up another issue with equations in games like Traveller, in that they tend to be too simplistic. In real life things rarely ever follow a simple linear relationship. Since High Guard covers such a large range of vessels I'd really rather expect some economies of scale in some instances or dis-economies for other aspects.

Regards

PF

It may not be entirely realistic but would be fine for most in a game situation.

But could still be simply just use if vessel > 1,000 tons but < 2,000 then use adjusted forumula.

 

[AndrewW]

I think simple, intelligent use of multiplication (for power functions) and derivatives (pre-calced so people only saw the multiples and adds, etc.) could more than satisfy a non-linear design mechanic while being very simplistic to implement.

Adding power requirements would be a nice addition...

 

[PFVA63]

...I think simple, intelligent use of multiplication (for power functions) and derivatives (pre-calced so people only saw the multiples and adds, etc.) could more than satisfy a non-linear design mechanic while being very simplistic to implement...

Hi,

That was kind of part of my reasoning for prefering tables (at least in some areas). You could lay out whatever progression you felt was appropriate for the system in question, but the user would only have to look up the vaule and add or subtract, etc and not have to do logarithms, exponentials, and complex polynomials, etc.

That, and the point I tied to make earlier that when a question arises about a design, you can go back and clearly show that this values came from column A of row B of table X, etc, rather than debating whether 1/6 of 14,000 should be 2330, 2333, 2333.3, or 2333.3333333, etc which may be effected by whether someone is doing hand calcs or whether they have a spreadsheet or program ro do the calcs.

It may not be entirely realistic but would be fine for most in a game situation.

...But could still be simply just use if vessel > 1,000 tons but < 2,000 then use adjusted forumula.

That could help alot, but I fear that you might still run into the second issue I noted above in some cases.

Regards

PF

 

[BP]

By pre-calced so people only saw the multiples and adds - I was referring to derivatives simplified into 2x instead of x^2 etc...

Yes tables are good for complex, non-linear progressions - but, a) as a RPG and not a simulation, MGT, doesn't need that level of psuedo-realism and b) that, even more, (and more unrealistically), limits designs to discrete table entries (i.e. 100 tons versus 120) - since it would, really, make inbetween value interpolation very unreliable (without the equation, rounding might even preclude curve fitting by those knowledgable of such - and most would use a linear interpolation anyway - drastically, and inconsistently throwing things off).

Your point about rounding is fine - but couldn't be handled in tables well in another respect. Consider - in a 12 ton vessel, 0.12 tons is very different, feature craming wise, than 0.12 tons on a 1,000 ton vessel. With a table the importance of such could not be addressed well at all. With equations, simply stating the number of significant digits or decimal places, would work perfectly. As it could scale with the design or remain static as needed.

• Verifying or even figuring out missing design specs is really easy and reliable with equations. For instance, currently, for standard (100-2000 tons) ships, M-Drive rating is simply half of the cost after subtracting 2 MCr. That is a heck of a lot easier than looking up a cost in the Table on pg 107, after first finding the correct column, then looking across to find the correct drive code (hoping one doesn't go cross eyed and grab the wrong code), then, turning to the table on pg 108, then finding the correct tonnage column for the ship, then looking down the rows to match the Drive codes for the correct rating (and better luck on not going cross eyed there). Now, not only does that take a lot more time, space, and effort to explain, and perform (the book space included) - there is a whole lot more chances for mistakes than in simply doing one subtract and a divide!

Of course, this should also include stating a rounding method for use everywhere in all designs. Note: these issues exist today for numerous design mechanics already out there - where tables would take up way, way too much print space (not to mention be very impractical to use) - such as Capital ship drives.

Since this is a fictional system - such can also be left to the designer, as it is today. Except if using automated programs to just transfer specs (and not tons/Cr) - or in tourneys - this is largely a non-issue. In tourneys such should be explicitly spelled out. For other cases, tonnage is really only relevant for the designer - and cost to fractions of a MCr applicable only for small ships, and easily adjusted by Ref (personally, 'pricing' should be handled differently, anyways). This is, afterall, a fictional system - and designed to be playable - which precludes 'realism' to a greater extent anyway.

NOTE: Not saying get rid of tables - by any stretch. They should be used where appropriate - for multi-value lists, matrixes, and non-equation based data. All the tables we are talking about were derived/created from equations in the first place.

 

[BP]

Darn, looks like I missed Matt's April Fools Day planet mongoose post - when I could have let everyone know about being the millionth book purchaser!

 

[Rikki Tikki Traveller]

I prefer simple formulas.

For example, for the size of the M-Drive:

Size = (A + BR)*Ship Tonnage

Where A and B are values looked up from a table that changes with TL and R is the rating desired (in this example, the G rating).

This lets me make things smaller, and more expensive, as TL increases, giving some more granularity to the TL tables instead of huge jumps every 2-4 TLs.

Each TL would also have a Minimum or Maximum Rating limit and possibly a minimum size limit.

 

[PFVA63]

Something like that could be a very good idea, allowing you to implement non-linear stuff into simple calcs. As long as the rules also address rounding and significant digits, etc in all the steps of the calcs I'd favor that kind of approach.

Regards

PF

 

[Rikki Tikki Traveller]

I have always felt that 3 significant figures is "good enough".

When you have a 500,000 ton ship, figuring out something to the thousanth of a ton is rediculous. Same for cost. When dealing in Megacredits (1,000,000 credits) who cares about a Cr. 10 comm unit or a Cr. 20 coil of rope?

 

[Bishop Odo]

Back tracking a little bit, I have noticed that any attempt to replace a good GM with Rules is destined to fail, sorry. A RPG is not a wargame or a boardgame, it should not competitive. If there is no trust between the GM and players, no sense of comradely, that is you are all in this game together, make the best of it, how can it, the game, truly succeed?

It’s one of those things, that until you experience it, you do not know what you are missing.