We need to decide whether or not Phish will be multithreaded. Designing a multithreaded application presents certain advantages. We could make each individual fish a thread, so that the various different fish are independent of one another, thus closely mimicking the real world. Each fish would move about and interact with its environment on its own schedule.
The alternative is to have a central managing object that provides a clock "tick". At each tick, a new round of Phish commences. At each round, every fish must move, resolve any conflicts and draw itself in the new location. This is much less realistic, but it is much easier to implement.
A second advantage of this latter, centralized approach is that we avoid taxing the operating system with hundreds of threads. Each thread brings some overhead, and the game might slow considerably if we were to implement each fish in its own thread.
In addition to the raw performance consideration, in a highly multi-threaded design there will be significant contention for shared resources, all of which would need to be under synchronization control. Each thread would need to lock these resources, use them and unlock them, and the risk of deadlock would be much greater.
We therefore decide, early in the design process, that we will implement the game using the central managing object, tentatively titled the
class. Once the application is built and debugged, we'll revisit this decision and consider re-implementing the fish themselves as worker threads.Simulator