Как реализовать массив хранящий различные типы данных?

public enum FirstEnum {
    One
}

public enum SecondEnum {
    Two
}

public struct Element {
    public string     Text;
    public FirstEnum  First;
    public SecondEnum Second;
}

public class SomeClass {
    public Element[] Elements;
}

Это самая базовая база программирования.

Как сделать, чтобы CombineMeshes() объединял несколько материалов, а не только меши?

Никак. Материалы к мешу никак не относятся. У компонента MeshRenderer есть поле materials. У меша есть сабмеши. Ты можешь меши с разными материалами скомбинировать в один меш, но с несколькими сабмешами. Для каждого отдельного материала - отдельный сабмеш. А в меш рендерере установить эти материалы. Индекс материала в меш рендерере соответствует индексу сабмеша.

Как можно объединить элемент через CombineMeshes() чтобы еще и несколько текстур тоже объединялись?

Назначь для каждого материала отдельный сабмеш в меше.

Как правильно ограничить выбор enum значений в инспекторе для разных типов предметов?

freeExec,

public enum ItemType : byte {
    Clothes,
    Weapon
}

[CreateAssetMenu(fileName = "Item Config", menuName = "Configs/Item")]
public class ItemConfig : ScriptableObject {
    public ItemType Type;
    public float    Damage;
    public float    SwingSpeed;
    public int      Armor;
    public float    Weight;
}

[CustomEditor(typeof(ItemConfig))]
public class ItemConfigEditor : Editor {

    public override void OnInspectorGUI() {
        var typeProperty = serializedObject.FindProperty("Type");

        EditorGUILayout.PropertyField(typeProperty);

        var type = (ItemType)typeProperty.enumValueIndex;

        switch(type) {
            case ItemType.Clothes : {
                DrawProperty("Armor");
                DrawProperty("Weight");
            } break;

            case ItemType.Weapon : {
                DrawProperty("Damage");
                DrawProperty("SwingSpeed");
            } break;
        }

        serializedObject.ApplyModifiedProperties();
    }

    private void DrawProperty(string name) {
        EditorGUILayout.PropertyField(serializedObject.FindProperty(name));
    }
}

5 минут. Крайне хлопотно.

Как правильно ограничить выбор enum значений в инспекторе для разных типов предметов?

У тебя в комментах к ItemType написано то, что должно быть в ItemType.

ItemType {
    Clothes,
    Weapon
}

Можешь избавиться от наследников ItemConfig, все их поля перекинуть в айтем конфиг, а для айтем конфиг написать кастомный инспектор, который будет отображать нужные поля, в зависимости от типа предмета.

Как в 3D-моделях можно сделать кости для анимации?

Ты нейросеть или просто прикидываешься ей?

Unity как отследить координаты мыши после клика по ui кнопке или проведя по ней с зажатой клавишей мыши?

Создать кастомный класс кнопки, реализовать этот и этот интерфейсы. OnDown вызывается при нажатии клавиши, OnUp при отпускании.

Архитектура MV* используется для разделения логики персонажей?

Николай Егоров, можешь декомпилировать(открыть в райдере/вижуал студио Assembly-CSharp.dll, которая находится в папке Game_Data/Managed) игры от Owlcat Games (pathfinder, wh rogue trader), там какой-то из мвх паттернов используется для юи.

А сущности у нас обычно состоят из многих компонентов... тот же самый игрок, или NPC

С мвх компонентный подход, когда на одном геймобжекте висит 20 компонентов несовместим в принципе. Будет еще больше ненужного кода, который ничего не делает, а существует просто для связи одного с другим. Делай один компонент для игрока и в него пхай все, что относится к игроку. Если хочешь вынести что-то в отдельный компонент, просто выноси это в отдельный класс и пхай его в сущность, соответственно, этому классу не нужно плодить контроллеры, вью и т.п. И будет тогда, условно, Player, PlayerView, PlayerController, гораздо меньше бесполезного говнокода.

Архитектура MV* используется для разделения логики персонажей?

Иногда встречаю высказывания, что всю логику хорошо бы делить еще и по MVC/MVP

И почти всегда такие высказывания делают люди, которые этот мвх только на юи примерах видели.
Не нужно использовать мвх для логики игры, ничего, кроме разделения одной/двух сущностей на 3 оно не делает. Использование его приводит только к запутанности кода, когда логика одной сущности раскидана по нескольким классам и один из этих классов существует только, чтобы связать между собой другие.
Мвх может быть полезен для юи и то в очень редких случаях, в остальном это написание кода ради написания кода.

Если ты хочешь свой проект на юнитевских компонентах переделать в мвх, то проще будет создать новый проект и изначально писать его на мвх. Можешь попробовать, чтобы понять насколько это абсурдный паттерн.

Как правильно начать изучать Unity?

никогда не ясно насколько качественный код предоставляется в качестве решения моей проблемы

Забей на "качественный код". Писать говнокод ты будешь в любом случае, этого не избежать. Избежать "некачественного кода" при обучении невозможно.

