Game Design Theory - keeping track of the gamestate

Hello all,
As an exercise, I've been attempting to implement the popular Game of Thrones Board Game in Unity.

If you are familiar with the game, it's like a complicated version of Diplomacy. If you aren't familiar with that, it's a complicated version of Risk.

Players assume the role of a great House, and the control Territories, muster Units, and so on.

My question has to do with, what is the best design practice for keeping track of (for example), which House controls which Territory? Should each House instance store a List of Territories it controls, or should each Territory reference the House which controls it? Or both?

Here is my thinking on the various options - I'd like your advice on which is the "best", what the best-practices and design patterns are, etc. Thanks a bunch!

Keeping track from both sides sounds great, but I'm concerned about running into synchronicity issues (although I could always write code that keeps them synchronized, that feels like a hack).

Keeping track from one side (House keeps track of territories, or Territory keeps track of house) seems simpler, a bit more elegant, but at the cost of sacrificing convenience of looping through either the list of all territories or the list of all houses whenever I wanted to travel the "other" direction.

Lastly, my gameState static class could keep track of the relationships (perhaps in a Dictionary<House, List<Territory>> construct) altogether and Houses and Territories wouldn't natively know about each other and instead use the class to look things up. The advantages of course are having a centralized information handler where it would be easy to enforce synchronization, but it feels less convenient.

Anyhow, thank you for your thoughts!

 

That's an implementation question, not a game design question — the second one today. But I see you're new, so, no biggie.

When faced with an implementation issue like this, the key considerations are to (1) keep it simple, and (2) make it so that, as much as possible, the implementation details simply do not matter. Give each House a method that returns the Territories it has, and each Territory a method that returns the House it belongs to. All code should use one of these methods (whichever is more convenient). And now, it really doesn't matter how they are implemented — you can change your mind at any time, change the implementation, and none of the rest of your code will know or care, because they're going through just these two public methods.

This should be a recurring pattern in your approach to coding — identify a need, define a method that provides for that need, and then figure out some simple way to implement it. And then a few days later, think of a better way to implement it, and change it without breaking the rest of your code.

 

I wrote about 90% of a Diplomacy implementation and if it's actually a lot like Diplomacy, I'd have the Territory reference the House, because the rest of the game will be using all sorts of data from the Territory objects (and they'll interact with each other) far more often than it'll be doing anything with any individual player.