NES Styled Pixel Art

A friend and I are working on NES style content in our spare time (though we don't have the talent to make it an actual NES rom) in the vein of Shovel Knight, but more faithful to the hardware. I figured the least best we could do is try to get feedback on the artwork and sprites we have made;




These are some of the level tiles we have been working on so far. I figured NESdev would be the best place to go for critique to NES accuracy. Using a good looking color palette has also been an issue, but currently we use a palette someone posted here:



This was a quick comparison I did of the palette my friend was using:


We're both still reading and trying to understand how NES hardware works, so any tips and suggestions would be useful.

Your artwork looks really nice, and it seems to fit into an average NROM / UNROM limitation.

This looks pretty accurate, though I'd say that the caterpillar might pose an issue. It looks like it has four segmets, each of which being a 16*16 block. The Player character is also 16 pixels wide. The NES can display up to 8 sprites in a row without flicker, and sprite in this case means a graphical object that's either 8*8 or 8*16 in size. What you might think of as a sprite, in this case the entire character, is referred to as a meta sprite, which is a group of sprites. If the player and the caterpillar were on the same level, there would be flicker, but seeing that they're on different levels, there's little chance for flicker to be truly noticeable.

Also, it's been widely regarded as a good idea to design and flesh out your game in a higher level language while adhering to the NES limitations, and then converting your completed game for use on the NES. Whether you will port it or someone else is entirely on the wall.

Hmm, I see 5 colours in your status bar: Black, white, red, blue, grey.

Would you be doing one of these with sprites?

As a tip, I'm not sure if you're doing this, but it may be a good idea to avoid the D column greys, as there's a few problems that come up when using them. 0D generates a too-black colour that is out of spec and will cause some televisions to lose the picture. Using column D colours requires special treatment during fadeout to avoid 0D. On some emulators 3D/2D might have the same colour as 10/00, and 1D might be black, so you may want to avoid using column 0 and column D colours side by side, if you're not avoiding them altogether.

Woah! This tile-work is gorgeous, guy!

Very reminiscent of Castlevania! Though, the level layouts, and presence of multiple characters, seem to suggest a Mario 2 style progression?

Aside from the mentioned hud colour issues, the only problem I could potentially see with this, is that the rope tiles seem to use the same colours as the wall high-lights, with an extra grey colour. Causing an entire palette to be used for practically the same colours.

Perhaps you could find a way to merge the rope index, and the wall index and save those colours for something else? (Assuming you would want to stick to the 4-BG palette per area limit.)

Nit-picks aside, great work so far!

It's probably not a coincidence that there are 4 hearts and 4 spheres... although only one of those groups has to be made out of sprites, so he could even have more hearts if he wanted to.


I can't speak for everyone, but my fade routines are always table-driven, in one way or another, because the straightforward "increment or decrement the high nibble" technique looks extremely choppy. It can look good if your fade animations are really quick, but if for some reason you need them to take a little longer, you should look into less obvious techniques.


You know, I always dislike when people make this suggestion after someone posts good looking art. I agree that repeating 3/4 of a palette is a huge waste of colors, but the solution you propose would make the game look flatter, and not as great as originally drawn. I propose the exact opposite: keep using separate palettes for the different objects, but have them differ by more than 1 color (even if they're just slightly different and not completely different hues), so that you have MORE colors on screen. If both palettes can be reused for other objects, even better!

Ah, I forgot to say that it looks pretty good!

Another tip: test things with an NTSC filter. Some patterns, especially when dithering, will manifest poorly on the NES' NTSC signal. A pixel isn't really a pixel anymore when you're dealing with the real output of the NES.

There is a program to try this available here: http://forums.nesdev.com/viewtopic.php?f=21&t=11947

Thanks for the feedback so far everyone!


Good to know about the way sprites work; do NES games use one or both? The caterpillar was meant to walk in segments, but that could be too complex.

This alone would have 16 8x8s or 8 8x16s, which would go up more to give the lower half of the sprites their second walking frame. Some fat would seriously have to be trimmed it seems.

Some of the engine has already been made, but it's in alpha stages.

We recently got feedback on it so far, and the general conclusion is that the controls are too loose, even looser than Super Mario World, so the controls are being tightened. I don't know if the gif shows it enough, but sprites coming on screen also have a deliberate delay before appearing. The gif also shows a more recent HUD, which dials back on the colors used.



Right now, the game is set to have most sprites at a greyscale, and then converts the greyscale to a set palette. Here's what the rope would look like with the player palette (but then the rope changes color when playing as a different character).


Now this is a tool that will come in handy! Thanks for the recommendation. Here's some quick tests using the screens posted before:

Regarding 8*8 or 8*16 sprites, it's only one or the other. Whether this is global or can change per screen is something I don't know yet. I do know that there's advantages and disadvantages to each method, but seeing how your graphics look, I'd say that 8*16 would work better. In short, the advantage of 8*16 is that you can display more with the same limitations, the disadvantage is that it's rather clumsy, especially if you wish to have Megaman/Mr. Gimmick like sprite overlaying for more colors. With 8*8, a single tile over Megaman's face would have a smaller chance of causing flicker than if it was 8*16, since the sprite is now taller, and the sprites can overlap.

Think of it this way. If you had 9 8*16 sprites lined up so that they rose one pixel each but they have one line in common, they would all flicker. Think of how Hogan's Alley or Challenger writes Congratulations on screen.



The letters don't flicker because they're 8*8, and each letter is moved up one pixel each. You can have eight letters in a row without flicker, and the next letters would be unaffected by this. But if those were 8*16 sprites, you couldn't do it this way, the sprites would have to be spaced two pixels taller.

It can even be switched after any given scanline, but that's a mess to keep straight. (Which numbers refer to which sprite graphics vary depending on whether you're using 8×16 or 8×8 sprites)

I think the comment was to understand the hardware to adhere to its limitations, not to make the game for it.


But there's like only three palettes in use despite that...

Good job on the artwork in the playfield. As for the status bar, some glyphs in the font are difficult to tell apart at a distance: O vs. D, R vs. B vs. A vs. 8. If you could post all the letter and number tiles as an attached image, I'm willing to suggest some fixes.

Different TVs at different settings (and with different proprietary skin tone enhancement algorithms) will produce different palettes, so don't worry about that. If you have a PowerPak, I have a tool to let you view your backgrounds on your NES and TV.


In addition, on an NES-compatible system with an RGB PPU (PlayChoice, Famicom Titler, Sharp C1, 2C03/2C05-modded NES), all D column colors are exactly black. The safest grays are these:

• 0F: black
• 00: lightness close to 11-1C
• 10: lightness close to 20-2C
• 20: white

A scene can contain 8x8 or 8x16 sprites. A larger sprite is made out of multiple sprites: Super Mario is eight 8x8s in Super Mario Bros. or four 8x16s in Super Mario Bros. 3. Most of the time, an entire picture uses one size of sprite, but you should be able to use 8x8 for the status bar and 8x16 for the playfield without problems, as the write to $2000 to set the high bit of the X scroll position also changes the sprite size. Use 8x8 rules above the split and 8x16 rules below and there shouldn't be problems.

In any case, your Wiggler expies can probably get away with a 16x16 head and four 8x16 segments, for a total of 6 out of 8 sprite slivers (a sliver is 8x1 pixels), leaving 2 for the player character. Flicker when using your weapon can be expected.

Looking at the catterpillar again, another alternative would be to make it out of three pieces instead of four (automatically reducing the sprite count to six), then spacing apart the pieces more than in the pic (so it remains at the same length overall). The catterpillar in that mock-up already has lots of overlap between its pieces, so it's not like it's gonna leave some important gaps.

It's commendable that you're going after NES restrictions, but since this isn't intended to run on NES hardware I think all of this streamlining is pointless. Most people don't like the sprite flickering and if you're going to be designing your characters around sprite flickering, you'll be watering them down. If I were playing this game and knew nothing about NES restrictions (about 90% of the people who play these games) I really could care less. As long as the game is fun and the atmosphere is nice, that's all that matters.

And since you're going to be modelling your game after Shovel Knight, this might be worth a read.

But regardless, I think these are some great mockups. Your foreground and background have great contrast and it's really cool how you separated your foreground/background using warm/cool colors. Your character designs are pretty crisp and I'm a big fan of how you dithered your waterfalls to lower their contrast. I'll have to give that a shot later...

Dunno, whenever I see somebody claim to be using art recreating old systems and then they break limitations like nothing mattered it irks me like hell. May as well just go with no limitations in the first place.

Thing is, NES games look the way they do because of these restrictions. If sprite limit was no issue, and neither was sprite flicker, or VRAM, your hypothetical end result would have dozens of sprites the size of the boxers from Mike Tyson's Punch-Out!! while the background had full parallax. The NES would've been able to handle something like The China Warrior instead of Kung Fu without those restrictions. Hell, throw out most of the limitations, and nothing will stop you from making a game that looks like Crysis. But with those limitations in place, then your game has to look completely different. That's the thing that bothers me with Shovel Knight, I spend so much time saying "is this supposed to look like an NES game or a terrible arcade port to the Genesis?"

That's not my point, that same locale (tileset), is shown with mountainous backgrounds, and water tiles. Optimizing colour usage could allow for all of these to be displayable in one screen.

But, apparently they're sprites? That's an odd way to do ladders... >.>
Will they animate? (Move with player contact, while climbing)



I don't think you're quite understanding the term "NES-style", optimization is exactly half of the work!
...personally, I find severe restrictions quite fun!



Oh geez! Somebody with the same artistic opinions of Shovel Knight!? O_O
I thought I was the ONLY one!!! XD

Man up, or go home! No adding non-existent colours to a limited palette. That's just pointless.

What sort of "no limitations" are you talking about? Full "no limitations" would involve PS4-quality graphics, which are out of most individuals' and small teams' budget range.


Except budget. "Limitations" are a stylistic choice that allows a video game to be produced on less than a AAA budget. People see third- or fourth-generation graphics and think "desirable retro aesthetic"; they see PlayStation 1- or N64-class graphics and think "undesirable low-budget shovelware". Would you agree with the following statements?

• If you make a game with Coleco/MSX/CreatiVision limits, it must look more detailed in all respects than all commercial Atari 2600 games.
• If you make a game with NES or GBC limits, it must look more detailed in all respects than all commercial ColecoVision and MSX games.
• If you make a game with SMS limits, it must look more detailed in all respects than all commercial NES and GBC games that do not use vertical scroll splits.
• If you make a game with TG16 or Genesis limits, it must look more detailed in all respects than all commercial SMS games.
• If you make a game with Super NES limits, it must look more detailed in all respects than all commercial TG16 games.

The problem with Shovel Knight appears to be the use of NES/GBC tiles with Genesis parallax.

Funny thing is ... the 2C04 (PPU in the Vs. System NES-alike) adds a rich dark red, green, blue, pale-ish-person-skin-tone, brown, and gold. Given the four colors (dark purple, dark red, beige, and melanin-skin-tone) they mention adding, they probably could have just gotten away with using the 2C04 palette instead.

The NES can do GBC tiles (which I'm assuming you mean a unique background palette assigned to an 8*8 area as opposed to 16*16) with the MMC5, can't it? So that's the least of the issues there, the bigger issues would be the fact that it uses, simply put, too many colors. Not to mention the sprites are relatively large and there's several of them at once. As for the parallax, you could probably get away with it if you had a LOT of VRAM dedicated to constantly updating graphics.

That said, Retro City Rampage has a better style because it adheres to the NES' limitations as closely as possible, aside from some rudimentary things like shadows.

I wasn't referring to the attribute size but to the use of 2-bit tiles.


In other words, it looks like a TurboGrafx game.


In other words, it looks like a TurboGrafx game. Lots of TG16 games used the MetalStorm trick of scrolling a tile pattern in the background.

I smell a topic split!


Retro City Rampage doesn't adhere to NES limitations as closely as possible. Maybe you're just not looking as closely at it because you're aware ROM City Rampage does work on NES.

Count the sprite palettes in this screenshot.

I'll give you a hint. It's not 4. It's not 5. It's not 6. It's not 7! And maybe you could argue it's less than 8 due to sprite overlays, but it's still impossible to have as many colors as it does on screen. It may even be possible to get a screenshot with more palettes, I didn't play for more than a minute to get this. I never really checked background palettes in game, but judging by the palettized city map Brian uploaded a while ago, I'm sure it's pretty easy to find too many palettes on screen for the background too. You see that bus in the screenshot? How many sprites is that? Why, it's 15 assuming 8x8 sprites. Just because things in this game are small, doesn't mean it doesn't DESTROY the sprite limit on the regular. It's even over in that screenshot with almost nothing going on, assuming 8x8 sprites. And before you say it could be 8x16, know that ROM City Rampage is 8x8. 8x16 sprites would mean fewer different kinds of objects are possible. And in ROM City Rampage, which uses 8x8 sprites, there are already only two types of cars (cop car and regular car) and very few NPCs. Retro City Rampage especially blows through the limitation no one ever thinks about, which is the sprite tile limit.

edit: I should note it's possible my sprite counts are off due to scaling. For instance, the bus is 17 pixels wide. Maybe it's actually supposed to be like that, maybe it gained some width when scaled. Still there are way more sprites on that totally passive screen than you'd think.

tl;dr: Retro City Rampage breaks all kinds of things EVERYWHERE. You may think it has a better style, but it's not due to being close to the limitations. I'm not saying your beef with Shovel Knight is unfounded, but man. Don't give RCR a pass, then. REALLY look at it. You'll clearly be very surprised. And that screen shot has the rudimentary things like shadows turned off.

(For the record I think Retro City Rampage became a better game by discarding the limitations. I don't take issue with it taking liberties, I just think it's interesting no one notices just how many liberties it's actually taking. For what it's worth, I also think you could make a watered down Shovel Knight on NES much like ROM City Rampage. But ROM City Rampage existing is not a testament to how close Retro City Rampage is to NES. It's incredibly watered down.)

For the most part, it does. But there are even parts with PSX style parallax (way beyond Genesis). It's a weird mixture of 8bit and 16bit aesthetics: gameplay that's somewhere in between the two (but closer to 16bit), art that looks 8bit-ish, graphic effects that look 16bit-ish, 8bit music, etc.

Okay, I see green (van, truck), police (bus, car), brown, purple, and yellow. Five palette sets, assuming you could use overlaying. You could homogenize purple and brown to be one palette instead of two distinct ones. Some of the color differences would be subtle at best, like the arrow next to Paramour not matching any of the previously mentioned colors. On the background colors front, I see precisely four; gray/white/beige (building, trailer), dark green/green/yellow (signs), brown/orange/yellow (brick wall, dirt), and green/blue/light blue (sidewalk, pavement), with a master BG color of black. The menu bar looks a little different, but just like the sprites, those colors could be merged without a serious loss in quality. The color palette seems to use optical illusions to give the impression there's more color, such as the "shadow" near the buildings making the sidewalk darker.

Sure, there's more than the NES allowed, but they're still LEAGUES closer than what Shovel Knight tried to do. And RCR, as you said, exists in NES format, albeit severely compromised. Shovel Knight probably wouldn't without extreme reworking. Plus, didn't RCR start as a homebrew port of GTA3? Brian chose the overhead style because, if such a game could ever be made, it would work the best on the NES. Plus, RCR already has dozens of sprites onscreen anyway, well above the NES' limitations allow. It also looks exceptionally cluttered with all those sprites, your screenshot is what I would assume the "max" would be on the hypothetical NES version.

Sigh...Everyone here is missing the point. If your average gamer is playing your game, they're not going to think to themselves "Oh, this screen exceeded the limit of four sprite palettes, and it looks a lot worse because if it." As a matter of fact, the average person's conception of what is "8-bit" is something like this.

But I'm not saying all of the arbitrary restrictions should be thrown out of the window. Just stay close to the NES aesthetic and break restrictions whenever it would improve your art. Amazing artists like SmithyGCN and Arne are inspired by the NES but don't let it's arbitrary restrictions dominate their art.

See, and that's the thing. When I count it up and say there's 8, you don't even believe me. When I say there's more colors than you could even do with overlaying you don't believe me. But that doesn't mean it's not true. That's why this is such an interesting situation to me.

Here it is with the sprite colors crudely scribbled in. See it now? Maybe some of that's supposed to be done with overlays so it's less than 8, but it's more than 12 unique colors. And overlays would just add to a different problem, no?

Paramour arrow matches an NPC in the bottom right, and the player's face.


And as I've also said, someone could totally make Shovel Knight in NES format, albeit severely compromised. So what are we talking about?


I'd say only graphically (which is a much smaller problem than you'd think), but that's another thing. There's more to the NES than graphical limitations. There's like... a slow CPU. ROM City Rampage exists. If you've ever played it outside the built in emulator of Retro City Rampage, you'd know it runs at half-half frame rate mostly. (It seems like it's designed to run at 30 FPS, not 60 FPS. But mostly runs even slower.) It's probably possible to do better than that, but the essence of Shovel Knight's gameplay wouldn't be hard to do at all. And your problem with its large sprites is an easily solved one. Both of these games run at resolutions larger than 256x240 scaled up. So the bosses in Shovel Knight could be scaled down to fit on that (with everything else scaled proportionally) and you're in business.

The problem with Retro City Rampage that no one seems to notice is that it uses STUPID AMOUNTS of tiles, which is actually much harder to work around than making enemies smaller. Is it still as interesting a game with only 6 different NPCs? 2 different cars? Retro City Rampage doesn't even have the luxury of it being possible to make smaller, everything is already super tiny.


Right I said that. The sprite limit would kill a lot of tense moments that were had in RCR.

Shovel Knight has big stuff. That could be shrunk.
Shovel Knight has multilayer parallaxes. They could be made single layer parallaxes or left out.
Shovel Knight may have gimmicks I'm not thinking about right now.

Retro City Rampage uses boatloads of sprites. That's uh... a big one for this game, sure could still use less but less action then.
Retro City Rampage uses boatloads of sprite TILES on screen at one time. That's the biggest one. I keep mentioning the literally two cars in ROM City Rampage. Potentially could make them have 8 directions instead of 16, though.


That's why I defend Shovel Knight. I said earlier Retro City Rampage is a better game for playing fast and loose with the restrictions. Shovel Knight probably is too, specifically because of the parallaxes everyone harps on it for. I'm making an NES platformer myself, and man it's hard to have background decorations that are clearly separate from the foreground. I can even think of one place in Shovel Knight they didn't have a parallax background this and I immediately jumped off and killed myself thinking it was a platform. Heh.

tl;dr: There's more to NES than graphical stuff. I'd have a much easier time making Shovel Knight interesting on NES than Retro City Rampage. I'd probably even have an easier time just getting Shovel Knight's graphics in.

Unless my eyes are shot, and unless I'm not looking close enough at my monitor, I don't see any sprite object that has black/light blue/white, just dark blue/light blue/white. The player's sprite could easily be the aforementioned palette with the pedestrian palette for his head and hands on top. And I don't see a single sprite where they have brown/orange/yellow, but I see dark brown/light orange/yellow. Just like the first palette, those two could be homogenized and no one would be none the wiser, since the differences are rather subtle. The two sets of brown and the purple palettes would be the issue here.

Arne is NOT a good example for your argument. He loves technical restrictions so much, that he combined the architectures of two completely different 8-bit consoles to create his own! I've been following the development of that project on his Twitter for months, now.

I even gave him a shout-out, with a 16-bit mock-up for Cat Quest. Using his palette.

I wonder if we should combine him with kevtris to bring this platform to fruition.

My complaint with "retro" graphics is when people take that as an excuse to draw blocky 4x-sized stick figures with unlimited colors against really crazy 4x-sized background art at 1080p with no respect to the pixel grid created by the 4x sizing, bonus points for shaders and 32-bit color effects overtop of the retro graphics. It's in the same league as having really crazy chiptune-plus-real-drums-and-synths music with sfxr overtop of it. Maybe it's a decent game, but it's always going to be "that indie shit style" in my book.

I'm not offended by Shovel Knight's selective adherence to NES-style limitations. The game looks good, I could care less that they cheated and added colors to the NES palette. VRC6 is definitely wanked a lot and by a lot of people, but it really does sound good, and adds a lot to the NES's APU. I'm just glad they didn't ruin it by adding reverb and pads and other nonsense like having 4 triangle channels or something.



Stick figures and unrestricted colors = NES and C64. Yes, please shit on all of us, Kotaku. Not that this person's art is bad or anything, I'm just tired of people saying this is what 8-bit graphics look like, when they really mean "that indie shit style".

You mean like Contra or Super Mario Bros. 3 or anything else with sampled drums? Or the silly, gimmicky bat-bass that is Sunsoft's later NES output? Or perhaps the chip metal soundtrack of Kilken, a GBA demo by Calodox (which could totally be done with the Sunsoft technique)?


Allusion to Please pee on us, Will Wright?

The pants:



The hat in the very same image.

Edit: I was originally going to say that maybe having the hat in this picture was cheating. I grabbed this screenshot myself, I happen to have my Player customized that way. But I just checked and Player's default hair would have also been a palette that's not anywhere else on that screen. Black, dark blue, light blue.

I mean, I guess you have no real reason to trust that I double checked the image. But... I really did. (And I even kinda missed one, but it'd be easy enough to do with sprite overlays with the other stuff that's there. Heh.) Admittedly, I could have made the image larger to make things easier to see. The reason I scaled it is so it wouldn't be huge on the forum.

You're right it could be tweaked. Just so you know, my argument isn't "The palettes couldn't work even with some tweaking." My argument is, "That palettes couldn't work as they are." My argument is, "Shovel Knight could be captured with tweaking too. People would rush to find ways to make RCR work, and it doesn't cross anyone's mind to just make enemies in Shovel Knight smaller. Less parallax." I find that interesting. I guess there's like a scale and Shovel Knight is too heavy. But what makes it so heavy people are turned off? Because it's not solely breaking restrictions. I'm not even sure it's that it's farther from the console than RCR. It might be that it's farther from the console as people think they know it. But I guess I'll never quite get that, if it's that.

We know what the Pokemon would look like on the NES... exactly like they did on the GBC! It's not like they used more than 1 palette for each Pokemon anyway.

Heh, and we all know what Pokemon would've looked like on the Commodore 64!



DEM DOUBLE-WIDE PIXELS

(I was inspired to draw this a few weeks ago after I read that article, by the way. And yes, I followed C64 restrictions. Guilty as charged!)

Good job.


Almost. The C64's pixel clock (CB*16/7 = 8.18 MHz) is faster than that of the S-PPU that the Super Game Boy feeds (CB*3/2 = 5.37 MHz). Square pixels (CB*12/7 = 6.14 MHz) are somewhere in the middle. At 160x200, the effective pixel clock is CB*8/7 = 4.09 MHz, and each C64 double-pixel is as big as 12/7/(8/7) = 1.5 scanline heights or 3/2/(8/7) = 1.3125 NES pixels. A C64 24x21 sprite is as big as 18x21 NES pixels.

(All assuming NTSC; I don't know exact PAL timing.)

Double wide pixels are gross!

Yet most Super NES games used 256-pixel backgrounds despite the hardware supporting 512. The only games I'm aware of using hi-res are RPM Racing, some RPGs' text boxes, and third-party PowerPak firmware.

To call the SNES only using 256-pixel backgrounds "double pixels" is to eschew the point of his post. In the spirit of excessive detail, Kirby's Dreamland 3 uses foregrounds with every other row empty to create psuedo transparency using 512-pixel-wide mode.

The pixel aspect ratio of a 256-pixel wide image on the SNES is fairly close to 1:1, though of course it is wider than that (8:7 or so?). It is still very far from the 2:1 PAR shown in the above C64 mockup sprites, which means the resulting image doesn't have the "gross" appearance of the double-wide pixel sprites. I will agree with tomaitheous that the double wide pixels are unappealing.

C64 aspect ratio is, IIRC, exactly half as wide as VIC20 aspect ratio. So for NTSC, that becomes 3:2 and 3:4, and for PAL, 5:3 and 5:6.

Off topic: Tepples shows that the PAR for 5.369mhz mode is ~1.14. TVs were never calibrated to spec, and that always seemed too wide to me. I set my emulators and TVs (when given the option), to 1.12 or 1.11 PAR. That looks much closer to how I remember seeing these old games systems on multiple TVs BITD. I swear that I found that PAR was changed in sometime in the mid 90's with the clarification of how digital video should be created and how PAR should be corrected or handled. 13.5mhz, IIRC, seems to be dot clock for 720x480 (with 704x480 being 'clipped' of that. Technically 484 lines, but those 4 really don't change anything). But I could have sworn that I saw older documents (pre-90's digital dilemma), stating something like ~14mhz (to what the plastic overlay would equate to when you adjust the screen underneath for the test screen - BITD).

But yeah, double wide pixels as in the pixels appears almost double wide compared to vertical resolution (7800, c64, CoCo 3 low res, etc). Sooo gross :p

Hi guys! Thanks again for the feedback so far. I'm glad that this built up quite the discussion on palettes (to the point where I see the thread got split). I think for now my friend Naoshi and I are sticking to the palette table we currently have set up since it works best with the artwork we've created so far.

I did the art for this stage earlier in the year (it's on page 1) but I felt it looked too much like the Metroid tile set so I'm redoing it. Still a WIP.

And with a filter.


The characters were also tested with a minor palette tweak.


This is how the main characters look when taken out of the 8-bit graphics.

If that's what they're supposed to look like out of pixels, what would they look like in pixels with the light (skin) color for his shirt and her blouse, and the medium (red) color for her skirt?

Whoa! Those are some really professional character designs! It's rare to see such artistic talent on indie projects like this.

And yet...I think the pixel art designs could be a lot closer to the concept art. They're a little too serious. Maybe something like this, if it's not too late in development to change the designs?



Oh, and the WIP cave tileset is also coming along nicely...I like the texture of the door and the Western effect you achieved by banding the rocks like that. The background is just starving for some detail, though...why not fill it up with some single-colored rocks?

While those sprites of yours *are* quite nice, I wouldn't change the originals.
They have a rather interesting contrast from the NES-era standard.

NES-Era:
Gritty Box Art > Cutesy/Chibi Sprites

This Art:
Cutesy/Chibi Art > Gritty Sprites

It's still much more common than it will ever be for modern NES game projects. You have people creating interesting characters, nice graphics, and catchy music for various Mega Man fan games made for a modern engine, but when it comes to ROM hacks... just make Bomb Man blue, make him shoot his bombs in all 8 cardinal directions, and set it to some NES-ified Kirby music. That seems to be the trend of Japanese MM hacks, anyway.

The allegedly "gritty" sprites are actually close in proportion to the "cutesy" art.

Yes, but when you're working in smaller resolutions like this sprites generally look better with smaller head:body proportions. If you try to match the proportions of the concept art, you'll have to remove facial features and as a result, personality. There just isn't as much room for detail in 16x32 sprites like these.

But with that being said, 1:2 body proportions are a personal preference. Shane's 1:4 body proportions and side profile are very remniscent of older NES games, so I think they fit the NES aesthetic much better. And I don't think they're that gritty, either. When I think of gritty sprites I think of 1:8 sprites like in Ninja Gaiden, Contra, Metal Gear, etc.

Because of my work in the horror genre, I associate that pixel shading style as "gritty".
Just a term I picked up, from working in a dōjin circle.

Ohh! Do tell! What did you work on?

I don't know to what extent your palette budget can accommodate Mega Man-style sprite overlaps, but I edited the sprites to more closely resemble the concept art.

Hey, that's a pretty neat idea! And if you play around with the shading and design a bit, you could squeeze the sprite overlays to be only 8 pixels wide.

You can thank http://the-ez.deviantart.com/ for bringing out that professionalism! Basically she was shown character concept art as well as the sprites, and from there she gave them the "Wreck-it Ralph treatment." As for changing them majorly, it's unlikely since the games art style is already set in stone. Something overly cartoony could clash with the current level artwork. The deliberate aim is a medium between the Castlevania series and Super Mario Bros 2.


The Mega Man method could always work; it does take up sprites on its respective line though right?

Overall, the biggest issue the black outline test came up with is the sprites look a bit odd on a black background, which good portion of stages use.

You can always use different palettes for the characters depending on the level.

You could also try picking a darker shade of blue for those background elements, or touch up the player sprites so they're more colorful or varied. For comparison, take a look at Vice: Project Doom. Having different player palettes depending on the area you're in is also a good solution; SMB2 alternates between giving players a blue outline or a black outline depending on whether they're in a darker area or lighter area.

Hey its been awhile! The engine has been tweaked a lot and changes are still being made, mainly stress and lag related stuff. I've been doing more tile sets and recently went back to address the palette issue. The two main things I'm aiming for is the two players to have contrasting colors. The second thing was addressing Juanias skin color issue. Here's a test of that:


I also played with the idea of them being pink and blue:

A new tileset in the works:

With this tile set, you can see a slighter greater push for the western style design within the game, mainly a bordertown between Latin America and Native America.

Besides that, the main thing going on right now is making sure all of the connecting levels will work under stress tests and building up more levels. Once there's enough gimmicks programmed in, I'd like to make a teaser video (right now most of the levels are just empty levels without enemies or gimmicks).

I should probably remember to post here more often.


I've been burned out lately from the game, but I'd like to finish it one way or another. I'd really like to commission more people to help with the sprites. Something about the players sprites still bugs me too.

I like your waving floor idea. We have plenty of tech-talk, but not much talk about sharing game play ideas. Possibly because you still would need a way to program it anyway. For instance, that idea would require a special type of collision detection, having to switch between sprites and tiles, and chaining objects together.

I imagine the falling thing could be part of the BG, if you changed the tiles and the tilemap.

The tiles themselves can be part of the tile BG.

Maybe this could be special cased, and have a scroll table set out in ram. Hooking up several objects sounds too complicated for this.

Timed code, with some dynamic object collision (box collision, with moving sprite objects). Not too difficult. This could *easily* work on the NES.

The waving floor is still being worked on, but it definitely came first as an idea that would look fun first, and then tried to figure out if it could work on a NES (you'll notice the piano keys never reach the window either).

Anyway, I am currently looking for beta testers for the purpose of glitch finding or feedback, as well as spriters to help ease the workload. Send me a PM if you're interested in either one and we can go from there.

Bump!

I forgot about this place for awhile, so I figured I would drop some videos for y'all:

https://www.youtube.com/watch?v=N_o19yMTT9s

https://www.youtube.com/watch?v=6G0ueLkV1y0

While the project isn't dead, I have moved on to other projects. From helping the Sonic Time Twisted team through most of 2016, as well as rebooting a 16-bit style project called Wonderworld, I've been learning more about game development and working as a team. We're experimenting with ideas to either finish this and release Golds Curse individually or put it into the current project as a part of an extended story.

I haven't seen this thread until now, but wow, this looks really great! Gameplay looks solid, too.

I must say I have some trouble with a few notes in the song in the first video. These few notes i found troublesome inject quite a bit of drama, which is fine and exciting on its own, but i think they need to be reeled back into the fold a bit. I feel like i'm missing a release or transition or two; alternately a change of accompanying harmony in preparation for the "wild" ones.

At 0:38 in that first video, did the crumbling block make the skype message sound?

Looks real nice!

This looks like a genuine contemporary NES game. I love that.

Loving it too, not only do the graphics and gameplay look nice, I dig the game design. I want to play this

Felt that to: "I want to play this"

While modern code is no doubt going to make it more accessible/portable to a range of different systems of today, have you thought about partnering up with someone to make a NES port? Since so much care has been taken to make it close to NES specs, that might be a possibility.

Thanks for all the compliments, everyone! Means a lot from a community of experts and lets the team know we're going along the right path.

For the music, I'll send the critique to the composer, and see what he can do from there! Thanks for the feedback. As for an actual NES port, I'd love to do that someday, but the most important matter is finishing the game first.

There's four maps (out of six total) made and functionable in-game, but only two have about 75% of their gimmicks, while the other two are empty gimmick-wise, but explore-able.

A minor conflict development wise is the games story ties in to the story of another, 16-bit game we have in the workshop. The issue arises is I can't really decide if
A. This game, Golds Curse, should be released individually first, or
B. The story of both games would be made stronger by having to find collectibles in the 16-bit game to unlock the 8-bit game, and thus play through the six levels to reveal some lore/origins relating to the 16-bit games story. Basically, a game within a game.

A game within a game essentially means a significantly reduced number of people who will play the unlockable one.

I agree, and I was thinking one doesn't necessarily exclude the other. After a standalone release, you could reuse the code, lift a level (or make a new), and put it into your 16-bit styled game as a throwback to your 8-bit styled release, perhaps.

Put the 16-bit game inside the 8-bit one... that'd be a first!

That'd be a second. See what Space Invaders for Game Boy does when played through SGB.

Haha that's true.

Hey, hey! Figures I should blow the dust off this thread!



Weird to think some of the plans for this game are archived in this thread, but here we are today! Have fun!