Hardware limitations?

I'm pretty new to the scene and I want to create a turn based RPG similar to SMRPG with the timed hits mechanic. I'm reading a lot about NES development and I would love to be able to run my creation on hardware, and I'm trying to narrow down into plain terms what the hardware limitations are so I can draft up sprite work and game mechanics within the limits of the console hardware. Is there somewhere that summarizes the biggest, most common limitations?

Edit: I just found this to be very helpful:

Hah, I was just about to post that. (I also made it )

You can find a more verbose version here: https://pixelation.org/index.php?topic= ... #msg115062

Game mechanics limitations are... harder to pin down? Like, usually, if you're dedicated you can think of a way to do whatever. Even if it's 3Dish (See Elite or Tokumaru's raycaster) And granted, those things come with trade offs, but describing what they are can be hard if you're not already familiar with the system.

I'll say I doubt the hardware will be too big an issue with a turn based RPG like Super Mario RPG. (The way that game handles the overworld would be tougher, but not impossible.)

But if that's not a good enough answer, help us solve a known problem instead of an unknown problem. Rather than "What's not possible?" ask "Is <specific thing> possible?" or "How might <specific thing> be done?"

Edit: Inherent Smile is a game that was entered in one of yearly nesdev competitions: http://nesdevcompo.nintendoage.com/contest17/

And has timed hits/defense.

Edit2: I'll say RAM is usually not the thing that gets in the way, nor will CPU speed for an RPG.

The limit that usually gets hit is space. Like you can only have so many enemies, areas, tilesets. And you can write fancy compression to get more from what you have, but that's extra programmer time. (The answer to how much space is complicated, because NES cartridges can theoretically provide any amount. But let's say 512KB for code/data and 256KB for graphics as a good "max".)

So I'd say NES usually limits the scope of your game rather than the mechanics of it.

Like Kasumi said, it's hard to pin down the limitations imposed on game mechanics, because there are a lot of trade offs you can make. But here are some observations I'd like to make:

In terms of processing power, the CPU is not particularly powerful, and it lacks important operations such as multiplication and division at the hardware level, which means these operations can only be done if synthesized in software, which's slow. Considering these limitations, it's better to avoid complex physics simulations (prefer formulas that require only a moderate number of additions and subtractions) and be mindful of the number of active objects, depending on how complex their behavior is. It's always a trade off with processing power: you can have one or two characters with complex accurate physics (e.g. the players), but then there will not be much CPU time left for other game objects, so enemies might have to be "dumbed down" if you want to avoid slowdowns.

The other big limitation of the NES is memory. It has only 2KB of RAM, which has to be used for anything that's dynamic (static content can be streamed directly from ROM in most cases). Games that must keep a lot of state for long periods can be difficult or even impossible to code. The size of destructible levels (or the amount of destructible content in levels) is greatly affected by the amount of RAM, for example. Extra RAM can be added to the cartridge (8KB is the standard, for a total of 10KB, but some mappers can handle more), but that adds to the cost and complexity of the hardware.

Another important thing to mention is the VRAM bandwidth. On the NES, you can only manipulate video RAM during vblank, which lasts less than 8% of a frame, and the NES doesn't have a general purpose DMA unit that can speed up memory transfers between the CPU and the PPU (there's only one DMA, used to update the OAM - the sprite list), so every time you need to update backgrounds and palettes (and patterns, if using CHR-RAM), you need to do it byte by byte manually, which greatly limits the amount of data you can move each frame. Realistically speaking, with very optimized code you can move about 200 bytes of data each frame (in addition to the 256 bytes of OAM that are transferred via DMA) if most of it is sequential. You can force parts of the screen to be blank in order to gain some extra VRAM transfer time, but that comes with its own complications.

That being said, RPGs tend to be very light on the CPU, because there aren't many complex interactions between characters or against the background. It's mostly simple movements and flashy animations. The low amount of RAM can become a problem for RPGs, if the game is very long and a lot of things in the world change as the story progresses. ROM can also be a problem if you have a lot of content (maps, tilesets, animations, etc.), like Kasumi said.

