Progress Thread - Nebs & Debs Prequel

EDIT 6/3/2017

Created a new thread for tracking progress.

EDIT 2/15/2017 More bug fixes:

* Levels 2 and 3 should no longer contain visual artifacts and camera jitterriness.
* Fixed issue where dash counters would sometimes get out of sync with Deb's actual dash-ability.



EDIT: 2/3/2017 -2 Added newest build with a fix:

* No more mysteriously dying Debs! There was a bug where the Z65 enemy could clear Deb's sprites upon be destroyed.



EDIT: 2/3/2017 Added newest build with a couple fixes:

* Debs can no longer dash into and climb walls.
* Debs can no longer dash past the screen boundary and into the unknown.

I am currently working on a NROM platformer called Nebs & Debs. To help motivate me to get it done I am joining the competition with the goal of submitting a prequel using the same engine.

A sample animation of the protagonist Debs is attached.

Will post again soon.

Looks cute. I like how his ears bounce and how his eyes bug out when he jumps.

Is that two people? Which one's Nebs?

Animation looks awesome - plus I love platformers. Good luck!

Doing a prequel for the compo is a good idea! Is this a squid-hat?

Debs is a humanoid. Nebs an Nebular Octopus.

Nebs was fleeing the fortress. Debs was charging the fortress. Debs turned the corner. Nebs turned the corner.

SMACK! WHAT!?! GERROFF! EWWWWW.....

Lucky for Debs, the fused octopus grants her the power to warp through walls and enemies; an ability she'll need to finish her quest to free the four the sages. Unlucky for Nebs, every freed sage moves them closer and closer to the creature he fears the most.

Looks good. I would make the octopus bounce one frame out of phase with the body movement. When the player's body begins to move up is when the edges of the hat should show their dip. That way, the octopus's tentacles will appear to have inertia.

Looks more like a quadpus though!

This happened to the octopus in my game too; it seemed like in 2 dimensions it should only require 2^2 legs.

Then again, Octodad only has four legs too. Maybe this is a video game thing...?

This sprite looks real nice, though, dullahan. Looking forward to whatever you come up with.

It's not limited to video games... Octopus from Pocoyo also has only 4 legs.

And Octocat has... five?

Looking good. Incidentally I'm stuck in my project because I'm trying to program a tool to generate animation code easily... you seem to have that already figured out so props to you

