FROM BELOW [NES Homebrew] COMPLETE!

[calima]

That blinking and moving thing at the bottom is a bit too distracting. May want to tone it down (in both graphical and blinking terms).

[Goose2k]

That blinking and moving thing at the bottom is a bit too distracting. May want to tone it down (in both graphical and blinking terms).

Thanks for the feedback. That flashing block was just placeholder, and has been replaced in the next version.

[Goose2k]

Update Week 4!

From Below is really close to being finished now! Hopefully just another week or so.

Here's a short video walking through the whole game.

The Kraken is now in the game, and his tentacles slowly climb up the play area, pushing up blocks as he goes! I want to iterate on this further, but I would love to get some feedback on what you think, and how it could be made more interesting. Does it put an interesting spin on the classic Tetris formula?

I've also added a bunch of other stuff:

• Animated pieces in the world.
• "Hard Drop" by pressing UP on the dpad.
• Options menu to disable Kraken mechanic, and turn off music.
• Press Start now flashes to make it more obvious.

[Atlantis896920]

Thanks for sharing the work. It improved a lot. Im beginning to learn and your project is of big help. Could have some differences between day and night in the gameplay. And the difficult level raised in the last build.

[DRW]

Just a little side-topic comment:

Digital-Painting-Derk-Venneman-Kraken.jpg
(concept art: Derk Venneman)

If I saw this on an NES box and then turned the box to see what the game is about or if I googled the game, and then I found out that it's a "Tetris"-like puzzle game, I would be pissed or do a facepalm.

This cover artwork is so misleading. It literally has nothing to do with the gameplay, even if you include garbage blocks to represent the kraken's tentacles.
It looks like an action game. And even if I knew it's a puzzle game, I would still expect it to be some game where you have to place people on tiles or whatever and there appears a kraken now and then who removes all the people from the screen that are placed in certain locations or something like that.

I applaud the guy who made "Retroid" for the Game Boy because he created an honest box:
https://www.vintageisthenewold.com/wp-c ... 00x334.jpg

But the box of the NES homebrew "UXO - Unexplored Ordnance" was more than once the target of some inside jokes between me and my friends. It looks like the game would be similar to "Commando" or whatever:
https://i.ytimg.com/vi/AdCww68elRE/maxresdefault.jpg
And guess what: It's "Minesweeper".


If it's really your desire to create a "Tetris" clone, go for it, but why bother with a plot that has nothing to do with it?

But if you actually want a game with an evil Kraken who attacks a village, why don't you do your real dream game instead of wasting your time with the bazillionth "Tetris" variant?

[rox_midge]

I feel like there needs to be more of a twist. Does the Kraken start using more than one limb at higher levels? Or pushing blocks more frequently? Or removing blocks instead of just pushing them?

Maybe there can be a different game mode in which you need to damage the Kraken a certain number of times to advance to the next level, instead of completing a certain number of lines. And when advancing to the next level, the Kraken goes underwater, and the screen scrolls horizontally to the next tower, which has a different palette, a different width, and maybe a different collection of block shapes; since these specific shapes happen to be unusable in a published game. The Kraken gets more and more upset at each tower, until the last tower, which has some sort of final twist, like the Kraken will start removing blocks instead of just pushing them upward.

Defeating the Kraken at the final tower results in a victory screen, where the screen scrolls upward to reveal a taller tower than the one on the title screen (maybe three screens high), and shows the townspeople celebrating that their towers are safe.

Either way, it's really come a long way in a few short weeks. Super impressive!

[Goose2k]

Thanks for all the thoughtful feedback!

Just a little side-topic comment:

This cover artwork is so misleading. It literally has nothing to do with the gameplay, even if you include garbage blocks to represent the kraken's tentacles.
It looks like an action game. And even if I knew it's a puzzle game, I would still expect it to be some game where you have to place people on tiles or whatever and there appears a kraken now and then who removes all the people from the screen that are placed in certain locations or something like that.
...

Oh man, I appreciate the passion but that isn't cover art of the game. It's just a picture of a Kraken I put up for inspiration (prior to having real art in the game). Although I have to say, I have a bit of nostalgia for that sense of disappointment you described. That was a huge part of my childhood, especially on the Atari!