Посоветуйте с чего начать и к чему продвигаться

Начать с изучения c#, продвигаться к изучению юнити.

Vector3.forward: как он работает?

Moskaa, Я же русским по белому написал:

Vector3.forward это просто Vector3(0, 0, 1). Transform.forward - это направление оси Z объекта в мировых координатах.

Vector3.forward и transform.forward это не одно и то же.

Vector3.forward: как он работает?

Правильно все в документации написано. Vector3.forward это просто Vector3(0, 0, 1). Transform.forward - это направление оси Z объекта в мировых координатах. transform.forward - это просто transform.rotation умноженный на Vector3.forward.

Кто-нибудь пользовался CapsulecastCommands в Unity?

Я пользовался, вот код. Не знаю, правда, что ты из него почерпнешь.

var physicsResults  = new NativeArray<RaycastHit>(Entities.Length, Allocator.TempJob);
var physicsHandle   = SpherecastCommand.ScheduleBatch(physics.Casts, physicsResults, 1, 1);
physicsHandle.Complete();

Если ты делаешь каст и в начале каста какой-то коллайдер входит в стартовую область каста, то этот коллайдер не будет учитываться как хит. Проверь для начала это.

Когда выделяется память для переменных внутри функциях?

Просто создай структуру, которая будет описывать движение и передавай ее. Если ты не создаешь инстансы референс типов, то память будет аллоцироваться на стеке, это просто пшик.

Время, просранное на кэш мисс для получения данных монобеха будет больше, чем время, затраченное на этот иф. Нечего тут избегать.

Почему рекомендуется использовать private а не просто ставить везде Public?

Василий Банников, соболезную.

Почему рекомендуется использовать private а не просто ставить везде Public?

Василий Банников, соболезную. В юнити всю эту дичь тоже пытаются перетащить и di контейнеры каждый день новые, и скриптабле обжекты используют как дто, делают это те люди, которые ни одной игры в своей жизни не сделали и не понимают специфику создания приложений, работающих в реальном времени. Рекордов в юнитевской версии шарпа, к счастью, нет, а иммутабельность = 20 секунд фреймтайма, так что, надеюсь хоть этого избежать можно.

Почему рекомендуется использовать private а не просто ставить везде Public?

Василий Банников,

ситуация слишком простая, чтобы подход себя оправдал.

Других ситуаций в подобных книгах и не показывают. Показывают только то, что можно расписать на 10 книг, налить воды и продать хомякам. Как пример, тот же принцип единой ответственности, три книги мартина, три разных определения, а принцип как был убогим, бесполезным, вырожденным куском субстанции, так и остался.

После этого мне начинает казаться, будто мы говорим об одном и том же, но разными словами.

Я говорю о том, что должна быть причина сделать поле приватным, ты говоришь о том, что должна быть причина сделать поле публичным. Это немножко противоположные вещи. Пользу своей версии я написал уже как минимум дважды: приватные поля становятся исключением из правил, их меньше => с первого взгляда становится видно, что поля приватные не просто так и трогать их, не разбираясь как все работает, не стоит => ценность приватных полей возрастает.
Еще один пример рационального использования приватных полей - дверь с комплексной механикой открытия-закрытия. Будет несколько приватных полей, которые отвечают за то под каким углом дверь открыта в данный момент, какой угол был в предыдущем фрейме и т.д. Будут методы открыть/закрыть и свойство без сеттера/метод, который возвращает состояние двери в данный момент (открыта / открыта частично - открывается / открыта частично - закрывается / закрыта), основываясь на данных из этих приватных полей. Поля по типу материала двери, скорости ее открытия / закрытия, айди сущности, которая трогала дверь последний раз и т.д., будут публичными, потому что они никаким образом сломать важную логику открытия/закрытия двери не могут.

Почему рекомендуется использовать private а не просто ставить везде Public?

Василий Банников,

чистая архитектура у меня есть, но что-то я не помню там рекомендаций накидывать повсюду мелкие классы.

Открой главу, которая называется "Принцип единой ответственности" и посмотри что он советует делать в конце главы. Мне даже не пришлось ничего искать, по оглавлению понятно на какой странице будет бред.

Я тебя так понял, будто мы должны по-умолчанию делать все поля публичными и переводить их в приватные, если поняли, что они должны быть приватными.

Нет, я этого нигде не писал. Изначально нужно понимать, когда поле должно быть приватным. Этих ситуаций минимум и они всегда видны изначально. Как это понять и пример, я писал выше. Очередное смотрю в книгу - вижу фигу.

А дальше разработчика порвало, несите нового.

Аргументация уровня дошкольника.

Если обратить внимание, лично я ни разу не аппелтровал к защите и безопасности, ни в комментах, ни в ответах.

С публичным полем health разработчик (не обязательно другой), может в другом месте кода напрямую изменять его значение, что приведёт к очевидному багу - какой-то персонаж в каких-то условиях будет просто бессмертным.

