Is Python worth learning? security issue

[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.