Saturday, June 15, 2019

Level Design in Earnest

Well, with moving platforms done, I decided I'm fair enough along that it's time to start doing "real" level design. I've got a bunch of maps that I've designed for demo purposes, so you can play through a bit of how the world will play, and I can test out how transitions work.  But they were never intended to be the real map.

So I've wiped out all that, and started now on the "real game."  And after a couple years of fiddling about with the engine, it's really refreshing churning out a few maps. 

Spoiler alert!

I've realized a few things:
  1. I'm bad at making interesting maps.  I have these big rooms, and it's hard to fill them with things that will actually be fun. I'm trying though.
  2. I don't have to go very far before I run into features that I need to add into the engine.  I hit the first save room quickly, a few days ago, and remembered that I hadn't implemented game saves. I got that added, then immediately started on a room with some 8-px steps (which the main character is supposed to be able to run up without jumping). Of course, I haven't actually implemented the running up stairs yet.  Time to do that I guess.
  3. Nothing reveals bugs like real content.  Just tonight, I plopped an enemy (the eyeball creepy crawly guy that I've used all over the place in the demo rooms) into my map, and he's broken.  WHY, computer, WHY!?
Exhibit A, in which I decide that I hate computers.

Friday, June 7, 2019

Moving platforms working

Ok, another lunch hour devoted to the platforms, and they're working!  My idea of how to make them ended up working perfectly.

I ended up wasting about 45 minutes though due to a stupid optimization. Instead of checking collisions against the full world coordinates of the player and platform (which are 2 bytes instead of 1, thus requiring quite a bit more instructions for the collision check), I was just caching and comparing their on-screen rendered coordinates (which is just 1 byte).  That works well EXCEPT for the fact that the player's render coordinates are calculated AFTER the collision check, meaning they're one frame behind.  For a lot of things, that one frame might not matter, but here it caused the player to keep getting stuck in the platforms.

Once I removed my silly optimization, things worked great!  Although I need to make some minor changes to the camera code. Right now the camera only scrolls horizontally when the player moves naturally, but not when the platform pushes the player.  Meaning currently a platform can drag you offscreen. That needs to change.

The nice thing about this addition is all the ways it can be used in gameplay: moving platforms, moving walls that get in your way, enemies that can be frozen and climbed, barriers that can get moved by a switch or trigger, etc.

Tuesday, June 4, 2019

Catching up, and Halcyon moving platforms.

Hmm. I haven't posted here in almost a year. I got thinking about my progress on Halcyon, and decided it was time to actually get back to writing about what I'm doing here.

I realized I didn't say a thing here about Super Homebrew War, my 4-player nes brawl, using characters from other well-known NES homebrew games, which scored 2nd place in this year's NESdev competition. 

Nor did I mention that I got inspired to try my hand at Dreamcast development. Like last year's port of Robo-Ninja Climb to the 2600, I decided to once again take my NES code, and try porting it directly to the Dreamcast. As usual, it took slightly longer than I hoped, but I now have a Dreamcast version of Robo-Ninja Climb finished.
The nice thing about Dreamcast homebrew is that you can test on hardware for the low price of a CD-ROM!

Now I'm back on to working on my metroidvania, Halcyon.  Tonight's challenge is obstacles/platforms that aren't part of the background, and thus can move around.  Like ramps, moving platforms are always slightly trickier than you'd think they should be.

After a few false starts, my current theory of how they'll work is like this:

  • Moving platforms are actually just an enemy instance, with a modified collision routine.  
  • During the enemy platform's update routine, I'll do a collision check: If the player collides with the platform, I'll move the player by the same amount that the platform moved. (which lets the platform push the player around)
  • During the player's movement, it will look for any enemies flagged as platforms, and handle collision results against them just like collisions against background tiles.
  • During the enemy's movement/collision checks, the collision box of the platform will be adjusted to be a tiny bit larger than during the player's collision checks, so that the platform will "grab" the player and move it if the player is riding on top
Believe it or not, but that moving thing above the tank is a platform.

I spent the evening writing the first half of this (the enemy update phase, which can move the player around).  Hopefully tomorrow or soon I'll get to the 2nd half (the player's adjusted collision routine), and we'll see if my theory works out.

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!

Level Design in Earnest

Well, with moving platforms done, I decided I'm fair enough along that it's time to start doing "real" level design. I&#...