Creating the 'best possible' NES game

[Kasumi]

In my experience, no one will pay for this, though.

I get PMs every now and then on a pixel art forum asking me if I want to make an NES game. And everyone is scared off by a reasonable expectation of payment. I'd be happy to make "some money" doing this, as long as "some money" is worth getting out of bed for, and incentive enough to not just work on my own project instead. My own project where I don't have to answer to anyone.

Edit: And the fact is, I could always just make an NES-Like game as well. It's in my skillset. And that'd cost less solely because it'd take less time. Which is why (basically) no one will pay for an authentic one. You pay a bunch of extra money to feel good that the game works on NES, when that version of the game is not even what will be making the cost of the project back as you've said.

[Myask]

When it became Retro City Rampage, Nintendo only offered him a license to publish the game in exchange of him removing his NES development documentation.

This piques my curiosity(/censorship annoyance). Is there a record of this offer? Is his documentation still available somewhere?

[rainwarrior]

I get PMs every now and then on a pixel art forum asking me if I want to make an NES game. And everyone is scared off by a reasonable expectation of payment.

As a ballpark figure, I would suggest that a professional quality NES game should have a development budget of $10,000 at bare minimum, for a relatively small game (e.g. Donkey Kong). I would imagine that even this very lowball offer would scare away most. Not many people would put that much money on the line for an NES game.

A few years ago, I worked on a rather small action game for XBox 360 and PC. We made the game on a budget of about $1,000,000. The people working on it were being paid about 1/4 of industry standard wages (i.e. lower wages in return for a stake in the company). This is for a game that takes about 30 minutes to play through.

I doubt Mega Man 9 or 10 was made for any less than $1,000,000, so it's kind of ridiculous to think of it being used as an example as something that was "easier" to make than an NES game because of the reduced limitations.

[OneCrudeDude]

I was anticipating a budget for this game to be around $250,000 to $500,000, depending on how big the game will be and how big the staff would be. Maybe $750,000 if we want to push the budget over, and possibly give this game some unique hardware to work as intended. While those are huge numbers, they're still rather small for industry standards. Maybe the price doesn't even need to be above $200,000 for all I know, I wish I was a financial expert.

[Kasumi]

I tried really hard to avoid making a real post in this topic...

I doubt Mega Man 9 or 10 was made for any less than $1,000,000, so it's kind of ridiculous to think of it being used as an example as something that was "easier" to make than an NES game because of the reduced limitations.

Sure, game budgets are huge. If you've got a large staff working full time, you have to pay them all. I'd imagine whatever their budget was is still less than what it would be if they made an actual rom, though.

Budget is a topic I think a lot on since recently my NES game turned 5. I can't say I've worked on it full time for all those years, but eh... pretty much all my free time goes into it that isn't spent drawing. If I were paying myself, I dunno. It'd be... maybe 2-3 full time years? Could even be 4. And y'all can decide what the annual salary for 6502 programming/pixel art would be, I ain't posting a figure. I'm doing that thing I discourage everyone from doing. I'm finishing the thing on NES, despite that fact that I will likely not make cartridges. And it's easy to figure out why. Those won't even get me close to breaking even on the time I've spent at this point. I'll have to reprogram it in C if I want it on Steam or whatever.

And what's done?
The game engine is done, minus music playback. Supports slopes, Co-op, shooting, all sorts of neat object interaction, cutscenes, text compression and display.
There's one "finished" tileset.
Main character (8 direction shooting, grabbing and throwing objects in eight directions, close to "sonic-style" physics with slopes, rather than "if-on 45 degree slope move at slower fixed rate".)
3 Objects. (A ball to throw around, a single fully animated enemy, a spring. Up to you if the player character's projectile counts ¯\_(ツ)_/¯ )
3ish other objects that are pretty much fully animated but not programmed. (Because... more important stuff needed to be done.)

And what's not?
... 98% of actual content.
All the levels. There's just one "actual" level. (With 40 or so test levels I've got to test water/slopes/whatever)
All the tilesets. Kinda want at least one per world, probably more since the same set for every level in a world is kinda boring.
All the cutscenes.
All the music.
All the sound effects.
All the bosses.

As it stands, I'll be lucky if I finish before the game turns 6, but I think I'm out of the woods as far as truly difficult programming is concerned.

