Time Limiting a Game

Newbie & Debugging Questions
#1

I’d like to do something about making TakeDown a shareware game. As mentioned by Onyx, it’d be good to offer the game as say an hour’s demo before having to register. To me, this has two issues, one I think I have beat, and one I can’t work out.

  1. Where do you store how long the player has played for and hence limit to an hour?

  2. If you store it locally how do you prevent people just copying it around, or worse zipping up a registered version and providing it on the web?

I think point 2 can be solved by making the registration information contain the name and email address of the person registering (as extracted from their credit card). You display this in game so that for any given registered copy the name of the owner can be seen.

However, I’m stuck with Point 1, in my windows days I would have just stuck it in the registry but I’m not really sure thats a good idea from java. What’s more, where does it go on Linux/MacOS?

I assume you commercial folks out there have solved this one a million times, go on, let me know?

Kev

#2

You could be really sneaky and hide it INSIDE your game jar. Or put it in any data file, like hidden in a file that serves as a local high score list… If they want to reset the timeout, they lose their high scores too. Save file modification times of the high score list in other data files, so you can detect when someone tries to copy over the file to reset the timeout… ultimately it comes back to the fact that any software copy protection is prone to hacking.

#3

Hm. That’s a tricky question.

With webstart you could use muffins… that would be good enough to stop non-techy people. You could do pretty neat A/B tests then with different demo lengths (30, 60, 90 and 120 mins or unlimted time and only 10, 20, 30 starts) and after a while you just pick the one which converts best.

But MoleBox-ed… I wonder… well, you could of course use the registry there or that pricy wrapper thingy (forgot the name duh).

Well, I would say… at the beginning you need a MoleBox version for windows and webstart for everything else. Then a webstart free version for mac (by that time you should have pretty good crippling parameters) and since linux is pretty weak (~1% of the sales) you won’t need anything special there.

Unfortunately I can’t give you less fuzzy advices, because I’m not really experienced in that area myself.

#4

Hi I’ve never done any thing like this, but what about adding an ecrypted date to the download. The game decrypts the date and then tests, if the system time is between that time and maybe that time + 1 hour. This would you leave simply with a timezone problem. To overcome that you could also let the server generate the date during the installation process. This way the client would have to reinstall the game over and over or would have to reset the timer (he would have to do it every hour, because the time has to be in the interval). Here’s my idea for doing this in the installation process:

Installation
Client: sends date to server
Server: encrypts date
sends encrypted date back to client
Client: saves encrypted date

Game Execution
Client: date gets decrypted
time interval gets checked

for ecryption/decryption you could use RSA and the server contains the private key and the client only contains the public key. This way no user is able to fake dates(he doesn’t know the encryption key) and you can controll whom you give encrypted dates (e.g. if the same IP is requesting dates over and over)

So what do you think?

Arne

#5

Lovely, but my use might well not be connected.

Kev

#6

There’s no way to defeat the determined hacker. Calls to methods to check validity are easily commented out. Code that decrypts other code on the fly is harder, because the validity check can be in the encrypted code. However the loader has to have the key embedded in it, and therefore is vulnerable. Makes it a lot of work to break in though.

Regarding the validity check itself. How about 31 different versions of the game, each of which only runs on one day a month. To download the game, the user must provide a valid email address, to which is posted a dynamic download link to the current days game. You could check for duplicate emails to prevent someone downloading a new version every day. Of course the determined could obtain all 31 and distribute them as a set, but this could get to be quite a big install.

Obviously the savvy user could keep resetting their system clock, so this would not prevent the detemined. If the game is signed, maybe it could check the last modified date of the hiscore data file & refuse to run if it is later than the current system time. Gradually the timestamp of the hiscore file would move into the next day.

Overall, there is no really good solution, just lots of bad ones :wink:

#7

Maybe linux sales are so weak because linux users pirate more than others? :wink: In that case perhaps the linux market is even more important to protect against!

#8

I never quite liked the concept of limiting the time in which a game can be played - it seems unnatural, since it must somehow be possible to flush the information, and so you would have to sneak around on the user’s system to do it. The proper way, in my opinion, is to limit the game content such that the user only has access to part of the game. This hurts playability somewhat, of course, but you won’t have anything to hide then.

