Atari Anguna: bugs on a sixer

First, a brief bit of Atari history:  The original Atari 2600s had 6 switches on the front -- the power, B/W, Select, Reset, and one difficulty switch per player.  Later models moved the difficulty switches to the back.  All the Atari versions now have goofy names that the collectors call them.  The original "heavy sixers" were bigger and heavier than the "light sixers" but both are sixers (having the 6 switches).  You could also have a 4-switch "woody" (that still sported the awesome late 70's wood-grain), or the darker "vader".  Or poor saps like me have the cheap little re-released Junior.

Well, I had only tested Anguna on my Junior, and a 4-switch woody (and in the Stella emulator).  It worked fine, so I figured we were good (theoretically, all the models are supposed to work the same).

Well, I just found out that that's not the case.  The main character doesn't animate correctly on the sixers.  I'm not completely sure what to do about it -- how do I debug a problem that only shows up on hardware I don't have?

Current possibilities, from least to most painful:

1. Somebody on the AtariAge forums has a guess about a possible difference in the hardware, and I can just go fix it (this would be a long shot)
2. Get a sixer.  That means either buying one (maybe $50 if I'm lucky) or borrowing one.
3. Make changes. Email them to someone with a sixer. Wait for report. Try again.

Ugh.

Why retro games?

Recently my friend Bryan asked the question "Have you written before about what motivates you to create retro games?"

I've somewhat hinted at it a few years ago, but there's a few reasons:

Nostalgia is one piece of it. I grew up playing Atari and NES, and so the idea of being able to make a quality game for the system I grew up with is really fun.  As a kid, I wondered what it was like to make games for these systems, and spent hours sketching game designs on paper.  It's fun to finally get to do what I dreamed about back then. (I've wanted to make a NES game ever since the system first came out. After 30 years of preparation, I finally feel like I can pull it off!)

Another factor is the challenge, and how different it is from my day-to-day work programming.  I like programming, but the change of being so close to the hardware is a nice change..  The problems are somewhat similar to what I might solve at work, but really different in actual code.  And learning how new (old) video game systems work is not only a fun challenge, but also interesting from a history/nostalgia persepctive. (ie "oh, THAT'S how and why they did that on that game!").  Add in some crazy limitations (only 76 processor cycles per scanline!?) and you have a good fun technical challenge.

Really, the biggest reason, though, might be about the community involved.  For modern platforms (PCs, phone games, etc), the indie market is incredibly flooded right now. There are tons and tons of games being created all the time.  While there are a few crazy success stories like flappy bird, the vast majority of indie games don't really ever get noticed.  So you either pick a goal of just trying to be financially profitable (which requires more commitment than I'm willing to make right now, and a team of artists, musicians, etc), or just be happy making a goofy little game for the fun of it (which is what I did with Robo-Ninja).

In the case of Robo-Ninja, about 3000 people installed it.  Other than my friends, I got about one message about it, a couple of store ratings (some 1 star, some 3-5 stars), and that's about it.  I had fun making it, I enjoyed hearing from my friends that played it, but it just felt lonely, like I was riding a big crowded subway car alone in a big city.

In contrast, when I started making Anguna for Gameboy Advance 12 years ago, the GBA was just at the end of its commercial life, so it wasn't about retro gaming: it was just about the fun of making a homebrew game for a video game console.  What surprised me was hearing people talk about it. I'd get emails from people asking about it, reviews appeared on some websites, and there was a community of people to talk about it with.

Atari Anguna was also started just for the fun of it, but upon finishing,  people on the AtariAge forums expressed an interest in the game.  Realistically, it was a lot fewer than the 3000 that had downloaded Robo-Ninja. But it was a lot more fun and rewarding, having a small number of people be vocally interested, as opposed to a few thousand nameless installs.

The height of this was at last year's Portland Retro Games Expo when I got to chat with other Atari and NES developers, many of whom had made games I had played, and a number of whom had played and enjoyed Anguna.

So really, it's not just about the "retro" aspect of retro games, although that's part of it.  It's also about knowing that people play and enjoy my games, and getting to talk to them about it.  Right now that means retro gaming is the fun niche where I can make a cool game without a big team, have a ton of fun doing it, and hear about people enjoying it.  

Oh yeah, and retro games are hip right now.  I'ts fun to be doing something hip.

But who knows, I've always been a bit non-committal in my hobby projects. Maybe I'll suddenly decide I want to try something else in a couple years once I finish this game....

Starting the next game

Now that Spacey McRacey is done, it's time to move on to the next game: a large adventure game for the NES.

I've had two ideas in mind for awhile, either my Blaster Master-style metroidvania game that I've talked about before, or another Anguna sequel.  After asking around to see if I could find any artists interested in working with me, I found someone that's interested in doing the Blaster Masteresque game.  So that's where we're starting.

First steps involve picking some technology.  On the Atari, unless you were going for some crazy advanced cartridge with a co-processor on board (which was really rare back in the day -- I think Pitfall 2 was the only commercial game that did this), all the cartridges boards are pretty similar, other than ROM size and the exact method of bankswitching to map all that ROM to the limited address space of the Atari.  (Ok, some also had some RAM on board. But still, there wasn't all that much that was different).

NES cartridges are a different story. The NES was designed for the cartridges to have a bit more control, so there's a lot more variance depending on what cartridge hardware you're going to pick.  And certain types of cartridge hardware are more expensive to produce on actual cartridges than others.  So I need to pick a cartridge mapper type.  I've been doing some experimentation -- there's a new one out called the Cheapocabra that's both cheap and powerful.  The only downsides are the fact that not all the emulators support it yet, and it has no expansion RAM.   So I'm still trying to decide for sure.

The other question is whether I stick with pure 6502 assembly, or do a mix of assembly and C.  I've been doing some experiments with writing the core game logic in C, and dropping to assembly for the bits that need to have better performance, and it seems to be working reasonably well, so I think I'm going to start with that.

Next steps are to start thinking about a scrolling engine and internal level data representations.

Testing on hardware

Everytime I title a post like that, it's never good news.

We moved across town, which primarily means that I've spent more time fixing up an old house (to sell) and a new house (to live in) than I have programming for fun.  But I also had space to set up a nice desk space for writing/testing my games, including my NES and Atari attached to an old little tube TV (thanks, Jake!)

After hours of frustrating with faulty Compact Flash cards (remember those?), I finally got my PowerPak working, so now I can test my game on the real Nintendo! (as well as play all my NES games without fighting with dirty contacts every time!)

Well, as usual, it didn't go well at first.  Spacey McRacey was a jumbled mess of flickering as it scrolled. It bounced all over the place.

With some advice from the fine folks at nesdev.com, I had a number of things to try, but none of them worked.  BUT simplifying things by disabling my split-screen scrolling (the status bar at the top is locked into place by having a scroll split at it), and everything worked.

So I went back and tightened up the timing of my split screen scroll.  The NES PPU has some weird quirks, where underlying registers change automatically during rendering, so it's quite possible that I was taking too long, and things changed out from under me in the middle of setting up my split-screen scroll.  So optimizing the timing of the scroll actually ended up solving the issue.  WHEW, that only took about an hour (which is about 4 hours less than the time I've spent so far trying to fix the bad wiring in my house that fried my TV and desktop computer)

There's still one new issue that appeared on hardware that I need to fix, with the title screen getting corrupted, but I think I know what's going on there.

And here I thought I was done. Oops.