Question

This is related to preventing webform resubmission, however this time the context is a web-based RPG. After the player defeats a monster, it would drop an item. So I would want to prevent the user from hitting the back button, or keep refreshing, to ‘dupe’ the item-drop.

As item drop is frequent, using a DB to store a unique ‘drop-transaction-id’ seems infeasible to me. I am entertaining an idea below:

1. For each combat, creating an unique value based on the current date-time, user’s id and store it into DB and session. It is possible that given a userid, you can fetch the value back

2. If the value from session exists in the DB, then the ‘combat’ is valid and allow the user to access all pages relevant to combat. If it does not exist in DB, then a new combat state is started

3. When combat is over, the unique value is cleared from DB.

4. Values which is 30mins old in the DB are purged.

Any opinions, improvements, or pitfalls to this method are welcomed

Answer 1

This question is very subjective, there’s things you can do or can not do, depending on the already existing data / framework around it.

The solution you’ve provided should work, but it depends on the unique combat/loot/user data you have available.

I take it this is what you think is best? It’s what I think is best 🙂

1. Get the userID, along with a unique piece of data from that fight. Something like combat start time, combat end time, etc
2. Store it in a Database, or what ever storage system you have
3. Once you collect the loot, delete that record

That way if the that userID, and that unique fight data exists, they haven’t got their loot.

And you are right; tracking each piece of loot is too much, you’re better off temporarily storing the data.