Friday, July 6, 2018

Robo-Ninja Climb 2600

So I had this crazy idea.

The game logic of Robo-Ninja Climb is really simple. And so is the display. So in theory, with the NES and the Atari 2600 both having the same 6502 processor, I could take the NES source code for the game, rip out the rendering bits (and sound and controls), leaving just the core game logic, move it directly to the Atari, then rewrite all the rendering stuff.

In theory, this is made even easier by the fact that the Atari has built-in collision detection. On the NES, about half the work was tracking where you had scrolled, so you could do the math to compute collisions against spikes. On the Atari, I don't have to do that -- as long as I can draw them, it will do collisions for me. Which saves a ton of processing time.

So I got to work. First thing was stripping down everything I didn't need, replacing the controller code, and bringing over the main character physics. That went smoothly, and compiled for the Atari quite quickly. Of course, then I had to find a way to see if it worked.

It's certainly not as pretty as the NES version

Which meant writing an Atari kernel. I think it's somewhat like what women say after having a baby -- after a few years, you forget the pain and only remember the happy parts. Back to counting cycles, trying to squeeze everything into the 76 clock cycles per scanline. Ugh.

But it turns out it wasn't as bad for this game, as there's not nearly as much on the screen  (Anguna had a multi-color player, a  variable-length player missile (sword), changing playfield, a single color enemy, and en enemy missile. This has a single-color player, changing playfield, and single-color enemy. So not as bad.)

