nesdev.org

A trailer was uploaded on 7/9. Here it is: http://www.youtube.com/watch?v=zaK-RjiZedA

The following message was written on June 24th.

By next weekend, I'm going to pass the files off. Expect 3-4 weeks after that point to see the game out there. I'm still in talks about the LE version, but it's finally going to be done.

For the release, there will likely be two options.
#1 - Cart + manual for approx. $35
#2 - CIB + an art booklet that showcases unused/altered ideas for about $7 more.

Expected to post a trailer sometime soon.

===OLD MATERIAL BELOW===

Well, I figured I'd throw this out there. I've decided to go at it again.

http://www.youtube.com/watch?v=bBz4AX1tmsM - Here's an engine demo video that I put together on 8/6/10
http://www.youtube.com/watch?v=dlfqN92v7Xo - Video from 8/29/10 showing off the first area and boss.
http://www.youtube.com/watch?v=HNrsYjvLp88 - Video #2 from 10/17/10 showing off 3 other sectors
http://www.youtube.com/watch?v=tl9CsEpZ9Xw - Video #3 from 4/9/11 showing new features and another area
http://www.youtube.com/watch?v=CBxmswDIiLk - Video #4 from 7/14/11 showing the intro stage and preliminary cutscenes.
http://www.youtube.com/watch?v=-AaC7-SjOb8 - Video #5 from 11/18/11 showing a status, manual, and label preview
http://www.youtube.com/watch?v=PUb_P102SZ0 - Video #6 from 4/21/12 showing revised intro stage and scenes

This time around, I'll have some new skills, and more types of blocks such as ice and conveyors and such.

Thus far, I've got a basic room format loading. The nice part about doing this a second time is I'm accounting for bank switching and compression from the getgo. Whee!

***Just a note, there used to be screenshots here. I purged them as most of them are broken links and were just preliminary stuff anyway.***

Ice is really easy to do if your motion is based on acceleration (like Mario or MC Kids) instead of instant on/off velocity (like Teenage Mutant Ninja Turtles 2). Since there's normal deceleration when the player is on the ground, just decelerate more slowly if it's ice. I guess the Mega Man games sort of had ice, didn't they...

But acceleration-based motion is not how Battle Kid controls. Designing good ice mechanics for the kind of motion seen in Battle Kid seems tricky, especially since it's going to be used for lethal platforming puzzles.

Ice has both slow-to-accelerate, and slow-to-decelerate going for it, or slipperiness, or anything else you can think of.

Too late since you got the room compression done, but maybe make the screen bigger and use the select button to see your X/Y and special item(s).....Just a thought. BK3 maybe?

Like always, something to get us hyped up for. Especially the title screens, which look anti-aliased.

That is anti-aliasing. No way a NES could display that. A GBC maybe, but not a NES.

So what kind of compression are we using here? Some kind of RLE? Free-form resizable shapes like SMB, Zelda 2, or Metroid?

Dwedit wrote:So what kind of compression are we using here? Some kind of RLE? Free-form resizable shapes like SMB, Zelda 2, or Metroid?

It's a mix of RLE or LZ. In reality, RLE is the more likely one to get used. Basically, if you have tile $01 and want to repeat it 10 times, you'd go: $01,$FA...

Dwedit wrote:That is anti-aliasing. No way a NES could display that. A GBC maybe, but not a NES.

I'd do it with three colors in each palette: outline, text, and half outline half text.


If it's a mix of RLE and LZ, then it's LZ. RLE is the special case of LZ77/LZSS with distance one. I'll assume you mean "LZ77 where matches at distance one have a shorter encoding or longer maximum match length".

You thought about doing some scrolling in this one? Single screen seemed to work well enough before, nothing wrong with that, but scrolling would give it that final bit of "NES authenticity".

Memblers wrote:You thought about doing some scrolling in this one? Single screen seemed to work well enough before, nothing wrong with that, but scrolling would give it that final bit of "NES authenticity".

Negative. BK, past and future will always be the same formula. I do, however, have some thoughts on another scrolling type game for a followup. But we'll worry about that when the time comes.

If possible, I would suggest to change the way screen transitions are done unless there is a technical limitation behind it.

The "black flashing" transition seems harsh on the eyes. If you cannot keep the screen content, at the least if you could keep the status bar while the rest is updated would be already better. But this is my opinion only. Maybe other people don't mind as much as me.

Banshaku wrote:The "black flashing" transition seems harsh on the eyes. If you cannot keep the screen content, at the least if you could keep the status bar while the rest is updated would be already better. But this is my opinion only. Maybe other people don't mind as much as me.

It should be about 2 frames faster this time around. I really believe I've optimized it now. BK1's just was too big a mess to re-write.

The only real issue I had with the lack of scrolling in BK1 was the vertical parts. Either jumping multiple times to get onto the next screen, or jumping too high and landing on a re-spawned enemy.
But I suppose there aren't really too many ways around this. For this most part, I like that there is no scrolling. Especially in the puzzle-like levels.

Banshaku wrote:The "black flashing" transition seems harsh on the eyes.

I second that. With some time between transitions (like the time it takes to walk through a whole screen) they weren't bad, but when I jumped to a new screen at the top just to fall back to the bottom one, the flashing almost gave me headaches.

Sivak wrote:It should be about 2 frames faster this time around.

Faster isn't necessarily better. In fact it might be worse...

Since you have no scrolling, couldn't you try to render the new screen to the hidden name table, keep the old screen visible while that happens, and only switch to the new name table when it's ready? With unrolled loops it should be possible to draw a full name table in 4 VBlanks (that's pretty quick if you ask me), if you buffer the data in RAM beforehand instead of decompressing the maps directly to VRAM.

You are probably gonna say no, but I had to suggest it because that's something that bothered me a lot in the first game.

Astonish wrote:Either jumping multiple times to get onto the next screen, or jumping too high and landing on a re-spawned enemy.

Exactly. The flashing was pretty annoying, but having enemies you killed a second ago being brought back to life was too.

I see industria font

tokumaru wrote:Since you have no scrolling, couldn't you try to render the new screen to the hidden name table, keep the old screen visible while that happens, and only switch to the new name table when it's ready?

The thing with this is the new screen could conceivably be in ANY direction, left, right, up, or down. It'd be impossible to tell what way for sure the player is going to go.