Forums » Help » Game Source privacy?

Hi, Am new here and this is a question prior to purchase the engine. I would like to know if the final user gets to see the game source code. This question arises because of piracy issues.
With flash and java, you have to "encrypt" but there is always the possibility of someone stealing your media and source. That encryption is not really effective.
Upon checking the sourcecode for biolab, I do not see any code, with exception of the account number, which could be a privacy issue.

It brings another question> If I sell a game to a customer, do I have to hand him my source code? how this is handled?

Thanks.

I see the setaccount is for goggle analytics...

take a look in the source to a reference of something like game.min.js, that is the javascript that is essentially the game. Since javascript is client-side, you can have all of the source code. This code should look like a mess to you and hopefully make you not want to weed through it to pull out things you want. To combat the end-user being able to see Javascript, things are done that are usually referred as steps to 'minify' and 'obfuscate' the code.

I used Google Closure Compiler and the Bake Utility provided with impact. This takes all of your seperate beautifully coded Javascript files and packs them into one file. Various JS utiliities out there get rid of white space, rename variables to random strings, get rid of comments etc.

These also help to reduce the amount of files and filesize your browser needs to load.

BUT... That is still the entire chunk of code it takes to run whatever game you are looking at and if you are determined, you can reverse engineer it if you wanted. Would I? Hell No, it looks confusing!

That's my take on the deal.

As for your customer wanting the source code, that would be up to them and how you license it. I've actually been approached about the 2 games I've made so far with Impact on licensing them. Some companies just want their logo or brand in front of your game and you can maintain and keep it, some want the whole thing to do as they wish.

Yeah, BFresh is right on about your choices. Basically minify and obfuscate if you are concerned about someone looking at your code and stealing it. Or you can move some of the game logic to the server side. Supply some of your game data / set up info as json from the server. This way it is broken when they try and take it off your site and run it on theirs unless they figure out what the server was doing and recreate it. Plus just adds to the pain. :)

On another note ... congrats BFresh about the two offers. Dude you have to get a blog going or at least a thread. :) I'm sure I'm not the only one here who would love to hear some of your experiences with things like the ad's, the two offers you mentioned. How they heard of your games, etc... You don't have to give specifics. It's just great to hear/read about successes. I hope that continues for you. Best of luck.

Thanks guys for your useful answers.

I have been pondering that question myself for the last 6 months, and I have come to the conclusion that for cases where a lot of the functionality of the game needs/should be run on the client side, Flash is still the preferred option. While for demos and marketing purposes, or just experiments JavaScript is a good choice.

As a comment to what has been said about minifying JS-code: I have not come across a minified javascript that I wasn't able to beautify and make perfectly readable. You can use tools such as http://jsbeautifier.org/ to take a seemingly unreadable piece of code and make it perfectly readable.

I totally agree that the future of JavaScript games will include putting a lot of functionality on the server side. The average broadband connection increases every day, and requiring that you have an internet connection to play is no longer a ridiculous requirement.

I have also been approached by clients who wants to make games with JavaScript. To them I explain what it means to develop a game with JavaScript and the pitfalls it has. In the end, it is the client who has to consider how important it is for them to protect the source code.

From my point of view it all comes down to what kind of functionality can you put on the server. If most of the essential code is better of running on the client side, consider using Flash. If I'm going to spend a year developing something very special, that is also an essential part of the game, I'd like to protect that code. If I can put generic code that the average game developer would anyway know how to make, I wouldn't fear putting that code in the cloud.

all good arguments for protecting the code!

i believe the future of javascript games lies in it being open source! There's no near-future method to securely contain javascript (like Flash).

therefore, I predict the winner will be the one building open source games.

Case in point: I'm successfully selling a JavaScript game engine, even though you can get the (mostly obfuscated) source from any game out there.

So from my experience, don't worry too much about it :)

I guess you're right dominic. One shouldn't probably worry too much about it.

It doesn't really matter if one can get the source code of a game if one hasn't got the skills to turn it into a good game. And that requires experience, insight and understand of a lot more.

i find a free online javascript minifier and css minifier to compress the js and css code, so it will reduce the size of web page.