Tools for NES dev wish list

Totally hypothetical question - What would be the one or two tools you wish you had that would make NES dev far easier and faster?

1. Linux everything. Nametable editor, graphics editor, assemblers, emus, debuggers with emus, etc.

NES ROM Maker FTW! Can't get any faster than importing some MP3s, loading up a game template and running the amazing bug catcher (TM)!

A social network to bring together artists, programmers, composers, and play testers.

Efficient easy to use of HLL that was adaptable to any mapper via some sort of plug-in definition that would also work in an emu.

Most things already exist, although there are some more things I would be interested in.

One thing I would want to add is a way to define your own mappers and input devices for an emulator, by writing in C or in Verilog or something, and then loading it as a plugin. (Only source compatibility is necessary though; not binary compatibility.)

Another thing would be a simple music engine using MML (one more suitable to making a game than ppMCK is), compatible with expansion audio (only up to one is needed, since it is a game and not a NSF), compatible with MagicKit assembler, and can use hardware features and so on making speed up, so many of the ppMCK features can be omitted. I might write such a program.

The feature of ENSATA to reload the ROM image would be useful to have in a NES/Famicom emulator.

The completion of my mapper list in the wiki would be very helpful.

A general purpose level editor/converter could also be a good idea.

A feature of an emulator to randomize initial RAM and mapper and other things, as well as checking for bus conflicts and undefined, could help in order to check for some errors.

Autotest feature could also be useful.

Software which is cross-platform would be good ideas. This is what I do; I write a C program, using the command-line mode or using SDL, in order to allow it to work cross-platform.

Perhaps this forum, wiki, IRC, can be used? Make up some area for that if what we already have isn't suitable.

So, in other words, there would actually be a lot of things, not just one or two.

1: ASM6-compatible Cross Target Assembler for 2a03/6510/6502/6507, 65c02/Hu6280(PC-Engine), and 65816 (also with Customizable Opcode Table support)

NOTE: CA65 is hard for most people, So #1 is part of the wish list.

2: a better, faster, extendable IDE to go with the above, Support Plugins for use as multiple types of consoles (NES, SNES, etc.)

3: a better NES and a SNES Music engine and toolset combo, like SMW's Addmusic MML compiler, but usable for hacks along with SFX support based off of Addmusic, uses equal or less then one page plain BSS RAM (example, $7xx) and $10 bytes or less of Zero Page RAM

Oh dear, I'd never seen this before... wow, um... *keeps mouth shut*

Oh this is one of the things I've wanted to make for several years. Pehaps I'll take the time to do it some day.

I think the Atari 2600 has had a great revival in part from batari BASIC. Coding is not a rite of passage but an art form. We need more types of people making more games.

If I could I'd use the same strategy as batari BASIC here on our NES.

Agreed, But in order to do so, Someone has to rewrite everything to be ASM6 compatible, and use NES features!

1. Newer versions of Nesicide building on GNU/Linux systems, as that's the only one where I could get a working USB->serial connection for my powerpak
2. A more optimized emulator in Nesicide, so debugging becomes more feasible on my slow laptop

Not having worked for an authorized Nintendo DS developer, I'm not sure what this feature is. Is it the same as being able to save state, relink the ROM file, and load state?


That depends on making these non-coders aware of this forum, plus possibly repository hosting for retro game projects.