The real kick in the head about NES programming is stuff players take for granted... stuff that's REAL EASY on a modern platform is totally frightening to program on NES. I hate sharing screenshots and things about my games in progress (unless they're nearly ready), but there's a fun one:


(The game has good graphics, I promise. This was a test to make sure attributes were properly restored)

In C, the above textbox appearing and disappearing (And restoring the level underneath) would have taken me... a half hour? Maybe two? Maybe a whole day?
Guesses for how long it actually took?
3 weeks. I guess I'm not the best guy for the job at this, I'm sure many of you could get it done quicker. But I'm sure it would still take orders of magnitude longer than the same person doing it in C.

More fun! I actually got text compression and display done in 3 days. (After... a long time planning out a good, feasible compression scheme.) On a modern platform, I wouldn't have to compress the text.

Slope collision? Hah, you know what was hard about this? Getting it fast enough. Making sure the player could not get inside of walls while checking the fewest amount of points. On a modern platform, I could check every point my character is drawn on.

What the folks here call 8 way scrolling took me a long time as well. And would be free on a modern platform. In fact, I'd bet a lot of money I could write scrolling code from scratch faster on a modern platform than I could PORT WHAT I HAVE IN 6502 TO ANY OTHER PROJECT!

I'm not sure people who want to get into the NES homebrew business know where the time really goes... Pixel artists think partnering with me will save me a lot of time, but art is not where the time goes. And maybe people who make famitracker music may think partnering with a person will save them lots of time, but this is also not where the time goes.

And this is why there are many, many, many NES-looking games and very, very few quality NES homebrew games. And honestly, when I see topics like this one it just makes me angrier and angrier every year.

The reason I post all this here is because this topic is about the "best possible" NES game. I have no doubt I could make a simple game in a week. I have no doubt I could make a slightly more complex non scrolling game in a few months. And this is what I tell everyone who wants to make a homebrew NES game (with me or anyone else.) Don't scroll. Don't do slopes. Don't be ambitious with it.

But the game I'm working on now (which I'm trying very hard to make as good as I possibly can) could not be made without a large budget, or people willing to work for free. (And I hope no one would want to work on a project like this for free, unless they started it.) And Tokumaru would still say it's not technically impressive because I didn't hide scrolling attribute stuff. (I did end up doing this, and there aren't wrong tiles at the edge of the screen like in SMB3, though.)

And I'd agree with Tokumaru, it won't be technically impressive. No parallax scrolling or other scanline effects, no variable width font, no nothing. Just code optimized enough to get enemies on screen (with slopes no less!) while slowing down less than Kirby's Adventure hopefully. Just a fun game. And it'd have cost you all a lot to make.

For what it's worth, if I had any idea I'd still be working on the game now when I started I would not have started. I'd have just made a modern game. That's why I discourage people from doing this, despite doing it myself.

A final point: You may be thinking, "But Kasumi, it must be possible to get done much faster if I find someone better than you." I have no doubts you could find someone better than me, but you would have to pay them more because they are more skilled. Funny thing about that. And if you want to pay more people to get it done faster, that's fine too. It adds to your budget.

[tokumaru]

That's a pretty melancholic view of the whole thing, Kasumi. I can see where you're coming from though, seeing as I've been working on the same handful of projects for several years (NES platformer, NES raycaster, Atari 2600 metroidvania) and have made even less progress than you. That used to bother me a lot, but I guess I learned not to care so much. I never planned on turning game making into actual work, because pressure and deadlines tend to ruin hobbies for me, and I really don't want to ruin this hobby. I find the fact that it's easier to complete a game for modern PCs pretty pointless, because more than half of my fun comes from seeing the programs running on these limited platforms.

I've recently accepted that the chances of me ever finishing a game are extremely low, specially now that I have a 1-year-old daughter to raise. Having a little girl actually helps a bit with the frustration of never finishing any projects, because she gives me a sense of accomplishment that I doubt I could get any other way. If I ever manage to finish anything, great, but I gave up on setting unrealistic deadlines that just result in frustration.

I guess I do sound a bit extreme when I'm judging other people's works, but I'm actually pretty flexible. I can forgive a few flaws (e.g. scrolling artifacts) if the product as a whole offers more good points than bad. I do feel a general indifference towards very simplistic games will straightforward graphics and dull music, because there's absolutely nothing that stands out. Unfortunately there are a lot of homebrews like that. Maybe if the people responsible for such releases stuck around longer, the quality of their releases would increase, but I guess that more often than not the difficulty of programming for the NES drives people away.

[rainwarrior]

I doubt Mega Man 9 or 10 was made for any less than $1,000,000, so it's kind of ridiculous to think of it being used as an example as something that was "easier" to make than an NES game because of the reduced limitations.

Sure, game budgets are huge. If you've got a large staff working full time, you have to pay them all. I'd imagine whatever their budget was is still less than what it would be if they made an actual rom, though.

The thing about this is that you can scope any game plan to fit your budget (you sort of hit on this with your time-vs-scope estimates). They could have targeted an NES ROM if they wanted, for the same budget, it would have just been a more restrained game. The reason they didn't is because there's no reason to expect the game to sell any better if they made it as an NES ROM, and the game wouldn't be as good.

There are situations where I think it's actually a reasonable risk to make a commercial game for the NES (and I'm taking this risk myself), but I don't think it was ever on the table for MM9; not at the scale they needed to target.

