Прошлый тред: >>641602 (OP)
Официальный сайт: https://unity3d.com/ru
Документация: https://docs.unity3d.com/ru/current/Manual/index.html
Уроки: https://unity3d.com/ru/learn/tutorials
Форум: https://forum.unity3d.com/
Магазин ассетов: https://unity3d.com/ru/asset-store
UnityWiki: http://wiki.unity3d.com/index.php/Main_Page
На Unity сделано много замечательных игр - Rust, Блицкриг 3, Pillars of Eternity, Tyranny, Kerbal Space Program и многие другие. Главным преимуществом Unity перед другими движками является его простота для одиночной разработки. Не нужно иметь целую компанию девелоперов, чтобы сделать хорошую игру. Если ты один или имеешь небольшую команду и хочешь сделать хорошую игру без претензий на ААА, то Unity станет лучшим выбором. Тем не менее, даже крупные корпорации зачастую выбирают для своих игр именно Unity.
FAQ
- Какие у Unity сильные стороны?
- Простота разработки, удобный инструментарий, кроссплатформенность, богатая документация, огромное сообщество.
- Какие у Unity слабые стороны?
- Сложность в создании фотореалистичной графики. Для графики "как в Crysis" рекомендуется взять другой движок. Хотя Unity вполне способен выдавать не уступающую любым другим движкам картинку, это требует определённого навыка от разработчика.
- На каких языках я могу писать скрипты для Unity?
- На выбор два языка - C# и UnityScript. UnityScript - это что-то среднее между JavaScript и ActionScript. Выбирай язык по своему вкусу, они оба вполне удобны, но помни, что большинство примеров написано на C#.
- Для каких жанров подходит Unity?
- Для абсолютно любых! Жанр ограничивается лишь фантазией разработчика (и его умением писать скрипты, разумеется). Можно создавать и РПГ, и стратегии, и слэшеры. Можно делать VR-проекты или Minecraft-подобные песочницы.
- На каких платформах работают созданные с помощью Unity игры?
- Windows, Linux, MacOS, SteamOS, Android, iOS, Windows Phone, PlayStation4, Xbox One, WebGL, Oculus Rift и многие другие. Полный список можно найти на официальном сайте. Таким образом, игры Unity работают на десктопах, на смартфонах, планшетах, приставках, в браузерах, VR-очках и некоторых других системах.
- Часто вижу скриншоты с красивой природой на Unity. Как такое создать?
- Очень просто! В Unity встроены удобные инструменты для создания террейна и SpeedTree для создания деревьев и готовая реализация ветра - не нужно ничего писать или скачивать и подключать плагины - ландшафт в Unity создаётся в пару кликов.
- Что такое стартер киты?
- Starter Kit - это набор скриптов и префабов, а зачастую и графических элементов для игры. Они призваны облегчить разработку игры определённого жанра и как правило разбиты по жанрам (Action-RPG Starter Kit, RTS Starter Kit, 3D Shooter Starter Kit, Space Game Starter Kit, VR Starter Kit и так далее). Также бывают стартер киты различных игровых элементов, не связанных с геймплеем (Nature Starter Kit с дополнительными природными объектами, Medieval Starter Kit со средневековыми объектами и так далее). По сути, стартер киты выполняют в разработке игры ту же роль, что и фреймворки в программировании. Однако стоит отметить, что использование геймплейного стартер кита принуждает разработчика изучать большое количество чужого кода и чужой структуры для внесения своих изменений и полноценного использования. В связи с этим большинство разработчиков предпочитает писать почти всё с нуля, получая полное понимание работы своей игры. Новичкам крайне не рекомендуется начинать знакомство с Unity со стартер китов.
- Что нужно уметь делать для создания полноценной игры, кроме Unity-разработки?
- Кроме непосредственной разработки игры на Unity, требуется также уметь создавать 3D модели (3ds Max, Blender, ZBrush), 2D рисунки (GraphicsGale, Aseprite, Piskel), текстуры (Substance Designer, NeoTextureEdit), музыку (FruityLoops, Ableton). Не обязательно учить это всё - например, в 2D играх не нужны 3D модели, а музыка необходима далеко не всегда. Также вы можете скачивать элементы для ваших игр на бесплатных сайтах. Если у вас есть деньги, то все необходимые элементы можно заказать у фрилансеров на https://www.fl.ru/ (русскоязычный) или https://www.upwork.com/ (англоязычный).
- Бесплатен ли Unity?
- Можно свободно скачивать, использовать и продавать готовые игры на Unity с лицензией Personal - это абсолютно бесплатно! Но на бесплатной версии при запуске игры будет появляться короткий стартовый ролик "Made with Unity", а также ваши доходы ограничены 100 000 долларов в год. Для снятия этих ограничений нужно приобретать платные версии лицензий Unity. В конечном итоге, платные варианты используются лишь крупными компаниями с огромными доходами, тогда как обычные разработчики в большинстве своём используют бесплатную Personal лицензию.
Обучение
- Язык
Итак, с чего же начать изучение этого замечательного движка? Прежде всего, с изучения языка. Самые основы C# можно узнать на интерактивных курсах здесь:
https://dotnetcademy.net/CSharp/Beginner
или в текстовом туториале здесь:
https://www.tutorialspoint.com/csharp/csharp_quick_guide.htm
Для изучения основ UnityScript выучи вначале основы JavaScript:
https://learn.javascript.ru/
Помни, что далеко не все элементы JS есть в US. Чтобы понять, в чём разница между этими двумя языками, прочти эту статью:
http://wiki.unity3d.com/index.php/UnityScript_versus_JavaScript
Помни, что тебе достаточно одного языка из двух и учить их оба одновременно не нужно.
- Движок
Если ты уже умеешь использовать язык, то можно приступать непосредственно к изучению движка. Крайне рекомендется купить/скачать книгу Unity in action (Unity в действии). В ней подробно описываются множество возможностей движка.
http://www.ozon.ru/context/detail/id/34792570/
Также посмотри на видеотуториалы с официального сайта:
https://unity3d.com/learn/tutorials
Если же ты не любишь видеотуториалы (или не понимаешь разговорный английский) и предпочитаешь текст, то посмотри здесь:
http://catlikecoding.com/unity/tutorials/
Тут крайне подробно описан процесс разработки и приведены примеры кода. Эти туториалы универсальны и описывают множество различных частей игры, от работы с текстурами до генерации карты мира. А вот в этом туториале описыватся разработка двухмерной игры с видом сверху:
https://www.raywenderlich.com/61532/unity-2d-tutorial-getting-started
Это будет полезно, даже если ты планируешь разрабатывать трёхмерную игру. Ни в коем случае нельзя обойти вниманием этот сборник туториалов:
https://noobtuts.com/unity
В нём подробно описывается процесс пошагового создания разных игр - двухмерных и трёхмерных.
Разумеется, все эти туториалы охватывают лишь часть возможностей Unity. Самый надёжный способ выучить Unity - это начать делать игру и по мере разработки гуглить непонятные моменты.
Шапка: http://www.writeurl.com/publish/zukmrogwv45ptyuseyol
Допустим я хочу нарисовать луч исходящий из gameobjecta пустого (насколько я понял нужно взять его трансформ)
Но как кинуть сам луч ?
Ещё видел в видосах ему можно задать длинну и цвет.
Запилил два слоя анимаций, стейты для них идентичны.
Смену анимаций делаю, меняя "вес" слоя анимаций, т.е. начинается бой - вес "стандартного" слоя (Base Layer) опускаю до нуля, а вес "боевого" (gun) повышаю до 1.
В теории при входе в бой у меня должен играться слой gun, но по факту при смене "веса" слоя gun на 1 мне пишет дичь "invalid Layer index '-1' и ничего не играется, пока не верну базовый слой взад.
В гугле пишут, что такая ошибка может быть если скрипт не может найти стейт в новом слое, но стейты в обоих слоях одинаковы, различаются только сами анимации в них.
Чего я тут не понимаю?
Если "заглушить мотор" машина не стартует вперёд пока не нажмёшь сначала "S" т.е. задний ход.
Это баг или фича? Как пофиксить?
Я думал это я напартачил, скачал официальный пак - там то же самое.
А то я туплю - учился во времена когда анимации делались сразу с моделью (и называлось морфом) и каждая две модели человека анимировались как совершенно разные (нельзя было сделать одну анимацию)
А тут часто вижу как продают анимированные скелеты или наоборот модели без анимаций...
и как я понял - мы вошли в ту эпоху когда можно сделать один скелет, анимировать его, и затем натягивать на кучу моделей... но как все это делать?
Короче надо гайды
Смотри готовые примеры с того же сайта юнити. Смотри многочисленные видосики. Анимации сложная штука и на словах не объяснить. Надо самом щупать, тогда быстро освоишь.
Ещё посмотри новый Animation Rigging. Он пока в превью, но мне уже нравится. Платная альтернатива - FinalIK. Его можно бесплатно скачать на пиратских сайтах.
Ебанный аниматор со своими слоями довёл вчера мою сраку до точки плавления >>647180. В теории вроде понятно, на практике нормально работать не хочет. Вместо переключения слоёв решил проблему радикально, буду тупо заменять контроллер аниматора в рантайме. Пошли они нахер.
Сильно хочется их объединения в супер движок на котором даже мы смогли бы делать игоры
Ну что, пиздюки, похоже, придётся переходить на ваш сраный юнити. Надоело писать велосипеды вместо игр.
(Автор этого поста был предупрежден.)
>юнити лаунчер может в любой момент перестать пускать меня в программу. мало ли что им взбредёт в голову.
А еще может метерит тебе на голову упасть, такая же вероятность. Ну бойся, хуль. Может уебищный говнодот взять, там никаких рисков!
(Автор этого поста был забанен. Помянем.)
>юнити лаунчер может в любой момент перестать пускать меня в программу. мало ли что им взбредёт в голову.
>А еще может метерит тебе на голову упасть, такая же вероятность.
Вот интересно кстати, край же изменял лицензию, после того как на нем игра какая-то вышла, прей по-моему. Заработал он после этого или еще меньше людей стало его юзать
Ну никогда же не было такого, чтобы фирма запрещала использовать свой движок. А когда игру переписывали на новый движок, изымала всё оборудование студии, в судебном порядке обязывала изымать тиражи игры и доводила студию до банкротства штрафами. Не было такого. Хотя юнити в этом плане одна из самых безопасных, почти как тот же край, скоро крайтек разорится нахуй и движок окончательно уйдёт в опенсорс.
>>647458
Так прей на четвёртой версии, а лицензия менялась на пятую. Да и там менялось в сторону большей демократичности.
>Заработал он после этого
Они жопу амазону продали за сотни денег и амазон выкатил ламберярд. Сомнительная сделка на самом деле.
Делаю аи для игры, начал с навигации. На уровнях присутствуют двери, которые персонажи должны открывать с помощью располагающейся рядом кнопки, вентиляции, в которые персонажи смогут залезать пригнувшись и тд. То есть, рассуждая терминами юнити навмеша, есть офф-меш линки, но чтобы ими воспользоваться, персонажу нужно совершить определенное действие. Как персонаж должен получать информацию об этих возможностях и необходимых для их реализации условиях?
Подозреваю, что вопрос базовый, и должно быть достаточно будет денек поковыряться с апи, но может есть здесь знатоки, которые ускорят процесс.
>То есть, рассуждая терминами юнити навмеша, есть офф-меш линки, но чтобы ими воспользоваться, персонажу нужно совершить определенное действие.
офф-меш линком будет как раз кнопка открытия двери. ну или другое аналогичное действие.
если пути графа имеют цену прохода, то цена прохода через дверь соотвественно будет равна проходу к кнопке + проходу к двери, чтобы у ии была "мотивация" сьебывать жать кнопку вместо обычной рутинной беготни по графу навмеша
короче вангую тебе предстоит свой навмеш под это всё велосипедить
ну или хуйзабей, при приближении к двери отключай функци анал обычной ИИ рутины и подменяй его специальной, которая будет заставлять персонажа добежать до кнопки
вообще, знаешь, ни разу не видел реализации подобного в играх. мб и нахуй не нужны такие шарады
У ии в агента отключаешь
https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent-autoTraverseOffMeshLink.html
потом в апдейте проверяешь на навмешлинке ли он
https://docs.unity3d.com/ScriptReference/AI.NavMeshAgent-isOnOffMeshLink.html
К самому навмешлинку лепишь триггер в котором устанавливаешь тип линка (дверь, кнопка, че хочешь) который он передаст ии
И у ии после проверки что он на нем стоит в зависимости от типа запускаешь действие
Самая простая реализация до которой я додумался
Да нихуя оно и небыло бесплатным. Когда-то был крайэнжин сдк с версией движка что-то типа 3.5 с абсолютно непонятными условиями, потом была четвёртая версия движка с лицензией 10 баксов за место. Потом вышла пятая "плати сколько хочешь" версия движка, но прей-то на четвёртой. Потом вышла 5.5 "плати 5%" версия, но с оговоркой, что если ты зарегал проект до какой-то даты, то остаёшься на старой лицензии "плати, сколько хочешь". У юнити же вообще лицензирование удобное до охерения, есть вообще ретроактивная лицензия, когда ты покупаешь лицензию на новую версию и пользуешься под ней старой версией движка. Уверен, многие до сих пор на 2017 юньке пилят.
>>647529
>Это чё за хуйня?
Модер-долбоёб горе на доске.
Кто ж тебе запретит, для прогера это идеально, игры сложно придумывать, слишком разноплановое творчество, движки чисто задача для прогера. Можешь плагинчик какой-нибудь запилить, например констрактовские события для 3д движка, такого еще нигде нет. Для юнити есть много систем упрощенного программирования, но они все одинаковые на нодах, популярная только одна. Иногда простенькие плагинчики могут приносить неплохой доход. Может быть конкретный шаблон игровой. Но тут тоже четкого пути нет, некоторые плагины слишком универсальные, для рпг например огромные, проще сишарп изучить чем изъебы этого плагина.
Подскажите, UnityScript больше похож на ES5 или все-таки умеет штуки из ES6+? И поддерживается ли все еще US? Слышал от коллеги, что его выпилили/собираются выпилить
Давно выпилили. Из юнити постоянно выпиливают какие-то фичи.
Например, я только что узнал, что из версии 2019.3 выпилили окно настроек: https://forum.unity.com/threads/the-display-resolution-dialogue-has-been-deprecated-and-will-be-removed-in-a-future-version.670798/
То есть теперь чтобы запустить игру на втором мониторе, нужно писать свой сторонний launcher (!) отдельно от юнити и запускать игру через командную строку либо сохранять/читать файл настроек.
Обычно такая ситуация означает, что что-то пошло не так. Ввести бы абстракцию для модификаторов и объединить листы. И юниты объединить!
Но если я абсолютно точно хотел бы оставить текущее положение вещей, то я бы предпочел ленивую инициализацию. Нехуй тратить ресурсы там, где не нужно. Можно даже сделать обёртку для твоих листов с кучей null проверок, чтобы было комфортнее.
Из пыха когда вкатывался в эти ваши шарпы, сначала такой "ебанись, оно выполняется вечно". Сейчас, наверное, уже на пыхе нихуя не смогу, а в шарпы быстро вкатился, когда понял, откуда точка входа. А жсники в принципе ебанутые.
>>647752
Двачую этого. Скорее всего листы на самом деле вообще нахуй не нужны, хранишь все моды в одном месте, а в юнитах только айдишники модов.
Собственный цикл жизни обьектов, начиная с кривой инициализации и кончая уничтожением, когда null не null.
Генераторы с yield вместо многопоточности.
Абуз рефлексии и дорогих переборов обьектов сцены во внешне невинных местах.
Логика, размазанная по апдейтам, без единой точки входа и распределения.
Сюда же официальные мануалы, в которых публичные поля - норма, а умение написать пул объектов - нихуевое такое достижение.
> когда null не null
Уничтоженный инстанс не нуль во всех движках. Придирка непонятна.
> Генераторы с yield вместо многопоточности.
Многопоточность — это высший пилотаж кодинга, который здоровый преподаватель никогда не преподаст ньюфагам.
> Сюда же официальные мануалы, в которых публичные поля — норма
Сюда же. Мануалы — для ньюфагов. Профи юзают класс-референсы.
> Абуз рефлексии и дорогих переборов обьектов сцены во внешне невинных местах.
Сюда же. Ты доебался до мануалов (и туториалов наверняка) которые — для ньюфагов. Профи делают дорогие операции редко и контролируемо. Как пример — объявляют переменные с вызовом дорогих гетКомпонент в старте.
> Логика, размазанная по апдейтам, без единой точки входа и распределения.
Во всех движках логика размазывается по апдейтам. Потому что принцип такой, общепринятый всеми. Принцип главного цикла с коллбэками в него. Если у тебя логика непонятная тебе — то это проблема твоего проекта, а не движка.
Ты прав. Претензия моя в основном в том, что пока ты ньюфаг - тебя кормят говном. И пока станешь профи (а в таких условиях, может, никогда), наесться говна придется три ведра.
А потом ты понимаешь, что движок нехило так заточен под ньюфагов и активно мешает тебе в выстраивании грамотной архитектуры. Тут уж ты начинаешь всерьёз воспринимать мемы про свой движок или жёстко дрочишь на MVC, вынося все говно в View, что во многих случаях тоже субоптимально.
>Уничтоженный инстанс не нуль во всех движках. Придирка непонятна.
Зато знаешь где уничтожение зануляет референсы? Во всем остальном мире. Об этом я и говорил в начальном посте - трижды охуеешь, пока адаптируешься.
> Претензия моя в основном в том, что пока ты ньюфаг - тебя кормят говном.
Да. Качественное образование - очень редкая и ценная вещь. Грамотных преподавателей, которые умеют соблюсти баланс и не накормить учеников неюзабельным говном из легаси и упрощений, но при этом не вызывать в них уныния, преподавая сложные, трудноподъёмные вещи - вот эти преподаватели очень редки.
> Зато знаешь где уничтожение зануляет референсы? Во всем остальном мире.
Не буду спорить на сей счёт, навскидку не скажу, как там во всём мире кодинга.
>Ввести бы абстракцию для модификаторов и объединить листы. И юниты объединить!
Это было бы просто охуенное решение, если бы юнити умел сериализовать дженерики.
Ведь в принципе все модификаторы схожи, это просто число и ключ того значения, которое должно быть модифицировано. Различаются только типы этих ключей: это константы из перечислений Stat, Skill, и т.д., в статах соответственно сила, ловкость и другие, в скилах - одноручка, двуручка и тд. Былобы очень просто наследовать классы этих модификаторов от общего модификатора<Т>, где Т - перечисление, и хранить в массиве базового типа, но бля, юнити его сериализовать не будет. Я изначально о такой релизации думал, еще когда не знал о таких тонкостях движка. Но вот теперь знаю и страдаю с кучами коллекций неуниверсальных классов.
Вот например, здесь без задней мысли сериализуется специфицированный до строкового дженерик лист:
https://www.newtonsoft.com/json/help/html/SerializeObject.htm
Не, ты не понял. Тут у тебя сериализуется лист одного типа, а мне предлагают сделать лист общего типа и хранить в нем модификаторы разного типа. А такое уже сериализовать не прокатит.
Так то юнити из коробки умеет листы сериализовать, никакие плагины не нужны, проблема в сериализации общего типа.
https://play.google.com/store/apps/details?id=com.GhostZoneProd.UndyingHeroes
> а мне предлагают сделать лист общего типа и хранить в нем модификаторы разного типа
А, вон чо. Так это ты сам не понял, что тебе предложили. Общий тип - это класс-предок типа Модификатор. Лист специализируешь его типом. В лист кидаешь инстансы классов-наследников. А хотя да, хуита получится, при сериализации выведутся в файл только поля общего типа, а поля дочерних классов отбросятся. Теперь понял и я.
Да... В плане сериализации статически типизируемые языки посасывают у динамически типизируемых. Остаётся только либо кастомные утилиты сериализации писать чисто под твою задачу, либо делать как ты с самого начала и делал.
А это что такое, петух?
https://blogs.unity3d.com/ru/2019/03/08/on-dots-entity-component-system/
Юнитеки так и пишут: с помощью DOTS и Burst вы должны писать на Юнити свой движок. Нихуя не знаешь, а лезешь других учить.
> вы должны писать на Юнити свой движок
Именно так, однако я с формулировкой не согласен. С ДОТС разрабу поверх движка требуется писать свой тулсет, специфичный игровой редактор для редактирования конкретной игры. Что-то уровня беседковского криэйшон-кита, когда у тебя справа загруженная игра, слева таблицы с данными и ты летаешь по игре в режиме бога и создаёшь правила игры, которые тулсетом динамически сохраняются в наборы данных.
Ясен хуй, что впоследствии на этом мета-редакторе тот же разраб может написать и вторую игру и третью. Как, собственно это и делал Тодд.
У меня только после переустановки студии заработало. Ни один способ, который я нашёл на стаковерфлоу, не помог.
Например https://stackoverflow.com/questions/42597501/autocompletion-not-working-in-visual-studio
Причём студию я поставил через юнитивский инсталлятор.
Я напиздел. Оказывается, как минимум ньютонсофт умнее и прекрасно умеет заглядывать в актуальные классы. Я думал-думал над этим, не удержался и наваял код для проверки.
>>647844
Надеюсь, ты ещё не ушёл и прочтёшь инфу. Вот код на скрине и вывод. Классы коттедж и тауэр - это и есть твои модификаторы разных подтипов, хранящиеся в одном листе общего типа. Как видишь, сериализатор прекрасно выводит их в текст со всеми различающимися полями.
Возможно и майковский дефолтный сериализатор так делает. Пока не проверял.
Надеюсь, это поможет тебе сделать годные игры. Я не тот, анон что доебался до тебя выше.
Скорее всего тебе поможет Odin. Сам городил анальные костыли при создании модульной логики, после траты 3к на это расширение выпилил их все нахуй. Теперь спокойно сериализую интерфейсы и абстрактные классы, в том числе и женерики (хотя про твой случай конкретно не понял, ты там что-то лихо завернул в обьяснении).
И словари!
Заманчиво, но что-то слабо верится, что поможет, проблема видится мне прямо дико укорененной. Смотри, если сделать так:
class Modifier<T> where T : enum {
T Key;
float Value
}
class ModifierStat : Modifier<Stat> { }
class ModifierSkill : Modifier<Skill> { }
enum Stat {
Strength,
Agility
...
}
enum Skill {
Melee,
Range
...
}
И где-нибудь объявить так:
ModifierStat mStat = new ModifierStat(Strength, 0.1f);
ModifierSkill mSkill = new ModifierSkill(Melee, 0.1f);
List<Modifier> Modifiers = new List() { mStat, mSkill };
То, с помощью одина, можно будет без изъебств сериализовать Modifiers? Чтоб прямо работало. Можно, а?
Тебе шарп учить надо. Ты неправильно объявляешь. Я скопировал твой код в тестовый проект и уже на первой строке он отказывается объявлять энум как шаблон. В качестве шаблонов нужно типы юзать, а не энумы. Типами могут быть классы и интерфейсы. Идея в целом ясна, но я не могу с наскоку попробовать реализацию.
>UnityScript
Че нахуй? На этом кто-то пишет хоть что-то?
За 150 баксов в месяц.
https://store.unity.com/compare-plans?currency=USD
>>647969
Вот в таком виде работает. Если тебя всё устраивает - то можешь прямо сейчас тянуть нугетом ньютонсофт-жсон и нехер тратить бабки на какой-то там платный Один.
Энум очевидно сериализируется как инт. При десериализации тебе нужно будет как-то различать эти классы, добавляя serialization info как минимум. Или разнося значения шаблонных энумов по разные стороны, и детектируя класс по величине ключа.
>[SerializeField] private int kekCount;
и что если нужно подсмотреть значение переменной из одного класса в другой нужно писать
>public float ppSize { get; private set; }
Правильно ли делаю? И вот как мне теперь лучше изменить этот самый флоат из вне класса? Через отдельный публичный метод внутри класса и вызывать его?
>Правильно ли делаю?
К успеху идёшь.
>И вот как мне теперь лучше изменить этот самый флоат из вне класса? Через отдельный публичный метод внутри класса и вызывать его?
Да. Или через public set. Обычно методы используют когда надо намекнуть, что изменение значения - дорогая операция с сайд-эффектами, например, выстреливание ивентов. А set - для простых операций без сайд эффектов.
Функционально оба метода идентичны. Зачем нужны эти изьебства вместо написания публичного поля? Легко прикручивать дополнительную логику. Как я уже упомянул, ивент при смене значения, например. Или валидация, чтобы твой кек всегда был неотрицательным. Ну и чтобы знать и легко контролировать точки входа и выхода из класса, естественно.
Делают префабами которые загружаются/удаляются. Минуса два - будет спайк при смене (из-за загрузки большого префаба) - чтобы скрыть делают смену под какой то анимацией (у анимации должна быть точка остановки где ты можешь долго повисеть пока префаб не загрузится), второе - изначальная загрузка приложения будет долгой, из-за того что ты не разбил на сцены, а все ресурсы подгружаются на старте.
Ну хорошо, а как разбить на сцены? Так все нормальные делают, я тоже хочу. Я уже выучил, что есть такая функция как загрузить сцену, но не знаю даже как в загруженную сцену перемещать данные и обратно. Всё что я придумал это с сохранениями в реестре колдовать, выгружать оттуда данные. (Кстати, на Маке такие сохранения будут работать?)
Зачем? У тебя изначально список выключенных локаций, где ты включаешь первую. При смене - выключаешь первую и включаешь вторую. И так далее.
С уничтожением такая же система. Так ты экономишь ресурсы на старте, ибо тебе не нужно инициализировать десять тысяч объектов каждой локации, но переходы будут чуть дольше из-за создания новой локации с нуля, а не простой активации уже созданного.
Про асинхронную подргузку сцен, думаю, рассказывать тебе ещё рано.
>>648554
Ты бы посмотрел пару туториалов для начала, никто тебе тут в двух словах не расскажет про азы работы в юнити.
А подразумевается что всякие объекты кликаемые в локации тоже придётся постоянно включать/выключать муторно?
Я вообще думал не проще ли сделать всё через камеру, расположить объекты порознь и когда переходишь в другую локацию просто менять положение камеры, можно ещё выключением со старта самых крупных пикч запилить как ты писал чтоб меньше нагрузка на память, но все объекты заколебёшься делать. Какие подводные камни?
Анончики, я тут алгоритм поиска пути монстрикам под свою игрушку пишу, и у меня сейчас встал вопрос производительности. В прошлом треде анон поделился неплохим решением >>643420 → , точнее рядом решений, но работает это адекватно только в простых ситуациях.
У меня игровая локация представляет собой лабиринт, и грамотно рассчитать путь получилось пока только методом трассировочно-волнового алгоритма. Для этого на каждом нпс я выделил массив структур, содержащих gameObject и Vector3 координат предыдущей ячейки, меньшим способом я получить информацию о соседних ячейках не смог никак, да и мне кажется что будь-то массив одних только векторов3 или интов, тормоза от большого размера массива будут, потому что кручу его за один фиксед апдейт. Подсчёт этого массива сделал раз в секунду, если сменились ячейки у преследователя и преследующего. Чтобы рассчитывать очень длинный путь, нужно выделять массив где-то на 100 ячеек, и вот когда он заполнен почти полностью - начинаются подлагивания, при подсчёте на 10 нпс одновременно. Собственно мне длинный прямо-таки путь не нужен, хватает и 10-15 ячеек в массиве, всё-равно это тупо, что моб за тобой через всю локацию бежит, но всё же у меня навязчивая идея это оптимизировать иным способом. Может можно как-то попилить одну полную прокрутку массива на несколько апдейтов или что-нибудь в этом роде?
Можешь попробовать использовать вейпоинты
http://mejorka.ru/publ/sozdanie_waypoint_podbot_3_0/1-1-0-124
Генерируй из заранее через скрипт редактора. А в риалтайме уже все будет максимально быстро.
https://gamedevelopment.tutsplus.com/tutorials/understanding-steering-behaviors-path-following--gamedev-8769
>А подразумевается что всякие объекты кликаемые в локации тоже придётся постоянно включать/выключать муторно?
Все делаешь внутри корневого объекта. Отключаешь его - выключаются все дети.
>Какие подводные камни?
Если локации крупные, то объектов будет дохуя. Сам как думаешь, это скажется на производительности?
Скрипты будут работать вхолостую. Анимации будут работать вхолостую. Системы частиц. Физика. Коллизии. Ладно ещё две-три локации, но если их будет больше десятка?
Выключенные объекты хоть и висят в памяти, но не нагружают процесс всем этим дерьмом. Часть всего перечисленного оптимизировано, чтобы не нагружать игру, если не в поле зрения, но многое придется оптимизировать самостоятельно. Откровенно говоря, проще будет потратить час-два-три на пару туториалов о сценах и сделать игру здорового человека.
бамп
Это совсем другое. Я лучше подумаю как мне обработку длинного массива на несколько апдейтов разбить.
Если ты генеришь лабиринт, значит у тебя есть данные где можно ходить, а где нельзя.
Я бы эти "ячейки и клетки" хранил в NativeArray и поиск пути выполнял в отдельном потоке через Job.Schedule.
И вообще повторный поиск можно делать не каждый кадр, а если точка А или точка Б сместилась больше чем на 0.1 - просто и тупо, но эффективнее чем 60 раз в секунду строить путь.
Точнее скрипты чтобы сделать такую же камеру с такой же отзывчивостью (на видео прямо чувствуется когда персонаж в тяжелых латах прыгает)
И возможно анимации меканим (если я правильно понимаю)...
Короче, вообще любые ассеты скриптов (кроме моделей) которые бы помогли начать такой проект
Добавил интерфейс UI обьект при нажатии на который другое действие2.
У обоих стоит галка ловли рейкастов.
При нажатии на кнопку UI нажимается и обьект в 3д под ней, происходят оба действия
Что я делаю не так? Может прозрачность интерфейса пропускает клик?
Использовать EventSystem.IsPointerOverGameObject https://www.youtube.com/watch?v=EVZiv7DLU6E
>Я бы эти "ячейки и клетки" хранил в NativeArray и поиск пути выполнял в отдельном потоке через Job.Schedule.
Чёт я малость погуглил и сделал вывод что для чего-то подобного нужно переписывать всю логику воздействия сил с нуля. А ещё нужно этому научиться.
>И вообще повторный поиск можно делать не каждый кадр, а если точка А или точка Б сместилась больше чем на 0.1 - просто и тупо, но эффективнее чем 60 раз в секунду строить путь. -> >>648574
>Подсчёт этого массива сделал раз в секунду, если сменились ячейки у преследователя и преследуемого.
>>648651
Спасибо, а то я пытался укоротить цикл for в апдейте, когда можно от него отказаться. буду думать в этом направлении.
Известная практика, последние года 2 все становится только хуже, например запекание теней совсем недавно пофиксили (до этого их вообще не было)
>>648768
>Чёт я малость погуглил и сделал вывод что для чего-то подобного нужно переписывать всю логику воздействия сил с нуля
Вообще если сейчас у тебя нет данных о клетках, то да.
Если есть - там все проще чем кажется, создаешь NativeArray, заполняешь его своими данными, создаешь структуру IJob кажется и в ней делаешь переменную с этим массивом и всю логику, вызываешь этот метод через var mahJob = Job.Schedule(YourJobName);
Все, потом из mahJob.Result можешь в любое время брать результаты
ЛЕГКО И БЕЗ ЗАДНЕЙ МЫСЛИ как говорится
Поправочка, не 2.7 а 2.6...
Попробуйте! Лютый вин
https://www.youtube.com/watch?v=W3ak78JCWA4
https://www.youtube.com/watch?v=7rx7xeqadFQ
http://download.unity3d.com/download_unity/UnitySetup-2.6.0.exe
Запускается на любой кофеварке и не тормозит!
https://learn.unity.com/tutorial/essential-unity-concepts
Третья ссылка в гугле же
> я пытался укоротить цикл for в апдейте
Посаны! Я придумал, как объяснять новичкам суть проектирования на главном цикле! Когда новичок заводит речь о циклах в апдейте, говоришь ему, что игра уже содержит цикл и выглядит это так:
while (Application.Running() == true)
{
Application.Update();
}
Поэтому новичку можно (анонимус разрешает) не создавать свои циклы, а прицепиться к главному, путём размещения своего барахла в апдейте.
Ты что-то странное говоришь, в Юнити главный цикл не так устроен. Лучше прочитать мануал
https://docs.unity3d.com/Manual/ExecutionOrder.html
> Ты что-то странное говоришь
Ты не новичок.
>>648816
Посаны! Я придумал, как объяснять новичкам суть корутин! Когда новичок заводит речь о корутинах, говоришь ему, что корутины - это функции с циклом внутри, каждая итерация которого приостанавливает выполнение корутины до следующего вызова... Корутины - это когда в жопу ебут. Карочи, корутины - это поилка для цыплят с автоматическим пополнением воды. Как только цыплята выпили всю воду, поилка автоматически наливает ещё порцию. Вот так же и корутины работают.
>>648846
Вот о чём идёт речь
https://www.youtube.com/watch?v=McjxK1VBwJ0&
"+0.1 STR from: <ModifierSource>"
Проблема опять же в том, что источником модификатора могут быть разные типы объектов. Как юниты, так и некие эффекты, перки и т.д. Сначала я думал тупо хранить в модификаторе поле object Source и тип этого соурса, чтобы знать, к чему приводить. Но object сериализовать нельзя. Поэтому приходится задумываться о некоем глобальном объекте, который знает обо всех источниках модификаторов в игре и может предоставить таковой по индексу.
Или же написать класс ModifierSource, который будет таскаться с каждым модификатором. Он будет содержать поля всех возможных типов источников модификатора, но только одно будет не равно null (опционально добавить в него поле enum, которое подскажет, какое именно поле должно быть не-null), и парсить источник уже на местах.
> класс ModifierSource, который будет таскаться с каждым модификатором. Он будет содержать поля всех возможных типов источников модификатора, но только одно будет не равно null
Это чудовищно. Не делай так!
Зачем тебе сериализация? Ты хочешь каждому модификатору руками назначить источник? Или сохранять его куда-то? Не проще будет запилить обычный стринг, в котором ты просто пишешь описание модификатора?
Храни в полях строки или именованные константы. А то может быть так, что у тебя прилетает пуля, с ней прилетает модификатор урона, пуля сделав свое дело уничтожается. Спустя пару кадров твой перс перебирает список модификаторов, чтобы посчитать урон и зачем-то обращается к никому не нужным ссылкам на объекты-источники и попадает на высвобожденную память. Жидко пукнув, твоё приложение крошится на десктоп.
Хороший курс по Юнити от UNITY3DSCHOOL
2D Платформер с нуля
https://cloud.mail.ru/public/4Jwu/d9huafGV8/
>>648651
Короче сделал я перебор запись/считку массива поиска пути в фикседапдейте, работает производительнее.
Но у меня теперь такой прикол - массив состоит из структур, объявляю и инициализирую я его сразу в классе моба, protected LocationCheck[] pathList = new LocationCheck[50];. И когда путь считается на несколько мобов - начинаются тупняки, как будто этот массив един для всех и все в него пишут. Если вместо структуры объявить класс с тем же внутренним составом - у меня не получается массив инициализировать предыдущим способом, и в старте тоже не прокатывает, по всем скриптам с ним выдаёт ошибку nullreference.
FixedUpdate - быстрее т.к. скорость апдейта настраивается в ProjectSettings, ты это значение можешь выставить даже "обновлять раз в 5 секунд", но и физика игры будет обновляться раз в 5 секунд.
>nullreference
Просто немного опыта работы со структурами и классами не хватает (структуры не могут быть null и по дефолту проставляются)
>начинаются тупняки, как будто этот массив един для всех
На логику нужно смотреть, fixedUpdate работает синхронно т.е. "посчитал 1 моба -> посчитал 2 -> посчитал 3", могу предположить что ты где-то ссылку на массив держишь в статике и случайно её переиспользуешь
>FixedUpdate - быстрее т.к. скорость апдейта настраивается в ProjectSettings, ты это значение можешь выставить даже "обновлять раз в 5 секунд", но и физика игры будет обновляться раз в 5 секунд.
Там про другое разговор.
>могу предположить что ты где-то ссылку на массив держишь в статике и случайно её переиспользуешь
Объявлен массив в родителе класса мобов, там же сразу инициализирован. Сейчас переделал структуру на класс [System.Serializable] и получилось его инициализировать, как получалось структуру. Но путь считается на одного моба, остальные с нульреференсом висят, видимо массив создаётся один и пользуется им тот, кто первый начал считать путь.
Чот как-то после ТСа не сильно охуевается от типизации Жавы. Охуевается больше от Скалы.
Ну до диез так до диез, хуле поделаеш.
>>647652-долбоеб
https://www.youtube.com/watch?v=GCuCQSyqeXM&t=4s
Возможно ли подобное на Unity? Если использовать встроенный физический движок и некоторые оптимизации?
public static readonly string[] StatKeys = { "Strength", ... };
Но мне не нравится, что придется гадать по индексу, какой ключ я хочу получить, вдруг напишу несуществующий индекс, или не тот, который нужен. Хочу избежать таких ошибок и как-то получать ключ по его константному имени. Но не хочу делать ключи отдельными константами ради расширяемости. Приходит на ум сделать enum EStatKeys { Strength, ...}, а вместо массива использовать статический словарь <EStatKeys, string>, и получать строку-ключ по имени константы из перечисления. Содержимое словаря соответственно будет иметь вид:
{ { EStatKeys.Strength, EStatKeys.Strength.ToString() }, {...} ... }
Но вручную писать сначала объявление энума, потом и объявление этого словаря для каждого класса с таким функционалом как-то не в кайф. Опять же, на ум приходит инициализировать этот словарь проходом по всем элементам энума:
foreach(var elem in Enum.GetValues(typeof(EStatKeys)))
{
StatKeys.Add(elem, elem.ToString());
}
НО он по логике должен быть ридонли, его можно менять только в конструкторе класса, а мне его в принципе менять не надо, надо изначально задать и все. Какие могут быть решения? Реквестирую советов мудрых, может есть какие тайные фичи, которые помогут?
Хуй знает что там у тебя но я с интерфейсами ебался достаточно долго времени пока не узнал что все мои кастомные скрипты для юи это велосипеды которые уже давно есть в юнити из коробки и находятся они во вкладке layout. Без вот этих двух компонентов на пикрилейтеде например, скроллрект бесполезен.
У меня на анимации завязаны некоторые скрипты, так вот я хотел бы быстро по нажатию кнопки пропустить анимацию и перевести её в финальную позицию сразу.
Как это сделать?
Сложно ли будет вкатитьтся после тырпрайза на шарпах?
Делаю так, чтобы потом делать вот так:
StatKeys[EStatKeys.Strength] // "Strength"
Я же написал, если юзать чисто массив, то придется получать из него значения по числовому индексу, а это понятность кода снижает, будешь потом постоянно вспоминать, в каком индексе у тебя лежит то или иное значение. Если юзать чисто стринг, то можно оебиться на криволапии ("Strngth", "strength" != "Strength"). Гораздо нагляднее (и надежнее), когда ключ получается по именованной константе из енума.
Зачем инициализирую словарь в статическом конструкторе? Так ради расширяемости же. Если в игре появится новая стата, это делается в одно движение: добавляешь ее в енум и все само собой подхватывается по цепочке.
За последнее издание не скажу, но в прошлом было очень много воды. Тем не менее, она неплохо помогает в освоении большинства базовых знаний по юньке за пару вечеров.
В тырпрайз после юнити вкатиться гораздо сложнее, чем наоборот. Тебе просто нужно будет привыкнуть к особенностям архитектуры и выучить чутка синтаксиса. Все.
Вот основное, что тебе нужно знать:
- Нативная многопоточность сосат. Придется строить костыли, предоставляемые юнькой.
- Генерация мусора сильно бьёт по производительности. Плохая новость для любителей LINQ и тех, кто объявляет классы внутри циклов, например.
- Тебе будут говорить, что паттерны не нужны, но они нужны.
https://www.manning.com/books/unity-in-action
Эту книгу надо читать?
Это прошлое издание. Читал его год назад, уже тогда там была устаревшая инфа.
За последние пять лет перепилили интерфейсы, систему префабов, системы рендера, несколько других систем. Читать ещё можно, но для большей актуальности рекомендую издание 2018 года.
Пойдет:
public static readonly Dictionary<string, string> StatKeys = {
{"Key1","Value1"},
{"Key2","Value2"}
};
Но лучше использовать enum - так правда меньше шансов потом ошибиться и .ToString() каждый раз будет генерировать CG мусор - а это для производительности плохо
другой анон
>public static readonly Dictionary<string, string> StatKeys
обосрался, так правильно:
public static readonly Dictionary<string, string> StatKeys = new Dictionary<string,string>(){
{"key","value"}
}
А вообще если тебе нужно только наличие, то вообще заведи List<string> и проверяй наличие методом .Contains("Твое значение")
Я тебе в прошлом году советовал посмотреть видосы XPUCT на ютубе по сишарпу. Ты посмотрел? И не отнекивайся, это был не другой анон, это был ты, я тебя узнал.
Вот тебе ссылка на первый урок https://www.youtube.com/watch?v=MGypxPUNtWk
Заваривай кофе, нарезай печеньки ломтиками.
Хз кто как считает, но эта книженция это как библия по шарпам, как минимум по моему опыту. Пусть она немного и протухла.
>49-24
Я сталкивался с этой проблемой. Могу вот что сказать:
1) Я не смог найти, как сделать свои звуки именно печатания, если найдешь как то поделись пожалуйста, тоже интересно.
2) Решил проблему костыльным способом- попросил звукаря для каждого диалога предварительно подготовить свои аудиозаписи, и уже в фунгусе через функцию проигрывания звука озвучивать диалоги. Благо у меня было не много диалогов.
Отправляю такой запрос
Texture2D texture2D = TextureToTexture2D(texture);
List<IMultipartFormSection> formData = new List<IMultipartFormSection>();
formData.Add(new MultipartFormDataSection("description", description));
formData.Add(new MultipartFormFileSection("upload", texture2D.EncodeToJPG()));
UnityWebRequest webRequest = UnityWebRequest.Post(_uriCreateArtObject, formData);
webRequest.SetRequestHeader("Content-Type", "multipart/form-data");
webRequest.SetRequestHeader("Authorization", "token 75f8s7df75218735f8787a5s87d587587g587583d");
yield return webRequest.SendWebRequest();
и получаю ошибку Curl error 18: transfer closed with 111 bytes remaining to read
через постман все ок
Какие же крутые игры делают на ЮНИТИ.
Может кому интересно.
«Во время кризиса COVID-19 мы стремимся поддерживать сообщество с бесплатным доступом к Unity Learn Premium в течение трех месяцев (с 19 марта по 20 июня). Получите эксклюзивный доступ к экспертам Unity, интерактивным сеансам, учебным ресурсам по требованию и многому другому.»
https://unity.com/products/learn-premium
https://youtu.be/waHH86zTkx0
> Собираюсь обмазаться Lua сприптом, посмотреть что это такое
Обмажься бесплатными реализациями.
https://www.lua.org/download.html
Пять секунд гугла и статья от 2014 года
https://habr.com/ru/post/211576/
Я правда ХЗ, работает ли описанное там сегодня и, если работает, то осталось ли бесплатным?
https://stackoverflow.com/questions/48793217/how-can-i-reflect-a-point-about-a-line-in-unity
Чот ты накаляешь своей тупостью, братишка. Пойду воздухом подышу. А ты держи скриншот.
бесплатно на три месяца открыли
Я не шарю именно в юньке, но тут ошибка никак не связанная с шарпом, это ошибка сервака... Проверь запрос и то что передаешь еще раз, например в дебагере само тело запроса просмотри и сравни с тем что через постман передаешь, скорее всего в этом чето не правильно.
Анон, насколько юнити требовательный к уровню знания шарпа?
Насколько я понял, он требует больше знания программирования в целом, ну там алгоритмов разных действий в двухмерном и трехмерном пространстве и т.д. Пока чего-то требующего знания шарпа я не заметил, под этим имею ввиду что его можно было бы зменить на любой язык из мне известных и ничего бы не изменилось.
мимо разраб на шарпах перекатывающийся из тырпрайза, учу юньку меньше недели
Понимешь, тут дело в том что шарп интерпразнутый язык до мозга костей, а в тырпрайзе совершенно другие задачи, нежели в гейдеве. Тут шарп это скорее скриптовый огрызок по моим ощущениям, поэтому я не думаю что тут нужен прям большой уровень знания шарпа. Лучше, наверно, математику и физику подтянуть.
> Тут шарп это скорее скриптовый огрызок по моим ощущениям
>>650606
> мимо разраб на шарпах перекатывающийся из тырпрайза
Хуя в тырпрайзе специалисты. Знакомых юзингов не увидел в начале файла и уже думает, что тут шарп какой-то не такой, какой-то обгрызенный.
мимо самоучка
первым делом попробовал подключать к проекту юнити различные неймспейсы платформы, потом сторонние сборки, в том числе через нугет - и довольно урчал, когда всё работало
нашел его, он же сам и говорит кек
https://www.youtube.com/watch?v=Y3Rs1z7it5M
Ну мб ты прав, но выше кто-то писал что тот же LINQ тут редко используется для оптимизона, а в тырпрайзе он повсеместен, например.
Шарп крут в плане функционала доступного из коробки, спору нет, но что-то у меня есть подозрения что юнька не использует большую часть этого функционала, ибо он в игре тупо не нужен.
> выше кто-то писал что
Вся суть местных чмонек да вообще-то подавляющего большинства индюков по всему миру в том, что они не знают шарпа, да что шарп, не знают информатики в целом, что собственно ярко проиллюстрировано: >>650617
Поэтому и получается то, что мы видим на рынке игор - говно и треш.
А насчёт функционала, посмотри на игры крупных студий. Очень часто можно видеть в начальной заставке серию логотипов, среди которых помимо движка несколько коммерческих технологий. Очевидно же, что возможность сопряжения со сторонними модулями, библиотеками, серверами - заложена в современные движки. И если ты не видишь эту возможность, это не означает, что такой возможности нет.
>они не знают шарпа, да что шарп, не знают информатики в целом
Классика, я даже на stackexchange натыкался на посты о гемдеве в духе "паттерны для энтерпрайза, в геймдеве паттерны не используются".
Проблемы я вижу две.
Первая - в юньке и геймдеве в целом много новичков-самоучек, юнька легка в освоении и дружелюбна, а также предоставляет огромное количество возможностей наговнокодить. До такой степени, что активно тебе мешает в выстраивании адекватной архитектуры.
Вторая - шарп позиционируется как высокоуровневый абстрактный язык, где быстродействие находится на пятнадцатом месте, после читаемости, тестируемости, расширяемости и прочее, и прочее. Отсюда у вкатываетелей складывается ощущение, что оптимизации вообще не нужны, или в лучшем случае их можно сделать потом, никогда перед релизом.
В результате мы видим мемы про взрывающиеся телефоны от юньки.
>юнька не использует большую часть этого функционала, ибо он в игре тупо не нужен
Не то чтобы он в игре не нужен, просто юнити сам по себе ебанутый. Практически все обращения к компонентам используют под капотом нативный код движка, что не позволяет адекватно юзать шарповый многопоток, таски, таймеры, вот это всё. Плюс другие фичи, например, Math и Numerics, уже встроены в движок ради оптимизаций (иногда довольно сомнительных). Плюс альтернативы шарповским фичам вроде ивентов, которые по сути та же хуйня, только с другой стороны. Плюс другие задачи и требования к производительности (в тему LINQ, а некоторые аутисты я в их числе даже foreach не юзают ради оптимизаций).
На самом деле настоящий ад перекатываться из тыпрайса в юнити или наоборот. Думаешь, что все знаешь, а оказывается все совсем по-другому.
мимо работающий в обеих областях одновременно
По сабжу писал первый способ из https://www.youtube.com/watch?v=oZ1gmpnQBFg
но так как я ньюфаг, то масса вопросов и не знаю даже как активировать в юнити скрипт. (Перетаскиваю на инспектор, а оно пишет ошибку.) Два часа уже пытаюсь разобраться как сделать.
Юнити дарят три месяца премиум-обучения в честь коронавируса! Налетай! С регистрацией, но без смс!
Во-первых, сохраняться в реестр - жуткое извращение. Так никто не делает. И ты не делай.
Во вторых, может тебе пока рано сохранения пилить, если у тебя проблемы с отладкой скриптов?
Лучше потратил бы эти два часа на базовые туториалы/книги по юнити, больше пользы будет.
Как тебе сказал >>650736 этот госпадин, сохранение это гемор, я не стал смотреть видос, но предложу тебе еще 2 варианта:
1 - EasySave - старый плагин, нужно в ручную каждую штуку сохранять (примерно как и PlayerPrefs), только там можно прям классы сохранять, давным давно пользовался когда был нубом и у меня даже вышло.
2 - Если со скриптами туго, лучше сделай систему вейпойнтов и сохраняй только точку, до куда дошел игрок, тип поршел треть и сдох? - начинай с контрольной точки. Так будет намного проще "сохранять/загружать" чем в ручную записывать каждый объект в сцене
> в ручную записывать каждый объект в сцене
А если каждый объект в сцене будет при значимых изменениях своего состояния посылать сообщение в эфир с новыми данными? А некий, скажем синглтон (ууу, антипаттерн, дальше не читал) будет ловить такие сообщения и тщательно записывать в свою тетрадочку. А когда игрок нажмёт Ф5, то этот дядя с тетрадочкой запишет содержимое тетрадочки в файл. А когда игрок нажмёт Ф9, этот дядя загрузит содержимое из файла, пробежится по нему и разошлёт специальные сообщения о том, что он загрузил. А все объекты, о которых сказано выше, подписаны на такие сигналы и при их получении выставят значения своих параметров.
Ты про это плагин? Оно дорогое что-то.
https://assetstore.unity.com/packages/tools/input-management/cross-platform-easy-save-the-ultimate-serialization-plugin-129177
>2
А если надо будет выйти из игры, то придётся всё заново, точки же никуда не сохраняются.
>>650757
Мы тут вдвоём сидим, понимаешь? Я просто видел успешные люди сохранения через реестр делают и фангусом обмазывают, поэтому другие методы для меня извращение. Ещё локации и инвенты на сцены разбивают, но данные у них не пропадают как у меня. Похоже надо поискать другое место где спрашивать.
Вот про это я говорил:
https://assetstore.unity.com/packages/tools/input-management/easy-save-the-complete-save-load-asset-768
даже сейчас можно найти на каком-нибудь сайте.
>>650743
Ну так напиши такой код, который это обработает, лол.
Синглтоны подходят для ГД т.к. тут работают другие правила успешного продукта, а именно "делай проще"
Посмотри, как он включает пост проц
https://www.youtube.com/watch?v=WiDVoj5VQ4c&t=657s
Он довольно ебнутый в новых версиях, там играет роль еще то, на каком леере или какой тег на обьекте где пост проц висит. Много всякой дичи. Вообще погугли просто как новую версию использовать, в интернетах много инфы как переезжать на v2 пост проц.
Я вкатыш из /pr/, сейчас в поисках работы. В том числе в игровой индустрии. В портфолио есть две игры на андроид, но они, фактически, написаны на голой джаве с опенгл, а часто требуются знания петушиных движков, в основном - Юнити. Вот и возникла идея ебнуть быстренько игру. Вся игровая логика уже продумана, уровни придуманы(это будет головоломка), точнее, написан генератор уровней на плюсах(тоже в качестве тренировки к собесам, лол), который их придумал и записал в файлики. Осталось только освоить быстренько Юнити(в объеме, достаточном для примитивной 2д-игры) и нарисовать несложный арт. По Юнити у меня пару вопросов:
1. Насколько требователен сам движок? Я просто сижу с некропека фактически без видюхи - даже опенгл выше 1.1 нет. Про директх вообще молчу - 9.0с потолок.
2. Есть ли простой туториал вроде видоса на 10 минут? Мне главное знать общую архитектуру приложения, как вывести спрайт и звук, ну и инпут.
Есть некие сложности с идентификацией обьектов. Как ты сохранишь, скажем, сундук в файл?
Можешь дать ему уникальный Id, по которому будет происходить сохранение/загрузка координат. Дальше что? Если у тебя 10 сундуков, то можно каждому назначить свой Id (ебанешься так делать). А можно написать алгоритм в духе "сохраняем 10 одинаковых сундуков по одному id, загружаем и расставляем 10 одинаковых сундуков". Но один хуй на каждую группу объектов придется делать id и держать его где-то.
И это без содержимого сундуков или динамического создания/уничтожения объектов.
Не уверен, что могу рекомендовать тебе юнити. Тут сейчас табуны вкатывателей юнидрочеров ходят, ежедневно все ящики ломятся от курсов по юньке, работодатели зажрались, работы нема.
Знания движка полезные, конечно, но будь я тобой, то ломился бы в экзотические вакансии на мертвых языках. Туда ньюфагам обычно страшно идти, а по требованиям только алгоритмика без определенного стека.
Дело в том, что я ищу специфические вакансии, если речь про игровую индустрию - программист игровой логики или программист ИИ. Я для них в принципе подготовлен, алгоритмы знаю, математику знаю, но не хватает знаний самих языков и движков, в которых придется работать. Вот и хочу просто поверхностно ознакомиться с Юнити.
> каждому назначить свой Id (ебанешься так делать)
Зачем назначать вручную, если при создании сразу уникальный айди генерируется?
Никаких сложностей с сундуками не вижу. В том числе с содержимым. Любое содержимое любого контейнера это всегда просто [ список ] не вижу сложностей записать список в файл.
> на каждую группу объектов придется делать id и держать его где-то
Какие сложности? У тебя есть локация. Это уже готовый родитель, корень и создатель объектов внутри себя. В файле сохранения генерируешь пути вида "локация/группа/сущность" вот тебе и уникальный айди.
Карочи, выдумываешь сложности на пустом месте. Спокойной ночи!
>программист игровой логики или программист ИИ
Интересные, кстати, темы. Я, волею судьбы, оказался фуллстак прогером в геймдеве (если такой термин существует), но всегда засматривался в сторону ИИ как в фундаментальную специальность.
Ты изучал эту тему как-то особенно/книжки какие-то порекомендуешь?
Не изучал. В универе был ИИ(нормальный, а не игровой) в рамках курса по обработке информации, при этом не дата сайнс и нейроночки, а нормальные алгоритмы. Отсюда знание алгоритмов(поиски по деревьям, методы оптимизации поиска), базовой теории игр(имеется ввиду раздел математики, а не геймдизайн), и все это легко наложилось на обширный игровой стаж. На самом деле читать-то особо нечего, если ты пиздюком придумывал игры на тетрадных листочках или хотя бы играл в сложные рпг или стратегии, где нужно посидеть и спланировать, что и в каком порядке добывать, что крафтить и кого бить. А так достаточно прочитать википедию на предмет вышеназванных тем и подучить соответствующие алгоритмы. Закрепить можно, взяв любой современный движок, и заебенить более-менее сложный ИИ с помощью деревьев. Если же ты говоришь про нормальный ИИ, то тут я не помощник - это тебе к датасаентистам. Там ничего интересного - сидеть ковырять практически по рандому нейроночку и выжимать из нее доли процентов при распознавании грубо говоря. Есть еще особые разделы, на которые в тайне дрочат все датасаентисты, потому что осознают ущербность того, чего делают - когнитивные вычисления, machine reasoning(совершение ИИ выводов на естественном языке) - этим заниматься можно только в лабораториях и университетах, ибо пока что это фантастика.
Проснись, ты обосрался. Уникальность и персистентность - разные вещи. Мало того что нет простого способа линковать инстансы с префабами, так ещё и instance id может рандомно измениться при перезапуске.
https://answers.unity.com/questions/863084/does-getinstanceid-ever-change-on-an-object.html
>>650785
Скачивай 2017.2 юньку и учись. Туториалы на самом деле говно собачье, читай документацию, все видео по юнити - просто мусор созданный долбоёбами для долбоёбов, по ним ничему не научишься. Читай текст.
Вот у юнити есть DOTS, который заставляет создавать массив данных и передавать его в IJob.
А вот есть я, который не может (или не хочет) делать дизайн таким, чтобы можно было легко разделять данные.
Но есть идея перенести всю логику в BackgroundThread-ы, просто запустить их при старте (Application.ThreadCount) и кидать свои кастомные джобы как Action в какой-нибудь ConcurrentStack или Queue, и в основном потоке выполнять обновление Transform/создавать Go/и тд.
Сразу вижу проблему с GC т.к. каждый Action - это GC, потом еще возможно будет сложно создать GO и дальше работать с ним.
Насколько этот вариант пригоден для жизни вообще?
И может кто-то уже решал такие проблемы?
Дотс это целый стек, который, возможно, получится разделить и использовать раздельно жоп системсы и ецс. А вообще я когда-то давно пилил подобную хуйню, когда нагуглил кастомные системы с инвоками мейн треда из дочерних, показалось пиздец сложно. Так что я насрал две системы - одна в дочернем треде крутится, вторая в апдейте. Ну и два типа жобсов на основе структур. Go создавались в мейн треде, если фоновому тредовалось создать Go - создавалась задача на создание Go и добавлялась в список задач для основного потока. Фоновый умел в эвейты и прочую чушь. Спасло меня малое разнообразие задач, потому что система разсиралась просто огромная.
>>650846
В сундуке метод схоронить, в который входит и выходит массив байтов. В методе дописываешь в массив нужные байты - три флоата, один бул isMimic ну а хуле - сундуки есть, а мимиков нет? , ссылка на префаб это один ushort, который указывает на номер префаба в скриптейбл объекте. Если игра предусматривает рандомную генерацию параметров на предметах, то каждый предмет имеет метод сейв, а если предметы созданы заранее - то просто intы, не более. И срёшь на диск вот этим всем, лол.
Я тыкал по кнопочке AddEvent в окошке анимации, но там ебала какая-то. Пользуется кто-то вообще таким? Все норм у вас работает?
Я с Юнити не работал, но не проще иметь список ВСЕХ объектов в игре, при добавлении в который нового объекта, ему присваивается имя исходя из имени предыдущего и правило наименования. Ну или банально на основе порядкового номера данного объекта в списке? В списке также может быть ссылка на сам объект для быстрого доступа. Еще у каждого объекта могут быть в этом же списке флажки состояний. Можно иметь несколько списков под несколько типов объектов. Хуйню, наверное, сморозил...
А, люди.
Подскажите, что делать, если нет скилла для полноценной игры, но нет идей для чего-то интересного из "мелкого инди"?
Года с 2015 делал горсть мини-проектов "для себя" (платформеры, что-то типа смеси тавердефенса с тиром, пошаговка, подобие Дварфов, пикрелейтед)
Но когда обдумываю "что сделать, чтобы !!ух!!", то сталкиваюсь с тем, что что-то крупное или не зайдет никуда, попутно сожрав кучу времени (см дварфы, которые из-за моей криворукости застопорились на моменте с большой картой с ландшафтом) или будет не интересно никому, кроме меня и улитки в аквариуме у монитора (потому, что она смотрит на все, что шевелится)
Откуда взять мини-идеи, чтобы хоть не мировая-знаменитость аля Андертейл и подобное(да, я в курсе, что оно не Юнити), но хотя бы что-то играбельно-веселое придумать.
Йоу, спасибо! Да, проблема в файле, который я пытался загрузить. По описанию ошибки понятно, что сервер закрывает коннект до того, как файл загружается полностью, но почему- хз. Анон выше люто ратует за тулзы. Теперь и я ратую, т.к. всё заработало, а код без лишних корутин с коллбеками и прочей лапши
>стабильность
)
>перфоманс
>переписываем всё на DOTS
>до конца так и не сделали DOTS
Т.е. и дальше сидим на костылях
> визуальный язык программирования
блюпринты какие-то
> Анимации в DOTS DOTS DOTS
ну подождем еще пару лет
> Освещение
> Добавят разделение настроек лайтинга
Многие профи запекают тени в стороннем софте, но что-то там улучшают, ок
>World-building
Сделали: probuilder 4.0, scene visibility, scene lock, grids, terran holes
Prerelease: proBuilder 4.3
In Dev: Customizable toolbars (но сейчас же и так можно создавать свои окна?), Snap, align and pos improvements - вода какая-то
> VFX
> Будем фиксать баги
молодцы
> AI
Прям в движке можно редактировать текстуры, интересно
Можно научить AI играть в игру и тестировать её
> Camera Design
DOTS DOTS DOTS
> Working with assets
Lazy loading
> Universal Rendering
Хотят довести до ума и сделать стандартным рендером
> HDRP
> Ну мы улучшаем его))0
> Physics
> Havok 0.2.0 Preview
> Network
Сплошная вода, "будем делать онлайн игры еще лучше и DOTS DOTS DOTS"
>визуальный язык программирования
>блюпринты какие-то
Это они зря. Я как профиконстрактер все время ждал чего-то такого в юнити, и уже код освоил и уже считаю что вижуал скрипт говно. Но черт бы с ним, но скоро начнут пилить уроки по нему и все будет загажено лапшой, как у анриала.
>> AI
>Прям в движке можно редактировать текстуры, интересно
>Можно научить AI играть в игру и тестировать её
Вообще не понял, что это за хрень, по-моему бесполезная трата ресурсов очередная, у них половина отделов в пустую трудятся.
>будем делать онлайн игры еще лучше и DOTS DOTS DOTS"
Тоже не понял, какая мне разница, что там за дотсы, мне нужен рендир, чтобы красиво, и чтобы запекался мгновенно, и чтобы импорт не ломался на полтора месяца, и чтобы функций, чтобы нихуя не делать, и все само делалось. Каких-нибудь материалов 10к штук профессианальных. Они не понимают, что важнее иметь сто готовых крутых эффектов, чем усложнят инструмент на котором их делать, потому что что проф студии у которых есть отдельный профи на эффектах не берут юнити, а индюкам невозможно на высоком уровне освоить вообще все. Нужны паки анимаций на все случаи жизни, материалы готовые, шейдеры, генераторы растительности всякие. Анриал в этом плане лучше понимает, из магаза бесплатные раздает, но и они плохие, потому что отдельные небольшие паки. Посадите сабстенсдизайнера, пусть за пару лет несколько тыщ материалов сделает
Хороший курс по Юнити от Unitystudy.ru
https://cloud.mail.ru/public/au93/33cJnnRxV/
128 книг по Юнити:
https://yadi.sk/d/GGKCL4mAn7I-QQ
О, заробило. Спасибо этому гайду: https://simpledevcode.wordpress.com/2015/12/29/flood-fill-algorithm-using-c-net/
Ебанько? Ты не знаешь че несёшь клоун всратый.
Epic toon fx тот же 300 эффектов и 900 вариаций в сумме, всего за тридцать баксов
> Пак материалов хотя бы 2к штук
Если тебе так дохуя надо то покупай подписку на gametextures.com и не еби людям мозги, нормальным людям хватает паков по 100 материалов для своих задач
Ебаная нищета совсем охуели
>Где там эффектов хотя бы штук 300, дура?
>Показали Пак эффектов на 300 штук
>УУУУ ЭТО НИ ТАКИЕ ЭФФЕКТЫ КАК МИНЕ НАДА))
Ебать шизик, я ебу чего тебе там надо, мультяшные или нет? Ты сказал что нету паков на 300 штук, я тебе кинул первый который вспомнил, есть ещё дохуя в любом стиле.
Алсо
>2d говно
Ебанутый ? Там 3д эффекты
>Может еще нанять себе личного художника, дура?
>Кококо мне предлагают тысячи человеко-часов работы за десяток баксов в месяц, но я буду верещать что мне все нужно бесплатно кокок я мерзкая оборзевшая нищепидораха, не уважающая чужой труд но почему то думающая что все должны уважать мой
Отвратительно
>Начал пиздеть про эффекты и материалы
>Обосрался
>ААААА зато анимации и шейдары не найдешь)))
Иди одноклассников троллируй этой хуйней, клоун
>годный 3д Пак шейдеров Пак анимаций
Ебать дебил, определение годного какое у тебя? Мне делать нехуй тебе тут что-то искать, а ты потом будешь кукарекать что НИТОЧТОНАДА))) ХУЛИТАКДОРОГО))) если надо ищи сам, я уже тебе уже указал на парашу после того как ты кукарекнул что нормальных паков нет, больше мне доказывать ничего не требуется
https://assetstore.unity.com/packages/vfx/particles/ultimate-vfx-26701
Вот ещё один, 300 эффектов за 40 баксов
>Один Пак только нашел
>Два пака только нашел
>Десять паков только нашел
>Сто паков только нашел но они не такие как мне НАДА)))
Да да, продолжай обсираться, клоун
прикручиваю ironSource рекламу
вылетает такая ошибка:
Duplicate class android.support.v4.app.INotificationSideChannel$Stub found in modules classes.jar (:support-compat-27.1.1:) and classes.jar (androidx.core:core:1.0.0)
нагуглил что нужно дописать это в gradle.properties:
android.useAndroidX=true
android.enableJetifier=true
но где gradle.properties ?
gradle кастомный
Если да, кто-то может пояснить как этот алгоритм работает?
Нейросети не пишут на питоне, их пишут на С++.
На питоне пишут клиентскую обвязку, чтобы ты смог запустить эту нейросеть с нужными параметрами на нужных данных.
Твоё утверждение по уровню непонимания утверждаемого тобой звучит примерно так же, как "википедия написана на html", без понимания того, что у неё есть бэкенд на сервере, который написан не на html.
Скорее всего, мои посты и видишь. Суть алгоритма заключается в объединении рядом стоящих отдельных квадов в один большой, уменьшает количество треугольников (если говорить о майнкрафт-лайк поверхностях)
Суть то ясна, просто не могу найти хорошее описание деталей работы алгоритма.
> наверняка будет большой оверхед
Если оверхед написан не тобой и при работе не отнимает слишком много ресурсов, немного увеличивает размер выходного бинарника. НО при этом даёт тебе удобный функционал так, что ты можешь делать игры, а не движок. ТО почему бы не воспользоваться?
Все прогнал через один монобехейворский апдейтер, вызывающий экшены этих спрайтов. Количество спрайтов в движении на экране 9к - 60 фпс.
Без этой фичи 5к спрайтов - 60 фпс.
Но если вкидываю туда колижены и райджтбоди, физика сжирает прям все ресурсы и количество спрайтов максимум 200-300. Что я делаю не так? Мне это не нравится. 9к спрайтов мне нравилось больше.
Я не хочу пилить физику на движке. Это бред. Зачем тогда движок?
Асинки пока не рассматриваются, все на одном ядре.
Прилагаю скриншот профайлера без всякой физики
Там просто бокс колизии. Я просто чекаю, что надо остановится, если ты в кого-то врезался. Если я это сделаю банальными радиусами с перебором всех, это будет гораздо быстрее, чем эта херня. Но тут проблема, я начинаю делать что-то за движок, пытаясь на более верхний уровень натянуть костыли более нижнего. Это не хорошо.
Это нормально. Считай движок обычной песочницей с большим количеством неоптимизированных решений. Хочешь сделать что-то оптимально - делай это сам.
По теме - можешь подкрутить настройки коллайдеров, rigidbody и физической вкладки параметров. Но вряд ли ты выжмешь больше, чем вдвое-втрое от того, что сейчас. Простые векторные расчеты будут быстрее, чем физика коллизий.
Я тестирую это на старом девайсе, в качестве объектов - пачка спрайтов, из-за альфа блендинга все это дело выдает где-то 40 фпс. Включаю режим одной камеры - прироста ФПС нет.
Но если сделать, что бы камера 1 рендерила в текстуру - то 2 камеры будут выдать порядка 30 ФПС.
Вопрос - в чем разница? Почему рендеринг камерой не сжирает ФПС, а рендер камерой в текстуру - сжирает. В обоих ведь случаях идёт полный проход по фрейм буферу.
https://youtu.be/L9_7QYaeNjc
Видео отвалилось
Я это никак не регулировал - просто назначил камере рендер текстуру. Если я правильно тебя понял - то процесс рендеринга в тестуру по умолчанию вызывается в OnRenderImage.
Т.е. я должен вызывать рендер в текстуру руками, и камере не назначать рендер текстуру - ты это имел в виду?
Не, по умолчанию всё ок, там производительность падает вдвое, как и должно быть. Ради прикола проверил, 4.5к юнитикубов с коллайдерами и две камеры - одна в текстуру, вторая на экран. С одной 100 фпс, с обеими уже 60. Может, ты в какие-нибудь буферы упёрся, хуй знает. Никто не поддерживает старые устройства и ты так делай. Был ещё какой-то баг с иос, когда буферы не чистились, ещё лечилось дебильно - добавлением камеры, которая не рендерит никуда.
Планирую делать симулятор космического корабля Союз-ТМА. У меня имеется математическая модель движения этого корабля (одна из самых точных), которая принимает в себя начальные условия (параметры орбиты и начальное состояние корабля), а на выходе дает положения корабля в пространстве и его скорость с шагом 1 мс. Вопрос - подойдет ли Юнити для реализации графической составляющей(планета Земля и корабль с возможностью получения текущей позиции, ориентации и скорости объектов по протоколу TCP)&
Аноны, подскажите пожалуйста книг по скриптингу в юнити.
Я подумал, что лучше создам хеш тайлмапы и переведу объекты в плоскость тайлов, где каждый объект будет прописываться в конкретной клетке на карте. Это будет незаметно для пользователя, а все обсчеты будут типа "Спросить есть кто там в матрице по прописанной клетке, если есть - ну че, братан делай че-нибудь".
Это работает очень быстро, т.к. тупо запрос к ячейке памяти. Так же я могу прописывать объекты на несколько клеток сразу, делая их более "толстыми" и выписывать сразу из всех клеток. Таким образом, я задам радиус коллизии. Да, не очень удобно в подходе с динамическими играми, но для моей мини-стратегии подойдет.
За пару дней накатаю базовый прототип и проверю.
Да, вся логика у меня отдельно просчитывается, в Юнити же только графика - вид от первого лица в кабине космического корабля и панель управления с интегрированным в нее GUI штатного ПО Сюза. С Юнити просто происходит обмен UDP пакетами, так что в данном случае Юнити выступает в роли СИВО(Системы Имитации Внешней Обстановки).
Я не слышал, чтобы приглашали делать игры на джаве (кроме андроидных) или сишарпе. Но на C++ да.
>>651460
Бред. Всем и так ясно, что слои нейросетей и всяких тензорных операций реализованы в бинарниках, иначе питон просто не потянет. Но ведь сами нейросети можно писать на питоне используя керас или питорч, они из слоёв накладываются друг на друга, а исполнение отдельных слоёв уже происходит в оптимизированном машинном коде.
Что насчёт википедии, то это не уместно, так как википедия это набор статей, склееных по определённым идеям и соглашениям. Твоё утверждение подошло бы их движку, викимедия или как там его.
здесь рекурсия, чтобы понять зочем нужна нейросеть, нужно иметь собственную нейросеть.
Анончики, я тут продолжаю свой рогалик пилить, и сейчас стоит вопрос реализации полосочки ХП/стамины над головой вражины во время удара. Сильно накладно по производительности будет на каждого нпс свой canvas создавать? И если да - то есть ли простые альтернативы?
Если у тебя несколько сцен и хочешь делать "понятный красивый код" - GameObject.Find(ObjectNames.GoConstName).GetComponent<Type>.
Если ты один и у тебя одна сцена как у меня - испектора с префабами достаточно.
Кстати заворачивать эти объекты в префабы тоже норм варик.
>>652127
Конечно сильно накладно, вот секунда в гугле и ответ:
https://answers.unity.com/questions/799616/unity-46-beta-19-how-to-convert-from-world-space-t.html
>вот секунда в гугле и ответ
Ну там у него один таргет, а у меня количество полосочек не определено, то есть ударю сразу пять вражин - пять полосочек над головами, ударю двух - две.
Не мог бы ты объяснить чем будет плох допустим небольшого размера world space канвас, привязанный к нпс и активирующийся при нужде а потом опять дизэйблящийся?
Делать канвасы на каждую хп как делать камеру на каждого солдата, зачем тебе делать 1000 раз то что можно сделать 1 раз?
Да, тебе не нужно знать все твои полоски, ты сделаешь метод (как в том форуме) и будешь передавать в него список своих полосок.
Если твоих солдат расставляешь ты сам, то добавляй их например в public static List<Soldat> _nvm = new List<Soldat>();
потом можешь через for while foreach (что угодно) проходить по этому списку и говорить "дай мне позицию солдата на канвасе" это будет в сотни раз быстрее чем и правильнее чем делать на каждого солдата канвас
Если ты ОКР касательно перформанса и хочешь выиграть 0.01 наносекунды на каждый префаб - то прокликивай руками. Или если у тебя тысячи объектов подгружаются.
Я раньше так делал, сейчас понял, что продуктивней и проще лишнюю работу выносить в скрипты. Чем меньше тебе настраивать в инспекторе - тем больше времени останется на важные вещи. И проект почище.
tg @comewithme
Почему если у материала Render Mode = Fade, объект не принимает тень? Только когда = cutout.
Чтобы при активации действия шла анимашка, но зациклен был лишь ее конец?
Сделал я 3д модельку, прикрепил кости и спустя много времени увидел, что у костей вперед это Vector3(0,1,0) а вверх это Vector3(-1,0,0)
Хочу сделать, чтобы lookAt работало, написал
var _orientation = Quaternion.LookRotation(new Vector3(0, 1, 0), new Vector3(-1, 0, 0));
var _bipedRotationFix = Quaternion.Inverse(_orientation);
и успешно вызываю код:
HeadBone.LookAt(targetPos);
HeadBone.rotation = HeadBone.rotation * _bipedRotationFix;
А теперь хочу, чтобы кость головы не крутилась на 360 градусов и не могу это сделать, через localEulers и clamp по x и z он оработает пока я стою перед моделькой, если захожу за спину, то её разворачивает до -180 (хотя в клампе стоит 70), и хз что делать.
У кого-нибудь была такая проблема?
Уже думаю модель всю переделать из-за этого
В 2019 таймлайн переделали, что-то вообще туториалы из 2017 не подходят. Есть актуальные?
1. Как быть с отрисовкой больших воксельных моделей, где требуется большее количество вертексов?
Делить на несколько мешей?
2. Насколько дико каждый воксель делать отдельным мешем (с учетом, конечно, отсечения граней)? На пике - один меш, 20x20x2.
У кого как, некоторых карантин не коснулся вообще.
>>652798
Это не юньковское ограничение, а хардварное. Большие модели разбивай на модели поменьше, очевидно же. Когда не влезаешь в лимит по полигонам - создавай новый меш. Но я бы шёл от противного, создавал объект, который не может в принципе содержать максимальное количество полигонов, и набирал из таких объектов всю сцену. И помни, что вершины часто густо дублируются.
Делал по туториалу, получил ошибку при запуске на устройстве: AndroidJavaException: java.lang.ClassNotFoundException: com.cw.unity.MyPlugin
До этого андроид студию в глаза толком не видел, но делал все по туториалу.
Java код: https://pastebin.com/UWNBTRug
C# код: https://pastebin.com/TmqL8mX0
Что я могу делать не так?
Я давно это делал и все забыл, сразу смущает приватный конструктор, ты можешь попробовать запустить java код без юнити, а просто через еклипс.
А еще лучше сначала сделать даже без статиков, а самому создавать инстанс класса и вызвать метод простой.
>>653402
В течении года поправят, а сейчас никак, я на своем режим энергоуправления настроил и число кадров порезал
>>652960
Похоже будто на 1й кадр применяется анимация, в магике можно анимации делать?
Начал недавно изучать шейдер граф. И заодно пиксельную графику.
Есть небольшой вопрос. Как зайти за пределы текстуры?
Т.е. есть рисунок 16x16 полностью заполненный. Хочу сделать обводку, но сосу хер, т.к. места для нее нет
Анон ПАМАХИ.
Пару лет назад ковырял уеч для интереса. Ща решил поковырять юнити. И сильно уебался - я не понимаю принципов архитектуры юнити.
В сраном уече были GameMode\GameInstance\GameState классы, которые гарантированно появлялись в определенный момент.
И в них можно было написать какую то логику первичной инициализации и не парится, что блядь какой то объект проснется раньше все и получит кучу нуль референсов.
В юнити все что я нашел - костыли. Костыльные недосинглтоны, костыльные геймстейты, костыльные костыли. Блядь, как так жить то?
Можно где почитать про базовые архитектуры и бестпрактиклс в юнити? В туторах на ютубе как обычно делают коней в вакууме.
Прицнип простой. У тебя есть точка входа (самый простой вариант - монобехейвиор, висящий на геймобжекте, но можно и иначе это сделать). Из точки входа ты инициализируешь все что тебе нужно, и создаешь все необходимые объекты с помощью пулов и фабрик.
Синглтоны и глобальный доступ - для пидоров.
Алсо.
В итоге даже мелкий МВП у тебя будет либо пиздецом макарон из райтонли кода и зависимостей.
Либо нагромождением самописных архитектурных костылей.
В чем проблема блядь была сделать ебучие
>У тебя есть точка входа (самый простой вариант - монобехейвиор, висящий на геймобжекте, но можно и иначе это сделать)
Из коробки, что бы мне не нужно было выснять как это делать по форумам или другим
>можно и иначе это сделать
подводные камни?
https://www.youtube.com/watch?v=bYya22v7RYI
Как ехидный скрипт может проснуться на сцене, если его нет в момент запуска? Суть точки входа в том, что она является единственным скриптом, находящимся на сцене в момент загрузки.
>>653571
>И чем это отличается от синглтона
Ты вообще знаешь что такое синглтон?
>>653586
>макарон из райтонли кода
Што?
>и зависимостей
Кури dependency injection.
>Из коробки, что бы мне не нужно было выснять как это делать по форумам или другим
Ты в Юнити программировать пришел, или лепить говно из блюпринтов? Если ты пришел программировать, то на столько очевидные вещи ты какбы должен был бы и сам знать.
Есть кто пиратит? Подскажете ресурсы, откуда качать лучше?
Искал пол часа проебавшийся TEXT, дошло до того, что я нахуй снес все на канвасе, заспавнил 2ой текстовый элемент и поставил все 1 в 1 как на первом.
И знаете? ОН НИХУЯ НЕ ПОЯВИЛСЯ 2 ЧАСА ЕБЛИ С ЕБУЧИМИ АДАПТИВНЫМИ ПАНЕЛЯМИ ЧТО БЫ УЗНАТЬ ЧТО ХУЙНЯ ПРОСТО ЗАГЛЮЧИЛА
Все еще лучше чем CSS. Спасибо Абу.
А я люблю обмазываться UI и писать новые абстракции. На два слоя целый день уходит. Очевидно, что каждый объект на экране это UiItem, хуярим поверх юипанель. Ну, она же может иметь хедер, так что пилим юитекст. А если панель можно закрыть? Точно, пишем поверх юиитема новый класс - юибаттон. Так, нужно окно инвентаря? Ну, значит, пишем поверх юипанели таббедпанель для которой нужен класс баттонпанели!, а уже поверх неё инвенторипанель. В которую добавляются инвенторипейджесы. Так, таскать по страницам инвентаря мы будем кнопки? Оно же кликабельное, как кнопки. Но и драгабельное, как юипанели. Ладно, незачем дописывать родительские классы, напишу новый InvItem. Ах да, это всё ещё View, теперь-то надо начать писать контроллер.
Хорошо, что я проигнорировал UiElements и запилил всё на uGui.
Ремультиплексируй, сука! Ремультиплексируй, мразь! Неужели это так сложно, гандонище?
> Нахера, уёбок?
Тащемта по банальной причине.
У тебя с пекарней что-то не то, кодеки накати.
>>655921
Я бы на твоём месте поубавил костей в языке и просто двигал их скриптом. И удалил нахуй блендер.
>>656179
А ты вскрой стандартный шейдор, он на самом деле не монолит, а тонна инклюдов, которые не инклюдятся, когда не нужны. И в нём не включены прямо таки все варианты, только некоторые.
https://unity3d.com/ru/get-unity/download/archive
Где и всегда.
> У тебя с пекарней что-то не то
Линуксянка, осложнённая опенсорцом головного мозга.
> кодеки накати
Не помогает. Надо отказаться от браузера и перейти на небраузер от корпорации добра. Чего я делать конечно же не буду. Так что, демультиплексируй, няш. Секунда делов-то! Как я показал в предыдущем посте, запостив демультиплексированный твой файл, это даже размер слегка уменьшает.
>965Кб
>973Кб
Уменьшает, ага, на целых 8 килобайт твой файл больше моего.
>Не помогает.
Тогда хуйня твой опенсорц, матроска на самом деле не формат, а контейнер, там внутри mp4. Если не забуду, в следующий раз раскукожу, как удобнее, я obs только ради тех семи секунд и накатил.
>>656250
Деформ это блендшейпы, ты ими нормально язык двигать не сможешь. Смотри в сторону Transform.LookAt ну и двигай тазом скриптом кости.
>>656385
В личных тредах опа принято хуесосить, так что я бы не советовал.
> Вот в чем разница для далнейшего использования
Циклические анимации удобнее ин-плейс, болванчик дрыгается на месте, а ты его координаты по карте таскаешь со скоростью, совпадающей с частотой дрыгания, чтобы ноги не чесали по земле. Рут-мовшен удобнее для одиночных анимаций, тебе ничего двигать не надо. Анимация сама переместит болванчика из точки А (земля) в точку Б (площадка не лестнице, например). Потом правда возникнет проблема, что нужно ловко подменить координаты при переключении на следующую анимацию.
В общем, вопрос вкуса, стиля, привычки и всего такого. Анонимус предпочитает инплейс. Чтобы все перемещения контролировать самостоятельно.
https://docs.unity3d.com/Manual/WindowsPlayerIL2CPPBuildProducedFiles.html
А хуль справку не почитать? PDBшки и c++ код, ничего особенного на самом деле.
>>657083
Установи 3д редактор какой-нибудь, который в fbx экспортировать умеет. Блендер не умеет. Да он, собственно, нихуя не умеет.
Ну там блендер же не только в два формата экспортирует? Или только в два? Экспортируй в майку, оттуда в fbx и в юнити. Скорее всего у тебя или плагин блендера кривой, или блендер кривой. Или не та версия питона, нужна такая же, но с перламутровыми пуговицами. Но это скорее вопрос для /td, чем для /gd, тут так-то не особо много пользователей этой хуйни. Рабство стола. Ну или кидай файлом .blend, какие проблемы? Юнити в таком случае, если не ошибаюсь, сама переконвертирует в человеческий формат. Или попробуй не делать передом отрицательную ось, я хуй знает. Олсо ты ебанутый, кстати, ты анимацией там колёса крутишь? Пиздос просто.
Вроде как Юнька не конвертирует, в этом и проблема. Блендфайл по итогу весит в три раза больше. FBX 300 кб, BLEND 900 кб. Проблему решил методом тыка. Надо было убрать эти две галочки
>На выбор два языка - C# и UnityScript
Когда перекатывать будете уберите нахуй юнитискирпт он с 2018 не поддерживается
А это уже сложнее, в юнете есть TrailRenderer и LineRenderer, Trail идет как хвост, а Line - можешь сам указывать точки, но оба компонента 2D
Если хочешь 3D реалистичную змею, то тут я бы сделал 2 части - голову и хвост, а тело генерировал сам, но повторюсь, если ты новичек - это будет оч сложно т.к. нужно разбираться в типе данных 3д форматов, самому строить векторы, полигоны и UV карту.
Ты шаришь в этом? Если да, то по чему изучал?
Сейчас по шейдерам вообще очень мало инфы, особенно для юнити, копать только книги, насколько вообще оцениваешь сложность, с нуля месяц или больше? У меня много идей, и если кто-то с этой может помочь, то можем доход поделить, змейки сейчас актуальны, особенно 3D и казуальные.
Лол, я бы мог это сделать, но желания нет, свое гавно пытаюсь доделать.
По чему изучал - одно время читал все подряд на том же хабре и ютубе.
Про вертексы и UV узнал когда смотрел многочасовые уроки по моделированию, моделировать так и не научился.
Еще мне кажется у тебя неправильное понятие шейдеров, да они отвечают за отрисовку, но они уже принимают точки, полигоны, позиции и тд, они могут "чуть-чуть" поменять позицию точек или отсвет какой-нибудь, а создать тело змейки нужно заранее и в (нашем случае в) c# коде.
Умения программировать у всех растут по разному, я с нуля в первые 6 месяцев сделал своих космических рейнджеров и не стал их доделывать т.к. графика была вырвиглазная.
А вел я это всё к тому, что я посоветовал читать бы форумы с твоей целью. Книги и ютубы бесполезны, нормальных учителей мало и они могут дать тебе знания, которые сейчас не нужны.
А еще точнее - https://www.raywenderlich.com/3169311-runtime-mesh-manipulation-with-unity тут разбирают тему "изменения меша" прям в движке, так же можно нагуглить и кости и всё это соединить
Тащемта ничего сложного тут нет, делаешь модель для головы плюс модель сегмента тела с хвостом. В рантайме инстансируешь голову плюс сегмент, потом наращиваешь сегмент за сегментом. У каждого сегмента своя кость или даже две, так что анимировать скриптом будет легче лёгкого. Из минусов, овердрав большой, но можно добавить урезанный сегмент без хвоста.
Мне надо вот такую змейку получить
Так ты же сам их и позиционируешь скриптом, как расположишь - так и будут соединяться. Делаешь у переднего торца вейт вершин 100% к крайней кости спереди, у заднего вейт 100% крайней кости сзади. Потом помещаешь первую кость второго сегмента тупо в последнюю кость первого сегмента и двигаешь ими, как одним целым, обе кости за раз. Не лучший вариант с точки зрения аккуратности, но сработает. Возможна z-битва, но это не точно.
Если ты хочешь делать по-людски, то пили процедурную генерацию змейки. Для графона, как на пике, даже текстуры не нужны, так что головняк с uv отваливается, уже проще. Около хвоста добавляешь луп, хвост сдвигаешь чуть назад. И да ты можешь и ты должен на ходу строить кости - это просто, создаёшь пустышку и закидываешь её в SkinnedMeshRenderer.bones, тут главное индексы не проебать.
1. public class YourHolder : MonoBehaviour{
public static readonly YourHolder Instance = null;
// Тут твои scriptable objects
protected void Awake(){
Instance = this;
}
//on destroy -> Instance = null;
}
И потом YourHolder.Instance.YourScriptableObject
2. Пихаешь их в папку Resources и потом в коде Resources.Load<YourType>("YourScriptableItem")
3. Делай айтемы через префабы и просто сохраняй ссылку на ScriptableObject, ссылки в памяти занимают мало места, ничего страшного не случится.
Я использую 1 и 3 способы
Cмахивает на то, что ты ебанут. Любой меш будет растягиваться, если за кости потянуть. Так скиннинг и работает, если что. Другое дело, что он будет деформироваться. И чтобы этого избежать, нужно добавлять точек и треугольников.
>как динамически кости добавлять
>создаёшь пустышку и закидываешь её в SkinnedMeshRenderer.bones
Я писал уже вообще-то.
Я не ебанут, а объяснил ты кратко, говорю же, не шарю.
Если все так просто, спасибо за помощь, буду гуглить этот скиннедмеш. Я сам просто не капал и хотел найти уже что-то более менее похожее на то что я хочу, но с костями на ютубе только с персонажами работают.
Если отталкиваться от моего скрина, где уже есть созданные части змейки, могу ли я их использовать как кости? Братан, можешь не отвечать если вопросы тупыми кажутся, я же сказал, настроение такое, нехуй делать, сейчас тупо время прожигаю и собираю ответы, завтра может начну уже что-то искать.
> Активация Шиндовс
Обрети свободу, пацан.
https://2ch.pm/gd/res/659486.html
https://2ch.pm/gd/res/659486.html
оп хуй не оставил ссылку здесь
Сделал такую хуйню: Для объектов, из которых нужно сохранить инфу, сделал абстрактного предка. А на том самом классе с сериалайзед массивом на геймобжекте сделал поиск всех этих предков на сцене. Правда здесь проблема в том, что выключенные объекты не находятся.