Vigilante Ninja (edit)

[dougeff]

Why is this limit in place?

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...

[dougeff]

square foliage

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.

[darryl.revok]

square foliage

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

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.

[tepples]

I don't want to have to change the compression system, and redo the past 3 levels.

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"?

[dougeff]

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.

[dougeff]

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)

[na_th_an]

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

The collision si fine as it is now.

[darryl.revok]

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.

[dougeff]

(change) jump physics

I'll try to improve these a little later.

fix the collision (with projectiles)

Will do.

less dithering

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

[darryl.revok]

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.

[8bitMicroGuy]

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!

[na_th_an]

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:

Code: Select all

-3, -4, -4, -3, -4, -3, -3, -3, -3, -3, -2, -3, -2, -2, -3, -2, 
-1, -2, -2, -1, -2, -1, -1, -1, -1, -1,  0, -1,  0,  0, -1,  0
 1,  0,  0,  1,  0,  1,  1,  1,  1,  1,  2,  1,  2,  2,  1,  2, 
 3,  2,  2,  3,  2,  3,  3,  3,  3,  3,  4,  3,  4,  4,  3,  4

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.

[Punch]

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!

[dougeff]

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.

[na_th_an]

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.