А что делать, если я не хочу двигать объект физикой?
Мне нужно двигать объект и считать его коллизии. Например, у меня Tower Defence или клон Zuma. Мне нужно просто, с постоянной скоростью двигать объект из одной точки в другую.Но коллизию можно посчитать, только если есть ригидбоди.
Как именно вы предлагаете двигать объект, если не через трансформ? Вместо того, чтобы просто задать объекту новую точку, постоянно прикладывать и убирать силы?
Или через трансформ, но в Fixed Update?
Хм. Меня, похоже, не поняли. Синглтон я использую только как демонстрацию наследования статических полей. И попутно показываю, что есть такой способ делать синглтоне, если кому надо. Моя система сохранения не основана на синглтоне. Она основана на обобщённом классе поведения (контроллере), которому можно передать любую модель и таким образом легко получить сохраняемый объект, просто определив поля и не реализуя один и тот же функционал каждый раз. А потом все такие объекты можно сохранить вызовом одной функции.
Блин, классы взаимодействуют, куда от этого деться? Я предполагаю, что если человек использовал синглтон, значит, ему реально позарез надо обращаться от одного класса к другому. Для примера можно взять игрока. Методы получения урона и гибели одинаковы у игрока и врага. Но на гибель игрока игра должна особым образом реагировать. Посылается событие person.ondead, а игра должна проверить, не игрок ли преставился.
Это для примера. Я пытался сказать, что если синглтон кажется разработчику подходящим решением, то недостатки сильной связности можно устранить интерфейсами и наследованиями
Ну и компоненты у меня — тоже тут никуда не денешься. Шутер, коллизии, физика, трансформы всякие. Тут единственный способ избавиться от юнити — писать свой движок
1) Чтобы кто угодно не изменял, делаешь public get protected set
2) Я делаю следующим образом: все поля в модели public, но сама модель видна только своему контроллеру
3) Статичные публичные — у меня обычно методы. Вот тот же SaveLoadBehaviour. У него
protected static List All
А вот методы SaveAll, LoadInitAll — публичные.
4) Мне надоело писать для синглтонов MyClass.Instance.DoMethod(), я делаю MyClass.DoMethod() и в нем уже на статический инстанс ссылаюсь.
Т.е. может дело не в синглтонах, а в том, чтобы правильно их готовить?
А повышение связности когда — опять же, помогут прямые руки и ООП. Для заменяемости/удаляемости пользуйся интерфейсами, и будет тебе счастье.
В моей статье предложен подход:
1) абстрактный класс со статик полями
2) от него наследуется обобщенный класс для работы с разными моделями
3) от обощенного — конкретная реализация
Тот же подход можно применить для синглтонов
1) Интерфейс, определяющий желаемое поведение синглтона IAdapter
2) Обобщенный синглтон GenericSingletone3) Абстрактный класс, наследующий от синглтона и интерфейса.
SingletoneOne: GenericSingletone, IAdapter
4) Если мы по примеру 3 сделаем SingletoneTwo, то у них буду разные static Instance
5) А вот если мы унаследуем от SingletoneOne, то у SingletoneOne_1 и SingletoneOne_2 статический инстанс будет общим!
6) Соответственно, во всем коде работаешь с SingletoneOne.Instance.AdapterMetod()
7) А конкретную реализацию меняй как вздумается.
Я стараюсь использовать в Unity как можно меньше Unity. Ибо в реальных проектах, которые на работе за зарплат, логика часто shared или серверная.
А еще можно взять shared бизнес-логику, скомпилировать в dll и перенести на Unreal. Поэтому имхо чем меньше ScriptableObject, MonoBehaviour и прочего using UnityEngine, тем лучше.
Но вообще есть нюанс. Из разряда «нам бы ваши проблемы». Переносимость сохранений из МегаИгра1 в МегаИгра2: Воскрешение.
Мы не можем гарантировать, что какой-нибудь умник не переименует класс. Да может быть мы сами в процессе разработки что-то переименуем. И, предположим, у нас есть несколько сохранений, чтобы тестировать игру в разных местах (ну вдруг).
Короче, надо об этом очень сильно помнить.
В Юнити нельзя предсказать, в какой последовательности объекты сохранятся. И, следовательно, в какой последовательности будут храниться и загружаться.
Вообще, может, и можно: создать вручную начальное сохранение, а потом читать из него в заранее заданном порядке в начале игры, в этом же порядке хранить в коллекции и в этом же порядке записывать.
Но вообще бывает такая вещь как крафт: о) И расход ресурсов. И смерть (исчезновение) персонажей.
В общем случае набор сущностей в игре непостоянный, поэтому «сразу знать, что и где» — негибко.
Суть-то как раз в том, чтобы сделать решение, которое ложится на любой проект. Чтобы одно и то же по сто раз не писать.
И у меня пока что нет сохранения в файл, всё хранится в оперативке — и в этом все равно есть смысл, ибо загрузка последнего сохранения (чекпоинта) и рестарт уровня.
1) Спрячте под спойлер, пожалуйста.
2) Можно ли так сериализовать тип? Чтобы ридер сам знал, что читает из файла?
3) Можно ли так сериализовать всё в один файл (из коллекции) и потом прочитать это же всё и создать нужные объекты?
4) насколько удобно это для передачи по сети?
2-4 — потому что я никогда не работал с бинарной сериализацией, я во многих вопросах еще нуб.
Выглядит очень похоже на правду.
Я тоже так не пробовал. Если добавить в мое решение автоматическое полное копирование объектов, автоматическую сериализацию и автоопределение типа, то будет полностью завершенное решение.
Новое поле добавляется в модель. Копирование модели в модель пишешь сам. Хотя по идее должно же быть встроенное средство копирования объектов.
А каркас остается. Я сначала на геймсджем писал игру про котосминогов и сделал там эту систему сохранения. А потом для тестового задания про шутер просто использовал ее же, заменив модели. До самого последнего момента не знал, заработает ли. Вызвал в GameManager AbstractSaveLoad.LoadInit() для рестарта матча — и все заработало.
Конечно, лучший код — ненаписанный код и кнопочка «Сделать прекрасно». Но чем богаты.
Во всяком случае добавление новых сохраняемых сущностей происходит максимально безболезненно, проверено на двух разных проектах.
Насчет глобальных синглтонов не знаю. Но я у себя сделал самый закрытый менеджер игры.
Он у меня — такой мост между всеми подсистемами. Слушает события и вызывает нужные функции. А к самому нему никто доступ не имеет.
Все, что с ним можно сделать — проинициализировать (ну, чтобы он хоть как-то появился в памяти).
Максимально закрытый GameManager
public class GameManager
{
static int EnemiesCount;
static int EnemiesCountCurrent;
static float MatchStartSeconds;
static PlayerController player;
public static void Init()
{
player = GameObject.FindObjectOfType<PlayerController>();
player.OnDamaged += OnPlayerDamagedHandler;
AbstractAliveController.OnDead += OnAliveDeadHandler;
EnemiesCount = GameObject.FindObjectsOfType<NPC.Enemy.EnemyController>().Length;
UI.UIController.OnRestart += RestartMatch;
InitMatch();
}
}
Да. Это делается стандартными средствами юнити. А вот отличить в самом коде платформу, на которой ты стоишь от платформы, через которую ты идешь, отличить именно "коллизию стояния" — это то, что делает моё решение.
Очень поверхностно. Как насчёт Проблемы Космологической Постоянной?
Мне нужно двигать объект и считать его коллизии. Например, у меня Tower Defence или клон Zuma. Мне нужно просто, с постоянной скоростью двигать объект из одной точки в другую.Но коллизию можно посчитать, только если есть ригидбоди.
Как именно вы предлагаете двигать объект, если не через трансформ? Вместо того, чтобы просто задать объекту новую точку, постоянно прикладывать и убирать силы?
Или через трансформ, но в Fixed Update?
Блин, классы взаимодействуют, куда от этого деться? Я предполагаю, что если человек использовал синглтон, значит, ему реально позарез надо обращаться от одного класса к другому. Для примера можно взять игрока. Методы получения урона и гибели одинаковы у игрока и врага. Но на гибель игрока игра должна особым образом реагировать. Посылается событие person.ondead, а игра должна проверить, не игрок ли преставился.
Это для примера. Я пытался сказать, что если синглтон кажется разработчику подходящим решением, то недостатки сильной связности можно устранить интерфейсами и наследованиями
Ну и компоненты у меня — тоже тут никуда не денешься. Шутер, коллизии, физика, трансформы всякие. Тут единственный способ избавиться от юнити — писать свой движок
2) Я делаю следующим образом: все поля в модели public, но сама модель видна только своему контроллеру
3) Статичные публичные — у меня обычно методы. Вот тот же SaveLoadBehaviour. У него
protected static List All
А вот методы SaveAll, LoadInitAll — публичные.
4) Мне надоело писать для синглтонов MyClass.Instance.DoMethod(), я делаю MyClass.DoMethod() и в нем уже на статический инстанс ссылаюсь.
Т.е. может дело не в синглтонах, а в том, чтобы правильно их готовить?
А повышение связности когда — опять же, помогут прямые руки и ООП. Для заменяемости/удаляемости пользуйся интерфейсами, и будет тебе счастье.
В моей статье предложен подход:
1) абстрактный класс со статик полями
2) от него наследуется обобщенный класс для работы с разными моделями
3) от обощенного — конкретная реализация
Тот же подход можно применить для синглтонов
1) Интерфейс, определяющий желаемое поведение синглтона IAdapter
2) Обобщенный синглтон GenericSingletone3) Абстрактный класс, наследующий от синглтона и интерфейса.
SingletoneOne: GenericSingletone, IAdapter
4) Если мы по примеру 3 сделаем SingletoneTwo, то у них буду разные static Instance
5) А вот если мы унаследуем от SingletoneOne, то у SingletoneOne_1 и SingletoneOne_2 статический инстанс будет общим!
6) Соответственно, во всем коде работаешь с SingletoneOne.Instance.AdapterMetod()
7) А конкретную реализацию меняй как вздумается.
А еще можно взять shared бизнес-логику, скомпилировать в dll и перенести на Unreal. Поэтому имхо чем меньше ScriptableObject, MonoBehaviour и прочего using UnityEngine, тем лучше.
За утилиту спасибо: о)
Мы не можем гарантировать, что какой-нибудь умник не переименует класс. Да может быть мы сами в процессе разработки что-то переименуем. И, предположим, у нас есть несколько сохранений, чтобы тестировать игру в разных местах (ну вдруг).
Короче, надо об этом очень сильно помнить.
2) Ну и переносимость сохранений.
Так что файлы наше всё
Вообще, может, и можно: создать вручную начальное сохранение, а потом читать из него в заранее заданном порядке в начале игры, в этом же порядке хранить в коллекции и в этом же порядке записывать.
Но вообще бывает такая вещь как крафт: о) И расход ресурсов. И смерть (исчезновение) персонажей.
В общем случае набор сущностей в игре непостоянный, поэтому «сразу знать, что и где» — негибко.
И у меня пока что нет сохранения в файл, всё хранится в оперативке — и в этом все равно есть смысл, ибо загрузка последнего сохранения (чекпоинта) и рестарт уровня.
2) Можно ли так сериализовать тип? Чтобы ридер сам знал, что читает из файла?
3) Можно ли так сериализовать всё в один файл (из коллекции) и потом прочитать это же всё и создать нужные объекты?
4) насколько удобно это для передачи по сети?
2-4 — потому что я никогда не работал с бинарной сериализацией, я во многих вопросах еще нуб.
Я тоже так не пробовал. Если добавить в мое решение автоматическое полное копирование объектов, автоматическую сериализацию и автоопределение типа, то будет полностью завершенное решение.
А каркас остается. Я сначала на геймсджем писал игру про котосминогов и сделал там эту систему сохранения. А потом для тестового задания про шутер просто использовал ее же, заменив модели. До самого последнего момента не знал, заработает ли. Вызвал в GameManager AbstractSaveLoad.LoadInit() для рестарта матча — и все заработало.
Конечно, лучший код — ненаписанный код и кнопочка «Сделать прекрасно». Но чем богаты.
Во всяком случае добавление новых сохраняемых сущностей происходит максимально безболезненно, проверено на двух разных проектах.
Он у меня — такой мост между всеми подсистемами. Слушает события и вызывает нужные функции. А к самому нему никто доступ не имеет.
Все, что с ним можно сделать — проинициализировать (ну, чтобы он хоть как-то появился в памяти).
if (point.y — bounds.min.y < 0.001) типа того