I actually look at 4 major areas useful for a modern, rasterized game to play thru a computer to your screen, all containing libraries of coding.
1) System - includes hardware and a Runtime Environment working with the Operating System (one of several major Runtime Environments which may come with the computer from the factory or be installed later, several actually being allowed and installed in the same client) The Runtime Environment includes the lower level coding needed in the form of various libraries with interfaces or even Software Development Kits (SDK) to develop applications and software which will run with machines using that particular version of that OS or made for any system which has that particular Runtime Environment version or earlier version installed. If that is confusing, then just remember that the Runtime Environment comes with (or allows third party tools to create) coding which is expected to be fully compatible with that Runtime or earlier version which is installed. It gives libraries of lower level coding to provide the APIs, compilers, and various other tools for all levels of coding to be read implemented in the computer. (Note: some higher level and lower level coding tools are included but more of general tools for nuts and bolts programming, created "from scratch" applications and software which are original from top to bottom. These all either come with the Runtime or are made for it, many no cost and can be downloaded. Highly skilled coding and experience is needed usually to make large applications and software here, sometimes requiring a team.)
2) Development Framework - such as SDKs, IDEs (Visual Studio, MonoDevelop, Java IDE, etc.), or game engines (In order of size, complexity, and generalization: 1)IDEs 2)Game Engines 3)SDKs). These are all various sizes of framework which provide the ability to create applications and software targeting a specific Runtime Environment in most cases, though sometimes as in the case Java Runtime Environment or Mono they can be cross-platform with some time spent in testing and debugging. These three categories of framework provide more of the coding already complete such as UI interfaces, default sounds, access to lower level graphics APIs (OpenGL or Direct3D), input interfaces-device, voice command, or other inputs, configuration interfaces, compilers/ de-compilers, and so forth. So these frameworks all are more specific toward goals than the tools in the previous system based Runtime Environments and frameworks include libraries made for certain genres of development. There is less work in making custom made tools and applications within the software in terms of coding with one of these dedicated frameworks, being that a huge collection of standard libraries come with the framework to add to those of the Runtime Environment. Often the developer can do relatively little or no lower level coding with a framework, freeing them to spend more time on end-user features.
3) Default libraries - may be GUIs, templates (including games in some cases which come with a game engine as a building foundation for you), specialized tools ( such as terrain editors, effects editors, and so on ), actual ingame assets (such as models, effects, sounds, et cetera), and the like.
4) Third party libraries - can include any additions to the above items which are original creations: plug-ins (external connected libraries), add-ons (attached libraries), and patches (internal libraries).
That's a decent summary and over-simplification, but you get the idea now.