is the resolution a must (40x30)?
because EGA could only reach up to resolutions of 640×350:
and the color pallette has 64.
what if the rules are something like:
resolution divided by 10 and you get…
64x35:64pallette
and call it the six4 contest, like the 4 in 4k.
I understand its a big change just for a name 
Here’s some food for thought. If this works well enough to make a regular event, then perhaps having a different ‘theme’ each time could be cool. Such as: Vector Graphics machine (like Asteroids, Battle Zone, Tempest), early console (some fixed number of background planes and sprites), etc. For each someone could toss together a “reference” framework that enforces the requirements.
The main focus is a tiny game rather than EGA so 40x30 or 30x40 will be a hard restriction. Using EGA means you can’t just smooth scale a larger game and have it look like it’s being played in a tiny window it forces you to think about every pixel and how you will use it. For this reason I don’t think interpolated upscaling is a good idea either because it destroys the pixelated feel.
Demonpants do you want to go ahead and create a sub forum with the title “Tiny Game 2010” for now, we can change it later if we get a better idea.
Any thoughts on sound? Should it be as restricted as the visuals?
I can think of ways in which elaborate sound effects could be used to compensate for the lack of pixels. For example, a voice counting down the seconds remaining so that the game doesn’t need an on-screen timer. Would allowing that sort of thing be good or bad?
Simon
This sounds extremely awesome, and I’d love to be part of writing those frameworks if at all possible. 
As for sound, how about no sound?
The 16 colour restriction will make things interesting. I’d like to write my own framework, if that’s Ok. It’ll probably feature a dynamic palette based on the colours of the various elements currently on screen. I might also look at palette switching at half frame rate to get more colours, although that might be going too far.
@dishmoth - I was thinking about sound too. Maybe voiceovers in lieu of textual description.
[quote]Any thoughts on sound? Should it be as restricted as the visuals?
[/quote]
No restrictions on sounds, I don’t think we need to get carried away with making it harder or more authentically limited. If we head down that road we will end up requiring it to run on an emulated Motorola 68000 with 64k of ram. Of course stylistically you probably want to have your sounds be suitably retro and I will probably provide a TinySound class that emulates a nes-style sound chip.
I suggest we try to keep things simple and focused for the first contest. When we wrap up this one and assuming it is a success then we can discuss what people liked/disliked and vote on changes for next year.
[quote]The 16 colour restriction will make things interesting. I’d like to write my own framework, if that’s Ok. It’ll probably feature a dynamic palette based on the colours of the various elements currently on screen. I might also look at palette switching at half frame rate to get more colours, although that might be going too far.
[/quote]
[quote]This sounds extremely awesome, and I’d love to be part of writing those frameworks if at all possible.
[/quote]
I anticipated people wanting to write their own frameworks which is why it will be allowed, but it will be required to be open source (just the main framework).
Great, I’m more than happy to open source the framework.
Sound should probably be three channel sine/square/triangle + one channel noise. Funny thing is I already have code for this. The noise channel was a bit tricky.
I really liked Marcus’ Eye of the Beholder GIF. It’s really raised the bar on my ambitions.
Sounds like a great plan! When do we start? =D
you haven’t already started? I have 
Why exactly it should be open source ??
I guess so people can see we’re not cheating and using non-EGA colours, or more than 16 at a time.
I’m not fussed, the code won’t have much instrinsic value and I’m assuming we post it at the same time as the entry.
[quote]Sounds like a great plan! When do we start? =D
[/quote]
Consider it officially under-way. I expect we’ll see a 40x30 version of Minecraft posted tomorrow…
[quote]Why exactly it should be open source ??
[/quote]
Just the framework (Screen class really) as Alan_W said so we can make sure it is following the rules.
Java only?
[quote]Java only?
[/quote]
Yes, and must not require any other functionality that would trigger a security warning.
Absolutely. I’m working on a 4k game which uses a total of 3 colours with 2-bit alpha. The particular combinations which turn up mean it could be implemented with a palette of 11 colours, although admittedly not all of them are in the EGA palette.
eww, was using Slick2D, guess I can just switch to Java2d once I’m done.
anyway had a go at making some fonts, so in case it help anyone else heres what I got
all number are 3x5 and all letters are 45 (apart from M and W which are 55).
[quote]eww, was using Slick2D, guess I can just switch to Java2d once I’m done.
[/quote]
Seriously, you were using Slick (like a few megabytes of libraries + OpenGL) to fill in 40x30 pixels.
Fontwise you can actually do a readable font in 3x5, it relies a bit on your brains use of shape to recognize words so you probably want to use lower case characters.
yup, was also using a Full JDK, 500mb IDE, Quad Core i7 Processor with a 1099511627776 byte hard disk ;D
wow thx, thats really cool.
Not sure if I have understood correctly. The framework (you mean the class extending Applet and draws the stuff?) should be open-source… but when we run each applet, don’t we then easily see if the game is following the rules? And for the graphics, my thought is to simply use png-images, having the look of EGA-graphics. How can the colour pallette of that be controlled in the source code? Or am I missing something?
Like you mentioned earlier, the difficulty in this challange is how to make a playable game on 40x30 px.