Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (522)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (590)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5
  ignore  |  Print  
  New j4k contest anytime soon?  (Read 40658 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #90 - Posted 2005-11-26 11:32:51 »

Last year, for webstart files, you were allowed to exceed 4k with the signed JAR, right?

Incorrect. Many developers offered a Webstart version for convenience. However, most were actually judged on a downloadable JAR version of the game.

Actually the WebStart version was preferred over all others.  At least that's what I did, and I thought Blah^3 did the same.

Yep. c.f. previous comment about webstart and caching. But, in my case, it was judged in phases (on airplane, at conference centre (with internet), in hotel (without internet) Smiley) so different things preferred at different times.

Quote
This time around I would make it a requirement that Web Start be the ONLY way that the games are to be run.

This was my very strong recommendation from last time too. Frankly, I find it sad that this is even being debated, given that we, as judges, made such a huge point of this last year. There were arguments back then, and we replied, and I got the impression some people still weren't convinced, but ... you know, we actually *did* try and work through every game, we're developers ourselves, we can fix a lot of crap, and we *still* found it extremely difficult in more than a few cases.

There were also several other major recommendations we made. No-one's thought to email me to ask for input this time around, so I'm hoping Woogley got all those comments and has taken them into account. If not, TBH I can't be bothered to go through it all all over again. We're not exactly hard to find or contact, if people can't even be bothered to ask, I'm fed up trying to tell them.

malloc will be first against the wall when the revolution comes...
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #91 - Posted 2005-11-26 14:01:54 »

Great attitude!

People who can't be bothered to try to get things to run shouldn't be judges.
I enter the competition to try to squeeze a fun game into 4k, not to worry about how some moody judge will like my packaging.

Play Minecraft!
Offline woogley
« Reply #92 - Posted 2005-11-26 14:14:01 »

last year there was about a month of wasted time debating the rules - not this year. the contest is running almost the exact same way as last year with only a few minor changes such as no command lines. gamers should be able to click a game link in java unlimited and then immediately be playing a game. it's fine if you zip your files and the user has to unzip it, but it should never get to the point of using the command line. the only games that really *need* to be zipped are applet-based games because they need an HTML file and a JAR file to run. Most application-based games can get away with just living inside one JAR file.

This isn't about the judges, it's about the players. Look at the download numbers for games in Java Unlimited - and that's AFTER the contest. It's not just judges and java devs playing these games, you have some gamers googling around for games who know nothing about the command line and barely anything about unzipping
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #93 - Posted 2005-11-26 18:31:09 »

no command lines.
Fine
Quote
gamers should be able to click a game link in java unlimited and then immediately be playing a game.
Does this include executable zips, or is webstart compulsary.  Are you supporting pack.gz archives serverside or do we need to use regular zip archives only?  Are the judges going to judge the entries directly from java unlimited, or do I need to provide a downloadable version that runs offline.  Offline running from harddisc with no server means no pack200.
Quote
it's fine if you zip your files and the user has to unzip it,
Are you directly supporting applets, or only indirectly via downloading a zip with the relevant files.  It won't be possible to use pack200 on the latter, as you need server support to send the archive with the correct MIME type.  Running directly from disc doesn't cut it with pack.gz archives.

I don't really care whether pack200 is in or out, but will need to know when the rules are published, whether it is indirectly prohibited by the rules regarding how the game is to be executed.

Thanks
Alan Smiley

Time flies like a bird. Fruit flies like a banana.
Offline woogley
« Reply #94 - Posted 2005-11-26 18:55:36 »

you'll be getting the full set of rules on launch day. but like I said earlier, do not worry about pack200 at all. Also, the only person that will be running the entries offline is me, and that's just to validate that no online resources are used. everybody else including the judges will be running them through Java Unlimited the exact same way as normal players.

the reason that pack200 is out for at least this year is because java 1.4.2 is the minimum compatibility requirement. Next year the minimum will most likely be java 5, in which case pack200 will be allowed. This also means next year could be the most impressive year to date since pack200 reduces JARs almost 50% more. The reason for this is that I log on Java Unlimited what java version a user is running (provided the browser provides the information), and I've also been looking at Webstart's signature when it downloads the resources... after rounding it off it comes to this:

  • 75% of users are running Java 1.4
  • 15% are running Java 5
  • 5% are running Java 1.3
  • 5% are running MSJVM (Java 1.1) or Java 1.2

I'm not sure what the *official* percentages are over the entire web, but this is how it is on my site. Most likely next year will yield more Java 5 users. Until then, no pack200.

edit: for those who are randomly curious of how these stats are found, this is what webstart's signature looks like:

Quote
User-Agent: JNLP/1.5 javaws/1.5.0_01 (b08) J2SE/1.5.0_01
UA-Java-Version: 1.5.0_01
Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #95 - Posted 2005-11-26 21:29:13 »

Quote
but like I said earlier, do not worry about pack200 at all.
...
the reason that pack200 is out for at least this year is because java 1.4.2 is the minimum compatibility requirement.

I'm glad you clarified this, because 'don't worry about it' could mean anything, either affirmative or negative.

I'm not happy about excluding pack200, but if that's the rules then so be it.  I would've liked to see more discussion about it though, as several of us have clearly stated we favor it.  I thought last year jre 1.5 was required, but hardly anyone required it.  Why the change?

edit;

Quote
This isn't about the judges, it's about the players. Look at the download numbers for games in Java Unlimited - and that's AFTER the contest.

I disagree with this too.  This contest is about the challenge.  That's all.  If no one participated then there wouldn't be any games to 1) judge or 2) download.
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #96 - Posted 2005-11-26 21:59:28 »

