Комментарии 15
Тяжелые проекты в вебджл достаточно долго билдить, как программист тестирует код в юнити, он дублирует интерфейс в каком-то простом стиле?
Смотря о чём речь. Если юнити - геймплейный плеер. Весь мета гейм вероятно будет на стороне реакта, и тут надо смотреть в частностях. Отображение счёта или валют, или чего-то ещё можно делать на уровне логов. Простые кнопки, моки и команды решают остальное. Там не нужен гуй. Дублирование гуя слишком дорогой инструмент получится с его поддержкой. Контекст меню юнити, хоткеи и т.п. Полный цикл уже в билде, так как тестирует не разработчик, а тестер.
И тут вопрос, что такое долго. Если билд собирается билд роботом, то не особо дольше, чем il2cpp сборки. Юнит тесты скажем так через гуй и при обычной работе не стоит делать.
Особняком тут будут ММО или рпг, где сложный интерфейс сопряжён автоматом с геймплеем. Но всё равно тестить смотря что и смотря как. Если настроены ассембли, если правильно организован с разбивкой ассетов на бандлы, то пересборки просто будут не такими частыми)
Не очень понял про "весь мета гейм вероятно будет на стороне реакта". Не могу придумать сложный кейс, но представим себе джуниора, ему поставили задачу разработать какую-то ui логику, при работе с этой логикой недостаточно просто вывести логи, допустим это задача связана со взаимным расположением ui компонентов друг относительно друга в зависимости от различных параметров. Без визуального представления такую задачу сложно решить. Исходя из такой логики, я хочу представить идеальный кейс, при котором можно построить работу с комфортом и без ненужной переработки используя эту библиотеку и основания для внедрения ее. С моей точки зрения, я бы применил эту библиотеку, если бы у меня был уже готовый юнити проект на другой платформе и я решил бы зайти на webgl.
Если коротко, очень зависит от игры. Описанный кейс вероятно будет решать реакт разработчик вообще. Так как весь гуй на стороне реакта)
Такой процесс и подход предполагает, что все проблемы гуя решаются на стороне реакта. А на стороне юнити нужно один раз написать апи для проброса нужных параметров
Тогда зачем вообще использовать юнити ?
Для рендера не GUI задач. В основном 3д или же 2д со сложной механикой взаимодействия типа платформера. Игра - это же не гуй. Ну собственно вот частный пример. У меня есть такой продукт https://whitelabelgames.ru/game/ar-bow И это очень простая игра, и очень простая механика. Разработка на три, плейканвасе и т.п. просто по моему опыту медленнее
Когда я пытался ту же самую механику сделать на Three.js и полностью на веб технологиях я потратил в разы больше времени, чем на Unity + React. Ну, а на реакте такое вообще проблематично сделать. Всё очень зависит от игры
Если делается текстовый квест, hidden object и т.п. без VFX или с VFX который проще сделать на стороне веба, то Unity действительно нет нужды использовать. Скажем вот игра целиком на реакте, так как Unity тут ни к чему https://whitelabelgames.ru/game/card-game
Я бы тут обозначил другую проблему. Данный подход применим только для чисто веб проектов. Потому что смешивая технологии мы теряем возможность сделать адекватное приложение. Можно конечно запихнуть в стим билд засунув туда в сборку локальный сервер и chromium для отрисовки игры. А на мобилке вебвью по сути запускать. Но это "костыль" обладающий всеми недостатками веба. Скажем так сделал Warcraft 3: Reforged с главным меню, и видно что там внутри веб :)
Поэтому делая такую смесь мы теряем в некотором смысле в кроссплатформенности. Плюс это требует двух разработчиков. Но для мобильного веба делать проект чисто на юнити — это натуральное самоубийство. Потому что там постоянно будут лезть проблемы и нужно будет писать воркэраунды, так как официальной поддержки веба нет. Но как я потестировал чаще всего ломаются всякие инпут филды и т.п. Плюс нужно всё равно иметь JS экспертизу, чтобы правильно давать разрешения на скажем гироскоп или камеру. Правильно пробрасывать аналитику и т.п. И поддержка всех платформ становится гемором. Поэтому это решение (как и любое существующее решение) — не серебряная пуля. И всё очень зависит от контекста. Просто есть и такой подход :)
Просто тут надо сравнивать. И сравнивать смотря с чем. Скажем возьмём чистый веб. Пикси, плейкансвас и т.п. Я пришёл к тому, что процесс Unity + React эффективнее по бизнес причинам масштабирования команды. Unity разработчиков можно найти много на рынке, React разрабов тоже хватает. Но если мне нужно будет масштабировать команду на Pixi или Three.js, да просто повеситься проще :) Тех кто знает эти технологии очень мало. И мы начинаем учить своих. Это долго, дорого и менее эффективно) Чем за гуй отвечает реакт, за механику юнитисты. Тут думаю любому понятно, как масштабировать команду. Это не задача с кучей звёздочек. Так как и те, и другие специалисты на рынке есть :)
Да требуется иметь две экспертизы для поддержки проекта, но это не такая высокая цена с точки зрения бизнеса в долгосрочной перспективе скажем так. Чем когда бюджеты есть и ты просто тратишь пол года на обучение людей твоему фреймворку написанному поверх Three.js, обучая нюансам Three.js. Конечно это не всё, чем ты платишь юзая Unity. Так как скажем ты теряешь в возможности динамически грузить шейдеры, так как их придётся компилировать и пересобирать сборку. Но так как это Web для меня это тоже "малое зло" :)
За цену двух экспертиз поддержки проекта ты получешь отличное и удобное SDK для механик (Unity) с огромным комьюнити. И тоже самое для SDK разработки своего интерфейса (React) с таким же огромным комьюнити. Просто исследуя разные подходы реализации веб проектов я пришёл к этому из соображений мышления студии нежели разработчика :)
Вот этот аспект построения команды мне как раз и был интересен, спасибо за статью и ответы. Не пробовали ли babylon.js ?
Я за пол года попробовал всё. Максимально близкое PlayCanvas из-за наличия визуального редактора. Просто визуальный редактор очень сильно влияет на скорость разработки. Но проблема везде одна. Исследовал я для решения на чём и как делать https://whitelabelgames.ru/ я упёрся в то, что представим что проект полетит и мне нужна будет команда или несколько команд. А теперь идём на hh и вбиваем babylon.js в поиск. Видим две вакансии. И как бы прекрасно не было любое веб сдк — так со всеми. А это значит захочешь масштабировать команду — расти своих. А это очень дорого и звучит сильно дороже связки Unity + React. И по скорости разработки фич, и по масштабированию команды, и по много чему ещё. Типа с точки зрения бизнеса я не нашёл ни одного аргумента перебивающего эти недостатки. Технологии то хорошие, просто толку то, если их никто не знает. Да и людям невыгодно учить, так как потом они пойдут на рынок труда и не найдут работу. А это даже немного нечестно по отношению к своей команде :)
Наличие разработчиков на рынке, комьюнити, числа решённых проблем, числа готовых решений которые можно прикрутить — слишком сильно решает. Кто-то идёт в такие риски и думаю работает эффективно, но для своих проектов и продуктов я обосновать такое решение не смог :)
Недостатки Unity я решил и в статье описал как решается большая часть. Или посчитал их несущественными относительно бизнес недостатков остальных решений :) Я же разрабатываю проекты под заказ сейчас для разных компаний. И у меня очень сильно скачет загрузка. Иногда бывает по 10 проектов одновременно. И толку мне от pure web технологий, если я не могу масштабировать команду под такие случаи :)
А на 4pda как раз была тонкая реклама изготовления на Unity игр для Яндекса. Если разными путями приходят к одному и тому же, наверно это правильно.
Единственно чего я не понял, так как вообще можно сравнивать Unity и Three или Babylon. Если придёт время написать что-то поумнее и заслуживающее 15 секунд ожидания, то какие альтернативы Unity? Разве что Unreal, кто-то где-то как-то его вроде приспосабливает, но никак не pure web. Unity так же думала, скорее всего, когда экспорт в WebGL делала.
Пока читал всё ждал слова PWA, почему не дождался - не понимаю.
Да я просто как-то не интересуюсь именно PWA. Не моя специфика)
Что же касается движков. Unreal с вебом вообще не дружит. Там был какой-то плагин от комьюнити, но он давно не поддерживается вроде как. Так что только Unity, если брать прям движки
А про сравнивать. Ну я бы конечно прям не сравнивал, если были бы альтернативы хорошие. Сейчас разрабатывать на pure web почти равно разрабатывать свой движок :)
фпсы в раннере пропали
в ar-тире норм
Я понимаю, что автор никому зла не желал, но я должен предупредить всех читателей. Кто бы мог подумать, что одна маленькая настройка сломает весь проект. Из-за установки Managed Stripping Level в значение High перестали работать события UnityEngine.EventSystems. И перетаскивание, и наведение мыши, все перестало работать. Эту настройку нужно оставить в значении Minimal и не трогать вообще. А т.к. я делал еще много изменений в проекте, я потратил целый день, чтобы найти причину! А заказчик уже поторопился объявить релиз проекта, так что подстава не только для меня получилась. Ничего личного, но крайне не рекомендую пользоваться советами этого блогера
Сломать можно что угодно, если пользоваться советами бездумно. Все эти настройки - это максимальная степень оптимизации. Конечно если убрать из проекта пакет UI, где и лежит неймспейс EventSystem или же просто все галочки включать, то всё перестанет работать. Стрипинг удаляет модули, которые считаются не используемыми. И внося любые изменения в боевой проект нужно проверять, что они делают. Это просто советы не для новичков)
Unity WebGL + React