#9

Even if I limit game functionality, I’d still want the user to be able to unlock the extra functionality. I’d still have to store something somewhere to indicate this was a registered version of the game?

Or is there some clever way of doing this?

Kev

#10

No… it’s more like there aren’t many linux users, most of em don’t play games (or casual games) and then are also those linux user who don’t want to pay for software ever again. That doesn’t mean that they will pirate it, but they will complain about the price (even if they never intended to buy it either way).

If supporting linux was actually real work it would be a complete waste of time. (from the business pov)

Well, it’s just like that (and it’s not my fault - mind you).

Each game is different. If you have lots of content, you can limit that. Say… a platformer with 50 levels and the demo version has only 5. But you can’t do something like that with (most of the) puzzle games, because you get almost everything there is up front. If there is no reason to buy it, why should someone do that? Well, yea… some people will do that, but it won’t be many. It would be like donation ware.

So, if your visitors are generally like those you can see on the big portals, a time limited demo will convert very well (in this case). A demo which is limited by the amout of runs might even work better… but that’s a thing you have to test.

#11

You quite often see vendors provide an unlock code based on a user name. You have to type your name and the unlock code into the software to make it work. This deters casual copying, since both name and code would have to be distributed, but the doesn’t prevent the check code from being removed from the software. It also doesn’t help if false user information was supplied in the first place (e.g. a stolen credit card). Console manufacturers face the same problem and attempt to solve it by encryption. The decrypt key is buried in a chip in the hardware. People have sliced off the tops of such chips & determined the key by examination. You can make it difficult to remove validity checks by encrypting your software, but since you don’t have the benefit of a hardware decryptor, the key would be in plain site in the loader. There is no silver bullet.

#12

Yes, look at Doom. I’m not being facetious - this is the model used for solving these problems: you don’t download to the user’s machine that which they don’t have access to. Everything else is - as clear from the above conversation - complex and time consuming either for you, the player, or both.

Either they have the registered WAD file or the shareware WAD file (in Doom parlance).

Think about the ways in which someone can contravene this (basic threat-modelling): essentially, the only way people will easily be able to pirate is if BOTH people are distributing full versions of the game on the net, AND these distribution points are sufficiently common/large that people can find them. So, the main threat to your game is that it becomes so popular that lots of people know about it and it is easy to find a full version for illegal download - but that can only happen by catapulting your game into the limelight. Which is likely to mean you’re making a lot more money anyway, or at lesat that it’s now easy for YOU to find and shutdown illegal distribution points.

Why did Doom make so much money? Obviosuly, a large part of it was simply because everyone showed or gave it to their friends…many of whom later bought it anyway rather than go through the hassle of finding another pirate copy when they changed PC, changed job, etc.

Finally…IMHO, time-lmited games are a damn good reason never to play a game from that company again. They really really piss me off. For instance, I played AF for a while on my mother’s PC (wasn’t running properly on linux at the time), and then when I wanted to show her, because I thought she might like it enough to buy it … THE ***ING THING WOULDN’T LET HER PLAY. Shrug. Whilst I fully appreciate the need to increase conversion rates, stuff like this severely pisses people off. Small games are dependent upon viral marketing, and the first rule of VM is “don’t piss-off your consumers” - so I would argue () that the long-term negative effects of time-limited games outweigh the increased conversion rates.

(*) - I’ve never sold my own shareware (although used to sell other people’s, many years ago), so I can’t argue based on personal experience and stats. OTOH, I know a lot about VM; that’s the perspective from which I’m coming.

#13

At what point does the fact that, “people who want to pay for it will pay for it, those who don’t never will.” No matter what the registeration method.

Do you reach a point where you make it difficult for those who to pay? I would assume this is a fine line: just enough “locking” to get those who want to pay’s money for more. You’ll never be able to lock it down in such a way as to keep people from hacking it for free (but those people would have never given you their money anyways).

Princec probably knows more about this than I do as I’ve never done any shareware. Just seems like a balancing act to me, don’t want to turn away those that have money in their hand.

#14

