[Spaceships] Getting started on a Java-based ship builder

[panton41]

I'm thinking about starting work on a Java-based designer based on GURPS Spaceships. I'd probably do it in stages with a data-import subsystem working first, then the back-end for the actual assembly (using a console-driven interface) then finally a GUI front end.

I'm thinking rather than the XML-based import I discussed earlier I'll use tab-delineated plain text and instead of recreating the tables in Spaceships I will recreate its mathematical underpinnings (namely the 1-3-10 and 2-3-5-7-10-15 based cycles) and generate the data from that information. Doing that would allow ships of arbitrary size. Tab, Carriage Return and EoF characters will be "keywords" in the data file format and there's be escape characters for comments.

The back-end would be anchored with a 21-field array that contains a binary data type (to say if the system has been filled) and a data type that represents the systems themselves. There would also be a linked-list to represent the additional options (like gravity, stealth, etc.).

There would be a method that would go through both the systems array and options linked-list and add up everything to display price, workstations, etc.

Saving the ships will also be tab deliminated plain text, but include the data files used and be more like a list of the internal ID numbers for the systems rather than anything usefully readable. Loading would be more or less the reverse of saving. There would also be an export feature that would output it in more readable format.

My initial goal would be to get Spaceships 1 implemented and some of the user-friendly features of Eric B. Smith's spreadsheet (like being able to declare what each "cabin" and weapon mount contains). I'd consider that minimum, with a console-based interface, the "1.0.x" level of finished. Adding the systems and options presented in later books would probably be simply redesigning/adding data files if needed. Spaceships 3 would warrant a 1.1.x version due to adding hex-based stats and 1.2.x for Spaceships 7 because of larger and smaller systems being added. After than a 2.0 GUI build would be made for a more user-friendly interface that would cover everything in the console builds.

I would include house rule data files, starting with the ones from Eric Smith since I've found them pretty useful and common-sense. Any others would simply have to be created based off of the data file template.

Finally, the rational for Java is twofold. One, it's pretty well cross-platform and would work on Windows, Linux, Macintosh and probably a decent number of Java-enabled smartphones. And Two, it's the language I know best and "good enough" for such a simple project.

Due to issues with SJ Games IP being involved I'd rather not open source the program outright, though the source code would be freely available to anyone who wants it. (Maybe use the GPL on the source-code and let the data files be handled by SJ Games copyright. If anyone official wants to comment about the best way to handle this feel free.

After all of that, is anyone interested in helping with this. I have a feeling it would probably only take a few weeks to hammer out a working console-based beta and maybe a 1.0 release before the end of the year, assuming school doesn't kill the progress.

[ericbsmith]

Originally Posted by ciaran_skye

I'm thinking rather than the XML-based import I discussed earlier I'll use tab-delineated plain text and instead of recreating the tables in Spaceships I will recreate its mathematical underpinnings (namely the 1-3-10 and 2-3-5-7-10-15 based cycles) and generate the data from that information. Doing that would allow ships of arbitrary size.

While that works with most systems, keep in mind that a few ship systems step outside of those two standard size ratios. The lowest end of armor dDR, a few of the SM4 systems introduced in a later supplement, and the number of Areas in Open Spaces immediately come to mind. If you can use the standard size cycles for most information, but allow for specific SM's to be set "arbitrarily" that would help alleviate some problems you'll encounter later on.

[Kuroshima]

Personally, I would not chain myself to the file format. Tab Separated Values is not the best format for data storage, but it's easy to parse and read, it's a good preliminary format. Do things right, and use proper layer separation between data, business and presentation layers, so you can change the data layer later on, to something more sophisticated. This, I like from your project plan, because you tart with the data, and then slowly move to the upper layers.

