Blackberry Witch. Почему Unity?
В прошлых постах мы упоминали скриншот из редактора.
Да. Как верно подметили некоторые пользователи: мы используем Unity.
К Unity мы пришли рассматривая множество вариантов движков, фреймворков и библиотек.
Нам было необходимо:
1. Возможность кроссплатформенной сборки для iOS, Android, Mac, Windows.
2. Наличие готовых инструментов для работы со спрайтами, импорта и преобразования текстур и сборка атласов.
3. Наличие системы сцен и пользовательского интерфейса
4. Наличие готовых инструментов для работы со звуком
5. Наличие поддержки системы частиц и шейдеров
6. Хорошая документация по api
7. Большое сообщество, повышающее вероятность того, что кто-то уже сталкивался с той или иной нашей проблемой
На втором плане, но не менее важно
8. Готовые инструменты для работы со скелетной анимации
9. Наличие сносного менеджера сцен
10. Система предметов, системы квестов, сохранения состояний при переключений сцен
В нашей команде один программист и так же он занят в разработке анимации и пользовательских интерфейсов, мини игр, загадок и паззлов, это приводит к значимым ограничениям в вопросе разработки.
Наша художница ранее работала с dragon bones. Тот поддерживает Unity, Egret и Cocos2d.
Собственно Unity
Плюсы:
1. Широкий набор инструментов работы с графикой
2. Поддержка как direct x для windows билдов, так и opengl es 3 для android
3. Система сцен и объектов сцены
4. Обфускатор
5. Набор инструментов для работы со звуком
6. Сборщики и упаковщики с разными вариантами сжатия
7. Достаточно хорошая симуляция прямо из редактора, уменьшающая необходимость различного железа в процессе разработки.
И многое другое
Значительные недостатки:
1. Отсутствие адекватного менеджера сцен для их переключения
2. Отсутствие адекватного способа хранения данных между сценами
3. Отсутствие определенной главной сцены, сцены \ экрана загрузки
4. Отсутствие адекватной системы единого пользовательского интерфейса для всех сцен
5. Отсутствие инструментов для простой организации многоязычного перевода
6. Значительное потребление ресурсов на целевых для нас платформах
И ряд других менее значительных, как например некоторые баги.
И благодаря тому, что мы смогли решить значимые для нас недостатки, мы решили его в дальнейшем использовать.
Значимую часть из этого нам очень сильно помогло реализовать сообщество за счёт множества готовых примеров решения тех или иных вопросов, что в значимой степени ускорило разработку.
Подробнее
File Edit Assets GameObject Component Adventure Creator Tools Window Help # В о 0 0 * 0Pivot ® Global = Hierarchy + ▼ A* All I 0_Cutscenes ► 0 _DialogueOptions ► 0 .Interactions 0 -Lights t 0-Logic ► 0 -Moveables ► 0 -Navigation ▼ 0 _NPCs ▼ 0 LoLo ► 0 AnimationGroup 0 Trigger » 0 Liquorice 0-Sounds ► 0 -SetGeometry 0_UI 0 GameEngine ► ft HotspotPoints >* Animator Layers Parameters A* Name active # Scene Shaded Ê Asset Store ▼ 2D < '<’> si ▼ <&0 £у ж Тоже баг в юнити, таких пакетов не используется. ► II и И ▼ Gizmos ж а* ап У Collab ▼ Account * Layers w asyium-ist-iioor-coriaor’ ► ©i Main Camera > ▼ 0 -Cameras ▼ 0 -GameCameras ft Game Camera £ > ©I Desk Camera ш > © Inspector 53 Navigation Services ✓ Desk Camera Tag BackgroundCamera Prefab Open T A Transform Position Rotation Scale ▼ Layer Ignore Raycast Select Overrides Layout ▼ a i Static ▼ © Tt : Y 1.65 Z -10 Y 0 Z 0 Y 1 Z 1 Camera Preview <s> Base Layer Auto Live Link to Project ^ Console + - ■■ rieiaub to Renderers to Resources to Scenes to City to Coven to Fields to Final to Forest to School to SchoolYard to Town ▼ to Scripts ▼ to Actions tit Audio Mixer ©Animation ActionList Editor Profiler AC.ConversationEditorWi... A A Assets > Blackberry adventures > Scenes > City <3 <3 <3 <3 <3 <3 city_hoten city_hotel2 city.hoteL... city_hoteL- city_hotel_... city_hotel_... a : 5* # ★ S^21 <3 <3 <3 <3 cityjtft city_out_fr.„ city_outsid... city_station ▼ ■< Camera © 1 i Render Type Base ▼ ▼ Projection Projection Orthographic ▼ Size 4.685311 Clipping Planes Near 0.3 ▼ Rendering Far 1000 Renderer Default Renderer (UniversalRenderPipelineAsset-Renderer) ▼ Post Processing Anti-aliasing None ▼ StopNaN Dithering Render Shadows ✓ Priority -1 AC Game Editor : Scene Settings Actions Variables Inventory Speech Cursor Menu Scene manager Asset file: V Blackberry adventures.SceneManager (SceneManager) © Basic structure Organise scene objects: With folders Without folders mm Create new folder Scene settings Pathfinding method: Polygon Collider ▼ Default NavMesh: □ Default NavMesh (NavigationMesh) © Default PlayerStart: □ PlayerStart2D (PlayerStart) © Default Camera: □ Game Camera (GameCamera2D) © Default Sorting map: □ Default SortingMap (SortingMap) © Default Tint map: None (Tint Map) © Create Default Sound: None (Sound) © Create Override vertical movement factor? Vertirá! movement factor . Л i - 07 Поддержать разработку можно на нашем patreon.com/Creepybox_Games
gamedev,Игры,Blackberry Witch,разработка,Приключения ведьмы Ежевики,point and click,unity,Blackberry the Witch
Там нет ничего на подобии GameInstance как Unreal? Не уж то за столько лет не изобрели класс, который бы инициализировался только один раз при запуске игры и работал при смене сцены?
"Отсутствие адекватной системы единого пользовательского интерфейса для всех сцен"
Вот это вот совсем в замешательство вводит. Разве UI не должен быть привязан к контроллеру игрока, и оттуда же вызываться? При чем тут сцена то?
2. По сути гейминстансов нету.
3. Пользовательский интерфейс это та еще головная боль. Нет, не привязан. Устройство обработки и вызова UI идёт немного иначе. Мы сами пишем код обработки для него и сами его привязываем, но в любом случае к объектам сцены, их компонентам. Сделать это всё адекватно это настоящая головная боль.
Сам давно посматриваю в сторону юньки, чтобы перекатиться с анриала, и что-то такие минусы меня насторожили.
Мы пошли другим путём и использовали платный плагин к Unity имеющий значимый набор необходимого нам добра решающий вопросы работы между сценами.
Модель данных в Unity UI откровенно слабая, да. Говорю как человек пиливший MVVM поверх Unity UI и MVC поверх IMGUI. Оба в опенсорсе, но ссылок не будет - я там под своими ФИО.
Из плюсов Юнити - оно не относится к программистам как к обоссанным под шконарём гоблинам, поэтому программировать под него очень приятно. В UE ты без блупринтов ничерта не можешь - в Unity их просто нет. Это бесконечный плюс, поскольку ты можешь написать красивый код, но не можешь сделать красивый блюпринт. C# же гораздо удобнее, чем анриловский диалект C++.
При этом Unity гораздо стабильнее UE4 - в вечер пятницы UE4 скорраптил мне блюпринт и уровень. Последний раз, когда у меня не загружалась сцена в Unity, был, кажется, в 2013 году.
По стабильности сужу по тому, что мне приходилось удалять кэш, все папки вижака и перекомпилировать проект два раза за последние две недели в анриле, и два раза за последние два года в Юнити.
Пиздец, дожили, я хвалю Юнити за стабильность.
Писать большие проекты на блюпринтах - это вообще плохой тон. Обычно блюпринты используют только для настройки визуальных элементов и тестирования С++. Но довелось поработать и с 2D проектом (тут должен быть закадровый смех), который был уже написан до меня целиком на блюпринтах. Из С++ с этим работать слишком неудобно, поэтому приходилось обмазываться блюпринтовой лапшой.
Есть же SceneManager, там и управление сценами. В Unity сцена - это группа объектов для загрузки. Ничто не мешает загружать сцены вместе. Объекты одной сцены будут нормально работать с объектами другой. В одной сцене карта, в другой интерфейс и тд.
2. Отсутствие адекватного способа хранения данных между сценами
Это не совсем понятно. Функция DontDestroyOnLoad отвязывает объект от сцены. Все, теперь его данные хранятся, пока сам его не удалишь. Выгрузка сцены на него больше не действует.
3. Отсутствие определенной главной сцены, сцены \ экрана загрузки
Зато можно самому решить какая сцена главная. При старте приложения загружается первая сцена. После этого все в руках разработчика.
4. Отсутствие адекватной системы единого пользовательского интерфейса для всех сцен
Интерфейс можно вынести в отдельную сцену или в префаб и будет один единственный интерфейс для всех сцен.
5. Отсутствие инструментов для простой организации многоязычного перевода
В AssetStore есть бесплатные ассеты для локализаций. У них много всяких клевых возможностей, включая подгрузку перевода из Google sheets.
6. Значительное потребление ресурсов на целевых для нас платформах
Unity один из самых популярных движков для мобилок. Там все нормально с потреблением ресурсов. Гораздо чаще встречаются проблемы с оптимизацией у разработчиков.
Unity в разы медленнее работает в сравнении с opengl напрямую. Учти что юнити по умолчанию упаковывает ассеты обфускатором. Что еще сверху навешивает. Добавь, что по сути внутри реализован его "плеер", запускающий сцены.
>Есть же SceneManager, там и управление сценами. В Unity сцена - это группа объектов для загрузки. Ничто не мешает загружать сцены вместе.
И к каждому проекту ты создаёшь это снова и снова вручную. Загрузчик сцен, хранилище.
Есть инструменты, но нет реализации из коробки. Если это буквально каждому проекту надо, то в чём смысл не делать наличие по умолчанию?
>Отсутствие адекватной системы единого пользовательского интерфейса для всех сцен
А почему нельзя из коробки, если каждый раз для нового проекта надо создавать загрузчик интерфейса в итоге?
Как ты себе разработку представляешь? Типа набора Лего, просто кубики местами переставлять?
...как и любой универсальный высокоуровневый движок. Да, даже UE4.
> Учти что юнити по умолчанию упаковывает ассеты обфускатором. Что еще сверху навешивает.
Отключи обфускатор? Будто бы есть обфускаторы, которые не навешивают вычислений сверху.
> Добавь, что по сути внутри реализован его "плеер", запускающий сцены.
Так тебе нужен готовый движок или нет?
> И к каждому проекту ты создаёшь это снова и снова вручную. Загрузчик сцен, хранилище.
Есть инструменты, но нет реализации из коробки. Если это буквально каждому проекту надо, то в чём смысл не делать наличие по умолчанию?
SceneManager и есть реализация из коробки. Откуда юнити знать, как и когда у вас в проекте должны загружаться сцены?
> А почему нельзя из коробки, если каждый раз для нового проекта надо создавать загрузчик интерфейса в итоге?
Потому что есть юзкейсы, когда в проекте не нужен единый пользовательский интерфейс на все сцены.
Если нужна первая/стартовая сцена - значит у вас там идет какая-то инициализация. Раз она есть и написана - пихаете в любую сцену, хоть черный экран, хоть с экраном загрузки. Не совсем понятно что движок вообще должен в этом плане предоставить, он же не знает что вам нужно инициализировать в вашем конкретном случае.
Тоже не понял что за проблемы с переключением между сценами, хранилище? Опять-таки, данные желательно отвязать от интерфейса, визуала и реализации. Нет смысла хранить их хоть каким-либо образом привязанно к сцене. Разумеется, реализовывать можно как хочется и как душе угодно, но в данном случае (сугубо мое мнение) - сцена должна быть по типу "Gameplay", и туда должны подгружаться интерактивные экраны в виде префабов, а их смена и обработка должны происходить через конкретный менеджер. Можно и через сцены (или подсцены, кстати, как вариант. Или даже prefab variants.), но само понятие сцены в юньке - условность, оно совсем не обязательно подразумевает что игровые локации должны быть разбиты на манер "одна сцена - одна локация".
Не к тому что юнити это прям сказка, там проблем хватает, но блин, как-то озвученные проблемы звучат скорее как проблемы архитектуры, чем как проблемы движка, не в обиду.
https://docs.unity3d.com/Manual/MobileOptimizationPracticalGuide.html