Hi,

I am trying to determine the feesibility of using Java as my game programming "platform". I am not looking at doing 1st person or 3D. I am looking at doing card, puzzle and strategy games.

First the pros:
1. I am a Java developer by trade, so it would be my first choice, based on comfort level. I could do C++, but would have to bone up on the toolsets (graphics libs, APIs, etc).
2. My experience is that Java is "fast enough" for the types of games I plan on writing (and actually much faster).
3. Possibly shorter development time frame vs. C/C++, based on fewer development bugs and existence of many APIs.
4. Trivial to add network interfaces and threading.
5. Crossplatform. I would like to publish for win/linux/mac. By coding for the Java "platform", I may be able to do this without porting and maintaining multiple source trees. (But this may be fantasyland, when you throw in graphics rendering, audio, etc).

Now the cons:
1. Installation. I have not used the install tools on the market. How easy can I make it for potential customers to install and run my game if it is a Java application? It is easy for a technogeek like me, but what about non-techies. Does InstallShield or other 3rd party vendors solve this issue?
2. Possible difficulties with sound support and crossplatform graphics rendering.

If the installation and sound issues cannot be solved, does anyone know of languages and toolsets that allow cross compilation to win/linux/mac? I am thinking of QT, GTK+, OpenGL and Mesa? Or maybe I am totally out-to-lunch on this idea and I should just stick with supporting a single platform? :cool:

Thanks!

Well, you can't go wrong supporting just one platform, as long as it's windows. :)

However, if you can make a fun, compelling game, it doesn't really matter what language it's done in, so I'd suggest working on a game using what you know, rather than spending a bunch of time learning something else. There are some issues with Java that you'll have to work around, and those will probably eat any time saved by using a higher level language.

Installation isn't a big deal at all, I've deployed a couple java apps, so I can help you out there.

Well, you might consider making on-line Java apps for someone like Pogo (http://www.pogo.com) . Making stand-alone Java apps that your customers download to their machines means they have to install the Java VM, etc., too before they can run your games. This may discourage a fair number of sales. Also, while the Windows and Mac markets are well established, I don't know if Linux users are ready to start paying for software. :)

This is a market I've been researching quite a bit.

There is some value in games for groups like Pogo (now ea.com) or Popcap, but they are also difficult to sell to. FWIW, Pogo will typically pay roughly $40K to $60K for a quality java applet game (but don't hold me to those numbers!). Popcap doesn't pay anything up front, but they give you, I think, 50% of all sales from the Windows-native (i.e., not java, typically C/C++) version of the game. And they have fantastic reach with their games.

But as I said, both companies are difficult to sell to. Pogo has a difficult acceptance process, and Popcap has very specific things they like to see in the games (gameplay and UI) that they sell.

If you're trying to sell to either of these markets, among other things you have to restrict yourself to Java 1.1, as that's the latest VM that comes with Windows and/or the browsers (since the beginning of the year, Windows XP hasn't included any VM at all!). Trying to sell Java apps (rather than applets) is not likely to work: it's roughly the same as trying to sell a game that requires DX8. You can do it, but some large majority of people who might otherwise have bought your game will stop short when they realize they have to download a huge library to make it run. (This is the same thing holding back games written in C# btw - this requires a huge .NET download.)

Overall, I think Pogo, Popcap, et al, have a good model -- one form of the "trialware" model. They let you play the game online via the java applet, but then sell you a version you can play on your computer offline (exe), often with bonus features or at least a lack of nagging and/or delay screens.

Yes, it seems the Linux market is definitely not ready to buy games (or much else for that matter). As far as Java, the stand alone runtime is large (several MB, isn't it?). That will hurt sales. Additionally, for browser based apps, I understand that (due to the lawsuit settlement) Microsoft is no longer shipping the Java VM with Windows, requiring the user to download it separately. That can't be a good thing.

It's funny the whole Java VM issue was brought up.

Sun just won a suit where Microsoft must carry Sun's VM for windows. Those not in the loop can read about it here: http://www.reuters.com under the tech section.

Aha, at last, something I can comment on!

I've been using Java for several years now, and about two years ago decided it would make a good game development language, for the usual reasons. Now it's at version 1.4 it's got the speed it needs thanks to direct memory access.

However, it makes a very, very, crap game platform.

Here are the issues:

1) Rendering bugs in AWT. Inexplicably the AWT is still buggy. Inexplicably they can't get fullscreen working under Linux. Inexplicably there are issues with crashing. Inexplicably there are still major issues with rendering performance, although for your kinds of games, this is unlikely to worry you much.

2) Runtime deployment. Currently a minimum of around 10Mb download for a proper VM, hardly anyone can be bothered to download it. This is Sun's fault, largely, not MS's, but don't bother bitching about it because it won't get you anywhere.

3) Misinformation available on the net. There's plenty of people telling you how do to things in all sorts of clever ways, and the truth of the matter is that most of these people don't really know what they're talking about. Be very careful about taking any advice about how to write it! Including from me :)

4) No hires timer. Without a hires timer in Java, you can't reliably time animation of any kind, period.

Here's how I've solved these issues:

1) I designed the Lightweight Java Game Library (http://java-game-lib.sourceforge.net/). This is a cross-platform library designed to turn a machine into a games console, more or less. It gives you direct access to OpenGL, OpenAL, mouse, keyboard, joystick, gamepad, memory, and some batch vector processing for fast 3D (again, not your problem). It has no AWT code in it, so you can compile with Jet to a single executable. The .dll itself is very small. It still requires Java 1.4 to work. Using LWJGL I get games performance that is indistinguishable from C++, as all the hard work is done by hardware, as it should be. I also get proper reliable cross-platform capability. Yes, it works on Linux! The Mac port should be ready as soon as the Mac port of 1.4 goes into beta as well.

2) I'm solving this particular dilemma myself by using Jet to do a native compile on Win32. You could try GCJ if you're skint. This has also meant removing any dependence on the java.awt package from my code, and also means I get faster code. Yes, Jet is faster than Sun's VMs, and will probably remain ahead for a few more years. Fine by me!