Why not just hand-code them? Once you have the metasprites defined (there's a handful of tools for that) animating them, using a timer and a defined frame count is trivial.

For example, my Dragon Quest clone uses this format:

After this, the result is used to read from an offset table, and the sprite routine handles the rest.

For the moment I have an Object table that points to an Animation table that points to several Metasprite table entries. Maybe I should simplify this a little bit but it's the most flexible system I could think of. I need at least to have an object table since I have a linked list to spawn/destroy objects, each represented by a byte.

Anyway this isn't about my game, sorry for doing a light derail of your thread.

If you'd like, I would not mind sharing my metasprite animation format, which allows for variable frame lengths and arbitrary loop points.

I don't want to cheat on this and implement everything by myself but yours could be a good reference so I don't do a dead-end design that's going to be completely replaced once I find out it's not viable. So yeah, you can show me your format, thanks a lot.

Thanks, I will give that a try.



Thanks rainwarrior. Yeah, the number of arms/legs for me is strictly due to size constraints--I couldn't fit any more in a 16x24 space.



When I am working on animations I just do it all inside PyxelEdit which has a nice animation editor. Then when I am happy with the animation I export a sprite-sheet. With the sprite-sheet as input I run a ruby script to generate the CHR and ATTR bytes. Then I manually enter the frame def bytes in the metasprite/object definition.

I used to have a fancier workflow with ruby scripts detecting the palette, reading JSON animation defs, etc; but it was buggy and complex and not offering enough benefit.

Made some progress with collision detection logic and reacquainting myself with the code-base (have been working mostly on pixel art commissions the past few weeks). I also cleaned up some of my metrics tools such as ROM and RAM usage.

So next week I hope to have collision detection working and basic player movement. After that will be Debs special ability--blinking through walls and enemies.

PLEASE.
I've been struggling with animation code for so long. I wasted an entire month making a metasprite animation routine that ended up using an entire 30 rasters for a single instance. Then I started making high cycle efficiency code for each animation and my raster count is down to like 3 but I'm running out of ROM a lot faster. I need examples so bad.

I'll see about cleaning it up a little, as it's only slightly coupled to how my game is built right now.

Progress has been slow with collisions between the background and sprites, but I now have it working. See attached GIF. Up next need to experiment with Debs special ability.

- EDIT -
The embedded GIF preview looks corrupted, but clicking on it to view in another tab works fine for me at least.

Corrupted, makes me think of the old Animator vs Animation …animation.

The "preview GIF" is corrupted because it's doing the Wrong Thing(tm) for "erased frames". Animated GIFs support multiple methods of frame disposal.

Preview GIF: download/file.php?id=6698&t=1
Full GIF: download/file.php?id=6698&mode=view

Please see:

* Frame Disposal Methods: http://www.imagemagick.org/Usage/anim_basics/#dispose
* Types of Animations: http://www.imagemagick.org/Usage/anim_basics/#types

I have not run ImageMagick's identify on either image (the extended metadata is what needs to be viewed, to determine disposal method), but I'm certain it would disclose the mistake.

I don't think it actually has anything to do with disposal? I think it's entirely about scaling. After the first frame none of them are in the correct position or correct size. The size is even inconsistent (obviously every frame should get the same scaling).

If they were scaled correctly, you wouldn't see the "bad disposal" trails. The problem is the pixels that are supposed to hide the previous frame's sprite are at the wrong position and size.

Not all that useful, since it was almost certainly phpBB that wrecked the GIF when resizing it down.

Specifically, what it looks like is happening in the preview resize:

1. The X,Y offset of each frame is not being changed, instead of being scaled down with everything else.
2. The scale of each individual frame is adjusted to match either the width or height of the preview image (best fit), rather than the overall scale of the image.

This means that frames where only a small sub-rectangle changes, that rectangle gets blown up to the total width/height of the image, and also gets left in its original offset.

Basically the resizer makes the incorrect assumption that all frames are the size of the whole image and at offset 0,0, and generates a totally bogus GIF whenever this isn't true.

There's two common optimization steps when preparing GIFs. The first uses blank transparency to cover any area not changed since the previous frame, and the second crops each frame to a rectangle enclosing the differences.

Because the second step is only cropping out empty transparency, the savings there is rather minor compared to the first step. If you want to work around phpBB's resizing bug, it's reasonable to leave out (or undo) that second step. I used a GIMP plugin to undo it for this test.

Here's the original image, but with that step undone. It's only 6% bigger than the original version and should preview correctly:

I think it has an additional "ghosting" problem from trying to use bilinear interpolation to resize instead of nearest neighbour, but we can only squeeze so much blood from this stone. It's a bad resizer and it should feel bad.

Thanks everyone for the GIF detective work. Been working on cleaning up Debs run animations today by reducing frames and adding more personality.

And what software do you think phpBB uses to manipulate images? *chuckles*

I have started a new thread for preview GIF corruption discussion, so we don't clutter dullahan's thread any further:
https://forums.nesdev.com/viewtopic.php?f=13&t=14868

I don't know or care. What I'm saying is that it's not something that anybody posting GIFs on this forum should have to care about -- it should be fixed on the phpBB side.

(Maybe I misread the intention of your post? I don't know.)

Trying out some basic enemy types...also noodling if I want to use overlay sprites.

Added more enemy types. No plans for these guys, but wanted to make a pool of villains from which I can draw later. Probably will ditch the shading color later.

Love the style. Looks stronger without the extra color for shading, though.

Thanks for the input M_Tee. I agree about the shading; although, I am still partial to the shells having a different color.

BTW really like the Isolation pics I've seen so far.

Thanks.

Have you thought about having the shells just use the color of another enemy? Instead of leaving those three pixels of shading/highlighting on the edge, the sprites could use two separate palettes. For example, teal for the body and orange or lavender for the shell. This will maintain consistency in (lack of) shading while increasing the color count.

Thanks.

That may be the route I have to go if I want to keep the color; although most feedback I have received is in favor of ditching the extra color so I will probably run with that.

Took a break from game mechanics and started experimenting with some background gfx. The clouds definitely need some tinkering. I want to animate those ultimately with palette swapping. Looking at the platforms now I of course realized that my collision engine doesn't currently support one way collisions through an object--doh! Will have to address that after I get Debs' physics working.

Did some work on Deb's dash today. Currently,

* Players can control the duration of dash at a gradient of 8 px as long as they are not colliding with anything.
* If a full dash can not be executed, a smaller dash (8 px) is attempted, and so on.
* Dashing does not reset the player's ability to jump (although I may change that later).
* The dash speed is 4 px a frame. At first I had it at 8 px, which feels pretty fun, but I the ability for more fine control is probably more important.

Up next I need to animate debs for the dash and also I think add a target sprite so the player has a better idea of where they are dashing to. Right now it feels weird to dash through objects.

Click the GIF preview to see the GIF animated correctly.

Still trying to get the dash animation right. Here are the first two attempts:

Second looks better. That's a very interesting use of colors for motion blur, as they follow the outline like that. It's unique and works.

The first looks like a Matrix glitch.

I think the tentacles may be your best shot at showing weight in your animations by having them "catch up" with the body. For example, if the character dashes forward, the tentacles could be pulled behind. If the character falls, the tentacles could be lifted up, etc.

I think the first version works better, if it's intended to make the character able to move through walls (which I would assume, since you do it in the GIF?). I think the fact that the ability does that, feels much more intuitive if it DOES look like he's glitching through the matrix - which I also think is a really unique effect for an NES game that I haven't seen anywhere before, I really like that.

That said, I agree that the colored lines that follow the outline do have a nice look to them.

Thanks for the input. I think you're both on either side of the heart of the issue which is the dash ability both removes enemies and allows a player to pass through walls.

For the enemy removal and "empty space" dashes a player should be able to see Deb's progress in order to determine when they wish to stop dashing. Deb's should also have weight and the dash should feel like it is impacting the world.

On the other hand for wall traversal the player loses their ability to stop the dash (while in the wall) so showing Deb's progress through space is less important. Deb's should appear more incorporeal since she is after all passing through solid matter.

I am debating about possibly having two separate animations one for each; although I'd rather save the sprites. Another option is to possibly remove the wall traversal part...which truthfully would make the movement logic easier since dashing would then become glorified sprinting and I would no longer need to perform all those extra collision checks to make sure the endpoint of the dash is clear.

Trying some more interesting run and jump animations. Also yet another dash Need to see how it looks in the actual game tho.

If you're keeping the wall traversal, I think it would be important to have one animation for gameplay reasons. You can't expect people to read your manual. If trying out the dash without wall traversal looks like the character is "shifting" through space, and you subsequently put a wall up to block the path ahead (preferably on the first stage), dashing through it is probably the first thing a player would intuitively try.

> dash2.gif

it's like the opposite of Mega Man zooming in from the top; neat! dunno if you can spare sprites/tiles for movement lines in the beam part, or if you have the tile/sprite budget for a pointed end (showing which way the player is moving).

The other animations look great!

Thanks for your input Sumez. For now I have commented out the wall traversal, might make it back in if the gameplay is too flat without it.

Thanks freem, I actually used the MM animation as a study source.

Update:

* Damping is working with horizontal movement.
* Changed balloons into crystals since it seemed right.

Next up:

* Integrate famitone and create sfx for crystal captures and crystal breaks.
* Implement logic for gathering crystals (like coins in SMB1).
* Implement logic for breaking crystals (happens when Debs dashes through them). Breaking crystals resets Debs dash ability thus allowing for multiples dashes while in the air.

You can see the new movement on my twitter page: https://twitter.com/cacciatc/status/806662957195067393

Now working on the first level. Here are a couple screenshots:



Animated GIFs can be found on my twitter: https://twitter.com/cacciatc/status/810313593967124480

Up next:

* Implement sprite0 HUD.
* Fix a mess of bugs discovered with the level change.
* Add crystal shatter animations.
* Add crystal collect animations?
* Implement death.
* Implement hurt animation and logic.

My goal for the end of December is to have two working levels, then another two in Jan for a total of 4 levels for the final NES 2016 submission.

It looks really good. I'm looking forward playing this.

Give it a try and let me know what you think.

It's simply gorgeous. The dashing turned out really smooth, and the title screen lettering is solid. I especially love the warm emphasis usage on the pause screen.

Really nice! Also Kulor's soundtrack is rad. (I really love the "ending" tune.)

I notice the bottom row of attributes seems to get corrupted frequently. I tried to jump down onto one of these. :S


Am I supposed to die if I jump up here? Or is this an unintentional wrap-around causing me to fall down the pit at the bottom?

Another very nice entry! I did run into a few problems while dashing, though...

Dashing in the air once sent me behind the clouds and the collision map no longer matched what was being displayed on the screen. I couldn't replicate this in the air, but dashing against this wall or against the edge of the screen a few times does eventually make me land on the opposite side of the screen, and the collision map is wrong.

Dashing against the wall:


Landed on the opposite side:


Standing on air:

Thanks M_Tee I am a fan of the pause screen too.


Aye, Kulor did a great job.


Interesting, I hadn't noticed that behavior. Thanks for the report. I will check it out.


Bummer, a regression it would appear I've fixed that bug a couple times now!

Thanks for the reports. Thought the wrap around bug had been fixed.

This is a very solid and enjoyable entry! Music is fitting and great, too.

Maybe it's just me not mastering the height of the jump yet , but i keep bumping into this platform repeatedly, everytime in the beginning of level two, and kind of wish it was something like the edit to the right in this pic. A very minor issue in a great platforming experience.




Something caused the screen to go gray in fceux (2.2.2) when paused on my first play, but i cannot replicate it.

Thanks for the input. Yeah, that beginning section can be annoying. Also will keep an eye out for the gray screen.

rainwarrior what emu were you running when you noticed the attr glitches on the bottom row? I haven't been able to reproduce on FCEUX 2.2.3; however, on my Powerpak I do get weirdness-- sometimes attributes are wrong, other times the background tiles, and other times sprites. I was under the impression that my Powerpak was being wonky though. Will need to investigate.

I was using FCEUX 2.2.3 (+ a few more recent additions, I build from source, but it's basically 2.2.3), though it might be important that I use New PPU mode.

I don't seem to see the attribute problems on the first stage, but they seem to occur frequently in the second stage. I also notice in the second stage "bumps" in the vertical scrolling now and then, almost like the scrolling is set too late, might be related to the same problem?

Problem seems to occur in Nintendulator too (the vertical shake + the attribute corruption, specifically in stage 2).

I've noticed another problem. This has happened to me a few times in the first stage, if I take the "lower" path and get the extra dash token, there's a high probability that I get killed by an invisible enemy in one particular spot.

Attached is a short FCEUX movie file demonstrating the problem, around about frame 1800 (~30 seconds) I seem to hit an invisible enemy in the air?

This is a picture of the spot just before it happens:

I can reproduce the attr artifacts and stuttering in Nintendulator and FCEUX 2.2.3 using the new PPU. But everything is gravy with the old PPU for me on 2.2.3. Well guess I will checkout the screen shake code and then after that the palette animation logic for waterfalls.....

Thanks for the detailed info. I was aware of this issue, but cannot reliably reproduce it. One prerequisite does appear to be that Debs needs three dash charges though so that's something.

I don't know if this is relevant, but under the right (now hopefully impossible to trigger) conditions the explosion-drawing code in Wrecking Balls will run past the end of vblank in FCEUX (2.2.2 with new PPU), but work fine in Nestopia and Mednafen.

I don't know which is accurate, since I don't have NTSC hardware to test on, but there's definitely a difference between emulators.

You can use the FCEUX movie to reproduce it and all the regular debugging features work with movies too.

Thanks for the info Rahsennor that may be a lead.

I haven't tried FCEUX movies with debugging that sounds great.

I discovered that the screen going gray when paused happens if i simply start fceux (again, 2.2.2). Selecting the old PPU fixes it for the duration of the session, and switching back doesn't retrig the problem. I'm half assuming the game is tickling a bug specific to that version of fceux?

I also found that you can glitch through the left walls (including the invisible barrier far left) by dashing against them, as long as you've scrolled at least one tick. Glitching (dashing repeatedly) all the way through and wrapping around the screen offsets the object position relative to the collision map.

Thanks for the info FrankenGraphics. Interesting about the gray screen bug.

Just updated the original post with a new build that includes the following bug fixes:

* Debs can no longer dash into and climb walls.
* Debs can no longer dash past the screen boundary and into the unknown.

I haven't been able to trigger the Debs mysteriously-dying-on-the-first-level bug recently which used to happen 1/4 attempts of level 1 roughly, so I am very interested in reports either way on that one.

Figured out the Debs dying suddenly bug and uploaded a new build in the original post. Now I just need to crack the nut that is the weird attr behavior and y scrolling jitters on levels 2 and 3!

Re: weird attr, scrolling jitters, and (for me on powerpak) tile corruption.
These sound like the usual symptoms of writing outside of VBlank.

Mild glitches appart (I didn't get anything nasty), this may be my favourite submission this year. I love the Capcom feeling all around. Congrats!

Yeah, I will be interested to finally get that fixed!



Thanks! I've enjoyed your entries as well!

I liked the game, but I hit the things others have also mentioned - the hero dying in midair with enemies nowhere in sight, walking into bricks, and slight jitter when moving.

You asked for more info about that, it happened on the point in the attached picture, in the first level. I jumped up and dashed to the platform, then boom, dead. Using the compo build.

Had a lot of fun with this - I beat it on actual hardware! (Save states? Who needs em?) I didn't run into any of the glitches other folks have mentioned, thankfully. It did feel a little short, but I guess the prequel, and Demo on the title screen shoulda clued me in to that.

Great entry.

Thanks calima. I think I have this issue fixed in the newest release.



Glad you enjoyed it! Thanks for playing.

Updated original post with a new build which should fix issues with level 2 and 3. As some of you guessed there was too much work being done during VBLANK. I unrolled the loop that copies over the tile buffer and that saves me ~500-600 cycles.

Thanks to everyone for playing. Excited about Nebs n' Debs performance in the 2016 competition. Look for more updates in this thread.

Great music.

Hit some weirdness using the competition version: on the segment where you have to dash under to get a Dcoin (Mines-1), often the dash would only last four tiles and I'd plummet to my doom, going in or out. Oddly doesn't replicate on Mednafen. (Was initially on PowerPak.)

Consider resetting any falling (but not rising) on dash to make things easier. I don't see the trick of making certain two-dash jumps.

There was an invisible enemy somewhere aside from where they showed it…lessee…no, I'm getting warp-into-void glitches and dying too much to find it again on Mednafen.

Consider letting Start skip the game over theme.

Thanks for the feedback Myask. Many of the dash/warp glitches you mention should be fixed in the most recent build posted at the beginning of this thread and on the Action 53 release. Thanks for playing!