+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Plugins (https://forum.cuberite.org/forum-1.html)
+--- Forum: Plugin Discussion (https://forum.cuberite.org/forum-8.html)
+--- Thread: Coiny refresh (/thread-1608.html)
Coiny refresh - xoft - 10-04-2014
I think it's about time we had a proper look at the Coiny plugin and updated it to the latest standards. I'd like to first throw a few ideas around and see what the discussion brings.
What's needed:
- Remove dependency on Handy (done)
- Use UUIDs instead of names
- Use SQL-backed storage instead of INI (SQLite, most likely)
- Rewrite command handlers for Info.lua scheme (done)
- Proper documented inter-plugin API
So, what are the basic requirements for such a plugin?
- store, for each player, the amount of virtual currency that the player has.
- allow players to query their balance.
- allow players to exchange that currency directly, using a command.
- allow an admin to add or remove currency from any player's account.
- provide a webadmin interface for the admin to simplify the administration.
- provide an API for other plugins to interface with the accounts.
Account storage is pretty straightforward - a SQLite file with a table, storing each player's account balance. Additionally, there could be another table storing the past transactions for the players; these would be only for information purposes and won't take part in any balance calculation. In order to simplify things, let's decide to store only integral amounts (only dollars, no cents).
Querying balance and exchanging currency directly via a command is rather easy - a set of commands that query the DB and do basic transfers. The transfer would use simple SQLite transactions to provide basic safety for the transfers.
Admin would be able to give or take money from any player by using an in-game command, or the webadmin interface. Both are pretty easy to do; for the webadmin the account storage will need to provide a list of all accounts as well.
The API for plugins is somewhat problematic in regards to transaction safety. There's just no way to implement a general safety (in terms of "money isn't paid until goods are delivered; goods aren't delivered until money is paid"). We can only approximate such safety and put some of the burden on developers of the interfacing plugins. This is mostly because a true transaction safety would need to be able to rollback all changes if anything breaks before committing the transaction, but there's just no general way to rollback goods delivery if the goods is provided by a different plugin. This however only presents problems if the interfacing plugins are broken, so this shouldn't pose a serious risk.
The API functions needed are simple: Give, Take and Transfer.
Additional ideas:
- virtual accounts
- webadmin API
Virtual accounts are used to keep track of server-provided goodies. Imagine this simple scenario: The server offers players the ability to buy a diamond for a price. Each time the player buys a diamond, the money is taken from their account - and it vanishes, there's no real transaction to keep track of, the admin cannot look at how many diamonds were bought, etc. Now imagine the plugin allowed virtual accounts. There would be such a virtual account for "buying diamonds from the server"; every time a player buys a diamond, the currency is *transferred* to that account (and stays there). Now, the admin can view all transactions for that account, do all kinds of statistics etc. Sounds good?
Webadmin API can be used to automate systems that link real-world money transfers to virtual currency. Most larger servers allow "buying" some form of credits using real money. The payment processing can then make an API call to webadmin (using a special webadmin username just for that) and the payment will be automatically processed by Coiny. This would require a few changes on the webadmin side in MCServer itself - allow permissions for individual webadmin accounts etc., but generally it's doable.
RE: Coiny refresh - xoft - 10-08-2014
I decided to change the DB structure. Instead of having the account balance as the primary and the transactions as supplemental information, I decided to make the transactions table the primary, and drop the balance table altogether. This makes the implementation a bit simpler. It could mean that for players with large payment history things could get a bit slow; we'll see how it fares, it shouldn't be a problem.
RE: Coiny refresh - xoft - 10-08-2014
Still bad. An even better solution would be to store each transaction as two records - for the src account and for the dst account. This way we could later on compress the old transactions - replace the oldest N hundred transactions for an account with a single transaction, "balance transfer" and thus the number of transactions that comprise a single account's balance would be kept in reasonable numbers. It would even make counting the balance easier, as it would be a single query, as opposed to the previous system that needs two queries (sum(amount) for incoming minus sum(amount) for outgoing). Each money transfer would effectively become two transaction records - one for the src account, the other for the dst account; the amount in one being negative of the amount in the other.
Why do I feel so dumb for not coming up with this natural system earlier?
RE: Coiny refresh - tigerw - 10-08-2014
Quote:Why do I feel so dumb for not coming up with this natural system earlier?
Don't feel dumb.
But if you want to know why you feel dumb for not coming up with this system earlier, perhaps it's because you didn't come up with the system earlier? You posed a sort of self-answering rhetorical question
Or maybe you are referring to the chemical processes inside your brain that trigger you to feel 'dumb', and why and how they activate when you experience something suitably 'dumbing'?
RE: Coiny refresh - xoft - 10-08-2014
Twisted big cat humor
RE: Coiny refresh - tigerw - 10-09-2014
:D
+5 characters.