Sunday, October 16, 2016


Thanks for the title suggestions everyone!

The 3 suggestions that I like the best were:

  • Pew Pew Pew
  • Reginald McGillicutty's Big Boom Blast Party
  • Spacey McRacey

After some thought, I decided:

Pew Pew Pew just isn't google-able enough. There's too many cultural references to "Pew Pew Pew" nowadays, which will make my game get buried even if people are looking for it. And alternative spellings (someone suggested Pew Pue Pu) are just too weird.

Reginald McGillicutty blah blah blah....I love this one from author Jeffrey Aaron Miller. What disqualifies it is really the format of the game required for the game competition I'm hoping to enter with this. The requirements of the game use a NES cartridge format that's quite limited in video ROM, which means I have to share space between the title screen and gameplay.  Which means I can't spend a ton on a giant fancy title screen. (Unless I'm misunderstanding the specs of the format, which is quite possible).  

Which leaves Spacey McRacey. Which is what I'll go with for now until something changes my mind otherwise.

Tonight's work was the "start game" screen (not the title screen), where players push start to register that they're in the game. (since it's a 4 player game).  Mostly, that involves drawing 4 big frames on the screen that each say "press start".  So I've been working on a reusable routine for drawing frames on the screen of arbitrary size and location.  

That's a task that should be pretty easy. But with the limitations of the 6502 combined with the oddities of how the NES handles background data updates, it's slightly more complicated that intuition would lead you to believe (to write any given chunk of background tiles, you have spend 4 instructions telling it what tile address you want to write to, then serially write data to a register, which is great for horizontal or vertical stripes, but annoying for an arbitrary rectangle in the middle of the screen, as you have to keep re-positioning the address register).

Anyway, it's getting there!

Saturday, October 8, 2016

Rapid Progress

I told my office-mate that if I ever finished that background mess, I'd start making much faster progress.  And it turned out to be true.

Earlier this week, I decided it was time to look at audio engines. I understand the concept of how audio engines work on the nes, but I just don't want to take the time to build one myself.  After trying out a couple of them, I found one that integrated really easily, and lets you play music imported from the popular famitracker format. After digging around, I found some interesting famitracker compositions under a Creative Commons license from a guy that goes by Turned out to be a really nice guy and was helpful in providing me info to get some of his music integrated into the game. So now I have background music!

The next steps were collision checking, explosions, and player bullets. No problems there!  Most of that is pretty simple stuff, or would be in C. In assembly, it's a little more error-prone and slower-going, but not substantially more difficult: the logic is the same, but at a lower level. In just a few hours of work this week, I've those things all working!  (Well, there's still a bug where if a barrier's gap isn't aligned on a 16-pixel boundary, my collisions don't work quite right. Should be easy to fix though).

At this point, it's quickly starting to take shape!  I just need to add the points system, and suddenly the skeleton of the game is complete.  Then comes the fun part: adding the actual polish.

This includes:

1. Title screen and screen to select number of players
2. Sound effects
3. More interesting background graphics behind the barriers
4. Powerups
5. Different rounds with slightly different behavior

The last one needs a little more explanation.  The first round will be straightforward, with no tricks.  To keep it interesting, subsequent rounds will have a theme, such as:

  • Speed round (everything is super fast)
  • Battle round (the barriers are spaced out more easily, but everyone is maxed out with all sorts of weaponry, and you also gain points for kills)
  • Collision round (touching other players kills you)
  • Survival round (you lose points for dying)
  • (and I'm trying to think of other similar ideas)

That all being said, send me ideas for a title. I'm serious, I need help with this.

Monday, October 3, 2016

PRGE, and I need a name

It's been awhile since I posted anything here!

First off, Anguna 2600 is pretty much done. I'm currently in the process of working on some promo material for the Portland Retro Game Expo, where we'll be showing off the game at the AtariAge booth.  I'm excited to be in a giant room full of people that are into retro-gaming, and have my game on display.  Should be a fun time.

I'm still slowly working on the nes game I talked about. I got hung up for awhile on displaying the barriers. I just kept running into bugs trying to get the game model to work right, then have it render properly based on the game model.  Part of it was scrolling -- the game has the appearance of scrolling through a world, but because the 6502 is only an 8-bit processor, I didn't feel like doing the math to track giant scroll values. So it's somewhat fake in terms of in-memory model.  The barriers move, the player stays motionless.  But because the nes background register is scrolling, (and it thinks that the top of the screen is 32 pixels off because of my top status bar), and because of mistakes I made while using fixed point path, and because the vertical resolution wraps at 240 pixels instead of the nice 256, I kept getting my math slightly off.

(it would have been easier if I just decided it scrolled 1 pixel per frame, so I'd know that every few frames, we'd hit an exact 8-pixel boundary, and would know to draw the next tiles. But because I'm scrolling by a variable amount (using fractional fixed-point math), it's more work to know when I cross that boundary.

Anyway, I FINALLY just threw away most of my background code and sat down with a pencil and paper and worked all the numbers out on paper, then re-coded it to match my paper-work. It worked much better when I did that.

Once that was out of the way (ok, I'm lying somewhat...I still have some issues with the background palettes, but I'll tackle that math later), I've finally got back to some of the game logic -- player collisions, etc. Fun stuff.  Today it was adding explosions and resetting the player position when you hit a wall:

It's actually started to vaguely resemble a real game at this point.

Next up: I need a title.  It's a party game with spaceships racing through barriers. My first thought was "Space Jam" until I remembered that that was that terrible movie with Michael Jordan. (Ok, I never saw it. Maybe it was actually awesome?)  I need a name.  And eventually a cool title screen to go with it.  Any suggestions?

Monday, September 5, 2016

Backgrounds and debugging

One of the hard things. Ok, so far the ONLY hard thing about NES development is how the background tile maps work.  In theory, they're pretty simple -- a big array of memory where you write a tile number, and the PPU (the video chip) draws that tile at that position.

But there's so many little gotchas:

  • The nes addresses 4 different screens' worth of data, but by default only has ram for 2 of them. So unless you provide more RAM on the cartridge, you set up (via actual wiring on the cartridge!) mirroring where data is duplicated between screens. 
  • The screen nicely pans and wraps between screens'-worth of background data. Except that there's only 240 tiles high, so you have to do math instead of letting bytes just wrap around
  • Setting color palettes for tiles is painful -- you do it in a separate block of memory, mapped in a funky way where you map 4 tiles to 2 bits of a particular byte.  Which means you have to do odd math to work out how to change colors of backgrounds.
  • Mid-screen scroll changes are weird.  To do a header bar, many games will switch scroll positions after the header (since there aren't layered backgrounds). But switching scrolling mid-frame requires more weird math, because you can't just write to the scroll registers like normal -- you have to do weird gymnastics with the various PPU registers instead.
It's not horrible, but it's driving me a little crazy. Really, I just wish I had better debugging tools. I got really used to Stella (the Atari emulator)'s quirky debugger, and realized how awesome it was. The nintendo debuggers I've used just aren't nearly as usable, at least with my current level of experience with them.

This is a debugging diagram of the four screens of data. I'm mirroring vertically, so the top and bottom are cloned.
The left half is my game background. The right half is the header bar.
Each frame, I start by telling the NES to set the scroll to where the header bar is.
Once it's drawn, I reset the scrolling to point to the correct position on the left half.

I finally broke down today and wrote routines for my game that let me do some primitive on-screen debug messages, displaying decimal versions of values using the player score headers. That will help, I hope.

Tuesday, August 23, 2016

Atari vs NES

It's really interesting to me the differences and similarities between Atari and NES programming. They both use the same 6502 processor (well, a variation on the same processor -- the Atari's is missing a few address lines, and the NES is missing a BCD mode), clocked at similar speeds (the nes is about 50% faster).

But beyond that, things start to diverge.  The most interesting to me is fundamentally where things happen, based on how their video chips work.

On the Atari, the video chip (the TIA) is designed to handle a scanline at a time. Which means that, like I've mentioned before, the whole time your TV is drawing, you spend that time babysitting the process, using all your processing time updating each scanline.  Then during vblank (the time the TV is repositioning the electron beam), you get to hurry and do your game logic updates.

On the NES, it's practically the opposite. The video chip (the PPU) is designed to handle a whole frame at a time (GASP!).  So during rendering, unless you're doing any fancy effects, you get all that time free to do your game logic updates, while the PPU does its thing in the background. Then during vblank, you hurry to push new data to the PPU so its ready for the next frame.

There's still hurrying involved in the NES -- there can be a lot of data that you want to shove into the PPU (new tiles for scrolling, etc), and not a lot of time to do it (most video data has to passed to the PPU over a janky serial interface, written one byte at a time), but compared to the Atari, I feel like I have EONS of time to work with.

It also helps having more RAM than I know what to do with. The Atari had 128 bytes. The NES has 2048 bytes. (Two whole kilobytes!)  It's crazy town.

There's still some challenges. Talking to the PPU is weird, you're limited to only 8 sprites per scanline, mid-screen scrolling (ie if you want to add a status bar) is tricky.  But so far, it's a different world.

Sunday, August 7, 2016

NES Game and LiveCoding

Well, I started messing around with making a NES game. I'm not sure I'm ready to tackle another big project right now, and there's still bits of work to be done with Atari Anguna (mostly fixing bugs as they get reported, then getting it ready for production), so I'm doing a little project:  sort of a simple 4-player space race game.

Tonight's tasks was writing the code to support the 4-player adapter, and scrolling the starfield.

The fun part is that I thought I'd try LiveCoding it, which is basically where you live stream yourself writing code and explaining it as you do.  I've tried this for the past 3 nights.  It's a really weird experience.

First, I don't know why anybody would want to watch someone code. I mean, at least watching someone stream video games is interesting because there's a lot of action. Coding is mostly thinking and typing.

Second, it's REALLY HARD.  Now I'm trying to do all my thinking out loud. Which is a really weird process.  Everything feels blurry and sluggish in my head. I feel like I'm not coding well, and not explaining well.  Maybe it gets easier, I don't know.  Then on top of that, trying to actually be somewhat entertaining while coding and talking?  Yeah right.

Third, I'm used to writing my hobby game code in the late evenings, as a way to sort of wind down. Only this doesn't wind me down, it winds me up. I've been finishing a bit after 11, and I'm all jittery and high-strung. There's just no way I can go to bed after spending an hour performing for strangers on the internet.  And I can't really do it sitting next to my wife on the couch as she watches TV, which is normally where the coding happens.

So I don't know how long this will last. On the one hand, it's tons of fun, because I have an audience. On the other, it's exhausting.  But hey, I might as well have fun with it for now.

Friday, July 29, 2016

Finished world map

Well, I'm still making a few tweaks (the most recent was based on feedback that the off-centered sword was annoying, so I made the sword centered by default, but let you use the difficulty switches to change it back to the old off-centered setting), but thought I'd share the final finished world map:

Sunday, July 24, 2016

Beta Testing Time!

Ok, Anguna 2600 is ready for some testing!  I'm looking for testers to try playing the game (either in an emulator, or on an actual Atari with a Harmony cart or similar device), and let me know what bugs and issues you find!

The main features aren't likely to change at this point, but I'm looking to fix any bugs and possibly tweak the game difficulty.

You can download the instruction manual and current build from this post on AtariAge.  Please email me (nathantolbert at gmail) or leave comments if you find any bugs or issues.  If you find any problems that I fix, I'll also credit you in the instruction manual if you'd like, if so, let me know how I should credit you.

Next steps:

  • My friend Tim Lapetino, author of the upcoming Art of Atari book, is designing art for the cartridge label (hopefully to be re-used on the manual as well).
  • I'll be updating the game and manual to fix any issues found during the beta test
  • Hopefully later this fall, if all goes well, everything will be finished, and I'll do a cartridge release through the AtariAge store.

Tuesday, July 19, 2016

First full playthrough finished!

When I get near the end of a video game release, I have this phase. Where I play through the game, fix all the bugs I found, play through it again, fix all the bugs I found, play through it again....and so on....until I finally play through and don't find any new bugs.  (I've done this before)

It's somewhat miserable. But here we go again.

I finished the first full-playthrough tonight. Fixed a ton of bugs. Tomorrow I need to do another full playthrough, and then attempt a full playthrough on the actual Atari (which I'm not sure if I'll pull off, because my Atari controller is in poor enough shape that it will be really painful to go through the whole game!)

For anyone that wants to try the always-newest build and help me test, you can grab it from my jenkins server, which I'll be happy to email you the address to.....

Sunday, July 10, 2016

Tons O Bugs

Well, my friend Daniel (AmishHack3r on Twitch) decided to give my game a try. And let me tell you folks, this guy is an amazing tester.

He found ALL SORTS of bugs for me. And diligently recorded video of each one, made drawings on a map of areas with glitches, and so on.  I couldn't ask for a better tester, thanks Daniel!

That being said, I have a lot to fix!