Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for upgrade cards that remove slots or actions from a ship #81

Open
spiegela opened this issue Mar 27, 2017 · 5 comments
Open

Comments

@spiegela
Copy link
Contributor

This could take the form of a revoke clause. For example, the TIE Shuttle card would be formatted:

{
    "text": "Your upgrade bar loses all [Torpedo], [Missile] and [Bomb] upgrade icons and gains 2 [Crew] upgrade icons. You cannot equip a [Crew] Upgrade card that costs more than 4 squad points.",
    "name": "TIE Shuttle",
    "points": 0,
    "slot": "Title",
    "ship": [
      "TIE Bomber"
    ],
    "id": 221,
    "xws": "tieshuttle",
    "image": "upgrades/Title/tie-shuttle.png",
    "grants": [
      {
        "type": "slot",
        "name": "Crew"
      },
      {
        "type": "slot",
        "name": "Crew"
      }
    ],
    "revokes": [
      {
        "type": "slot",
        "name": "Torpedo"
      },
      {
        "type": "slot",
        "name": "Missile"
      },
      {
        "type": "slot",
        "name": "Bomb"
      }
    ]
  }

Thoughts?

@jesseflorig
Copy link

jesseflorig commented Apr 6, 2017

To keep the top level clean, I think these should go under a top level section like shipMods with children like addSlots and removeSlots. So Tie Shuttle would look like:

{
    "text": "Your upgrade bar loses all [Torpedo], [Missile] and [Bomb] upgrade icons and gains 2 [Crew] upgrade icons. You cannot equip a [Crew] Upgrade card that costs more than 4 squad points.",
    "name": "TIE Shuttle",
    "points": 0,
    "slot": "Title",
    "ship": [
      "TIE Bomber"
    ],
    "id": 221,
    "xws": "tieshuttle",
    "image": "upgrades/Title/tie-shuttle.png",
    "shipMods": { 
      "addSlots": [
        "Crew",
        "Crew"
      ],
      "removeSlots": [
        "Torpedo",
        "Missile",
        "Bomb"
      ]
    }
  }

Then you could add in additional upgrade effects like Adaptability's PS mod, making it look like:

{
    "image": "upgrades/Elite/adaptability-decrease.png",
    "text": "Decrease your pilot skill value by 1.",
    "name": "Adaptability (-1)",
    "xws": "adaptability",
    "points": 0,
    "slot": "Elite",
    "id": 232,
    "shipMods": {
      "skill": -1
    }
  },

@spiegela
Copy link
Contributor Author

spiegela commented Apr 8, 2017

@jesseflorig

Personally, I prefer something general like grants/revokes as opposed to addSlots/removeSlots since these types of changes can apply to slots, actions and potentially other elements in the future.

I think the idea to nest grants and revokes beneath another key could work, but I don't think shipMods is exactly the right terms, since this can modify either the ship or the pilot... Maybe changes is a better term? Of course, one downside to moving grants around is that it would introduce a breaking change to existing apps.

Those are just my thoughts on the topic.

@jesseflorig
Copy link

jesseflorig commented Apr 10, 2017

I would think if a change is going to apply to a different attributes (slot, action, etc.) you would want to capture that somehow instead of shoving the a bunch of named items into a single field without annotating their differing types. After re-reading your initial post, I see you already accounted for type.

I agree shipMods is the wrong top level name, especially considering they do, in fact, modify the pilot card in most cases. My initial thought on this was that modifications was nice and vague but collided with the upgrade type of the same name. Maybe adjustments?

However, given the fact that grants and revokes is already setup to handle many types among those two fields, it seems more logical to keep them at the top-level. Maybe adjustments could be added to hold all of the number properties (pilot skill, hull, agility, etc.) since they're not really being granted or revoked per se.

@philtomblin
Copy link

philtomblin commented May 18, 2017

Another option would be simply to stick with grants and add a value parameter to action and slot objects in exactly the same way that stats has, but then also allow negative integer values. This would standardise the usage and simplify the schema as a result, without adding any more clutter to the top level.

A couple of examples...

R2D2 would look like this:

{
    "name": "R2-D6",
    "id": 70,
    "unique": true,
    "slot": "Astromech",
    "points": 1,
    "text": "Your upgrade bar gains the [Elite] upgrade icon.<br /><br />You cannot equip this upgrade if you already have a [Elite] upgrade icon or if your pilot skill value is \"2\" or lower.",
    "image": "upgrades/Astromech/r2-d6.png",
    "xws": "r2d6",
    "grants": [
      {
        "type": "slot",
        "name": "Elite",
        "value": 1
      }
    ]
  },

Adaptability (-1) would look like this:

{
    "image": "upgrades/Elite/adaptability-decrease.png",
    "text": "Decrease your pilot skill value by 1.",
    "name": "Adaptability (-1)",
    "xws": "adaptability",
    "points": 0,
    "slot": "Elite",
    "id": 232,
    "grants": [
      {
        "type": "stats",
        "name": "skill",
        "value": -1
      }
    ]
  },

I'm happy to have a stab at updating upgrades.js if we can agree an approach. I might need some pointers on how to do this the right way as I'm a novice when it comes to git and how pull requests work...

@philtomblin
Copy link

Okay, I've submitted a pull request to address this issue. There is an added complication in that slots can be granted by value (+ or - a specific value) or revoked altogether (i.e. remove all slots of a specified type). I believe this is fully covered and I've also amended the upgrades data for all impacted cards I can see.

Comments welcome...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants