40x30 EGA Contest

[Markus_Persson]

I'm ABSOLUTELY in!

Here's a 40x30 EGA remake of Eye of the Beholder II I started on a while back:

[Markus_Persson]

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?

[dishmoth]

I vote that we limit it to 16 colors on screen at once, and strictly those available in EGA.

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

Games published by our own members! Check 'em out!

[Markus_Persson]

I think it should be allowed, yes.

But it's really up to ShannonSmith. =)

[Roquen]

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).  

[kappa]

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.

[Markus_Persson]

But isn't the point kind of to MAKE it hard?

[ShannonSmith]

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.

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.

You can't really alpha blend with only 16 colours, but I will include an image format that includes bitmask transparency in the framework.

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).

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.

[bobjob]

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?

[dishmoth]

we should probably come up with a catchier name than 40x30EGA first though.

Going with a Java/coffee theme, how about "Pixel-latte"?

Actually, no, that's rubbish.  Forget I said anything.

Simon

Games published by our own members! Check 'em out!

[bobjob]

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

[Roquen]

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.

[ShannonSmith]

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.

[dishmoth]

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

[Markus_Persson]

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.

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?

[Alan_W]

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.

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.

[ShannonSmith]

Any thoughts on sound?  Should it be as restricted as the visuals?

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.

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.

This sounds extremely awesome, and I'd love to be part of writing those frameworks if at all possible.

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).

[Alan_W]

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.

[Markus_Persson]

Sounds like a great plan! When do we start? =D

[kappa]

Sounds like a great plan! When do we start? =D

you haven't already started? I have

[teletubo]

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).

Why exactly it should be open source ??

[Alan_W]

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.

[ShannonSmith]

Sounds like a great plan! When do we start? =D

Consider it officially under-way. I expect we'll see a 40x30 version of Minecraft posted tomorrow...

Why exactly it should be open source ??

Just the framework (Screen class really) as Alan_W said so we can make sure it is following the rules.

[Eli Delventhal]

Java only?

[ShannonSmith]

Java only?

Yes, and must not require any other functionality that would trigger a security warning.

[pjt33]

The really hard part is trying to get a decently playable game in 40x30 pixels.

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.

[kappa]

Yes, and must not require any other functionality that would trigger a security warning.

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 4*5 (apart from M and W which are 5*5).

[ShannonSmith]

eww, was using Slick2D, guess I can just switch to Java2d once I'm done.

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.

[kappa]

Seriously, you were using Slick (like a few megabytes of libraries + OpenGL) to fill in 40x30 pixels.

yup, was also using a Full JDK, 500mb IDE, Quad Core i7 Processor with a 1099511627776 byte hard disk 

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.

wow thx, thats really cool.

[fruitmaze]

Consider it officially under-way. I expect we'll see a 40x30 version of Minecraft posted tomorrow...
Just the framework (Screen class really) as Alan_W said so we can make sure it is following the rules.

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.