Anyway, after all that, I've got most of an Atari port of Robo-Ninja Climb working. Over the last few weeks, I've been slowly working through the more tedious or difficult parts: rendering items, adding title and level transition screens, etc. With a few more hours of work, I might have a Robo-Ninja Climb port for the Atari! (and I wonder if it's the first Atari port to ever directly use source code from the NES game that came first?)

Yes, I'm still working on the BlasterMasterMetroidVania game. And the 4-player adapter. I promise.

Wednesday, March 21, 2018

I blame Twitter

Huh. I haven't posted here since last December.  Not because I'm not doing things. But mostly because of all the NES dev folks that hang out on twitter and discord, so I've been posting short status updates there along with my usual twitter nonsense.

But because in 4 years when I come back here to this blog to try to remember what I was doing in early 2018, here you go future me. Turns out I have WAY too many projects going on at once! Begin wall-of-text mode!

  • I've got cool destroyable blocks going in my metroidvania game, and the basics of some enemies. I've added music thanks to the awesome sound engine that Derek of Gradual Games made. And unfortunately, I've realized that the current version of the game won't actually boot and run on hardware. UGH.  I think on EVERY PROJECT I've ever done, I say "oops, I wish I would have tested on hardware sooner."  Time to pare things down and figure out where it's going wrong. Hopefully in time for Midwest Gaming Classic, where I hope to show it off a little.
I also added a map screen to help you figure out where you've been. 

  • The Atari 4-player adapter hit a slight roadblock when I realized that there's something causing a weird static/flicker on the screen whenever player 4 moves their controller. It's hardware-related, not game-related, so I've been needing to do some hardware debugging, which is HARD. Thanks to some advice from Paul at InfiniteNESLives, I've added some capacitors in the last week or so, and they seemed to have helped. But now (based on some suggestions from another awesome Atari homebrewer, John Champeau), I've decided to test another design, based on 2 separate 1-to-2 joystick adapters, which gives some more options for a game to work with other peripherals at the same time (ie 2 joysticks plus an AtariVox speech synthesizer). We'll see how that goes -- I have the parts and the design should be pretty quick to slap together, but after that, I'm stuck in the same "how do I turn this from prototype to production" situation.
Yeah, I'm pretty sure that's NOT the recommended way to attach the capacitors to my board

  • Speaking of hardware, I've also started helping Kevin from KHAN games (he pronounces that K-Han, not KHAAAAAN, which is crazy) on a project that involves connecting a NES to the internet.  So I've rigged up my raspberry pi to my NES via the controller port, and I've been trying to get them to talk. So far it's been mixed results, but this week I managed to get the PI to tell the NES to print the alphabet. Until halfway through the screen, when things got horribly out of sync.  I'm going to have to read up on serial protocols and error checking, I think.  
Things were looking good until suddenly they weren't.
  • The results came in from the NESDev competition. Robo-Ninja-Climb got middle-of-the-pack results, which is what it deserved. The entries were really high-quality this year, so I'm pretty satisfied with where I ended up. If you want to hear me attempt to talk about it on the Assembly Line Podcast, now's your chance.

  • Speaking of the competition, I decided to make a multi-cart of my competition entries (and in theory, will update it each year with any new small games that I make for the NES). So I spent the last couple weeks modifying my competition entries to work on a different board/mapper.  That took a bit of work, as the new mapper (GTROM) uses ram instead of rom for tile graphic data (chr-ram), and four screens-worth of tile map data (nametables) that I have to account for. But now I have a slick demo cart to show off my games. If I can't get the Blastervania game ready by MGC, I'll at least have something to demo!

Sunday, December 17, 2017

Half-height collisions

I'm back at the metroidvania game tonight. I had just gotten collisions mostly working, at block sizes of 16x16 pixels.  But the artist I'm working with (the amazing Frankengraphics) asked if we could do it at half-height -- so 16x8 pixel collision resolution.

One thing I've learned in life is to try to say yes to every feature the artist recommends. It will make your game better (which is why the original Anguna turned out so well: Chris had tons of great artistic suggestions, which required me to completely rewrite the engine after he came on board!) 

In this case, I reserved 1 byte of data for each metatile of 4 16x16 blocks, which means 2 bits per block. That could allow 4 different collisions types: open, blocked, destructable, and "special" where special depended on the room (with options being things like lava, water, etc). To add half-height collisions, something was going to have to change. But I didn't want to re-tool the whole engine to support EVERYTHING operating at a 16x8 level.

So the answer I settled on (for now, at least...we'll see how it works) is that I'll add an extra byte of collision data per metatile, meaning each block gets 4 bits, which is 16 different collision types. One of those collision types is half-high-blocked.  So I check for that separately in my collision routines, but everything else (block destruction, etc) can still operate at the 16x16 pixel level, which should make everything easier.

We'll see if that holds true....

It's hard to really tell, but the big block that the vehicle is
sitting on near the top-left is 32 pixels wide, and 24 pixels high.  Meaning the top
layer is 2 half-high-collisions.

Wednesday, November 29, 2017


I just realized I never did a post after the Portland Retro Game Convention talking about how great it was!

The first great part was just standing in line to get in.  I started chatting with the fellow in line behind me, who not only was familiar with my Atari version of Anguna, but had actually bought a copy just a few weeks before the convention!

The convention itself was a blast -- the biggest highlight was meeting (in person) many homebrewers that I've gotten to know in the AtariAge, NesDev, or NESDev twitter communities.  It's nice to finally put faces with names (or real names with internet names!).

Other than that, I spent a lot of time hovering in the background, watching people try out the Quadtari. It was fun seeing people pick it up and give it a try.  (What surprised me most was the number of teenagers who had no idea how to hold an Atari joystick.)  At one point, Joe Decuir, the engineer who designed much of the hardware of the original Atari, made a stop by to see it!

As they were walking away from trying Quad-Tank, I overheard of these guys say,
"That was the most fun I've ever had playing Atari!"

Albert, the mastermind behind AtariAge, hard at work.

Now I have a lot of work to do. The first prototype took me hours of soldering, about $25 in parts, and is already getting a little unreliable after being jostled so much.  So it's time to design a proper PCB and it get it properly made.  I've got a board designed that I hope is the same as what I prototyped, and I'm in the process of getting quotes on PCB fabrication and soldering assembly from a place in China. We'll see what happens!

3 weeks

So one of the main goals of Robo-Ninja Climb was to see how quickly I could crank out a reasonably playable NES game.  Nothing ground-breaking, but a short fun game.

The answer is 3 weeks of evenings.  Approximately 40 hours, maybe. I've got a game that's certainly playable (although by all reports, a little too hard. Oops, I'm bad at that) 

I decided partway through to ditch the "endless" part of it -- I realized I didn't have a good plan for making random levels that were actually fun to play.  So I designed 5 short levels, with a few power-ups part way through.  Each has slightly different background graphics, to give the player a sense of progression.

A few thing that I felt like were somewhat interesting during the development:

  • I used the NES's Sprite-0 flag to make the spikes at the bottom not scroll away with the background. But to make it more interesting, I cycle sprite 0 up and down slightly, to make the spikes bounce and look a little scarier.  
  • Robo-Ninja is a giant character by NES standards. Most games have characters that are 16x32 or so.  Robo-Ninja is 32x48 or larger (depending on the animation frame).  I can get away with it because there aren't many other sprites in the game.  Most games have enemies, bullets, and so forth to deal with. Robo-Ninja mostly dodges background elements.
  • I didn't feel like mapping levels out manually in a tile editor (mostly it's blank space!), so I mapped them all out using text like this, and then have a pre-processor as part of my build script that converts it to actual binary level data:


Well, other than collecting feedback, tweaking difficulty, and possibly adding some music from another composer, I think it's done. And I still have 2 months left before the deadline! You can try it out using any NES emulator, and grabbing the rom from my bitethechili site.  If you do, let me know if you have feedback!

Friday, November 10, 2017

Robo-Ninja Climb

Well, out of the blue, I decided that I was missing out by not entering something into this year's NesDev competition, so a couple weeks ago I decided to see how quickly I could churn out a simple-but-fun game.

My idea is an endless-climber type of thing, based on the Robo-Ninja character. You just bounce back and forth scaling walls while dodging obstacles.

It's been fun, trying to churn this out as fast as possible.  To be as efficient as I can, I reused a number of routines from my primary nes project, and then have been coding everything in a mix of C and assembly, switching back and forth at whim, using whichever seems easier for any given part of the game.

I just finished my 7th day of development, and it's almost a playable game -- I just need to make collisions with the obstacles actually work, and tweak the controls a bit, and it will be time for some preliminary testing: the standard "is it actually fun" sort of thing. We'll see.

There's a lot more I'd love to say about some of the technical challenges of writing this game, but with trying to finish it as quickly as possible, I end up not wanting to waste time writing about it.

Like last year, I don't have a lot of intentions of winning the competition, but I couldn't pass up a chance to at least enter something.

Tuesday, October 17, 2017

Metatile Designer

For the NES game, I'm building my levels out of 32x32 pixel metatiles.  What is a metatile?  The NES background tiles are 8x8 pixels, but that's too small for a lot of purposes.  Loads of games were built out of bigger blocks (16x16 is very common, which is what Mario or Zelda used, making the standard "block" size you see in many NES games).

The smaller your blocks, or metatiles, the more ROM space a level takes up, but the more flexibility you have in laying out your levels.  For this game, I'm planning to use 32x32 blocks.  (which I've built the whole engine around, so if that changes for some reason, I'm in for a lot of work)

Here's a picture of Super Mario Bros.  By this time your eyes are glazing over
and you don't even remember why I was talking about Super Mario Bros anyway.
Warning: the next paragraph is even worse.

The reason I chose 32x32 is because of how the NES handles palettes. In memory, there's a byte for each 8x8 pixel space on the screen, to indicate which tile should be drawn there. But each tile can have one of 4 palettes, and that byte doesn't include any palette information. There's another block of video memory where you assign palettes to tiles.  BUT, there's a few limitations.  You can only assign one palette for every 16x16 pixel block (group of 4 tiles), which is one reason it's so common to have blocks that size in games.  AND 4 of those groups (a 32x32 pixel block) shares a byte in memory (2 bits for each 16x16 block).  So in my case, each 32x32 metatile can map to a byte of palette memory, which simplifies writing palettes. 

So between the ROM savings for large levels (64 bytes to represent a single screen) and the ease of writing palettes (also called attribute tables), I picked 32x32 metatiles.

Now the problem is that I need a better tool for designing my metatiles.  There are a few tools out there (NES Screen tool by Shiru, Sumez's editor, etc).  But for one reason or another, none of them quite did want I wanted.  So it was time to start tool building, which is a sometimes-miserable, sometimes-nice distraction in the middle of a project.

In the past I've tried a few different technologies for quick-and-dirty gui tools.  It used to be Borland Delphi.  Then C#.  Then the web with either raw javascript, or Angular.  This time I wanted something cross-platform but I hate the web, so I decided to try javafx, which I've heard is decent.

I considered forcing myself to use Kotlin or Clojure for the sake of learning another language, but once again, the pragmatism of getting something done quickly set in, so I cranked it out in java.  Java 8's lambdas makes gui programming a little less unpleasant, so it didn't take long to have my metatile designer working but ugly.

Now it's time to actually try to put together some decent-looking metatiles and start building a cool demo level.

Robo-Ninja Climb 2600

So I had this crazy idea. The game logic of Robo-Ninja Climb is really simple. And so is the display. So in theory, with the NES and the A...