Thank you for the responses, this is all very helpful and encouraging.

In my case, I'm theorizing an RPG where each character's combat is based around some kind of mini game, so not 100% like SMRPG. For example, a character who has abilities which draw a crosshair on the screen and you have to shoot the enemies opposing you. Still turn based, but with little mini games for skills which determine how much damage/healing/buff/debuff they do.

I'm assuming a lot of the enemies in FF1 are drawn as background tiles as the 4 sprite color palettes are used for the 4 player party members?

You are correct. You can see most everything about what a given game is doing graphically quite easily in a debugger emulator. (Like Mesen, or FCEUX).


In Mesen, pressing ctrl+P will open the PPU viewer. (You can also get there from tools, debugger, then tools, ppu viewer on the new window.)

It will show you nametables (the background map for whatever is being displayed), palettes, sprites, and CHR (the tilesets themselves).

Anything that does not appear in the nametable is sprites.

In FCEUX, it's Debug, PPU viewer and Debug, Nametable Viewer. No graphical secret is safe from the debugger, so you can research any game.

The spells in Inherent Smile are like that, minigames determining the heal/damage boost.

Yeah in Final Fantasy battle mode and in menus only the PCs, the cursor and the effect animation are sprites. In Dragon Quest 1 even the cursor seems to be a BG character and since it uses a first-person perspective, the only sprite is the enemy (so that it can overlay the battle background). Later DQ games doesn't use battle backgrounds so that a combination of sprites and BG characters can be used for enemies to make them more colourful.

In turn-based RPGs in general I guess you have a lot of wiggle room with sprites. The exception is in walkabout mode where you have both PCs and NPCs that may need to share the sprite limitations.

I guess a turn-based RPG also gets away with using software multiplication/division since nothing else needs to be done while the CPU is calculating damage and such. If your game uses a real-time mini-game with moving objects and such, that particular mode should probably be treated as an action game though. But since it's still turn-based I guess you wanted it to play a mini-game, keep a "score" for the player's performance and then use that score in the damage calculation after the mini-game is over. So since each mode is separate it doesn't really make much of a difference performance wise.

Unless you are going to use passwords for saving, you can expect the extra 8 kB cartridge RAM with battery. It can be used partly for saving the game and partly as extra work RAM.

If you want perfectly authentic graphics you can start by seeing what you can do with a program like NES Screen Tool or yy-chr. That will teach you a lot about the CHR table and how backgrounds work.

The NES hardware design made it practical for cartridge makers to include up to 8K of RAM in addition to the memory included within the system, and it was not particularly unusual for cartridges to exploit this. Some cartridges included a battery so that the extra RAM would retain its contents when the system was powered off, and some included more than 8K of RAM, but these would have added to the manufacturing cost (if I recall, each additional 8K would have cost something on the order of $3 or so, with the cost dropping significantly throughout the life cycle of the NES). It's probably not good for a game to require extra RAM simply because the programmer was lazy, but it would be better for an RPG to include 8K of battery-backed RAM and use it to hold the state of the gamer's world, than for it to require that players "save their game" by writing down annoyingly long passwords and then have to re-enter them to resume their journey.

While there might have been some smaller and cheaper memory chips that could be battery backed, I think the market was favoring the 8Kx8 size. Static memory could be made using NMOS or CMOS technology, and in previous years NMOS technology had been cheaper but consumed much more power (and would be unsuitable for battery-back-up applications). As time went on, however, the cost advantages of NMOS chips evaporated. When the NES was produced, 2Kx8 NMOS RAM chips were obsolescent but plentiful (which is why the NES used them) but I don't think 2Kx8 CMOS RAMs were ever a commodity item.

I thus think a developer who wants to be "period-correct" could quite appropriately design a game to use a battery-backed 8K RAM.

Ah! To answer the specific minigame part, the cross hair idea would be 100% fine.