Is development difficult on the NES?
Short answer: If you don't scroll, and don't handle slopes, it's actually only a little more difficult than C. You have to spend a little more time planning before doing your level format/etc. because of RAM and size constraints, but I've always found both to be extremely manageable. You also have to be prepared to learn some things about hardware you wouldn't need to know for anything modern. But really it's only hard if you want to make a very ambitious game. First game I made (which didn't scroll or handle slopes
) was a clone of Geometry Wars and I think it only took about 4 months. (Starting from zero assembly or NES knowledge. I did know C beforehand.)
Longer answer:
The big problem about NES is that it doesn't have a fast processor. And my game is super ambitious for its CPU. Maybe that's my beef with PC games that are made as retro NES games. The graphical restrictions have always been easier to follow than writing/designing a game that can be optimized enough to not run at < 60 FPS. I've actually considered dropping co-op just so I don't have to worry about my game dropping frames.
Multidirectional scrolling (meaning I can scroll both up/down and left/right in the game frame) has been the hardest part so far in my own project. You'll notice a lot of games (Metroid/Megaman/lots of stuff) tend to do just one axis at a time. And even doing that is pretty difficult. The Level Hubs of Kirby's Adventure (with the doors to enter each level) multidirectional scroll, but as far as I can recall the actual levels never do. Super Mario Bros 3. does it, as does MC kids. My scrolling is about as optimized as I can make it, and in the worst case it alone can actually take about half to 1/3 of the available frame time. (But generally it hangs closer to 1/10 or 1/5).
Handling arbitrary slopes (think Sonic) has been the second hardest part. The main reason is, it has to be super optimized, especially if you want two players on screen. It takes a lot more time to check if a point is in a slope than if it's just in a tile. But there's even more to it than just each point taking more time. You also have to check more points. If your character doesn't move faster than your tile size and you don't support slopes, you can instantly eject a character from a wall in a given direction with just one point. (If the size is a power of two, you can AND the position with the tile size, and subtract that +1 to eject instantly, or AND the position with the tile size XOR that result with the tile size and add that +1 to eject instantly depending on the direction.) With slopes, you basically always have to check two. The character could fall less than your tile size, but still pass through a slope. You eject from the floor tile of the destination point. And then you have to check the point after that ejection to make sure you don't have to eject up FURTHER.
But most problems you face are problems you'd face in any game.
Hopefully that wasn't too specific/technical.
Ashbad: Sorry to hear about that. I still remember those posts by Mike and they just weren't okay.
