Quote:
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?
Quote:
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.
Quote:
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).