I work in software development. And I am often surprised at the awesome content that game companies come up with. But also conversely mystified about how certain bugs will show up. For instance I was puzzled over the history of the grinder. What kinds of grinds it supported or didn’t at first and then later added and why.
If I implemented something like it would likely just be in a SQL table or an equivalent data structure for games. It could be implemented multiple ways. The columns could be something like, itemtype1, itemtype2, itemtype3, rarity1, rarity2, rarity3, potential_output_rarity, potential_output_type, percent_chance.
When the user puts items in the grinder, the game would run a check against my table to see if any rows match based on the first 6 columns. The downside of this method is that you might have to store extra rows to know whether a pistol, a sniper, and a shotgun is a valid recipe vs a pistol, a SHOTGUN, and a SNIPER (items are in a different order). So, maybe the data structure would have to be something smarter like a many to many to many relationship. Or maybe the code that is checking has to be smart enough to seek the data table 6 different ways based on the input types. Like below:
abc
acb
bac
bca
cab
cba
That can probably be simplified by sorting the types before checking them and storing your data alphabetically.
So, then it finds matching rows and says it’s a valid grind. The user grinds it next and then you look at all the rows brought back and determine randomly which output row to use based on the percentage chances. Moonstone grinding would influence this of course.
Another method is strictly code. Which sounds messier in some ways, but in other ways cleaner/easier to use/manipulate.
Code version would look have a bunch of IF then Else statements or case statements to narrow down the possible results of the grind and whether the grind is possible and how much it costs.
edit: I feel I got off topic… My point is, I think the game wasn’t cheaply made or cutting tons of shortcuts.
