Opinions on my NES style game

Hey. Been working away on a wee platformer thing using Construct 2. I have no coding skills whatsoever, I just enjoy messing with the oul' pixels. I love the look of NES games. Love all the blacks n' the chunky low resolution. I wanted to emulate that, but not stick 100% within the NES's limits. Was wondering what a group of NES experts thought of how my game's coming along so far. Any crits, comments or suggestions would be greatly appreciated.

Looks nice, and quite NES-like. I don't really have anything else to say about it, really.

Please use the forums image attachment feature to post images, so that they won't disappear together with your Dropbox account. (Is there any way that we could make it more obvious for users that they should use the image attachment feature rather than the [img] tag?)

Looks really cool! I don't see anything that immediately sticks out as not being possible on the NES, except for the lack of flicker from using such large sprites. Well, that and the debug HUD! =)

Its cool that you manged to make these detailed and expressive sprites without having to completely break the color limitation, like most pseudo-retro games do.


From what I can see, you're way closer to the NES than many other similar projects I've seen recently.

Keep us updated!

Thanks much for the replies. I sure will keep you updated!

The temptation to break the 4 colour sprite limit was so strong, but I managed to stick to it. His sword is an extra colour, but that's a separate sprite that I'll swap out for different weapons.

So I can actually just upload images to the site, eh? That's handy. I'll swap the image over then.

Things that caught my attention, but these are all moot if you don't plan on "truly" sticking to the NES's limitations:

1. Large sprites (already discussed) -- may induce flicker
2. Torches -- probably would have to be sprites, which could induce further flicker
3. Background graphics -- very hard to tell, but some areas of the map look like they'd violate attribute table + nametable limitations.

Overall it looks more like an amalgamation of NES + SNES capabilities, which is perfectly fine. Shovel Knight, for example, falls under this category too. Nothing wrong with that in the least.

Looks great! Any chance this was inspired by TKGS? The "rising lava floor of doom" always makes me think of TKGS.

Absolutely fantastic! The enormous, featureless eyes add a really unique look to your character designs. Your animations are quite smooth, but also have a little jerkiness to them to keep them from feeling too far from an NES game. Your dithering on the background details adds a really textured look, and your color choices are pretty great.

If I could offer up one piece of criticism, you might want to add a little more form to your arms and legs. Right now, I can't really tell where the limbs end and the hands/feet begin. Reworking the highlights and adding some highlights to the hair might help too.

I quite like the hands in your edit. Thanks. I'll give him a wee update. I'm still unsure about the backgrounds n' tiles. I think they might have too much detail in them. I'll see what solid colours to for me. Might look a bit rushed though. Hmm...



Aye, I'm sure I've gone way overboard with the tileset. I'm tinkering with adding in some parallax now. Which is breaking another NES limit I think, but it'll look so nice.
Hmm... never heard of TKGS before. Don't think I've ever even SEEN an Amiga before! It was just Nintendo n' SEGA for me growing up.

To me it looks more like Hill Top's rising lava section, but I guess this is common enough in old games.


Nice changes! I particularly like the hair.


Which isn't necessarily breaking an NES rule... there's always the MMC5, which allows access to 16384 tiles at a time, and 8x8-pixel attribute areas.


This is usually the ultimate evidence that games aren't actually NES programs. Not that parallax is impossible on the NES (look at Sword Master, Metal Storm, Battletoads, Batman - Return of the Joker... the list goes on!), but there are very strict rules regarding what can or can't be done with an actual NES.

Single-direction parallax is mostly fine, just not full free two-dimensional scrolling¹.
As long as you can fit your entire set of parallax-ing tiles into just 64 tiles, and don't have more than ≈64 different scroll configurations that you want, that's a reasonable affordance for a NES game².

¹There's an old demonstration of full free two-dimensional scrolling I remember seeing on the forum, but only on 8x8 tiles. I can't find it right now...
²There's an incomplete homebrew game that supported full free two-dimensional scrolling... but it worked by having horizontal stripes of background vs foreground. Still looks nice.

There's also the fact that the foreground can't contain slopes or other complex shapes, or the places where background and foreground meet can look weird. The Battletoads example actually has a pretty complex foreground, but they compensate by making the background less detailed. The edges still look a little weird though. Battletoads also uses free two-dimensional scrolling, but the background pattern is small enough for it not to be a problem. And the game uses CHR-RAM, so it doesn't have to store all possible rotations of the background, they can be calculated in real time.

To be fair, many NES games avoided slopes altogether (because of the physics in general), but even then you can probably cheat by ensuring slopes are always in front of some foreground (effectively making them opaque like non-slope tiles).

True, the important thing is to not have irregular shapes separating the parallax background and the foreground.

Is it this one?

No, it wasn't that one, although that one's very nice.

The one I was thinking of was a library of 64 banks of tiles where each bank contained one of the 64 different possible scroll offsets within a tile, so that e.g. going forward/backward one bank would cause the tile to rotate horizontally and going forward/backward eight banks would cause the title to rotate vertically.

This is looking very nice glad you ditched the black outlines.



SMB3 was choc-full of slopes, Kirby too. Admittedly there was no paralax...



Didn't the MMC3 do away with such small tile limits?

Giving a couple of examples doesn't really disprove the original statement. Sure, some platforming games on NES had slopes, but majority of them didn't.

To be fair those were two of the best selling games on the platform. Programming is hard in general, but you shouldn't limit capabilities by effort or majority. Slopes were 100% possible.

