A Million And One Ways
Disclaimer: The beautiful and treacherous thing is that there’s no one way to implement this kind of stuff. Generally speaking, it’s best to go with a technique that makes sense with how you think, agrees with the game design, and is consistent with other patterns you’ve been using.
–
@Drummermonkey01, it really depends on how many items you have, and how everything is organized. But to humor you, here’s a rough idea off the top of my head—hopefully it gives you some inspiration.
-
You need a system for creating and managing an item registry. This would be up to you to figure out what makes the most sense. The general idea would be to have a list of all your items, each with a unique ID and their appropriate details (name, price, stats, etc.)
-
Your Vendor component could have a particular inventory, essentially a Dictionary with keys that corresponding to unique item IDs, and values for current stock.
-
Your Vendor component could implement an IShopKeeper interface, which would have methods for adding/reducing stock, repairing items, etc.
-
Your Player component could implement an IVendor interface, which would have methods for buying/selling items, buying repairs, etc.
-
Your Player could also have a private float _wallet that is fetched by a read only property wallet to fetch how much money they have. (In your implementation of the IVendor interface, it could update the private instance variable _wallet in the buy, sell, repair methods.)
-
Your Shop component could handle the interface, and mediate the interaction between player and vendor.
How to lock the object from being used until the player has enough money to buy the object?
The item should know how much it costs, not the vendor. (The vendor merely knows what she has.) So when you are in the shop UI, and the user attempts to buy an item… shop calls player.buy(int itemID) for example. It’s here that you could look up the item details with the provided ID, check the cost of the item, and compare it to your wallet property.
If the item.cost < player.wallet the buy() is successful, and you can carry on with the rest of the logic: adding the item to player inventory, calling vendor.reduceStock(int itemID), saving the players progress, etc.
Otherwise, you surface some type of error message, or play a “deny” sound.
Another idea could be that your Shop checks the player.wallet when the UI opens, and you call some vendor.disable() method to dim items that they can’t afford. They could still attempt purchasing dimmed items, but of course the buy() would fail… this would be just for visual feedback up front.
How to unlock the object once the user has bought it?
Obviously once the user has bought it, they can then use it. So how would I be able to save the information that the specific user has bought it?
I think for this you just keep track of all items that the player has unlocked, perhaps a hash map of unique IDs. You can of course look into System.IO for writing data to files, so that the data is saved across sessions—not just in the game.
Good luck!