Sign In Register

How can we help you today?

Start a new topic
Answered

Any advantage/disadvantage to using currency, virtual good or home-grown runtime collection for XP?

So up to this point, been storing player XP in a custom runtime collection along with a slew of other player related fields.

Any particular reason why I should (or should not) switch to using one of the 6 currencies or even a virtual good to track XP - other than the convenience functions allowing easy credit/debit/balance/hasVGood/useVGood?  

Near as I can tell, the values are simply stored in the system Player collection (much as my current XP is stored in my custom runtime collection).

Thanks in advance!


Best Answer

Hey Jeff


The main benefit of storing it in the currency field would be that a transaction history record would be created for each change. Whether this is important to you or not I don't know.


The other benefit (which you could code around if you wanted to) is the atomicity. The currency debits and credits are atomic, and will not be skewed with multi-threaded access.


I hope that helps !




Answer

Hey Jeff


The main benefit of storing it in the currency field would be that a transaction history record would be created for each change. Whether this is important to you or not I don't know.


The other benefit (which you could code around if you wanted to) is the atomicity. The currency debits and credits are atomic, and will not be skewed with multi-threaded access.


I hope that helps !



Thanks for the reply - follow-up - I assume the atomicity is obtained by virtue of using mongodb $inc or some such mechanism - but one of the issues I came across was the 'zero balance' concept.  Player has 18 of a particular currency or virtual goods count - I want to debit 20, and if they don't have enough, make it zero.  While I can simply detect if the debit/useVGood fails (for lack of available balance), and then debit the current balance (by reading the balance first).  In such a multi-step process, concurrency rears its ugly head and another process could easily have jumped in and changed the balance and I end up with screwy results.  The issue is not solved by using my own custom collection - as I have to essentially execute the same number of steps.  I don't know if the issue is solved by built-in mongodb optimistic locking - but I doubt it.  Any thoughts?  Can/should I use a mutex-type lock with lockKey() (maybe with a key value of player id or a hash of player and currency type) to block others from accessing until group of activities are complete - thereby creating a transaction (or at least a sense of atomicity)?  Thanks in advance!!

bump

SparkPlayer.debit() will atomically validate the amount you want to debit is greater (or equal ) the the current balance using $inc and a query.


You could do mutex locking using Spark.lockKey, but given the above it is probably simpler to loop by a decrementing around the debit.


It depends on the concurrency of change on a player though, there is an overhead to locking that would be avoided for most calls if this is not common.

Login to post a comment