re: inheritance vs composition...
favoring inheritance can lead to the "diamond problem", which composition can avoid.
https://en.wikipedia.org/wiki/Multiple_inheritance
inheritance as a design methodology lends itself well to problems that are inherently hierarchical in nature. Unfortunately, a number of things in games are not hierarchical in nature.
re: one big list...
Many of the data structures in games tend to be lists of things.
As performance becomes an issue, its common to use a number of lists of specific types of things, as opposed to one big list for everything.
re: globals vs passing params....
by passing params, all the dependencies of the code are explicitly stated in the API, which makes the code more portable.
define ownership at the lowest scope level possible, and pass down from there.
you may find that you often pass the same params again and again. these are good candidates for a parameter struct - a struct you define just for passing around those pesky parameters.
re: organizing game code....
from a design agnostic point of view, it would seem that games are made up of lists: meshes, textures, animations, sfx, entities, inventories, item definitions, npc definitions, entire libraies of scripts, maps, dialog tree branches, etc.
it also seems that code falls into two broad categories:
1. code that works on a single data structure. a library, or self contained class, etc. what i call worker code.
2. code that needs to know about two or more types of data or data structures. IE it must operate on data from two or more units of code from category 1. it needs to use two or more worker code APIs. i call this controller code.
it seems that games (and all software) are made up of low level worker code units, which are used by higher level controller code units.
a number of design schools, languages, and syntaxes can be used to implement this is in variety of ways, but at the end of the day you always seem to end up with data structures, worker code, and controller code.
