tokumaru wrote:
clueless wrote:
We have MUCH better dev tools than they had in the 80's.
Don't forget more knowledge about the platform. I'm pretty sure that developers back then were tossed into projects with little more than poorly written manuals about the PPU and APU. We have been studying the NES for years, and know a lot of details that programmers back then didn't.
Very good point. Although, I would have assumed that Nintendo's in-house dev teams would have had a direct line to the hardware engineering team...
When I was in college ('94-'99), my first semester programming class was taught by a really (40+ years) tenured professor. This guy was sharp, but an old fart. He tried to impress upon us that when he was younger code was manually encoded into punch cards. You only got one run per day on the shared main-frame to test your code. You _HAD_ to get it right really quickly, and without the benefit of debuggers, single-stepping, profilers, ICE (in-circuit emulation) or any of the tools that we have today. Back then, most developers poured over their code in print-outs, running it in their heads and on paper.
Fast-forward to the late 70's when developers were creating Atari 2600 games. Testing a game was time-consuming (burn an EPROM or use an expensive device with dual-port ram called a 'frob'). There was no easy way to "printf()" on the 2600 (maybe play sounds to indicate calculation results I would guess...) And the 2600 is much harder, imho, to code for than the NES. But those guys created some really intricate games. ET was written in 6 weeks. I think that Adventure took 6 months, I could be wrong though (I read Warren Robinet's interview on this once, a long time ago). Some 2600 developers had access to a 6502 simulator that ran on a PDP-11, but I don't recall whom it was.
By the time the NES was out, one could test non-hardware specific 6502 code on a variety of home computers.
Imagine how we would change our development habits if we didn't have emulators to test in. It is so easy to load a ROM image info FCEUX, set a break point, fire it up and examine the machine state. I'm totally spoiled doing this.
We have a large amount of docs, knowledge, a huge pool of fellow developers to collaborate with and really good tools.
I don't have an interest in making a SMB-like game, but I'm confident that several people here could do so given how much better the total developer experience is for us.