Object oriented Game Development -P3: There’s a better than 50% chance that you have picked this title off the shelf in a bookshop and are wondering if it’s going to be another one of those ‘secrets of the inner circle’ type of titles. You know, the ones that promise to tell you unspoken truths on how to write really cool games but in reality offer up a rehash of a manual you may already have for free anyway. | 46 Object-oriented game development the rather annoying habit of standard libraries to be anything but. When it comes to multicomponent packages there are two schools of thought The component must be entirely self-contained no linkage to external systems is allowed other than to packages that reside at a lower level in the system. The component can depend on a broadly static external context composed of standard libraries and other more atomic components. In the case of the first philosophy we often need to supply multiple files to get a single reusable component because we cannot rely on standard definitions. For example each component may have to supply a types file that defines atomic integral types int8 uint8 int16 uint16 etc. using a suitable name-spacing strategy. If we subscribe to the belief that more files means less reusable then we slightly weaken the reusability of single components to bolster the larger ones. We should also note that it is quite difficult to engineer a system that relies on privately defined types and that does not expose them to the client code. Systems that do so end up coupling components and have a multiplicity of redundant data types that support similar - but often annoyingly slightly different - functionality. On the other hand systems written using the latter scheme are better suited for single-component reuse with the penalty that common functionality is moved to an external package or component. It then becomes impossible to build without that common context. As a concrete example consider a library system that has two completely self-contained packages collision and rendering. The collision package contains the following files amongst others Defines signed and unsigned integer types. Defines 3D vector class and operations. Defines 4x4 matrix class and operations. Note the use of package prefixes in this case coll_ to denote unambiguously where the files reside. Without them a
