nesdev.com

I don't want to weigh in too much on your design choices, but it looked like you had a wind mechanic that complements the player avatar changing directions? But if you want to change that up, it's for example a pretty common setup to make levels two screens wide or tall, and "threadmill" the other direction wich is only 1 screen long. There's also the possibility to wrap let the "camera" wrap around the two-screen-wide field.

Oh, and since you probably have more than enough of prg-rom and chr-rom even with the simple CNROM and even more so with any mapper more generous than that, there's plenty of room to do something different and/or potentially larger than your first game, if you ever want to.


Huh... i've never seen those titles before. and they're cheap. Wait, did you remove the picture? I didn't catch their names


Not hard, but a bit more limited and a bit more to think about than a proper irq. Sprite0 needs to have a solid pixel touching a solid pixel on the background. That makes it much easier to place the HUD/bar on the top because it will always remain still so you know where to score a sprite hit. Placing it at the bottom is trickier because you're not automatically guaranteed to get a sprite hit as the map moves around. Oh, and you must keep your status bar "out of sight" from the map scroll, naturally, but that goes for an irq split too. The last point is another thing that's in the favor of GTROM, since it can flick between 2 sets of 4 nametables, you can keep your status bar and other stuff in one set and the map/ in the other.

It's a very friendly forum, but i think your illustrative example helped a lot.

_________________
http://www.frankengraphics.com - personal NES blog

Nah, it was hard coded in the original. It was a game jam game, so I never got far enough to make the wind into a mechanic.



Yeah... Posting that picture made me curious again and I started Googling the names. I think they might be pirate Japanese carts or something... I got weirded out and pulled the photo. I guess it's not my fault though... I made a another thread about that. viewtopic.php?f=5&t=16755

Right, it's in the same direction all the time, but that's just aswell. What i mean is that (now that i played through it, i can say it with some confidence) that you've managed to put a lot of variation in terms of challenge and experience into one smallish map simply by the way the sail maneuvering + wind + direction works together, which comes easier when the boat can roam freely in all directions. I just wanted to comment on how good that felt. I found this combo of features better/more interesting than beforementioned "Solar Jetman" for the nes, which is a personal favourite.

_________________
http://www.frankengraphics.com - personal NES blog

Man, you're the first one here wondering if things are going to be hard. Most nesdev people are only interested to do things IF they are "hard".

I also think this is very sensible.

A 24x24 boat and a 16x16 sail maybe? That's only 13 tiles per angle. You could fit all this in ~1k of CHR, there's really no need for CHR-RAM or banking?

Yeah it's easier with a smaller boat. I was under the impression it would be rather big because of the pico 8 proportions (like 4 tiles wide when facing east/west, so more or less a grid of 4x4 tiles, 3x3 for sails) but a smaller boat would additionally help towards the sprite limit per scanline if the foam trail is to be ported and be sprite based to some extent.

Larger objects do not only require more tiles per rotation cel, they also require more cels to look smooth rotating at the points farthest away from the centre. On the upside, they can be much more minute and precise in their rotation steps, which could perhaps be to the benefit of a game like this.

There's the sail meter to add in, too. but that can maybe be solved more efficiently as far as the game is concerned in the HUD.

There's also the possibility to prerender all sail positions and boat rotations onto the same sprite, rather than having independenly moving layers - this would require a lot more space, but it's pretty straightforward to do in photoshop with a minimalist boat design like in the original. The benefit is freeing up a lot of the scanline bandwidth + the marginal benefit of fewer sprites for the cpu to juggle around every frame.

CHR ram could just maybe help with constructing the foam trail on the bg layer with some primitive drawing in software. It would probably be a pain to get it to look right, but it could be a complement or an alternative to sprites.

Then again water foam wouldn't be the worst thing to let flicker if it's all sprite based and there's not enough room on the scanline.

_________________
http://www.frankengraphics.com - personal NES blog

Started prototyping my boat sprites. Pre-computed sprites with flipping and palette swapping is going to be overly satisfactory I think:

(The red/green channels are going to be mapped to the two bitplanes.)

64 rotations in only 32 character table slots. Leaves plenty for the sail animation and other effect sprites.

I started modifying the original Pico8 game to generate them, but was unsatisfied with the precision artifacts in my rasterizer. So instead I quick rewrote it as a shadertoy. Lol. Feels a little absurd, but whatever.
https://www.shadertoy.com/view/MllfW4