What games use your technology?

General Discussions
#1

After a bout of XML wizardry this evening, all technologies on JGF automatically have thumbnails + links to all the games we know of that use those technologies.

So, for instance, if you go to the JGF front page (http://grexengine.com/sections/externalgames/), go to the Tech section, and then click on Java3D (and scroll down a bit), Flying Guns shows up as using this tech, with a mini screenshot + link to the detailed entry. Or if you go to the webstart page, you find loads of games ;D.

Now…some technologies are woefully under-represented here, and with this update it becomes all the more obvious. Screenshots are great for promoting your technology-of-choice, and giving people an idea what it can do, but … real games are so much more effective!

So, for all those contributing to techs listed on JGF (and if you work on a tech that isn’t listed, send me the details!), why don’t you give us a list of games - alpha, beta, or gold - that use your tech, and we’ll try and get their authors to send us the details to add to JGF?

PS: Those techs most lacking in games right now are:

  • jME (zero)
  • ODE (zero)
  • JInput (zero)
  • JOAL (zero)
  • JOGL (two)
  • LWJGL (one)

I’m sure each of those has at least 4 or 5 games in develoment already, and some many more … but I just don’t have the details :frowning:

#2

There’s at least 4 more LWJGL games you might want to add to JGF:

Tribal Trouble from Oddlabs
Danger Maze from Adamant Games Inc.
Super Elvis from us!
Quix from Orangy Tang

Cas :slight_smile:

#3

[quote]There’s at least 4 more LWJGL games you might want to add to JGF:

Tribal Trouble from Oddlabs
Danger Maze from Adamant Games Inc.
Super Elvis from us!
Quix from Orangy Tang

Cas :slight_smile:
[/quote]
Great stuff - I’d love to have as complete a list as possible.

Last time I asked the TT guys, they had nothing playable they wanted anyone seeing, and preferred not to even have a “preview” article, so there’d be nothing for it to auto-link-to on the site (links are generated from walking the XML tree and using methods, not from scraping HREF’s / URL’s from a source file - I could change this at some point in the future, but for the time being all I need is for the game to be on JGF and it will be found automatically, which is not much to ask :stuck_out_tongue: until I have the time/energy to add mroe intelligence to the link generation).

For SE nee HG, if you send me the details (or a note to confirm that it’s “exactly as for AF” so I can just copy/paste the AF source XML) along with the HTML-fragment (use P tags etc as required) for the description, and URL + 320px-wide screenshot, then I’ll add it this week.

Quix…IIRC OT has promised to send me the details when he’s happy for people to start playing it (or maybe that was just a promise for another diary update, and I’m getting confused…)

Checking out DM now…

#4

[quote]Quix…IIRC OT has promised to send me the details when he’s happy for people to start playing it (or maybe that was just a promise for another diary update, and I’m getting confused…)
[/quote]
Probably both. :slight_smile: On the other hand, you can tag S-Type under the Jogl catergory.

#5

I remember looking at this one before, and there was some problem (can’t remember what).

:frowning: right now, their linux download is to a shell script, which I would need some serious persuading before accepting. Ditto their windows link to an EXE and OS-X ZIP. If they JAR or webstart…I haven’t got as far as deleting all non-webstart games :slight_smile: but one of the few absolute rules is that if you force someone to download the game, they must be able to simply copy that file to another computer and have it run. No: “I downloaded a windows-only version and have to re-download the whole thing in order to play it on my linux partition”.

FYI the only other one I can remember off the top of my head is that the game cannot be available on one platform only - that’s stretching the definition of “java game” too far (it becomes a game that is “written in java-the-language, but does not run on java-the-platform”) given that JGF seeks to increase the appreciation of the benefits of pure java games - and hence increase demand. This is why the Kingdoms RTS game is not on JGF - they refused to distribute anything except a windows EXE.

#6

[quote]JGF seeks to increase the appreciation of the benefits of pure java games
[/quote]
Surely “pure Java” excludes libs like LWJGL that rely on native code (eg the dll for windows and the .so for Linux)?

Or am I being pedantic? ???

#7

Yes, you are :stuck_out_tongue:

Java uses native parts all the time. Since Java itself isn’t native there has to be parts wich do the dirty low level stuff.

So… it’s “pure” with common sense applied. That means for the “Java platform”, but that only includes the 3 major operating systems: win, mac and linux. Others are nice, but they don’t matter anyways :>

#8

Thanks, I should have originally explained better myself :).

