This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Famicom Party: Making NES Games, 1985-Style

Famicom Party: Making NES Games, 1985-Style
by on (#232673)
I came across Kevin Zurawel's book on NES development, Famicom Party. I believe it's still a work in progress but I enjoyed the chapters I read.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232730)
Looks interesting, but I was really thrown off by the "1985-style" in the title.
I was interested in someone trying to replicate the actual process of the time, but instead it's a modern setup on a PC with emulators and stuff, like we all know and love. :P I guess it's making NES games, 2019-style.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232800)
Sumez wrote:
it's making NES games, 2019-style.

Heh, totally. I wonder what 1985-style really was like!
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232807)
Heh, totally. I wonder what 1985-style really was like!

Probably horrible? Waiting for programs to assemble, limited storage and fiddly storage media, limited or no multitasking, no wysiwyg, no emulation, having to program ROM chips, no or very rudimentary graphics and sound/music software.

Once they started using separate designers and artists around that time, drawing levels and characters by hand and leaving it for a programmer to punch the numbers for each cell doesn't really encourage making the most of the system and will force your design to be minimalist to help workflow, factoring in memory constraints of early mappers/no mapper.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232808)
Didn't the NES have dev cartridges they could program instantly when assembling from their work stations?
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232809)
Not sure I agree with the above assessment; you're comparing things that exist today to things that didn't exist (or had not even been considered / were unfeasible) in 1985. It meant that then-available solutions and approaches were simply different because of what technology existed then. The tedious nature of what needed to be done by artists and musicians then (especially stuff like this; enable CC please) was often par for the course; we have interviews and magazines from that time period that explain the process. I can't imagine anyone at the time said "man this sucks, I sure wish we had 4GHz CPUs and 4GByte/sec storage and multitasking OSes and emulators!" because they had no idea of what the future held. It was probably more along the lines of "I sure wish I had a tool that could generate these waveforms easier" (and someone internal to the company would probably design one, barring time limitations). No multitasking? Many artists/musicians/developers had multiple computers on their desks for that very reason. I think a fairer assessment would be to wonder how things were in 1985 compared to, say, 1951 (34 years -- the same amount of time between 2019 and 1985); ICs in general were certainly a pretty major breakthrough in comparison to, say, systems still using literal vacuum tubes.

That said...

The NES/FC certainly had to be one of the more annoying systems to develop on/for (compared to, say, arcades, where the companies were responsible for designing the entire system and picking/choosing what ICs they wanted. They knew the systems cuz they designed them, or could wander over to the PCB engineers desk and ask questions) because Nintendo wasn't known for giving great documentation or toolsets, and it was also their first time stepping into the video game console industry (which was a huge gamble considering what happened to Atari). In contrast, arcades had been around for a while (since the late 70s) and had time to "mature" -- the NES/FC was fairly new, with only a few previous systems (the Odyssey and "home Pong" systems, followed by Atari consoles; consider that Sega's SMS wasn't released until 2 years after the Famicom). You now had a system that was pre-made on a very tight/strict budget (see above, re: a gamble), by a company with no previous home video game console experience, giving you limited documentation. My point is that it was a whole new era, but the technology was better than it was in the 70s.

The processes you described sound akin to what it was like doing reverse-engineer and homebrew stuff for the SNES in the super early 90s. Really. I can't remember ever saying "gosh, I sure do wish I had an emulator with a debugger and a multitasking OS and...". I do, however, remember wishing we had better tools -- but the testing model (if you had a copier with a LPT port wired up properly for ROM transfer) was way better than dealing with EPROMs, that's for sure. (Nintendo's SFC/SNES devkits apparently could include some form of hardware ICE, but I don't know how helpful that was at the time.)
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232810)
Worth noting is also that Nintendo never intended for anyone aside from themselves to release games for their system, so at the time it wasn't directly comparable to the Atari 2600.
Of course, by 1985 this had already changed completely, with companies like Hudson and Namco having joined the fray the year before. It makes sense that Nintendo didn't initially have any focus on supplying thorough dev tools and deocumentation to licensed third party developers.

That said, I agree with Koitsu (even if this is mostly just speculation on my part). Computers weren't total crap in the 80s. They just didn't have an insane overhead of doing a bunch of other stuff useless to your process. Especially working in an actual software engineering company with a real budget, as opposed to being a bedroom developer, you'd assume the programmers had access to multiple powerful computers and other hardware for quickly testing out their code. The NES itself wasn't exactly state-of-the-art for the 80s.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232811)
I'll never accept that developing for the NES now is just better. Where are the new ninja gaiden 3s? Something is missing, and I don't think it's just that they did it as a full time job.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232813)
Experience, full time focus, a supporting work environment where everyone is working towards the same goal, as well as the spirit of the time (ie. Ninja Gaiden 3 was a "mainstream" game, not a niche title for retro action enthusiasts).

