What do we want in a tutorial?

[tokumaru]

Or just put "you need to be able to run Windows programs" in the prerequisites and let those people sort it out.

That's probably the most sensible solution. No need to waste time rewriting instructions for a step that's probably already documented elsewhere. Linking to such instructions would be enough.

I think we can safely assume some minimum technical background.

You'd be surprised at how many people don't know what a command line application is, and come here claiming that the assemblers they're trying don't work because they open a black window that instantly closes.

I mean, I'd also advice that anybody who doesn't have at least some minimum game programming knowledge to stay away from NES homebrew because otherwise they'll make way too many mistakes

Learning game programming concepts at the same time you're learning assembly and computer architecture is indeed a tough task. It's not impossible, it's just harder. In general, I think people underestimate how long it takes to get good at this. I started in 1997 (with game programming, NES came a bit later) and I still learn new stuff all the time.

[tepples]

if there's one thing you can leave out of the package, it's emulators. If someone is attempting to create an NES game, I think it's safe to assume they know how to install an use an emulator.

Just because someone can install an emulator doesn't mean he can 1. install specifically a debugging emulator or 2. trigger the emulator to start after a successful build. How should we expect the user to provide the emulator's path to the batch file?

And in order not to sound too buddy-buddy with Microsoft, we're going to have to come up with some believable wording to explain exactly why we are relying on Windows executables. Besides, a particular build of asm6 or png2chr is itself "not commonly downloaded", and the Python installer signed by Python Software Foundation would probably score higher on SmartScreen's Application Reputation feature than an uncommon executable that is not signed.

[Pokun]

I'd try to make it as compatible with PPMCK as possible to avoid inventing new standards.

I'm just afraid of the inefficiencies that I might have to introduce into the converter in order to abstract over differences between the data model of PPMCK and the data model of my music engine. Or are you instead recommending that new music engines be designed around the quirks of PPMCK?

I guess format incompatibilities between different sound engines is unavoidable, and I don't think sacrificing efficiency for compatibility reasons is a good idea for a sound engine (PPMCK isn't designed to be small and fast unlike NSD.Lib). But you ask what kind of syntax to use, so I suggest to make it as compatible as possible to current popular formats in order to make it easier for people to convert their songs to your format.

Because FCEUX is GPL, distributing FCEUX ourselves rather than relying on the official download site would require mirroring FCEUX's source code as well.

Ideally, everything would be included in a single install file (I, particularly, hate this approach, but I think the novice NES programmer would appreciate it), but if there's one thing you can leave out of the package, it's emulators. If someone is attempting to create an NES game, I think it's safe to assume they know how to install an use an emulator.

I hate having to use installers for every little program that really doesn't benefit from them, and I avoid them whenever possible (that's why I preferred to not use Python at first).

I'd also advice that anybody who doesn't have at least some minimum game programming knowledge to stay away from NES homebrew because otherwise they'll make way too many mistakes

Learning game programming concepts at the same time you're learning assembly and computer architecture is indeed a tough task. It's not impossible, it's just harder. In general

Of course it's easier if you already know game programming, but the first time it's going to be hard anyway so they might as well learn it on a platform that interests them.

[Sik]

You'd be surprised at how many people don't know what a command line application is, and come here claiming that the assemblers they're trying don't work because they open a black window that instantly closes.

Which probably means they still have a lot to learn before they should start learning NES development.

And in order not to sound too buddy-buddy with Microsoft, we're going to have to come up with some believable wording to explain exactly why we are relying on Windows executables.

If you're so worried about that then shouldn't you also be worried about being too buddy-buddy to a particular emulator (something that tends to lead to "religious" wars as people tend to attempt imposing their preferences on everybody else), or too buddy-buddy to a particular tool? Seriously, I believe that you're overthinking this.

If you want to teach people how to use a tool and that tool happens to only be readily available on Windows, then that means you should tell the person to find a way to run those programs, and if you don't like this, then you should find tools that are readily available elsewhere to avoid the issue in the first place. It sounds like your problem is that you want to avoid coming out as being Microsoft friendly.

