Необходимость рекомпиляции кода после его изменения — это особенность стека, на котором работает Unity. Чтобы правки подхватились, необходимо пересобрать assembly с изменённым кодом. И чем больше assembly, тем дольше оно будет пересобираться.
Также Unity ещё нужно домен перезагрузить: статику сбросить и пр. формальности, чтобы стартануть Playmode с актуального и чистого листа.
Немного сгладить ситуацию можно, отключив автоматическую рекомпиляцию и перезагрузку домена (см. скриншоты). Я это делаю только вручную по Ctrl+R.
Постоянный deprecated — это уже мем в сфере Unity. Так и живём. Это нормально. Но со временем оно становится стабильнее и таких неприятностей с пакетами, которые находятся в официальном релизе, всё меньше.
Большое спасибо за проделанную работу! Контента по этой теме действительно немного, особенно написанного доступно и просто. Ради шутки даже вбил SharedLogic в поиск по Хабру — результат, как говорится, налицо.
Планировал и сам подобный ликбез оформить, но теперь уже просто буду ссылаться на этот материал в смежных работах.
Для улучшения производительности мы в командах ещё применяем батчинг команд, когда несколько команд отправляются на валидацию серверу одним пакетом. Т.к. всё локально и так просчитывается, клиент имеет возможность подождать чуть подольше, чтобы накопить команды. Но при такой реализации появляется больше сложностей с откатами в случае проблем.
p.s. "Вот результаты его выполнения на AMD Ryzen 9 5900X (12 cores) " дважды повторяется
Благодарю за ценное замечание. Вообще, честно, я и не встречал его применения в реальной практике, только в качестве примера во всяческих учебных пособиях. Как оказалось, не зря 🙂
Там такой глубокий вьетнамский флешбек, что многие (и я) до сих пор кэшируют всё, что можно, чтобы лишний раз Unity не дёргать. Сегодня кэшируется, а в завтрашнем обновлении – нет. И то ли баг, то ли фича. То ли исправят, то ли нет. Увлекательная игра 😁
Если побенчмаркать, то кастомное кэширование всё равно немножечко, но всё же эффективнее. Хотя в Unity 6 может успели ещё докрутить этот момент.
Отличная статья: полезный и хорошо приготовленный контент! Отметил ряд моментов, о которых нечасто упоминают в статьях о Unity. В т.ч. про свою реализацию SyncronizationContext. Такие мелочи важно знать и помнить.
Небольшая корректировка: у Unity и своя реализация GC, отличная от .NET. Могу подкинуть эту статью по этой теме.
Дополнение про UniTask: они полноценно работают в вебе.
Можно, наверное, можно ещё упомянуть про UI на Canvas'ах. Там уже вместо Transform используется его наследник — RectTransform. Порядок элементов на сцене влияет на порядок отрисовки. Ну и сам канвас имеет свою специфику в плане отрисовки.
И может будет интересно сравнить Unity UI Toolkit с упомянутым в статье WPF.
По клиент-серверной архитектуре материала очень много. Вбивание в поисковую строку выдаст множество актуальных ссылок по теме разной степени сложности. С этим проблем никаких нет.
Что касается Netcode For Entities — здесь не подскажу. Не знаком. Весь их DOTS — это сплошной "движок в движке". В production-режиме возможно использовать только Job System и Burst Compiler. По другим элементам DOTS'а я живой информации про реальное использование не встречал. Все только пробуют и ставят обратно на полочку.
Я пробовал их ECS-решение, следил за всеми версиями пока они были в бете. После оф. релиза нравиться больше не стало. Соответственно и в сторону соответствующего Netcode не было смысла смотреть.
Соседняя команда с большей экспертизой по ECS проводила RnD Photon Quantum. В целом, примерно аналогичное решение. Вердикт: прикольно, но излишне сложно. На проектах нашего масштаба использовать слишком неудобно и неоправданно. По итогу взяли Mirror и натянули на свой ECS-фреймворк.
Лезть в NfE имеет смысл только тогда, когда имеется глубокая экспертиза как по ECS, так и по неткоду. Начинать изучение неткода с NfE — на мой взгляд, большая ошибка, которая сильно затормозит и наведёт только больше беспорядка в голове.
Благодарю за дополнения — подумаю над тем, как их вписать в текущую структуру 🙏
Про симуляцию вычислений на клиентах и вынесение вердикта сервером по-моему где-то в тексте мельком упоминалось. Чуть подробнее и более явно писал в предыдущей части. И более пристальное внимание планирую уделить в части про способы компенсации задержек. Здесь я хотел сделать акцент больше на том, что подобная гибкость вообще есть. А для чего она — уже как-будто вопросы другого порядка.
Детерминированная симуляция с синхронизацией через команды — достаточно ходовой подход. Я бы не стал это завязывать на P2P: это легальный способ сократить объём траффика на любой топологии. Я бы скорее это связал со скоростью геймплея. Если игра достаточно slow-paced — лучше варианта не придумать: для меты классно подходит, всяческие баттлеры и матч-3 хорошо делались. Но с повышением скорости геймплея разработка в такой парадигме усложняется. Для шутеров и shoot'em'up'ов по-моему даже пытаться бессмысленно. А для синка большого кол-ва NPC есть и другие "велосипеды". Например, объединение в группы и синк не каждого непися в отдельности, а всей группы как единого объекта с определённой долей свободы локальной симуляции в рамках группы.
Классный тейк про стратегии — об этом не думал. Экспертизы, даже с точки зрения игрока, в этом жанре не имею, но почему-то тоже кажется, что здесь всё упрётся по итогу к скорости игры.
Спасибо за работу – с большим удовольствием обработал статью и растаскал на цитаты :) Каталка для ног – супер лайфхак, тоже до него случайно дошёл. Когда резко похолодало и ногам было холодно на полу, утащил у супруги небольшой ролл для фитнеса – так и не отдал 😁
Нечасто удаётся встретить реальных пользователей FishNet на реальных и серьёзных проектах – классный кейс 👍
Если текущая реализация не доставляет проблем, работа с ней всем на проекте удобна и понятна, геймдизы получают что хотят, а игровые сервера (при их наличии) не бьют по кошельку, то отличный подход.
Цели разработки: - чтобы работало; - чтобы дальше расширялось; - чтобы входные требования удовлетворялись; - чтобы отдел разработки не страдал.
Если все цели достигнуты, то не нужно бежать за «лучшей жизнью» и решать «надуманные проблемы». Всё уже сделано.
В описанной схеме красных флажков не увидел. С точки оптимизации, если на каждую абилку нужно создавать новый GameObject с навешанным NetworkBehaviour, то стоит завести пул сетевых объектов (если его ещё нет). А если FishNet позволяет динамически NetworkBehaviour навешивать, без инстанциирования лишних GameObject, то замечательно.
Представление – это Presentation Layer, если выражаться терминами N-Layer. Или View, если выражаться терминами MVx. Слой приложения, который отвечает за взаимодействие с пользователем: считывание инпута, отрисовка картинки, воспроизведение звуков, вибро и пр. Опосредованная связь с этим слоем позволяет менять его реализации или убирать совсем, чтобы, например, запускать в режиме игрового сервера как терминальное приложение.
Шина команд нужна, если требуется наладить координацию между модулями или слоями проекта без явного связывания. Т.е. это один из инструментов для налаживания общения с Представлением, если не хочется, чтобы от него кто-то явно зависел.
То, что тряска камеры находится в контроллере камеры – ничего страшного нет, если так удобно. Кто это и как это вызывает – более важный аспект. Но беспокоит ли это? Если явных проблем с механикой нет, то лучше гнездо лишний раз не тормошить. Хорошее сделать лучше сложно 😁
Очень приятно получить такой отзыв — это вдохновляет и вносит вклад в калибровку ещё формирующегося стиля. Рад, что эта работа смогла оказаться полезной. Спасибо за обратную связь — буду учитывать это при поиске и подготовке новых тем!
Спасибо за полезный и интересный контент.
В разделе 2.3 последнее предложение обрывается:
"при необходимости - создает или обновляет гайд в
guides/с примерами использования или ..."Спасибо за уточнение, добавил в список на тестирование 📝
На момент моего RnD он ещё не имел агентного режима и поддержку MCP. Сейчас вижу, что уже добавили. Хотя последние отзывы пока удручают 🫠
Спасибо за рекомендацию, не встречал ранее Sweep AI — выглядит интересно, буду пробовать 👍
Windsurf использую два последних месяца — пока показывает себя стабильно, даже пожаловаться не на что 🫠
Для Odin, пожалуй, альтернатив лучше и нет 🔝
С Debugging Essentials не сталкивался — положил в список для отслеживания, спасибо за рекомендацию 📚
Будь оно иишной, обошлось бы без опечатки — текст они уже давно нормально умеют генерировать :)
Ранее уже верно прокомментировали эти моменты.
Необходимость рекомпиляции кода после его изменения — это особенность стека, на котором работает Unity. Чтобы правки подхватились, необходимо пересобрать assembly с изменённым кодом. И чем больше assembly, тем дольше оно будет пересобираться.
Также Unity ещё нужно домен перезагрузить: статику сбросить и пр. формальности, чтобы стартануть Playmode с актуального и чистого листа.
Подробнее - в оф. доке
Немного сгладить ситуацию можно, отключив автоматическую рекомпиляцию и перезагрузку домена (см. скриншоты). Я это делаю только вручную по
Ctrl+R.Постоянный deprecated — это уже мем в сфере Unity. Так и живём. Это нормально. Но со временем оно становится стабильнее и таких неприятностей с пакетами, которые находятся в официальном релизе, всё меньше.
Большое спасибо за проделанную работу! Контента по этой теме действительно немного, особенно написанного доступно и просто. Ради шутки даже вбил
SharedLogicв поиск по Хабру — результат, как говорится, налицо.Планировал и сам подобный ликбез оформить, но теперь уже просто буду ссылаться на этот материал в смежных работах.
Для улучшения производительности мы в командах ещё применяем батчинг команд, когда несколько команд отправляются на валидацию серверу одним пакетом. Т.к. всё локально и так просчитывается, клиент имеет возможность подождать чуть подольше, чтобы накопить команды. Но при такой реализации появляется больше сложностей с откатами в случае проблем.
p.s. "Вот результаты его выполнения на AMD Ryzen 9 5900X (12 cores) " дважды повторяется
Благодарю за ценное замечание. Вообще, честно, я и не встречал его применения в реальной практике, только в качестве примера во всяческих учебных пособиях. Как оказалось, не зря 🙂
Там такой глубокий вьетнамский флешбек, что многие (и я) до сих пор кэшируют всё, что можно, чтобы лишний раз Unity не дёргать. Сегодня кэшируется, а в завтрашнем обновлении – нет. И то ли баг, то ли фича. То ли исправят, то ли нет. Увлекательная игра 😁
Если побенчмаркать, то кастомное кэширование всё равно немножечко, но всё же эффективнее. Хотя в Unity 6 может успели ещё докрутить этот момент.
Отличная статья: полезный и хорошо приготовленный контент!
Отметил ряд моментов, о которых нечасто упоминают в статьях о Unity. В т.ч. про свою реализацию
SyncronizationContext. Такие мелочи важно знать и помнить.Небольшая корректировка: у Unity и своя реализация GC, отличная от .NET. Могу подкинуть эту статью по этой теме.
Дополнение про UniTask: они полноценно работают в вебе.
Можно, наверное, можно ещё упомянуть про
UIнаCanvas'ах. Там уже вместоTransformиспользуется его наследник —RectTransform. Порядок элементов на сцене влияет на порядок отрисовки. Ну и сам канвас имеет свою специфику в плане отрисовки.И может будет интересно сравнить Unity UI Toolkit с упомянутым в статье WPF.
По клиент-серверной архитектуре материала очень много. Вбивание в поисковую строку выдаст множество актуальных ссылок по теме разной степени сложности. С этим проблем никаких нет.
Что касается Netcode For Entities — здесь не подскажу. Не знаком. Весь их DOTS — это сплошной "движок в движке". В production-режиме возможно использовать только Job System и Burst Compiler. По другим элементам DOTS'а я живой информации про реальное использование не встречал. Все только пробуют и ставят обратно на полочку.
Я пробовал их ECS-решение, следил за всеми версиями пока они были в бете. После оф. релиза нравиться больше не стало. Соответственно и в сторону соответствующего Netcode не было смысла смотреть.
Соседняя команда с большей экспертизой по ECS проводила RnD Photon Quantum. В целом, примерно аналогичное решение. Вердикт: прикольно, но излишне сложно. На проектах нашего масштаба использовать слишком неудобно и неоправданно. По итогу взяли Mirror и натянули на свой ECS-фреймворк.
Лезть в NfE имеет смысл только тогда, когда имеется глубокая экспертиза как по ECS, так и по неткоду. Начинать изучение неткода с NfE — на мой взгляд, большая ошибка, которая сильно затормозит и наведёт только больше беспорядка в голове.
Но ведь совершенно нет....
Так в студиях-"не гигантах" тоже сокращения, в процентном соотношении вероятно даже не менее массовые.
Если сравнивать с вакансиями типа "тестировщик матрасов", то возможно и так.
Ну ведь не может.
Благодарю за отзыв 💜
Благодарю за дополнения — подумаю над тем, как их вписать в текущую структуру 🙏
Про симуляцию вычислений на клиентах и вынесение вердикта сервером по-моему где-то в тексте мельком упоминалось. Чуть подробнее и более явно писал в предыдущей части. И более пристальное внимание планирую уделить в части про способы компенсации задержек. Здесь я хотел сделать акцент больше на том, что подобная гибкость вообще есть. А для чего она — уже как-будто вопросы другого порядка.
Детерминированная симуляция с синхронизацией через команды — достаточно ходовой подход. Я бы не стал это завязывать на P2P: это легальный способ сократить объём траффика на любой топологии. Я бы скорее это связал со скоростью геймплея.
Если игра достаточно slow-paced — лучше варианта не придумать: для меты классно подходит, всяческие баттлеры и матч-3 хорошо делались.
Но с повышением скорости геймплея разработка в такой парадигме усложняется. Для шутеров и shoot'em'up'ов по-моему даже пытаться бессмысленно. А для синка большого кол-ва NPC есть и другие "велосипеды". Например, объединение в группы и синк не каждого непися в отдельности, а всей группы как единого объекта с определённой долей свободы локальной симуляции в рамках группы.
Классный тейк про стратегии — об этом не думал. Экспертизы, даже с точки зрения игрока, в этом жанре не имею, но почему-то тоже кажется, что здесь всё упрётся по итогу к скорости игры.
Спасибо за работу – с большим удовольствием обработал статью и растаскал на цитаты :)
Каталка для ног – супер лайфхак, тоже до него случайно дошёл. Когда резко похолодало и ногам было холодно на полу, утащил у супруги небольшой ролл для фитнеса – так и не отдал 😁
Благодарю за столь положительную обратную связь!
Нечасто удаётся встретить реальных пользователей FishNet на реальных и серьёзных проектах – классный кейс 👍
Если текущая реализация не доставляет проблем, работа с ней всем на проекте удобна и понятна, геймдизы получают что хотят, а игровые сервера (при их наличии) не бьют по кошельку, то отличный подход.
Цели разработки:
- чтобы работало;
- чтобы дальше расширялось;
- чтобы входные требования удовлетворялись;
- чтобы отдел разработки не страдал.
Если все цели достигнуты, то не нужно бежать за «лучшей жизнью» и решать «надуманные проблемы». Всё уже сделано.
В описанной схеме красных флажков не увидел. С точки оптимизации, если на каждую абилку нужно создавать новый
GameObjectс навешаннымNetworkBehaviour, то стоит завести пул сетевых объектов (если его ещё нет). А если FishNet позволяет динамическиNetworkBehaviourнавешивать, без инстанциирования лишнихGameObject, то замечательно.Представление – это Presentation Layer, если выражаться терминами N-Layer. Или View, если выражаться терминами MVx. Слой приложения, который отвечает за взаимодействие с пользователем: считывание инпута, отрисовка картинки, воспроизведение звуков, вибро и пр. Опосредованная связь с этим слоем позволяет менять его реализации или убирать совсем, чтобы, например, запускать в режиме игрового сервера как терминальное приложение.
Шина команд нужна, если требуется наладить координацию между модулями или слоями проекта без явного связывания. Т.е. это один из инструментов для налаживания общения с Представлением, если не хочется, чтобы от него кто-то явно зависел.
То, что тряска камеры находится в контроллере камеры – ничего страшного нет, если так удобно. Кто это и как это вызывает – более важный аспект. Но беспокоит ли это? Если явных проблем с механикой нет, то лучше гнездо лишний раз не тормошить. Хорошее сделать лучше сложно 😁
Пожалуйста! Рад, что материал справился со своим предназначением 🙏
Очень приятно получить такой отзыв — это вдохновляет и вносит вклад в калибровку ещё формирующегося стиля. Рад, что эта работа смогла оказаться полезной. Спасибо за обратную связь — буду учитывать это при поиске и подготовке новых тем!