Units are hostile or friendly

[olistic]

Units are "hostile" or "friendly", instead of "enemy" or "captive". This gives greater flexibility.

With this change:

• Unit's constructor receives a hostile parameter that defaults to true instead of the current captive parameter.
• Space's .isEnemy() is removed in favor of a new and simplified method .isHostile().
  • .isHostile() calls unit.isHostile() (also new) under the hood.
  • .isHostile() still returns false if the unit is bound.
• Space's .isCaptive() is removed in favor of a new method .isFriendly().
• The rescue ability should check if the receiver is friendly, instead of captive.

Docs and official levels tips like this one will need update as well.

UPDATE: Let's also pass a bound parameter that defaults to false to the Unit's constructor, and set it to true in the Captive unit definition.

[froehlichA]

If you plan to support additional characters that are friendly, but not captive (for example, NPC shopkeepers) further down the road, I would suggest adding the .isFriendly() next to the .isCaptive() method, so that you have two super types: "hostile" and "friendly", and "captive" as a sub type of "friendly".

[olistic]

Hello @froehlichA! Thanks for your interest in the project. Regarding this issue, my plan is to make the core as generic as possible. For that matter, being able to distinguish between hostile and friendly units is enough, leaving the semantics of what a captive is to the towers (some towers may not even define them). For the existing towers, for example, a captive is a unit that is friendly and is bound. With that in mind, do you think there's a benefit for preserving .isCaptive()?

[froehlichA]

Currenty, the beginner tower uses the units imported from warriorjs/units. Why are these units defined in this seperate package, and not in the beginner tower source? Are they there for other tower creators to expand upon?

Personal Opinion: If you want to make the core as generic as possible, I would just put basic unit types that provide a basis to build upon in the warriorjs/units package and leave the rest (like Archer, Sludge, or Wizard) to the tower creators.

Concerning the .isCaptive() method, my personal opinion is that the .isCaptive() should be removed from the Space API and replaced with the .isFriendly() method, like you mentioned, but that tower creators should then be able to define the appropiate methods on the units themselves instead.

An Example:

//warrior-tower-community/units/Shopkeeper.js
const Shopkeeper = {
  name: 'Shopkeeper',
  character: '$',
  maxHealth: 7,
  friendly: true,
  detectionFunction: 'isShopkeeper'
}
export default Shopkeeper;

Warriorjs should then automatically expose the method unit.isShopkeeper() (or something similar) in their API.

With this principle, the tower creators themselves would be able to give players the possibility to check if an unit is a specific unit type or not, because players may want to take different actions if a unit is a friendly shopkeeper, a friendly captive or another friendly unit.

TLDR: Generally, I agree with you that there should only be detection of alignment (.isHostile() and .isFriendly()) in the core, but also leave definition of detection of unit types (.isCaptive(), .isArcher(), ...) to the tower creators, and only expose those through the API.

[olistic]

Currenty, the beginner tower uses the units imported from warriorjs/units. Why are these units defined in this seperate package, and not in the beginner tower source? Are they there for other tower creators to expand upon?

Currently, the two official warriorjs towers are beginner and intermediate. As both shared units, abilities and effects, I decided to create separate packages for them. That allowed me to reuse code in both towers, and also allows other tower makers to use them if they want.

Personal Opinion: If you want to make the core as generic as possible, I would just put basic unit types that provide a basis to build upon in the warriorjs/units package and leave the rest (like Archer, Sludge, or Wizard) to the tower creators.

What I mean by "the core" is the @warriorjs/core package, not all the packages inside this repo. With that definition, the core is already agnostic to unit types, abilities and effects. Those are left entirely to tower makers.

(...) tower creators should then be able to define the appropiate methods on the units themselves instead.

I like this idea, I think it's worth exploring. Would you mind submitting a new issue to discuss this?