The policy with JGF is that if it runs from a single link for all major platforms (“whatever has an up to date high quality JVM”) then that’s OK.

Webstart games buy themselves a freebie here, because most use native libs that mean you do need to download once for each platform - unlike self-contained JAR’s. But…to the user, there’s just one URL, and it Just Works on every machine they try it on. If a game turns out to be broken on a major platform, then I start breathing down the author’s neck, and if if they don’t fix it soon they get delisted.

Overall the point is to have a site where - assuming yuo have a JVM :wink: - everything works straight away, with no “extras” you have to download or install, no hassle, no fuss, just “click and go”.

The thing I like most about webstart is that it lets people do games e.g. like survivor which actually uses not one but THREE 3rd-party technologies that need to be installed separately - but the player is not even aware of this! It all happens automatically, under the covers, installing the correct selection of native libs and x-platform jar files.

Even more wondrously - although many techs haven’t set this up appropriately yet - you can configure it so that the downloaded techs are automatically shared between all webstart games. So, if you run a game and JOGL has upgraded, it downloads the new JOGL, and suddenly all your games are using the new, faster, less buggy JOGL. Nice :). All without you, the player, lifting a finger. In theory…

#9

[quote]Even more wondrously - although many techs haven’t set this up appropriately yet - you can configure it so that the downloaded techs are automatically shared between all webstart games
[/quote]
Does this mean that if I have already downloaded a LWJGL game, then the next LWJGL game will only download the app and not the LWJGL lib again?

[quote]So, if you run a game and JOGL has upgraded, it downloads the new JOGL, and suddenly all your games are using the new, faster, less buggy JOGL
[/quote]
And suddenly all your games break :stuck_out_tongue:

I have mixed feelings about Webstart. It’s new to me as the last time I looked at Java was at 1.2. I just wish it didn’t look so damn ugly!

#10

Say there was a bug in one of the JOGL implemenations, and the user had to work around it, when the new JOGL gets updated, the work around would still be there, ultimately, it would seem like a new bug but it isn’t really. If you get what I mean ???

So really, thats a disadvantage, and sometimes it can break games.

#11

Precisely.

Which is why I get very angy when open-source software hasn’t been regression tested - the base assumption ought to be valid that new releases will not break old code except very rarely.

However, IIRC the easy and obvious solution to this is that you link to a specific version of the technology rather than their “latest build”, and that way your game will only ever use that build. With most techs though it’s safe to just use the latest (stable) version.

#12

It is impossible to regression test a library against 3rd party software, period. Therefore we have solved this problem in LWJGL by simply making the distribution of the LWJGL to be under half a meg and therefore very easily redistributable without a great deal of wastage. (It can be shrunk to half that with a little ingenuity too)

Cas :slight_smile:

#13

[quote]It is impossible to regression test a library against 3rd party software, period.
[/quote]
EDIT: I’m not talking about testing against the software directly, I’m talking about testing against the virtual contract you make with the software. If you have good documentation, it’s their fault if they rely on undocumented behaviour; you only need to test that your system does everything it says it does.

Assuming we’re talking about that, then expensive, yes. Impossible, no. It just requires a really extensive test suite.

IMHO it’s not much to ask that any production-level library (e.g. LWJGL after version 1.0) not break things that were working beforehand, bar exceptional cases.

