So the source code that is used, is that similar to a language like Java or HTML that is easily readable? Are all NES games being built off the same base code that is unique to the NES? Or... would that be like an OS or something....?
First off, I'm not a game-writing expert. Though one game company did make me an offer for a job, the day following a day-long interview there. My expertise is in designing hardware and writing embedded software for scientific and commercial instrumentation. That said, there is a great deal of similarity. What I do is sometimes called "bare metal programming." Which is to say, you really need to apprehend hardware design very well and your programming deals directly with the hardware in very intimate ways. You must understand how things work to do that. And your programming skills are often quite different from those required for, say, Windows programming under .NET.
The work I do is going to depend upon the microcontroller and the other limitations imposed on the design. If I have very little RAM and ROM to work with (for competitive reasons I won't dwell on right now) and I won't be using libraries of code developed by other folks and forced onto my application for other (schedule) reasons, then I will probably be writing the application entirely in assembly. I can use semantics at that level which simply don't exist with any other language. And it may make sense to do that. I would tend to expect NES games to be written mostly in assembly code, as a slightly-educated guess. However, if there is more room to work with or if there are software libraries written in some other language (like C), then I will use a mixture of C and assembly... using assembly where needed and C everywhere else. I almost never have a project that can be entirely done in C and have never been exposed to a project using Java, for example. But if I were doing an embedded project that required the use of video and audio codecs and specialized flash file system designs where I wasn't permitted to write them all myself from scratch (likely, I would not be allowed to duplicate those "wheels" if they already are available for a reasonable cost), then I'd use the languages appropriate to those libraries and appropriate to the project requirements.
I am finding C being used with SNES development. But I've just started looking over the code, too. But what little I've learned so far suggests that at least some significant portion of SNES games were written as a C+assembly mixture. If you get a chance, go look on the web for some examples of C code. That will give you a good idea about what that kind of coding looks like.
Texture maps are often developed through the use of specialized tools to help artists. The same is true for sprites, and pretty much anything where you are having digital artists do their work. Sometimes, digital artists will use commercial off-the-shelf (COTS) software to do that job, producing standarized file formats that the game software writers will then either use directly, or else after some other conversion/compression steps. The tool chain can be quite long, in fact. Some of the tools (and steps) may be the result of captive programming employees working as part of the game team. Some may be COTS software. The exact details will vary by project, project size, team experiences, and a host of other factors all of which enter into the early planning stages. (I haven't even mentioned the musicians, yet.)
The game software itself will usually be running stand-alone. This means, without an operating system environment. Sometimes, a limited operating system will be written, designed to the game requirements. Sometimes, a COTS operating system will be used. Sometimes, no operating system at all, instead carefully crafting the interrupt system and timers and other related hardware so that the software can operate "as if" lots of stuff happens in parallel even though everything really is happening one instruction at a time. Some game systems will have two CPUs, though. I suppose some will have even more than that. And of course, they may also be "multi-core." Those tend to require operating system support of some kind.
HTML coding is not at all similar. In fact, I look at HTML more like a kind of "set of word processor commands" than I do a programming language.
Hex editing is a tool I'd probably still have on hand. But I probably wouldn't use it much. It's one of those things you might use if you know exactly what you are doing and need to do a "quick test" without having to re-run your entire compiler tool chain just to find out. So I'd want one present if something like that came up. But I wouldn't expect it to be part of a regular routine. It's an exception-based tool, I guess. But really handy when you have to have it.