REST API for Starship Component creation

[robject]

Most importantly: my code is up on github. All are welcome to post merge requests.

The most likely way to improve the base in a timely fashion is to fix it for everyone.

There are a lot of improvements to make, structural and feature. I get to them one by one as my interest waxes. But improvement is parallelizable.

https://github.com/bobbyjim/acs-builder


Off the top of my head, here are things I know I have to work on.

Code related.

• Breaking the codebase into modules
• I may split component endpoints by range class.
• Moving the component code to an interface-type architecture to better share code.
• Or, perhaps writing actual builder-type factories for component-based building.

Feature related.

• Including permissable mounts for components, perhaps in a sublist. If I have to, I can do it in another endpoint, but I don't think that's ideal.
• Adding defenses.
• Adding armor and coatings.
• Bridge and controls management.
• Adding in "picklist" endpoint for life support-based items.
• Adding in "picklist" endpoint for vehicle-based items.
• Adding in "picklist" endpoint for payload-based items.
• Completing a "flow" of endpoints, from picking the hull to adding life support and staterooms.
• Computer selection.
• QREBS
• Stage Effects
• Mission selection
• Hull TL
• Hull elements: jump field, landers, fittings, wings where appropriate.
• Refueling systems

QREBS and Stage Effects are a bit tricky. They require some specific checks based on the target component; thus each component class needs custom code to manage these.


Still thinking about how a lot of this interworks. For example, comfort and demand are tricky, and feel like the ship validation service what Whartung talked about. I really really really really really think that's the wrong direction for a microservice. So my hindbrain will be thinking about that.

 

[whartung]

Software design is a marathon, not a sprint. One thing at a time.

Especially when still working on fundamentals of "is this even a good idea" in the first place.

Get this thing to design a Free Trader, Scout Ship, Corsair, and a Mercenary Cruiser, then you can make a second (third, fourth..) pass adding in detail.

 

[robject]

As a plain database, it removes some burden from the UI designer, since the backend management of data is done.

But, the potential here is that a microservice can do common and annoying computations as well -- call it business logic -- so that the UI designer can get on with designing the user experience.

Especially when still working on fundamentals of "is this even a good idea" in the first place.

That is EXACTLY right.

Get this thing to design a Free Trader, Scout Ship, Corsair, and a Mercenary Cruiser, then you can make a second (third, fourth..) pass adding in detail.

I note that I finally started to think of these endpoints in terms of my old "T5 Shipyard" app, and how the design flow typically works. In short, I started to think in terms of "How much ship can I design using Postman and this service, without knowing anything about the components except price and tonnage?"

 

[robject]

Let's Try to Design a Beowulf

The walkthrough at this early stage is helpful. People who are attuned to T5 (Dilbert) will easily spot the holes. But even CT Book 2 people will see gaps.

My current aim is to "pass" the "CT Book 2" test. If a CT Book 2 person can't see gaps, then I've made real progress.

I also call that "ACS Zero".

Step 1. Get a Hull.

I know I want a 200 ton hull. But what are my configuration options?

GET /hulls

...
    "U": {
        "config": "U",
        "name": "Unstreamlined",
        "tl": 0,
        "tons": 0,
        "mcr": 2,
        "mcrPer100Tons": 3
    }
...

OK, 200t Unstreamlined. I'll go order one. Let's call it TL 10.

POST /hulls/U

{
   "tons": 200,
   "tl": 10
}

Result:

{"config":"U","name":"Unstreamlined","tl":10,"tons":200,"mcr":8,"mcrPer100Tons":3}

I don't like that extra junk in the object. I know one way to fix that but I don't want to multiply the number of typedefs in my code at this time. So I let it pass until I can't stand it anymore.

OK, I slap that component in my object, probably under the name "header" or something -- actually it doesn't matter how the UI handles that data, that's the UI designer's decision.

Step 2. Install Drives.
Taking a peek at the drives I've got in the service:

GET /drives

{"J":{"type":"J","name":"Jump","label":"","rating":2.5,"tons":5,"mcr":0,"targetHullTons":0,"tonsMinimum":10,"mcrPerTon":1,"fuel":10},"M":{"type":"M","name":"Maneuver","label":"","rating":2,"tons":0,"mcr":0,"targetHullTons":0,"tonsMinimum":2,"mcrPerTon":2,"fuel":0},"P":{"type":"P","name":"Powerplant","label":"","rating":1.5,"tons":1,"mcr":0,"targetHullTons":0,"tonsMinimum":4,"mcrPerTon":1,"fuel":1}}