Also chances are that somebody developing on Linux or OSX is more likely to have a good technical background out of necessity because they're using less common (and thereby less supported) platforms.

[tepples]

You'd be surprised at how many people don't know what a command line application is, and come here claiming that the assemblers they're trying don't work because they open a black window that instantly closes.

Which probably means they still have a lot to learn before they should start learning NES development.

Which in turn is why I created a list of Wikipedia articles on general computer science topics that people ought to know first, so that I could cite it in a tutorial.

If you're so worried about that then shouldn't you also be worried about being too buddy-buddy to a particular emulator (something that tends to lead to "religious" wars as people tend to attempt imposing their preferences on everybody else), or too buddy-buddy to a particular tool?

The emulators, scripting language interpreters, and the like are free software. Windows is not.

It sounds like your problem is that you want to avoid coming out as being Microsoft friendly.

Correct. If I wanted to be Microsoft friendly, I'd skip the NES tutorial in favor of a DirectX tutorial and encourage people to develop games for the Windows Store in the hopes of applying for the ID@Xbox program.

[psycopathicteen]

Yeah, this. Or maybe for something more complex, a shmup that has player, bullets and enemies (no background or scoring or whatever, just a barebones one). In any case it would be way more useful in order to get started understanding how to make games on the NES.

I like this idea.

[mikejmoffitt]

It might be good to provide a shell script to install dependencies, and even offer to curl/wget/whatever other necessary requisites are for the user. You would have to give the script some sensitivity towards the type of package manager being used, but if you support apt and yum you are already supporting a majority of the tiny Linux minority. A similar batch file for Windows users would be helpful. If you want to support Mac users, then yet another script can help.

I don't think this is an appropriate opportunity to care about how friendly you are appearing to Microsoft. Windows is not free software, but more or less everything involved in the tutorial is. Furthermore, people aren't going to go out and buy or pirate Windows because the tutorial told them to. Chances are most readers of the article already have Windows. It is difficult to find a computer that does not come with some license of Windows. You have to go out of your way to not own Windows with a store bought computer. If you want the tutorial to reach people, it is best to make it platform agnostic, or at least reach as many people as possible.

If you want a kitschy all in one solution, you could make a small ready-to-go VM image with a basic Debian install ready to go with everything set up. All you'd have to do is help people install VirtualBox at that point, which I'm hoping is free enough to scratch the FSF itch.

[psycopathicteen]

A "how to make a shmup" tutorial would work like this.

Part 1: Initiating the NES, and displaying a color.
Part 2: Objects and Sprites
Part 3: Moving Objects
Part 4: Collision
Part 5: Spawning and Killing Objects

[Drew Sebastino]

That's actually the order I've found myself doing things, except I've been working on vram crap that you don't need to worry about on the NES.

[psycopathicteen]

A shmup would be easy because everything can be in screen coordinates, and the scrolling would be implied.

[Sik]

Don't forget the biggest advantage: the end result will resemble (even if barely) the kind of games you could expect to see on the system, and will teach you enough to get an idea of how things work in a "real" game. This helps build up confidence really quickly, which will mean more people will stick around instead of giving up early.

[Memblers]

I remembered an idea I had a while back, that I haven't thought of for a while. For the Garage Cart series, one of the things I wanted to have on it was some kind of NES programming tutorial or reference docs that would actually be displayed on the NES itself. It's less about practicality, and more about introducing the topic to a different audience.

[mikejmoffitt]

What would be really neat is an interactive prompt on the NES. It would be great if a user could just POKE things into OAM parameters or the tile map and watch it change on the NES to make it very clear what different registers do. A very clear annotated showcase on the NES, something like "this is what the screen looks like with red tint on" and then of course the red tint bit is set. There is a small example like this for the Genesis, showing some VDP features.

[Kasumi]

I've actually considered making an interactive rom like that to explain the restrictions to pixel artists.

[tepples]

You could have pixel artists try my background graphics editor to explore the limitations.