Write once, run anywhere --- with Java games?

I’m curious if anyone is willing to share their experiences with the areas of pain while trying to make sure that their Java games ran correctly across platforms, such as Mac OS, Linux, and Windows XP? What kind of compromises needed to be made, if any?

Also, are there any statistics to show what platform is used most to run Java games?

I’m curious about the same thing. My main reason for starting to learn Java was platform independence, but is it always a sure thing they’ll run the same? For me, testing Windows and Linux is no problem (I regularly use both) but I can’t test OS X. .JARs can be executed from all platforms, right? Why have I seen download pages for Java games with links for Windows, Linux, and OS X? I guess it could be the format in which they’re packaged in (.rar, .tar.bz2, etc) still…

We’ve successfully been doing it for the last 3 years (well, mostly succesfully ;))

A few things of note:

  1. We never really took the Linux option seriously; for the size of the market it just isn’t worth our while. We do support Linux but only in the sense that we make Webstartable versions of our games. That mostly work :wink:

  2. Beware endianness issues on the Mac. It’s not that your code isn’t cross-platform, it’s just that you forget to account for this minor fact. Normally it manifests itself in the form of white noise for sound effects

  3. Using LWJGL we minimised the differences between the three platforms and provided a pretty stable, simple abstraction for all three environments. J2SE itself varies wildly on the three platforms due to bugs and idiosyncrasies in AWT (mostly to do with high-performance rendering rather than GUI code). For instance, true fullscreen mode has only recently been available on Linux in AWT but we’ve had it for 4 years with LWJGL.

  4. Also beware where you write files to. Each platform has slightly different conventions for “application data” and “user data” which Java has not yet abstracted.

  5. Deployment on Windows: you are expected to provide a self-extracting executable installer. If you do not, you will fare poorly. I for one rarely bother with unzipping files; others generally feel the same way.

  6. Deployment on Mac OS X: you are expected to provide a .dmg or a .zip; double clicking a .zip with a .app in it is something Mac users are used to. I don’t actually know how to write an installer for Mac so I’ve never tried it. The launcher in a .app file is some bit of native wizardry found in the SDK. Take a look at one of our games to see an example and try tweaking the contents.

  7. Get your icons right.

  8. There are some differences in the way each OS handles thread scheduling and latency; do not rely on the behaviour of threads to do anything other than what they were designed to do, which is to execute code when some other thread is doing IO. In practise this means you won’t really be using much by way of multiple threading in client code.

  9. We’re stuck using JDK1.4.2 because that’s what a large proportion of working Macs still uses (and targeting 500MHz PPC CPUs for performance, too). Next year we’ll consider moving to JDK1.5 if our stats tell us <5% of Macs are using 1.4.2.

Probably lots more I could say on the subject but that’ll be enough to get you asking more questions eh?

Cas :slight_smile:

NB: If you planned to use AWT you must take care of windows and window components apparence checkbox,dropdownlist,textinput… all are platform dependant and can have different size/layout.

I’ve never used AWT, and only used Swing on Windows, so is Swing the same way?

Also, for games, what’s better to use for menus and the like; AWT or Swing? I like Swing, but since I’ve started using Eclipse and can’t find a good WYSIWYG Swing editor plugin, I’m up for either. Unless importing a project started in NetBeans isn’t hard. I really hate how NetBeans generates all sorts of stuff right in the beginning though…

I think that Swing is not platform dependent, as its first goal for me was to remove the platform dependancie of AWT between platform.

You may also use your own GUI API wich is sometime less difficult to do than it seems. I guess you can also found good one over the net, dont really know about that.

It is not fair. You do exactly what Microsoft expects. I disapprove it. You shouldn’t punish Linux users. I hate Microsoft but I have tested my game under Mac OS, Linux and Windows. If the developers wrote more games for Linux, more Linux users would be interested in playing games under Linux and this market would become bigger.

Sorry but creating an undecorated frame with the size of the screen is possible since Java 1.4 and KDE (GNOME too) considers that a window which occupies the whole screen has to be considered as in fullscreen mode. It is sometimes a little bit buggy but it is not recent.

Boardspace.net games are pretty much “run anywhere”, but not painlessly. Windows, any flavor, is pretty solid. Macintosh is
plagued with minor UI glitches, which shift depending on what version of java and which browser is used. Likewise for Linux,
though I have a lot less data. There are also plenty of glitches due to non-java differences in OS and environment, such
as firewall and proxy issues.