I was anticipating a budget for this game to be around $250,000 to $500,000, depending on how big the game will be and how big the staff would be. Maybe $750,000 if we want to push the budget over, and possibly give this game some unique hardware to work as intended. While those are huge numbers, they're still rather small for industry standards. Maybe the price doesn't even need to be above $200,000 for all I know, I wish I was a financial expert.

Well, going back to SMB3 as an example, I'm sure they spent more than $1,000,000 on just the marketing for that game, completely aside from the development cost. There are NES games you could get for $200,000 or any budget you choose, right down to $0, but that seems awfully low for a "best possible" game, even in 1988.

More recently, even the rather turnkey Cheetahmen II project was asking for $65,000 for something that probably didn't require more than a day's worth of software engineering.

I guess that more often than not the difficulty of programming for the NES drives people away.

Making games is hard, on any platform, always.

[Kasumi]

The thing about this is that you can scope any game plan to fit your budget (you sort of hit on this with your time-vs-scope estimates).

It's true, a less ambitious game is doable.

But this topic is specifically about the BEST POSSIBLE GAME, which assumes the game is NOT scaled to fit the budget. The reverse in fact!

That's a pretty melancholic view of the whole thing, Kasumi. I can see where you're coming from though, seeing as I've been working on the same handful of projects for several years (NES platformer, NES raycaster, Atari 2600 metroidvania) and have made even less progress than you.

Maybe it's melancholic because I hate this sort of hypothetical thing. People are always all, "Hey wouldn't it be cool if..."
And I'm like, "It'll never happen." Like a true killjoy.

Maybe it's melancholic because I think people really, really don't know what they're getting into when making any sort of game. Kickstarter budgets make me laugh on a regular basis. I imagine if I had tried to kickstart this game back when I started. And how damn off I'd have been on the estimate of delivery/budget.

