As part of reverse-engineering pyNES for both docs and getting info so other people could continue work on it (given in most cases it isn't well-commented), I'm starting to make few simple games, first being an Asteroids clone. After doing that, I'll do few more complicated games like Space Invaders and Tetris both to test limits of pyNES and learn how it work internally.
May I ask, why you decided to do Asteroids? In my opinion, it is one of the least suitable games for NES hardware, because of sprite limitations (total and per scanline).
It is also certainly more complicated (CPU-heavy) than Space Invaders and Tetris - many freely moving objects of different sizes, with number of objects increasing as a level progresses.
It is also certainly more complicated (CPU-heavy) than Space Invaders and Tetris - many freely moving objects of different sizes, with number of objects increasing as a level progresses.
It is easier to write and largest asteroid sprite in my game is 16x16 pixels (2x2tiles).
Keep in mind that this will be very simple project, a poor-man's Asteroids if you will. Game will go to level three (3 big asteroids), then loop back to level one (one asteroid). Since this will be my first nes homebrew that isn't a hack (done few gfx hacks in my life, mostly for own amusement), I need to start small.
//edit: If I figure out how to work with nametables in pyNES, this will be title screen (done with NES Screen Tool):
//edit: If I figure out how to work with nametables in pyNES, this will be title screen (done with NES Screen Tool):
If one were content with multiple asteroids with similar graphics a la Atari, seems like one could use CHR animation and UnROM and put some asteroids in the background (re-write the tiles to get pixel by pixel movement), then use sprites for the rest (or for all the small ones, perhaps). It'd be a fun challenge.