Classification of technologies and hexadecimal system.

[Stormcrow]

A lot of early sources were interested in representing things with strings of characters representing lots of values. In addition to Traveller, another, even earlier, source was Tony Bath's Ancient Wargaming, in which a sample character called Prince Valiant is described with "435424/344243," meaning General Disposition: Cheerful; Morals: Drink & Women; Generosity: Open-Handed; Loyalty: Duitiful; Appearance: Ugly; Popularity Factor: Popular / Intelligence: Average; Activity: Active; Martial Aptitude: 4; Martial Experience: 2; Political Aptitude: 4; Political Experience: 3.

I feel fairly confident that such systems were abandoned largely because they are not practical to use quickly — you have to count digits and consult tables, and this becomes difficult to do smoothly while actually running a game. Bath's book uses the system it does for exactly for the reason Anthony says: data storage. Bath's audience would be constructing a world and all the characters in it to be referred to during campaign write-ups and after-action reports, not during the heat of play, so they'd have time to look up the codes. Recording each character, who really mostly amounted to background color for a wargames campaign, in one line would be a great time- and space-saver.

I would only consider Alonsua's system useful provided (a) the system covered every relevant technology, which as whswhs has suggested may not be the case for the listed technologies, and (b) if I needed to record a LOT of worlds' technologies without getting too deep about any single one. Fixing (a) is just a matter of better organizing the technologies. (B) depends entirely on the campaign. I could see it being useful in a large-scale space campaign in which you want to generate a lot of worlds randomly and record your results. It would be basically useless in a campaign in which each world or technologically distinct area is carefully developed before visiting it. For instance, in an Infinite Worlds campaign, you're probably going to develop any given world before the players visit it, in which case listing the world's technologies in a code somewhere doesn't really help.

[sjard]

<Moderator>
A reminder that "Correcting" someone else's post in a quote to "to say what they really mean" is considered rude and is not allowed.

Thank you.
</Moderator>

[Alonsua]

Originally Posted by Stormcrow

A lot of early sources were interested in representing things with strings of characters representing lots of values. In addition to Traveller, another, even earlier, source was Tony Bath's Ancient Wargaming, in which a sample character called Prince Valiant is described with "435424/344243," meaning General Disposition: Cheerful; Morals: Drink & Women; Generosity: Open-Handed; Loyalty: Duitiful; Appearance: Ugly; Popularity Factor: Popular / Intelligence: Average; Activity: Active; Martial Aptitude: 4; Martial Experience: 2; Political Aptitude: 4; Political Experience: 3.

Thats impressive. These systems are not made for human use, of course, but for computers. You just need to designate the meaning of the position and the character gives it a value.

[Anthony]

For comparison of systems designed for computer use, let's say I'm designing a computer game that stores D&D characters.

In the 80s I'm probably heavily memory limited, so I might well have an internal representation that is something like:

typedef struct {
  unsigned char str, dex, con, int, wis, cha, hp, classes[3], equipment[6]
} character;

That's 16 bytes long, which is a convenient size for computers. If we assume we encoded percentile strength in the values 19-118, classes are (class index) + (level), and fighter is a class index of 0, a level 5 fighter with 18/25 Str, 9 Dex, 14 Con, 7 Int, 11 Wis, 11 Cha, 32 hp, would be encoded as

2B 09 0E 07 0B 0B 20 05 00 00 <gear>

and enterprising hackers would use binary editors to change their characters.

Now, that format is a hassle to work with directly, so it might get exported as a csv, which would be

18/25,9,14,7,11,11,32,F5,-,-,<gear>

and then imported into a spreadsheet, edited, and read back. By the 90s, you might decide to just keep stuff in the csv and never bother with the binary storage. Even further on, you might use xml (not going to build cuz xml is annoying) or json; a json might look like:

{
	"attributes": {
		"strength": 18,
		"percentile": 25,
		"dexterity": 9,
		"constitution": 14,
		"intelligence": 7,
		"wisdom": 11,
		"charisma": 11
	},
	"hp": 32,
	"classes": [{
		"class": "Fighter",
		"Level": 5
	}],
	"equipment": []
}