If you want to have any hope or running anywhere, you MUST have a good logging system to automatically record the the problems. Don’t
depend on the user’s to tell you anything. They won’t complain, they’ll just assume your site is broken and go elsewhere.

I develop on Windows and had no major problems porting my game to Mac/Linux. I didn’t spend any time on portability during development, what’s great. With Java it’s easy to just focus on the code!

Although later it turned out, Swing is running slower on Linux/Mac compared to Windows! Also, there were some minor tweaks I had to do but no show-stoppers (e.g. screen size issues…).

[quote]We never really took the Linux option seriously; for the size of the market it just isn’t worth our while.
[/quote]
It didn’t took me more than 2h get my game working on Macintosh/Linux. Compared to the many 100s if not 1000s of development hours that’s cheap! Also, that’s the cool thing about Java getting the game to work on other platforms such as Mac/Linux! 8)

I couldn’t care less what Microsoft expects, and besides, our main market is Mac OS X. We don’t try hard with Linux (mainly due to total lack of time, skills, and motivation) but we do actually provide all our games for Linux via Webstart. Pointless really as the conversion rate on Linux is even lower than Windows but at least we’ve broken the chicken-egg cycle and done something and our games run just as well that way as any other way. In fact seeing as Linux doesn’t have the notion of a universal way of installing stuff, Webstart’s a bit of a blessing in disguise.

[quote]Sorry but creating an undecorated frame with the size of the screen is possible since Java 1.4 and KDE (GNOME too) considers that a window which occupies the whole screen has to be considered as in fullscreen mode. It is sometimes a little bit buggy but it is not recent.
[/quote]
In the commercial world, buggy is no good, and nor is “considered”. If it’s not real, reliable fullscreen, it wasn’t what we wanted, so we got it with LWJGL. In fact it was one of the primary motivators behind LWJGL.

Cas :slight_smile:

When I say “didn’t take it seriously” I didn’t say we don’t deploy for Linux - we just simply don’t provide a “native” installer for it, we just rely on Java Webstart being installed and leave it at that.

Cas :slight_smile:

Which is reasonable considering the number of different ways different distros install programs. You COULD package an RPM, a DEB, all that stuff, but it would be a waste of time and probably only helpful if you put the game in the distro’s repos, since not many people want to navigate a page just to find their distro’s installer format.

Unless they compile from source, but that wouldn’t help either, because they would need JDK on their machine.

I am hoping to reach Linux users when I do finish a game. There were only a few games that really grabbed my attention when I ran only Ubuntu, which were Sauerbraten, and one other I can’t remember, ONLY because they were usable FPSs on Linux. I could have installed Doom3 or UT2k4, but the installers didn’t work very well, and the other two games installed easily.

Edit: Plus, I didn’t like futsing with WINE. It worked, but at the same time didn’t work.

install4j works really nice! I got installers for Windows, Macintosh and Linux ready in no-time. It’s not free though, but if you are planning to release games in the future, it might be well worth your investment.

Note: I am NOT affiliated with the company.

Heres a free one written in java supporting cross-platform support and a registration system right out of the box: http://www.compudav.com/jsetup/jspe.htm

[quote]Heres a free one written in java supporting cross-platform support and a registration system right out of the box: http://www.compudav.com/jsetup/jspe.htm
[/quote]
this product seems awesome and it is compatible JRE 1.1 :slight_smile: that’s a good approach for an installer, anybody tryied it ?

I have and i use it for my projects. I think its a very good product.

Speaking of which, does anyone know what these conventions actually are? I know Vista disallows programs from writing to the Program Files directory, which is responsible for 50% of the “program X doesnt work on Vista” issues. But I have no clue of where you should write application data to on OS X and Linux.

I use


File mySettingFolder= new File(System.getProperty("user.home"),".myApp");

in most of the cases and sometimes


File myUserSettingFolder= new File(FileSystemView.getDefaultDirectory(),"MyApp");

on windows for settings I want to expose to the user. I don’t know where FileSystemView.getDefaultDirectory() is pointing to under linux and MacOS, but maybe they are sensitive places too.

I think Microsoft wants you to write stuff like settings to Application Data, which you can get by:

System.getenv("APPDATA")

which obviously only works on Windows. Using FileSystemView is actually quite clever, I´ll check where it points to on different OSes.