I have a game in which there are different kinds of garbage.
They have fields like:
- type (as an indicator that indicates which parameters will be next)
- speed (depends on type)
- damage (depending on type)
- skin (depending on the type)

I created a prefab with a script that selects the necessary skin and sets all the parameters, but I think how beautiful and understandable is it to organize everything? It is possible to create types in the enum list, and in the class script to define a field with a specific type and method that set the parameters depending on the type? But then what to do with the coders? They also dynamically substitute? Where to store information about all types and characteristics?

Or is it easier to make different prefabs with different characteristics but with a single script?
Tell me how to choose the right structure for this class of objects? :)

  • And more important information. If you put a minus question, then please kindly explain at least in comments. :) - DmitriyLeaf pm

2 answers 2

100% imho

To whom it is as simple as a programmer , I rely more on scripts than on settings through the inspector, because I trust the control of source versions via git with all the consequences.

However, if there are no programmers in the project, it is not convenient for them, it is convenient for them as in a unit, i.e. prefabs, inspector, etc.

In projects that I do alone, I try to use programming with the mouse as we call it, because I do not like to look for something in the scene. it's easier for me at ide to press ctrl + f

And how objects should be arranged - the artist (you) knows better, whether it is enum or any other feature of c # / oop, this is highly context dependent.

  • An interesting answer, I agree it would be great to carry less than a mouse. It is true that when only I and the artist are in the team, I have to decide here and ask for a more practical implementation. :) - DmitriyLeaf

I agree, the answer was vague and blurred. But I came up with a solution and explain what:
First, I created two enum lists in the object generator: (and yes, I don’t use the original code here;)

public enum OTypes { easy, //1 normal, //2 hard, //3 ultraHard, //5 danger //1 } public enum FieldsToOTypes { score = 0, speed = 1, damageToLocation = 2, damageToPlayer = 3 }

Also in the class created a dictionary:

 Dictionary<OTypes, int[]> OTypesDictonary = new Dictionary<OTypes, int[]> { // rules to build difrent types of O { OTypes.easy, new int[] {1, 1, 1, 0} }, // meaning of array indexes can see in FieldsToOTypes { OTypes.normal, new int[] {1, 2, 2, 0} }, // score, speed, damageToLocation, damageToPlayer { OTypes.hard, new int[] {2, 3, 3, 0} }, { OTypes.ultraHard, new int[] {3, 5, 5, 0} }, { OTypes.danger, new int[] {0, 5, 0, 1} } };

What it is? I think this code will allow you to easily add new types of objects, and the creation and setting of parameters will be similar to a factory and has a clear view:

 OEntity.score = OTypesDictonary[type][(int)FieldsToOTypes.score]; OEntity.speed = OTypesDictonary[type][(int)FieldsToOTypes.speed]; OEntity.damageToLocation = OTypesDictonary[type][(int)FieldsToOTypes.damageToLocation]; OEntity.damageToPlayer = OTypesDictonary[type][(int)FieldsToOTypes.damageToPlayer];

Vseda happy advice and criticism of my decision :)

  • I found out about json and realized that it’s better to convert everything into a separate file, but the structure will remain :) - DmitriyLeaf
  • The logic of the factory remained, but some data changed. Now I use Json for object counting and special classes for Data Serialization, and then I also process parameters. var dataAsJson = Resources.Load <TextAsset> (path); Objects = JsonUtility.FromJson <Locations> (dataAsJson.text); - DmitriyLeaf