Scope economy features

[Parsonswy]

@BrokenKage

We need to decide how we're handling the internals of the economy, IE; where where are balances being stored, what are we using for shops, where do /pay commands come from, is item trading going to be a thing, etc.

If the answer to anything economy related is "use an external plugin", we'd probably need to implement Vault.

I'm thinking the answer to most of the above is we have, can, or should implement it all our selves. With all the custom items we have, I think we would encounter a lot of issues with using 3rd party plugins. Having just kicked off the GUIShop project, we'll have to see how best it would be to implement those functions in SCO. It may be worth setting up an API to run our GUIShop plugin alongside the SCO plugin, or it may be so much more involved that the /shop on PvE that we just copy paste GUIShop once it's done and build from there.

[Parsonswy]

We can probably talk about this in the weekly meeting, but putting down notes or guiding discussion topics here would be good.

[BrokenKage]

@Parsonswy
I agree. We should do the economy ourselves. However, I don’t think we should implement a GUI shop. Each floor will have their own merchants of various types that will be responsible for the shops. It would be difficult to implement the GUI shop when each merchant on each floor will have different items.

Currently the players money is stored in SCOPlayer data in two forms. Bank and wallet.
Bank: players “safe money”. They deposit money here to protect it from being stolen.
Wallet: players “risky money”. This is where merchants draw money from when shopping. However, if a player dies or is killed they lose a large percentage of this amount.

Players are responsible for transferring money between these locations.

In addition, players should/will be able to see which floors have what items. Most common place items will be available across the board, but if they require a specific resource the merchant location will be the limiting factor.

[BrokenKage]

Potential solution:
Creating a "MoneyManager" class of sorts that is initialized on player join using their saved money values. Money transfers will no longer be handled as s.withdraw() which directly edits values stored on the player. Instead s.withdraw() will go through their "MoneyManager".