Is this the best way to structure my code?

I'm not a coding expert so I thought I would ask for some help here.

I have an open world game and I am trying to build the code in away to make adding and removing or swapping assets as simple as possible.

This rough drawing shows what I have come up with, using the example of a slider setting the resolution of a the worlds water reflection.

I figure this is the minimum amount of scripts I would need to be able to make efficient changes, abstract things away so swapping assets would not be too difficult. This way if I change to a different water asset in the world I just have to change the helper that goes with a new water asset.

Does this make sense what I am trying to achieve here? Is this a best practice, or are there any suggestions how to improve it?

 

Answering this question really depends on what kind of workflow it ultimately ends up in. Ideally each chunk can exist and evolve on its own without requiring all other chunks of the world to suddenly be upgraded to work with it.

Generally this implies keeping the loosest most minimal connection between game state and which areas of the world are loaded. The tighter that coupling is, the more things break when you have to change it.

Unity's scene manager system is an awesome way to additively stream content, although I have not used it personally in an intensively performant fashion. I've used it mostly for composing game scenes out of many sub scenes at runtime, which eliminates the need to put common things like UI and player and enemy managers into every single "content" scene.

 

Thank you I took what you said and applied it to each piece, and I think they adhere to it.

It makes me think I don't need to go through a World.cs intermediate really. My slider could just speak directly to the water manager, and the water manager can use the helper to affect the asset.

The representation of the "world" in code becomes a collection of managers (water, terrain, animals, etc). And I could keep a World.cs script maybe to just keep track of all the managers that are active, although I don't know if that would be useful somehow.

Ill try this structure, and I appreciate the food for thought