Vigilante Ninja (edit)

Hello all,

I'm new here. Just wanted to introduce myself and tell you I finished 2 NES games. Both are available on Romhacking.net under homebrew section...

Paint or Draw, just a simple drawing game. You can choose from any color in the NES palette, and doodle on the screen.
http://www.romhacking.net/homebrew/69/

The other game is an action platformer, with 4 levels and bosses. Pretty simple, but it was my first NES game.
http://www.romhacking.net/homebrew/68/

Also, I just wrote the music and music engine for another (currently unnamed) game, that a friend of mine is programming. It will be a vertical scrolling space shooter.

Hey, if anyone else out there needs someone to write music for their game, send me a message.

Oh, and I wanted to thank everyone who contributed to the informational portions of nesdev - I learned 90% of NES programming from reading stuff on this page, and from reading old threads on this forum. The other 10% was from Nerdy Nights and a few others. I couldn't have done it without you.
.
.


Edit, Oct 10, 2018
.
.
I'm putting the Vigilante Ninja 2 links here as well, to make it easier to search for...

Full Game...

http://dl.dropboxusercontent.com/s/13w2 ... l-revA.nes

3 level demo...
http://dl.dropboxusercontent.com/s/2ipv ... 2-DEMO.nes

MANUAL...
http://dl.dropboxusercontent.com/s/dw5f ... anual4.pdf

Another thought.

What do you think I should do next? I was thinking of making a programmable piano game, kind of like Mario Paint, except for the NES.

I also want to do something big and awesome, kind of like zelda with a sci-fi twist.

You could probably just make it the music composition side, as drawing with 4 different colors isn't exactly exciting... (I didn't even see that you already did something like that. ) (One thing I've always wondered: Why didn't Mario Paint use 8bpp mode?)

Not enough memory to hold both the background and animation layers in memory, plus the undo buffer and everything else. Besides, there are no modes with two 8bpp layers, so the animation layer has to be 4bpp.

Why do there have to be two layers for displaying information? Is it for double buffering?

Awesome!
I like the painting program. I like it how you implemented the drawn pixels in the nametable.

Mario Paint has a background layer and a 4-, 6-, or 9-frame "animation" layer on top of it.

I was going through older posts and I just wanted to say I think you should develop the Vigilante game, it's quite nice!

If it had more detailed animation/bg etc I think it would be a really great experience. There are some internal tweaks you could make, for example when you hold down the punch or jump button the character continually jumps or punches.

I'm not sure how exactly it works on NES, but you should check the the user input in a way where you check for the buttons being pressed and see if they are different than the previous frame, this way you can see whether the button was pressed or held.

Interesting that you mention that, because I was thinking about redoing the vigilante game with much better graphics and better physics and moving enemies and all that. It could take me a few months. I'm also working on a space-shooter with a guy from the romhacking forum, currently.
Once I finish writing a data compression algorithm that buffers the data on one frame, writes it to the ppu on the next loop, and stores it somewhere in the RAM as collision data (see smb) - I'll start rewriting the core game engine. Also, going to add sprite 0 collision for a split screen at the top, maybe. Lots to do.

This took me all week, but I finally have a working engine!!

I know it doesn't look like much, and only the R button works, but this is a functioning scrolling engine that does all these things...

-fetch and uncompress data stream
-load it into RAM, 2 pages reserved for 2 nametables of metatiles (like SMB)
-load 2 columns of metatiles, and convert to 4 columns of tiles, buffer
-convert 2 metatile columns to 1 attribute table column, buffer
-and load the buffer and attributes to the nametable at the start of the next frame (every 8 scrolls R)
-without glitches or slowdown!

And I added a split screen at the top, for more a detailed status bar. I'm not sure yet how I'm going to update the status bar, except maybe freeze the frame, update it with rendering off, and then turn back on. Because, I'm completely out of V-Blank time. In fact I had to unroll the 'load buffer to nametable' loop to get it to fit. I don't know if anyone out there cares to see a VERY EARLY demo of Vigilante Ninja 2...

(LINK REMOVED, OLD)

Note: all the graphics are dummy graphics, just to make sure the scrolling engine works. And I think I'm going to do the jumping like Contra, where if you press down+jump you jump down, and you can jump upwards through a platform without colliding.

The link doesn't work, the download button is greyed out. The forum's attachment feature is a better choice for longevity.

You're supposed to click the greyed out link, and then click the option not to sign in. It's terrible user interface, but the download works.

It's better just to create direct links, I dunno why anybody uses this janky interface for dropbox when there's an alternative. I just go to my public folder, right click, choose "copy public link" and I get a plain link to a file that looks like this: https://dl.dropboxusercontent.com/u/883356/bxrom_512k_test.nes

Hmmh, I actually did try that earlier, but it didn't start the download for whatever reason. Worked this time.

I tried Vigilante right now. It's pretty cool, congratulations!
The only problem is: the floor will not appear on NTSC televisions.
Seems that your game was designed to use NES' full resolution (256 x 240) but people who plays at 256 x 224 won't be able to see the entire stage.

In my experience, an NTSC TV still in operation may hide up to 8 pixels on each side, 16 on top, and 11 on bottom. Early games, such as Super Mario Bros. and The Legend of Zelda, were designed for 1970s TVs that could hide up to 16 on each side and 24 on top and bottom. For more information, see Overscan.

I would also lose the hearts at the top of the screen if you assume a loss of 16 pixels from the top. I notice on Super Mario that the text at the top starts at the 16-17th pixel down and the floor goes 2 full metatiles up, 32 pixels up from the bottom. I had no idea you lose so much of the screen. 2 questions...
1. Can you simulate this overscan loss in an emulator?
2. Would a modern TV (digital) have the same edge loss with a real NES?

In FCEUX for Windows, Config > Video has two fields for NTSC scanline range, defaulting to 8-231. When testing for overscan compliance, set it to 16-228, or just run your games in the scaled mode of PocketNES (which is hardcoded to 16-228).


My Vizio VX32L shows roughly lines 8-231, the same lines that NES emulators show by default in NTSC mode.

Thanks.

So, if I want to make a game that will play on all devices, like old TVs, I need to not put anything important in the top or bottom 16 pixels, nor the side 8 pixels. Also, I noticed that old TVs displays are round at the corners - so, I might lose a few pixels in the corners too. Good to know for future games I work on.

I've had some progress on Vigilante Ninja 2. I worked out most of the game mechanics for the hero. Here is an updated demo.

(LINK REMOVED, OLD)

I'm going to change all the background graphics still, and redo the font. And, there will be multiple throwing tools you can equip - like Castlevania or Ninja Gaiden. I don't have them programmed in yet.

I think I'm going to use MMC3 and have multiple background ROMs to swap out at the start of each new level, and after the title screen. Not sure how detailed the title screen will be at the end.

up + B - throw
down + B - slide
there are 3 speeds of running and 3 heights of jumping (depending on how fast you are running). Everything seems to be working for me. I corrected all the bugs I saw. In my experience, it's about 40% writing code, and 60% trying to figure out why it isn't working the way you expected. I use the debugger in FCEU/FCUEX.

Hey all,

Update!

After working on Vigilante Ninja 2, I went back and played the first game, and realized just how slow it played. Ugh. So I rewrote the code so it now plays twice as fast, and has better jump mechanics. And I edited the levels since you can now jump almost twice as far.
And I fixed a few bugs. It's been reposted at romhacking.net, the link is on the original post.

