Free giveaway every 60 minutes

[Mark Spritzler]

Here is a puzzle. One I am actually implementing, so I thought it would be a good puzzle.

You have a client/server app where every 60 minutes you give away something to a user. Be it Gold or other gift. But you only want to give each player 1 per hour and no more.

You have the client which shows a countdown till the next gift and the client is where the user clicks to retrieve their gift. The user might click well past after the hour is up, and when they retrieve their gift, you want the timer to restart from 0, not give them 2-3 gifts if they retrieve the gift hours later.

You have on the server side a database where you can store anything.

What is the best algorithm, solution to make sure you know exactly when the last gift was given to make sure that they only get at most one gift in an hour, but it could be even less if they don't check every hour.

Mark

[fred rosenberger]

I'm not sure I understand the problem, because I would think you'd simply store the time you last gave a gift.

The client would ping for lastGivenTime, and the timer would count down if < 1 hour, else display "you can get your gift now".

When the user clicks the 'get gift', you give them one gift, and reset the lastGivenTime to <now>. The client pings for the new value, and starts over.

[Mark Spritzler]

fred rosenberger wrote:I'm not sure I understand the problem, because I would think you'd simply store the time you last gave a gift.

The client would ping for lastGivenTime, and the timer would count down if < 1 hour, else display "you can get your gift now".

When the user clicks the 'get gift', you give them one gift, and reset the lastGivenTime to <now>. The client pings for the new value, and starts over.

That is one possibility. But is it possible to cheat that. There is no auditing of all previous gifts. So, are you sure the timing is right?

Basically, I am trying to see if there are ways to circumvent the timer, and if so, how can you protect against it. I think that is what makes this problem a bit more interesting.

Anyone can store last time with a user, but is that really the best solution. I don't think so. I think you can store that value, however, don't rely on it as the be all end all last time they got the gift.

Mark

[Mark Spritzler]

So I think you need a db table that stores all the Free gifts given with enough fields to be able to do a query to get the last gift for a particular player. However, if that table gets large and you do the max(date) type query for a user, would that be too slow as the data got bigger?

So I think it would make sense to do some sort of combination approach. Look in the user field, but check against the audit table.

Mark

[Mark Spritzler]

Ooo. Can I add another twist.

What if the giveaway gets more in value the higher level the player gets. Nevermind that can be done in the actual giveaway code, regardless of how you make sure that one and only one gift is ever given in a 60 minute period from the last gift.

Mark

[Mark Spritzler]

fred rosenberger wrote:I'm not sure I understand the problem, because I would think you'd simply store the time you last gave a gift.

The client would ping for lastGivenTime, and the timer would count down if < 1 hour, else display "you can get your gift now".

When the user clicks the 'get gift', you give them one gift, and reset the lastGivenTime to <now>. The client pings for the new value, and starts over.

Here's where that logic fails. I have not received my first free giveaway. I login, so my timer starts. I log out in 59 minutes with one minute left till the first gift will be available. I log back in and there should be 1 minute left. But lastGivenTime is still null. Now you have to do extra work to find last login time, and use that in the calculation too.

Mark

[fred rosenberger]

Mark Spritzler wrote:Here's where that logic fails. I have not received my first free giveaway. I login, so my timer starts. I log out in 59 minutes with one minute left till the first gift will be available. I log back in and there should be 1 minute left. But lastGivenTime is still null. Now you have to do extra work to find last login time, and use that in the calculation too.

Is "extra work" a problem? How much can you do? When does it become an issue? What other constraints are there that I don't know about?

Can you initialize everyone's lastGivenTime? I.e. when I log in, if lastGivenTime is null, set it to now().

When the user logs out, can the client say 'they were logged in for x % 60 minutes', so they don't 'loose' that time?

Can the client ping the server ever 1/5/10 minutes and say "the user was logged in for another 1/5/10 minutes"? then even on an abrupt disconnect, the user would loose at most 1/5/10 minutes.

What are your priorities? is it not allowing someone to cheat? is it accuracy? minimal CPU time? smallest possible DB table?

I really just kind of throwing out random thoughts here. You've probably thought through all this already, but I do find this to be kind of fun.

[Mark Spritzler]

fred rosenberger wrote:

Mark Spritzler wrote:Here's where that logic fails. I have not received my first free giveaway. I login, so my timer starts. I log out in 59 minutes with one minute left till the first gift will be available. I log back in and there should be 1 minute left. But lastGivenTime is still null. Now you have to do extra work to find last login time, and use that in the calculation too.

I really just kind of throwing out random thoughts here. You've probably thought through all this already, but I do find this to be kind of fun.

Yeah, even though it is something real for work that I am working on, I found it fun to work through this, and why I posted it.

We figured out, for the first giveaway, they don't have to wait 60 minutes. Their first time in they can see the button active. That way the first one doesn't have to be calculated to how much time they have to wait. Then they get the first one, and all the subsequent ones are now good to find the last one given out.

Yes 100% it has to be unbreakable and not give out more than it should because people will definitely exploit it. No cheating allowed.

The other criteria was to try and make the server side not have to keep track of time for this, as for all the users would need this and having all those timers (We already have thousands of other timers running at the same time) isn't the best or needed.

We also added another interesting twist, that the general code should also work with a reward system, where you can receive gifts at any time, or an admin might reward a player on their own without a players interaction. (But there still will always be the timer) and that is the puzzle of this thread.

Mark

[Guillermo Ishi]

Mark Spritzler wrote:

Yes 100% it has to be unbreakable

The other criteria was to try and make the server side not have to keep track of time for this,

(But there still will always be the timer) and that is the puzzle of this thread.

Mark

I think if you are relying on a timer other than one on your server the prizes should not be very valuable! I think the security should be in the timer on your server. I would suggest maybe everybody could be on the same timer and so you might have to be logged in as long as 59 min. before you become eligible (in the next hour). You could display "next giveaway begins in..." A local timer is too easy to defeat, just by switching computers for example.

You mean if I click on something that says free gift I might really get something besides a virus?

[Mark Spritzler]

Guillermo Ishi wrote:

Mark Spritzler wrote:

Yes 100% it has to be unbreakable

The other criteria was to try and make the server side not have to keep track of time for this,

(But there still will always be the timer) and that is the puzzle of this thread.

Mark

I think if you are relying on a timer other than one on your server the prizes should not be very valuable! I think the security should be in the timer on your server. I would suggest maybe everybody could be on the same timer and so you might have to be logged in as long as 59 min. before you become eligible (in the next hour). You could display "next giveaway begins in..." A local timer is too easy to defeat, just by switching computers for example.

You mean if I click on something that says free gift I might really get something besides a virus?

There isn't an actual "timer" on the server side that counts down. It is time since last free chips that the player received. It is a very common thing on casino type games with chips. For instance. My Vegas ios App is one then you have to wait at least 3 hours to get your next one. But you don't have to be logged in/in the game.

Mark