По некоторым вопросам движка автор выразился слишком критично. И статический батчинг и лайтмапы и Occlusion можно заставить работать с подгрузкой уровня, это описано в документации и управляется из кода. Да, неудобно и нужно писать руками вспомогательные утилиты, но апи для этого всё же есть.
Не представляю, как можно в 2020 году в мультиплеерной игре сделать не авторитарный сервер. Тут бороться не с читерами нужно а со своим сетевым стеком.
Заметил что на шариках в гифках отражение не правильно смещается. Получается как буд-то шарик полупрозрачный как ёлочная игрушка. Должно же быть не так?
Странно что так мало оценок, очень важная и полезная статья! Сейчас культура работы с LWRP только зачинается и никаких best practice еще не устоялось! Респект!
На сколько сложно теперь подвязать к этому шейдеру Master Node и расширять с помощью Shader Graph?
Даже только для того чтобы нельзя было в таких вопиющих случаях ссылаться на правила хабра, призываю руководство портала рассмотреть коррекцию этого пункта правил. Все и так понимают кто в стране кто и пора иметь профессиональную площадку где это можно заявлять. Многие действия или бездействия в нашей стране отражаются на профессиональном сообществе, сейчас это приходится читать только между строк. Чем лучше информация распространяется, тем больше мы можем сделать для людей, которых система ест прямо сейчас.
А сами проверки производились в редакторе? Какая версия редактора была? (UPD: пропустил, оказывается есть в статье) Была ли включена настройка Editor Attaching? Были ли отключены проверки безопасности для нативных коллекций и вообще?
Я считаю что самый правильный способ сравнивать эти цифры, это делать сборку на целевую платформу, выключив все проверки и development build option, тогда вариант 3 станет эффективнее на порядки раз, судя по замерам моей команды. Хотя мы не с Actors, а с Entities тестируем.
Забавно, но мы столкнулись с другой проблемой, хоть вариант 3 самый эффективный, в редакторе на большом проекте работать все равно нормально невозможно так как всё тормозит. А галочка Editor Attaching работает только с перезапуском редактора, что неудобно, дебагер нужно подключать всегда не вовремя.
Разработка роботов началась несколько лет назад и там использовались немного другие подходы к проектированию. Чуть подробнее можно прочитать в статье нашего СТО Сергея Жданова “Почему мы не стали делать идеально” habr.com/company/pixonic/blog/346374
Вы пытаетесь оптимизировать тот этап, который и не планировался быть быстрым. Сжатие текстур, подсчет хешей, сбор бандлов — это всегда будет долго выполняться, не нужно это оптимизировать пока не мешает работе. Во все времена, для трудоемких операций использовали кеш чтобы не делать ненужную работу. В вашей статье по кеш-сервер и его варианты не написано совсем, а рекомендовать в первую очередь нужно именно его, а не покупку новых машин. Для сложных случаев есть локальный кеш в коробке с редактором.
По поводу карт освещения — оно как раз делается с использованием GPU, и, по логике, должно версионироваться синхронно со сценой. В настройках запекания тоже есть опции для быстрого превью вместо полного прохода.
Отличный вопрос! При первоначальном исследовании фотона и eNet — внутри него я не обнаружил стратегии доставки Reliable-unOrdered. Это означает что пакеты, пришедшие не в том порядке могут быть молчаливо пропущены. В случае с нашим инпутом это вредно — у нас есть кейс, когда мы не можем выстрелить ракетой сейчас по какой либо причине, но должны сделать это в симуляции при выходе из блокирующего состояния. Может у меня устаревшая информация и апи фотона стало гибче в этом плане?
Да, клиент — «телевизор», верит только серверу. Лишь изредка экстраполирует по примитивным правилам для поддержания плавности при высокой потере пакетов. Симуляция на клиенте нужна только для отладки и работы оффлайн. Например: стартовое обучение бою. Поддерживать подключение к серверу расточительно и излишне влияет на воронку прохождения — мы запускаем симуляцию с ботами локально на девайсе.
Технически, мы поддерживаем любой пинг в ущерб быстрой реакции на ввод. Но с пингом выше 300 играть не рекомендуется, необратимо портится игровой опыт. В итоге все сводится к вопросу расположения и стоимости серверов.
Игровой сервер — NET приложение на фреймворке Photon, Unity в сервере не участвует.
В симуляции используем отдельную 2D физику (VolatilePhysics) и периодически туда контрибьютим, т.к. в ней есть конкретные баги. Нам повезло, что мы смогли упростить взаимодействия до столкновений неупругих примитивов + рейкастов (сферические и обычные) для расчета видимости и попаданий.
Как при игре по сети вы боретесь с задержкой результатов ввода? Клиент ждет результат от сервера или отправляет на сервер ввод и действия постфактум а сервер верит?
Лучше забыть про юнити-опыт и изучать по Э.Троелсену, тренируясь в консольных приложениях и так далее по NET. стеку. Одна из плохих особенностей юнити, это то, что вы привыкаете работать в рамках фреймворка и не прививаете себе мышление использования инверсии зависимостей.
Это не верно. Средство редактирования кода никак не влияет на его выполнение. У вас что в моноДевелоп, что в студии, что в райдере будет при сборке вызываться один и тот же компилятор.
По некоторым вопросам движка автор выразился слишком критично. И статический батчинг и лайтмапы и Occlusion можно заставить работать с подгрузкой уровня, это описано в документации и управляется из кода. Да, неудобно и нужно писать руками вспомогательные утилиты, но апи для этого всё же есть.
Выглядит что и в исходниках так же. Чекните юзинги, такое не соберется как я догадываюсь. https://github.com/HolyMonkey/unity-typed-scenes/blob/master/Assets/Plugins/TypedScenes/Core/TypedScene.cs
AssetDatabase API доступен только в редакторе, у вас разве код соберется вообще из примера?
На сколько сложно теперь подвязать к этому шейдеру Master Node и расширять с помощью Shader Graph?
Я считаю что самый правильный способ сравнивать эти цифры, это делать сборку на целевую платформу, выключив все проверки и development build option, тогда вариант 3 станет эффективнее на порядки раз, судя по замерам моей команды. Хотя мы не с Actors, а с Entities тестируем.
Забавно, но мы столкнулись с другой проблемой, хоть вариант 3 самый эффективный, в редакторе на большом проекте работать все равно нормально невозможно так как всё тормозит. А галочка Editor Attaching работает только с перезапуском редактора, что неудобно, дебагер нужно подключать всегда не вовремя.
Второй аргумент показывает максимум диапазона значений не включая саму границу. S всегда будет равно 1.
Вот док, для float и int различное поведение, что логично:
docs.unity3d.com/ru/530/ScriptReference/Random.Range.html
По поводу карт освещения — оно как раз делается с использованием GPU, и, по логике, должно версионироваться синхронно со сценой. В настройках запекания тоже есть опции для быстрого превью вместо полного прохода.
В симуляции используем отдельную 2D физику (VolatilePhysics) и периодически туда контрибьютим, т.к. в ней есть конкретные баги. Нам повезло, что мы смогли упростить взаимодействия до столкновений неупругих примитивов + рейкастов (сферические и обычные) для расчета видимости и попаданий.