(oh, it's listed as Purple Cape Man)

Made some progress on the new game. Changed all the graphics, and completed level 1-1 except for the enemies.

For the demo, you can press 'select' to get a throwing tool upgrade. In actual gameplay, you will have to collect '?' boxes after killing enemies. Also, for the demo, press 'start' to spawn a square (the stand-in for enemies until they are programmed).

Up + B - throw weapon.
Down + B - slide.

ps, the song in the background will probably not end up in the final game, but it does test the sound engine nicely.

(LINK REMOVED, OLD)

Here's a screenshot

Level 1 design completed, except for the enemies. I added a lot of features and fixed a lot of bugs. The only bug I still see, is...you can jump when your feet are a few pixels below a platform (you should only be able to jump if you're standing on a platform).

Start - spawns 4 'enemies'
Select - shifts between tools that you already have, you have to hit enemies to get '?' to collect a tool.

Feel free to give constructive criticism.

(LINK REMOVED, OLD)

Also, I know the ninja can jump way up into the HUD. I prefer that to having him disappear.
And, Level 1-7 is where the boss is supposed to appear, that's why scrolling stops.

It seems a little odd that he can do the walking animation while falling. It also looks a little awkward that he runs as fast as he does while standing completely upright. I was thinking it would look a little better if he leaned forward slightly when he gets up to speed. And when I got to the part where you have to slide under the blocks, intuitively I was trying to press down+jump to make him slide, until I realized it was down+attack. Though now I see that slide actually seems to be a type of attack, so it does makes sense. I would probably go with the jump button (or either button?), if it was me.

Looks like a nice start to a game.

thanks, I'll review the animations.

Yes, the slide move is an attack...though I probably should make the ninja immune to injury while he's doing the slide, because otherwise you won't be able to use it against any bosses without taking damage.

It occurred to me the other day that I'm 2 months into this project, and still working on level 1. And I have 5 levels planned. This is going to take me 10-12 months to complete. And probably 2 more months of gametesting/bugfixing. Sigh. And, I'm trying NOT to get sucked into another project...like reprogramming SMB1's walk/run physics engine - as I already started to do (along with the other dozen changes I already made to it just for fun).

Here's the latest update of my new game. I added all the enemies for level 1, and fixed about a dozen bugs. There is still one unresolved bug, but it only happens about 1 out of 100 times and I came up with a crude fix for that.

Still need to write the boss code, and rewrite the music. Not sure what I'm going to make the boss. It was going to be like a big guy with a sword or axe, but now I think that would clash with the cartoony nature of the other enemies. Hmm.

(LINK REMOVED, OLD)

Let me know if it's too easy / too hard / other problems. Thanks.

I think something needs to change about how you're handling input. Pressing up or B while rising from a jump immediately makes you fall. This makes it hard to jump up and throw a projectile at something. He has a sliding attack that I assume is meant to be press B while crouching. But holding B, then pressing down makes him slide as well. He can even interrupt his sword swing animation to do this.

Holding up and then B activates a special power. If you hold both down, you can slide around with the ninja's arm extended.

You can't slide while holding left or right (or A button).

If you slide under the walls that you need to slide under while not directly next to them, and then stop crouching you get visually stuck inside them. (You can still slide again to get out.)

There are areas in the game where if you fall you can't get back up. (But the fall itself doesn't kill you. You have to walk off the side to kill yourself. That's annoying game design.)

Pressing left and right at the same time begins a very fast walk in place. (Maybe you don't want to fix that, but I recommend it.)

Thanks for your suggestions. When I read this, I thought, wow, I have a lot to fix...why did I never notice these things during the 100+ run throughs i did? But, now that I tried them out, they don't seem so bad, more like funny quirks. Like pressing L+R makes him run in place...it doesn't affect gameplay and it looks amusing. The same with holding U+B while running...I don't see it as a problem because I don't usually run around the stages holding those buttons down all the time.

I do agree with the jump being cancelled by other button presses -- and -- sliding can get you stuck in a wall temporarily. That sucks for gameplay and will need to be fixed.

There are only 2 places you can be alive and can't progress and have to walk off the edge to kill yourself. I will edit them so there is a way to survive.

Thanks again. Honestly, I'm new at this, so I'm just happy things are working. It's a great learning experience for me.

It doesn't matter if you usually do that or not. If absolutely nothing else, your game looks unprofessional whenever it's found. It's unintended behavior. Say it crashed the game. The response wouldn't be, "Well, just don't do that." You'd fix it. Fix it.

It's true a lot of games don't handle left and right at the same time. I understand the thought of, "Well, the hardware should prevent those buttons being pressed at the same time!" But I can beat Yoshi's Island in less than 10 minutes from a new file on the actual console specifically because they don't handle it properly. These kinds of things are exactly what people look for when they're looking to exploit the game, so even if the look doesn't bother you perhaps that might?

Another 'quirk' is that if you throw a tool and immediately press select, the tool disappears. That's because I added the select='switch tools' very late, and it caused the onscreen tools turn into other tools and behave wrong - because I define their movements and tiles by what tool you currently have selected. In retrospect, I should have defined them differently. My quick fix was to move them off screen on 'select' presses, but it looks stupid if done quickly. I may not fix this one either.

Kasumi said:


Well, me and my production team are trying to minimize the budget, and need to complete the project in time for Christmas season, to fill all the pre-orders from K-mart, so unfortunately, quality will suffer.

In all seriousness, I do appreciate the input.

It's risky to do a hyped November release as your company's first product. Hyped November releases should be total conversions of an existing engine that has proven itself in your company's previous product. If there is a hyped November release on a new engine, it'll usually be a launch title on a new console by a company that has produced hits on a console of the previous generation, and its architecture is likely to resemble that of a previous game from the same developer. For example, look at the parallels between the level formats of Super Mario Bros. 3 and Super Mario World: both are a list of 3-byte objects.

Another update...

I believe I've corrected all the bugs with walking and jumping and sliding under things. And I added the real level songs. And I changed a dozen other details that you probably won't notice.

Some of these fixes were very easy (fixing slide was just add another collision above check, add a bit to the auto-slide count if under a block). Some were annoyingly hard (I had to rewrite basically all the button handling, add several flag variables, tons of conditional branches, move the jumping subroutine, etc, etc, very ugly code)

(LINK REMOVED, OLD)

Everything is way better as far as button input. You can stand on a block that isn't the top block:

Yeah, I know about that one. I find it only happens about 1 time out of 100, and I haven't been able to correct it yet.

I think it happens because I only do a collision check (R or L), and eject, when R or L buttons are pressed, and if you are moving R or L due to the last frames button press, and stop pressing it exactly when he's at the top left or top right corner he can slip into the block ... and if R or L are not being pressed it never does the R or L collision check, so it doesn't eject.

I might have to add an "always check if I'm inside a solid block" routine.

Why not just do the check whenever you are moving left or right? (Why would you check based on input if it doesn't match the actual motion? Do collision based on the movement.)

Because I wrote the movement stuff poorly.

The next game I'll get it right, maybe.

And, done...here is the "official demo" of Vigilante Ninja 2, Level 1.

(EDIT, REMOVED LINK, OLD VERSION)

I'm going to take a short hiatus, since I've done little else with my free time for the past 2 months than work on this game. Some small details might change from this demo to the final game. Thanks for all your input, guys.

If anyone out there is able to test this on a real NES, please let me know, I'd like to find out if it is compatible (though it seems to play fine on the 4 emulators that I've tested it on).

Fixed one bug related to the boss music. Above link has been updated.

Hey I got around to playing this and it was pretty cool. Nice start! I really liked the white enemies with their mouths wide open and the boss rabbit. Cool characters.

My biggest suggestion would be something with the jump mechanics. I'm not sure exactly what, because I see that the way he jumps is the a part of the game design, but it feels a little funky. The first time I jumped an entire screen distance I thought I broke the game.

Maybe, he just needs a visual indication that he's going extra fast like Memblers suggested.

Other things I think are entirely related to the fact that this is a demo version. Jumping down off a platform would be nice, but you've already mentioned that. Unlimited special weapons means no reason to not spam the crap out of them, and whether intentional or not, the fact that you can always shoot again when your weapon leaves the screen means you can do the mega man trick where you close in on your enemy and blast at a super fast speed. This may have been intentional, and is characteristic of games from this time, just didn't know if you'd thought of that.

Keep it up!

Thanks for the suggestions. I have a few other things to tweak too. I'm taking a break currently... Learning Python, cc65, ca65, etc. I friend who has a band invited me to jam with them, so I got to practice the old guitar a bit, get some of the rust out, first.

The above demo link has been updated.

Main changes...
Smoother walking/running
Can go directly from slide to run (or to full jump)
Getting over 50 coins no longer resets to 0, but rather subtracts 50 (letting you keep a few if you just picked up a pink coin)
If falling, horizontal speed slows down gradually
Edited down the excessively long / wordy second title screen.

Officially back in production, level 2 metatiles / background graphics completed...

It's a beach theme.

Wow that looks very good! I like it when it's not just blocks, but some real and interesting textures.

Thanks.

Someone (not here) told me the graphics in level 1 look like crap, so I'm trying to improve as i go.

Level 3 will be in a cave.
Level 4 will be in a forest.
Level 5 will be a castle (interior).

And, I might redo all the graphics for level 1 as a final step.

Hmm...I wonder how if it would look better if the platform function allows sprites to be 1 pixel lower, so as to give the background a more 3d feel.

That would be such a pain to implement this late in the design, but it might be worth it.

Yeah, it's better that you do that. That's like in SMB1. It gives me the sure feeling that I'm standing on something and not maybe floating on slipping.

Also, I'd like to have that extra step jump. I hate it when jumping off the edge I press the button a milisecond too late and the character just falls through! Argh! Could you implement that? I think you'd need two flags. First one is if there's an extra frame for jumping and the second one is of the extra frame has expired.

I don't know if I'll do this, but I would do it like this...

A variable that is set to 2 if the engine detects that I'm standing on a platform. Then decreases it in the jumping function, and if it's still > 0, allow a new jump. That would give an extra frame of jumping.

Or, if R is pressed, you could extend all platforms to the right 2 pixels, and if L pressed, extend all platforms left 2 pixels.

No, I can't do this. I have so many narrow gaps that I want the hero fall into. It is what it is.

And Level 2 is done. Using 'Tiled' has greatly improved my level design speed. I'd say, by a factor of 4.

(EDIT, REMOVED LINK, OLD VERSION)

Notable changes to game engine:
-Sprites are 1 pixel lower (gives more depth / 3d ish)
-I finally implemented enemies that can be a size different than 16x16.

I still haven't tested this (or any) game on real hardware. If anyone out there has done this, please let me know. Or if anyone has any issues with any emulators let me know.

I did all play testing with the sound off, because I was listening to the FAMICOMPO songs...but I didn't change any music code/data. I'm going with the assumption that it works fine.

(I am on track for Summer 2016 completion of this project.)

It's very challenging. I don't like how the character accellerates so fast and it's hard to slow down and I have this jump frame problem or it's just hard to know what's solid when the land is sloped at the end. But I like it how there's lots of weapons! And their sound effects. So awesmoe. It's just hard to change between then. It'd be better if you could change weapons with select+up/down/left/right/A/B or pause the game to select it. Speaking of which, there is no pause button! AVGN would say "Have a *ing pause button" XD James also said it during a homebrew game let's play.

Re: challenging
Another person told me I made the game a bit easy. It's loads easier than some NES games (ghosts n goblins), I think about par with Megaman in difficulty.

Re: acceleration
I can slow it down, see how it plays. I wanted it to be crazy fast, but acceleration can be slowed.

Re: deceleration
He actually stops on a dime 1 frame after no R pressed

Re: pause
I can do that. Maybe even allow you to switch tools while game is paused. Sure.

Thanks for the input.

Thank you too. Also, since I can't really break the ice to start developing my own engine from scratch without those shiiinyyyyy :3 functions like DrawSprite() or ScrollScreen(), could I collaborate with you on your project via a screen share so that I can maybe fix some of your code or add something interesting? I have a physics code in Game Maker Studio and I'd like to see how it would apply to your game. I see many games not having that physics code and it's the only code that actually plays well like SMB3, other than Game Maker Mario clones that are slow due to people using objects for every single block instead of using a tilemap, which totally kills the experience.

Those functions() make me think you're going to code a game in C. My game is in asm, btw.

And, sadly, my code is a nightmare. It is a result of not having a plan at the start, and saying... maybe I'll just add one more feature, repeatedly, until it's an unreadable mess of spaghetti.

At this point, I just want to put in some level data, and be done with it.

Any real changes to physics, and I would much rather start from scratch, and give things sensable labels and organize my code into a form that I can read. And implement all movements and states and such completely different.

Here's an actual comment that I wrote in my own code
"Why is this here, shouldn't it go earlier??"

I see. I wasn't going to use C. I just wanted to use pre-defined jsr's with arguments in stack.

I've implemented the suggestions that 8bitMicroGuy said.

-Acceleration is slightly slower.
-I edited the Ninja's running animation
-Start = Pause
-You can switch tools during Pause Mode


(EDIT, REMOVED LINK, OLD VERSION)

Now, on to level 3.

Wow, I cannot pass even the first level XD
May I make an LP out of this?

You can do whatever you want. Keep in mind,
1.it's not finished
2.I'm going to redo level 1
3.it will be finished in 6-8 months.
4.you may want to wait

What's LP?

I looked up the acronym, here are a few of my favorite possibilities: (from http://acronyms.thefreedictionary.com/LP)

Long Playing (record)
Liquid Propane
Lonely Planet
Legal Problems
Lamp Post
Licorice Pizza (record)
Lesbian Pornography
Laser Prostatectomy
Lemon Party

My money is on "Lesbian Pornography".

JK, I think it's "Let's Play".

Hahahahah! XD no way. Of course it's Let's Play.

LP can be:

1. Longplay (video of a complete playthrough, usually without commentary)
2. Let's Play (video of play, not necessarily complete, usually with commentary)

Oh, of course! I guess I just haven't seen that acronym used. The first thing that comes to mind is a record.


While the concept of lesbian pornography based on a game or a game based on lesbian pornography isn't new, the idea of a lesbian pornograph based on Vigilante Ninja is pretty funny.

Although I was kind of hoping for lemon party.

So anyways, may I record the Let's Play on Vigilante Ninja?

I think I answered that...

1. It's not done
2. Probably should wait a little.

I tested this game on an Everdrive and an original Nintendo top loader and it played just fine.

Thanks.

I've been meaning to get a USB flash cart to test games.

I've redesigned Level 1 of Vigilante Ninja, here's some 'before and after' pictures...

Also changed was just a little bit of code...and I turned the volume of the Sq1 channel down a bit.

Here's the latest links.
Level1...
(EDIT, REMOVED LINK, OLD VERSION)
Level2...
(EDIT, REMOVED LINK, OLD VERSION)

By the way, the grass was inspired by a Famicom game "Bird Week".

Oh, and I see a bug already...it still says "Level 2" at the start of the game, because I was working from the level 2 code...I'll have to fix that...

(edit, fixed, link updated)

I have tested both demo levels of Vigilante Ninja II. The game looks great.

Thanks...

BTW, this project is delayed, due to me working on another project. Probably no updates till Summer.

I would really like to make a let's play. So I have to wait for summer to record it, right? That sucks. I would really like to do an LP on this.

Oh, go ahead.

You can do a follow up when it's finished.

What do you mean by a follow up?

fol·low-up (noun)

a continuation or repetition of something that has already been started or done, in particular.
an activity carried out as part of a study in order to monitor or further develop earlier work.
"follow-up interviews"

I made some cave graphics for level 3.

The game is pretty fun and challenging. Kinda like Dangerous Dave. I feel like I'll be playing it for a long time until I beat it. This is a good game for a long-term gameplay. I was daydreaming how awesome it would have been if this game had been on my NES clone from childhood. I'd play it all day besides Super Mario Bros 1.

I was thinking of changing the special weapons. I seem to use the throwing star 90% of the time.

The one tool shoots upward, but that's rarely useful. The spinning fire doesn't fully stop injury, which is annoying.

Any thoughts?

I don't like losing all weapons upon death. I'd like to save all weapons on checkpoint. Or maybe, put a sprite of the dead player from previous life so that when the player collects it, they regain all weapons. But that would be a nice challenge. Say, you have 5 coins. You'll lose them in the dead body too, but if you collect it, you regain them. Then, if you fall into a pit, you can't recover, lol, muhahahahaha.

I mean like...I was thinking of turning the fire circle into a Kirby style flame thrower, and replacing the 'Jacobs Ladder' electric tool (the one that goes up) with a boomerang.

https://youtu.be/P_41616M1zk

Here's the Let's Play.

Here's a slight update on the graphics. I really haven't had much time to work on this, but I did hand (pen and paper) sketches of the entire Level 3.

Hey guys,

I may seem like I've been slacking, but I've been working on other things. Here's level 3, with about 25 tiny changes and a few important changes...
-Ninja runs a little smoother and a little slower, and it's easier to get high jumps
-Fire circle replaced with Fire Sword
-Electric weapon replaced with boomerang

(EDIT, REMOVED LINK, OLD VERSION)

Please let me know if you catch any bugs (and not just the spiders ), or have any useful comments. Thanks

Here's some screen shots.

Some more.

Made one correction already. Changed the boss color. I just played it on a real NES, and the boss looked like a blurry pile of poop. Apparently there is no contrast between $06 and $07. I changed the main color to $16. Hopefully it looks better now.

Also, I wanted to thank darryl.revok for his contribution in making the Boss graphics. Sorry I screwed up his color.

I wish I could have convinced the artists for Haunted: Halloween '85 of this lack of contrast.

Here's a test for a possible redo of the Title...

https://youtu.be/_iHCUtGVaus

Does anybody like this, because it's not entirely finished, and I don't know if it's worthwhile to do it "right". I used Famitracker and recorded a .wav from it and overlayed it over a FCEUX video recording. My game engine is completely incompatible with Famitracker, so I would have to do some work to put the song in...plus the DPCM samples take up $f00 bytes of space, which I'm not too happy about. Also, I'm using a very inefficient way to update nametables here, that takes way too much time to fit in a V-blank, so I'm just turning rendering off every 8 frames to update the nametable. I could come up with a '2 nametables that switch' method, to make it not flicker...if I decide to go with this idea.

Comments requested.

1. The animation is pretty slow.

If this was in a game, I might watch it the first time to see what it is, but every other time I'd probably grumble it's so slow and mash START to try to bypass it.

2. The black parts of the Ninja can look like the background.

The first time I watched it, I saw a sideways A pushing a flame and pulling another flame behind it. Once the animation completed, it took me a second to realize the blackness wasn't the background, but the Vigilante Ninja. Now when I watch it, I see him every time. Maybe if the Ninja moved more quickly it'd be more obvious the black stuff is the Ninja the first time you see it.

3. It looks blocky.

I guess you're going for a blocky look on purpose? I thought your previous title screen might be replaced with a more detailed one in the future.

4. The music sounds sample heavy.

I can't decide if:
a. that's cool ("yeah! badass guitar sound on NES!"), or
b. that's cheesy (like the Action 52 intro). Maybe I'd prefer more "retro" sound in an NES game (more audible use of the NES's other sound channels) along with a few sample sounds.

If you go with this title screen, the slowness seems worthwhile to fix. The other three comments are less strong opinions that I'd be okay with if you didn't change.

Thanks for sharing your work.

Is this abnormal? Contra has a quick sliding intro and I always press start to jump into the action. I don't care how good, quick or fast an intro is, if I've seen it once, I don't need to see it again. I'd only be irked if you COULDN'T press start to bypass it.

I don't mind the pace. It highlights the over-the-top quality to the intro scene and I feel fits a light-hearted and slightly humorous game.

It reminds me of this but nowhere near as slow:
http://www.newgrounds.com/portal/view/73449

What does bother me is this:

I understand that it's a blown up sprite of the character, but I don't think that works for the aesthetic. It's kind of funny, and maybe if the fire behind him was detailed, the joke would work. But currently, I feel the low resolution belies the graphical style, and makes it appear as if it's going to be an Atari styled game. It's not. That style also clashes with the logo.

I'm not crazy about the logo. The monochromatic halftones make the text look messy, especially on the word Ninja. I'd prefer to see at least one more color in the logo, and I think solid shading would look better for a logo, where clarity and crispness are paramount.


Personally, I'd say that a. and b. are both true and I'd also say that I like it. I'm under the impression that the intro is supposed to be humorous, like an over-the-top action movie, contrasted with the simplicity of the protagonist. I think the heavy guitar fits perfectly, if I'm perceiving the intro correctly.

I do see why it would be fitting to have the character be blocky, so personally I'd like to see detailed fire. That's my two cents.

I see the flickering, but the fact that there's a fire in the background actually made that visually acceptable to me. I'd understand if you wanted to change it, but I wouldn't prioritize that personally.

1. The black frames in between frames of fire kind of disturb me. You've got 2 nametables to use here, so I'd recommend double buffering and flipping back and forth.

2. Because the ninja is the same colour as the background, I didn't know what I was looking at until the ninja was most of the way into the picture. It's basically because the fire itself has a bit of a natural line that's at the same position as the top of his head, except in the middle where the flames are a littler higher. If you moved him down like 4 or 5 pixels I think you would avoid the cutoff.

3. The sword appears in a single frame. Would be cool if it slid out progressively, maybe a "shinggg" sound on top. (If someone presses a button to skip to the end immediately, you could also play the shing SFX there as a reaction.)

4. Keep animating the fire when we reach the end! (See suggestion 1.)

Thanks for all the suggestions...

This was just a simple demo I threw together quickly last night (4 hours seems quick to me), not the final product.

I was kind of going for this (Sephiroth in Flames)...
https://youtu.be/sVXuq8HKGJA
Super over-dramatic, yet very pixelated... because it's NES...

I guess I'll go back to the drawing board, and try again.

I will probably literally wait till the last minute to remake the title screen (after level 4 and 5 are done). To be honest, I don't have much experience doing animation.

I think I'm going to have to start actually using a mapper other than NROM for future development.

I wouldn't want to see you scratch it. I like the direction. It's good for a start.


NES isn't THAT pixelated though. After I thought about it, I like the Ninja being pixelated, because it makes me think that he actually looks like that. I don't see why the fire would be pixelated though when the backgrounds in the game aren't.

Also a thought, what if you flickered the palette on the Ninja so that it looked like he was illuminated by fire?

First of all, let me congratulate you dougeff for your projects, they were quite fun; i just downloaded both compilations from the first page and managed to go through them before i saw you updated your ninja project few post ago:



i also dig up your draw and paint program and did some render of my current youtube avatar, well... part of it; it did not fit the screen lol

green vil


blue vil


red vil


dark vil


no, not a nes's link clone; not at all lmao; this tool is nice to fast swapping clothes tho lol amazing job you have done so far! i am really wishing to play your Vigilante Ninja project's last version = 3

I agree with Darryl's assessments of the title screen. I've animated a lot of flame effects for Pyronaut. I suggest watching slow-motion vids on Youtube of fires similar to what you want. Also, here's a quality animation cycle to reference as well.

Or just convert those slow-motion videos directly to NES graphics. Animating an entire screen worth of fire sounds very hard.

I'd imagine it a lot like the first level in Turtles II. There'd be a lot of repetition in the bulk of the fire but it would still look good for NES. If I was going to spend a lot of time on just one part, it would be the top edge.

If the game was changed to a different mapper, CHR bankswap would be a very easy way to animate this which would also fix the flickering issue.

Looking like an NES game rather than Atari would be my main focus. Beyond that is extra.

I need some critical advice, about the level 4 graphics...not sure if this is looking good enough.

Also, apparently someone else is going to write me a unique song for each level. I was talking to a guy on RHDN about writing songs for me a few days ago, and apparently he's already written 2 songs. I haven't heard them yet, but if they are any good, I might be using them and switching music engines to famitracker/famitone2.

Hmm... I'd say for defining the shape of the cylinder of the tree, not bad. And I could see this as an NES tree. It makes me think of Wood Man, minus the mechanical tree aspect. Or maybe Kirby-esque.

There are some weird things about the scene as a whole I'd change though. The short stubby branches without leaves, for one. It makes me think of a cactus, Cactrot/Cactaur/Sabotender, or a Haniwa.

Also, the tree trunks in the background being green doesn't work for me. I see that it makes a clear distinction between background and foreground, but maybe dark trees could do this too.

I'd definitely want to add some leaves but I imagine you're already planning that.

The stone is flat compared to the trees, which are rounded. Your lighting direction, as indicated by the trees, is from front-left. Tree bark is textured, so the jagged patterns work fine there. In contrast, the stone may read better with solid shapes instead of a jagged texture.

It is also confusing as to which surfaces can be walked on. Obviously the branches, ala Bionic Commando (arcade), but what about the stone? It's placement and treatment make it unclear as to whether it's a platform or simply decoration.

Perhaps if there weren't a (bump-up) tangent between the stone and the trees behind it. (You also have two more of these at the edge of your tree branches. This is something you may want to keep in mind when designing levels.)

I would suggest working on your BG graphics all throughout so that walkable surfaces are treated clearly differently than background decoration. Perhaps surfaces could have highlights? Perhaps no black outlines in the BG? There are multiple ways to approach it.

Actually, I did a quick paintover to illustrate these.

I did a few main things:
* Clear lighting and shadow source on the stone, also shown on moss. Also rounded the bottom edge.
* Increased the highlight of all walkable surfaces.
* Removed design tangents (where edges coincidentally lined up) while still adhering to the tile grid.
* Added small stones in the BG, so that the stone didn't stand out as much.
* Added an extra level of depth to the grass, and a furthest level of forest in silhouette to remove the harsh horizon line.
* Added an extra level of depth for trees (black with the faintest highlight)
* Quickly tried to sketch out some grass highlights that showed the same light source as the trees. Also added some darker grass to help the transition further back.
* Darkened the pit, with a bit of a grassy transition on its top edge.

Oh, and I thought that by using the branch tiles for stray logs, it will help visually connect the extreme foreground (grassy walking plane) and the next level of depth back (stone, walkable trees).

Also, forgot to mention that I quite like the background as it reminds me of Legend of Kage.

Thanks for all the great tips guys.



I definitely want branches you can walk on, which means aligning at least the top to a grid, but I'm not sure how I can make leaves blend with blocks of other palettes. The only shared color is black, but big black joining edges will look weird.

The game I was looking at to plan this was Dizzy, and Legend of Kage.

I really like the small rocks, and logs on the ground.

Also, The large rocks are platforms, so I nees to make sure they don't look like BG. They need to pop out.

I'm thinking about using the brown tree palette for the floor. I tried it quickly, and it looked weird, but if I replaced the grass with a dirt path, it might work. (Grass above and below).

Maybe I should make green the shared color, instead of black.

And maybe I wouldn't have 'tangents' at the rock/tree area if I had roots sticking out at the bottom.

Those trees are awfully close together and they look like telephone poles because they don't have many limbs or mass. Adding leaves and background foliage would help.

Those hue shifts help a lot. I didn't even touch the palette with my paintover.

Foliage is a big improvement too (although he definitely wouldn't want background foliage to overlap midground trees,but I assume that's not intended.)

As for the ground plane, I'm a big fan of showing a cross section. I think Adventure Island does this. Top layer is grass, then soil below it. Can even show a buried bone or something every now and again for interest.

Here's what I ended up with. I know pubby's looks better, but my game's graphic system has a limitation of 64 unique metatiles per level, and I'm stretching this level to the maximum.

Oops, I forgot to put some medium sized trees in this picture, but they will exist in the game.

Looks better. I wish you didn't have to have square foliage though.


Why is this limit in place? Is the benefit significant?

Upper nibble tells the decompressor which palette to use for the block, the lower nibble for metatile number. 4 palettes x 16 = 64. That's just the way I planned it. I will almost certainly not use this system in the future, but this game is like 75% complete at this point, I don't want to have to change the compression system, and redo the past 3 levels. (Note, I further compress it after that with a RLE style compression and dictionary style compression. The game decompresses it a metatile column at a time, and also uses the metatile map as a collision map).

Here's with those medium sized trees (I made them dark) and a few other changes...

Are you talking about the foliage at the top or the platform foliage in the middle?

If I got rid of the angled branches, or replaced them with L shapes, I could free up 6-8 metatiles, as I made a wide variety of backgrounds behind the branches, so that they can be at different heights, and still blend in.

I could also use the rock palette (which has 2 greens and black) for the platform foliage. I have 3 blank spots in that palette set of metatiles.

I meant specifically the foliage at the top.

I just thought what pubby did added a lot to the image. I can understand though that you'd be reaching the point of diminishing returns for the project. I wonder if there's a way to do something similar with less tiles. Something that isn't in a straight line, at least.

During the development of Haunted: Halloween '85, I changed the format of the compressed tiles and maps at least twice. I was able to do this because I stored them uncompressed in a graphic assets source folder and then added a task to the makefile to compress them when building the ROM. I did something similar when I was helping with compressed data for the Super Bad Apple demo: we were experimenting with various compression formats, and I transcoded each time psycopathicteen thought of some improvement that could be made to the size/speed tradeoff. Perhaps you could write a program to decompress your existing levels and then recompress them in the new format.

Super Mario Bros. also uses the top two bits of the byte for which attribute a metatile uses. But it has a separate (game-wide) set of 64 metatiles for each of the four attributes.

Another thing you can do with RLE is treat a run as a Markov chain. Instead of treating a "run" as a consecutive identical metatiles, try this:

• In the compressor program, find the metatile most likely to appear below each metatile. For example, "top half of mossy boulder" would be followed by "bottom half of mossy boulder" most of the time, and "bottom half of mossy boulder" would be followed by "ground".
• When decoding each column, treat a "run" as a chain of such most likely metatiles.

Or is this your "dictionary style compression"?

If the upper 2 bits (of each byte of data) is 00, the next 2 bits = palette, next 4 bits indexes to a list of metatiles (16 per palette).

If 1111, the next 4 bits is # of repeats, the next byte is then repeated (really only 3-13 repeats are meaningful, more than that will crash the game)

If 1000, the next 4 bits indexes to a pattern (list) of metatiles, of variable length, terminated in FF.

The last one, I called 'dictionary', I'm not sure what the actual name is for this system, but it can compress a complex column into 1 byte of data.

I need some more game testing...please.

I did a graphic redesign of the ninja in my game (still haven't fixed the title screen yet.)

Although this is basically the same game, I changed over 100 lines of code...maybe even 200 lines. So, as far as I'm concerned, the game is untested (except for the quick runthrough I did on 3 emulators and PowerPak).

Note, collision detection is still designed for a 24 pixel high character, even though he's 32 pixels high now...so he will be able to jump 6-7 pixels into the ceiling, and projectiles will pass through the top 6-7 pixels of his head uninjured.

Comments welcome, thanks.

(EDIT, REMOVED LINK, OLD VERSION)

I like it better than the original. It also fits the overall style better. Good job.

The collision si fine as it is now.

I didn't think that the character redesign would be that big of a deal, but it's actually a nice improvement. I would fix the collision. The head passing through ceilings on background collision isn't that big of a deal, but bullets passing through the player like that would look bad.

I really like the boss music.

I think the biggest issue with the game is the jump physics. Those are keeping the game from feeling professional, especially the float down. It seems your character's vertical velocity is at a fixed rate per frame. I would consider using subpixels in some way to give your character a smooth jump arc.

You don't have to make it too complex. My current Run 'n' Gun project uses only 8 bit positions for objects which aren't bullets. My characters also only have an 8-bit X speed but a 16-bit Y speed. I don't have to actually apply subpixel speed to my object (since it doesn't store subpixel position). I just use it to modify my Y speed in a smooth arc. If you'd like, I could show you how this looks in my game to see if you like that. It's really not that much more trouble to take the extra step and store subpixel positions, but I was trying to save any processing possible.

If you did that, and made your jump based on applying negative velocity to your character rather than a fixed pixel rate per frame, you'd need to implement some sort of variable jump timer and there are plenty of ways to do that.

I also feel like there's a bit too much dithering in some of the background patterns, especially the main cave background. Dithering is usually best used very sparingly.

I'll try to improve these a little later.



Will do.



I agree. I wanted the cave levels to be very dark (lots of black mixed with the darkest colors)...but it looks like a starfield on a real TV. I'll have to redesign the BG tiles too

Another thing I noticed. It appears that either the Ninja's hitbox goes too low or the enemy's go too high. This position hurts the Ninja:



The Ninja Master should be immune to enemies less than 16 px high while standing on a 16 px block.

Also, I uncovered a bug that I got to happen twice but it was tough to replicate. It would probably be easier to pin down with an emulator and save states.

Twice I managed to receive damage when the boss spawned when not touching him. Both times that it happened, I had just taken damage right before getting to him, and was almost still flashing. My guess is that there was some sort of damage state trigger that hadn't been cleared, and was processed twice when the game entered "boss mode".

Also, I believe it would be a big boost to the presentation if the enemies had some sort of animation when they died instead of just disappearing.

Just noticed another one. I fired a shuriken, killed and enemy, and picked up a scroll all at the same time (to my human perception at least, not sure how many of these things were on the same frame.)

My weapon switched and but a shuriken was left floating in the air. I couldn't fire again until it was gone. Changing weapons cleared it.

Wow the game looks kinda weird and zoomed in now. Before, it was a little ninja jumping from cliffs at super fast speed. Now it's a chubby guy and the physics feel more different. But speaking of the looks, I like it!

About jump physics, you can avoid the need to use fixed point math just for the Y axis if you use a table of precalculated increments, simulating the arc described by a second degree equation (the equation to calculate distance in a displacement with acceleration, i.e. gravity, is a second degree equation). Each frame during the jump (up and down) you add the value from the next index in the array instead of a fixed value.

You can calculate the arrays yourself, or you can use my simple (and terribly ugly and buggy) simulation program which outputs an array in C (which you can adapt to whatever). If you use windows, I can share it if you like.

Example of calculation: you input that the jump should reach 64 pixels high during 64 frames.

This is the output array for such a calculation:


The output array contains increment for going up, then down (a complete parabola, from ground). If the index pointer gets past the array values (an extended fall, when the floor is lower than the platform you jumped from) you just repeat the last value until you hit the ground. It's not perfect, but it works fine and nobody will notice.

I myself use a complete fixed point system in my platform games 'cause I find it natural and new interactions are easily added (for example, a propeller which makes you float from the floor), but for the fighting game I'm coding for the compo, I didn't need something that complex. I'm using the precalculated increments array approach for that game and the physics feel great.

Give me a shout if you are interested.

This game is looking pretty good. Nice, but to me character movement feels stiff because of the player character stopping completely when you change direction and when you try to walk after a sliding attack. Maybe the player should retain some speed after those moves (unless, of course, the player actually wants to stop - ie no direction button pressed). But that's just my dumb opinion.

Keep up the good work!

Thanks for your input, guys. I will definitely adjust the phyics.

I don't want to retain too much momentum...I always felt SMB was a bit slippery, and hard to stop on small blocks.

To avoid the "slippery" feel, use higher acceleration and friction values. Also, even if it is not realistic, don't use a much smaller friction value while the character is airborne. It gives you better control.

When will you combine multiple levels into one ROM? All I see is demos of individual levels.

I have a gameplay suggestion. When hearts are full and you collect a heart, it would be good if that would count as an extra heart or 8 coins because it's like a sixth of a life or sixth of 50 coins which is a life. I don't like it how I collect many hearts when my life is full, but when I lose them, I've already collected all weapons and no heart will spawn from an enemy. Then, it would be good if an extra weapon would count as an extra heart; or 8 coins if all hearts are full; if all weapons are collected. That way all collectables would actually mean something.

Here's a bit of code that came to my mind. CollectWeapon, CollectHeart, Collect5Coin and Collect1Coin are functions that the game should call upon collision with a weapon, heart or coins.

Re:bigger mapper

Interesting you mentioned that, because I just converted the first 3 levels to MMC3, but I will not be releasing a free version of that, nor the full game, I'm hoping to get it on a cart later this year.

Still need to redo some graphics, put new music in, etc, print boxes and labels and manuals. Lots to do.

Re:hearts,

I'm considering having multiple levels of difficulty, and possibly more hearts for the easy version (and fewer for hard)...will need to work out the details later. Maybe half hearts like Zelda? IDK.

Will you implement the feature that I've recommended?

Also, I cannot afford a real NES so I'm playing on emulators. If you sell your game, it would be nice if you could sell a ROM then just like the PC game Retro City Rampage has an NES ROM of ROM City Rampage. I would be happy to pay for the game, but not for an NES or for shipping of your game because shipping is expensive for my geographical position.

There's no DRM for ROM files as far as I know, but people today buy DRM-free games and are very respectful because their conscience tells them "Your game seller has been fair to you so be fair to them by not pirating.". If you're afraid of piracy, you could program and upload fake ROMs that don't work or that randomly crash or that reset the score and lives or don't reward you when you pass a level or finish the game. Earthbound's DRM resets the save data when you beat the game. I think something like that could be done to fight piracy.

I don't know. Maybe yes. Maybe no.

Yet another update, level 3, with lots of changes...

(EDIT, REMOVED LINK, OLD VERSION)

I've made the collectible items completely deterministic (rather than random), and if you have all the throwing tools, you will get hearts instead.

Falling is now acceleration down.

Graphics changed some more.

Fixed a few minor bugs.

Now on to redo level 2 and re-redo level 1.

More and more changes.

-new physics
-redrawn sprites
-animation on enemy death, boss death
-options screen
....3 levels of difficulty
- easy = half damage, slightly easier bosses
- medium = as is
- hard = max 5 hearts, slightly harder bosses

....cheats (extra lives, retain weapons on death)
(level select not functional)

New link to level 1 (completely redone)...

(EDIT, REMOVED LINK, OLD VERSION, buggy)

-things left to do....new music, redo title screen (again).
-rework level 2-3
-level 4-5, etc.
-story for beginning, with graphics.

Holding up basically freezes the player physics.

Edit:
There's actually still a lot of weird button things. Down similarly stores your speed which allows you to get the high jump from a standstill.


Getting hit releases the stored speed:

Edit2: Holding B makes me walk in place.

Edit3: Holding A after getting hit allows a jump

That last one could be intentional. I'm noting it because you can move left or right after getting hit, but the jump only comes out after the invinciblity. Basically you can move immediately after getting hit, but the jump happens frames after.
edit4: Actually I just realized holding A also freezes grounded physics. I was wondering what happened at the end of the gif above. And the answer is that I landed near the edge with a non zero traveling right speed. Since I was holding A, I didn't continue to move right until I released it.
Edit5: You can't slide while holding A. You can crouch in the air if you're not holding A.

Interesting.

I tried to completely rewrite the game physics, and that immediately broke the game in a dozen ways. So, I scrapped that, and just did a bunch of ugly hacks to the existing crappy physics. It seemed to work. I did 3 test runs this morning, one on an NES, and I didn't notice anything unusual.

Thanks for the input.

Link updated (now marked 39), changes made, as suggested. (except for the jump after getting hit, that still needs fixed)...fixed.

Hold right, let go of right, press and hold B immediately after. Physics freeze during the sword swing.


hold down, press A. No air control during jump.


Run right, jump, let go of right, press B. Horizontal physics freeze in midair.


For what it's worth, you can still hold B to swing when invincibility ends like the jump things. You can also buffer slides but that stuff's honestly kind of cool.

Edit: You can buffer a jump out of a slide, but that's also kind of cool.
Edit2: You still can't slide while you're holding A.

Are you isolating buttons with AND before checking for these actions? A lot of these seem like you compare with a specific value, but some other button being held (like A) makes the number different. But you can and out the bit for A so it doesn't make a difference. Or you're allowing movement with right+B but not B alone. I could debug the game to see, I suppose.

Edit3: If you try to pause during a sword swing and release the button before the swing ends, the input is missed.



Edit4: You can't pause during a slide at all. It seems your game engine isn't structured in a way that separates things. What state the player is in should not be able to affect if I can pause.

Edit5: You also can't change weapons while sliding or swinging the sword.

It skips getting/handling input during 'animations' (sliding, cutting). (And apparently skips L/R movement, start/select, etc.) I didn't want it to change states in the middle of a cut.

It slows you while cutting/throwing.

It ignores L/R input while pressing down (to avoid where he's ducking, but also moving L/R)

In what circumstance do I need to hold down while jumping, and THEN also add L or R?


EDIT, I guess my real question, for all you testers out there...does Y acceleration down feel about right? Does X deceleration feel about right?

How I operate: I play the game normally. But the second I notice something I think is wrong, I investigate. The reason I found anything is because I noticed the sword swinging stopped me while running, but only sometimes. This is the kind of thing that makes players feel the controls are wrong, even if that doesn't necessarily make them smell blood in the water.

If I find out something happens inconsistently, I will then try to find out why on the design level and then the logic level. And then I'll think about if they match. And if they do match, it wasn't actually wrong and I've learned something. If they don't, it's a bug and I may as well tell the developer. They can then tell me why they did what they did if it's not a bug, and I probably still learn something.

It doesn't consistently, though. Or I'd have "got" what you were going for and not pointed it out. The logic and design would match in my mind.

If you just hold right and press B it doesn't slow you down. It's when you hold right, release right, then press B that it happens.

If you want it to slow down, that's a bug, and if you don't want it to slow down, that other thing is a bug.


There's the game at half speed so it's easy to see. Something displayed in that gif is probably a bug. Or if you want it inconsistent in this way, then I think it might be bad design.

If swinging the sword without left or right just zeroed out my speed outright (as in I didn't continue to move after the swing was over), I would have thought it was a game mechanic and not a bug. I promise, I try to think about things before I post bugs.

I think that's the wrong question. Why shouldn't it work when I do?! Say I do hold down, and then press B, and then hold A to buffer a jump. And say I release down slightly after that jump begins. This means I've been scammed out of jump control for some frames and there's no reason for it. To me this is like asking, "Why would the player want to pause when they're sliding?" Even if they never would on purpose, there's no reason it shouldn't work. Is the only reason that you don't want to program it? Think about what that says. This is a game you want to sell, right?

Your game seems to expect perfectly clean input, but that's not how players play. There will absolutely be times where a player will end up holding down during jump for some reason, and they'll feel something is wrong, even if they don't quite know why.

Have you ever accidentally pressed a diagonal in a game? I have. Your game makes me stop moving, then, in a way that's unexpected. If you had some mechanic where my accidental diagonal did something, okay. But you don't, and that's why I'm saying there's there's no reason for it.

Your game does not seem to handle "dirty" well. And while it's much more likely someone will release right before pressing B, holding down while jumping is a really similar problem. People aren't TASbot. You should have leeway for "dirty" input.


So does Super Mario Bros. But not in the air.
So does Kirby's Adventure. But not in the air.
So do lots of games, not in the air.

As far as controls, I think your character moves WAY too fast to react to what's coming up. Your character moves at 5 pixels per frame. (I think) There are 113 pixels in front of your character's eyes. This is 22 frames to see and react to something on screen. But in practical terms, it's less than this. If an enemy is also moving toward me like the hedgehogs tend to, it will hit me even sooner. Consider a player that doesn't know the exact level layouts as you do because you made the game. Could they react, or do they have to get hit a lot to memorize what's ahead for their second play? Edit: Possible I'm wrong about how many pixels he's moving per frame, but regardless it definitely feels too fast to react to things.

X acceleration seems uneven. Like I accelerate with a fixed value for some frames, and then get a HUGE BOOST right at the end. This huge boost frequently ends up getting me hit. I'm planning for the consistent acceleration, but that last boost just pushes me into stuff.

Review of speeds...

SMB1 - walk = 1.5 pixels per frame
SMB1 - run = 2.5 pixels per frame
Megaman1 = 1.5 pixels per frame
Kirby = 1.5 pixels per frame
Sonic the Hedgehog, normal running = 6 pixels per frame

Vigilante Ninja, old programming, builds 0-33 = 4 pixels per frame
new programming, builds 34-39 = 3.5 pixels per frame

I suppose it is going a bit too fast. Not quite Sonic speeds, but well over SMB running speed. I'll try it at a reduced rate 2.5 - 3, and see how it plays.



I will do my best to improve button consistency.

I think I've worked all the bugs out. Here's Level 1 and Level 3. Level 2 needs some more work.

-Max speed is now at 2.3 pixels per frame (slide is 3)
-I've slowed the fastest enemies from 2 pixels per frame to 1.5 pixels per frame
-Jumps are slightly higher, unless you release A early, then it's less
-slight level changes and graphics edit on the Ninja

http://dl.dropboxusercontent.com/s/pyxu ... g2_Lv1.nes
http://dl.dropboxusercontent.com/s/zow1 ... g2_Lv3.nes

Note, while moving code around, I accidentally made it so you can slide in mid air (down + B). I actually think it's cool, so that will remain. It's kind of like a jump kick. And keep in mind, you're invulnerable during slides, so this could be a good attack strategy. I haven't tested it enough yet.

EDIT: link updated July 20

Now it's hard to make long jumps in terms of less flight and more x-ishness (how do I say it correctly... Less hitting the head into the ceiling which bounces you into the bottomless pit and more horizontal movement). I'd like a feature where the player can tap the D-pad to activate a sprint move and then jump to make a horizontal jump without hitting the ceiling. This happens to me a lot of times when there's little surface to walk on and when the ceiling is so low. The jumps are very fast upwards, but slow rightwards.

Perfect. All fixed. Three small things you may want to try if you want to keep the air slide.
1. Perhaps give it an upwards boost when it starts.
2. Perhaps make it continue until landing.
3. Perhaps make it continue in the air as long as the button is held down. (But also have a fixed minimum distance)

The reasoning behind one is I think it will look better visually. The reasoning behind two/three is sometimes it stops just short of an airborne enemy which then flies into you. It may not end up feeling good, but it's an idea to try if you wish.

I actually really like the air slide, regardless and that it moves faster than walking makes it a new movement choice.

Small thing:


A bigger thing.

The hitbox for the slide should probably be a bit larger. The enemy I'm mostly on top of isn't dead.

Some of the jumps and things are indeed tough now, since I guess they expect the old physics, but that's less work to change, probably.

Sorry if I was too rough.

Edit: Another thing I just noticed. There's a flash when you pause and switch weapons. (Probably related to how it removes the old weapon's object). The flash may be intentional, but I don't think I like it.

Good points.

Maybe if you hold B at the start of a jump, you get a slight X speed boost. Or, maybe just any time you press B you get a slight speed boost. ?

I don't generally like speed boosts on a button (that's a whole thing), but it's about what you'd like best there.

Of those two choices, though, B always giving a speed boost I like best. It's easier for the player to find. (Assume no one will read your instruction manual, etc.)

I agree with you that no one reads the manuals.

http://tvtropes.org/pmwiki/pmwiki.php/M ... kingManual

I remember someone saying they found an easter egg in a game. The reply was..."dude, that was in the manual". I think it was about Zelda, using a second controller to get the save screen.

And here's level 2 with the new physics. I had to narrow all the gaps to make them jumpable. Also, I replaced the stupid fish at the end with an awesome alligator. I don't know if you can tell, but I really enjoy doing this stuff

http://dl.dropboxusercontent.com/s/n6sk ... g2_Lv2.nes

Edit: link updated July 20.

Glitch! https://www.dropbox.com/s/f9zc7p11pc1ds ... 1.png?dl=0

I know about that one. When you kill an extra big enemy, it flips oddly. I only designed the game originally, to handle 16x16 enemies. I have to use a bunch of ugly hacks to make bigger enemies work at all.


Edited: July 20
Fixed. All 3 files updated, new links...

http://dl.dropboxusercontent.com/s/pyxu ... g2_Lv1.nes
http://dl.dropboxusercontent.com/s/n6sk ... g2_Lv2.nes
http://dl.dropboxusercontent.com/s/zow1 ... g2_Lv3.nes

I had a change of heart. I think I will share the MMC3 version of the demo...(levels 1-3). Level select does actually work in this version. Enjoy.

(link temporarily removed, will put new one up soon)

Thanks for sharing the MMC3 version. How many levels will have the final version?

5 levels planned.

Nice! Now there's even a weapon retain option to keep the weapons. In the final game, you might make that unlockable. You know, adventure mode would be where you unlock things and arcade mode would let you play with those cheats.

MMC3 link above updated. Fixed about 5 bugs. Slight jump increase. Title screen should say "July 31".

The title screen will probably look like this...

It's always bothered me that you are frequently collecting items and you often don't see what they are. So I decided to try to change this. Meaning...collectable items now have priority over the hero, who used to have top priority, but moving the hero's priority bumps into the weapons-on-screen priorities, also need changed, and a few other. ...BIG change. I had to reorder and redefine the position of nearly half of the sprite objects!

In the end it was over 200 lines of code I had to change. Yes, I changed that many lines of code in one sitting. You know what that means...new bugs. Lots and lots of new bugs. Yeah! (Don't worry, I backed up every source file before I attempted this.)

This is my favorite new one (yet unfixed)...when I go to the next level, this happens...

(Edit, I also added a slight delay between when the collectable items appear, and when you can collect them, so you can see them better when you are sprinting through the level, rather than immediately collecting as soon as they spawn).

Hmm, fixed all bugs but the one I posted.

Honestly, I don't know what I'm looking at. It's using tiles from the wrong pattern table...but just on the right side.

I'm sure I didn't change any $2000 writes.

As soon as you die, it loads the game correctly. It only happens when you beat a level and then advance to the next (vs options menu switch levels).

It's a mystery.

I smashed the 'break glass in case of emergency' box, and trashed the changes. That last bug was too much for me, couldn't figure him out. 3 hours of programming wasted.

Now using the backup. Problem was (couldn't see collected items if spawned in same position as Ninja). New solution (besides a slight delay before you can collect)...items now spawn 5 pixels more to the right than before.

And, I still don't know what the hell is going on in that screen cap. It looks like 16-pixel-high sprites, but I'm certain that mode is never set. Bug exists in all 3 emulators I tested. Oh, well, in the trash. Moving on.

Did you try opening a debugging emulator (Nintendulator or FCEUX for Windows) and trapping all writes to $2000, as well as writes to the address where you keep the next value written to $2000?

Yes. No help.

You mentioned back ups, but it sounded like you mean you were doing this manually? Have you ever tried source control systems like subversion or git? I find them invaluable for any kind of software project; they seem almost as essential to me as a text editor at this point. (You get back ups, tools for examining differences, and complete history of changes for every file, all rolled into one service.) There are lots of free private subversion/git hosts out there that you could try this out with.

In order for it to be "backups", your repository has to be stored somewhere other than your own computer. When developing RHDE, I know I backed up the source tree daily to a flash drive; I forget if I'd already been using Dropbox by then. A daily backup regime can be thought of as a very primitive, coarse-grained version control system, as you can always unzip a previous tree and diff them.

As for real version control, such as Subversion or Git, that's an excellent choice for free software or other projects whose source code is public. Perhaps I haven't looked enough, but I know GitHub charges a monthly fee for hosting private repositories. You could instead lease a virtual private server (another monthly fee) and set up a Git server.

There are lots of free private repository hosts, there's no need to set up your own. I've been using assembla for years, but there are many others.

I think we should split topic, since it's not about Vigilante Ninja...

viewtopic.php?f=2&t=14751

Finally got some time to complete level 4. One level left...but I want to redo the music (one song per level, plus some others), and I have some other things going on, so it might take me much longer than you would expect.

One more.

Looks good

Here's some screen shots of the last level. It will be much harder with lots of difficult jumps and more enemies. (Still haven't drawn or programmed the enemies).

If I hadn't mentioned it, there will be new music, with a new song for every level.

Awesome

Goodness, I haven't looked at this since it was Purple Cape Man.

Loving what you did with the last level. For being a keep made out of stone, it feels very alive. The lantern and its light is beautiful. However, in vig53, perspectives get quite distorted to my eyes when the ceiling blocks are drawn close to, at the same level, or lower than the 'base blocks'. Maybe that's what you're aiming for, though?

Re: perspective

I'm open to suggestions. I didn't want to just reuse the blocks that you walk on for ceiling blocks...but maybe it clashes a little when they are extended.

Side note, I just threw in some spikes right where the Ninja is standing on the top picture. I looked at it now, and was like "Hey, don't stand there!"

i started out testing an alternative, and then i went a little too far and completely butchered your tileset in the process.

Anyway, if the ceiling blocks are only tilted sideways, they don't clash as much with the ground blocks. You may still want to keep the style different, only the different tilt is needed for it to work, i think.

Please ignore the rest.

na na na na na na, FINAL, na na na na na na, BOSS, na na na na na na, FINAL BOSS!

(lightning will only come 1 at a time, this is a test picture).

(everything you see is BG except the ninja and the blocks he's standing on, movement will be done with scroll shifts).

looks pretty neat!

Hmm... What's a sprite and what's a background there?

Sprite (and you can just barely see a dot for the sprite zero hit)



Background



I've colored the lightning differently, to show that they each use a unique color palette entry.

Nice. I like it how you calculated correctly which tiles of the wizard should go where.
Now imagine you're on the ground and then one of the platforms drop onto your head like a troll, lol. Right before you would defeat the boss. Could you program that?

Level 5 (the last level, and the final Boss fight) is almost done...now just about 100 small details to fix, and convert everything to MMC3, and put the final music in. "It's almost too easy" (quote from the Waynes World movie, after Garth describes something very complicated).

Teaser clip...

https://youtu.be/1TuGW4I9-Lw

Cant wait

one thing to note though, i wouldve coloured the lightning bolts in electric colors (light yellow, white, light blue) rather than red, green and lemon yellow. but thats just my 2c.

They will be colored in lightning bolt colors. They're just oddly colored to make them easy to distinguish in mock-ups: "I've colored the lightning differently, to show that they each use a unique color palette entry."

oh, brainfart. >_>

I thought for a second that the recording had a lag or that my internet had a lag. The moment when the circles appear, it looks like the game froze a bit. I'd like to see the circle grow with a sound effect and the lightning extend bit by bit instead of appearing like a whole new BMP frame in a MS Paint animation.

Here's a good one for you...

I've been ignoring this thread for a couple years now as I assumed the thread topic was something to do with being ninja'd edited by someone while making thread posts somehow. I never reasoned what how such a ninja post edit could also be vigilante some manner. Just thought wow it must be some significant bbs issue as it keeps popping up from time to time in my unread posts.. Was finally curious enough to see what all the fuss was about today. Opened the latest post and was confused as to how the topic got derailed so badly from bbs issues to a homebrew game progress. Guess I should pay more attention to the thread topic...

Sorry for the off topic post, but thought others might find humor in my poor assumptions. That is all, let the game dev continue.

Re: infiniteneslives

Funny.

Ok, small update. I have a stable build with all 5 levels and everything but the new sound/music in! My current 'to-do list' is about 12 things. Hope to be at final game testing by end of January.

Sound and sound fx are in and appear to be working / stable. This game is about 99% done. Will probably do a few months of nit-picky changes and testing.

I'm using Shiru's most recent update of famitone with full famitracker engine. It was amazingly difficult... due to the fact that....it's in cc65/ca65 and I'm using asm6. .I failed to convert the code to asm6...I already had plans for 80% of RAM space, and had to make absolutely certain when compiling the cc65 files that there were no overlapping variables...about 64 of which I shoved in the stack! I brought the code over as a BINARY import (.incbin), and had to use hardcoded absolute addresses...The music uses almost a whole bank of DMC files ($1400 maybe). Lots of MMC3 bank switching madness.

It's a freaking miracle that it works at all. (Sigh).

Edit...thanks to Estlib for writing me 9 new songs. Sounds great.

I love this song.

https://youtu.be/3jS5JY8FT2o

Here's clips of every level...with the new music.

https://youtu.be/xaOgFGrzW4E

and again, the title screen and music, if you missed it.

https://youtu.be/3jS5JY8FT2o

Can i upload the entirety of the soundtrack on my channel, or do you want to keep it off youtube?

Yes.

This game is awesome! Wow, if it was released on Humble Bundle as a DRM-free ROM or a DRM-free ROM merged with a NES>Real-hardware JIT compiler/emulator thing, I'd so buy it!

Dougeff you're hitting gold with your game, buddy. Excelent work!

I had missed it! It sounds really good!

Wow, this is looking like great fun! Congratulations! And the music is really great too. The castle tune reminded me a little of the overworld theme of Realmz, that hits a certain nostalgic string inside me.

oddly enough, i had that song in winamp at the time when i composed it. though the theme itself is intended to be a remix of the older version of vn2 level music.

Opinions, please. I'm considering changing the graphics for Level 1. I've never been happy with the hills. Here's what the old version looks like...



And, here are the new concepts...





The shadow, under the blocks, is a thing you can slide under. The fence things would replace the hills. You can jump on them, enemies will also. The gray blocks would be more rare than this picture shows.

Possibly, would add parallax scrolling on the hills.

I like the background hills a lot, especially the broken outline.
The diagonal black pattern on the foreground feels like a pattern for pattern's sake, and detracts more than it help.

I'm sorry to say, but I'm not a big fun of the new graphics... While some elements look fine, they're clashing badly against each other. The hills are nice, and so are the trees, but one being outlined and the other being shaded kinda prevents them from looking good together. The orange things (fences?) look fine too, but the total lack of perspective as they are placed farther away on the field is pretty confusing. Speaking of confusing, that rock pattern is my biggest gripe with these graphics... They appear to depict a "Q*bert style" 3D formation that doesn't look particularly good (too few colors?) or makes any sense in the context it's in, it almost looks like a window to another dimension or something.

Another aspect in which different elements disagree is realism. The grass is reasonably realistic, with seemingly random dithering and lack of discernible details, while mostly everything else is stylized. The old graphics were simpler, but were also more harmonious and direct to the point. It was easy to tell what everything was and to predict how the player would interact with the environment.

If you're really set on this graphical overhaul, my advice is that you try to stick to a well defined style. Make up your mind regarding shading (none, cartoon, volumetric, etc.) and realism.

I wanted to do something more interesting than straight horizontal and vertical line bricks.

I really like the new backgrounds, it's much less "generic platformer" and more in style with the theme of the game. Only the rocks look weird, the outline doesn't mesh well with the 3D look of the texture.

edit: Wow, I'm getting strong Gimmick! vibes from that soundtrack. Very good job!

The soundtrack is amazing!

Really excellent mastery of "sunsoft bass"!

Estlib did great on the music.

More tests on walls...

This looks great I think. Even if the darkened brickwall is a bit weird when there doesn't seem to be anything behind it
Semi-depth in a 2D platformer is always awkward.

It reminds me of a C64 game. I like it!

That looks much better.

This looks fantastic and the music is amazing.

Those walls are so awesome! Put that in!

Ok. This is starting to come together. Parallax scrolling seems to be stable and working.

https://youtu.be/bSyRWTovefQ


Sorry it's the old music. I actually build each level separately, and then later import their data into the final build (with the new music code / data). It would be impossible to insert the music without changing mappers (from NROM) on the single level tests.

Walking on platforms that are depicted as seemingly tens of meters into the background is strange. I think hovering platforms would read better.

Wait... the brown fences are platforms you can stand on?!?!? Then why are they drawn with their bases partially covered by the grass, as if they were on the ground in the far background? That makes no sense, they really should be drawn as floating platforms, and preferably with depth, since the other things you can stand on (the ground and the brick wall) now have depth. Depth can maybe be omitted if you use the argument that since he's a ninja, he's able to walk on thin objects without any trouble (but then so can the hedgehog!).

Is this better? Replaced fences with abstract magic floating platforms.

Having the top of the platforms being darker than the front, when the top of the walls are lighter than the front is a it unusual. Also, the dark brown border on the lower part, outside the outline, looks like shadows in the grass, due to the color. Those two things, along with the fact the wall that extends over the dirt path casts a shadow, but the platforms don't, still prevents the shapes from reading as foreground element. To me, they are ambiguous as to whether they are foreground or background.

A lighter top plane and shadows on the dirt may solve it. Getting rid of the brown haloing on the bottom would help too.

That's not a shadow on the left. It's a tunnel that you can slide through.

Yes, and is the tunnel not being indicated by a darkened back wall, and a shadow cast upon the dirt? ...Because that's what it definitely looks like to me.

Shadows...I guess.


This is what I ended up doing. Ok, 1 down. 8 more things on my To Do List.

Wow! This is probably gonna be one of the best homebrew NES games I've played! Well, after Super Bat Puncher. But yours will be finished!

It's actually 99.9% finished. I want to revise the graphics a little, and tweek the difficulty of the bosses.

I might make the platforms on level 5 a little less insanely difficult. Maybe.

I'm planning for a VERY limited release. Pretty much, if you don't contact me directly, and tell me you want one, you probably won't be able to get a copy.

Since you already told me (just now) that you want one, 8bitMicroGuy, I'll reserve you a copy.

Yay! Thank you!
Also, I see that the hearts and the weapon in the HUD have an ugly pallette. If you could place nice colorful sprites over them, that would be cool and you could make it look like it has 7 colors: 1 background, 3 from background and 3 from sprites! There's 6 hearts that are 8x8 and there's a 16x16 weapon which is exactly 8 sprites per scanline. If you program the drawing routine to draw those 10 sprites, that would be very cool. I'm just not sure if you have enough room in the code and the CHR ROM and the OAM to place all that.

I don't have any free sprites.

The core game code was programmed before I knew what I wad doing. I had to do some ugly hacks to get enemies bigger than my hardcoded 16x16 design to work. There will be no code changes, other than slight tweeks of hitboxes, or slight tweeks of timed code (sprite zero).

The main fixed bank has...I think 17 bytes free. So. No changes.

...actually, that's an exaggeration. I have 2 unused banks ($4000 bytes total) free. I could swap banks and put more code there. But, I don't want to.

Alright. I'm waiting for the moment to get this game. When I do, I'll make a Let's Play of it when I get the time.

Does this also mean no Internet release of the final product? Or does "VERY limited release" apply only to the cartridge release?

I want to see if there's any interest in the cartridge, before I decide on how to release it. There's probably a good reason the Battle Kid isn't available free. I'm going with the same assumptions.

There is a free demo of some of the levels.

Any plans for a soundtrack release? (NSF and/or bandcamp?)

If you're going to sell cartridges, maybe you should start a Kickstarter campaign for your game so that you get enough money to run the production of the cartridges. Unfortunately, I don't have an NES so I cannot play a cartridge, but I'd loyally keep the ROM for myself if the game is not free just like how I keep the DRM-free version of Freedom Planet only to myself. I'm not a seeder or a pirate. If you want, you can send me a version of the ROM tha has a subroutine that renders "LICENSED TO 8BITMICROGUY" on the screen in the main menu, in the loading screen and on top of the HUD during gameplay. You can make a checksum checker to cause the game not play if the text is hacked. Also, keep in mind that this is just one of my online usernames. The other one is Zvoc47.

No. I meant you can buy one, if you want. I don't plan to make personalized versions.

Anyway, there will probably be a kickstarter for the other game I'm working on...which is not my call, since I'm not in charge of that project.

That's up to estlib. They're his songs. I thought he was going to post them somewhere, but I don't think he has.

Edit, correction...
He did post one song...

https://m.soundcloud.com/estlib/vigilan ... heme-dread

Depending on the costs (these usually aren't cheap to produce), I'd be up for a cartrdige.

The game is now 100% done...with only some final play testing remaining, before I order cartridges.

I hadn't really heard the music before (didn't have speakers hooked up to my work station for a very long time and didn't check the ROM out again after getting them hooked up).
Estlib's tracks, especially the one you linked, are all great. Thanks for sharing it.

How much would a ROM cost? I would like to buy the game.

I have to crunch some numbers, see how much it costs to print a booklet / label. It will be similar to the homebrew prices at RetroUSB, plus shipping. I don't think there will be a box, but if so...a little more cost.

I could make a limited cd release of the music to go with the cartridges i guess (which would be put in together with the cartridges), but other than that, theyll be all uploaded to youtube for free listening soon(ish).

I watched the video you posted about the redesign of Level 1.

I saw the intro and it says "Beware! The wizard has enchanted all of the animals to attack you.". I just love it when game developers make an argument why there's so many NPCs trying to kill you. While Mobius is flooded with Eggman's robots, and Avalice (Freedom Planet) with a vengeous prince's robots, your world has just normal animals which are enchanted. Wow, I just like this idea!

The background music is also good too. Nice, cheerful, epic at some moments and also long.

The game cartridge will look like this. (Photoshopped)



Still need to work on the manual a bit more.

Where are you shipping cartridges from?

Pittsburgh.

Will I have to get a physical cartridge (which means that I'll have to pay the expensive US shipping to Croatia) in order to get a ROM when I buy the game?

Hmm. I hadn't thought about that.

...not to mention import taxes :/ Battle Kid 2 ended up costing me more than twice the asking price on the webshop. Not dougeff's fault, but makes me have to think extra hard about what stuff I bother importing

Yeah, wouldn't it just be easy that I pay you over PayPal for "goods and services" and then you send me the ROM?

Imagine a house of cards (I couldn't find appropriate image, all google searches go to TV series)

Me: Just one more card on top

(house of cards collapses)

Me: Dammit!

Yes, small last minute code change introduced huge complicated bug. Debugging now.


EDIT, fixed. Deleting a few lines of code, pushed an important subroutine from the $a000 bank into the $8000 bank. It was called when I had bank switched the $8000 bank out, and it jumped to data instead of code.

Interestingly, it managed to find it's way back to the main loop every frame, but because the subroutine handled sprite collisions...it returned "collision detected" every frame, for every type of collision. I was getting 1ups over and over, and getting hit by nothing, over and over. Fun bug.

Wow that's scary. You should use some kind of offline version control program so that you can always restore the previous build without having to use Save As for every single change.

I'm just tidying up the final details of my game. What's your opinion of...



Context. The top left was the original. I recolored him black...but that doesn't work for level 3, all black background. Do you think the bottom most sprite is a good idea, since I prefer the black. I just game him some brown outlining (just for level 3).

Why not both? Fabrics are often different colors based on lighting.

I like the old blue in the cave better. Of the five samples in that picture it is the best one. I think the change in scenery/lighting can justify a change of colour for different levels, so it need not be the same colour everywhere. (Brown outside, blue inside is perfectly fine.)

What I really think is important is that it stands out against the background so you can see what you're doing. I don't feel the brown outline does this job well in the cave. The black against the darkest grass in the day does not stand out well either, but neither did the old dark blue. (That's why I think the lighter blue in the cave was the best.)

In Super Mario Bros., Goomba and Buzzy change colors in dark levels.

Thanks for the input. I will test some more palette options.

I think this is what I'm going to stick with...

13 blue for levels 1,2,4
03 blue for levels 3,5



New demo will come soon.

I was thinking about the Ninja to be black at all times. However, the shade would be brown during the day and blue during the night. I don't want to use any outlines for the Ninja during the dark, although that might help to make the player know where they are, but still, it looks too much MSPaintish when outlined.

Here's the final demo of levels 1-3.

http://dl.dropboxusercontent.com/s/2ipv ... 2-DEMO.nes

They're very good! The game has a fair challenge and will never disappoint the player. I don't have to watch out if I'm gonna run into an enemy, but I simply press down and B and slide through them. I can attack in air, below, upwards. It's so much fun. It's not like one hit you die, but here the game gives the player a chance. I like this feature to keep weapons too, but I played well without it. Couldn't beat the 3rd boss, though. Been on my last life and game over. Short, but sweet.

What does the difficulty selection change?

This is probably too late to be any good for feedback, but I feel that the game is balanced well enough that you could hae done with much fewer hitpoints for the ninja. As it is, I feel like I can plow through large portions of the game without caring much if I get hit.

Easy - injured by half.
Normal - injured regular, 6 hearts
Hard - Injured regular, 5 hearts 4 hearts

And the bosses HP and behavior increases with difficulty.

Level 4 and 5 bosses are a bit harder, not available in the demo. It's usually the level 4 boss that I struggle with, especially in hard mode.

Oh, and you start with fewer lives in harder modes.

The "traditional ninja garb" of all-black suit is actually traditional Japanese stagehand garb. Kuroko (black) is the usual, but white (yukigo) and blue (namigo) variants* exist as well.

Of course, gameplay is not suited for when your character blends perfectly into the background, so…

*In case you wondered why Joe Musashi wearing all white, and Ryu Hayabusa in all blue…a likely explanation, though I'm not finding anything English actually calling this out, and my Japanese is rusty enough that I don't want to go looking too far.

Man, I haven't played this since it was a Batman-expy.

Since I can run through 'hard' difficulty in my game with no problem...I decided to make all difficulties harder (heart power-ups less frequent, 100 coins for a life now)...and I added a 4th difficulty 'Crazy'. That's 2 hits and you're dead, no heart power-ups. And, I'm making a few of the enemies a little more aggressive.

Adding a new super-difficulty because you can breeze your hardest? Cool!
Increasing the minimum because you can breeze through it? Not so cool. Remember, you're literally the most-knowledgeable player of your game who exists. This is the sort of thinking that produces crazy-hard inaccessible ROM-hacks.

This is why you have testers. I agree that it's very difficult to actually perceive the difficulty of your own creations, and you need input on that stuff.
But as I already addressed above, from what I played of the demo, even normal difficulty allows you to pretty much run through everything tanking damage and picking up health powerups without thinking much about the enemies. I think it's completely fair to increase the lowest difficulties.
You should also always expect there's someone out there better at your game than yourself.

I managed to beat 'Crazy' Hard. It was grueling. Several Tries. But, it can be done.

I'm not worried about 'Easy' being too hard. In the options menu, you can cheat and get 10 lives, and you can skip to any level. A lot of the increased difficulty is in the behavior of the enemies, which are more aggressive. For consistency, all the difficulties will have the same enemy behaviors.

And I have a few people testing the game for me right now. They will let me know if 'Medium' is too hard.

Soundtrack will be available to listen within the next week, ill update this post.

Soundtrack now avaliable https://youtu.be/WkinjUsG2fU

This looked weird to me today, while doing final testing...

Although, he is exactly 32 pixels in length in both, the aspect ratio of the TV, he looks super stretched when sliding...about 25% longer. I think I will have to adjust.

According to my math, I should have made him 26 pixels long sliding (26 x 1.25 = 32) to compensate. But, it would probably look just as weird in an emulator.

I think the size is less of an issue than the animation itself.

Firstly, the ratio of players playing on a CRT compared to say, an AVS on an HDTV is decreasing, especially when you consider the type of collector with the excess income to purchase a homebrew. Secondly, the squash and stretch principles of animation could be used to justify the difference in both height and width for that frame.

However, the stance itself is too stiff and static. Take Megaman's slide, for instance, which has a dramatic gesture to the position which is also seen in baseball slides.

V. Ninja's sliding position is like a mannequin, laid like a board on its back, looking straight up into space lifelessly and casually holding its sword, again-straight like a board, as if it were a toy stuck in the hand of an action figure.

It would be greatly improved if he were looking where he's going, in a dynamic stance, holding his blade in a position that shows intention (to telegraph to the player the offensive purpose of the slide because at the moment it looks like it's accidentally killing enemies due to the way the sword is held).

It's 14 percent, at least on NTSC. Something 28 pixels wide and 32 pixels tall will appear square on a 4:3 TV calibrated to the standard.

Showing my work

The pixel aspect ratio of the NTSC NES is 8:7, meaning that pixels are ~1.14 times wider than they're tall, so 25% is too much... Are you by any chance using an HDTV that's stretching the 4:3 picture to 16:9?


Since the PAR is actually ~1.14, the correct width for the sliding frame is 28 pixels.


You can't please everyone. I prefer to assume that a CRT SDTV is the correct way to display NES video, so I obey the official PAR or 8:7. If people who don't know any better prefer to play every existing NES game in squashed (square pixels) or stretched (4:3 stretched to 16:9) form, that's not my game's fault. If they play every game wrong, they probably don't care.

You mean like this?

https://goo.gl/images/RqERhu
(Image of soccer / football kick while sliding)

Yeah, that could work really well.

EDIT:

...but if you try to use that stance, you might want to depict clearly whether the sword or legs are intended to be used offensively.

This is what I came up with...

That's a big improvement

That looks so cool!

That's much better, and definitely a step in the right direction. However, an even stronger exaggeration of the position
could make it look less like he's reclining and more like he's sliding. Also, the way the head overlaps what he should be sliding under is a bit distracting.

You might try rotating him toward the camera some to get the head lower, and drawing the lower arm further back to exaggerate the horizontal movement. (Right now, the lower forearm is facing forward, but it would, in a slide, drag behind the person).

Also, have you thought about altering the design of the character to provide something to help show movement? I-Ninja has a bandana that flows behind the character for example. I think something like the excess bit of hood in Ninja Hattori's design could benefit this design. CHR space allowing, it could extend slightly behind head to show horizontal movement (running, sliding, etc.), above the head to show downward movement (falling) or downward to show upward movement (jumping). Excess belt flap could serve the same purpose, although you'd have to be careful to avoid unintentional readings of the sprite since the belt shares color with the flesh. Even if CHR space is tight, sacrificing some of the total size of the head to allow a more unique silhouette could be beneficial.

I like the new slide the way it is.

BTW, I'm mere hours away from flashing the ROMs. So, there will be no more revisions. (actually, Infinite NES lives will be).

No worries. Glad to have been of help.

Are you from Australia? I thought you were Korean.

Edit. I see Cowlitz County is in SW Washington state. I'm guessing American.

I'm American but reside in Korea. I've actually never been to Washington though. I started working on the Cowlitz games due to forum connections and was attracted by the charity nature of the project. (We have people from three countries working on that game.)

Soundtrack now avaliable https://youtu.be/WkinjUsG2fU

Is there a way to get a cartridge in europe? The toll from USA is a turnoff for me.

Did you just change the slide animation? Haha, I actually liked how the original was. It was like the ultimate wedgie slide. Like if you ever slide like that you would be giving yourself the biggest wedgie ever. But honestly the new pose does look better graphically and seems to make more sense.

The little I heard from the soundtrack so far was really cool! Will check this out soon!

MANUAL...

http://dl.dropboxusercontent.com/s/dw5f ... anual4.pdf

The music of the game has surprised me a lot. It reminds me of some musical compositions proper of the SunSoft games for NES / Famicom. Have you composed it?

I added a retrospective (post-mortem) about Vigilante Ninja 2 on my blog, if anyone is curious.

https://nesdoug.com/2017/10/08/vigilant ... st-mortem/

Very nice to read, and interesting, it's nice to see the programmer's opinion on his own game. I have to play your game, I have not tested yet.

Good job!!!

I really liked reading this. I think it's great that you reflected honestly on the game and mistakes that were made during the design process. One of the things I also underestimated in designing a game is the challenge of making it fun to play. When I envisioned my side-scrolling shooter (similar in gameplay to yours), I guess I just assumed it would be fun. Once the whole engine was built, and I created a test level, I was surprised at how much I had a to tweak to make it challenging/interesting, but not too easy or too difficult. I still haven't finished the game, partially because designing fun levels/AI is so challenging.

Thanks for your replies, guys.



I'm having the same issue with my next game, the guitar girl game. The game engine choices I made (you don't die if you fall, for example) has made gameplay too easy, and I can run through every level in 20 seconds a piece, which isn't fun at all.

If I make falling kill you, I basically have to start from scratch, and redesign every level. But, I'm basically looking at that possibility anyway, because it's not fun.

@dougeff: Just add more challenges, e.g. enemies

It could also be that the levels are too short, which can really suck in terms of programming if your max number of screens is too low. Depending on "why" the maximum is what it is, you may have to go back and make a lot of changes to the engine to accommodate a larger number of screens.

What commercial games are most similar to yours? Cowlitz 2 was my first attempt at level design. Not having done it before, I read a handful of articles, and then started watching longplays of games in a similar genre. First, I checked the big ones: Bubble Bobble, Loderunner, Donkey Kong, etc. Then I started digging through obscure ones, for Spectrum, Amiga, etc., asking myself, when I saw a level, how I could try to achieve a similar result within our game's constraints.

I printed tiny booklets of graphs at our game's gameplay area (16x12 metatiles) and spent a long time putting them on paper first, then probably each stage received some nunber of revisions after playtesting by testers of varying skill.

Anyway, one of the articles I found suggested starting a design by drawing an intended path for completing a stage.
Then, decide what obstacles keep the player on the path (walls, spikes, vines, etc), what obstacles interfere with the path (enemies), and what alternatives to the path are there? (Perhaps a risk/reward branch from the path that's more dangerous and not mandatory for completion)

Being a co-op game, I had to make sure there was a successful path for each player (often different for interest), and our game mechanics helped with the risk /reward (not only are there mandatory items to collect, but also optional ones that offer additional rewards).

Hopefully that could be helpful. I'll try to track down the articles and post them too.

The number of screens shouldn't really be a problem, if the gameplay difficulty is well balanced.

A small arcade-styled NES game I was recently commissioned to program, cranked up the difficulty with regenerating powerups (like the fruit in Pacman), and some enemies would beeline for them, to give them an advantage over the player.

Imagine the hammer in Donkey Kong, being wielded by a common enemy!

It really depends on the style of game. I think once you move beyond single-screen, it definitely is a factor to consider. Think of a game like Sonic, for example. One of the things that makes the game so fun is those parts you can go speeding through freely. As the player, I would be disappointed if the levels were too small to allow for it. I don't think it's a good solution to put the player through 4 really annoyingly difficult screens to increase the time it takes to beat a level. I would much rather go through 32 screens that aren't as challenging, but are more interesting.

Sonic levels are built out of huge chunks (256x256 pixels in Sonic 1 and CD, 128x128 pixels in 2, 3 & Knuckles) for a reason. You don't need much detail when you're zipping through a path designed for speed, so the game gets away with repeating large chunks of terrain over and over.

I don't consider the classic Sonic games to be all about speed, though. In Sonic 1 there are zones that are absolutely nothing about speed, such as Marble and Labyrinth, but they're still fun to play (Labyrinth less so, because of the slowness of moving underwater and the fear of drowning). I really like to explore, get a better sense of the architecture of the levels, look for hidden rooms and items... You can't do that if you're zooming through every stage.

Right. The freedom to zoom through sections is part of the fun, but not all of it. I, too, like to explore and absorb the environment. In either scenario, if the levels are too small, it can have a negative impact (either too short to run through, or too short to spend enough time exploring).

What are you talking about? Vigilante Ninja 2 is awesome! It took me a while to get used to the physics. The game was challenging and hard, but once I got used to the physics, I've been passing levels in a row. The bosses are very well-made and it feels very rewarding when I finish them. The game seems short, but it's one of the best NES homebrew platformers that I've played so far. Please don't delete it! The game is awesome! I'd like to see more of such games as well as Super Bat Puncher. If only there was some kind of a permissive-open-source game engine for the NES that utilized nice physics so that we could all be coding games rather than coding engines and system stuff.

We were talking about something else. Which is why I was trying to move the discussion over to the "Jammin Honey" thread.

Apparently I'm giving everyone here a review on their game I guess.

Anyway.

- Music is some of the best I've heard. All songs are catchy and unique and sound great.

- The game mechanics are good. The player controls just fine.

- My only real suggestions are to try and make the levels more diverse design wise. For example I can just spam the attack and mash right on the D-pad and pretty much beat the game. It would be great if the levels offered more variety so that I can't just use this one strategy all the time for the whole game. Maybe make some levels where you have to climb up or down a little. Or go to the right then up then left then up then right in like a little cave or something.

- A more diverse group of enemies might also improve the game. Say for example an enemy which can't be killed or an enemy which will kill you if you touch it only once. It just seems as if all the enemies seem the same.

- Boss battles are good though.

- Also how do you know which power up scrolls will give you which special ability? Is it just random?

https://www.youtube.com/watch?v=FQCAeVY ... e=youtu.be

I played my game after several months off, and I thought "wow, this scrolls too fast".

These Game Genie codes will slow the right scrolling by 20%. Which feels a little better.

YLXOTLLK + YLUPZLAK.

However, this makes 1 jump in level 5 quite a bit harder to make. (not available in the demo).

By the way. I have about 10 copies of this game left on cartridge. If anyone wants a copy ($) let me know. Thanks. Soon, I might auction the rest of the games off.

i wouldve gotten one if it would run on a pal console

I made 100 tiny changes.
-bigger sword/weapon hitboxes
-less head collision with ceilings
-better PAL support (including music at the right tempo, wrong graphics title/cutscene screens)
-moved 1/4 of the enemy start positions
-changed the enemy walking back and forth code, which had a typo bug
-minor graphics changes
-added secret Gameboy Mode
-shifted the BG screen 1 pixel up

If anyone here would like to test the revised game, send me a PM.

Here it is. The full game. Vigilante Ninja 2 (rev A).

http://dl.dropboxusercontent.com/s/13w2 ... l-revA.nes

And here's an explanation of the scoring system (since I never mentioned it).

100 for each enemy you kill

100 for each coin you have at the very end

5000 for each life you have at the very end
(not counting extra 10 lives)

10000 for beating each boss

- Difficulty Bonus -
0 for easy
40000 for medium
80000 for hard
120000 for crazy


Note, the "secret" gameboy mode is activated by pressing A+B+Select on the options menu.