3) I've spent two years just finding out everything and anything about Java gaming. The route I've gone down is to hell with Sun and anyone else's advice - think what is actually happening deep in the bowels of the machine and figure out why it works. In particular, avoid threads, object creation in a rendering loop, and alpha transparancy tricks. In fact, don't touch threads or object creation in your rendering loop. (And watch as a swarm of Java developers come in to argue with this point of view and make you believe otherwise).

4) Well, what do you know, there's a hires timer in LWJGL too... not that it matters because generally it's for running games fullscreen and we sync to vertical refresh.

I'm writing a development diary down at Java Gaming Online (http://www.javagaming.org/) which is an excellent resource and you can come along and watch me argue with everyone else.

Cas :)

To me, sun just looks like a big baby over this whole issue. They complained about Microsoft extending java to support Windows specific behavior (I thought making extensions to Java was encouraged) and because it wasn't compatable with the Sun implementation (even though the MS implementation was more compliant with the spec than Sun's own VM...go figure). So they sued and said "make yourself compliant or terminate the license". Microsoft chose terminate. Sun got exactly what it asked for. Sun realized they backed themselves into a corner. They threw out an option that they never thought Microsoft would bite at. Now they are SOL, so they go back to court to force Micriosoft to do something different. Ship the Sun VM (which, coincidentally is quite slow compared to the MS one).

So now, of course, MS is stuck shipping a pitifully out of date version of the JavaVM (1.1.4). Sun said they may let microsoft use newer versions of the VM in the future, but as far as I know the settlement was not worded to say Microsoft MUST accept these newer versions. I'm convinced if Microsoft doesn't accept the newer versions, Sun will take them back to court to force them to.

:rolleyes:

princec,


I designed the Lightweight Java Game Library.


This looks promising. I will check it out. This is the info I was looking for. Are there any games available that have been written on for the LWJGL? I would like to check them out on both Linux and Win.


I'm solving this particular dilemma myself by using Jet to do a native compile on Win32. You could try GCJ if you're skint. This has also meant removing any dependence on the java.awt package from my code,

Are you saying that AWT is NOT compatible with JET and/or GCJ? I haven't used either but thought these might offer a solution to my problem of trying to avoid distributing JAR files and JVM's. Also, what is skint?

Have you looked into the Eclipse SDK? It is an alternative to Swing/AWT.

Thanks for the insight and pointers! :)

No games yet! We're still only in alpha but it's probably going to be beta shortly because we can't think of anything more crucial to do to it. There was a game on the Ludum Dare site called Countersheep by OrangyTang which he knocked up in 48hrs. And my game's coming on pretty fast.

AWT is compatible with everything but Sun's license isn't. Even if you compile your code down to an executable, you still have to ship it with the entire JRE if you use AWT in any way because you are not allowed to ship just the AWT .dlls that Sun have written. Excelsior don't seem to want to write their own AWT implementation, and that's fair enough because it's a bit fiddly. I've avoided the issue by simply not using a bean of code from AWT. (There is a similar restriction with Java Sound as well - in fact, any of the Sun .dlls - but the Jet guys have reimplemented most of them).

I use Eclipse as my IDE, but SWT's not exactly what I need and I believe it may still depend on AWT underneath although I don't really know for sure. I render all my GUIs in realtime using OpenGL and my own lightweight framework and that's fine.

Oh, and I keep getting asked about "skint" - I didn't realise it was only known in England :) It means "to have no money"! Er, like me.

Cas :)

Darn right Lord Kronos.

Same thing goes for the State's antitrust lawsuits against Microsoft. They finally settled, Microsoft can't give special pricing to it's partners, it has to allow them to ship icons on the desktop, and it has to expose the API for windows media player. That barely registers as a slap on the wrist. Sure it might make the other civil lawsuits a little easier to get a settlement for but Microsoft has more then enough money to handle that.

One has to ask if the states representing aol time warner, and Sun Microsystems had spent 5 years and millions of dollars on innovation as opposed to litigation they might have actually had more of an impact on Microsoft. The only real winners out of the whole thing were the lawyers on both sides, man lawyers really can make a lot of money off stupid people.