Color War?

[Thomas Jentzsch]

During my awakening I just got a basic game idea I would like to share. Not sure if one could make a interesting game out of is.

 

The Atari is pretty good at displaying lots of colors, so the game is based on colors and mixing them. Your opponent is throwing colored bombs are you and you have to modify your defense/shields to match the shots color. You are also bombing your opposite, but the color of your bombs has to be complementary of your opponents defense/shields.

 

There would be two bars of rainbow colors which can be controlled by the joystick to mix the colors for bombs and/or defense.

 

Both players have an energy reserve, which gets drained when you throw a bomb or are hit by a good (very complementary color) enemy's bomb and increases when you hit your opponent with a good bomb.

 

So far the basic idea.

 

The graphic representation could be very abstract, e.g. a colored (wobbling) bar at the top and one at the bottom, representing the two players, their energy level (bar height) and shield color. Bombs are large blobs of one color (maybe glowing), slowly moving up or down.

 

Controls is a problem, since you have to control your defense's color and your bombs color. So either the game has to be round based or both colors are identical (or automatically complementary). This is one important point for gameplay.

 

Variation ideas (just brainstorming):

- bombs can hit each other, causing bombs of new color

- different color schemes for each round

- permanent fire (a flow of bombs)

- ...

 

What do you think? Could this be transfered into a working game? Or does a similar game already exist?

[Robert M]

In my mind I am seeing a sort of SCSIcide dueling mode, but I don't think that is what you have in mind.

[Thomas Jentzsch]

...but I don't think that is what you have in mind.

Indeed. Because the core element should be mixing colors.

[Mirage]

I can't help since I don't program the 2600, but just wanted to say this would be particularly interesting for my wife and I to play, since we have been in the business of color for the past decade or more. Mixing colors in RGB to defend against colors attacking sounds like a blast! Please do this!

[Thomas Jentzsch]

Maybe you have some ideas how to mix colors. There are so many representations possible.

 

RGB values like you wrote? YMC? Two (partial) rainbow bars? ...?

[Mirage]

Maybe you have some ideas how to mix colors. There are so many representations possible.

 

RGB values like you wrote? YMC? Two (partial) rainbow bars? ...?

 

Well, my first thought would be to do RGB (definitely not CMY(K)) as the range for just CMY would be way too small, and it seems unnecessarily forced to use that, to me). Any other color space would be too obtuse, and I think enough people (geeks) have at least a passing familiarity with RGB. I doubt this would be a very highly technical game, right? Just see a color, and use the 3 (?) color bars to mix a color that looks like the target color on your screen? I guess you could start out with the "cursor" in the center of each of the three bars, so movement would be the same distance to either end, or maybe it would start in random positions, or all 3 at 0 (black).

 

EDIT: Deleted my obtuse discussion of L*a*b color space, because upon further thought, I really don't think it would be as good to use for this as RGB.

 

Those are my only thoughts right now. That, and there is at least one color mixing type game on the iPhone that might give some ideas, but I haven't tried it out yet.

 

Good luck! Really hope someone tries this! I'm not a 2600 programmer, but it seems to me that this game may be one of the "easier" (cough) to program, if one didn't go too overboard with features and detail. Sign me up now for a cart if it ever happens

Edited November 5, 2008 by Mirage1972

[+Propane13]

Sounds fun!

 

The only issue I think would make this a no-go project would be a certain unmarketable audience-- those who are color blind.

However, certain colors can be "seen", depending on how color blind someone is.

 

So, maybe there could be "regular mode" and "black and white mode" to meet that requirement.

 

Just a thought, if you hadn't considered it.

 

-John

[Thomas Jentzsch]

Well, my first thought would be to do RGB (definitely not CMY(K)) as the range for just CMY would be way too small, and it seems unnecessarily forced to use that, to me).

If I am able to implement RGB, implementing CMY would be very easy. So I could use that for an extra level. But see below.

 

Any other color space would be too obtuse, and I think enough people (geeks) have at least a passing familiarity with RGB.

Maybe hue combined with saturation and/or luminosity?

 

I doubt this would be a very highly technical game, right?

No, I prefer a fast action paced game. Maybe even up to a Kaboom! like game variation, where instead of moving a bucket you move color bars.

 

Just see a color, and use the 3 (?) color bars to mix a color that looks like the target color on your screen? I guess you could start out with the "cursor" in the center of each of the three bars, so movement would be the same distance to either end, or maybe it would start in random positions, or all 3 at 0 (black).

Probably there will be no reset position at all. You just constantly adjust the postions.

 

Those are my only thoughts right now. That, and there is at least one color mixing type game on the iPhone that might give some ideas, but I haven't tried it out yet.

Thansk, I'll try to get further information about that one.

 

Good luck! Really hope someone tries this! I'm not a 2600 programmer, but it seems to me that this game may be one of the "easier" (cough) to program, if one didn't go too overboard with features and detail. Sign me up now for a cart if it ever happens

The biggest problem will be the color mixing itself. I have to choose from fixed 128 colors and not all combinations will make sense. E.g. Red, Green and Blue do not exist as plain values (e.g. 255, 0, 0 and 128, 0, 0) but are all somehow mixed (e.g. 240, 10, 12 and 220, 40, 48). So not all mixing algorithms will work.

 

