Ычан: [d | b / bro / hr / l / m / mi / mu / o / ph / r / s / sci / tran / tu / tv / vg / x | au / tr | a / aa / c / fi / jp / rm / tan / to / vn / vo]
[Назад]
Ответ в нить
Имя
Animapcha image [@] [?]
Тема   ( ответ в 25313)
Сообщение flower
Файл 
Пароль  (для удаления файлов и сообщений)
Параметры   
  • Прежде чем постить, ознакомьтесь с правилами.
  • Поддерживаются файлы типов 7Z, BZ, BZ2, GIF, GZ, JPG, MO, MP3, MP4, OGG, OGV, PDF, PNG, PSD, RAR, SVG, SWF, TXT, WEBM, WEBP, XCF, ZIP размером до 5000 кБ.
  • Ныне 3710 unique user posts. Посмотреть каталог
  • Максимальное количество бампов нити: 500
movie_002.mp4 - (1.15MB, 1068×726)
25313
No. 25313    
Я все же создам новый тред, да простит меня джаббер тред внизу каталога.

Решил вкатиться в юнити. Читаю их туториалы, пока в восторге от доступности и простоты материала (по сравнению с тем, что было раньше)

Буду тут писать отчеты.

Пара ссылок:
Сайт: https://unity.com
Обучение: https://learn.unity.com
Есть тг канал: @unity3d_ru
Развернуть все изображения
No. 25314    
movie_008.mp4 - (4.50MB, 854×480)
25314
Сегодня узнал про компоненты, отвечающие за физику:
Rigid Body - позволяют объекту реагировать на гравитацию
Коллайдеры - позволяют поверхностям взаимодействовать с объектами, имеющими Rigid Body компонент.
No. 25315    
movie_002.mp4 - (2.15MB, 854×480)
25315
Еще раз отмечу туториалы. Возможно это не уникальное явление, но я впервые увидел, чтобы к обучению ПО подходили настолько тщательно. Обычно от туториалов ожидаешь рассказы про механику, принципы, интерфейс... То есть все в рамках конкретного программного продукта, как вещи в себе. Здесь же немалую долю уделяют объяснению самой индустрии и разных моментов, с ней связанных: различные ниши, карьерные возможности, подходы к проекту. Предлагают оформить цель, написать первый элементарный план. Также есть задания сделать что-то и опубликовать. Респект.
No. 25330    
movie_004.mp4 - (2.84MB, 854×480)
25330
Освоил азы работы с input, но получилось довольно сумбурно. Пришлось в одном месте даже руками сделать таймаут для исключения множественных нажатий.
No. 25336    
movie_002.mp4 - (1.12MB, 854×480)
25336
Узнал про Префабы. Это такие подготовленные (prefabricated) объекты, которые можно динамично создавать и удалять прямо в коде.
No. 25339    
movie_005.mp4 - (2.11MB, 854×480)
25339
Юнит3 Junior курса оказался богат на новые для меня фишки. Впервые потыкал компоненты:

  1. Animator. Это такая стейт машина с переходами между различными анимациями и условиями для этих переходов. Ей можно управлять, изменяя параметры, участвующие в условиях перехода.
  2. AudioSource. Можно проиграть подгруженный аудио файл. Все просто.
  3. Collision Trigger. Можно детектировать столкновения между объектами. Можно даже чекать объекты по их тегу и в зависимости от этого делать различное поведение. Сами коллайдеры еще бывают разными в зависимости от их формы.
  4. Particle System. Частицы, изменяющиеся во времени. Можно делать эффекты. Им почти как и аудио, можно сделать Play() и Stop().

No. 25364    
movie_003.mp4 - (3.91MB, 854×480)
25364
Попробовал корутины. С шарпом почти не знаком, и тут они мне показались немного необычными. В моем понимании, корутина - это что-то что с момента создания живет немного своей жизнью, но ее можно подождать (ну или события от нее послушать). Здесь же yield-ом корутина может отдать управления обратно основному циклу (прям в любом месте), при этом в нее точка выполнения вернется сама, когда ей будет это удобно..

Но корутинами удобно описывать процессы, которые должны протекать во времени в течение нескольких фреймов. В противном случае можно утонуть в бесконечных таймерах и флагах, делая это все в основной функции обновления фрейма.
No. 25389    
movie_004.mp4 - (4.27MB, 1280×720)
25389
UI оставил двоякое впечатление, с одной стороны все просто. С другой стороны, чтобы его сделать невырвиглазным, нужно постараться.
No. 25401    
Узнал сейчас про object pooling. Если один и тот же объект планируется создавать и удалять много раз, то гораздо оптимальнее будет инстанциировать лист этих объектов и сделать каждый из них неактивным. Далее, в момент когда объект необходим в сцене, из пула берется один из его инстансов и делается активным. При этом могут меняться некоторые из его параметров (например позиция).