I bought Puppytron for three reasons:
1 - I found myself wasting a lot of spare moments with it
2 - I got tired of having to reload the whole thing to play a new game. (After the inital plays of the demo period expired, it would only let you play one game per launch. I thought that was plenty fair.)
3 - it was cheap

Alien Flux followed a Doom-like model. Full access to the first couple levels… I liked it and wanted to play more.

#15

At first I didn’t think the Doom Model gave any benefits over using a registration code. However on reflection, it does reduce the incentive to hack the code significantly.

  • With a registration code system, the ‘reward’ for removing the validity check is being able to play the full game.
  • With the download the full game model, the prospective hacker must have already coughed up for the game and doesn’t get any personal gain in hacking it, only the ‘joy’ of providing it too others. A much lesser motivation.

Alan

#16

Yes, much better: it doesn’t actively lock you out, preventing you from even trying the thing any more, it just gives you incentives and irritation that make you want to purchase it.

The massive problem with time-limiting is that, really, the author is shooting themself in the head: if the player hasn’t registered already, there’s a high chance they haven’t decided they want to yet - and YOU have just told them to piss off and stop playing the game; if they’re undecided, you’ve just made it damn hard for your game to finish persuading them to buy!

Although AF sometimes followed that model, I believe it didn’t always do so: as in the example I gave, at least one version locked you out permanently so you couldn’t even try to play it any more. Cas is known for massively changing his model from version to version :wink: (witness SuperElvis, now completely emasculated - it’s IMHO dull and unpleasant to play now, and I was rather embarassed after trying to show it to a friend; it just looks crap and boring, where originally it was ass-kicking).

#17

Just once, I’d really like answer. :slight_smile:

I’ve pretty much decided that my game doesn’t suit unlocking further features, its fun to play, cause its fun to play… not because there are tons of additional features. It doesn’t suit adding loads of added bonuses that really don’t add anything to the game. I as I see it I have thread options:

  1. Give the game away for free (most probable, hoping for a job with a company somewhere)
  2. Give the game away for free, ask for donations
  3. Time limit the game, and ask for payment for additonal play.

It seems that plimus.com has some method of supporting registration codes that are node locked. I’d like to understand my options for time limiting a game or at least how their managing it before using them.

Kev

#18

Applying hard logic to the stated problem.

  • To provide a time limit it is necessary to keep a non-volatile record of the time played so far.
  • If this must work off line, then it must be stored locally
  • If cross-platform operation is required then:
    – EITHER the persistant storage must be directly supported by java
    – OR you have to write native code to store the data in a platform specific manner.

The native code route would allow you to use things like the windows registry, but there isn’t an equivalent for linux/mac, which use configuration files. So limited benefit really.

That really leaves storing the information in a file. The most obvious location for this is in a subdirectory of ‘user.dir’. If you start the directory with a period ‘.’ it will not show up with a normal ‘ls’ on unix. This is really a curtesy to the user rather than any real security. I can’t see any api to set the hidden bit on windows systems; maybe worth considering native code; again really just to declutter the ‘Documents & Settings’ directory.

When the program runs, it should check for the presence of the file. If it is absent, I suggest the program should check the date last modified on it’s own jar. If this is more than a day or two old, it is likely that the user has deleted the data file in an attempt to gain more player time, and the game should refuse to run. If the file exists, but the time limit has been reached, then the program should refuse to run. Otherwise play and update the file accordingly. The file should contain a checksum as a simple anti-tamper measure.

Obviously this doesn’t defeat a canny user who deletes the game files AND the data files, then reinstalls.

So all rather obvious and no magic super secure solution (but hopefully on topic this time)

Alan :wink:

#19

As terrible as it is, I’m thinking that I’m going to provide a licensing solution for windows, then let linux and macos run free (but ensure thats the only platforms they run on).

Shame there isn’t something a little more tucked away like the registry on Windows and MacOS.

Apologies for the arrogant post above, was a litlte drunk. I do appreciate any responses and even the conversations at a tangent.

Kev

#20

[quote=“kevglass,post:19,topic:23677”]
There is!

On Mac OSX there is the “defaults” system… very much like the registry. Type ‘man defaults’ in the terminal for the info.
You can get at this info using execute(“defaults”…)