Quote:
Originally Posted by swordtart
Sounds like their should be an App for that ;)
For the wider issue of keeping things fresh without stretching implausibility, I was thinking of doing a solo game where you start at a particular system and then jump into the unknown, generating systems as you go (sort of like scouting, but focusing on the trade aspects).
This would be divergent from the basic Traveller canon where everything is already mapped out, but you could put it forward as extending trade to a pocket empire hitherto uncharted after a self imposed quarantine like Japan in the 19th century. I was also wondering about doing a TNE campaign where things have changed. You can safely assume the Gas giant for refueling was still in place, but the TL and economy of systems would be very different from the historical records.
This would be making new markets and for a few months you would be lord of all you had surveyed.
|
For a Traveller Milieu Zero campaign, that probably would work. As for the app aspect?
When I crafted what I had - I used an excel spreadsheet like data container (Datagridview). In it, I stored the following information:
Bid Status, Lot Size, Freight Code, Freight Description, Destination, Freight Rate, Delivery Date, and Distance in Parsecs.
I had a menu feature called "Spot Freight Market" which allowed for one to "View today's lots". The program would then open a file that contained all of the trade partners for that world per the original Far Trader rules, whose BTN was in excess of a given value (in other words, it had to actively generate daily trade). Then, it would generate all possible trade not only based on the limit of the daily trade, but also for each and every trade partner.
Once that list was generated, it was organized by Destination world. When the Cargomaster of a ship wanted to select any given lot, he'd simply right click on the lot in question, and a menu option appeared. Bid. If he selected bid, the bid status changed from "Open" to "Bidding" and the entire line would be highlighted in Green. Should the cargomaster change their mind, right click on that bid and the menu would instead show "remove bid" and the green highlight would disappear and the status would revert back to open. As you bid upon each lot, a running tally of how many dTons of freight lots being bid upon was maintained. Once you bid, it would generate a delivery due date, remove all outstanding "Open" lots, and leave showing only those that were bid upon.
The criteria for generating freight lots for the day was that each BTN relationship had a gross tonnage value for that destination per the rules given. Then, a for loop would call the function to generate a number as 4d6-4 value (if zero was the result, reroll until it was not a zero result). The loop would generate lots until remaining lot size was less than 20. If the remaining tonnage was less than 20 but greater than 0, it would end the process.
Mind you, that app worked to do what I wanted it to do, but here was the problem...
It always generated a new tonnage value between the worlds in the BTN pairing fresh. There were no provisions for those lots that were not bid upon the previous day.
I would have needed to implement a database structure to track per the rules, fluctuating lot sizes between worlds for each and every world throughout the game - even those worlds not being visited largely because of how the rules were structured (in case any given world was within range of the player characters or might be a possible destination). How much data would have been necessary to store would be debatable (ie up to the discretion of what I thought was necessary), but that would have required more work on my part.
The other problem is that pure distance from port to destination port does not equate to how many jumps it will actually take to get to the destination. For that, I would have either had to create an AI routine to determine best possible route, or I would have required that information to be manually imported by the user (best case scenario) or created a listing of destination times from each world to its BTN partner (ie by doing the grunt work ahead of time manually).
The nice thing was - if you were going to a destination that was 12 parsecs away, and you had to visit 5 worlds between your current location and your destination location, you could also view the available lots of freight on each of those 5 additional worlds and bid on them.
The reason I stopped working on the app was largely because the Traveller campaign had come to an end, and we moved on to a new GURPS campaign - why work on something I wasn't going to use any more?
For the cargo lot identification, I used the codes from TRAVELLER 5th edition for my code, so I could generate things like Live Animals, Meat & Meat Preparations, Dairy Products to Raw Hides & Skins to Petroleum & Petroleum Products to "Chemicals, Other" right on down to musical instruments.
In all, I had 101 freight description listings. :)
The other problem I have is that when I use the rules as written, without turning the ship into a "Line" (which technically speaking, your milk run became when you only plied your trade between two worlds) - a tramp freighter who owes money on monthly basis for its mortgage payment, can't survive on 700 credits or 650 for destinations in excess of 2 parsecs.
Eventually - GURPS SPACESHIPS would come up with modifiers for freight bidding in that if the ship has been there before within a certain time span, all rolls for available freight and cargo lots suffered a penalty. Those rules were not for Traveller however.
So - could someone actively write an app to handle all of this? That I got as far as I did using a text interface only, the proves it isn't all too difficult. It is just a bit tedious in how much of the manual grunt work will be to determine actual jump travel rather than distance in parsecs. It is also tedious in setting up a database to track numbers for star systems not being visited by the player characters or the ship itself. Last but not least, if I were to want to have a graphics based interface, I'd have to learn how to create bmp style pictures from scratch (something I didn't want to do with VB.NET).
it can be done however. Any time I want to remember how I learned to work with data in a Datagridview container - I refer back to that particular program, as it taught me how to do that kind of thing. :)