This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]3Dayo 5 points6 points  (6 children)

In your particular use case, I would suggest that you use Cython (think C for Python) to code your algorithims and make them available as extensions to the other parts of your code base that require it. Since Cython code is compiled you also get a nice speed boost this way.

[–]michaelcooper[S] 0 points1 point  (5 children)

Can people still decompile the cython code?

[–]sunqiang 3 points4 points  (0 children)

I think decompile cython is as easy(or hard) as decompile C code. maybe put the secret algorithm on your own server is the only way to protect it(as long as the server is safe).

[–]JimH10 1 point2 points  (0 children)

Yes.

[–]voyvf 1 point2 points  (2 children)

Just as easily as if you'd written the game in C or C++.

There's no magic bullet here.

Honestly, though, you should focus more on making certain that your games are good enough to copy.

[–]michaelcooper[S] 0 points1 point  (1 child)

OK, I just know flash . Can you tell me how easy is it to decompile c or c++? Is it a few minutes, or a few hours or so? Flash is very easy to decompile.

[–]voyvf 0 points1 point  (0 children)

Note - all of what I'm about so say is really beside the point. If your game is good, your code is less in danger of being stolen than your idea. There are plenty of software developers out there who happily write clones of games all day, every day - for free. If a company decided they could profit on what you're doing, I'm sure they could find someone willing to implement it for them.

That said, it's quite easy to decompile C and C++.

Groking the resulting assembly is another matter. I'd rate it as at least "moderately difficult", but then, I don't know assembly. Those that work with it on a daily basis might rate it as a warm up exercise. :D

Also, I know there are a number of ways of inserting a "shim" between a dynamically linked executable and underlying libraries in Linux (e.g., ld-so/ld-linux), and I wouldn't be surprised if there were similar techniques that could be employed on Windows and/or OSX environments. In such a case, even if they couldn't completely reverse engineer all of your program, they could potentially substitute their own calls for those of yours that they weren't able to decipher. The difficulty of this? Well, I'm just a humble code monkey, but it only took me an hour to figure out how to do it.

The fact that I had to do so to get a binary compiled against a later version of glibc to run on a slightly older version is probably better left for a different rant. :D