In all honesty, the best advice in today's age is: Defer writing of the actual 6502 code as long as you can.
A lot of the games of the (g)olden days are a lot crappier than we remembered them gameplay-wise. Partially this was due to pioneers still trying out what worked. But a lot of it probably also has to do with the fact that iterating on gameplay mechanics was very expensive when coding directly on the system.
A few companies (like Nintendo) did manage to do this really well, always putting controls and gameplay first. But the challenge of iterating on fixed-point math on a 6502 often meant this crucial element was not prioritized in other companies.
Today you have the luxury of using modern programming tools and environments, not only for data creation and conversion, but also for prototyping your ideas before trying to squeeze them into the NES's code space. And an approach that I wish more people would try is using the benefit of emulators using Lua to get a good prototype of your game before you dig into assembly.
1) Find a good game engine that uses Lua for scripting, that allows dynamic reloading of Lua scripts and has a decent visual editor. Not sure which one to be honest, but there are quite a few alternatives AFAICT.
Try to make a game that respects all the NES's limitations graphics-wise, and doesn't seem to be too heavy for an NES. (i.e., don't try putting Box2d or other advanced physics code in there)
2) Rewrite all that Lua game code, quantizing everything to fixed-point rather than floating-point. Avoid any divisons, and be very selective about multiplications as well. Verify that you can get the same smooth gameplay even with this approximate math.
3) Use a modern NES emulator's ability to run Lua scripts to get you easy-to-maintain-code running working with a small 6502 core. Focus on getting the rest of all that engine code for your game (level loading and storage) that doesn't need the "magic touch" of well-balanced gameplay.
4) Gradually convert your gameplay from Lua to actual 6502 code, step-by-step.
While it sounds a bit off-putting to re-do the same work multiple times, I'm certain you'll save time on average this way, exactly because you won't spend all that time debugging complex game logic code that you'll likely throw away anyway as part of the gameplay tweaking process
. To get those elements right the first time, you would have to have both a lot of intuition for how to write well-balanced gameplay. Most of us don't have that, so reducing the cost of experimentation early is key to success.
Just my two cents... others might disagree