But if you actually want a game with an evil Kraken who attacks a village, why don't you do your real dream game instead of wasting your time with the bazillionth "Tetris" variant?

I started NES Dev 4 weeks ago... chill out . It's just a project to learn how to code for the system without having to design an entire game as well. Hopefully my next project with be something a little more original (although I am thinking of just porting my game Witch n Wiz).

By the way, I tried to check out your game in your signature, but the link is broken, FYI.

Thanks for sharing the work. It improved a lot. Im beginning to learn and your project is of big help. Could have some differences between day and night in the gameplay. And the difficult level raised in the last build.

That's really cool to hear! I would love to see what you are working on!

I feel like there needs to be more of a twist. Does the Kraken start using more than one limb at higher levels? Or pushing blocks more frequently? Or removing blocks instead of just pushing them?

Maybe there can be a different game mode in which you need to damage the Kraken a certain number of times to advance to the next level, instead of completing a certain number of lines. And when advancing to the next level, the Kraken goes underwater, and the screen scrolls horizontally to the next tower, which has a different palette, a different width, and maybe a different collection of block shapes; since these specific shapes happen to be unusable in a published game. The Kraken gets more and more upset at each tower, until the last tower, which has some sort of final twist, like the Kraken will start removing blocks instead of just pushing them upward.

Defeating the Kraken at the final tower results in a victory screen, where the screen scrolls upward to reveal a taller tower than the one on the title screen (maybe three screens high), and shows the townspeople celebrating that their towers are safe.

Either way, it's really come a long way in a few short weeks. Super impressive!

Currently the gameplay does not advance any beyond just speeding up. I would like to add more tentacles, but they are currently being done as sprites and I can't afford to update any more (start dropping frame at around 15-20). I originally had them in the nametable, but we couldn't figure out a way to get the 2x2 attribute palettes to play nice.

I think your other ideas are great! However, this is just my first NES project, and more of just a learning experience, so I don't want to invest so much time into it. I am hoping to find more simple, minor tweaks which add to the formula, rather than completely revolutionizing it.

I do plan to try some original shapes in order to see if I can get the game on the next Action 53.

[rox_midge]

I started NES Dev 4 weeks ago...

What the WHAT?! You went from zero NES development experience to a fully complete game in FOUR WEEKS?!

I've been fighting with getting my attribute table to update properly for the last month and a half (it's still not working, FYI) and I'm not even to the point where I'm ready to start displaying sprites yet. Much less music, SFX, title screens, and gameplay. Granted, I don't subscribe to the "start small" philosophy, but still...!

Please tell me that you've done something tangentially related before, like writing software for Apple II / Commodore 64 / SNES, or that your parents taught you assembly language before they taught you English, or something.

Currently the gameplay does not advance any beyond just speeding up. I would like to add more tentacles, but they are currently being done as sprites and I can't afford to update any more (start dropping frame at around 15-20). I originally had them in the nametable, but we couldn't figure out a way to get the 2x2 attribute palettes to play nice.

I'm glad I'm not the only one who loathes the attribute table.

What makes the updates take so long? It feels like it should be pretty straightforward to iterate through the tentacle tiles to update them for the purposes of animation. It doesn't seem like there would be much at all in the way of time constraints here, except just after a piece lands.

[Goose2k]

I started NES Dev 4 weeks ago...

What the WHAT?! You went from zero NES development experience to a fully complete game in FOUR WEEKS?!

Actually I guess I've been looking into this for over a year really . I just started actually coding 4 weeks ago. I've been going through the nesdoug NES in C tutorials for a while, and I read this book a while back. So I've been learning lots for some time now.

Please tell me that you've done something tangentially related before, like writing software for Apple II / Commodore 64 / SNES, or that your parents taught you assembly language before they taught you English, or something.

I've never done any retro console dev (closest thing is Pico8), but I am a professional game developer, so I'm pretty familiar with how to make games, which has helped.

And as I said, I'm not learning ASM at all; I've done everything in C. It's been a huge leg up to get things off the ground quickly, but I do wonder if it will bite me in the butt down the road. I figured though, learning the NES hardware is hard enough; I don't need to learn a new programming language at the same time!

I'd recommend it if you are familiar with C-like languages.

What makes the updates take so long? It feels like it should be pretty straightforward to iterate through the tentacle tiles to update them for the purposes of animation. It doesn't seem like there would be much at all in the way of time constraints here, except just after a piece lands.

