Stairs and a hoppy guy

One thing that Frankengraphics (the artist I'm working with) suggested was adding 8-pixel tall blocks that the character could run/drive up without jumping. Sort of like ramps, only without the continuous nature. I've been putting it off, because ramps are weird.

I finally decided to tackle it in the last few days. And it turned out that the discrete nature of the steps, combined with how I've handled collisions so far, made them really easy.  As in 30 minutes of work, and they just worked.

Finally got around to adding stairs that you can climb without jumping. I was expecting it to take 4 hours, only took about 30 minutes. One of those rare magical moments when my code actually works.#NESdev #halcyonNES pic.twitter.com/XxYoKPDg2D

— nathantolbert (@nathantolbert) June 17, 2019

Next I decided I needed some hoppy bouncy enemies. Because erratically bouncing enemies are always a giant pain to fight, which is a good thing. My hoppy enemy took a bit longer than I thought to get it working right (a couple of hours for this guy, way longer than my stairs!), but I finally have it working mostly right.  Except that it needs art.  I'm using a random placeholder for now, so it mostly looks like a bouncing cheeseburger.

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.

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.

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.