I will have to do some experimenting here first.

[Thomas Jentzsch]

The only issue I think would make this a no-go project would be a certain unmarketable audience-- those who are color blind.

This will probably become the first game with a warning sticker: "Not applicable for color blind people!".

[lucifershalo]

that could be quite fun, Thomas

[Devin]

Interesting idea. The Atari 2600 does excel at colors.

 

How about a game about a crazy painter? The character would have to mix paint to create the right shade - maybe to fix a missing spot on a wall, match some other object, etc.... The character naturally would have to match the color quickly, do the work, and go onto the next job.

 

It might be better not to use RGB in this case. When people mix paint, they do it just like we all did in elementary school: red, yellow and blue paint! ... and perhaps white for brightness.

 

That's my two cents.

[Thomas Jentzsch]

How about a game about a crazy painter? The character would have to mix paint to create the right shade - maybe to fix a missing spot on a wall, match some other object, etc.... The character naturally would have to match the color quickly, do the work, and go onto the next job.

How would you graphically represent those tasks?

 

It might be better not to use RGB in this case. When people mix paint, they do it just like we all did in elementary school: red, yellow and blue paint! ... and perhaps white for brightness.

Yes, real color mixing (additional, like you did at school), not mixing pure R, G, B colors.

 

At first thought, this mixing can be quit easy implemented in NTSC as the average of the two colors indices. So when I mix e.g. $40 (very dark red) with $88 (medium blue) I get $64 (dark violett). This works well, as long as the two colors used are pretty close together

 

Problems occure due to the circular arrangements of the colors and the not 100% fixed palettes the Atari 2600 produces.

 

