Обычно после обновления нахожу переменную ответственную за путь и меняю на соответствующий
Это адская боль при апдейте ассетов, особенно если их больше 3-4.
вызывает неопределённое поведение иногда
я написал, почему так и это не фиксится, ибо специфика работы текущей версии юнити. Оно заработает как только юнитеки будут брать платформозависимые папки Android/iOS из любой вложенности иерархии проекта (как сейчас делается для Editor) — на данный момент все постбилд-скрипты должны лежать в /Plugins/<платформа> папке.
заведите папку addons или extensions и все-все-все сторонние дополнения старайтесь сохранить в ней.
К сожалению это часто невозможно, т.к. в плагинах прошиты абсолютные пути от Assets или используется папка Plugins/Android или Plugins/iOS — юнити смотрит платформозависимые вещи только в корневой папке.
namespace Client.Common {
sealed class PlayerManager : UnitySingleton<PlayerManager> {
public PlayerSettings Settings { get; private set; }
public PlayerProgress Progress { get; private set; }
public PlayerSession Session { get; private set; }
protected override void OnConstruct () {
base.OnConstruct ();
DontDestroyOnLoad (gameObject);
Session = new PlayerSession ();
LoadSettings ();
SaveSettings ();
LoadProgress ();
SaveProgress ();
}
void LoadSettings () {
// грузим Settings из PlayerPrefs или из Persistent-хранилища
}
public void SaveSettings () {
// сохраняем Settings в PlayerPrefs или в Persistent-хранилище
}
public void LoadProgress () {
// грузим локальный прогресс
}
public void SaveProgress () {
// сохраняем локальный прогресс
}
}
}
sealed class PlayerSettings {
[JsonName ("o1")]
public float SoundVolume = 1f;
[JsonName ("o2")]
public float MusicVolume = 1f;
}
// по аналогии - другие классы-холдеры данных, с Json-сериализацией.
Смысл в том, что не нужно ничего никуда вешать — просто потрогать инстанс этого провайдера данных и он будет сам следить за собой + предоставлять централизованное апи для работы с кросс-сценовыми данными. PlayerSettings — настройки пользователя (звук и прочее), PlayerProgress — если есть локальная кампания в синглплеере, то данные можно хранить и предоставлять так, PlayerSession — данные текущей игровой сессии, должны сбрасываться при смерти игрока и начале новой сессии. Как-то так. Т.е. основной смысл — хранить данные, по которым уже можно выполнять генерацию контента в каждой отдельно взятой сцене. Можно сделать и на pure-C# классах и как-то кидать линки, но если нужна реакция на события жизненного цикла MonoBehaviour, то это самый простой способ.
Поспорить? Я вроде как процитировал то, к чему писал комментарий, где там было про передачу данных между сценами? И да, в этом синглтон без привязки к данным сцены тоже неплох (например, хранение настроек клиента игрока, его прогресса, для централизованного сохранения и использования в качестве контейнера для данных, которые требуются во всех сценах), ибо возможна реакция на события жизненного цикла MonoBehaviour, например, можно поймать момент загрузки сцены. Вот повсеместное и бездумное использование статик-классов считаю вредным, за редким исключением — синглтоны довольно просто перепиливаются под отдельный инстанс, а вот статику так просто не переделать.
Синглтоны плохи тем, что они остаются в памяти даже тогда, когда уже и не нужны, а убрать их оттуда сложнее чем разрушить объект.
Да неужели? Уже ведь была обсосана тема на хабре про синглтоны и их время жизни. Пример в этой статье — плохой, отсутствует механизм проверки существования инстанса для учета, например, в OnDestroy и тп деструктивных эвентах. Более «прямой» вариант можно посмотреть тут: можно узнать, создан ли синглтон, можно сделать обработку Awake-а для одного инстанса (а не для всех попыток создания копию), по умолчанию это локальный для сцены синглтон (умрет при смене сцены корректно), если требуется глобальный — можно в перегрузке OnConstruct() добавить DontDestroyOnLoad (полезно для всяких глобальных провайдеров данных и сетевых решений).
Судя по всему целевой платформой является исключительно Windows, потому что под другими платформами начинается адский ад при использовании разных контроллеров. Самые большие проблемы вызвал xbox360 контроллер, который выдавал безумные результаты под osx (где еще нужно постараться его завести через левые драйвера от коммунити) и под андроид: где-то триггеры выдавали значение вкл-выкл (0,1, без плавной интерполяции по силе нажатия), где-то левый триггер выдавал диапазон [-1,0], а правый [0,+1] по одной оси! Те можно было ткнуть оба и полуить одновременно -1 и +1. Те же проблемы с D-pad-ом, где-то детектится как 2 оси, где-то — как 4 независимые кнопки. Аналогично — правый стик. После всех опытов было выяснено, что единообразно работает только левый стик на всех контроллерах, все остальное — абсолютно в разнобой, причем одни и те же контролы на одном и том же контроллере могут мапиться абсолютно на разные номера кнопок / осей на разных платформах. Единственным исключением стал ps3 / ps4 контроллер — он работал всегда и везде единообразно. Собственно, из-за этого адского ада существуют фреймворки, пытающися по имени вендора контроллера перемапить внутри себя всю эту мешанину. Вывод: или избегайте контроллеры по-максимуму, или будете иметь максимальную боль на разных платформах.
Да и перевод не блещет качеством. «Reflection» — это уже устоявшийся акроним, который не должен переводиться вообще или хотя бы не быть прямым переводом на русский.
С unity 5.x появилась поддержка графов на базе аниматора и StateMachineBehaviour — свой огород можно больше не городить, а гонять штатный. На ноды графа теперь можно вешать компоненты с методами-реакциями на вход-выход в / из ноды, например, как тут.
Бесконтрольно — значит инстанцируются и уничтожаются без дополнительной обработки. По сути — это самые тяжелые операции (инстанцирование само по себе, уничтожение — в результате копится мусор, который однажды будет собран GarbageCollector-ом с фризом основного потока). Чтобы такого не было, применяют разные техники, например, пулинг: когда требуется много одинаковых объектов создавать / уничтожать, мы просто не уничтожаем их, а прячем и кладем в очередь на будущее использование; когда в следующий раз потребуется инстанцировать такой объект — сначала проверяем эту очередь и берем инстанс оттуда (настраиваем позицию, свойства и тп — все как для нового инстанса). В результате память через какое-то время перестает выделяться и течь в GC — инстансы будут переиспользоваться по кругу.
Пример реализации: PoolContainer
Пример использования (тут лучше смотреть в тестовую сцену — на префабе висит RecycleAfterTime): PoolingTest
Все, что связано с физикой — может двигаться только в FixedUpdate (частота вызовов FixedUpdate соответствует частоте симуляции физики). Цепочка проста: используем двигающиеся колайдеры -> используем rigidbody на них -> двигаем только в FixedUpdate. Если двигать в Update / LateUpdate — мы будем двигать чаще чем физика будет симулироваться и это приведет к дрожанию и протыканию колайдеров со всякими неопределенными поведениями.
Многие заметили, что статья и видео похожи на уроки с этого канала. От части это так. Но я позаимствовал только лишь расстановку вэйпоинтов и построение уровня.
Это не так, повзаимствованы все косяки и нежелание их исправлять, т.е. статья просто перевод — так ее и надо оформлять. В комментах к прошлому переводу были ссылки на best practices. Что в итоге? На крипах опять колайдер без Rigidbody, двигаются они в Update, а спаунятся и умирают бесконтрольно (привет, фризы на GC).
Да на том же хабре говорилось ни раз про всякие best practices, про то, что колайдеры считаются physx-ом статичным миром если не помечены rigidbody и их перемещение приводит к полному перестроению статичного мира физики (в unity5 это немного пофиксили с обновлением physx, но сама проблема осталась). Так же были статьи про tower defense на юнити — эта статья хуже по всем параметрам: учит плохому, информации практически не несет по сравнению с аналогами.
Это адская боль при апдейте ассетов, особенно если их больше 3-4.
я написал, почему так и это не фиксится, ибо специфика работы текущей версии юнити. Оно заработает как только юнитеки будут брать платформозависимые папки Android/iOS из любой вложенности иерархии проекта (как сейчас делается для Editor) — на данный момент все постбилд-скрипты должны лежать в /Plugins/<платформа> папке.
К сожалению это часто невозможно, т.к. в плагинах прошиты абсолютные пути от Assets или используется папка Plugins/Android или Plugins/iOS — юнити смотрит платформозависимые вещи только в корневой папке.
Смысл в том, что не нужно ничего никуда вешать — просто потрогать инстанс этого провайдера данных и он будет сам следить за собой + предоставлять централизованное апи для работы с кросс-сценовыми данными. PlayerSettings — настройки пользователя (звук и прочее), PlayerProgress — если есть локальная кампания в синглплеере, то данные можно хранить и предоставлять так, PlayerSession — данные текущей игровой сессии, должны сбрасываться при смерти игрока и начале новой сессии. Как-то так. Т.е. основной смысл — хранить данные, по которым уже можно выполнять генерацию контента в каждой отдельно взятой сцене. Можно сделать и на pure-C# классах и как-то кидать линки, но если нужна реакция на события жизненного цикла MonoBehaviour, то это самый простой способ.
Да неужели? Уже ведь была обсосана тема на хабре про синглтоны и их время жизни. Пример в этой статье — плохой, отсутствует механизм проверки существования инстанса для учета, например, в OnDestroy и тп деструктивных эвентах. Более «прямой» вариант можно посмотреть тут: можно узнать, создан ли синглтон, можно сделать обработку Awake-а для одного инстанса (а не для всех попыток создания копию), по умолчанию это локальный для сцены синглтон (умрет при смене сцены корректно), если требуется глобальный — можно в перегрузке OnConstruct() добавить DontDestroyOnLoad (полезно для всяких глобальных провайдеров данных и сетевых решений).
Такое может называться скрипт-языком, годящимся в качестве клея для вызова апи? Реализация (coco/r + обертка).
Судя по всему у друга что-то не срослось, раз стал бывшим.
Пример реализации: PoolContainer
Пример использования (тут лучше смотреть в тестовую сцену — на префабе висит RecycleAfterTime): PoolingTest
Это не так, повзаимствованы все косяки и нежелание их исправлять, т.е. статья просто перевод — так ее и надо оформлять. В комментах к прошлому переводу были ссылки на best practices. Что в итоге? На крипах опять колайдер без Rigidbody, двигаются они в Update, а спаунятся и умирают бесконтрольно (привет, фризы на GC).