i saw this subject mentioned alot,
and i know i have great interest in the subject myself...

Artifact's (http://www.samugames.com/artifact/) "protection" is simple: It's a client-server game, with all payment information kept on the server. About as close to perfect protection as you're ever going to get.

There is a lot of non-game software that is going that route. I know my QuickBooks 2000 insisted on accessing the Internet periodically even 3 years ago.

-David

for the ppl who voted for other mechanisms,
what protection scheme did u use?

This article (http://www.ambrosiasw.com/webboard/Forum14/HTML/000052.html) was written about a year ago by one of the developers of long-time Macintosh shareware producer and publisher, Ambrosia (http://www.ambrosiasw.com/).

This and several other articles I have come across over time, make me believe that crippling is a good thing. Also, time-based license keys are good. Perhaps even hardware-based keys...

But trying to prevent hardcore crackers from getting ahold of your game is like keeping the ants off the potato salad at the company picnic.

Your best bet (IMHO) is to spend your time and energy on real features. If you have the money, I'd also recommend buying a toolkit to do your licensing with (Kagi? RegSoft?).

-daniel

We send a secret url + a registration code based on user's name.

This has some pro and cons:
+ demos are smaller to download

- some people want to play immediately and get frustrated because they have to redownload a file.

pat.

I voted for "I don't protect it at all, i give the full version upon payment", although I think holding onto the full version until payment is a form of protection. Originally, I used a reg key (based on user's name) along with this separate full version download. However, after going with this for a while, I decided to give my dad a copy of the game and see how he liked it. I think of my dad as my target audience...casual computer user, likes computers for the novelty (emailing friends, creating holiday and birthday cards, download and playing games, etc) and all that.

After sending him the reg key (which wasn't very complex) he emailed me back saying he could not get it to work. I downloaded the same version he had, tried the key, and it worked perfectly. I reconfirmed the key with him, and he still couldn't get it to work. I don't know what it was he was doing, whether it was switching a 0 with an O or adding spaces or whatever, but he was having difficulties. I then realized that if he is my target audience, this is not what I want to burden him with, so I removed the key requirement.

Ron,

I use registration keys with The Journal (http://www.davidrm.com/thejournal/). I used to get complaints like that. I've learned over time, though, to:

1. Provide instructions on how to enter the keys.

"The Registration Keys are case-sensitive, so they must be entered exactly as shown. The easiest way to do this is using the Windows copy-and-paste method to copy the key values from this email and into the correct fields in The Journal."

2. Support about as many ways as possible of entering the keys:

a. As instructed.
b. Copying one key at a time to the clipboard.
c. Copying both keys at once to the clipboard (a recent change).
d. With "Key 1:" and "Key 2:" as part of the keys, and without them.
e. All uppercase (the "correct" way) as well as all lowercase, or mixed.

I'm sure, over the next few years, I'll discover a few more ways that users can attempt to enter the keys, and I'll learn to adapt to them.

-David

Thanks for sharing your experience, David.

I was fighting the same problem for the last 7 months. I had deliberately made my keys too long to be entered by hand. I thought this would prevent typos and other mistakes when people enter keys symbol by symbol. Sure I'd provided them with the most detailed instructions on how to copy the key. Nevertheless, I had a lot of problems with people unable to register.

This is what I've learned:

1. The registration instructions should balance between details and simplicity.
2. The program should display a simple but prompt diagnostic message if the user do something wrong (like pasting part of the key, pasting anything but the key, etc.). So the users can often figure out the way to install the key by their own.
3. The algorithm analyzing the pasted data should be very flexible. It should accept keys pasted with leading and trailing spaces on each line, keys pasted from forwarded emails, keys interlaced with empty lines and so on. In general, you should make it as flexible and robust as possible. It will save you much more time than you will spend improving it.

I am pretty sure there are many other ways for improvement though. I just need to find them yet.