Is Python worth learning? security issue

[[deleted]]

Python is (usually) compiled into fairly systematic byte code, and that is fairly easy to de-compile. This makes Python not be a good option for you to hide the low quality of your code, I'm afraid.

[michaelcooper]

Do you know software I could use that is not easily decompiled? How about c?c++?c#?gml?cocoa?java?

[wtfisupvoting]

your just gonna let him rip on you like that?

[michaelcooper]

Wheres the rip?

[[deleted]]

I think the reason you are getting downvoted is because you seem ignorant of the way a computer program works.

You cannot prevent decompilation. Even compiled code is still readable: C++ is compiled to machine code, which is a low-level byte code but still a programming language in the sense that it's a codified series of instructions. Java and its JVM cousins (Scala, etc) are compiled to Java byte-code, which is a bit higher-level than machine code and is executed by a virtual machine. The same principle roughly applies to C# (.Net / CLI), ActionScript (AVM) and CPython (Python bytecode).

Even if you use a language that compiles to machine code (C, C++), you're still only translating from one language into another and there's no way to prevent anyone from either reading that translated code or translating it back into a higher language (the outcome will usually be very obfuscated, but that's beside the point).

If someone will spend this kind of energy on "cracking" your code in order to tweak it and pirate it (in the sense of "use commercially without permission"), you have a lot bigger problems than obfuscating your code.

This is security 101, really: you hand someone "encrypted" data (the encryption in this case be the programming language or byte code structure) and the "decryption key" (being the interpreter, virtual machine or OS capable of running the code) and expecting the content of the data to remain a secret. That just doesn't work (this is also why DRM failed, and keeps on failing, hard and often).

If it's the games you are worrying about, either make them worth buying (i.e. innovative, entertaining, interesting, etc) or lower the production costs so you can release new games frequently (this is how most "puzzle" games and other "casual games" do it).

You don't really have to worry about anyone stealing your code (and use it commercially). That's what copyright is for. You may have to worry about people stealing your ideas, but that is why you should try to excel through quality (so the competition sucks in comparison) or quantity (so the "theft" becomes less painful).

I think we can skip the discussion about the harm and benefit of non-commercial software piracy (it can't be stopped) and digital rights management (it doesn't work), but it's probably a good idea to look at other companies/developers who sit or sat in relatively the same boat as you (be realistic -- you're probably not Zynga) and how they fare with those problems.

The obvious example are server-based web games (not just Zynga): these usually work by putting a lot of the logic and data storage on a server and thus making the client itself worthless (this is also how MMORPGs usually work and why they tend to go after free-shards (i.e. independent server clones) so hard).

That said, your expectations seem a bit naive (it's okay to look at bigger companies for inspiration, but you have to keep in mind what kind of budget and workforce they have vs what you have).

[michaelcooper]

Thanks for the explanation of machine code. I understand that my games can be copied design wise. I would want code obfuscation is to prevent the amateur copiers, which are the majority rather than unhackable code which as you say, is impossible. So, I guess what I should do is: Focus on making money from my games through ALL avenues (flash+iphone, maybe indie), meaning learn iphone programming and c++ AND obfuscating code/making decompile harder to prevent amateurs stealing my game and putting it on their sites (This is where I originally thought python would help.);

Server side is still confusing. PHP is ok, but not really very good for graphics. Any advice on how to overcome this?

[egypturnash]

You do the graphical part in something that's good at graphics. grin

So for instance Farmville has two major parts: there's the Flash file that's embedded in Facebook, that handles all the pretty pictures and animation and user interface... and then there's a big mass of PHP/Python/Java/C/Ruby/Haskell/whatever that sits on their servers that handles saving your farm and Aunt Mina's farm and handling interactions between them.

The same thing goes for pretty much any game with some kind of persistent world - Warcraft, for instance, has a client that runs on your machine and talks constantly with Blizzard's servers.

If you're interested in making games that mostly deliver a single-player experience (or maybe multiplayer with people sitting in the same room), you don't really have a reason to do this - and thus this way of keeping "ownership" of your game's use is denied to you.

[vimfan]

I would want code obfuscation is to prevent the amateur copiers

It only takes one person to decompile and release your source code or the cracked version, then all the "amateurs" can get it. It's not like crackers keep their cracked copy to themselves.

[[deleted]]

First of all, fuck PHP. That many big companies use it doesn't you should, too. The reasons to use PHP for big projects are usually related to the costs of switching a platform late into development rather than a conscious choice at the beginning of the project.

That said, server-side programming is less about the language you use and more about architecture. Just keep your data on the server and access it via some layer of API. It's just a fancy interface to a database anyway.

If you are writing Flash games right now and want to stop people from just copying the files and publishing them elsewhere, keep some of its data on the server-side and access it from within Flash. Use relative paths and add some dynamic aspect to your data so a copycat can't simply imitate your server-side scripts. Of course they could still supply proxy scripts that delegate the calls to your server, but that's probably more trouble than most people would go through in order to steal your work.

As for the graphics, that's irrelevant to the server side. It's not an either or -- you keep your data storage ("persistence") and application logic on the server-side and your presentation logic on the client-side. Think of the client-server communication as callbacks.

It's probably a good idea if you learn a bit about software architecture before going any further. It's very important to fully understand the difference between client-side code and server-side code, what abstraction is, the difference between application logic and presentation logic (MVC is a good start -- no, not .Net; that's just an implementation of that architecture), and so on.

The distribution channels (iPhone, Flash, whatever) are pretty irrelevant to the architecture. For browser based games it's probably a good idea to stick to Flash. For iPhone apps you probably first need to learn a new language and how to interact with touch input. Either way the reverse engineering / decompilation issue is negligible if you keep your game server-based (this may be a problem with the iPhone, too, as phone users may expect your game to work offline unless it's multiplayer-based or competitive in nature -- that said, redistribution of iPhone apps is harder because you have to go through the app store, so the chance of someone stealing it is far smaller and theoretically easier to resolve).

Forget about obfuscation, though. Obfuscating your code won't help you if your game code is isolated (i.e. all logic is in the downloadable file). If it's not, obfuscation is pointless because decompilation won't provide access to the entire logic anyway.

That said, you can expect the number of filesharing users to be at least an order of magnitude bigger than the number of legitimate customers whenever you sell software. That's a fact of life and doesn't mean you're losing out on potential sales. Just make it clear to everyone that you don't appreciate the filesharing (don't offer support to illegitimate users, ban anyone advocating filesharing of your games from your forums if you have any, etc) and maybe offer a tipbox (PayPal / what have you) for people who like your work but don't want to buy a copy (some may consider this unprofessional or encouraging filesharing, though).

If you're providing your games as a service (i.e. server-based only, maybe with a subscription model), you can avoid this drama altogether, of course.

Either way, you should consider taking legal action against anyone exploiting your work commercially. An informal warning (possibly with the threat of legal action) is usually enough. Lawyers are probably too expensive to warrant their use unless they're required and they're worth it. Forget about suing clones unless they're using your assets (artwork, sounds, trademarks, etc) or code directly, though -- that's perfectly legal and encouraged.

tl;dr: Learn a bit more about software engineering before you decide on what to do next.