It's hard to believe the quality of the games back then had anything to do with their tools. Though usually I'd also say the quality has more to do with the games' overall design than just the programming job.
Even in modern indie PC development backed by super powerful engines, there are very few games able to match the likes of Ninja Gaiden 3. :)
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232815)
I wonder if there are any good articles out there with the actual 80s setups used for 8-bit console games?

I know there's the one with HAL, showing pictures of the tools they used for Kirby's Adventure, but it's kind of superficial. I'm more interested in the hardware, and the technical side of things.
Most internet discussions regarding the subject tend to fall back on how assembly programming for these consoles works - stuff we are all very familiar with as it is. :)

I did come across this Reddit post from an old Interplay employee though, talking about custom hardware created at Interplay specifically for the purpose of NES debugging: ... n/d03j3ro/

I would love to see an authentic contemporary NES debugging setop in action!
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232816)
koitsu wrote:
I sure wish we had 4GHz CPUs and 4GByte/sec storage and multitasking OSes and emulators!" because they had no idea of what the future held.

Oh, i completely agree with this, and for the record, i began with dos and qBasic, so i have no genuine experience. Remembering those days, i do miss the focus you had when all you had in front of you was one or two fields of text editing/referencing with no background services tugging at your attention or requiring a reboot and general, online-ness keeping your mind scattered.

I should've clarified: Probably horrible (..."if i were put in that situation, knowing what i know now and having the tools i have now"). But of course, if i compare to what my grandma reminisced about cobol/fortran programming - that she examined the hand-written code for bugs thoroughly before compiling since terminal access, storage and time were severe restrictions, making games in 85 ought to be a relative breeze. Then again maybe it's comparing pears to apples, the kind of stuff she did was database, statistics and equations. No artistic effort required, no fancy yet quirky hardware accelerated graphics and sound that raise the expectations of presentation, and so on.

But if you're writing, say, a zx spectrum game, also written on the zx spectrum, of course you were limited and probably frustrated atsome level by the limits of work RAM, columns/rows on screen or even the rubber keys. I think people quickly forget the everyday tedium of past times. Like how people forget the tedium of waiting in line to be paying the bills at the local bank office before internet access/auto transactions.

As for Ninja Gaiden 3, he homebrew scene has a difficult time with these things:

1a)all of the skillsets required housed in one person, or
1b)all the time to acquire it, and
1c)all the time required to make the game


2a) a team large enought to cover all bases
2b) a designated project manager to make the work of the former members strive towards a common goal and cohesive end product.

We're beginnning to see more complex and ambitious games when there's teams of 2-4 people. But for most, it's something you do at economic loss/as a hobby.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232817)
nesrocks wrote:
I'll never accept that developing for the NES now is just better. Where are the new ninja gaiden 3s? Something is missing

What specifically is missing from games like this?
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232819)
HH86 is exceptionally well made! Tim contacted me and was really kind to give me a steam key for it. This is what I told him at the time:

"I played it a bit, until gameover. The game is great, I had no idea! Very funny and the programming is top notch, I'm really impressed.
The graphics are very creative and unusual, congrats on that :)
Great character animation too"

This is something I told Macbee about it:
Me: "I've played it, I thought it was really well made. Got a gameover because I didn't know a few rules/tricks. I just watched Brad Smith playing it so I'm going to try it again later. There are some very nice parallax effects in the cavern."
"Macbee: "Yeah, there's lots of moves, I thought that was great too"
Me: "Tepples programs so well"

I promised Tim to try the game again but I guess I forgot about it with xmas and new years etc. I have now replayed it twice while writing this. I will add that the OST is also very nice.
For criticism, the first thing that made me look for a "what do I do now video", was that you need to jump to destroy the wall inside the room at the first minutes of the game. I understand there was a previous instance where there was a need to destroy a wall, but since it only had happened once, I think it wasn't yet established that the player is expected to break walls at dead ends. It's something that's hard for developers to notice ("of course the player has to break the wall"). The other thing is that I didn't know you could double jump.

So, as to not derail this thread into a HH86 discussion and keeping it in topic but still making a comparison, I think the thing is, these companies used to make the "same game" over and over. They didn't spend a lot of time thinking about the game design, they made one game after the other and implemented slightly new/better ideas in the next game. I think maybe that's what's missing. It's not so much that they had a full time job to make one game, it's that that was their career. They made countless games, sometimes just 3 months apart. It's particullarly apparent in interviews when they don't recall much about making games we consider now masterpieces, because for them, it was just tuesday. The games were masterpieces because through iteration they honed the game design of it.