Ну и соответственно, если активный объект больше не нужен, но не удаляется, а делается неактивным. Пул всегда возвращает один из неактивных объектов, то есть не используемых в данный момент.

В итоге получается, что мы имеем в памяти постоянное количество объектов (равный размеру пула), а не постоянно создаем и удаляем бесконечное количество объектов по мере работы сцены.
No. 25412    
Unity вкатывается в настоящую мультипоточность и асинхронность. В то время как в мире микросервисов это давно стандарт, в таких больших проектах похоже не так все просто.

До сих пор в стейбл версии используется старый подход, при котором главный цикл обновления сцены однопоточен. Сейчас (точнее еще в 2018) нашли способ это сделать многопоточным со скедулингом по разным ядрам. Правда это до сих пор в превью, хотя и выглядит вполне надежно и многообещающее.

Основная фишка тут в том, что подобный подход требует изменений в структурах пользовательского кода и объектов. Для этого были придуманы конверторы, и это вылилось в отдельную версию редактора. Пользователь работает с игровыми объектами и их компонентами, как и раньше. А дальше они сами конвертируются в “новые” сущности и компоненты (Entity Component System) для работы с ними в коде.

Ну и в коде, в связи с этим, уже нет работы с игровыми объектами в их обычном понимании, а с компонентами напрямую, которые в свою очередь уже содержат какие-то данные (например позиция, скорость). Отсюда этот подход получил название Data-Oriented Technology Stack. Классы теперь наследуются не от MonoBehaviour, а от JobComponentSystem.

https://unity.com/dots
Ну и разумеется, все это стало гораздо производительнее, и стало возможным делать сложные сцены, работающие даже на мобилках https://www.youtube.com/watch?v=KgcU2HBOXAw
No. 25423    
Погуглил больше про ECS.

Концепция сама существует давно и не является изобретением Unity, но уже DOTS - их термин. Она сама по себе не про производительность, а про подход к описанию игрового мира и взаимодействий в нем.

В ECS игровые объекты не наследуют кучу всего и не создаются со статичной кучей параметров и компонентов, существующих вплоть о момента удаления объекта. В ECS игровые объекты - просто entities, некие изначально пустые "сущности", играющие роль уникальных идентификаторов.

Параметры игровых объектов (например, здоровье, скорость, "прыгучесть", etc) являются самостоятельными компонентами (components), не привязанными ни к какому объекту статично. Они могут назначаться каким-либо entities, если им необходимо данное поведение/характеристика. Причем эта привязка или отвязка происходят в рантайме, что позволяет делать классные вещи в виде изменения казалось бы статичных характеристик игрового мира в уже работающих клиентах.

Системы (systems) содержат уже логику, обрабатывающую данные из компонентов. Можно думать о них, как о контроллерах. Важно то, что системы не завязаны на конкретных компонентах и entities. По крайней мере в юнити, как я понял, системы могу выбирать entities на основе привязанных к ним компонентов (entity query) и тем самым всегда работают с группой entities. Поэтому в коде много foreach :)

В этой концепции Entities, Components и Systems - вещи изначально существующие обособленно друг от друга, и им нужны отдельные средства коммуникации. И тут уже все зависит от конкретной имплементации.
No. 25450    
movie_005.mp4 - (436.97KB, 854×480)
25450
Разобрался со сценами и переходами между ними. Сцена - это некая уникальная инстанция мира. В зависимости от сложности игры может быть отдельным уровнем, может быть целым открытым миром. Или это может быть просто menu screen.

Все игровые объекты создаются внутри сцены и при переходе между сценами удаляются. Однако есть различные методики для персиста данных между сценами. Самый простой способ - это использование синглтона, который один раз создается при инициализации и помечается, как неудаляемый.

Персист данных между сессиями (между разными запусками игры) сложнее. Причем не потому, что надо писать в файл или работать с другими внешними сущностями. А потому что надо постоянно думать, могут ли внутренние структуры быть сериализированы. В шарпе не все так однозначно. Обычный array, например, может быть сериализирован в json, List уже нет. Хотя BinaryFormatter с ним справляется без проблем.
No. 25670    
бамп

Стив, как дела, продвигается ли изучение?
Удалить сообщение []
Пароль  
[Mod]