I am trying to build a game where the users will be given a set of randomly generated rules. For example each player will receive a different starting weapon, a different tool, different clothes and so on. I don’t want to hard code all the possible combinations, so I am looking for a better solution. But I have run into a problem. Some of the outputted combinations are conflicting. For example, a player might receive a dagger and a suit of heavy mail, when they would be much better suited to leather armor. I there a way to avoid this problem? A solution that doesn’t involve a massive if else tree would be preferable, as that is very hard to scale.
You have lots of choices. Hard coding is certainly among the least attractive.
As a simple point of logic, generally applicable to your data, is to ask which is smaller, the list of rejections or the list of acceptable matches. I suspect the rejections, or one might call them a list of incompatibilities, is probably smaller. You could proceed on the assumption that things go together just fine unless there’s a specific exception that identifies incompatibility. So, you could have a small container (List<> for example) of identifiers attached to, say, the heavy mail, which indicates an incompatibility with the dagger. The leather armor wouldn’t have such an entry in it’s list, such that your logic would discover what doesn’t work with what, and proceeds to retry for a better match. If, however, you think the list of incompatibilities is actually the larger list, it would be less work to identify likely matches. The point here is you’d choose that which defines less work for yourself.
This incompatibility or compatibility ‘rating’ could be graduated if you want to indicate preferences. In this way you could allow for situations where some weapons are a best match, good match, poor match or fundamentally rejected, such that if availability of some items is limited the system could help choose an acceptable if not optimal match, and conversely to choose an optimal match among several less optimal alternatives.
You could ‘script’ the data. The word script is unfortunate, because Unity refers to C# code as scripts, which are really the text files of code in a solution. In this case, however, I use the word script to reference some sort of database, perhaps a JSON or XML file, or it could be a SQL database if you prefer. The point here is that the relationships you must define need not be built in C#. They could be loaded at runtime from a data source, which you could subsequently edit without having to rebuild the application. This ads to the convenience of representing the relationships if you get it right. You could create some UI elements which give this power to in-game editing, or you could create a custom editor for Unity (if these are fairly quick solutions for you), or you could use external tools like spreadsheets or just a text editor.
Check out Markov chains. With this you can easily control the probability of applying certain rule, based on what other rules were already applied.