I'm not totally sure. Could just be that I am starting to hit some of the problems with C programming in the NES. Probably doing a bunch of stupid stuff. Trouble is, at this point I don't even know how to profile things on the NES. Probably something I will look into soon.

[calima]

Writing in C does give you a headstart. It only took me a few weeks, when completely new to NES, to make a plants vs zombies style game.

To profile on NES, use the color highlight or grayscale bits. Set it before and clear it after the code, and you will see on screen how many (rounded) lines it takes (one line is ~113 cpu cycles).

[DRW]

By the way, I tried to check out your game in your signature, but the link is broken, FYI.

Thanks for the information. This can only mean that the game is sold out now. I'll ask the publisher.
However, if you take the last link, you'll get to the website where you can download the ROM, the manual and the box artwork. I made the game freeware a few months ago. The first link was just the sales website for the cartridge anyway.
If you want to see the complete in box package, John Hanckock made a video about it.

[DRW]

And as I said, I'm not learning ASM at all; I've done everything in C. It's been a huge leg up to get things off the ground quickly, but I do wonder if it will bite me in the butt down the road.

I would recommend Assembly for some general-purpose stuff like graphic updates etc., but all in all, C is fine, especially for a small game like this.

But you might want to keep some things in mind:

Don't use local variables or function parameters. Globals variables and static local variables are faster.
(You can simulate parameterized function calls with macros.)

Whenever you use a pointer, cc65 creates horrible code. Array access is fine, but array access through a pointer is crappy. For my new game, I wrote some C macros that have inline Assembly for pointer access.

Shiru has some more hints:
https://shiru.untergrund.net/articles/p ... s_in_c.htm

Trouble is, at this point I don't even know how to profile things on the NES. Probably something I will look into soon.

The NES has a mechanism where you can put a color layer over the complete screen:
https://wiki.nesdev.com/w/index.php/PPU ... rs#PPUMASK --> Emphasize red, green, blue.
You can set those values mid-frame. This way, only a certain portion of the screen will have this layer. (Have a look at "Noah's Ark" on the NES. They did this for the transparent water effect.)

You can do this to measure the duration of your code:
The game logic is processed while the TV updates the picture. So, if you put a red color emphasis at an arbitrary point in your code and reset it at the end of the code, then you will see a red bar on the screen that overlays the actual picture. The fatter the bar, the longer your code takes.

[Memblers]

Since you mentioned Steven Hugg's book, if you're using the 8bitworkshop IDE, note that color emphasis benchmarking won't work in that IDE's emulator. That emulator seems to apply the effect to the entire screen, and doesn't render the mid-frame changes.

[Bananmos]

And as I said, I'm not learning ASM at all; I've done everything in C. It's been a huge leg up to get things off the ground quickly, but I do wonder if it will bite me in the butt down the road. I figured though, learning the NES hardware is hard enough; I don't need to learn a new programming language at the same time!

I've always been a bit sceptical of how enjoyable C-on-6502 really can be, but with KickC support for NES being announced I am quite curious for real-life examples on how it performs compared to cc65 in practice.

Would you care to take KickC for a test drive and see if it works for compiling your game, and if it improves things like performance / code size in practice?

[Goose2k]

The NES has a mechanism where you can put a color layer over the complete screen:
https://wiki.nesdev.com/w/index.php/PPU ... rs#PPUMASK --> Emphasize red, green, blue.
You can set those values mid-frame. This way, only a certain portion of the screen will have this layer.

Since you mentioned Steven Hugg's book, if you're using the 8bitworkshop IDE, note that color emphasis benchmarking won't work in that IDE's emulator. That emulator seems to apply the effect to the entire screen, and doesn't render the mid-frame changes.

Do you know if it works as intended with neslib (c library)?

For me it appears to just tint the whole screen (tested on both Messen and FCEUX).

The code I use for this is:

Code: Select all

ppu_mask(0x3E); // 0011 1110 - Red emphasis, with all rendering enabled

I even put in a big loop to bring the game to a crawl, and I still see the whole screen tinted red.

Code: Select all

for(i=0; i < 9999; ++i) { }
ppu_mask(0x3E);

My guess is the library queues up the mask calls for the end of the frame or something.