@Woogley

Thanks for the clarification.  I'm quite happy to stay with 1.4.2.  I was planning to anyway, before the extra available compression of pack200 tempted me to the dark side  Grin

Alan

Time flies like a bird. Fruit flies like a banana.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #97 - Posted 2005-11-26 22:58:54 »

Great attitude!

People who can't be bothered to try to get things to run shouldn't be judges.

As Blah wrote "...you know, we actually *did* try and work through every game, we're developers ourselves, we can fix a lot of crap, and we *still* found it extremely difficult in more than a few cases."

It is absolutely ridiculous to put the responsibility of making things work on the judges!  It's not THEIR entry!  That's the crappy attitude.  People that can't be bothered to make things work properly, shouldn't be contestants.  That seems to make a lot more sense.

Amoung the suggestions from last year:  Have a warm up phase where people (including judges) can provide feedback, explaining what happens when they try to run it on their system.  This gives contestants the opportunity to work out glitches that they did not encounter with their own system.  I think it is particularly important because of the cross-platform nature of the contest.  If the entry still doesn't work after that, then it will be reflected in the score.

Offline woogley
« Reply #98 - Posted 2005-11-27 06:47:49 »

Quote
This isn't about the judges, it's about the players. Look at the download numbers for games in Java Unlimited - and that's AFTER the contest.

I disagree with this too.  This contest is about the challenge.  That's all.  If no one participated then there wouldn't be any games to 1) judge or 2) download.

The `This` I was referring to in that quote was about the reason the command lines were excluded, it wasn't defining the meaning of the contest.
Offline woogley
« Reply #99 - Posted 2005-11-27 06:56:40 »

Amoung the suggestions from last year:  Have a warm up phase where people (including judges) can provide feedback, explaining what happens when they try to run it on their system.

this is a good idea, although last year most entries were posted here at JGO and received quite a bit of feedback before the judging. either way it's a good idea to have people test your games out - "proofread," if I may Tongue

By the way, whoever was asking why the minimum java requirement was changed: I want devs to have equal opportunity in the contest. Some devs either have 1.4 compilers or they may have 1.5 but don't want to lose compatibility with earlier versions... or whatever. The point is, when java 4K sets the minimum requirement to Java 5 - everyone will HAVE to use Java 5 because of the pack200 advantage. If we have a mixed version development, most 1.4 based games will be DOA due to the tighter size constraints of not having pack200. It's a matter of which java platform is currently more available - this year it's java 1.4.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #100 - Posted 2005-11-27 10:28:18 »

Amoung the suggestions from last year: Have a warm up phase where people (including judges) can provide feedback, explaining what happens when they try to run it on their system.

this is a good idea, although last year most entries were posted here at JGO and received quite a bit of feedback before the judging. either way it's a good idea to have people test your games out - "proofread," if I may Tongue
[...]

None of the judges managed to run my game. The rules should be clear about which JRE is used... the one from the JDK (with soundbank) or the standalone (without soundbank).

Without a soundbank (midi) the only way to create sounds is to generate em on the fly (as seen in defender4k).

弾幕 ☆ @mahonnaiseblog
Offline woogley
« Reply #101 - Posted 2005-11-27 23:49:25 »

excellent point oNyx... it's a shame you were at a disadvantage due to a strange circumstance with the soundbank. personally I think the game was underrated since compatibility was unstable (because I, for one, am all about action shooters).

this is one issue I'll open to public debate. I personally feel it should be acceptable as long as you specify that you need a soundbank. This way I can provide a download link for a soundbank in your game's description after you submit it. The reason I want to be flexible with this is because MIDI is pretty much the only way to play sounds without generating them at runtime or loading AU/WAV files (which obviously wont fit into 4K).

Who agrees with allowing a soundbank download if needed?
Offline Alan_W

JGO Knight


Medals: 8
Projects: 3


Java tames rock!


« Reply #102 - Posted 2005-11-28 08:00:59 »

