ing the execution of the program. The ProblemOne problem was immediately apparent to me with this setup. I honestly had no idea who owned the pointers. For instance, take the Mesh class. I created it with a 'new' in my initialization procedure. Then I created a MeshObject, which is what controls where the Mesh is placed, how its animations are done, and so on. This way I only need one Mesh of a person to render an entire army, saving enormously on memory. The problem is, I passed the pointer to the Mesh into the constructor of the MeshObject, and so immediately there are two pointers to the Mesh; the application has one, and the MeshObject has one. Now, in this case it is fairly obvious that the application should delete the Mesh and then the MeshObjects. But let's have a look at the SoundSystem class. I create a new Sound object and pass it into the SoundSystem class, where it is stored to be played later. Now the application has a pointer to the Sound, and so does the single SoundSystem class. Who deletes this one? It became apparent to me that I was writing a game engine. The game code itself should never have to deal with any pointers to random engine elements, like vertex arrays or meshes or sounds. The SolutionFrom previous observations, the solution should be simple - just have the engine create and destroy all of its components. However, this is a much more complicated task than it sounds like. Let's look what I've done to make my engine totally self-reliant. The first thing that you need to do is to make every single constructor and destructor of every major engine element protected or private. At first, that sounds ridiculous. If the constructor and destructor are protected or private, nothing could create or destroy the object but itself! That is not entirely true. Those of you familiar with design patterns may recognize this technique from the Singleton design pattern. In the Singleton design pattern, the constructor is made...