The earlier formats are generally more compact and faster for a computer to process; the later formats can be edited with standardized tools and can be examined by a human. There is a reason formats have evolved in this way.

[Alonsua]

Originally Posted by Anthony

The earlier formats are generally more compact and faster for a computer to process; the later formats can be edited with standardized tools and can be examined by a human. There is a reason formats have evolved in this way.

Really cool. I want to suppose that it is for reasons of comfort, or laziness, but the truth is that the first method is much more efficient.

Now, the reality is that you can not pay a programmer with potatoes and expect a high degree of excellence, and it is clear that, if instead of making an application, I have to build twenty, I would give more importance to quantity than to quality.

[Stormcrow]

Originally Posted by Alonsua

Thats impressive. These systems are not made for human use, of course, but for computers. You just need to designate the meaning of the position and the character gives it a value.

Bath's system was made for human use on paper. He even describes his filing system. It's just not for finding a character's statistics in the heat of an encounter.

Back in the 70s it would have made sense to consolidate your data format to fit into a computer, since they had such limited resources back then. You had to save every byte. These days there's little point, as you've got plenty of memory and storage to deal with.

[Anthony]

Originally Posted by Alonsua

Really cool. I want to suppose that it is for reasons of comfort, or laziness, but the truth is that the first method is much more efficient.

That depends on the type of efficiency you're talking about.

The first method is highly efficient for data storage and minimal run-time, but quite inflexible (if you realize there's extra information you want to store, you have to convert everything) and if there's bad data, you need specialized tools to examine your data and find the bad data. The second method is somewhat more flexible (you can add columns that default to null to the end of the row without any data conversion) and you can just load stuff into spreadsheet to modify it. The third is even more flexible (there is no order or count enforcement, so you could add new attributes or something) and is somewhat easier to visually inspect, though you'd still probably use a tool to do bulk editing.

[Anaraxes]

Traveller came out in 1977. Personal computers existed, barely, but it was by no means a given that every gaming group or referee would have one, much less the whole group bringing their laptops or tablets to the game. The notion of giving the game a little high-tech flavor by using a computer-looking code for data records might well have inspired GDW, much the way you used to see SF properties in the 70s or 80s use the OCR-A or E-13B typefaces for their "high tech" looks rather than actual functionality. But I seriously doubt the UPP and hexadecimal notation was a game design criterion intended to save disk space or CPU time for their customers.

[Anthony]

Originally Posted by Anaraxes

But I seriously doubt the UPP and hexadecimal notation was a game design criterion intended to save disk space or CPU time for their customers.

While cosmetics was probably part of it, there are sectors known to have been computer-generated (including randomizer bugs) from the mid 80s.

[Anaraxes]

Originally Posted by Anthony

While cosmetics was probably part of it, there are sectors known to have been computer-generated (including randomizer bugs) from the mid 80s.

I'm sure. Somewhere, I've got the old Imperial Atlas with UPPs for the whole Imperium. That wasn't done by hand!

But there's a difference between a computer program printing out the output in an established format, and that format having been designed with the intent of saving computer memory.

It's more likely they just wanted a single character to fit in a single space or square on a character sheet. I can remember many, many forms of the era with strings of boxes for you to put in one letter per box. It's a pretty natural jump to think of everything as having to exist in a one-letter code in neat columns. That was especially common on government paper forms, of the style GDW was mimicking with their character sheets and all those other forms in Supplement 12: Forms and Charts. (There's an exciting title for you... and yes, I have that one, too. :))

If they were really going for optimal computer performance, they wouldn't have the awkward jump from digits to alpha in their internal formats. Just use one byte per value and start from zero. Non-printable directly, but you can easily run it through a lookup table to get a display character for output, and that'll be less code than an "if 0..9 else A + value - 10" kind of thing going on everywhere the value is used. (There's a jump in the ASCII codes between digits and alpha; it's not a natural progression from 0..15.) That byte is still just 8 bits per value, so that's a wash. They weren't packing those values into nibbles, or they wouldn't have been so casual about going past 'F'.