Читаю второе сообщение - делаю вывод, что, чтобы обезопасить себя от бага, нужно сделать публичное поле приватным. Да, именно про безопасность ты не писал. Когда я пишу про "безопасность и защиту", я имею ввиду ту мнимую безопасность которая появляется, когда кто-то просто везде пишет приватные поля и думает, что их никто не будет менять. Будут, как раз таки и потому, что непонятно должно ли это поле быть приватным или нет.

Предлагаю тебе ещё посмотреть на весь веб

Так практически весь веб - это рассадник этих бездарей, которые и тянут все эти "бест практис" в другие отрасли.
Особенно жава программисты, надеюсь им всем запретят выход в интернет.

Реальная история?

Да, это буквально сообщение из чата, сжатое до одного предложения. Можешь зайти в какой-нибудь юнити чат, там подобные истории будут еженедельно присылать.

Почему рекомендуется использовать private а не просто ставить везде Public?

Василий Банников,

К сожалению (или к счастью) у меня на полке таких книг нет. Пример будет?

Чистый код, чистая архитектура, все остальные бумажки анкл боба, книги бугаенко, любая другая книга по ооп, кроме, возможно, гради буча.

А зачем эта дополнительная ценность нужна для принятия решения о закрытии полей?
Сделаем всё приватным.

Сделал все приватным, а потом тебе нужно в разных местах ui одни и те же данные отобразить по-разному, твои действия? Переделать приватное поле под свойство? Так это же рефакторинг, нельзя так делать, сложно, да и данные наружу выходят, а так нельзя, это же инкапсуляцию нарушает (или нет?).

Сделать публичное поле приватным - breaking changes.

Зачем поле, которое изначально было публичным, делать приватным? Просто так захотелось? Инкапсуляции хочешь? Зачем полю в принципе менять модификатор доступа? Если делаешь поле приватным, то оно изначально задумывается как поле, к которому доступа извне не должно быть ни у кого. Не знаю что здесь сложного для понимания, больше я одно и то же повторять не буду.

Как такое ограничения сделать при помощи публичных полей? Да никак.

Смотрю в книгу - вижу фигу. Лучше бы со свежей головой прочитал все мои сообщения в этой ветке, потому что я явно дал понять, что я не против использования приватных полей в принципе, а против бездумного втыкания их везде, потому что "так безопасно, ничто не сломается", от кого там что защищать - непонятно, ведь, если мне нужно будет достать данные из приватной переменной, я просто поменяю модификатор доступа этой переменной на публичную или использую рефлексию. И, если публичные поля все ломают и делают плохо, почему же софт, написанный на С кучу лет назад, работает лучше(быстрее, меньше багов), чем тот ужас, что выпускают сейчас (можешь сравнить вижуал студию до того, как она перешла с плюсов на C# и после).

Как я и писал раньше, вся эта непомерная "защита и безопасность" - бред и может сработать только с новичком, который не понимает что такое программирование и будет просто брать и менять данные, не задумываясь о том, может ли это как-то навредить и нет ли других путей использования данных. Как пример подобного бреда - термин инкапсуляции, который в разных ресурсах описывается по-разному и существует в таком виде только лишь, чтобы продавать разные книжки или курсы человеку, который в этом всем не разбирается.
Сидеть и ограничивать себя в возможностях использовать данные так как тебе хочется, подбирать паттерны часами, надеясь найти подходящий, пытаться соблюдать "лучшие практики", солид, кисс, драй, ай, вай, а потом плакать в тг чатах, что уже год делаешь клон флеппи берд и не можешь доделать, потому что сложно все очень и запутанно. Типичный современный "программист".

Почему рекомендуется использовать private а не просто ставить везде Public?

Василий Банников, Плохо гуглил.


Чтобы найти пример, можешь прочитать практически любую статью/книжку/гайд про "правильное программирование", где тебе будут втирать, что нужно делать как можно больше маленьких классов для абсолютно тривиальных вещей.

Если тебе это не очевидно, соболезную.
В чем заключается ценность приватных полей, если они абсолютно везде? Каким образом понять, что поле следует сделать публичным?
Предвосхищая зеркальный вопрос на вопрос:

• Если у тебя в проекте условно 5% приватных полей от всего кол-ва полей, то ВНЕЗАПНО, приватные поля не просто так понапиханы, а они должны тут быть. И говорит о том, что они должны тут быть тот факт, что приватные поля - редкость, исключение из правил.
  
• Поле следует сделать приватным, если оно не должно быть доступно никому извне даже для чтения. Как пример - мьютекс должен быть приватным.
  

Удивительно сложный рефакторинг - нажать две кнопки в райдере или любом другом иде.

Зачем тогда приводить этот пример, если он примитивный и несостоятельный? Можешь, вместо того, чтобы отвечать на все остальные вопросы, привести пример того, как реализовать статы персонажа (сила, ловкость и тд) не используя публичные поля и чтобы это все было потом удобно использовать.

В чем заключается хрупкость? То, что мододел сломал все, не почитав документацию, проблема исключительно мододела.