Distribution once a game is finished

Well, I am not at this point yet, but this is something that has been on my mind for a while.



So say I have a project in eclipse, its a full game and its all ready to go.



What now?



I know in C++ you can make a .exe file out of your code for distribution, but what about java?

How would I finish this part of the game development?



One part of this that really confuses me is build path. If my build path runs through 3 other java projects, does it take those extra projects and build them into my game as well? In the case of JME, JMEPhysics and GBUI, that would cause alot of extra file size.



Well, thanks for satisfying my curiosity.



Eggs~

Exactly how you choose to package your game is up to you, but this is a tool that i’ve used to wrap .exe’s.

http://launch4j.sourceforge.net/

You can choose whether to wrap everything into the .exe, or just the stuff of your liking (to make updates easier).

Also consider whether you want to obfuscate the code, if so, http://proguard.sourceforge.net/, is a good tool for that, and optimizing your code.

Could always write your own JVM launcher in C/C++ using JNI :smiley:

I used Java webstart, with my demo of a unfinished game, but I don't think it is the  most safe way. Cuz I think the game would be very easily decompiled with jad and then hacked. Am I right?

Henri said:

I used Java webstart, with my demo of a unfinished game, but I don't think it is the  most safe way. Cuz I think the game would be very easily decompiled with jad and then hacked. Am I right?

Beside obfuscation, you can also do some operations in byte-code that are not allowed in normal Java code. This means the decompiled files can not be compiled again without changes.

It is only a question of time, when your code will be hacked. It is much easier to hack a Java program than a C++ program.
But there is one thing you can do: Most crackers don't play the game they cracked. They just crack it till they can start it, maybe load the first level, but then quit the game and publish the crack. So maybe the best way is to place delayed checks in your code, that will not stop the program to work, but cripple it so it is useless/restricted.

EDIT:
That's what the developers of The Witcher, Anno, Batman ... have done.
http://www.videogame-reviews.co.uk/news/batman-exposes-bug-in-hackers-moral-code/

JackNeil said:
(...)
But there is one thing you can do: Most crackers don't play the game they cracked. They just crack it till they can start it, maybe load the first level, but then quit the game and publish the crack. So maybe the best way is to place delayed checks in your code, that will not stop the program to work, but cripple it so it is useless/restricted.
On that note, there was also a good article about this on the escapist quite recently. Did we just hijack this thread into a DRM topic? We'll see! ;D

its general discussion right? lets talk away.



so, if I say program up a nice game with networking, people would be able to reverse engineer my code and essentially "hack" my game?



This seems bad for security…

Eggsworth said:
so, if I say program up a nice game with networking, people would be able to reverse engineer my code and essentially "hack" my game?

This seems bad for security..
Yep. Like Jack said and others have said before him, having your game hacked is really inevitable. It will happen sooner or later, and probably sooner than you think depending on the game's popularity. IMO the future of successful DRM lies on server-based services (battle.net, MMOs in general etc.) and rich 3D applications played directly through your browsers, which is becoming possible with tools like O3D.

The piracy issue isn't as big as the big companies make them out to be. I don't know about statistics, but I don't know anyone who pirated a game that they were planning to buy in the first place. Connect with your fellow gamers and target audience, create a community around your game, and they will buy the game because it's cool and they're supporting an online friend in the process.