Ninja of the Kick -- Test Stages and an Enemy Added

(That name.....I just quickly made it up.)

After considering concepts about my other demos (http://forums.nesdev.com/viewtopic.php?f=22&t=11965), I've come up with another kind of gameplay that I think can bring in many possibilities of level design. Someone might have done a game like this before, but I usually do not play a lot of games, so who knows?



Concept test: https://dl.dropboxusercontent.com/u/22954866/ninja4old.nes
More advanced: https://dl.dropboxusercontent.com/u/22954866/ninja4.nes

The START button spawns an apple. The SELECT button spawns an enemy.

So, the idea is about kicking. The player can kick objects into the air, and then kick them again to project them further. You'd be able to also kick enemies, kick things into switches, knock things off high ledges, keep things in the air for some time for bonuses, kick things into enemies, etc. I've also thought of two-player coop gameplay (the players would be able to play a sort of volleyball by kicking things to each other, which might be fun). Once you grasp the controls, you can do some cool stuff like kicking things backwards and over walls.

Anyway, I'd like to know whether controlling the game is fine or maybe too difficult (like kicking in the air, or making apples go over the top of that wall). I'd also like to have people's opinion on the general concept.

(Also, I'm really proud of the 8x8 tile collision and physics )

If you draw an apple on the background when it's not moving and then turn it back into a sprite once it starts moving again, that won't be as necessary. Think of what Super Mario Bros. does when you bash a 10 coin block or Super Mario Bros. 2 does when you toss a mushroom block or Crystal Mines, Exodus, and Joshua do when rocks and pickups fall down. Do you think you'll be able to put that in? Otherwise, it might need to be ported to the Super NES.

It's very cool and interesting with good music and graphics (as was your earlier demos), but it's unplayable in Nestopia and Nintendolator due to graphical glitches.

Controls are great.

But the objects' collision boxes are not aligned to, nor the same size of a tile. I'd like objects to overlap somewhat, and to have pixel-perfect positions for physics purposes (I've always disliked how mushroom blocks from SMB2 align into place after coming to a stop, although knowing the technical reasons for that).

Also, if the game had so many objects on-screen that it would need to replace them with tiles, then the extra time for updating nametables would, I think, overflow V-blank time, and the problem would not be solved (not even taking into account frame time overflow due to physics computation). There just isn't extra performance or memory on the NES, I guess. I'd like to mantain things at 60 frames per second.

It's best to just avoid having so many objects, specially many objects at a single scanline. Changing to the SNES? But we just looove the NES. Might as well just go for the PS4 then.


Thank you for the feedback! While it might work flawlessly on the FCEUX, I should switch to these other emulators... I hear they're more precise, or picky about stuff? I'll give them a go to check out these glitches for myself.

SMB2 aligns its mushroom blocks to 16-pixel boundaries because of the color area grid. But if all things in the background that aren't brick are apples, you can fill the entire rest of the background with apple color. Then you can align still apples to 4-pixel boundaries and the player won't be as likely to notice. Say your apples are 12 pixels wide. If you have "left two-thirds of an apple" and "right two-thirds of an apple" tiles for each rotation, then you can use the "left two-thirds" tile for apples whose X position mod 8 is 0 and the "right two-thirds" tile for apples whose X position mod 8 is 4. The other half of each apple would be drawn as sprites. Do you want me to draw and attach a diagram of what I'm talking about?

The key to efficient video memory updates on NES is to plan out all the updates to a buffer in $0100-$019F during normal draw time and then copy them to video memory during vertical blanking time. If an apple has frozen, copy it to the background. If an apple has started to move, remove it from the background. It shouldn't be too difficult to start or stop a dozen apples in one frame if you make a list of what to add and what to remove before the start of vblank.

The physics is indeed pretty cool.


My NES/Famicom consoles don't seem to have such an option...

And I highly recommend people do not.

It's a fun little demo. The sprites kinda remind me of Bubble Bobble and Dig Dug.

I would recommend that you update your sfx/music in the NMI routine, rather than inline with the game update. That way, slowdown doesn't have to affect the music and sound effects.

To improve sprites, try using a different OAM shuffling technique. Here's one that works for me:

Offset = 0
CurrIndex = 0

Each time you start a new OAM table:
Offset += $34
CurrIndex = Offset

Each time you allocate a sprite, allocate the one whose Y position byte is the one at CurrIndex, and then:
CurrIndex -= $0C

This'll produce a "rolling" flicker that'll evenly distribute the flickering among all sprites on that scanline, instead of just having two sprites that flicker at 50%, and invisible(!) sprites when there's more than 16.

Then add my revised 15-sprite fetch pattern suggestion to the FPGA :-p

I know, I'd never want people to circumvent the NES's original design. But it really gets difficult to watch those apples pushing each other when everything flickers.


Done! I've organized everything and fixed that, along with the graphical glitches on precise emulators (and hopefully the real NES).


Thanks! I've implemented it as suggested. But maybe it flickers too infrequently? I don't know; if more than 16 sprites at a scanline turns out to be uncommon on the final game, maybe it's better to have 50% flicker?

It does indeed seem like it'd be very difficult to have 16+ sprites on the same scanline in this particular game, so it's really up to you. It's still good to know of alternative methods though.

Much better, except this time I didn't hear any music at all (Nestopia). I would rather try to make some kind of rule in the final game that destroys objects before too many of them appear on the same scanline.

All this talk about scanline overflow reminds me of one of the endings for one of the Dangan Ronpa characters. The boy who looks suspiciously like a girl is placed into a console not unlike the Famicom, in a game not unlike SMB. Indeed, the graphics are obviously half assed edits from said game's sprites. The boy is chased and stalked by numerous evil bears, and if too many of them are on screen, the boy will disappear. Despite referencing the NES, the graphical quirks, and SMB, all belonging to Nintendo, this game does not appear on Nintendo consoles, and likely will not thanks to Sony's impenetrable grip on the market.

Well, I've implemented an enemy now (though you still can't take damage). More importantly, I've implemented scrolling and done a bit of work on the levels. I've put it at the first post!

It's really good looking (and sounding)! The kicking concept is cool but it's quite hard to get the object you kick where you want.

Ah, I see what you mean about the flickering. It worked for me because I was using 8x8 sprites, but with 8x16, it needs to be a little different.

I just played around with the constants a bit, try subtracting $14 from currindex, and adding $54 to offset, and see if that helps at all.

Really, as long as the value you subtract from currindex ends in either x4 or xC, (similar for the value you add to offset) you can play around with these numbers and see if there's one that looks best for your game.

Interesting, catchy music. It feels a bit "off" that I can't knock the second fruit off the tree with the first...though that's obviously not what you're supposed to do.

(A plain walking-jump-kick into the lower fruit naturally hits the switch.)
One can reset the fruits' positions, and thus the puzzle, by switching screens, but there's a problem with this: fruit can get 'stuck' in the door, keeping the ninja from moving through. Should probably fix that.