Unity is really great when it comes to allowing designers access to public variables and drag-and-drop interfaces for getting components talking to each other. But this obviously breaks down when using non-Monobehavior classes. I find myself either having to create many ‘manager’ classes just to set things up properly, or else making Monobehaviour equivalents for every non-Monobehaviour class.
I realise this is a broad question, but what are the best practices or design patterns (or hacks) when designing games with a lot of non-Monobehaviour classes?
EDIT:
For instance, I am creating an adventure game that plays on a Hex board. At each hex, there may be a number of things that a player can interact with (HexEntities). Each entity has a number of possible actions (HexAction), each with a set of requirements (HexActionRequirment) and results (HexActionResult). For instance, there could be a locked door that I can break down, with the requirement that I have certain strength, and result that I gain some treasure.
Short of creating many, many child classes and using the constructor to set things up (like adding actions to entities) I see no ‘nice’ way of doing this in Unity. For instance, some of my results need to access other game objects (like the player), and I can no longer make these public and drag-and-drop my game objects – since I am defining classes, not instances.
I was thus wondering how other designers manage to solve these (and other) problems with non-Monobehaviour classes.