Well by your answers I'm glad you are asking questions
1. Source code is generally a closely guarded proprietary secret for commercial releases. In some cases, the source code for a release of a game may be lost to time due to the sequel to the game being immediately developed from the same code base without strict versioning to save the state of the code which built a particular release/game. Source code is human-readable and human-written code that is fed through a compiler, usually C or C++. You can't extract it from a release because the release only has compiled code. Even in cases where a game was written in Assembly (*very* rare after 1994), the game as released has the
assembled code, not the source assembly code.
You can
ATTEMPT to reconstruct functional source code from a game's executable binary (often executable(s)). An "executable binary", in Windows, is what you know as a ".EXE" file. The primary tool for doing this is called Ghidra. Using Ghidra isn't really a learning experience because often Ghidra's output does not compile back into a working executable without extensive massaging and research, particularly in cases when a game has multiple interlocking executables.
2.
is the only barrier a program that can properly display/play said file
Sometimes games store data in customized "libraries". Think of them like zip files, but different. These aren't anti-piracy measures, they are simply made by developers to integrate methods of finding and loading files faster than the host file system can. Or to store files in ways that are more dense than allowed by the host file system. For instance, on a CD, data is stored in 2KB sectors. If you have a bunch of files that are smaller than 2KB, they will all end up taking 2KB of space on the disc, and reading them sequentially will be slow since the CD must adjust itself every time it wants to read the next file (read, stop, seek, read, stop, seek) whereas if it was in a "library" file, the library would describe the files and where they are rather than the files descirbing themselves in the file system, such that reading them sequentially would not span sectors. They could then be read all at once.
If you want examples, Dynamix developed two games at around the same time with very similar engines: TRIBES and StarSiege. Both TRIBES and StarSiege use slightly different versions of a properitary package format called ".vol". It just stands for "volume", like volume of files.
Many Blizzard games store their data in packages called ".MPQ". They used the .MPQ standard all the way up to the initial release of StarCraft 2, with scalable additions in each release. In that case you would be lucky trying to reverse engineer it because it is such a long-running standard.
BattleZone '98 (original) has a completely proprietary file stack format called ".lzf". This shares a name with a common compression schema, but these files are more than just compressed.
Within or without these libraries, you will find data formats which might be completely custom to a specific game.
For instance, Grandia (on Saturn) has a unique video format.
Anyway, my main point is not all the graphics/audio you want will be in a standard format and they may be contained within file packages unique to that specific game. ROMHacking is very much about figuring out those formats and the packages they are in.
For audio and sound though, you may be able to use emulators like SSF/Kronos to just extract the data from the game as it is running, allowing the emulator to convert it for you.
3. IDE, in the programming sense, stands for "Integrated Development Environment". Unreal and Unity are IDEs as well as game engines. CodeBlocks is another example of an IDE, but it isn't a game engine.
4. Ghidra is pretty much the answer to this.