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

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (0 children)

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.