Want to know a secret, Tokumaru? I used to worry about you "beating me to the market" so to speak, as you seem to be the only other one who has even tried a Sonic style thing on NES, at least... good Sonic Style. And not like... Somari. (I keep saying Sonic style, but I ain't got no loop-de-loops or running up walls. Just the slopes affect your movement in a more than basic way. And that I can have totally arbitrary slopes, but don't very often because there's only 256 tiles in CHR at once and storing non basic stuff uses a lot more unique tiles...)

These days the only game I "worry" about is Super Bat Puncher.

Make no mistake, I LOVE my game. I've spent probably literal weeks just running around in a big test level I have, and I'm still not bored of it. But the fact is, it's very unlikely for me to even break even on the time I spent on it. And even though the game making profit is not the only reason I work on it, it's still a factor I do consider. I could have made the same game faster on a modern platform. And since people buying my game won't have the choice for a rom, well, why didn't I? I wonder this, and so should anyone. Is your love of retro seriously worth EXTRA YEARS? Mine is not, but it's too late for me. If anyone reading this post loves NES that much, cool. I just don't want anyone to start not really knowing what they're getting into like I did.

Just know.
Just know...

[koitsu]

For what it's worth, Kasumi -- my own feelings mimic many of your own. So don't feel alone in things like laughing at Kickstarter budgets, or the lot of idealists who have no actual skill set to achieve what they propose (or the finances to do so -- or more importantly, even knowing the people who can make those realities happen (i.e. they know nobody)), as well as being frustrated by "simple things" like drawing + erasing a "window" on the NES (I absolutely can see how that would take 3 weeks. Hell, it'd probably have taken me more like 2-3 months -- it's really not a simple task, there's a lot that has to be tracked internally).

[Myask]

And what's not [done]?
... 98% of actual content.
All the levels. There's just one "actual" level. (With 40 or so test levels I've got to test water/slopes/whatever)
All the tilesets. Kinda want at least one per world, probably more since the same set for every level in a world is kinda boring.
All the cutscenes.
All the music.
All the sound effects.
All the bosses.
[...]
Pixel artists think partnering with me will save me a lot of time, but art is not where the time goes. And maybe people who make famitracker music may think partnering with a person will save them lots of time, but this is also not where the time goes.

It wouldn't have YET saved you time, perhaps, but it certainly appears that it WOULD save you time. At this point, you have a WORKING GAME! Isn't that pretty cool? Longer,It seems like your game has quite a lot of its programming done, by your list. Remaining would be the music and boss (maybe enemy?) AI, and maybe a few more objects, such as a level exit (if you have discrete levels) and a checkpoint (even if you don't). Possibly making some tools to make level creation easier, and possibly some codecs for data if you think you need more space.

However, the level design can almost wholly be done independently of the remaining programming, at least until one side decides more new objects are desired, and they may not be. Perhaps your game is going to be Sonic meets Glover, and doesn't need a whole lot of complicated objects. Even then, boss rooms aren't even always stored in the same format as the rest of the game, though obviously boss rooms and boss graphics and boss programming all need to be coordinated.

Similarly, the graphics and sound are a bit more dependent on level design and "programming" considerations (animation, banking, space) and "hey we want graphics/music for a forest level". Level design might mix a bit with either (if you want to have a neat setpiece at the beginning with some dramatic riff timed to when you go over a jump with some nice background, say), but again...

My impression of small game projects is that there is almost always a programmer, a sound person, and a graphics person. One of these usually is the designer of the concept. Occasionally you get wizards like the man behind Super Turrican.

Similarly, I don't think people get into it for the money. They just create things, and if, at the end of the day, they can sell what they've enjoyed making, that's a bonus.

This certainly makes me want to get to my own finished-product stage more.

[OneCrudeDude]

@Kasumi: I understand wholehartedly where you are coming from, and your post raises a few issues; specifically the implementation of more complex stuff. They do take a long time to create, so why shouldn't the effort be split between several people? One guy does the scrolling, the other does the dialog boxes, something like that. It might be difficult to merge the 'games' together as they both might've altered the game's core code to make them work, and be ultimately incompatible with each other. In some NES games, it seems like it wasn't uncommon for the credits to list certain people with seemingly arbitrary tasks; I wouldn't be surprised if there's an NES game that credits some "Erasher Shigami" for being responsible for the "scroll engine".

I agree, Super Bat Puncher does appear to be the best possible game a homebrewer can come up with. Then there's the impressive, near pixel-perfect port of STREEMERZ by thefox, and the Japanese-made Blade Buster or Kira Kira Starry Night. What's to stop me from, hypothetically speaking, hiring Miau to make the base game, and hiring that Japanese guy to program the overhead shooter stages? Probably memory constraints, or data sharing, or both.

[Myask]

As for the primary topic at hand, it's a damn shame that, of all of the PPU's VRAM, you can't farm out the palette data.

For the "Best Possible NES game," you could get away with having the CPU just run code that could fit in RAM to update the APU, the palette data and other PPU registers, and I guess an OAM DMA. (ed: and controller input, duh...though one might also theoretically have EXT-controllers, so...) Everything else, you can just have the cart do all the game logic (at a much higher speed), manipulate CHR and name/attribute tables according to where on the screen the PPU is drawing...if you added a cycle-timed loop for updating vertical scroll every line, you could even bring the attribute restrictions down to merely only each 8-pixel-wide slice of each scanline having 4 colors (plus 3 more when there's a sprite--and why not have them, if you're diddling the scrolling and CHR every line?)
(fake-edit: Actually, need one even update scrolling, one can just change the attribute tables between scanlines of a tile.)

You need not actually have the CPU pull instructions from a ROM, or obey interrupts. You can just ignore what address it's trying to read (more or less) and feed it the instructions YOU want to feed it. Probably mix some JMP $8000 in with your NOPs when you haven't got anything for it to do to keep the PC from overflowing into RAM.

You wouldn't even have to fiddle with the nametables, since you're basically pulling an Oeka Kids mapper writ large, so you could just have 0-FF (or 0-1F, with others for sprites) repeated over and over.

This seems like an ideal setup for "movie" carts.

[koitsu]

What's to stop me from, hypothetically speaking, hiring Miau to make the base game, and hiring that Japanese guy to program the overhead shooter stages? Probably memory constraints, or data sharing, or both.

Hypothetically indeed. What makes you think either of them 1) have time for such a thing, 2) want to involve money (e.g. want to be paid)?

