1 – Насчет SO я в принципе согласен. Если первая мысль при решении проблемы – использовать СОшки, значит есть другое решение. Но и полностью отрицать СО нельзя. Их можно использовать для создании данных для уровней , использовать пустые СО в виде ID, использовать в качестве конфига игры, который будет пылиться в DI или Service Locator.
2 – Сатик поля для доступа к объектам. Ну да, не хорошо, я бы так не делал и другим бы не позволил, но в качестве альтернативы ServiceLocator или простого DI для студентов подойдет. Я бы лично для небольшого проекта, да и для любого использовал ServiceLocator такого вот вида. Есть пить не просит, с рефлексий не балуется - ну и пускай существует.
public class Services<T>
{
private T _service;
private static Services<T> _i;
public static Services<T> S=>_i??=new Services<T>();
public T Get() => _service;
public T Set(T service) => _service = service;
}
Почему нужен Di\ServiceLocator? У тебя будет как минимум Controller сцены, который обязан её инициализировать при её загрузке: спавн уровня, спавно игрока, иницилизация всех других сущностей теми, которых он только что заспавнил. А ещё точно будет Mediator между игрой и всем UI. Вот уже как минимум две сущности, к которым захочется достучаться в любое время и им как раз самое место в DI, ServiceLocator или на худой конец в статики.
3 – Про MVC. Вот тут чистое имхо, ногами не бить. MVC в юнити с вероятностью 99 процентов не нужен, но если его все же использовать то модель должна быть точно такой же компонентной. То есть мы имеем какой-нибудь DataObject с CURD интерфейсом. А это за собой тянет следующие вещи:
Интеграцию с юнити инспектором
Отдельный редактор если надо посмотреть базу вне юнити
Система сохранение этих штук в отдельный файл
Если файл большой, то придется использовать кокой нибудь b-tree, чтобы просто этот объем не хранить в оперативки, а иметь к нему доступ, как мы имеем доступ к ассетам в редакторе через AssetDatabase.
А ещё может понадобиться язык сценариев, например JINT (реализация JS). Это заместо UnityAction или UltEvent, которых не будет в базе.
В итого это мини DataBase. Я такое искал – не нашел, если у кого-то есть ссылка, то милейше прошу поделиться. Иначе придется писать свой, использую BplusDotNet.
4 – тут исключительно согласен. Больше компонентов богу компонентов. А ещё если сверху приправить Odin и новым UI Toolkit с котором писать свои редакторы стало в разы проще, то работа с юнити становится просто наслаждением.
5 – Тоже согласен. Только я бы хотел добавить, что не надо бояться создавать пустые MonoBeh или SO. Такие пустые классы могут служить марками для других классов, которые будут работать с теми game object, на которых навешена пустышка.
У юнити появился новый visual element, благодаря которому сделать кастомный редактор для чего угодно стало не в пример проще. Хоть свои кастомные поля для int, string, object можно запилить, создав класс от visual element.
А как в unigine обстоят дела с созданием редактора? Просто ли добавить части инспектора в окно scene view? Можно ли создавать свои 3д handler для сцены?
1 – Насчет SO я в принципе согласен. Если первая мысль при решении проблемы – использовать СОшки, значит есть другое решение. Но и полностью отрицать СО нельзя. Их можно использовать для создании данных для уровней , использовать пустые СО в виде ID, использовать в качестве конфига игры, который будет пылиться в DI или Service Locator.
2 – Сатик поля для доступа к объектам. Ну да, не хорошо, я бы так не делал и другим бы не позволил, но в качестве альтернативы ServiceLocator или простого DI для студентов подойдет. Я бы лично для небольшого проекта, да и для любого использовал ServiceLocator такого вот вида. Есть пить не просит, с рефлексий не балуется - ну и пускай существует.
Почему нужен Di\ServiceLocator? У тебя будет как минимум Controller сцены, который обязан её инициализировать при её загрузке: спавн уровня, спавно игрока, иницилизация всех других сущностей теми, которых он только что заспавнил. А ещё точно будет Mediator между игрой и всем UI. Вот уже как минимум две сущности, к которым захочется достучаться в любое время и им как раз самое место в DI, ServiceLocator или на худой конец в статики.
3 – Про MVC. Вот тут чистое имхо, ногами не бить. MVC в юнити с вероятностью 99 процентов не нужен, но если его все же использовать то модель должна быть точно такой же компонентной. То есть мы имеем какой-нибудь DataObject с CURD интерфейсом. А это за собой тянет следующие вещи:
Интеграцию с юнити инспектором
Отдельный редактор если надо посмотреть базу вне юнити
Система сохранение этих штук в отдельный файл
Если файл большой, то придется использовать кокой нибудь b-tree, чтобы просто этот объем не хранить в оперативки, а иметь к нему доступ, как мы имеем доступ к ассетам в редакторе через AssetDatabase.
А ещё может понадобиться язык сценариев, например JINT (реализация JS). Это заместо UnityAction или UltEvent, которых не будет в базе.
В итого это мини DataBase. Я такое искал – не нашел, если у кого-то есть ссылка, то милейше прошу поделиться. Иначе придется писать свой, использую BplusDotNet.
4 – тут исключительно согласен. Больше компонентов богу компонентов. А ещё если сверху приправить Odin и новым UI Toolkit с котором писать свои редакторы стало в разы проще, то работа с юнити становится просто наслаждением.
5 – Тоже согласен. Только я бы хотел добавить, что не надо бояться создавать пустые MonoBeh или SO. Такие пустые классы могут служить марками для других классов, которые будут работать с теми game object, на которых навешена пустышка.
У юнити появился новый visual element, благодаря которому сделать кастомный редактор для чего угодно стало не в пример проще. Хоть свои кастомные поля для int, string, object можно запилить, создав класс от visual element.
А как в unigine обстоят дела с созданием редактора? Просто ли добавить части инспектора в окно scene view? Можно ли создавать свои 3д handler для сцены?
Надеюсь этот язык найдет применение в юнити, а то постоянные перекомпиляции проекта немного уже надоели.