As for how to store the systems (and remember, I have just a passing acquaintance with the spaceships system from forum posts and the Vorkosigan book), I would move away from static arrays. Java collections are quite good. I would design the Spaceship object as having 5 vectors (front, central, and real hull, core and systems that don't require slots). Give them the appropriate type via inheritance and interfaces (So a system that can be placed into any location would be a class mySystem extends abstractSystem implements frontHullSystem, centralHullSystem, rearHullSystem, coreSystem). Give your spaceship object appropriate methods to make sure that every system can only be assigned to the proper location (so addFrontHullSystem(frontHullSystem system)). Modularize. Use version control, even if you're working alone.

[panton41]

Originally Posted by ericbsmith

While that works with most systems, keep in mind that a few ship systems step outside of those two standard size ratios. The lowest end of armor dDR, a few of the SM4 systems introduced in a later supplement, and the number of Areas in Open Spaces immediately come to mind. If you can use the standard size cycles for most information, but allow for specific SM's to be set "arbitrarily" that would help alleviate some problems you'll encounter later on.

Would it make more sense just to recreate the tables from the book and be done with it?

Originally Posted by Kuroshima

Personally, I would not chain myself to the file format. Tab Separated Values is not the best format for data storage, but it's easy to parse and read, it's a good preliminary format. Do things right, and use proper layer separation between data, business and presentation layers, so you can change the data layer later on, to something more sophisticated. This, I like from your project plan, because you tart with the data, and then slowly move to the upper layers.

The reason for tab delineated format is that is that they're trivial to edit by hand and there's not really a huge need to make it especially robust. Not to mention these aren't hard set plans, just a brainstorming session typed out.

Originally Posted by Kuroshima

As for how to store the systems (and remember, I have just a passing acquaintance with the spaceships system from forum posts and the Vorkosigan book), I would move away from static arrays. Java collections are quite good. I would design the Spaceship object as having 5 vectors (front, central, and real hull, core and systems that don't require slots). Give them the appropriate type via inheritance and interfaces (So a system that can be placed into any location would be a class mySystem extends abstractSystem implements frontHullSystem, centralHullSystem, rearHullSystem, coreSystem). Give your spaceship object appropriate methods to make sure that every system can only be assigned to the proper location (so addFrontHullSystem(frontHullSystem system)). Modularize. Use version control, even if you're working alone.

Makes perfect sense, though it might make importing systems from the data file much more complex. I was thinking of having an item in the System object that would more or less be "locations" which would then be enforced. By doing that I could expand the features of the overall program without having to totally rewrite the whole thing (such as the changes needed for Spaceships 7). I'd rather put the emphasis of making major changes on the data files than the underlying code, which can help with long-term stability (less code changes) and expandability.

The reason for using the array for the internal systems is there are only 21 possible locations, of which 20 are used.Locations 0-6 would be "Front", 7-13 are"Center" and 14-20 are "Rear" and Location 6, 13 and 20 would be Core. There would be a method to see how many core systems are used and allow no more than 2 at a time. Also, these numbers would be set in a data file as well in case anyone wanted to implement house rules for more systems (and probably allow Spaceships 7 to be done easier).

[Langy]

After all of that, is anyone interested in helping with this. I have a feeling it would probably only take a few weeks to hammer out a working console-based beta and maybe a 1.0 release before the end of the year, assuming school doesn't kill the progress.

I'd be interested in helping! I'm not a professional programmer by any means, but I have some decent experience with Java, including an aborted attempt at making a Java-based ship building program myself and I'm currently working on an implementation of GURPS Space's star system generation sequence. I've also done a lot of tinkering with the Spaceships system - my Ships of Arbitrary Size thread should be helpful in looking up the various formula needed for each system.

Using vectors or lists instead of static arrays is probably a good idea - it'll certainly help when dealing with Smaller or Larger systems later on. No need to have a Core vector, though - just include that in the Front/Central/Rear vectors, since a Core system is still considered part of those sections.

As for data files, tab delineated files are perfectly adequate unless you want to get fancy and put all sorts of complicated bits in the data files rather than hard coding them into the program. It would probably be best to hard code various 'base' system types into the program (things like Generic Armor, Generic Factory, or Generic Reaction Drive) and then have the data file specify what generic system each system is and the specifics of it.

[ericbsmith]

Originally Posted by ciaran_skye

Would it make more sense just to recreate the tables from the book and be done with it?

Depends on what you want to do. If you're looking at extending SM beyond SM+15 then you're going to need to implement some extrapolation anyway, and most of the systems follow the standard progressions. In my spreadsheet I used formulas to fill out most of the information in a giant table, then replaced the formulas with the values.

It's not a huge issue to just follow the standard progressions; it's mainly an issue because you need to be able to introduce some systems at some SM's that don't follow the standard progressions, or that have their own progressions.

Incidentally, all of the information from the systems tables in Spaceships (and several other books) is already laid out in my spreadsheet. There's no need for you to go about recreating most of that work.

[Langy]

Would it make more sense just to recreate the tables from the book and be done with it?

There's mostly no need - you just need to make sure each system uses the correct progression. Open Spaces, for example, use a 10^(1/3) progression rather than a 10^(1/6) progression that, for example, Armor uses, or the 10^(1/2) progression that Mass follows.

There are some specific SMs and systems where things break down - the most egregious is probably the SM+6 Habitat module - but those can easily be taken care of with specific snippets of code.

[panton41]

Originally Posted by Langy

I'd be interested in helping! I'm not a professional programmer by any means, but I have some decent experience with Java, including an aborted attempt at making a Java-based ship building program myself and I'm currently working on an implementation of GURPS Space's star system generation sequence. I've also done a lot of tinkering with the Spaceships system - my Ships of Arbitrary Size thread should be helpful in looking up the various formula needed for each system.

Using vectors or lists instead of static arrays is probably a good idea - it'll certainly help when dealing with Smaller or Larger systems later on. No need to have a Core vector, though - just include that in the Front/Central/Rear vectors, since a Core system is still considered part of those sections.

As for data files, tab delineated files are perfectly adequate unless you want to get fancy and put all sorts of complicated bits in the data files rather than hard coding them into the program. It would probably be best to hard code various 'base' system types into the program (things like Generic Armor, Generic Factory, or Generic Reaction Drive) and then have the data file specify what generic system each system is and the specifics of it.

I'd have to go through my notes and remember all my options. We had to actually implement our own version of arrays, vectors, linked lists, trees, etc. just so we'd have a better understanding of how they work.

Like I said before, I'd rather hard code as little as practical and throw off as much functionality as possible to the data files but I suppose there are some minimums of what can be done like that. I'll probably dissect Eric's spreadsheet to see what all can be done like that, but I'd rather have a single System object type rather than an Armor object, Powerplant object, etc.

On the second thought, a single System object type extended to be a ArmorSystem, PowerSystem, etc. would be more elegant and flexible. How many different major system types are there to do like that?

Chances are I'd eventually want to implement your arbitrary sized ship as an option simply because about the only easy way to do it is in software and it would fill a major hole in the Spaceships system. It would be great if Mr. Pulver could help verify some number to give it a semi-official blessing.

Originally Posted by ericbsmith

Depends on what you want to do. If you're looking at extending SM beyond SM+15 then you're going to need to implement some extrapolation anyway, and most of the systems follow the standard progressions. In my spreadsheet I used formulas to fill out most of the information in a giant table, then replaced the formulas with the values.

It's not a huge issue to just follow the standard progressions; it's mainly an issue because you need to be able to introduce some systems at some SM's that don't follow the standard progressions, or that have their own progressions.

Incidentally, all of the information from the systems tables in Spaceships (and several other books) is already laid out in my spreadsheet. There's no need for you to go about recreating most of that work.

I'll probably export the tables from your sheet to use as a raw master data file since the grunt work is largely done, but I'm not well versed on how to use Excel at the level you do to pull out things like the equations and stuff.

At some point I'm still going to have to analyze each entry in the entire series with a microscope so I'll find the non-standard progressions and flag them for special consideration. There's probably still a progression to them that can be used so I'll figure that out when I get to it. If the standard progressions work for all but a handful of systems I'll focus on that first.

Edit: Just saw Langley's reply to Eric, I'll look into it, but the above is probably still true.

[Langy]

At some point I'm still going to have to analyze each entry in the entire series with a microscope so I'll find the non-standard progressions and flag them for special consideration. There's probably still a progression to them that can be used so I'll figure that out when I get to it. If the standard progressions work for all but a handful of systems I'll focus on that first.

I already figured the progressions for each of the different systems in Spaceships 1 in this thread. As I mentioned, there are some specific system/SM combinations that don't fit their normal progressions, so those ones will need to be hard coded in.

[panton41]

Originally Posted by Langy

I already figured the progressions for each of the different systems in Spaceships 1 in this thread. As I mentioned, there are some specific system/SM combinations that don't fit their normal progressions, so those ones will need to be hard coded in.

I'd still work it into the data file as opposed to in the Java code itself, especially if it's specific exceptions to an otherwise regular progression on the same system. Of course that makes for a good argument to use a more complex file format that just tab deliminated plain text.