all entries on one page would be really cool, however I’m not sure running multiple applets on one page is such a good idea, I’d hate to see what it’d do to a computer with java plugin1 installed (applet dos attack) 
we could do something like warioware though where you have a menu and just pick a game to play.
It sounds very interesting, but not sure if I have understood it correctly. Does the applet have to be 40x30 px big? Isn’t that going to be very very small to play on? Or should you be able to play it in full screen?
I’m going for a 40x30 game, however when its run as an applet its scaled x10 the original size (400x300).
I might be interested.
[quote]Does the applet have to be 40x30 px big? Isn’t that going to be very very small to play on? Or should you be able to play it in full screen?
[/quote]
40x30 pixels, optionally scaled up by a factor to make it a bit more playable. I think 4x scaling works pretty well (160x120), any bigger than that and it’s starts to look too blocky.
I would give it a try too.
I see, well maybe 400x300 might work as well. Anyway sounds like a fun challange! I will definitely give it a try. But how will we post our contributions? Will we upload our applets to a common server from where they can be played, or just post links to our own pages where the applet is?
Ideally we would have a similar setup to Java4K but we would need to find a clone of appel willing to put the time and energy into hosting. I would love too but I’m afraid I really don’t really have the time. I think for the first contest it will be host your own, if it is half as successful as Java4K and we decide to do it annually then we will really need to get a website for it.
This sounds like an awesome idea. I’m also up for participating in this.
I’ve wanted to make something similar ever since I saw that Trogdor flash game (http://www.homestarrunner.com/trogdor.html).
As for scaling, I’ve been messing around in GIMP for the past couple minutes with the example you posted. It seems like either 4x (as you noted) or 8x would be the best option.
Edit: Here’s some code that has all of the EGA spec RGB values in it. It’s a bit ugly but if anyone wants to optimize it then go ahead: http://pastie.org/916717
Sounds like a great idea. I been meaning to do a contest, this one I might do and then port it over to android.
I’m ABSOLUTELY in!
Here’s a 40x30 EGA remake of Eye of the Beholder II I started on a while back:
I vote that we limit it to 16 colors on screen at once, and strictly those available in EGA.
Should we have some common framework to help make this easier?
Seems a pity to rule out monochrome entries (e.g., sixteen shades of black, white and grey).
Would palette-switching mid-game be allowed?
Simon
I think it should be allowed, yes.
But it’s really up to ShannonSmith. =)
It’d be crazy not to allow palette changes. It’d be cool to allow (virtual) H-blank palette changes, but that would require strict rules. Some examples: having the palette change ‘not-quite’ synced to H-blank. The change of object color as it goes across a palette change boundary (like the cursor in dungeon master).
Allowing alpha blending on colors/sprites would also be useful and make it easier to pull of some effects that would otherwise take more work to achieve.
But isn’t the point kind of to MAKE it hard?
The really hard part is trying to get a decently playable game in 40x30 pixels. I was thinking to have the full 64 colors available because it would be difficult to judge but the more I think about it would be easy to have a common applet framework that has a display that includes this. I’ll code up a basic framework/rules this weekend.
[quote]Allowing alpha blending on colors/sprites would also be useful and make it easier to pull of some effects that would otherwise take more work to achieve.
[/quote]
You can’t really alpha blend with only 16 colours, but I will include an image format that includes bitmask transparency in the framework.
[quote]It’d be crazy not to allow palette changes. It’d be cool to allow (virtual) H-blank palette changes, but that would require strict rules. Some examples: having the palette change ‘not-quite’ synced to H-blank. The change of object color as it goes across a palette change boundary (like the cursor in dungeon master).
[/quote]
I think we needn’t go that far lest we scare off less seasoned developers. I think 40x30 and a 16 colour palette per frame is quite tricky enough.
If anyone else wants to have a go at a framework then go for it, I will probably allow other frameworks for the contest as I don’t want to enforce my programming style on everybody. I will provide a reference implementation and certify others as also meeting the required limitations. My implementation will include a TinyGame a TinyScreen and an TinyImage class.
sounds good. count me in.
I like the ideas of output restrictions.
I was wondering if it would be ok to smooth scale the screen (non 16 color gradients) for higher resolution. But have the default screen resolution with EGA graphics?
Going with a Java/coffee theme, how about “Pixel-latte”?
Actually, no, that’s rubbish. Forget I said anything.
Simon