Sliding Blaster

Sliding Blaster by NovaSquirrel, a homebrew NES game released in 2014



The compo version was posted to the contest14 page.

Comments during play testing:
<Pino> Control is kind of confusing
<Carole> Yellow character reminds me of Pac-Man
<Pino> Unclear how to proceed to the next level. Might there be something in the corner?
<Ryan> Hard to control when it gets too far away. Player 1 controlled with mouse in port 2 seems to be auto-fire, wasting all ammo.

Nova asked for tips on fixing the control without a mouse. I looked at the source code and found the names of the game's two cursors: PlayerPXH/PXL/PYH/PYL (the yellow cursor) and PlayerShootAngle (the white ring cursor). Instead of having the gamepad control the yellow cursor, have it control PlayerShootAngle more directly. Holding a direction would cause PlayerShootAngle to approach that direction. For example, holding Up would move it clockwise if it's on the left side or counterclockwise if it's on the right.

tl;dr: Take some inspiration from Gyruss.

Already done, and when I get time I'll try to add a Gyruss-like control scheme as an option.


An old shareware Multimedia Fusion game named Ballmaster 2.

So there is more than one level? Having read the description in the blurb I got the understanding that it was a single level/non ending game (boss listed in TODO) that demonstrated the mechanics of a game that was yet to be completed or developed into an actual game.

There are like 12 or so map layouts in the source and I was going to cycle through them all once, changing the enemy types or other things along the way. The original game it's based off of had a single unique map per level that enemies were placed on and you had to kill everything to proceed but I wanted to go for more of an arcade game. Right now level progression is based off how many enemies are killed, currently changing every 20 or so. Making levels more clear is also something I want to work on before the cart.

Sounds like a good game plan. For future reference lining out those details would be helpful during the judging process. I mis-understood the actual status/completeness of the entry as I didn't stick with it long enough to kill 20 enemies...

I now have the control scheme for standard controllers default to interpreting a direction held with the D-Pad as a target direction and turning clockwise or counter clockwise (whichever is faster) to point there. I slowed it down a little (rotating only every other frame) but I'm not sure if it's still too fast, but it feels okay to me (I included a build so other people can comment on it).

I only have ~4500 bytes left for NROM-128 and I feel like I might push into needing NROM-256, so I'd like to reserve a 32kb bank in the cart if I can, of which I'll only use up to 24kb and the rest can be used for graphics or an 8kb program. Sliding Blaster's graphics can probably fit in some of DABG's unused space when DABG is complete too since I don't have all that much to add to it.

Preliminary test: This control scheme feels much better. I'll need to sit down with it to master it.

As for extension to NROM-256 vs. remaining in the NROM-128 sweet spot: A "submulti" is my term for combining two arbitrary games into one 32K bank. But a submulti needs some way to tell which game's NMI handler to run. I handle this one of three ways:

1. Both games use the same NMI handler. That's how I combined Lawn Mower with Thwaite in volume 1. I debugged into Lawn Mower and saw that its NMI handler was functionally the same as that of Thwaite, namely a 3-byte "simplest thing that could possibly work" ISR.
2. An area of RAM that neither game uses is reserved for deciding which NMI handler to run. This is how the rest of the volume 1 submultis were done.
3. Use 16K bank switching, so that the lower game's NMI vector is duplicated from $BFFA to $FFFA while it is running. I'm starting to use that with new ROM-building tools developed with mapper 28 in mind. This relies on each game's PRG ROM being no bigger than 16K.

I've noticed plenty of empty CHR ROM in Sliding Blaster. If you can keep Sliding Blaster and DABG each under 16384 bytes of PRG ROM, possibly by stashing data in CHR ROM, they'll fit through method C. I don't know how similar the two games' NMI handlers are, but if you can share library routines between Sliding Blaster and DABG, they'll fit through method A or B. I noticed you can share at least the music engine and music sequence data.

There's very little space in DABG that's both in large quantities and isn't either code or needs to be read at random (mostly levels maps and the title screen), so it's probably not feasible to shrink it any, but there's about 5kb free and I know at least most of it will stay free even when I'm done with the last thing I'm adding.
I'm not sure if I will run out of space depending on how big the scope of the project goes (I'll try not to and probably won't run out), but if I do I'll use the last few kilobytes free in DABG's bank and either trampoline into it via RAM or possibly just keep one of DABG's 16kb halves always loaded for routines in Sliding Blaster that aren't needed as often such as ones for the level editor.
The small CHR ROM in Sliding Blaster means it would be even easier to stuff into unused space.

How much RAM at $0000-$07FF is free?


My builder already stuffs CHR ROM into games' unused space. The problem is finding what else to shove into your game's unused space. If you use 17K out of a 32K bank, it's hard to find 15K of other data to shove there. That's enough for about three games' compressed CHR ROM, and I noticed a lot of games submitted to this compo use CHR RAM. I'll have to assess the situation by looking closer at daily builds when I come over in a week.

Actually, Sliding Blaster will definitely fit as NROM-128. Now that I look at it, I've got most of the code in already and polish won't take more than what I have left. After all, the original version of DABG managed to fit as NROM-128. So the issue now is fitting it into the same bank as another NROM-128 game:


In Sliding Blaster, only 204 bytes of zeropage and 405 bytes of BSS (starting at $0300) are used. $5xx is used as a buffer when copying nametable data from CHR ROM to decompress afterward, but I can easily move it into $6xx (3 different arrays having to do with levels, 96 bytes available at the start of it) or $7xx (level buffer). Along with $01xx being used exclusively for stack purposes, there should be no problem finding some space it and another NROM-128 game both have free and placing an NMI vector somewhere.

If the "Big City Sliding Blaster" sounding similar to Big City Slider Station, a possibly poorly made 16x16 sprite of Mays in the CHR ROM next to the player sprite and having two poor attempts at the background music from the Oxiclean detergent ball commercials as FTMs weren't a big enough indicator, yes the plan this entire time was to involve Billy Mays. Product names can be replaced with more generic ones if trademarks are an issue.

I'm adding more polish, like right now dialog before the level for story reasons or to explain gameplay elements before they're introduced:

The text here is stored in CHR ROM and I will probably end up using some sort of 5-bit scheme. It helps that someone who always shouts can just have all uppercase which would be easier to compress like that.

That will not be a problem thanks to the automated submulti builder that I'm using for volume 2. Special treatment was needed for multiple 16K games with different NMI handlers in one 32K bank under BNROM. But the Action 53 mapper can duplicate an NROM-128 game into both banks. This leaves multiple 8K games with different NMI handlers in one 16K bank as the only thing that needs special treatment.

Anyway, now I know where the burgers come from.

I have about 6 levels now, out of a planned 10 so there's more to try out in this build. In addition to that, I finally transcribed the music I composed into the format Tepples' music engine takes, so there's music that's actually different from DABG's now. I think it might be too difficult currently but I'm not sure.

I find it funny that Billy Mays was universally disliked when he was alive, but when he died everyone cropped up saying that they loved him.

That said, you should see if you can squeeze Mighty Putty in there one way or another. According to a fan dub of a commercial, "not even Optimus Prime can break this shit".

I did really want to include Mighty Putty but I wasn't sure how it would fit in as a gameplay element, except maybe using it in the boss. Because this is going on the multicart and that will involve profit I'll probably have to tone down the obviousness of the references, or at least avoid trademark issues.

Just like last year with DABG, SMWCentral's C3 event encouraged me to hurry up and finish Sliding Blaster. It can be downloaded from here and should probably be considered done.