And then it gives you a URL with an auto-generated JNLP that will launch your game.

However...I've only tested it on two games so far. So, I need some authors willing to help test it. Preferably over the next 3 hours (because from tomorrow morning onwards I will have very little time to do any more work on this), but anything in the next 7 days will do.

Please email me at ceo @ grexengine.com with: - a list of all files your game uses - approximate file sizes - name of your game - + attach your JNLP file if you already have one that works, so I can compare it to the auto one if anything goes wrong!

and I will give you the URL's to upload your game to JGF.

Whatever problems you ahve, email me instantly, and I'll use the lsit of files and filesizes and game name to browse the logfiles and either fix the problme or work through it.

PS out of the many many many hours (probably multiple weeks if you put them all together) it's taken to get here, my time was spent approx:

40% - SQL being shit, MySQL being shit, or JDBC being shit. All this comes down to just two thigns: 1: MySQL authors were smoking some serious drugs when designing a lot of its behaviour. 2: (85% of the problem) SQL has no compile-time checking in Java because JDBC is so incredibly weak.

20% - reading, re-reading, misunderstanding, and reading again the JNLP docs which are an extended waffle by someone who was a bit bored and couldn't quite be bothered to explain anything in too much detail. There are still whole sentences I don't understand, and as noted in other threads here some bits are the opposite of Sun's own implementation...

15% - working around the general shitness of Sun's File API. Lots and lots of small ways in which it makes life as difficult as possible, presumably because the original author was writing it in as short a time as possible. About the level of what I'd expect if written in one week from scratch by an intern. Definitely not something you expect from a mainstream systems language.

10% - Eclipse trying to be "helpful" and being a PITA, e.g. by inserting and deleting quotation marks using some hopelessly broken so-called "algorithm" which always does the precise opposite of what you want. Eclipse taking up so much damn memory that I have to wait 2+ minutes because I ... typed the letter "d" in the middle of a multiline comment. Why swap then? God only knows...

So, all in all, it's taken more than 6 times as long as it should have done. But...it's done. Finally.

which will show each game as soon as it is initially added to the DB. I'll try to get a proper implementation of games pages, with at least a working ratings system, ASAP once the webstart-maker is finished being tested.

Good question: the term "alpha" is just because I had no better suggestions come in, and officially we're still testing . It has no special significance attached.

What happens is that the game-editor (specific role who overseas all games on the site) has the power to create new "allowed releases" and write a description for each of them. Most releases anyone can make for their game. Some releases - e.g. the "official, JGF tested" release which are the only ones allowed to appear on front page of site etc - can only be created by game-editors (once a normal release has been tested, they can promote it to an official one).

Roughly speaking. So, the idea is to allow you to create a "latest version" which you can update as much as you want, but also have an "official, tested version" (which probably won't be COMPLETE, simply tested to prove that it WORKS) so that people visiting the site don't get lots of broken games...

Gulp. I only today discovered how vile that yellow looks on some CRT's. My CRT it looked OK, my LCD it looks perfect, but on someone else's CRT instead of being a very white/pastel parchment colour it looks like banana custard .

Gulp. I only today discovered how vile that yellow looks on some CRT's. My CRT it looked OK, my LCD it looks perfect, but on someone else's CRT instead of being a very white/pastel parchment colour it looks like banana custard .

Welcome to the wonderful world of monitors.

It's time to prove to your friends that your worth a damn. Sometimes that means dying; sometimes that means killing a whole lotta people.

Basically, go to the DEVELOPERS tab, then do "submit game" on the left, and fill out the form and submit it. With MSIE, it returns an inexplicable DNS error, of all things. Sob. Happens to everyone so far, various versions of MSIE. Haven't double-checked with Moz, Opera, etc.

PS feel free to create "fake" games which I'll delete later once this is solved!

Might I suggest this tool for helping you diagnose the problem? It allows you to see exactly what IE is doing at the socket level. :-)

Good idea. I'd briefly considered using a packet sniffer, but thought "look, it's returning a DNS error, that can't be anything wrong with the server, can it?" so had put it way to the bottom of list of things to try .

Quote

I ran your site through Charles, and found that the real problem is that the server is returning HTTP Status 0 (!) which IE doesn't know how to cope with.

Thanks! The chances of there being a problem with that would have been approx 0.01% until very recently since the code has been run without change in many servers for more than a year with most scenarios happening eventually.

But...I patched the status-code code with a 2-line change just last week whilst trying to solve Cas's problem with his broken ad-ware blocker. So it looks like I broke JGF's version. Doh!

Anyway, will focus on this now. I was barking up the wrong tree entirely (thinking it was a problemwith the DNS server)

[/quote]BTW, why do the screenshots have to be JPGs? PNGs should compress nearly as well, and will look much better.[/quote]

LOL a silly reason: KISS.

1. Had to hard-code the image filename(s) into the "view game" page

2. Trying to get the uploads ready before the start of this week, didn't want to have to handle the HTTP semi-standardized automatic image retrieval system (browser makes a request for an extension-less image).

Because the screenshots are NOT being served by the standard file-service that comes with the grexengine, but by a custom thing for the CMS which is more tightly integrated with the DB, and because the CMS isn't production ready, if I wanted automated image selection I'd need to implement / finish the prototypical implementation mysefl.

3. MSIE doesn't support PNG, so that's out of the question if only one extension is to be supported.

I hate MS's attitude to IE ("we bribed our way out of the court case, so now let's leave our browser broken in major ways it would take us a few hours to fix because ... we can") but *shrug* have to live with it.

