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

[PROJECT] Drop System & Updates #486

Open
CollinHerber opened this issue Nov 15, 2024 · 3 comments
Open

[PROJECT] Drop System & Updates #486

CollinHerber opened this issue Nov 15, 2024 · 3 comments

Comments

@CollinHerber
Copy link
Collaborator

Summary

The drop and item acquisition system is THE MOST important system of any ARPG and I'm hoping to simplify yet make it expandable to the best of my ability without going to deep too quick.

Here is a rough draft of my ideas for the drop system.

image

Drop Type (Red Section)

The drop type is split into each of our "Categories" of items within the game. Right now that is Currency, Maps, and Gear.
As a starting point we can do something like 5% Map, 80% Gear, 15% Currency

This means that when the game decides to drop a PoT related item, it drops them with those percentages.

However these percentages can be manipulated by certain "events" or "areas" that you are in. For example Maps will could have an affix on them that is something like "50% Increased Chance of Map Drops"

image

These won't exclusively be manipulated by affix on maps, but there may be certain areas of maps themselves that have modifiers to the items dropped in them. Such as the EoW domain might drop more currency or something. Building in a way where it takes these areas into account will be important.

Determining Type / Tier (Green Section)

As apart of this new drop system we will need to have a weighting system to each of the gear types. This is where staticData.DropChance comes into place. Right now just about everything is set to 1f so everything drops about the same rate. However this will be adjusted so higher tier things drop less frequently, or some uniques are much more rare.

This system will have no ways of manipulating the set weighting systems at this time. I doubt we'll add anything that the player can do to sway these weights but we'll leave it possible as it is now for future implementation.

Determining Rarity (Pink Section)

Now that we have determined WHAT is going to drop, we need to choose the rarity. This is determining if the item will drop normal, magic, or rare. I think SpawnItemFromList is doing something like this from ApplyRarityModifier however it's only being applied from the command and I don't think there is any sources of "Rarity of Items" modifiers that we will want to introduce at some point. It's probably something we can revisit later when we get deeper but wanted to get this concept in writing so we have something to fall back on.

Conclusions

In reality the only portion we are needing now is the red section, which is determining what to drop. Right now it's just throw everything into a giant pool and pick something at random. We need to be a bit more precise in what is dropping otherwise as more items get added, map and currency drops become arbitrarily more rare

Reasonings

Needing to bring the drop system up to par with the mod

@CollinHerber
Copy link
Collaborator Author

CollinHerber commented Nov 15, 2024

I think as apart of this effort, it would be a good idea to make a drop simulator so we don't need to spawn in a ton of items filling inventory to test things and we can visualize it in a better way to make making adjustments much easier in the future.

Threw together this simple graph

image

Basically just able to put in all the inputs and have a table of everything to view. Is a scrollable table like this possible?

@GabeHasWon
Copy link
Contributor

A scrollable table is easily possible, though I'm not exactly sure what this image is conveying. Would it be like, the top %'s and #'s are filled out, click the Go Button, and it'll list the drops by:
Name | Count | NormalCount | MagicCount | RareCount | IsUnique
or similar?
So something like:
Iron Bulwark | 20 | 15 | 4 | 1 | False?
Repeat for every item of course.

As for the basic idea, this would streamline the really messy drop system we currently have a lot. The amount of files or things that do or do not happen if done in specific ways is untenable and should be absolutely changed.

A few questions:

  1. I assume all "Modify X drop rate" affixes or modifications would be, unless otherwise stated, per-player? Excluding map affixes for obvious reasons. If it is per-player, how would we determine what affix(es) apply to the loot? Last player who hit the NPC? Any player who hit the NPC?
  2. Would we want tMod-like hooks for all relevant things? Maybe excluding the above UI since it's debugging, but having hooks for modifying drop rates for all types, rarity rates, etc etc would be nice, especially for other mods to use and do whatever with if they wish. This may also simplify how we apply it in-house.
  3. For the red section drop rate normalization - is that strictly necessary? If we report the rates to the end user in release, it'd be necessary as reporting rates that are clearly over 100% doesn't make sense. If that's the case, ignore the rest of this numbered question. If not, internally we'd likely use a WeightedRandom which would function the same if we normalize the chances.

@CollinHerber
Copy link
Collaborator Author

So something like:
Iron Bulwark | 20 | 15 | 4 | 1 | False?
Repeat for every item of course.

I was thinking it would be a number for unique as well, so it would show the number of uniques that dropped. We could forgo that and just list the actual unique item that was dropped instead. Then the normal/magic/rare columns would just be blank for unique items. But otherwise your spot on, it would just list the number of Iron Bulwarks that were dropped in the calc and then the number would indicate how many of each rarity dropped.

I assume all "Modify X drop rate" affixes or modifications would be, unless otherwise stated, per-player? Excluding map affixes for obvious reasons. If it is per-player, how would we determine what affix(es) apply to the loot? Last player who hit the NPC? Any player who hit the NPC?

For the red zone, it would only be effected by the map or area they are in. Not by players, not at this time anyway. I have no plans for adding that type of manipulation through itemization or other means.

For the purple zone it would combine the player that killed the mob and the map modifiers as well. Not each player that is in the zone.

Would we want tMod-like hooks for all relevant things? Maybe excluding the above UI since it's debugging, but having hooks for modifying drop rates for all types, rarity rates, etc etc would be nice, especially for other mods to use and do whatever with if they wish. This may also simplify how we apply it in-house.

So there are a few things I wanna spit out that are in my head around this.
In short, yes I think having the ability to modify these would be great. However a few things to be aware of. Firstly we probably want these json driven to build outside tooling that makes modifying these much simpler. Additionally there is a chance we might move to a hosted DB for pulling in this data. If that be within the Path of Terraria Online mod or within the bade mod itself. I don't think that removes the possibility but rather the implementation could change. I think if we ever do pull from a database and have it be database driven through the Path of Terraria online mod then it would have to come from there and not be possible to override, as the trading and stuff could be skewed otherwise. It will be a difficult balancing act to make it plugin-possible while also not messing with the economy.

For the red section drop rate normalization - is that strictly necessary?

I don't see an easy way to have map modifiers manipulate the amount of type x to drop without something like this. There are ways but the normalization seems the easiest.

If we report the rates to the end user in release, it'd be necessary as reporting rates that are clearly over 100% doesn't make sense.

What do you mean over 100%? It gets normalized before calculated so in the end it's not over 100%, it's just being manipulated by sources.

I also don't think we need the entire vision completed for the initial playtest, but this is VERY important aspect in ARPGs and we gotta make sure to get it right.
Itemization and drops are by far the most important things.

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

2 participants