Ok - you got Grumpy's hackles up, but he does have a point - so you can:
-
Re-state that you want to use black-and-white video output, viewable on NTSC or PAL television systems (or just say you want to use the TVOut library and be done with it)
-
Or give up on the whole TV output thing, and go with VGA using a Gameduino shield
Now you haven't said how you plan to get the games on to the Arduino that is running them; if you just plan to dump them individually via the Arduino IDE (and/or an ISP - if you need the extra flash space), then probably no problem.
However, if you are looking to do something that like a "cartridge" or similar - you're going to run into some headache. Even there, though, I think with the hardware you have, it might be possible. How?
Well - let's say you use the single 328 to host the game code; your game code would consist of all the logic and data necessary to run/build/draw the gamefield, as well as communicate with peripheral processors. The "peripheral processors" in the meantime would be the two 168 processors. One 168 processor would be dedicated to "game loading". The second would be dedicated to "sound output". You might also use the second for "joystick/pad" input. Or you might press the Atmega8 processors into this service...
The 328 would be a "bare-bones" 328; no need for a bootloader (it could even be an Arduino, if you wanted to use the VGA shield - it just doesn't need the bootloader). All of the other peripheral processors (168 and 8), with the exception of the "game loading" processor, would be "slaves" on the I2C bus; there would also be code in your game (as part of your game library code) to communicate with these slave processors over I2C.
The "game loading" 168 would serve only one purpose - to act as an ISP programmer; this is where it gets tricky and might all fall apart (I haven't designed any of this - I am talking out my rear here, and haven't consulted anything - so take this all with a grain!). It would run the ArduinoISP programmer (you might load this sans bootloader as well), but it would read the hex file off of a pre-prepped SD card, then send it to the 328. Where it could all fall apart would be memory needs (can you fit the ArduinoISP sketch, along with SDFAT read capabilities - and who knows what else - all in a 168? Could it be done in a 328 even? I don't know - something tells me it will be tight, if possible at all - you would probably have to customize everything to make it all as small as possible), as well as pin needs (can you use/do ISP while reading from an SD card? Can other "non-standard" pins be used? Are there other solutions to make the pins available - maybe in a blocking manner?). If you can clear that hurdle...
Then the idea is that you stick the card into the reader, hit a button, and a hex file on the card is read, dumped to the 328, and then the 328 is reset (by the "game loader"?) to start the code running. It then acts as "master" to the i/o slave 168 and/or 8 via I2C (once again, if pins are available - maybe you have to use software serial instead); one of the processors gets input from the controls and passes the data on when requested, the other acts as a sound generator to play music and/or sound effects, etc (this can be as simple or fancy as you want - for starting out, just getting it to play simple tones or tunes based on commands/data dumped to it would be fine).
But like I said - take it all with a grain, as I haven't researched much on the specifics of whether this is all possible; it sounds great in theory, but practice (after a lot of research) might mean something very different...
Pong, Frogger, Asteroids, Breakout ..that's all.