Please could someone capture that form submission for me? I'm on slow dialup here, and I can't afford the time for ethereal (8+Mb) and for some reason log4j has its knickers in a twist and isn't enabling the http-traffic logger (no idea why not).

I think the problem is now a parse failure in the multipart HTTP form submitted by MSIE. It is *possible* that there's a bug in IE's implementation of that, but more likely I just vaped something by accident and eclipse saved it without me realising I'd done it .

So, the most important part I need is a trace of PRECISELY what data MSIE is streaming (preferably with line breaks intact) to the server. I've got the HTTP headers, but as I said l4j isn't giving me the raw form (the encoded body) which I *need*.

Please, someone (anyone) post it here or mail it to adam at grexengine.com

Otherwise it could be several weeks before I can even try to fix this (don't have much time right now)

Please could someone capture that form submission for me? I'm on slow dialup here, and I can't afford the time for ethereal (8+Mb) and for some reason log4j has its knickers in a twist and isn't enabling the http-traffic logger (no idea why not).

Well, I'm not going to upload an 8Meg file, but I do have the capture that I used to test the error before:

I think the problem is now a parse failure in the multipart HTTP form submitted by MSIE. It is *possible* that there's a bug in IE's implementation of that, but more likely I just vaped something by accident and eclipse saved it without me realising I'd done it .

I used to do my own parsing of multipart data. Then I found out it was randomly failing just for the hell of it. That's about the time I moved to the Apache Commons component for Multipart handling. Haven't had an issue since. :-)

Quote

3. MSIE doesn't support PNG, so that's out of the question if only one extension is to be supported.

The logo is more of an issue. However, JPGs for logos look like crap. If you don't want PNGs, then you should allow GIFs uploaded for those.

Quote

1. Had to hard-code the image filename(s) into the "view game" page

2. Trying to get the uploads ready before the start of this week, didn't want to have to handle the HTTP semi-standardized automatic image retrieval system (browser makes a request for an extension-less image).

Dunno about your CMS, but I would map /images/*.png and /images/*.jpg to something like MyImageServlet. The servlet would take requests for images, then parse out the filename and extension. The filename would be used as the key to find the right image in the CMS, and the extension would be used to produce a MIME of "image/"+extension. :-)

BTW, did I mention that it would be nice to auto-resize the screenshots for the user? ;-)

I consider that to count as not supporting it , since one of the primary sellingpoint features of PNG is not just alpha but an entire alpha channel, making things look pretty.

Again, under KISS, I had to bear in mind "if Im going to pick one format, which will it be?" hence giving in to the one where we wouldnt get buggered support in things like logos.

Shrug. Making the image type "anything you want" is going to happen soon anyway.

Quote

Dunno about your CMS, but I would map /images/*.png and /images/*.jpg to something like MyImageServlet.

That assumes that images only live in one directory. In fact, being a CMS, they live all over the place (because they are classified by what they're attached to as much as by what they are) AND there's no prefix to tell the filetype - you simply don't know until the file has been identified and looked up in th eMIME mapping - and so it requires a more general-purpose solution.

It should be easy to fix (I think), since there's already a table-based MIME lookup going on, it's just a question of splicing in the code to do extensionless file searches and writing the unit tests, checking it all works, etc. Just time that I don't have to spare right now .

Quote

The filename would be used as the key to find the right image in the CMS, and the extension would be used to produce a MIME of "image/"+extension. :-)

What I'd probably do is, when a request comes in for a file which is not found, do a search for all files with that name as prefix, and look at the MIME types for all. If all are the same, then use the q= tag in the HTTP header from browser to pick one to send.

That assumes that images only live in one directory. In fact, being a CMS, they live all over the place (because they are classified by what they're attached to as much as by what they are) AND there's no prefix to tell the filetype - you simply don't know until the file has been identified and looked up in th eMIME mapping - and so it requires a more general-purpose solution.

Umm... no, I was actually saying that the servlet would live in one directory (whatever that may be), and it will look up and return the image from the CMS.

and click on your game, and click on the "play now" link, and see if it works.

PS: it maintains counters of how often each game has been played. Doesn't work well right now, since Webstart can laucnh anywhere between 1 and 4 hits on the webstart JNLP for each "play" of the game...

Mighty Bubbles is the story of a little girl who wants to save her world of the water ennemies invasion. Their goal is to take control of any source of water. There are multiple water trees. Each of them produces water drops and the ennemies want to consume all of them. You, as the little girl (or boy if you insist) have to capture all the water ennemies by throwing them bubbles. When an ennemy is captured, you must pop the bubble to eliminate him.

Your second objective is to retreive all the water drops taken by the ennemies and bring them back to the water trees. A water tree can't hold more than 6 drops so when one is full, you must fill up another one.

You have to play the game with the keyboard. Here is the key mappings:

I tried to create an entry for Mighty Bubbles but I got the following error on second try:...It seems that you have problems with existing rows in your DB. Seems to be related to primary key/foreign key.

Unsurprisinlgy, you cannot have two games with the same name !

Although thanks for pointing it out...I need to add a pretty error screen to catch that exception and explain it in words, not stack traces

Check the games pages and see if your first attempt created a page (looks like it did, if it's in the DB).

Otherwise, create a "dummy" game with a slightly different name, and give me the error from the initial submit attempt.

Of course yes! But I think you should not use the game name as your primary key but rather an auto generated one for example. In my opinion the name of the game should be used to validate the game unicity in the system.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org