I have seen a lot of old topics on this matter about adding defines in player settings, that is not what I am looking for
What I would like to do is to have the ability to create a #define in 1 script and enable code in 2nd script if the first one is present in the project. example below
#define BUILDING
class Building
{
/* content of the class */
}
class Grid
{
/* Building unrelated code here */
#if BUILDING
public void AddBuilding(Building building, Pair<int,int> coords)
{
/* do Building related code here */
} #endif
}
Boolean variable wouldn’t work as I need to remove functions from compiling as the class used can’t be found
Same topic related question, is it possible to add a define in PlayerSettings when importing an Unity package? cause that would do as well as the main goal is to have different .unitypackages with different parts of a project, that way if you need part of a project and import that/those packages into a new one you don’t get any errors for missing out other parts.
like in example, importing the grid.unitypackages and not the building.unitypackages and not have 5 compile errors for each method that requires building class.
Sounds as if you could benefit much more from a better structure for your ‘modular’ approach.
I would not solve this problem with conditional compiling, rather with more abstraction and/or seperation, otherwise you’ll quickly run into the situations in which you start to enable/disable various conditional compilation symbols to get your code working.
If used too often, this does not only clutter code, it also makes it hard to maintain your code as disabled portions of your code will usually be ignored during refactoring processes.
There is also an attribute for conditional compilation that allows to prevent method calls from being build into the IL. (System.Diagnostics.Conditional) but it is also not the ultimate solution and comes with some limitations.
Another approach is some namespacing… I use that when I “mash up” two different Unity projects into one… Unity is SUCH an awesome engine that you can just mash 3 or 4 games together (keeping the directories unique), hook up a little UI and bam, you have a brand-new hybrid. No other engine can do that.
The idea is to create different modules separated in unity packages and use those to create quick prototypes based on your needs. If you need buildings but no grid you can load up the building module but not the grid module, need grid for some old school combat, can load up the grid module and might not need the buildings at all, or at least not combined with the grid…
The plan is to create modular code (already have that) and to push that into being actual external modules as well
The structure and architecture are fairly simple MVC with 50%+ non-mono classes (entire game logic is removed from mono classes) giving a very high reusability to each of those logic & data classes
Yes, but that also mean that they shouldn’t be coupled.
The connection between both would either be integrated into the grid module so that you can pass something to place on that grid, simply said kind of a GridPlacementController or some interface/facade-methods or you’d completely seperate that and treat it as appliaction specific logic, depending how specific it turns out to be.
I can only recommend to not spread conditional compiling all over the place. I’d restrict the usage to very specific things, such as platform dependance and runtime/version dependance if there is no other way around.
When I first tried C# with a C++ background a few years ago, I was like… well, why aren’t there macros at all and why is even conditional compilation used so sparingly. The answer is simple yet reasonable. The ease of use and understanding of an high level language such as C#.
There’s surely a better way that you’ll find out about and you’ll be way more happier with it. I bet. Cannot give some concrete example for your situation since I know nothing about the structure (even though it already sounds quite good from what you’ve mentioned). But I’d really go for even less coupling of hese both modules, otherwise, they’re not completely modular and kind of belong together.
Grid is the actual Controller on this, for some weird reason Unity doesn’t have a generic Matrix class so made 1 myself, that is where I store all the data with and Grid is the link that allows me to actually convert a Building into something that can be placed in the Matrix (Logical grid).
I think other option I have atm is to make 3 unity packages in stead of 2, 1 that contains Building, 1 that contains Grid with no Building code and 3rd that contains both… but this will quickly just bloat up badly