The first problem shows when I e.g. mix $10 (yellow) with $90 (blue). The result should be green ($d0, which is (($100+$10+$90)/2), but the result would be $50 (magenta, the complimentary color). I think I have to define some extra rules here, for which colors are allowed for mixing and what kind of result is expected.

 

The second problem means, that the spaceing between the colors is variable, depending on the Atari's color adjustement. This especially affects the upper colors which are calculated with this variable spacing based on $10 (yellow). The spacing should be set up so that the colors would repeat after ~14-15 steps. But this means that e.g. color $f0 could be a greenish- or an orange-yellow. With a very wrong hardware adjustment it even could be green or orange or worse. So when I e.g. mix $f0 with $40 (red) the result is pretty undetermined. So maybe the game needs some kind initial of calibration step (good) or I, if that doesn't work I have to avoid this kind of wrap around mixing (bad).

 

Conclusion: Before I base a game on color mixing, these problems have to be sorted out.

[vdub_bobby]

Conclusion: Before I base a game on color mixing, these problems have to be sorted out.

Maybe (probably?) you would have to limit the color space; don't allow all possible combinations. And maybe give several color schema options, so the user can pick which one looks best on his TV.

[+batari]

Instead of trying to determine all possible color mixes, why not simply interleave two different colors by row, then swap those rows on every frame? On a television, the results should be reasonable, I would think.

[Thomas Jentzsch]

Instead of trying to determine all possible color mixes, why not simply interleave two different colors by row, then swap those rows on every frame? On a television, the results should be reasonable, I would think.

I thought about this too.

 

But due to my work for Boulderdash I know that if you e.g. mix complementary colors this way, the result will be gray. And gray can be mixed from a lot of combinations.

[Thomas Jentzsch]

And maybe give several color schema options, so the user can pick which one looks best on his TV.

I thought about a test picture, displaying $e0, $10, $20 and $f0, where the user can define how $f0 looks compared to the other three colors.

Edited November 6, 2008 by Thomas Jentzsch

[Devin]

How would you graphically represent those tasks?

You could have a graphical painter run around the screen. At the bottom, you can have 5 paint buckets - red, yellow, blue, white (make things lighter), black (darker). The character could run over to the can, hit the button, and that would increment the color level.

 

Yes, real color mixing (additional, like you did at school), not mixing pure R, G, B colors.

It might be easier to just implement a lookup table rather than try to solve the problem algorithmically. This way, you can just index into a buffer and retrieve the correct color. The main task would be to keep track of the values of the different base colors (before they are "mixed").

 

Adding a color can simply increment its counter. If its counter is maxed, the rest are decremented. White and black can use the same variable, one increments, the other decrements. This is kind of how we did it in school, we just kept adding a colors until we got the right shade. Sometimes, we might add too much of one.. and then we just added a TON of the others to make it "go away". We were so wasteful as kids!

[+batari]

Instead of trying to determine all possible color mixes, why not simply interleave two different colors by row, then swap those rows on every frame? On a television, the results should be reasonable, I would think.

I thought about this too.

 

But due to my work for Boulderdash I know that if you e.g. mix complementary colors this way, the result will be gray. And gray can be mixed from a lot of combinations.

That would make sense, because if you were to average the RGB components of some complimentary colors of the same brightness, you would have near-equal parts of RGB, which would be gray.

 

Careful choice of colors may prevent that, however. Two colors with varying whiteness (or whatever the technical term for that is) may not produce gray (though they may be grayish if you mix e.g. purple and green) and two primary colors should not either.

 

It might be possible to write a C program or something, given the RGB values from, say, the Stella palate, then average them, and select the combinations that don't have near-equal RGB values.

Edited November 6, 2008 by batari

[Mirage]

If I am able to implement RGB, implementing CMY would be very easy. So I could use that for an extra level. But see below.

 

Well yes, I didn't mean you couldn't do CMY, I just don't think it would be an appropriate color space for this game. Look at the colors you can mix with just CMY (without K). Just my opinion.

 

Maybe hue combined with saturation and/or luminosity?

 

Yes, I like that idea, hadn't considered it. If you can make that work, it may be a good idea.

 

No, I prefer a fast action paced game. Maybe even up to a Kaboom! like game variation, where instead of moving a bucket you move color bars.

 

Exactly... that's what I meant. It would not be a technical game really, but would rather be more of a fast-paced action game. Sorry for my awkward wording.

 

Probably there will be no reset position at all. You just constantly adjust the postions.

Okay, good idea, good thinking.

 

I think you are on the right track though, I'm sure you'll come up with something that will work well within the VCS's color limitations!

[Thomas Jentzsch]

You could have a graphical painter run around the screen. At the bottom, you can have 5 paint buckets - red, yellow, blue, white (make things lighter), black (darker). The character could run over to the can, hit the button, and that would increment the color level.

It see. That would be a bit like Typshop Trouble advanced, right?

 

Not sure if i want to go into that direction now. First I would like to try out some other, more abstract ideas.

 

It might be easier to just implement a lookup table rather than try to solve the problem algorithmically. This way, you can just index into a buffer and retrieve the correct color. The main task would be to keep track of the values of the different base colors (before they are "mixed").

Agreed.

 

Adding a color can simply increment its counter. If its counter is maxed, the rest are decremented. White and black can use the same variable, one increments, the other decrements. This is kind of how we did it in school, we just kept adding a colors until we got the right shade. Sometimes, we might add too much of one.. and then we just added a TON of the others to make it "go away". We were so wasteful as kids!

I hadn't though about that approach. Definitely worth noting.

[Thomas Jentzsch]

Careful choice of colors may prevent that, however. Two colors with varying whiteness (or whatever the technical term for that is) may not produce gray (though they may be grayish if you mix e.g. purple and green) and two primary colors should not either.

I have to make sure, that gray doesn't happen. Or maybe gray is just another color which has to be mixed. That way people would learn something about complementary colors.

 

It might be possible to write a C program or something, given the RGB values from, say, the Stella palate, then average them, and select the combinations that don't have near-equal RGB values.

The biggest problem is, that the palette isn't perfect and that a lot of consoles are set up much differently.

 

So the lookup table will be difficulty task. Especially because I can only test with emulator or my PAL TV:

[Thomas Jentzsch]

Well yes, I didn't mean you couldn't do CMY, I just don't think it would be an appropriate color space for this game. Look at the colors you can mix with just CMY (without K). Just my opinion.:

If you subtract from white, shouldn't you get the same number of colors as if you add to black?

 

I think you are on the right track though, I'm sure you'll come up with something that will work well within the VCS's color limitations!

If I don't loose track or interest or RL interferes too much. The later has happened way too often now.

[+batari]

Careful choice of colors may prevent that, however. Two colors with varying whiteness (or whatever the technical term for that is) may not produce gray (though they may be grayish if you mix e.g. purple and green) and two primary colors should not either.

I have to make sure, that gray doesn't happen. Or maybe gray is just another color which has to be mixed. That way people would learn something about complementary colors.

 

It might be possible to write a C program or something, given the RGB values from, say, the Stella palate, then average them, and select the combinations that don't have near-equal RGB values.

The biggest problem is, that the palette isn't perfect and that a lot of consoles are set up much differently.

 

So the lookup table will be difficulty task. Especially because I can only test with emulator or my PAL TV:

The only real issue I've noticed is that browns and yellows appear green on some consoles. In order to avoid greens, I actually made the Gingerbread Man orange ($2x or possibly $3x color, I believe.) Particularly, $1x and $Fx are the worst. But since PAL can't display those yellows or dark browns anyway, it shouldn't matter.

[Thomas Jentzsch]

$1x and $Fx are the worst. But since PAL can't display those yellows or dark browns anyway, it shouldn't matter.

$Fx is very much varying, yes. But i$1x should look pretty identical on all consoles, no?

 

BTW: Found one experimental color mixing game: http://mrl.nyu.edu/~perlin/experiments/colorgame/

[+batari]

$1x and $Fx are the worst. But since PAL can't display those yellows or dark browns anyway, it shouldn't matter.

$Fx is very much varying, yes. But i$1x should look pretty identical on all consoles, no?

 

BTW: Found one experimental color mixing game: http://mrl.nyu.edu/~perlin/experiments/colorgame/

$1x looks fine on my consoles. However, I originally made the Gingerbread Man color $14 and I got a comment asking why he was green.