so few programming the NES?

[dougeff]

It seems to me that there are very few people actively making new NES games. Someone suggested that maybe there are dozens of people making games that just aren't posting them or talking about them. But, the skills required to make an NES game are hard to get by just reading the documents. I can only conclude that there really are very few people doing this stuff.

SNES, even fewer.

Not really a question. Just an observation.

[rainwarrior]

I would tend to agree. It is quite a small groups of people.

[Sogona]

I think the NES is at the perfect spot where, sure it's hard, but a lot more "possible" than something like the SNES. The atari just seems too limited for my taste, and while I think it's cool that you're a lot more involved with the TIA than you are with the PPU (from what I've read at least), it still just doesn't seem as fun as the Nintendo. And then the SNES just seems way to advanced.

I mean, didnt nintendo spend like 4 years or something working on Super Mario World? (Come to think of it, was there a team working on World at the same time 3 was being made?) Anyway, in my opinion for something like the Super Nintendo and beyond, you really need a team of people to make a game, but homebrews have been made, so...

For me at least, my biggest potential struggle is trying to get things right from the start. I have a bunch of ideas in mind for my current project, and I want to structure the basic skeleton so that it won't be a pain in the ass to implement new things that I think of along the way, but at the same time, putting in a bunch of placeholders for things really overcomplicates it at the very beginning.

[darryl.revok]

Just another small observation to add to this discussion.

When NES games were still being developed commercially, you had companies who could continually reuse their efforts when necessary. If you're going to make a new game and you've already made several, no need in creating new scrolling code unless your new game scrolls differently from previous ones. Same with most of the basic engine. I'm pretty sure Capcom used a modified Mega Man engine for a lot of their platformers.

With one individual making a game, two years or so when it's done, the individual is probably burnt out and done with homebrewing. Not the same for everyone, of course, but this is just one reason why the overall production of homebrew games is a lot slower than what we remember from 30 years ago.

[rainwarrior]

I don't think that holds true. Several NES homebrew developers have made a string of games.

After Battle Kid, Sivak made Battle Kid 2.
Khan games has made a series of NES games, about to release The Incident.
After Nomolos, Gradualore is making Owlia.
Sly Dog has released two games in their Amondus series so far.
Shiru made a whole bunch of NES games. (Alter Ego port, Zooming Secretary, Beerslinger, several others...)

If anything, I think the people that actually finish games are much more likely to make a second one. The people who burn out usually don't finish anything at all.

[dougeff]

continually reuse their efforts when necessary

My philosophy is "don't reinvent the wheel". If you have a platform game that scrolls well, just reuse and modify. Why waste time redesigning it, except maybe as a learning exercise.

[tepples]

How much code is shared among Super Mario Bros., Doki Doki Panic/Super Mario Bros. 2: Mario Madness, Super Mario Bros. 3, and Super Mario World? I seem to remember map formats being similar between the last two.

[dougeff]

I think SMB1 and SMB2(jap) have very similar code.

Doki Doki Panic was completely different, but it wasn't intended to be SMB2 anyway.

[FrankWDoom]

There's a pretty steep learning curve to get started on the NES. I feel like have have an ok handle on the instruction set, enough to write some patches for mappers and controller input and so on. But I'm sure there are a bunch of usual conventions I don't know enough to use yet. I'm still trying to wrap my head around the graphics system- I think I'm finally getting close on that. But overall I don't know how to organize code for a whole game, or what actions I should be doing at various points during the course of frame, writing "simulation" code for movement, collisions, etc, or even set up a proper build environment. Beyond that, I'm not an artist, so graphics are another uphill battle. I'm also more of a builder than a designer- coming up with decent ideas for a feasible game is a challenge. Also sound. There's a flash game I've had in mind that I think would make a solid source for a NES port, so I can at least start with something to rip apart for assets and logic.

And I say all of this as a programmer by trade. I don't know if that makes it better or worse. I feel like I at least know what I don't know, versus someone who might be totally clueless.