Neither have I, but I did see it once for some reason I cannot remember (and it isn't a very good emulator unless you are working for Nintendo, anyways). The feature is that if you push the "RELOAD" menu or toolbar icon then it will restart but also reload the ROM image from the file, instead of using the copy in the emulator's RAM.

FCEUX for Windows and any other emulator with a "Recent ROMs" menu sort of has that. Choose the first item to reload the ROM from the file and power on.

The other way to deal with this, the way I've tended to use on my Xubuntu laptop, is to have an emulator that either starts quickly or doesn't allow multiple instances. This way you can close the emulator, recompile, and have your makefile build the ROM and then restart the emulator.

I really need a dedicated Linux machine for this. Every time I attempt to get anywhere with Linux builds of NESICIDE using a VM something goes wrong.

Number one on my wish list is a mid-level language that compiles to clean and reasonably efficient machine language and supports banking. I'm working on that now

My other big item is a generic level editor. Kind of like Tiled but with different options. I keep threatening this, but never built one. Mainly because Tiled plus a few Python scripts gets me where I'm going.

I'm not entirely sure how feasible a "generic level editor" would be, especially for games using an object-based level data format like that of Super Mario Bros., Super Mario Bros. 3, and Super Mario World.

Come up with a format that is agreeable to most game types. It might not be the most efficient solve all format, but for anyone willing to accept the 'generic format' could then use the 'generic level editor'.

The generic level editor I envision would be more like generic for a given genre. The output format would be an easily parsable, human-readable format that you would then process into whatever format you want. Tiled gets the job done pretty well, just takes a bit more supporting scripts and a bit less tool integration.

Any editor that can only handle one type of encoding for levels, no matter how versatile it is, will fail to gather interest. The NES is a pretty limited platform, so most of the time the data in the games is very customized, so that each game can get the best out of ROM/RAM/CPU. On the other hand, an editor generic enough to handle all possible cases (grid-based vs. object-based, different metatile sizes, metatiles inside metatiles, etc.) would be insanely difficult to code, and would probably still fail to meet everyone's needs.

After some thinking, I decided that the most realistic solution would be an editor with a grid system and an object system, that outputs 2D arrays for grids and attribute lists for objects. The different formats would be handled exclusively by scripts (basic/common ones can come with the program, but everyone is free to write their own). Some features could be present in the editor to aid in the creation of compression-friendly maps, such as the ability to copy/paste variable-sized blocks (optionally aligned to a grid) or the option to automatically alter other regions of the map that look the same as the one inside the grid you're editing.

Building levels out of objects will be hard because the attributes of the objects need to affect how they look (e.g. how long a platform is), and even though it's easy for the editor to store custom parameters (e.g. an enemy's strength), it's pretty much impossible to customize how these parameters will affect the visual representation of the object. In this case, to store maps similarly to how SMB does it, I believe it would be better to draw them using a grid and have the script look for ways to compress them using objects. The script would be pretty complex compared to typical grid-based map compression, though.

Why not make a very easy scripting tool to parse the raw level data into a useable format for your game files? Or, just have it very easily doable in C, AKA not using C++ crap and making sure your code is heavily objectified and uses very few globals that it needs.

Plus, getting around the enemy encoding, you can have two planes. One a tile plane, one an object plane. They're need to be parsed in to one which'd be difficult, but you only have to write the tool once.

My own ideas for a general purpose level editor is one that doesn't use a limited format. It would have sufficient features (tiles, sprites, and other things), and then have a script to extend it and to make the format. (It can then be used for things other than NES/Famicom too, although it may have some features which are specific to NES/Famicom such as the pattern tables, name tables, sprites, etc. It could even output the proper assembly language codes, whether it is MagicKit, ASM6, etc.)

I might make such a thing in future; I have some ideas how to do so! (If someone else want to make, you can do too, of course; we can see who prefer what. I would probably do it with C, SDL, SQLite, and MagicKit, and it would use some vi-like commands and mouse-chording; but someone else might prefer something entirely different.)

It's a small miracle that a free level editor as flexible and well designed as Tiled exists at all, so I'm not holding my breath waiting for a (good) NES specific editor to show up.

Really I just wish there were an easier way to define custom objects for Tiled. It's not impossible, and it's pretty easy to work with anyway, which is why I said above that Tiled and a few Python scripts gets me where I'm going.

Can Tiled do NES palette attributes?

If it doesn't, which I'm pretty sure is the case, you can probably get around that by making 4 copies of your tileset, one with each palette, and chain them together. Then, when converting, you can use the highest bits of the (meta)tiles to create the attribute data.

This is exactly what I have done in the past. I use a script to generate the tile set from my metatile data in the ROM.

Another way, that I used in STREEMERZ, is to define a palette set, and then use a tool to map each tile to that palette set. In some cases this can be problematic, for example if certain palette entries have special meanings (the solution to the mapping problem isn't unambiguous).

Yet another way, probably simpler for a completely new game, would be to add the wanted attribute in the Tile Properties (each tile can have as many individual properties (strings) as is needed). This will of course only allow one to specify the attributes on a per-tile basis, not for each individual metatile in a map. One way to get around this is what tokumaru mentioned, other is to have a separate background layer with 4 specially colored tiles, the tile index can then be used as the attribute data when doing the conversion from TMX (the Tiled file format) to custom format. It's not quite as visual in the editor as tokumaru's method though (the view is not what you'll get in the actual game).

Another pointless drive-by comment from koitsu: I initially thought this said "The geriatric level editor ...".

I'm not entirely clear on what this even *is*. But from what I can tell after under 5 minutes of reading it, it appears to be a bunch of wishful thinking.

It's a "project" from this delusional guy that thinks that every crazy idea can become real with "just a bit of coding". He doesn't understand how things work and keeps treating his theories as if they were facts even when told by more experienced people that they don't make any sense.

I have shortage of words to express how much I'm fond of this approach.

Tell them that it might easier to attract programmers if the project lead can provide a detailed specification and mock screenshots showing exactly what steps users would take to create a game. For example, a spec would show whether it'd look like The Games Factory/Multimedia Fusion, RPG Maker, Game Maker, WarioWare DIY, or something else.