Seeing some of the comments no wonder every month we hear about more ridiculous DRM. Especially this part:
I would change the game mechanics in not so subtle ways. Blatantly put the player into impossible situations. Retroactively modify their savegames. Make the game downright unfair. When they inevitably die/lose from the artificially induced unfairness, show them a screen telling them that the game will treat them just the way they treated the developer by pirating it.
You know what would happen?
First of all, people would come to your forums/reviews complaining about game being broken, releasing an unfinished product etc. You will blame them for piracy, but some of them will be legitimate customers who were unfairly marked as pirates. Also, you kill any chance of these people ever coming back to play/buy any of your games because they don't want to mess with a broken product.
wait, that actually works as a deterrent for pirates! too bad it deters the customers as well.
There is a 100% DRM solution that always works - release the game without any DRM. Witcher 2 did, and you don't see them complaining about piracy. Usually devs complain about piracy when the game was a broken bug-ridden piece of crap to begin with (in before world of goo omg 90% piracy - he pulled his numbers out of nowhere, you can't just compare unique IP numbers vs sold copies).
It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.
All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.
The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).
C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.
Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.
So there you have it: use D
Decent toolchain? Maybe on *nix, but on Windows, AFAIK there are no really working IDEs with full debugging support, neither there are any user-friendly debuggers. Also, there are like five different build tools, because rather than trying to find a compromise, the already scattered opensource community is making a lot of forks. Just look how many dead projects are there on dsource.org.
I like D, but without a decent, open IDE, it won't gain any momentum.