koobas.hobune.stream
player rule builder
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.
I find there's a 'trigger happy' nature of killing questions like this, which are about writing a game but naturally focus on a C# problem in writing the script for it. The fact that Unity presents C# (a dubious choice I$$anonymous$$O) makes C# a Unity subject.
Alas, a number of moderators tend to remove such questions, but really, it makes it difficult for Unity users to get help in C# if these type of questions, writing C# for a Unity game, get removed.
I have as much motivation to strike this particular question because the OP has posted a similar question over a week ago, but hasn't yet recognized that an answer has been given, it just isn't obvious yet - and a breakthrough is im$$anonymous$$ent I think. It is one of those 'things' where the answer is a tad subtle, and the student is not able to recognize the answer for what it is. Sometimes these things need back and forth, and different perspectives - indeed, this version of the question is already moving in the correct direction, the answer is almost fashioned in the question, but again, the OP just hasn't noticed that yet.
thunderbuns is welcome to ask whatever they want on the forum and its members are welcome to respond.
I'm just re$$anonymous$$ding folks to keep it relevant before other moderators see a conversation devolving into SQL, chains, and high-level game design philosophy, then deciding the thread is in violation of:
Non-Unity question: we want to strictly keep Unity Answers for Unity-related content.
It doesn't have to directly involve gameplay to be related to unity.
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.
@$$anonymous$$derbuns, Actually, it doesn't if the data is structured correctly. The 'tree' you are imagining is implemented in data, not code. Imagine that I have a list of 100 items to be applied, each of ten different potential 'types'. For each item I have a list of excluded relatives. Where there is no exclusion specified, the items are compatible. Only if I see an entry in the exclusion list is there specified an incompatibility. Ins$$anonymous$$d of a tree, now, I have a list to run through. To check for compatibility, the code considers the recipient. To take your example, the heavy mail suit would include a exclusion entry referencing the dagger. The data, not a tree of if/else statements, indicates the incompatibility. By looping through the heavy mail's exclusion list, I can see what weapons that might be applied are incompatible. This doesn't result in a tree within the code, the tree would result from the data.
This could be implemented from the opposite perspective, though - ins$$anonymous$$d of an incompatibility list, it can be implemented as a match list. In a popular engineering tool, there are nuts, bolts, nails and other fasteners. In this design there are multiple data indicating categories and specific matches. Nails have no match to bolts, so they're rejected. Nuts have to match to nails. Straps have no match to nail, bolts or nuts. These can't be applied to each other. Only nuts match screws (and the reverse). There is no code with 'knowledge' of this - it is done through the descriptive data. The data forms what may be termed a matching algebra (it boils down to boolean, which is why they are a counterpart to if/else logic). From a theoretical perspective, this is no different than creating a compiler which has if/else logical syntax and recognizes how to implement it. The compiler need not know every possible if/else layout that may ever be written, it only requires to understand a few basics which the text can then describe. In your case, however, the text is replaced by the data, but the implementation is nearly identical, fundamentally.
This is what prompted Vadim$$anonymous$$insk to suggest $$anonymous$$arkov chains, though I'm not certain they're perfectly applicable to your requirements, you're implementing rather simple boolean matches, in data. The boolean nature is hinted by the fact you can implement them as if/else tests.
Can I see a small code example of this being implemented?
Check out Markov chains. With this you can easily control the probability of applying certain rule, based on what other rules were already applied.
