Skip to content

Class hierarchy concept for game objects

Louis Moureaux edited this page Sep 6, 2022 · 1 revision

At some point we'll want to turn game objects like tiles and cities into proper classes with encapsulation and the like. We'll want a class hierarchy for each object, at a minimum to implement the client- and server-only parts. Here I argue that we want more.

A never-ending story on the server is info leakage, mostly because of how hard it is to check player vision for everything. I think this can be solved in an elegant way with an appropriate class hierarchy.

Here is a working draft for cities:

  • abstract_city: abstract, only stores information that's always visible when the city itself is visible.
    • city: concrete city storage
      • client_city: client-specific things
      • server_city: server-specific things
    • vision_city: city as seen by a player, potentially outdated

Reusable code such as the effect system should always use abstract_city so a vision_city can be passed when info leak should be avoided and a server_city when evaluating effects in an omniscient context. To support this coal, creating a vision_city should be easy and cheap.

Clone this wiki locally