Download Object

Hey guys,

I'm currently trying to figure out how I could basically timebomb a game - which means that I could limit the time a person could play a construct game - for beta tests and stuff. So we could hand out games as beta that would stop working a month or two later.

My first guess was that this could work through the download object - just put up a simple text file that the game downloads at the start of the application, if it finds it the game works - if it doesn't, it'll show a message that the beta is over.

Problem is that the download object doesn't really seem to do anything or I'm setting it up wrong - basically my events are:

At Layout Start - Download file "blabla" into folder "blabla"

If Download failed - Close application

Doesn't seem to work though. It doesn't download the file and it doesn't close the application at all.

If anyone knows a clever way to do this, I'd be happy to hear it!

You need to specify a name for the file to download into. So for example, if you wanted to download your avatar to the harddrive as "avatar.png", your "Download to file" action would look something like this:

URL: "http://www.thomasmahler.com/images/avatar_heavy.png"

Local file: "C:/avatar.png"

I hope this helps.

Fuck yeah, that works! I thought it's just about defining the folder.

Thanks!

Just to ask, wouldn't this be a bad idea for people that don't have internet 24h. Like Dial-Up or people with Capacity Limit (Like 5GB per month). It always has to download the file from the internet and if it's not working or the internet dies for maybe some hours, you can't play the game.

I thought maybe to do like looking at the date & time of the pc and see how much difference is from the actual release and now. If it's too big, it closes the app or says it's expired. Just the problem would be, you could bypass this by setting the date back and presto, it's working again.

Or if your server goes down, everyones copies of the game start disabling. If it's just for a beta run though, it doesn't matter too much, people will put up with that (paying customers won't).

Also, you might want to pick a better download destination... you might be refused write access to C:\ - or even the application's own directory - in Vista/7. Might be best to go for a temp folder.

Just remember there will be someone who is able to hack your beta. It won't be hack-proof.

Or if your server goes down, everyones copies of the game start disabling. If it's just for a beta run though, it doesn't matter too much, people will put up with that (paying customers won't).

I'm paying my provider for making sure that the server pretty much never goes down (and I haven't experienced anything like that over the last two years).

I don't believe in DRM and all that shit and I do believe in extensive Beta testing before the actual release, but that also means that I'd absolutely have to make sure that the beta is time bombed - otherwise people would just keep playing the beta instead of the final thing, cause it would reach something very close to final status at some point.

Yes, it'd be a bit annoying to have an expired copy, but as long as its free and beta, it should be fine, especially if people liked the beta and can get a final copy at the same time.

What about compiling with the date object? Past a certain date it will not run.

That's what I meant. The problem would be, people could just set the date back and they can play again.

That's what I meant. The problem would be, people could just set the date back and they can play again.

Agreed, Soon it will get too tiresome to keep playing with the date, I would rather just pay.

Then again almost any copy protection can be beat, so go with what works and spend more time making a great game than worrying about the ultimate protection.

As I final thought they can always keep downloading the trial to play. I suggest simply a demo with only 1 level or a crippled version with out a key feature or save.

Another way:

S saves encrypted, so it's hard to get values in a readable format. Given that, why not restrict the playing time? Use S to add the running time to a variable that is saved as soon as the game quits. If a certain amount exceeds, the game refuses to run, as well as refusing to run if the file is non existant.

Given that, why not restrict the playing time? Use S to add the running time to a variable that is saved as soon as the game quits.

Using S would be a great idea. I like tulamide's idea based on play time.

Another easy way (slightly less secure) to mitigate setting the clock back is to keep track of how much time has transpired since last play. Each time someone plays you take note of the absolute value of the difference between last time played and the current clock setting. This info is saved encrypted to disk (using S) and is checked next time the game is run. If someone tries to set the clock back they actually hurt themselves because the time difference will appear like they have played into the future. The way to defeat this is to constantly set the clock back just a little each time you play, but that is a lot of work.. must mean it is a great game!

Then again almost any copy protection can be beat, so go with what works and spend more time making a great game than worrying about the ultimate protection..

Yeah, you're right. We don't have to do this like Ubisoft did with their online DRM.