For example, speaking personally, I would refuse #2 in every way/shape/form because what that would do is turn a hobby/something for fun into basically a job/form of work, and I segregate those two things. I promised myself back in the early 90s I would never turn any kind of hobbyist gamedev into a line of work or involve money in any way, and I've stuck to that promise (and I know quite a few people who did go into gamedev professionally and now regret it; "it no longer has the same feel to it"). There are a lot of people who keep hobbies as hobbies for a reason: because they don't like the pressures of time, deadlines, needs, or worries along the lines of "oh crap I won't get paid this month / cannot eat unless I finish up that graphics routine".

I have no idea what miau's up to these days, but Hally et al is usually quite busy (I follow many folks involved in Kira Kira Star Night on Twitter) from what I can discern. I get the impression he's already involved in some other unspoken project since he recently prodded Jake Kaufman (Virt), which means there may be something he's working on that requires Famicom music composition. That's purely speculation on my part, so take it with a grain of salt.

I guess my point is this: even if you had an unlimited amount of funding to throw at a game, it doesn't guarantee that any of the people you'd like to be involved (meaning people with the skill sets you desire) would a) want to be involved, or b) have any interest in it (including for monetary compensation). Absolutely no offence intended nor am I intending to rain on your parade at all (honest), but I mean we are talking about a classic console here, which means in a lot of cases the driving force is personal interest; you may have a 10/10 level of interest, but the person(s) you might want/hope have the same level of interest might turn out to have 2/10. Kira Kira Star Night is an amazing example of collaboration on multiple levels and I cannot even begin to fathom how Hally et al got everyone involved -- my gut feeling is that there is a significantly different vibe/feeling/social situation going on in Japan with Famicom things compared to here or Europe.

[tepples]

I promised myself back in the early 90s I would never turn any kind of hobbyist gamedev into a line of work or involve money in any way, and I've stuck to that promise (and I know quite a few people who did go into gamedev professionally and now regret it; "it no longer has the same feel to it").

The problem comes when a hobbyist can't get a game designed for two to four players onto TVs because the traditional "hobbyist gamedev" platform (that is, the PC) is stuck on a desk with a monitor sized for one person. True, it's been possible to use a TV as a monitor for PC gaming ever since TVs started including VGA and HDMI inputs circa 2007, and it was possible even before that with VGA-to-SDTV scan converters. And PCs have supported multiple USB game controllers through a hub since 1999. But other Slashdot users tell me that almost nobody actually does that. This lack of hobbyist platforms in the living room forces some developers into the industry.

[Kasumi]

It wouldn't have YET saved you time, perhaps, but it certainly appears that it WOULD save you time.

Maybe you're assuming I don't actually know what goes into making pixel art. You're right to assume that since I have nothing good posted publicly. But I've taken advantage of the time spent on this game to get good at it. You'd be right that I know nothing about music, though. If I break and hire a person for something, it'd be that.

The pixel artist I've talked to said an NES tileset takes him like three hours. Dude makes his living that way, I trust him. Just fully animating an enemy takes about that long for me, tilesets are 3 days to a week. And sure, 3 to 7 days is huge compared to three hours, but all of it's negligible compared to code/design. Consider that 5 years has gone mostly to code/design. I am unconvinced the graphics/sound will take even a quarter as long in this case. For the latest Mass Effect? Sure. For an NES style retro game? Nah.

Let's say that pixel artist lied to me, and it really takes him 8 hours for a set. He could probably still have got ALL the sets I'd potentially need (probably 16?) for the game done before I was done with just getting textboxes to display if we started at the same time. I'm not saying it's not time. I'm saying it'd be a small percentage of the time in a "best possible" NES game. Even if the dude was maxing out 256KB of CHR ROM... I'd beat him on just textboxes, but yo... we wouldn't be close on the rest. The gap between time spent is MUCH smaller when coding in C, but keeping the graphics NES-authentic. I wouldn't be totally surprised if coding suddenly became the easier job, actually.