Who agrees with allowing a soundbank download if needed?

Ok with me, although I feel that the game should be coded to work without sound if no soundbank is present, rather than fail with an untrapped exception (null pointer probably).  I reckon you can get basic midi sound effects in around 200 to 250 compressed bytes, while more like 800 are required to synthesise your own with the sampled sound API.  There's also Toolkit.beep() in the bargain basement at around 30  compressed bytes, although this gives the 'error' sound, which is a bit distracting.

Smiley

Time flies like a bird. Fruit flies like a banana.
Offline kevglass

« JGO Spiffy Duke »


Medals: 195
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #103 - Posted 2005-11-28 09:55:49 »

Soundbanks are an extension to the "standard JRE", I don't think they should be allowed. Otherwise, I'd like to use Java3D cause its only an extension Smiley

Kev

Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #104 - Posted 2005-11-28 12:48:22 »

Soundbanks are an extension to the "standard JRE", I don't think they should be allowed. Otherwise, I'd like to use Java3D cause its only an extension Smiley

Kev

In that case sound shouldn't be included during judging criteria.  If we went by the judging criteria of last year someone could make a 'really nice looking tetris' (  Roll Eyes again) and spend alot of bytes on synthesizeing music and sweep the contest.

I'm in favor of providing a soundbank.  Unlike java3d a midi soundbank isn't an additional api.....
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #105 - Posted 2005-11-28 13:42:13 »

i'm in favor of a soundbank too, sure its an extension but its probably the only way to get some decent sound into the 4k games. Games without sound sometimes just don't feel right.
Offline Markus_Persson

JGO Wizard


Medals: 16
Projects: 19


Mojang Specifications


« Reply #106 - Posted 2005-11-28 13:44:34 »

It is absolutely ridiculous to put the responsibility of making things work on the judges!  It's not THEIR entry!  That's the crappy attitude.  People that can't be bothered to make things work properly, shouldn't be contestants.  That seems to make a lot more sense.

You seem to miss the point that the competition is about the ENTRIES, not about the JUDGES.



Count me out this year.

Play Minecraft!
Offline kevglass

« JGO Spiffy Duke »


Medals: 195
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #107 - Posted 2005-11-28 14:32:23 »

Pardon my language, but this sound bank stuff if absolute tosh..

Soundbanks are an extension to the "standard JRE", I don't think they should be allowed. Otherwise, I'd like to use Java3D cause its only an extension Smiley

Kev

In that case sound shouldn't be included during judging criteria. If we went by the judging criteria of last year someone could make a 'really nice looking tetris' ( Roll Eyes again) and spend alot of bytes on synthesizeing music and sweep the contest.

I'm in favor of providing a soundbank. Unlike java3d a midi soundbank isn't an additional api.....

Sure, someone could do that. If they got a highscore due to wasting the whole 4k on sounds then the judgeing criteria is indeed screwed. I seem to remember last year sound gave a couple of extra points, nothing more.

Quote
i'm in favor of a soundbank too, sure its an extension but its probably the only way to get some decent sound into the 4k games. Games without sound sometimes just don't feel right.

because its hard to get sound in 4k doesn't mean we should just change the limit. Adding a sound bank is an extra download for the user (given that game players don't normally get the whole JDK). Hence, its no longer a 4k download.

If the topic had been kept quiet competitors could have got away with support soundbanks if present. That way on the judges machines they were likely to get nice sound.

Having additional resources over the 4k + JRE is cheating no matter whether its an API, Soundbank or tonne of additional levels downloadable from a seperate site.

Kev

Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #108 - Posted 2005-11-28 15:29:19 »


because its hard to get sound in 4k doesn't mean we should just change the limit. Adding a sound bank is an extra download for the user (given that game players don't normally get the whole JDK). Hence, its no longer a 4k download.

If the topic had been kept quiet competitors could have got away with support soundbanks if present. That way on the judges machines they were likely to get nice sound.

the soundbank download is very small 0.35mb, my view is if most of the people who are gonna try the 4k games are developers they'll most probably have the jdk anyway, besides its a very small trade off for better quality and more impressive games, its not like the 4k game limit is changing, games will still have to be 4096bytes, just gives developers another api to play with. Of course having other api's is different, only reason i think this should pass is soundless 4k games just aren't as fun as ones with sound.

Quote
Having additional resources over the 4k + JRE is cheating no matter whether its an API, Soundbank or tonne of additional levels downloadable from a seperate site.

its only cheating if its against the rules, which can always be changed   Wink
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #109 - Posted 2005-11-28 15:57:56 »

You seem to miss the point that the competition is about the ENTRIES, not about the JUDGES.

Funny, that's exactly the point that I think you are missing Smiley
Oh, well.  I'm not judging this year anyway.

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #110 - Posted 2005-11-28 16:00:47 »

