One of the reasons why computer games are a good kind of programming project is that writing computer games gives you some experience with creating computer simulations of something like real-world processes. Simulation is one of the most important things that we can do with a computer. In a simulation, we set up a model of some real-world system we are interested in. By watching the behavior of the simulation we can gain insights about the real world.
Things that have been simulated include factories, industrial machinery, the stock market, people's buying behavior, automobile traffic, the formation of stars, nuclear weapons explosions, the spread of disease, the solar system, organic molecules like human DNA, and games like golf and tennis. The entire business of computer aided design, or CAD, is about simulating the appearance of physical objects in mathematical space, and these days nearly everything that is manufactured is first modeled in some CAD program.
Even something like a telephone or Internet control system is a kind of simulation, insofar as the users and routes are being represented as data structures which the program manipulates. Payroll programs are again a kind of simulation, with data fields standing in for dollars and employees. Spreadsheets are one of the oldest kind of simulation programs; the power of a spreadsheet lies in the fact that you can alter a single entry and automatically simulate the changes that propagate out from it.
Object-oriented design (OOD) lends itself very well to simulation. The reason is that when we have a system to simulate, the system tends to naturally break into interacting objects, each object with its properties and behaviors. A class is a very natural kind of model for an object of this kind. One of the big differences between C++ and C is that while in C we can have struct objects to hold collections of data, in C++ we can have class objects that not only hold data but also hold specific methods that act on the data. This is encapsulation.
Another good thing about OOD is that it makes it easy to give your simulation objects a uniform behavior, such as is enforced by physical laws. Let's explain this a bit more. If you are modeling physics, all of the objects should obey Newton's laws of motion. By using the OOD mechanism of inheritance we can avoid having to reprogram Newton's laws over and over and over. Instead, we define a base class with, say, a move(dt) method embodying Newton's laws, and then we derive all of our simulation classes from the base class. Thanks to inheritance, the child objects will all obey the same laws of motion as the parent class.
The OOD technique of polymorphism is useful for expressing the fact that, although real-world objects tend to group themselves into classes of similar objects, it's also the case that there will be subclasses that have their own distinctive behaviors. And each object knows on its own how to behave. By using polymorphism, we're free to think abstractly, and say something like 'let each of the objects move a time increment step now,' and be able to trust our individual objects to know to use their own specialized styles of motion. Thanks to polymorphism we can ignore the differences between objects when working at a high level ? as when we form an array of them ? and still be sure that on the low, individual, level, the objects will be 'smart' enough not to exhibit simple generic behaviors.
In our discussions, we are going to focus on depth rather than breadth. Instead of talking about a wide range of processes to simulate, we'll concentrate on simulating one particular kind of thing: material objects moving around according to the laws of physics. And we are going to place these objects into the context of computer games built with the Pop Framework.