• Welcome to the new COTI server. We've moved the Citizens to a new server. Please let us know in the COTI Website issue forum if you find any problems.

Console or "Save String"?

robject

SOC-14 10K
Admin Award
Marquis
Assume we're in the 8 bit world, where games are small but interesting.

I've got my trader game, which currently is stateless. It doesn't save state. But it probably ought to, and it's probably not difficult to do.

SAVE STRING

However, I've also thought idly about "storing" a "LITE" game state in a short string.

Maybe it has the ship, its location, and the player's cash.

Seem reasonable? If the ship isn't customizable, it's easy. But what if it is? What are the limits here?

40D0A0743
"4" = ship index code. It's ship number 5 in the master list -- the Free Trader.
"0D0A" = hex location, in ehex, where Spinward Marches 0101 = "0101". Deneb would start at "2101". Or it can be in base-16.
"0743" = the guy has MCr 74.3, reasonably assuming you can't bank more than MCr 999. This could be in base-36 for a character saving.

The idea is that the player can type it in as a shortcut to give the initial conditions a bit of a kick.

This is also nice for me, the developer.

CONSOLE

Perhaps the BETTER option is to provide a console access in the game, where I can inspect and set values directly.
 
Last edited:
RULES

1. It should be a simple scanf() operation to split out the fields.
2. Encoding is useful as long as it doesn't use a lot of strange characters.
3. It has to be "short enough" for a human to TYPE IN. Yet "long enough" to be useful.
4. Assume you can't copy and paste (!).


What's "short enough"?
What's "too long"?


Probably, a USP is too long to type in, if it's just packed data, so take that as the ceiling. So under 20 characters.

A telephone number is fairly comfortable in length. Even then, they have to break it up into groups of 3 and 4.
A UPP and UWP are 6 and 8 characters, and have the anchor of familiarity to help us use it.

10 characters at 5 bits per character is 50 bits of data. Like a small QR code.


Or, if I'm just including hex, ship, and money, I can NOT encode it and let the user's brain leverage familiarity.
1910 A-BS11 743
"Why don't you just TELL me where you were, what you were driving, and how much money you had?" LOL
 
Last edited:
If the ship isn't customizable, it's easy. But what if it is? What are the limits here?
In terms of no combat trading game, most of the parameters involved with starship design become functionally irrelevant.
The starship parameters you Need To Know in order to interface with the trading system are:
  1. Jump Number
  2. Parsec Range, internal fuel only
  3. Fuel Purification/Unrefined Fuel Negation? (Y/N)
  4. Maneuver Number (1G faces challenges at world size: 8+, 2G has unrestricted landings)
  5. High Passengers quantity
  6. Middle Passengers quantity
  7. Low Passengers quantity
  8. Cargo capacity, internal
  9. Mail Contract? (Y/N)
  10. Fuel consumed per jump (used to update fuel state)
Future developments:
  1. Parsec Range, external fuel (adds a lot more complexity, so reserve that for a future development effort)
  2. Cargo capacity, external (again this increases complexity, so reserve for a future development effort)
  3. Life Support overhead cost
  4. Crew Salary overhead cost
  5. Berthing Fees overhead cost
  6. Fuel costs (Cr500 per ton refined, Cr100 per ton unrefined, Cr0 per ton skimmed unrefined)
  7. Subsidized ship? (Y/N)
  8. Paid off ship? (Y/N)
  9. Bank loan on ship? (Y/N)
    • Bank loan overhead cost amount?
That should be enough to get you started. :cool:
 
Yeah, clearly the whole ship's design isn't up for grabs. So MVP is an archetype.

With just a hand-typed string, an obvious "customization" is the QSP.

Mission code - Tonnage, Config, Accel, Jump.

Maybe that's as far as I'd want to go with that sort of interface. Payload is useful, but save it for an actual file.

Hardpoints are important, but I don't think that'll work as a typed string of customizations. Too many charaters, even tightly coded. So before then I'll be writing to a file.
 
Along the lines of "quick and dirty" / MVP...

I'm now thinking that what I REALLY need is a console by which I can set values directly.
That way, I can boot up Trader, bring up the Model/1, and set the ship type, location, cash, whatnot.
 
The level of save depends on what your game does and the granularity of what
Book 2 ships could have their custom USP. If your ships are not customizable and If it is just a trader game with no combat. you only need the values that change. Standard ships are kept in a table.
So your save profile would be.
Index to Ship used
Hex Location of ship (3240 Max)
Current Fuel
Cash on hand
Level of Broker

Stored in binary hex
Index and Broker Skill Level (each takes up 1 nibble)
Location 2 bytes (column 1 byte, row 2nd byte)
Current Fuel 3 bytes
Cash Available 4 bytes (4,294,967,295Cr)
Total: 10 bytes

Then a Series of 4 byte strings representing of your cargo lots
Byte 1 - Type of Lot (There are 36 different cargo types)
Byte 2-4 Tonnage of Lot
Total: 4 bytes per lot.

Limitations: Ships are not Customizable. You only have 16 to choose from (Index 0-15)
 
Last edited:
The problem with a string is if they write it down wrong, they lose their saved game.

Since you're not a wide spread public game you don't necessarily have to worry about accidental "bad words" in your save string.

You likely don't have to worry about folks cheating either. Folks entering arbitrary digits.

But even still you could do just find with Hex Codes, in 4 Digit blocks (no confusion with 1 and I and 0 and O). You should also checksum the values so that you know they're entered properly.
 
Mail could be a 37th cargo type.

Adding non-standard ships could be done by reducing the number of pre-loaded ships and adding a subroutine to add your ship into the ship table.
The Index table should contain the more or less permanent values a ship needs for the game to make use of. More complexity means increasing the index table and possibly the ship profile itself.

Values needed in the index table:
Total Tonnage, Jump number and total fuel tonnage are needed for fuel transactions (puchasing fuel, using fuel).
Cargo Tonnage to determine if you have space to accept a lot
Annual Maintenance Cost (might require a months maintenance over due byte in the ship itself)
Monthly Payment (payment overdue by, payments remaining on the ship)
Standard crew salary, except Your Broker to pay crew salary. Compute Broker salary. In a purely cargo game, the other skill levels & roles do not come into play unless you are going to add travel mishaps.
 
The level of save depends on what your game does and the granularity of what
Yep. I was thinking of something that gets part of what I want.

The problem with a string is if they write it down wrong, they lose their saved game.
Not this at all... rather, the string sets the game state. So it works like a poor man's save, but it's really setting variables without looking that ugly. It would let you try out different configurations, in different locations. For debugging. Call them cheats.



As far as the granularity of the game... well it's primitive. Here's the latest running version.

Traveller Trader 0.11.21
 
Not this at all... rather, the string sets the game state.
But you should checksum the state, and reject it if the state is invalid. Otherwise who knows what you're going to get and, even worse, who knows what the player is going to get. Without a checksum, there's no guarantee that what the player typed in is, indeed, what they expect to find. "Oh look, I seem to have a negative bank balance..."

Similarly, the checksum prevents entry of bad data, so that if they write it down wrong, they can "never" recover it.

Works both ways.
 
Back
Top