There's also that even if some other dude was doing art for me, I'd still have to put it into the game. And this is actually harder than you might expect for some things.

Possibly making some tools to make level creation easier, and possibly some codecs for data if you think you need more space.

You mean like this? (Again, I promise my game has good graphics. These are test graphics.) This tool to make level creation easier is another thing that makes an NES game take more time. Because if I weren't making an NES game, I wouldn't need to worry about all these layers of metatiles. I wouldn't need a custom tool to make and compress maps. I could use Tiled. Even if I did write a custom tool, it would not be as hard to write. I couldn't even like... re-use this tool on another game. Everything it does is very rigidly linked to my current game's structure.

Isn't that pretty cool?

Like I said, I'm not pessimistic about my actual game. I LOVE it! If anything, I'm pessimistic about the process. I just think NES homebrew glamor wears off once you really start, and am providing what this is like as a dude who has done it for a while. This topic needs some realism.

It seems like your game has quite a lot of its programming done, by your list. Remaining would be the music and boss (maybe enemy?) AI, and maybe a few more objects, such as a level exit (if you have discrete levels) and a checkpoint (even if you don't).

Realistically, that's a lot! A "few" more objects will end up being at least 40. (Probably even more than that.) Count the different enemies in Kirby's Adventure. In the average Megaman game. Add things like the star Kirby rides, and robo dog spring powers in Megaman. These are not enemies, but they are objects. There's a lot you may not be considering.
There will probably be at least 8 bosses. That need graphics. (Well, one boss is partially animated.) And code! Cutscenes to lead the worlds into each other I need to program. Dialogue needs to be written. Even though I think time spent on not code is tiny compared to the time spent on code for this game, it's still stuff that has to be done.

Last month, I'd have said, "There's still no end in sight." for my game, even with all that stuff done. This month, there's an end in sight since soon I will have my first levels and the beginnings of my first boss. But the end is still very fuzzy way out there by the horizon line.

tl;dr when your game engine is done, you're not NEARLY done. Even when your game is playable from start to finish, you're not really done. Those statements are true for all games, NES or not.

However, the level design can almost wholly be done independently of the remaining programming,

Designing without the whole is usually not a great idea. The one level I have? Its flow is broken because I recently changed the player physics. (They're now final, though. That one level confirmed my suspicions about something that needed changing.) If I made a level designed without the objects contained within, adding them would break the flow. I don't want an enemy in the way to halt the player until they kill it like Megaman or a Beat 'em up screen lock. I want my game to have a platforming flow the way a Mario game does. This is why I have so many test levels, before I commit to real ones.

Similarly, the graphics and sound are a bit more dependent on level design and "programming" considerations (animation, banking, space) and "hey we want graphics/music for a forest level".

Music can go in its own bank, because nothing but the music player ever needs to access it. Sound is cool because I can make the entire game without it and add it at the end and that's fine. It's the easiest thing to edit, update and replace. (Not saying it'd be easy to make a replacement song, but once a replacement song is made it'd be in the game on the next export. No change of code, or even script.) It's the reason I haven't bothered yet. It's true that occasionally one times a cutscene to music. If I needed that, I'd make a control code in the song that causes a cutscene event. The new song would just need to put that control code in the place where the event is meant to trigger. Even TEXT will generally be harder to change than music for this particular project. Enemy animations are behind music and text. Deciding a tileset needs to be changed after levels are built can be really, really tricky because you need the same structures, and you need to update all your metatiles. (and in my case, my meta-metatiles.) This can be easy, but for me on this project, it's hard.

My level editor already handles banking mostly automatically. If I run out of space in a bank, I have to copy the sets it uses to a new one, which only takes like 10 seconds. But all 46 of my test levels, fit in slightly more than 8KB. One level is 3840x2304 and another is 16128x256. Most are smaller, but I am very unconcerned. It took forever to write an editor that conveniently exports this data, but that's all behind me. Like I said, I'm pretty sure most of the truly difficult programming stuff is behind me. That doesn't mean there's still not a lot of game to make.

The game will absolutely get done. There may be better ways to do what I'm doing, but I'm certainly no slouch at this.

My impression of small game projects is that there is almost always a programmer, a sound person, and a graphics person. One of these usually is the designer of the concept. Occasionally you get wizards like the man behind Super Turrican.

I'm not the only one-person dev team. My favorite one. Check out The Iconoclasts demo. He made a tweet I identify with about that game. You might actually be surprised just how many solid games are made by one person. But this topic does not deal with small game projects. Not in the least.

@Kasumi: I understand wholehartedly where you are coming from, and your post raises a few issues; specifically the implementation of more complex stuff. They do take a long time to create, so why shouldn't the effort be split between several people?

I must be bad at stating the key points I want to make. If you pay one person full time to do something in 5 years, you're down that much in cash. If you pay two people to do something in 2.5 years, it costs the same amount of money, sure. My point is that no matter how many people you get, the money would go further on a faux-not-real NES game. My posts are not saying, "What I'm doing is not cost effective, but it would be if I had more people to get done faster" They're saying, "This is not cost effective."

One guy does the scrolling, the other does the dialog boxes, something like that. It might be difficult to merge the 'games' together as they both might've altered the game's core code to make them work, and be ultimately incompatible with each other. In some NES games, it seems like it wasn't uncommon for the credits to list certain people with seemingly arbitrary tasks; I wouldn't be surprised if there's an NES game that credits some "Erasher Shigami" for being responsible for the "scroll engine".

For the record, this is still true in C. Easier in C because it's significantly easier to avoid overlapping RAM. There's no fighting for fixed bank space... which woah, I never thought about as a solo developer. But man... it would not be fun trying to make new stuff with another person on the team when the fixed bank was nearly out of space.

What's to stop me from, hypothetically speaking, hiring Miau to make the base game, and hiring that Japanese guy to program the overhead shooter stages? Probably memory constraints, or data sharing, or both.

Your total lack of money, realistically speaking. I understand the sentiment, I do. If someone wanted to pay me to make something I'd be pretty down if it was a fair wage. But if you have nothing to offer, everyone who is good at this has their own thing they may as well work on if they're not going to be paid anyway. Plus all of Koitsu's points. (Both he and Tepples AND you responded as I writing this epic. I was originally just responding to Myask . )

If you're really into this, and win the lottery tomorrow to fund it, I'm not saying don't do it. I'm just saying here be dragons, take note.

I don't want to be the rain cloud, nor have it all be about my game. It just seemed a good idea to post about it so people could get an idea of what could be done in how long by someone who is actually pretty good at this. That's what was asked for.

For example, speaking personally, I would refuse #2 in every way/shape/form because what that would do is turn a hobby/something for fun into basically a job/form of work, and I segregate those two things. I promised myself back in the early 90s I would never turn any kind of hobbyist gamedev into a line of work or involve money in any way, and I've stuck to that promise (and I know quite a few people who did go into gamedev professionally and now regret it; "it no longer has the same feel to it").

Hah, this pretty much resonates with me. My goal with this game is more personal than "become a professional game dev", but the idea that it might sell does keep me on track.

There are many thoughts related that I suppose I won't post. But video games are already ruined for me, the way becoming an animator ruins animation the average person sees no problem with. I do wonder if becoming "professional" could possibly make it have even less of a "feel" that it already does, heh. At the moment, I feel held back mainly by NES. It might be fun to join some small indie game team using C++ and be amazed at how I can just... GO! As opposed to my game crashing right now because I added tile animation to the map editor. So the NMI changes which bank is being written to. So if a frame takes too long it will swap a prg bank index into CHR instead of PRG and then crash when trying to go to a routine mapped in that PRG. Yeah... I know how to fix it, it's easy, but I haven't.

One of the cool things about being solo... if I get frustrated with programming, I just move on the graphics. If I was a career programmer... nope, couldn't do that. And all of the bad things about being solo: When I'm not doing it, it's not getting done. Can't take a nap, and see some progress on a tileset for your pixel art guy. But now I'm very far off topic.

Sorry for the book. That's why I didn't want to post at all.

Edit: For the final point... A lot of my points become non points if you are not making something so damn ambitious. Fighting for fixed bank space is not an issue when you're making an NROM game. If you don't scroll/update the background during gameplay this removes a significant amount of coding hassle.

With none of the above, it's only slightly harder to make the game on NES than PC. BUT! The hardness increases an EXPONENTIAL amount for NESdev above the non exponential regular hardness step increase of a PC game for each of those things you might want.