For example, in HH86 I couldn't understand how to attack the golem boss in the cavern without getting hit. I couldn't beat him. I am probably missing something, but what it feels like is that the boss doesn't exactly fit the player's moveset as an appropriate opponent. So is it just "NES hard"? This may be a deeper discussion about expectations: should a NES game designed today be designed for today's audience or as something that could have been released back then? But I don't think it's the case, really. I can discover old NES games that I had never played before and still love and beat them, the last one being Konami's Rollergames. Nothing in that game left me wondering "how do I do this" or "what's going on". The game is not easy, but it is simple and direct, and still a lot of fun.

One thing to note is I might be biased into classic game designs. If I hadn't played a lot of Konami beat-em-up games before playing Rollergames I might not have enjoyed it as much. Maybe it felt familiar because of that. I can't be sure. All I know is that as a game designer I know that I'm prey to developer's point of view pitfalls so I try to put my games into test sessions whenever I can (so far managed to get too few of those). Because I haven't been making the same game for years, my game has problems communicating how I expect it to be played. It's definitely not easy to make something different. So I feel bad for criticising because what you guys did is totally awesome. I'm trying to put into perspective how we can all move forward.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232908)
Wait! Tepples programmed HH86?
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232909)
Sumez wrote:
Looks interesting, but I was really thrown off by the "1985-style" in the title.

Yeah, the title threw me off too. Other than that, this looks like a great introduction to NES programming. With luck we'll soon have something better than the Nerdy Nights tutorials to refer newbies to.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232911)
olddb wrote:
Wait! Tepples programmed HH86?

Yes, and its prequel + other titles. I believe he was contracted (read: paid) to do it, but that doesn't really matter (if anything, just goes to show there's still a market for such programming work, even now.)
Re: Famicom Party: Making NES Games, 1985-Style
by on (#232997)
If I'm doing programming work, even at my day job, I basically run VS Studio and maybe the email client, and the debugger. That is about all I need to actually do my job. Back in the 80s I wouldn't have had an email client, we would have just talked to each other, but seeing as the game team was 8 people for a really large team, not such an issue. Back then asm code editors where not that complex so they didn't take ages to load. That being said the Amiga 1000 brought us Multi-Tasking in 1985, although most people think it is something Windows 95 bought the to the table. But you could also get OS/2 that would let you multitask Windows 3.1. I think SunOS was multitasking and SGI IRIX was as well by the late 80s. Assembling 6502 with Macros on a PC is not that slow. I mean when you assemble on a C64 it took 4mins, on a 286 (1982) it took 40 seconds. When a SNES game took more than 30 seconds to assemble I know a programmer who went to IT and said "This game is taking 30seconds to assemble, that is too long, I need the new 486 SX 33" and they agreed and all the programmers got it.

Debugging was not that great. You can step 6502, its kind of slow on actual hardware see the PDS, but then emulating the chip on the host machine became faster. This lets you trap logic bugs, but if a sprite is showing the wrong data, if the bug is caused by timing, or interrupts you just have to stare at your code, make a guess and test it. This is known as Black Box Debugging. Now with emulators you can step clock by clock and see exactly what happens, look at VRAM etc It makes development a lot faster. Back then you would also print out your source code ( it was called a backup ) and sit there with a pen and manually trace it with values to find your logic flaws.

I feel the biggest boost however is the internet. Now I have some random bug, then I can post here, and get feed back, there are in depth docs. If I want to look up some Random number generators or fancy maths I just google it and get a working and tested example to copy paste ;) Back then it was you and what ever books you could afford.
Re: Famicom Party: Making NES Games, 1985-Style
by on (#233887)
Hey, this is me! :D I was going to post something here eventually, but not until I had much more content.

The "1985-style" was intended to mean "using assembly", vs. compiling from C or some other language. I can see how it's confusing, but when I talk to people who have no idea how NES games are/were made, they assume I'm talking about making modern games that look like NES games.

I started learning NES development a few years ago using Nerdy Nights and kinda hated it. I spent a lot of time lurking these forums and reading articles on the wiki, and eventually it started to make sense. Since then, I've given some tech conference talks and workshops. I started writing this book because I wanted to make it easier for someone new to everything to get started - there is a huge amount that you need to learn before you can dive in, and you can pick it all up from the wiki but the wiki doesn't have any kind of "path" to teach you.

I'm planning to eventually work this out into building a whole basic platformer, with MMC3 scanline IRQ and bank-switching, but I think that's a long, long way off. :P

Please let me know if I've made any huge errors in the book, I want this to be as accurate as possible. None of this would have been possible without I'm hugely grateful for everything this community has put out into the world.