C# Code Architecture For a Game Utility

In looking through the Meta, I found multiple answers that said code architecture questions go in Stack Overflow. If there's a better place for this, please let me know.

I am designing a utility to help me run a forum game I have created. However, I am running into some architectural issues that are causing me to repeat a lot of code, and I'm generally not happy with some of the things I've done, and could use some advice. Here are the basics of the classes and relationships that exist:

The GameState is the central object, representing the overall state of the game. It includes many other objects, such as the available Genes, available Buildings, Owners, available Research, wild Creatures and available Resources.

Owners contain their turn Actions, their owned Creatures, their collected Resources, their completed Research, and their Completed Buildings.

Buildings and Research each contain indicators of some amount of resources they require to research/build.

Creatures contain a copy of the GameState's available Genes, along with a count of the occurance of these genes in their genome.

The net result of this is that I've ended up passing a copy of the GameState Genes down into the Creature's constructor, and end up copying a lot of metadata into the Creature's Genes objects. This actually happens a lot, as I've done the same thing with Buildings, Resources and Research for Owners.

The goal of all this is to have a highly configurable set of game rules, so I can swap out Genes, Buildings, Resources, and Research and use the same general framework. How can I do this while avoiding duplicating objects (or worse, accidentally modifying a "master" object I don't intend to)? Is there a design pattern that would be helpful in this situation?

I have considered, instead of passing a GameState object around everywhere, compiling everything in a globally accessible class that contains all the relevant metadata. This would reduce some of the problems, but not all.