I'm torn on the soundbank issue.  I don't like it because I think the target should be the standard JRE as it is typically installed on end-user's systems.  But I think it's unfortunate that the standard JRE is crippled in that regard so it seems like adding the sound bank is a reasonable compromise.

I guess I will abstain.  I don't want to vote against the inclusion of the soundbank, but I'm not for it enough to give a vote.

Offline Anon666

Junior Devvie




aka Abuse/AbU5e/TehJumpingJawa


« Reply #111 - Posted 2005-11-28 20:05:59 »

[futile hope]If we convince Sun to include it in a point release of 1.5, the issue is irrelevant Smiley[/futile hope]
Offline g666

Junior Devvie





« Reply #112 - Posted 2005-11-28 21:47:57 »

I vote for no soundbank, i cant be bothered to download it, so why should any other players.

desperately seeking sanity
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #113 - Posted 2005-11-28 21:59:11 »

I vote for no soundbank, i cant be bothered to download it, so why should any other players.

If you have the JDK installed you already have a soundbank.

弾幕 ☆ @mahonnaiseblog
Offline g666

Junior Devvie





« Reply #114 - Posted 2005-11-28 22:04:27 »

I vote for no soundbank, i cant be bothered to download it, so why should any other players.

If you have the JDK installed you already have a soundbank.

but i have the 1.4 jdk and the 1.5 jre. Smiley

desperately seeking sanity
Offline Rick

Junior Devvie


Projects: 1


Java games rock!


« Reply #115 - Posted 2005-11-28 23:43:20 »

I would like to use the soundbank. The Midi API is part of the standard JRE. You still have to be clever and make sound tradeoffs to balance the game play graphics and sound. Just getting a handle to a MidiChannel will cost a few hundred bytes. I think part of the fun is discovering new areas in the JRE that you would not normally use in day to day work. But of course any failure in loading the sound bank should be handled and should not stop the game from running.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #116 - Posted 2005-11-29 03:21:01 »

I would like to use the soundbank. The Midi API is part of the standard JRE.

Let me get this straight, having never coded MIDI sound....

Are you saying that the sound API is included but is completely unusable because there are no sounds ("instuments") for it to play?

If so, what would be the point of sun including the MIDI related classes inthe JRE at all?

If this is NOT true, and the instruments are just limited to a smaller set or something, then I vote no sound bank.  Deal with the restricted environment, as it exists for the bulk of the user base.

If it IS true, somebody slap Sun for me Smiley

Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #117 - Posted 2005-11-29 04:14:26 »

The applet getAudioClip() and others work in web browsers so far as I know (ie I haven't tested it myself).  These were made static to be usable all over.

It is absolutely ridiculous to put the responsibility of making things work on the judges!  It's not THEIR entry!  That's the crappy attitude.  People that can't be bothered to make things work properly, shouldn't be contestants.  That seems to make a lot more sense.

You seem to miss the point that the competition is about the ENTRIES, not about the JUDGES.



Count me out this year.

 Cry
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 78
Projects: 15


★★★★★


« Reply #118 - Posted 2005-11-29 13:14:15 »

Are you saying that the sound API is included but is completely unusable because there are no sounds ("instuments") for it to play?

don't think it needs a sound "instument" to run midi, here on linux i have no hardware/software midi support but java runs the midi fine, i think it may have a built in midi instument emulator or something.
Offline Anon666

Junior Devvie




aka Abuse/AbU5e/TehJumpingJawa


« Reply #119 - Posted 2005-11-29 13:49:03 »

I would like to use the soundbank. The Midi API is part of the standard JRE.

Let me get this straight, having never coded MIDI sound....

Are you saying that the sound API is included but is completely unusable because there are no sounds ("instuments") for it to play?

If so, what would be the point of sun including the MIDI related classes inthe JRE at all?

If this is NOT true, and the instruments are just limited to a smaller set or something, then I vote no sound bank.  Deal with the restricted environment, as it exists for the bulk of the user base.

If it IS true, somebody slap Sun for me Smiley

I believe the intention is that you can package your own midi synthesizer with your app.
Pages: 1 2 3 [4] 5
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

trollwarrior1 (29 views)
2014-11-22 12:13:56

xFryIx (71 views)
2014-11-13 12:34:49

digdugdiggy (50 views)
2014-11-12 21:11:50

digdugdiggy (44 views)
2014-11-12 21:10:15

digdugdiggy (38 views)
2014-11-12 21:09:33

kovacsa (62 views)
2014-11-07 19:57:14

TehJavaDev (67 views)
2014-11-03 22:04:50

BurntPizza (64 views)
2014-11-03 18:54:52

moogie (80 views)
2014-11-03 06:22:04

CopyableCougar4 (80 views)
2014-11-01 23:36:41
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!