Subsystem: Core - Adam-Poppenheimer/Civ-Clone GitHub Wiki

The Core subsystem is perhaps poorly-named. During development it was meant to be analogous to a Main() method: The place from which execution of the simulation began, and where its most central architecture was located. Fundamental to Core is the exchange of turns and rounds, particularly whose turn it is currently. It also contains some game-wide configuration and a handful of utilities.

The core of Core is the GameCore class and its IGameCore interface. This is where turn and round exchange occurs. It calls into a decoupled list of IRoundExecuters to help it perform all of the per-round tasks that units, cities, and civilizations need to take, and in their correct order. It reveals a BeginRound() and EndRound() method in addition to an EndTurn() method, but it's not clear that BeginRound() or EndRound() should ever be used. Closer analysis is most likely required to determine what form GameCore should take.

The various IRoundExecuter implementations perform subsystem-specific beginning- and end-of-round actions. They define the canonical order in which PerformX methods are called. The order of IRoundExecuters is considered important and is defined in CoreInstaller, where the various implementations are instantiated and bound.

There's a (perhaps misplaced) interface called IPlayModeSensitiveElement which a number of classes outside of Core make use of. This exists to serve the needs of map serialization and deserialization, which is discussed in detail in the Map Management section.

There are also a pair of classes in Core which likely belong in other subsystems, but whose ideal placement is uncertain.

One, AppQuitRuntimeClearer, exists as a way of reducing error message spam when stopping execution of the game in Unity's editor. The precise areas in which those messages occurred is unclear, but it relates to the complex web of relationships that exist between important MonoBehaviour subclasses like City and Unit. To properly destroy an object it needs to be meticulously cleared of all its relationships to other objects. If those other objects are destroyed before the relationship can be cleared, it generates a superfluous error message.

The other, ChunkCullingBrain, might belong in MapRendering, but it's possible there are technical reasons for its placement in Core. Regardless, ChunkCullingBrain exists to disable MapChunks which are outside of the bounds of the camera in order to save memory and improve performance. Every frame it makes a relatively simple check for collision between the frustum of the camera and each MapChunk in the grid, telling it to render or not render depending on whether it overlaps or not. Given the performance issues of the game on my system, more work than this needs to be done to improve efficiency.