Add unique items

[sidav]

Unique items should have special rarity (higher than Mythic), their own graphics and at least one unique (i.e. created specifically for this item) affix.

[Derpford]

Thinking about how to implement this...

• It would be nice to have a "guaranteed affix" thing in the Affixable mixin, because this would also be useful for debugging affixes by temporarily adding that affix as guaranteed. I figure the cleanest way for this to work is to have an array of affix class names that can be added to during PostBeginPlay().
  • This would have to be able to skip affix validity checks if you wanted to, for example, make a unique quad-barrel shotgun with a mag size of 4 that fires twice per reload without allowing mag size as an affix on regular double-barrels.
  • Aside: I wonder how hard it would be to make the SSG have the no-mag behavior, but gain magazine-based behavior on specifically the unique? Or would this have to be its own class of weapon? I think putting some logic around A_Refire would work, maybe call it A_RefireIfMagBased?
• If we assign a weight of 1 to Unique items and put them in their normal pools, it'll gradually make getting a unique more likely as we add more uniques.
  • I might want to implement the DropCategory class/system I described in Drops Spawner Refactor #8 sooner than I thought.
  • Alternatively, an isUnique property would be a simple and immediate solution to this.

[sidav]

It can be made like this (weapons example):

1. Make abstract class UniqueRandomizedWeapon : RandomizedWeapon
2. Inherit all unique weapons' classes from it
3. Item generation methods aren't performed for uniques. Instead, the unique's own method is called.
4. All the "unique affixes" code is in the same folder as the unique item itself.
5. Uniques should be in separate weights table.
   This will allow good robustness in uniques' definitions, as you can make uniques with as much affixes as you want and even alter the generation process itself.

As for the SSG, I think it would just be simpler to make a separate weapon for this. It will also allow separate balancing for these two weapons.

About debugging the affixes: I'm just adding it to affix instantiator with high random chance when testing.

[Derpford]

Note that if all uniques have to subclass from a special class, this means you can't have a unique weapon inherit from an existing weapon--for example, if I were to implement a Unique called "Noisy Cricket" off of the Blaster, I wouldn't be able to use existing Blaster functionality. There are probably things I would have to reimplement most of the weapon for--like, if I wanted to make a unique SSG that uses reloading, I'd obviously have to implement the reload animation--but if we use a special class as the marker for weapons being Unique, that'd be true for every Unique.

That's why I'd prefer something like an isUnique flag and adding something that runs during item generation to add extra affixes, change stats, etc. This could even be something you'd do in setBaseStats(). Then, a hypothetical Unique Blaster or Unique Chaingun or Unique BFG9K would simply subclass from the weapons they're based on.

Oh, another thing we need to do: We need to make sure Unique weapons can't be held alongside their non-Unique counterpart. Maybe a "weapon class" field that gets checked when you swap weapons? I haven't looked at that part of the codebase yet. (This would also allow, say, making the Blaster replace your Pistol if you pick one up.)

Also, I'm being nerdsniped by the DropCategory idea I had earlier, even though I'm not really up for working on it tonight...c'est la vie. Maybe I'll take a stab at it after a good night's sleep.

[sidav]

1. You just need to move Blaster functionality methods to RandomizedWeapon then. That will allow having affixes which for example make the existing weapons chargeable.
2. Do you know if it's possible to replace weapon graphics from outside the states definition? That's what will be needed if weapon is being made unique during generation.
3. About simultaneously having counterparts: I think it shouldn't be a restriction. First, unique weapons are not neccessarily counterparts of something. Second, I was going to implement some "weapon slots" mechanic, maybe tied to backpacks. You can have e.g. 3 weapons at once, and backpacks can increase this amount. What do you think?

[Derpford]

Re: 1, I'd be concerned about what the experience for addon devs would be like. Then again, if someone's making a weapon addon pack, and they have some unique mechanic that's used by one or more of their guns and one or more of their uniques...they can probably just make it a mixin. I don't really like having to move weapon-specific behavior into RandomizedWeapon, but...I can also use mixins for this.

Re: 2, I think it is possible, but...also not necessary? Like, the way I envisioned the isUnique flag working is that it's a Property, and then you can have something like:

RandomizedWeapon // isUnique = false
-> RwBlaster // isUnique = false
  -> U_NoisyCricket // isUnique = true
  -> RwHypotheticalSecondBlaster // isUnique = false

And then U_NoisyCricket and RwHypotheticalSecondBlaster would simply implement whatever they to, whether that's new animations or new mechanics, while using the RwBlaster as a base. Then, when gathering all the classes for the DropsDatabaseHandler, U_NoisyCricket gets sorted into the Unique category instead of the Weapons category.

I'm also not 100% sure about a weapon limit--I'd definitely want to rebalance several weapons if we did that. If you can't carry the whole arsenal at once, then individual weapons really need to be roughly equal in terms of their power budget--which doesn't mean you can't have stuff like the BFG, it just means that the BFG should be balanced around its drawbacks such that replacing it with a shotgun is a meaningful choice with different answers depending on the situation.