But looking at LWJGL in particular, how many regression bugs have you had so far? From what I’ve seen on the PG forums etc the answer is “few, and very few that haven’t been spotted quickly and then fixed”. This is presumably partly because you, Cas, are doing regression testing nearly all the time - first with AF, now with SE. And that is a fairly good set of regression tests AFAICS :). If I were to criticise the LWJGL process at all it would only be to say that when you spotted regression problems it would have been better for others if you had brought them up and either fixed (or nagged someone else) them rather than just workaround them in your code.

Personally, I think that if a tech’s authors decide to forego regression testing (which, as above, I don’t believe you guys have done, despite your claims ;)) then they can make it OK by making it very easy to lock-on to a particular version, and being VERY up-front about the need to avoid “using the latest version” even going so far as to not have any symbolic links to “latest”.

(re: size: half a meg is still on the high side for impoverished developers with only a few Gb a month on their web hosting plan :(, but 0.25 Mb would be great; JOGL is currently 900k IIRC, and that’s certainly going to cause a problem with survivor, unless people stop playing ;))

#14

LWJGL can be trimmed down to about 0.25mb by removing the code you don’t use and using lzma compression.

We’re especially keen to avoid breaking stuff after 1.0 which is why 1.0 isn’t out yet :slight_smile:

Cas :slight_smile:

#15

Heck I’m still trying to get the Mac version of LWJGL under 4.8 MB!!!
Yeah, something is obviously hosed… the last version I had is 640kB.

#16

[quote]Yeah, something is obviously hosed… the last version I had is 640kB.
[/quote]
The latest version is ~850 kB - you need to strip the file!

Using compatible compression technologies, I can compress the lwjgl.jar and lwjgl.dll into a 195 kB zip file :p. Using an obfuscator could probably reduce the lwjgl.jar file drastically.

Using incompatible compression (LZMA) I can compress the same files to 133 kB. Ofcourse one would need 7zip to uncompress… (using an SFX archive, I end up at 206 kB total).

#17

[quote]The latest version is ~850 kB - you need to strip the file!
[/quote]
How? I ran ‘strip’ on it and it had no effect.

#18

Ok… apparently I don’t know how to use “strip” I tried the -x option this time and that reduced the size to 265684 bytes!!! Seems a bit TOO small now… … I should go on a rant about how stupid the GNU compiler is for producing such a bloated useless file in the first place… and how brain-dead the XCode project defaults are for a JNI library such that they increase the size of the lib by a factor of 6 for release (“deployment”) builds… but I think I can hold back :slight_smile:

#19

[quote]Ok… apparently I don’t know how to use “strip” I tried the -x option this time and that reduced the size to 265684 bytes!!! Seems a bit TOO small now…
[/quote]
Hmm, a bit small yes - but if it works…

[quote]… I should go on a rant about how stupid the GNU compiler is for producing such a bloated useless file in the first place…
[/quote]
It’s just building with all symbols exported and a slew of debugging info

[quote]and how brain-dead the XCode project defaults are for a JNI library such that they increase the size of the lib by a factor of 6 for release (“deployment”) builds… but I think I can hold back :slight_smile:
[/quote]
I also tried to get it to compile under xcode once. FWIW, Xcode seems like a good solution, but I just had the feeling that it was needlessly complex - and the UI is anything but simple. Very counter Mac OS X’ish.

#20

[quote] It’s just building with all symbols exported and a slew of debugging info
[/quote]
In the “Deployment” build? (The other option is “Development” build)

[quote]FWIW, Xcode seems like a good solution, but I just had the feeling that it was needlessly complex - and the UI is anything but simple. Very counter Mac OS X’ish.
[/quote]
I agree 100%. It is basically that there is a learning curve to it. Since I’ve been learning Objective-C and Cocoa I have come to appreciate it a bit more, but considering this is coming from Apple I’m surprised at how counter intuitive they made it.

To give Apple some credit, it is a full featured IDE that is included with the OS for no extra charge, and Interface Builder and Objective-C can be pretty sweet for making a good looking app in record time.