[darryl.revok]

The people who burn out usually don't finish anything at all.

Good point. Or they stop at the demo stage as a lot of projects do.

I used to think that the esoteric nature of the information pushed people away, but now that I'm doing the programming myself, that detailed information is extremely valuable. More people are getting involved though. I know a few people joined around the same time as me.

Another thought, not on the number of people programming, but on the length of time for development to see full games: I feel like creating the game content is always going to be the longest part. Creating a solid engine, even beginning without 6502 knowledge, probably takes about 6 months tops. Creating all of the graphics, sounds, levels, and an editor to build those levels, is going to take quite a bit longer.

[93143]

I think the NES is at the perfect spot where, sure it's hard, but a lot more "possible" than something like the SNES. ...in my opinion for something like the Super Nintendo and beyond, you really need a team of people to make a game, but homebrews have been made, so...

I dunno; I like the SNES. It's more complicated, but to me it still seems to be simple enough for a single person to do a whole game. A lot of stuff seems to be simpler than on the NES; for example, the dual-axis scrolling and status bar in SMB3 are trivial on the SNES. Doing a reasonably sophisticated game on the NES requires you to work around its limitations, whereas on the SNES you just do it.

(Just be sure to keep a reference handy so you can easily look up the S-PPU registers; there are a lot of them and no one should have to memorize them all.)

On the other hand, as others have said, the implicit standards for production values are a lot higher on the SNES, and audio programming is a whole different beast (that I personally haven't even tackled yet), so I can see how it might be more daunting.

Maybe I should come back when I've actually finished a game rather than just a handful of tech demos and half-baked mockups...

...

On topic: NES programming isn't a job any more; it's a hobby. You have to really want to do it, and even then you can't go very fast. I think that explains most of it.

[Memblers]

Don't forget to check out the community on NintendoAge as well, I know there are several NES programmers on there who never seem to post on here.

It may not seem like there are very many people programming the NES, but there are way more than there were 15 years ago, 10 years ago, or even 5 years ago. I always assumed it would kinda plateau at some point, but it seems that it hasn't yet, it's been more like exponential growth. Even with RetroUSB and INL helping people release their games, there was still enough unmet demand for me to go ahead and put my own GTROM board and cart shells into production.

[Drew Sebastino]

I dunno; I like the SNES. It's more complicated, but to me it still seems to be simple enough for a single person to do a whole game.

Vram... I've still never completed everything I want for it. My trouble is thinking of how to store the information for sprites over multiple frames, so it knows where to erase from the vram table whenever the animation changes. I'd also like to think of a way to double buffer without hardcoding it for each object and a way to only partially update something, to where if there's a tank sprite object, you would only need to update the sprites for the treads. None of this would be a problem with chr rom...

...Maybe I should have opted for a simpler system and just held back, considering I've never programed anything prior to starting this. Most people have at least made pong...

[darryl.revok]

Espozo, just curious, did you make the "In the Hunt" for SNES demo I saw posted on Youtube a while back? Before I landed on NES, I was thinking about developing for SNES, looked up SNES homebrews and that was one of the first things I saw.

[tepples]

I feel like creating the game content is always going to be the longest part. Creating a solid engine, even beginning without 6502 knowledge, probably takes about 6 months tops. Creating all of the graphics, sounds, levels, and an editor to build those levels, is going to take quite a bit longer.

We discussed some of this years ago with respect to the complexity of a one-man unpaid hobby project.

I'd also like to think of a way to double buffer without hardcoding it for each object and a way to only partially update something, to where if there's a tank sprite object, you would only need to update the sprites for the treads.

My current NES project double-buffers 16 tiles for each of six sprites. If I put the treads in one half (up to 8 tiles), I can put the part that doesn't need to be updated in the other half. (Even if you saw this, the OP probably hasn't.)

EDIT: Corrected attribution of quoted post