Just what a Beowulf needs: a J, an M, and a P. I'll put in orders for one of each.

POST /drives/J

{
    "targetHullTons": 200,
    "rating": 1
}

Response:

{"type":"J","name":"Jump","label":"Jump-1","rating":1,"tons":10,"mcr":10,"targetHullTons":200,"tonsMinimum":10,"mcrPerTon":1,"fuel":20}

POST /drives/M

{
    "targetHullTons": 200,
    "rating": 1
}

Response:

{"type":"M","name":"Maneuver","label":"Maneuver-1","rating":1,"tons":4,"mcr":8,"targetHullTons":200,"tonsMinimum":2,"mcrPerTon":2,"fuel":0}

POST /drives/P

{
    "targetHullTons": 200,
    "rating": 1
}

Response:

{"type":"P","name":"Powerplant","label":"Powerplant-1","rating":1,"tons":4,"mcr":4,"targetHullTons":200,"tonsMinimum":4,"mcrPerTon":1,"fuel":2}

Slap those into wherever my UI is storing components.

Step 3. Turrets
Following CT Book 2, I can try to get a couple of weapons. What do we have?

GET /weapons

{"A":{"type":"A","name":"Particle Accelerator","tl":11,"mcr":2.5,"rangeClass":"S","mountClass":"B1"},"K":{"type":"K","name":"Pulse Laser","tl":9,"mcr":0.3,"rangeClass":"R","mountClass":"T1"},"L":{"type":"L","name":"Beam Laser","tl":10,"mcr":0.5,"rangeClass":"R","mountClass":"T1"},"M":{"type":"M","name":"Meson Gun","tl":13,"mcr":5,"rangeClass":"S","mountClass":"M"}}

Hmf, no L-M-S Hybrid! And how does the system know that the T3 is the ONLY mount it will take? Clearly there's a gap here that I want to fix.

Well anyway, let's take one Beam Laser and one Missile.

Mount selection has to be easier than this, but anyway at least I can SEE the mount list.

GET /mounts

{"B1":{"type":"B1","tons":3,"mcr":5,"class":""},"B2":{"type":"B2","tons":6,"mcr":7,"class":""},"Surf":{"type":"Surf","tons":0,"mcr":0,"class":""},"T1":{"type":"T1","tons":1,"mcr":0.2,"class":""},"T2":{"type":"T2","tons":1,"mcr":0.6,"class":""},"T3":{"type":"T3","tons":1,"mcr":1,"class":""},"T4":{"type":"T4","tons":1,"mcr":1.5,"class":""}}

Looks like a bug in there too. What is "class" and why is it always empty?

Range?

GET /ranges

{"AR":{"type":"AR","tlmod":0,"costmod":1,"tonsmod":1},"BR":{"type":"BR","tlmod":-3,"costmod":0.25,"tonsmod":0.25},"D":{"type":"D","tlmod":-1,"costmod":0.5,"tonsmod":0.5},"DS":{"type":"DS","tlmod":2,"costmod":5,"tonsmod":3},"FR":{"type":"FR","tlmod":-2,"costmod":0.33,"tonsmod":0.33},"Fo":{"type":"Fo","tlmod":2,"costmod":5,"tonsmod":3},"G":{"type":"G","tlmod":3,"costmod":6,"tonsmod":4},"LR":{"type":"LR","tlmod":1,"costmod":3,"tonsmod":2},"Or":{"type":"Or","tlmod":1,"costmod":3,"tonsmod":2},"SR":{"type":"SR","tlmod":-1,"costmod":0.5,"tonsmod":0.5},"Vd":{"type":"Vd","tlmod":0,"costmod":1,"tonsmod":1},"Vl":{"type":"Vl","tlmod":-2,"costmod":0.33,"tonsmod":0.33}}

Not ideal at all.

Well anyway, I'll pick a couple of T2 turrets and build weapons. Not ideal; I'll work on that.

POST /weapons/L

{
   "mount": "T2",
   "range": "Vd"
}

Response:

{"type":"L","name":"Beam Laser","label":"Vd T2 Beam Laser-10","stage":"Std","mount":"T2","range":"Vd","tl":10,"tons":1,"mcr":1.1}

Summary

Mount and range options per weapon are a solvable problem. And I think it has to be solved.

And of course development hasn't gotten to all of the absolutely critical things yet.

 

[robject]

Ah! I have to solve weapons (et al) the way I do in my app:

The POST includes a weapon type and a mount, and you get back a list of builds by range.