The problem is that the larger the pattern that scrolls, the more banks you need to represent all possible rotations. If you're scrolling a pattern of 8x8 tiles (64x64 pixels, 64 tiles), you need 64 versions of those tiles if you want to animate them exclusively through bankswitching (which is the only possible way if the tiles cover a large area of the screen). This means that this pattern alone will consume 64KB of the CHR-ROM, 1/4 of what the MMC3 can handle. This means the MMC3 certainly didnt do away with such small tile limits when it comes to parallax scrolling, which needs multiple versions of the same patterns.

I may as well point out this then =P

Everybody says that game just uses line scrolling and bank switching over multiple backgrounds. The name table is what is being bank switched, right? There is no way the game has that many pattern sets.

Yeah it must be bank switching hell, but point stands that it looks like something the NES shouldn't be able to do at all, yet we don't go around treating that like the minimum bar for a NES game.

IIRC, the name tables don't change... The background is always made of lines extending from the horizon to the bottom of the screen, and different CHR banks make the lines assume different colors, creating multiple one-dimensional patterns (because each line is the same color all the way). By switching banks multiple times in a frame it creates two-dimensional patterns. To animate these patterns it just changes the scanlines where the switches happen over time.

EDIT: Yup, just as I remembered. If you look at the 2 name tables in an hex editor you can clearly see the lines extending from the horizon towards the bottom of the screen. It's all solid areas and diagonal lines separating them.

Come on, Cosmic Epsilon is a much more extreme case than slopes. The 3D effect is achieved with a fairly complex trick, while slopes aren't any harder to implement on the NES than on the MD/Genesis, for example. The only reason why the NES has less games with slopes is because the NES is older, and older games often didn't have slopes. A lot of early MD/Genesis games didn't have slopes either (Alex Kidd is a notable example), but it wasn't because of a hardware limitation, it was just because slopes weren't very common yet, in any platform.

As slopes started to become the norm, they were extensively used on the NES during its later years. There are many, many more games than just the 2 hawken mentioned.

The MD's flagship game had so many slopes it's hard to find a flat surface

Can we just say slopes were used extensively on NES but are hard to combine with parallax bank switching?

Maybe "you shouldn't", but in practice you are limited by the amount of effort required by a feature (and the skills of the programmer, and the limitations of the hardware) when you have to finish a project in time.

Anyway, that was not really the point I was originally trying to make. I was just pointing out the flawed reasoning in "many NES games avoided slopes" => "not true, because games X and Y have slopes". Now, we can of course argue until the end of world about whether the reason for the lack of slopes in games was technical (like Sik said) or cultural (like tokumaru said). Probably it was bit of both.

Slopes are perfectly fine for NES-style games.

If you choose a single fixed angle for slopes then it's a bit easier to cheat that into a platform engine than to actually support arbitrary slopes and perform trigonometry.

Slopes are a design choice, not really about feasibility at all (any competent developer should be able to implement them). They're good for certain kinds of flow and movement, and obviously it affects level design.

It's kinda weird that there is a page of discussion here about slopes when the OP never even suggested them.

In the NES game Strider Capcom probably should've folded and left the slopes out of it, they're so broken. Although that is in line with the brokenness of other Capcom titles from the same era, like Trojan and Commando.


Welcome to NesDev. But yeah, this discussion should probably be split (not that it was very interesting to start with...)

I think the common thread connecting the two was supposed to be "slopes would interfere with use of tile animations to perform parallax scrolling". Could you suggest a good split point?

I'm not really a fan of thread splits, I just thought it was funny how much we're talking about slopes in here.

Battletoads has slopes and parallax in Level 4. The bg/fg clash is noticeable, but not too much of an issue (i.e. I've never heard anybody complain about it).

That is pretty good, however I wonder why the elevator has a black outline, when it's a "sprite"?

And little demos like these are often disheartening because no NES game could ever look that slick, not then due to technological constraints (cartridge memory, infantile memory switching hardware), and certainly not now because, well, assembly is admittedly a pain in the ass. It might have a few taboos such as flicker (to be fair, Konami gave the scanline limit the middle finger for their post 1990 games), but everything else looks reasonable. In short, games like these are basically what the NES could've been like, but will never be.

Its palette has enough room to accomodate for it? In fact the large orange stalactites are using the same palette (for some reason they seem to be sprites as well even though they never move).

Are you talking about Battletoads? or the parallax demo?

Because it be.

Probably the game in the first post, which I think is doable on the NES, at least in its current state.

@Sik: I was referring to how the lift appears to be a "solid brick" when it's graphic doesn't look like it. Perhaps he was trying to emulate the limitations of moving BG tiles, but since it's moving, it should be classified as a sprite. It's hard to see the "solid brick", but believe me when I say it's there.

@Tokumaru, Hawken: Yes, I am indeed talking about the OP's little animation and demo. I hope the OP will stick to the limits while still delivering a charming slick game, maybe even share the source code.

While I have no idea what the precise reasoning is (very likely technological ones), I can't help but feel that the NES was born at the wrong time. It was designed at a time when archaic arcade design philosophies were the norm, and thus many original games feel like arcade games. By the time developers started giving their games more substance, the NES was already old news, and even major developers like Nintendo themselves stopped caring about their NES output. In short, the NES doesn't have anything nearly as deep or long as Link's Awakening, despite it being developed for technically even weaker hardware than the NES.

Can't you recycle ASM code from earlier projects? I'm pretty sure somebody already has a code for all of these things.

bg map scrolling = common
object handling = common
gravity = common
collision = common

Wait, I thought you were talking about the Battletoads video (welp).


The problem would be more that the Super Famicom took too long (which would eventually hurt Nintendo in the long term once the generation after that came in).