Это копия, сохраненная 13 апреля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Ти дурний?
Нужен один спрайт с доской, ОДИН, ёпта.
И спрайты шахмат по ним ходят, по координатам, КАК ВО ВРЕМЕНА ДИДОВ.
Перекатился на LWRP с год назад, охуел от сырости. Поверил, что потихоньку допилят. Прошел год и... Я по-прежнему охуеваю!
Создаю десктоп игру с упрощённым графонием уровня симсов. Настал момент создания локаций - пора выбрать пайплайн и не оглядываться назад.
Продолжать жрать кактус с URP или перекатиться в легаси/HD? Тяжёлую фотографичную картинку делать намерений нет, но со светом, тенями, материалами, постпроцессингом буду играться много по ходу дела.
Изначально выбрал lwrp ради шейдер графа, но теперь имеется аналогичный инструмент от Amplify, поддерживающий все режимы.
А в чем преимущество Amplify перед обычным встроенным шейдер графом? Стоит перекатываться на него, если и так вроде пользуюсь шейдер графом и все ок?
Я его только начал ковырять. А так:
- удобней, больше функционала (?)
- поддерживает легаси и hd
- может сразу показывать сгенерированный код шейдера - очень удобно для обучения.
- много темплейтов.
Короче, то же, что встроенный, только лучше. Не уверен, что стоит перекатываться, если и так все устраивает.
Менеджер сцен как минимум придётся свой велосипедный писать. А по существу там придётся горы велосипедов написать. Даже если возьмешь какой-нибудь годный фреймворк типа СФМЛ.
Тогда непонятно, почему ты возмущаешься необходимости их создавать по отдельности, если они разные объекты.
>>27066
И, откровенно говоря, видя ебанутую политику юнити касательно существующего функционала, я не уверен, что встроенный шейдер граф будут развивать, или даже поддерживать. Вполне может стать, что через год-полтора его поддержка прекратится, а дальше его переведут в deprecated.
К Amplify доверия побольше, так что мне не жалко было расстаться с 2к.
VSCode такое говнище! ИМХО, конечно. Не рекомендую. Лучше лишний раз сходить покурить, пока запускается студия, чем ебаться с вскодом.
Там вроде проект (или солюшен, не помню) без установленной студии не создается. Или пока не откроешь студией через редактор. Чот такое.
А что не так с вскодом?
Интелисенс есть, интеграция с гитом есть, дебагер есть. Я больше ничем и не пользуюсь.
Не то же самое, а гораздо удобнее.
Ух ты! Любопытная штучка. Спасибо. Пойду пощупаю.
ЕО3Оесть один три дэ обьект с моделью, текстурой. Таких обьектов создается несколько штук на сцене одновременно и они активны. Каждый обьект рано или поздно будет уничтожен. В этот момент надо ему проиграть анимацию смены цвета альфа из 1 в 0.
Я попробовал у MeshRenderer.materials у них color менять. Возрасло количество draw callov в 5-10 раз. Использовал стандартный шейдер с mode=Fade и mode=Transparent. Оно еще и проглючивает.
Может кто-то сталкивался?
> Возрасло количество draw callov в 5-10 раз.
У тебя игра-то есть, или ты преждевременной оптимизацией занялся?
Можно на время анимации создать новый материал - копию старого, и менять у него альфу постепенно в колоре, тип поменять на транспарент. Ну либо пиши свой шейдер
https://blogs.unity3d.com/2015/12/23/1k-update-calls/
отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
Много апдейтов это хуево, да, уже много лет все это знают.
Поэтому всегда говорят удалять пустые апдейты например.
>отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
В теории да, но тут больше вопрос о том сколько у тебя объектов активных на сцене в одно и то же время. Если у тебя 100-200 объектов, то это даст маргинальный буст производительности, а если у тебя 10000 объектов то у тебя будет нагрузка в любом случае, и ты что-то делаешь неправильно (либо нужно придумывать продвинутые способы оптимизации)
>10000 объектов
Что вы там мутите, псы призраки? Вы же инди индюки, делайте маленькие супер игры и зарабатывайте миллионы! Сколько апдейтов в celeste, говори блядь! Это знать надо!
Я делаю клон ксп с прицелом на 10-20к частей на крафт. На ецс, правда, поэтому мне апдейт коллы строго похуй.
>отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
Это звучит как дичайший костыль. Здесь важней не прибавка 0,12% к фпс, а то, как ты потом поддерживать все это будешь.
>отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
https://www.youtube.com/watch?v=mQ2KTRn4BMI
Смотри все
спасибо за интересный видос, аутизм начинается на 28:34
про мастер сцену с саб сценами юнити сам учит в адвенчур гейм туториале, другого подхода в юнити просто не должно быть если игра сложнее геймджем перделки
то что я понял:
>сделоли Update() с форлупом на 1000 колов
>выиграли 1-2 мс (говорит на 49:27)
на этом вопрос можно закрывать
не юзать апдейт это скорее вопрос принципа, когда следуешь mvc или типа просто больной аутист как я
>>27150 >>27223 вы правы короч
Не на юнити можно апдейты юзать, тупой козел-ебанат?
Да, а то твой платформир залагаит
Какой архитектуры, там примитивный (свой) фреймворк накачен, такой за пару дней делается
Рендер пайп это заебись когда свой пишешь, под свои нужды. HDRP норм благодоря фиксированому функционалу и чёткому пониамнию команды что он делают. LWRP/URP это какое-то недоразумение. Они пытаются уседеть на трёз стульях в итоге выходит нерасширяемое неподдерживаемое говно. По мне им надо было разделиться на чётко HD и Mobile, и лоу енд игры впролне могли бы делать на мобайл пайпе.
Желаю тебе удачи, бронька, всего тебе хорошего, надеюсь все у тебя получится. Здоровья близким!
На примере двери. Код, скажем, из door.cs:
if (Input.GetKeyDown(KeyCode.E)) {//открыть дверь}
Но, отлавливать нажатия можно, только если чел рядом с этим объектом и смотрит прямо на него, то есть, код должен быть примерно таким:
if (CanInteract() && Input.GetKeyDown(KeyCode.E)) {//открыть дверь}
CanInteract() возвращает true, если чел рядом с этим объектом и смотрит прямо на него.
Чтобы функцию CanInteract() не дублировать в key.cs, box.cs и прочих, я решил сделать компонент. Его нужно повесить на каждый такой gameobject и указать тип. Когда происходит фокусировка на объекте, или он теряется, то сообщаем об этом скрипту объекта.
Нормальное решение?
В этом же компоненте можно реализовать показ и сокрытие UI иконки или подсказки, чтобы чел знал, что можно нажать.
А вообще, чтоб не возиться с компонента, лучше сделаю внешнюю статичную функцию, которая принимае transform объекта, и возвращает true или false, в зависимости от того, смотрит ли камера не него
Потому что гц занимает процессорное время. Представь. Заехал к тебе во двор мусоровоз. Загородил проезд. Выворачивает контейнеры с мусором себе в кузов. Проехать нельзя. Петрович на шохе ждёт. Михалыч на фокусе ждёт. А хули ещё делать?
Хуйня. Почитал немного. Лаг происходит на любом железе, даже на i9 9900k. Проблема в том как работает гк в юнити. Он по-сути останавливает выполнение программы во время очистки. Плюс напрямую с памятью работать нельзя поэтому приходится полагаться на гк.
Ну, не знаю. Юзай шарповый майкрософтовский гц. Или вообще. Прибирай за собой мусор сам. Будь олдфагом, блеать.
интерфейсы? https://www.reddit.com/r/Unity3D/comments/3elzv2/nice_examples_of_using_interfaces_with_unity_i/
и да, сейчас можно юзать TryGetComponent
https://docs.unity3d.com/ScriptReference/GameObject.TryGetComponent.html
Можно работать с памятью напрямую, школьник ты сука ебаный. Специально чтоб ебаные дети типа тебя не на косячили, в сиське есть режим ансейф кода, по умолчанию отключенный (защита от дураков как ты). Но ты настолько тупой, что тебе для начала надо учиться писать код без мемори ликинга.
Докладываю, начал разбивать исходный мир на группы (инпут, контрол и симулейшн для начала), но слегка обосрался и пришлось откатиться.
Сегодня начну с малого, сделаю инпут систем груп и барьер после него, чтобы создавать управляющие энтити.
И если успею сделаю аттрибут для раскидывания систем по мирам и второй мир с одной тестовой системой в симулейшн систем груп.
А вообще я пытаюсь через рефлексию все делать, как Юнити в документации пишут, но получается какая-то хуета, если честно. Проще вручную систему за системой распихивать по группам. Но тогда не будет корректно работать UpdateInGroupAttribute, что печально, он мне нравится.
Судя по токсичности этого "олдфага", успехов в жизни он не достиг, и решил хотя бы на дваче самоутвердиться.
Не будьте такими, дети.
Для того, чтобы детектить неудовлетворенных жизнью лузеров, не нужно быть психоаналитиком.
Разница в округлении, чтобы вычисленная шейдэром текстура выглядела бы как не фильтрованная. Но видимо суперсовременные видеокарты не предназначены для ретропикселей.
Ты floor пропустил. Получается не тоже самое отнюдь.
При этом, чем больше Ц, тем крупнее ячейка до величины которой округляется число на выходе. Я очень горжусь тем, что эту формулу я вывел сам.
Причём здесь гордость за вывод очевидных формул? Я вообще спрашивал про то, сталкивался ли кто нибудь с артефактами округления в пиксельных шейдерах.
Ну прост. Решил поделиться своими достижениями с братушками. А вы тут злые какие-то.
А, сори, неправильно проинтерпритировал твой предыдущий пост.
Ага, я уже перекатился на HD, ощущения исключительно положительные. Надо было это сделать год назад, лол.
Наступал на такие же грабли несколько раз. Просто заюзай функцию OnMouseOver, с проверкой дистанции до игрока. И логику взаимодействия вынеси в отдельный скрипт, а не засоряй monobehaviour.
И пожалуйста, не пиши четыре вложенных if'а!
Глаза режет.
Точно, я сонный даже не увидел ее. Если через lwrp делаешь, посмотри что рисуется через frame debugger, возможно это из за постобработки или вот эта залупа даже на 1 сглаживает пиксили.
Не забыл. Несоздание мусора является аналогом прибирания за собой. Объект объявил. Объект создал. С объектом поработал. Объект уничтожил. Так делали деды и отцы.
Разобрался! "Anisotropic Texture стояло в положении "Forced On". В общем - да, для пиксельных сцен надо всё поотключать.
Помоги, пожалуйста с таким вопросом.
Есть части двигателя. В майке они выглядят нормально, трансформы заморожены, все путем. Но после экспорта в юнити, данные нифига не сохраняются, и если сбросить их на ноль, то меш будет помещен в центр мира. Я уже пробовал делать parent, группы, но все фигня. В чем тут дело ну, кроме того, что я туповат? Как сделать, чтоб все данные о расположении, в Юнити были так же на нуле, как и в Майе?
Сделай пивот (надеюсь ты знаешь что это) в майке в 0,0,0 или там же где у парента, если тебе эти нули нужны любой ценой.
А чего подробнее, когда в интернете мануалов навалом?
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnMouseOver.html
Выстреливает каждый фрейм по аналогии с апдейтом, когда курсор находится поверх предмета. Также есть mouseEnter и mouseLeave. У предмета должен быть коллайдер.
Избавляет от необходимости писать любые виды обнаружения предметов (я тоже раньше через рейкаст делал), проверять нужно лишь дистанцию до игрока, чтобы не ворочал мешками из другого конца комнаты.
> Нормальное решение?
Такое же нормальное, как делать тетрис, где каждая новая фигурка это класс, генерируемый фабрикой фигурок. Перемещение фигурок реализовано через сериализацию. А взаимодействие фигурок с полем через подписку на сообщения.
> когда курсор находится поверх предмета
ты наверное имеешь ввиду 2d игру? я пилю 3d, курсора нет
Если у тебя курсор скрыт то считается центр экрана
Это ещё что, я как-то работал с игровым движком, где отправка сообщений была реализована через рефлексию, а вызов главной камеры проводил перебор объектов сцены.
Вот это отрицания, маня.
Всегда так делаю.
Так себе схема. Я бы сделал один класс на любые объекты, с которыми игрок моюет взаимодействовать, через этот класс-болванку реализуешь интерфейсы. А уже в интерфейсе под каждый случай можно прописывпть че происходит или вызывать соответствующий метод.
Получится много копирования кода для каждого класса(активация, деактивация, сайд-эффекты), либо выносить все в родителя, а тогда будет громоздкий родитель и широкое некрасивое дерево наследования.
Лучше сделать систему модулей, где каждый модуль опционально подключаем и выполняет кусок своей логики. Тогда очень круто играет open-closed принцип: для расширения логики тебе не нужно ничего переписывать, ты просто добавляешь новый модуль.
Эти твои модули это постоянно чекать на наличие и отсутствие модулей, я с компонентами заебался возиться, а ты тут ещё предлагаешь свои собственные компоненты сделать.
Я сделал один компонент, а внутри него enum с атрибутом [Flags]. Для каждого префаба нужно прикрепить один компонент, а флаги выставляешь любой комбинацией для создания гибкой логики.
Это мне нравится больше, чем создание тысяч InteractableDoor, InteractableChest, InteractableItem, InteractablePotion, ...
Мой случай слишком специфический чтобы ответить тебе что-нибудь внятное. У меня только базовые классы (юнит, обстакл, дудад), а всё взаимодействие вынесено в заменяемые скрипты на луа. То есть InteractableDoor и InteractableChest, но я их читаю из текстовых файлов снаружи юньки.
Тебе нужен паттерн observer. Просто делаешь свой ивент менеджер или берешь готовый и подписываешься в нем на получение урона всеми, кто нужен. Во время удара триггеришь и пересылаешь необходимую дату.
IIRC отправка сообщений не рефлексия, а перебор объектов на хардкоженном C++. Обращение к трансформу, иерархия с трансформами и графика таким же образом идёт.
Нет. Я юнити люблю, но каждый раз охуеваю, как он может.
>Во время удара триггеришь и пересылаешь необходимую дату.
Это очень много даты. И это до черта проверок булей.
Я сам под капотом не копался, так что могу пиздеть. Но абсолютно везде механизм объясняется именно рефлексией.
А обращение к компонентам идеи так, как ты сказал. Что тоже не супер быстро.
Почему же. В момент удара создаёшь контейнер данных с получателем, мб отправителем, размером урона и мб типом урона или как у тебя система сформирована.
А подписчики уже сами решают, что с этими данными делать.
>А подписчики уже сами решают, что с этими данными делать.
Это говно очень быстро вырастет до внушительного по размерам пакета, который будет пересылаться всем-всем-всем как только появится нужда в follow-up ивентах вроде парирования, доджей, чеков на proximity чтобы реакцию какую-то сделать и т.п. Видел, как икскомы виснут, иногда напрочь, когда в конце стрельбы очень дохуя эффектов разом срабатывают? По сути, я спрашиваю, как с такой ерундой справился Хартстоун.
При первой отправке сообщения все обработчики кешируются. Получается так-же как быстро как подписка на события, только без ручной подписки/отписки.
Хз, тогда можно посылать ивентом только отправителя и получателя. Получатель ловит ивент и запоминает отправителя, после чего они начинают срать данными между собой. А в другие модули данные отправлять небольшими сообщениями-ивентами, без мусора.
Хотя.. как ты будешь пересылать получателя ивентом, если у тебя изначальное требование не быть связанным прямыми ссылками? Хуй знает короче.
Лол, пока спрашивал нашёл у себя в коде типа-решение - разбивать ивент на куски, которые выстроены в последовательность, и каждый кусок выполняет свою часть ивента, и если эта часть вызывает какой-то другой ивент, то он кусками встраивается в уже имеющуюся последовательность.
Это... менеджер, который курирует последовательность ивентов, собирая по пакету на каждый из них заново по требованию ивентов? Ну, в другом месте кода это работает, надо repurpose'ить
Только в режиме гибрида, не полностью
Вечером, если время будет.
Ты ещё здесь?
И вообще здесь есть именно те кто удалённо зарабатывает, чтобы не надо было ходить в офис.
У меня был свой источник дохода - в лучшие времена до $5000 в месяц, сейчас упало до $1500-2000, сам я бывший веб программист, но не хочу ходить в офис, интересует данная тема на пообщаться
>У меня был свой источник дохода - в лучшие времена до $5000 в месяц, сейчас упало до $1500-2000
Рассказывай, съебешь на рескины, а я буду твоим методом зарабатывать, для меня 1500к это заебись
Лови: https://pastebin.com/hahTUw1d
В эту систему можно дописывать любого вида модуль:
1. Создаёшь новый наследник.
2. Добавляешь новый флаг в enum.
3. Пишешь две строчки на создание нового модуля.
Третий шаг можно автоматизировать, но это выглядит грязно. Быстрее вручную дописать, на мой вкус.
А ещё можно создавать не только опциональные, но и обязательные, и взаимоисключающие модули!
Конечно, я не стал писать тысячи null чеков и других проверок, а надо бы.
Ты издеваешься?
>this.rb = rb;
>rb.isKinematic = false;
Весь функционал твоего "модуля" - это сменить значение одного буля. Это гораздо проще и быстрее и чище сделать без таких извращений.
>>28292
Ладно, похуй на один буль. У тебя идея в том, чтобы "расширять" 3 метода в зависимости от тэгов. Как насчёт сделать круче - для каждого возможного модуля сделать менеджер, и вместо того чтобы подключать модули к объектам заносить объекты в списки этих менеджеров, а затем звать апдейт, дестрой и что там ещё из менеджера проходясь по списку?
>Ты издеваешься?
Да. А теперь посмотри на другие модули. Они тоже написаны в две строчки. Можно написать ещё штуки две- три таких же с базовыми функциями.
И нахуя их плодить, да?
Но вот если все их запихнуть в один мегакласс, получится дикая мешанина из событий при каждом старте/стопе взаимодействий. Это не очень хорошо.
- Я знаю, где расположен кинематический модуль и мне не нужно искать нужную строчку в стене общего кода.
- Легко расширять логику. У меня, например, там торчит таймер, снимающий кинематику не сразу, а через какое-то время. Я могу навесить в модуль ещё две-три простых функции, прежде чем он потребует декомпозиции.
- Почему скрипт взаимодействия должен что-то делать с rigidbody? Это нарушение принципа SRP и засорение логики. Его задача - создавать и поддерживать модули, а все взаимодействия должны располагаться в них.
Да, у меня ОКР, да, я угораю по аккуратному и структурированному коду. Да, это мешает продуктивности, но с моими библиотеками мне потом необычайно легко работать
Не совсем тебя понял. Сделать модули scriptableobject'ами, а в объекте создать их список, наполнять через инспектор и пробегаться по списку?
Пожалуй. Но я предпочитаю "чистые" классы, а делать менеджер scriptableobject'ом нет никаких причин. Енум это простейший способ работать с чистыми классами через инспектор.
У тебя сейчас дохуища экземпляров разных модулей. Я предлагаю взять объекты, к которым цепляются модули, и распихать по менеджерам, выполняющим функции этих модулей. Это как если вместо того чтобы иметь 100 объектов с апдейтом в каждом из них сунуть этот апдейт в менеджер и в менеджере же проходиться по списку объектов.
Объект становится набором переменных почти без методов, а все методы кочуют в менеджеры, которые затем жонглируют объектами.
мой метод связан с ютубом, я делал мультфильмы на ютубе.
Сейчас закручивают гайки и лучше не начинать.
Я не так давно пробовал написал 2д шутер на Unity и в принципе черновой вариант был готов с нуля за 3 трудодня (полтора дня писал код и полтора дня дизайнер рисовал).
Т.е. в сумме игра была сделана за 1.5 дня.
Мы не занимались играми до этого, но интересно в плане нужна какая-то раскрутка же явно для игры - как это делать и т д.
Ибо тут парень писал что когда игры умирают он делает новые, но явно там не бесплатные методы поднятия игры. В принципе мы не против и в команду вступить и делать что-то вместе, просто пока пробиваю почву (сейчас у меня есть заказы в вебе, но они закончатся).
Почти все годные игры взлетают, даже средненькие свое получают. А вы так вообще по пятьдесят игор крутых в год сможете выпускать, в деньгах будете купаться!
как обойти?
форсед мем
Попробую.
В прошлом поколении были такие приставки - PS3 и Xbox 360.
В них поставили процессор без Out of Order и предзагрузки кеша.
На них в процессе разработки по причине такой вот ущербности железа в полной красе проявились байтопроблемы ООП, когда любой объект с более-менее жирным мемори футпринтом приводил к постоянным кеш-промахам и производительность сосала жопу.
Была (и есть) такая контора как Naughty Dog, внутренняя студия Sony Computer Entertainment прославившая себя играми серии Uncharted (это который Drakeface), Last of Us, Crash Bandicoot.
Они изобрели байтоебский способ борьбы с ущербным консольным железом путем декомпозиции объектов и превращения массивов объектов в массивы отдельных полей этих объектов, который они позже назвали Data Oriented Design.
То есть вместо
class Mob {
private vec3 position;
private vec3 rotation;
private int health;
private AiState state;
...
private Huita huita;
}
стало
class Mobs {
private vector<vec3> positions;
private vector<vec3> rotations;
private vector<int> health;
private vector<AiState> states;
...
private vector<Huita> huitkies;
}
В таком случае, при итерации по отдельному полю, когда, скажем, нам, нужно двигать мобов, в кеш попадает не весь жирный объект, засирая его, а только куча позиций сразу нескольких мобов. И промахов не происходит.
Далее ECS - тут суть в том, что вот эти вот отдельные поля могут использоваться в совершенно различных сущностях, позиция может быть не только у моба, но и у игрока, источника света, итемов на уровне.
Так что мы из сущности вот эти вот поля нахер убираем и передаем их отдельной системе - двигательной, поворачивательной, осветительной, ИТД. А в сущностях мы лишь оставляем упоминание что вот моб умеет двигаться поворачиваться атаковать с помощью этих вот систем. Таким образом поля стали отдельными компонентами, их логику обслуживают системы, а сущность - это просто такая хуитка с айдишником и списком того в каких системх она учавствует.
Ну и третья составляющая - сделаный с блекджеком и шлюхами низкоуровневый диалект сисярпа, вместе с кастомным компилятором этого диалекта в нативный код.
Попробую.
В прошлом поколении были такие приставки - PS3 и Xbox 360.
В них поставили процессор без Out of Order и предзагрузки кеша.
На них в процессе разработки по причине такой вот ущербности железа в полной красе проявились байтопроблемы ООП, когда любой объект с более-менее жирным мемори футпринтом приводил к постоянным кеш-промахам и производительность сосала жопу.
Была (и есть) такая контора как Naughty Dog, внутренняя студия Sony Computer Entertainment прославившая себя играми серии Uncharted (это который Drakeface), Last of Us, Crash Bandicoot.
Они изобрели байтоебский способ борьбы с ущербным консольным железом путем декомпозиции объектов и превращения массивов объектов в массивы отдельных полей этих объектов, который они позже назвали Data Oriented Design.
То есть вместо
class Mob {
private vec3 position;
private vec3 rotation;
private int health;
private AiState state;
...
private Huita huita;
}
стало
class Mobs {
private vector<vec3> positions;
private vector<vec3> rotations;
private vector<int> health;
private vector<AiState> states;
...
private vector<Huita> huitkies;
}
В таком случае, при итерации по отдельному полю, когда, скажем, нам, нужно двигать мобов, в кеш попадает не весь жирный объект, засирая его, а только куча позиций сразу нескольких мобов. И промахов не происходит.
Далее ECS - тут суть в том, что вот эти вот отдельные поля могут использоваться в совершенно различных сущностях, позиция может быть не только у моба, но и у игрока, источника света, итемов на уровне.
Так что мы из сущности вот эти вот поля нахер убираем и передаем их отдельной системе - двигательной, поворачивательной, осветительной, ИТД. А в сущностях мы лишь оставляем упоминание что вот моб умеет двигаться поворачиваться атаковать с помощью этих вот систем. Таким образом поля стали отдельными компонентами, их логику обслуживают системы, а сущность - это просто такая хуитка с айдишником и списком того в каких системх она учавствует.
Ну и третья составляющая - сделаный с блекджеком и шлюхами низкоуровневый диалект сисярпа, вместе с кастомным компилятором этого диалекта в нативный код.
эм, может я недопонял но ты сейчас описал ECS.
А я спрашивал что это за DOTS которую юнитеки последний год презентуют.. .или таки это оно? но тогда что в нем нового и при чем тут сам движок если так может и сам разраб делать?
Ах да, вы спросите, причем тут Unity?
По причине воя школоты о низкой производительности Unity, юнитеки пригласили одного из этих соневских байтолюбов себе в контору. Знакомьтесь, Mike Acton, он же Миша-Оптимизатор, автор DoD, любитель пердолить байты.
Вот он сейчас и занимается DOTS
https://www.youtube.com/watch?v=rX0ItVEVjHc
На второй фотке - его коллега по команде, Jason Gregory, всё оттуда же из сони, нотидог, тоже пилил дрейкфейс, автор книги Game Engine Architecture/
Оба они - главная причина влажных дрочек сониблядей из /cg/ по ночам.
DOTS - это ванильные из каропки ECS + DOD + кастомный компилятор сисярпа с гейшами и куртизанками
Сейчас погуглил и понял что спиздел, Мишаня из Insomniac и он не изобретал DOD, он только дал название и форсил.
1. Какого-то хуя билборд не генерируется снова после смены цвета через метод Terrain.terrainData.SetTreeInstance, а только через установку всего массива деревьев в Terrain.treeInstances ? Баг?
2. Раз SetTreeInstance не вариант при смене цвета, то мне каждый раз весь огромный массив из 10000 деревьев ставить? Насколько это затратно или может одна установка массива лучше чем сотня вызовов SetTreeInstance? В документации что _конкретно_ делает и регенерирует каждый метод нет.
3. Какой лучше использовать подход, чтобы расширить свойства деревьев? Допустим я хочу хранить где-то жизнь и возраст каждого дерева. Пока в голове висит вариант вести параллельный массив к массиву всех деревьев и в нем уже структуры с нужными свойствами. Звучит достаточно костыльно и нихуя не ООП, но как быть еще? Как привязать к деревую нужную структуру данных?
>а самом деле, камера. Main просто использует финдгамеобжектсвистаг ()
>с помощью тега "маинкамера"
1С ПОГРОМИНГ ИН АСОЦИЭЙШОН ВИЗ РАПИРА ЭНД КОМПАНИЯ ПРЕЗЕНТС
Подскажите начинку для .gitignore, пожалуйста.
Стандартный, который предлагает github выполняет свои задачи?
Все по делу расписано
это автоперивод, маьнка
Внезапно, но что бы шейдеры и освещение канали , им нужны охуенно сделанные карты - альбедо, нормаль, глосинес, металлик, вот это вот все, натянутые на норм модельку.
А что бы они были охуенно сделаны, то нужно сидеть днями и корпеть, вылизывая, вылизывая и вылизывая.
Гуглишь гитигнор для своей среды разработки и гитигнор для юнити. Оба содержимых заливаешь к себе. Профит.
Пробежался по статье. Большая часть перечисленного - мастхев, который должен знать любой уважающий себя юнитидел большую часть перечисленного я узнал только на третий год разработки.
90% актуально и не для VR.
Не согласен только с заявлением про интерфейсы. Вот так и рождаются говнокодеры, оправдывающие свой говнокод мифической прибавкой в 0,002% к фпс.
Да. А если хочешь кодить на уровне "бог", то также изучи как не надо писать комментарии и начинай писать документацию к своим публичным методам и классам.
Ты путаешь свойства и поля. Свойства:
>public Speed { get; set; } = 10;
Поля:
>private speed = 10;
Свойства имеют геттер и сеттер и пишутся с большой буквы, обычно они нужны для открытия внутренних переменных внешнему миру.
Поля не имеют геттеров и сеттеров, пишутся с маленькой буквы и всегда должны быть приватными, за публичные поля в нормальном обществе сразу пиздят ногами. Используются для внутренней логики скриптов.
Почему во всех мануалах пишут публичные поля? Потому что долбоебы Чтобы они отображались в инспекторе юнити. Так пишут для простоты понимания ньюфагами скриптов, нормальные посаны пишут:
>[SerializeField] private speed = 10;
Тогда у нас получается няшное приватное поле с маленькой буквы, с ним не нахуевертить внешними скриптами и при этом оно отображается в юнити.
На самом деле таких тонкостей много, со временем понимаешь, что в мануалах часто пишут хуйню, просто чтобы максимально примитивно показать функционал не заморачиваясь лучшими практиками. Хочешь заморочиться - читай статьи и блоги программистов.
Да, тот анон прав, потому что это я.
Все ивенты юнити типа нажатий кнопок синхронизированы с апдейтом. Тебе придется при внедрении каждого нового действия проверять, исполняется ли оно один раз, дважды или ни разу.
Нет, почему же. Статичное следует тем же правилам, что и обычное.
Константы внутри клаcса - с большой буквы.
Константы внутри метода - с маленькой.
Но это уже менее устоявшиеся правила. Кто-то их хуячит капсом с подчеркиваниями.
Но важно понимать, что каждый дрочит как хочет. Можешь вообще изучать Swift и юзать эмоджи вместо названий переменных. Там можно.
А как их ограничить если большинство скриптов наследуются от MonoBehaviour? в котором уже есть пустые Update()?
или стараться по минимуму наследоваться от MonoBehaviour?
Апдейт не будет вызываться, если ты его удалишь, даже если он наследуется от MonoBehaviour
Синглтон не нравится. FindComponent тоже херня
Пытался гуглить но нашел только всякие MVC (а я не фанат этого паттерна - мой мозг не может думать видами и контроллерами).
Сразу фпс до нуля падает
В скрипте удаляешь функцию и всё прикинь
генерирует солюшен проекта на С++. Можно запускать прямо из студии. Но вот кода там нет - пустое Main
Это юнитеки вдруг решили С++ завести? (2020 версия юнити)
Для поиска компонентов ничего лучше getcomponent не изобрели. Причем я предпочитаю писать ленивую инициализацию, а не засирать Awake. Получается не так чисто, но зато не будет лагов при инициализации сразу сотни объектов.
А для поиска абстрактного объекта сцены я угораю по servicelocator'у. Статический класс с глобальным доступом, удобнее синглтона, не имеет недостатков синглтона, легко переиспользуется. Поддерживает интерфейсы, в отличие от синглтона, что позволяет писать охуительные вещи. Имеет два недостатка (прячет зависимости и превращает ошибки компилятора в рантайм ошибки), за что адепты ентерпрайза нежно окрестили его антипаттерном. На мой взгляд для юнити это не применимо.
Название намекает - его лучше использовать для служб, существующих в единственном числе. Причем их даже не обязательно наследовать от monobehaviour. Я его обычно использую для кастомного логгера, ивент менеджера, менеджера сцен и сохранений и... Для игрока. Это наверное не очень хорошо, но охуенно удобно.
Для взаимодействий десятков объектов же ничего лучше observer'а нет. Пишешь свой ивент менеджер и подписываешь сотни объектов совершенно не парясь о перетаскивании их мышью. В юнити есть встроенный ивент менеджер, он чуть удобнее своего, но гораздо медленнее.
Всё зависит от задачи. Тут нужно в каждом случае индивидуально подходить. Либо ты делаешь лоадскрин, в котором всё инициализируется "трудолюбиво", либо юзаешь ленивую инициализацию и имеешь некоторые просадки фпс.
Этот принцип я запалил, например, в ведьмаке втором (подчёркиваю, втором). У меня была слабая машина тогда и была такая тема: Когда идёшь медленно и находишься в пределах локации (чанка), то игра работает нормально. Когда начинаешь ускорятся, то при смене локация начинаются лаги. Если во время лагов притормаживать, то игра продолжается. Если пришпорить плотву и втопить - врубается лоадскрин.
Плохо понимаю, чего ты хочешь. Рисовать пальцем на экране, чтобы потом корабль летел по нарисованной траектории?
Я бы просто каждый фрейм ловил положение пальца и говорил кораблю: лети в данную точку имея при этом такой-то velocity. Можно поиграться с rigidbody и менять направление с помощью addforce, для создания интересной инерции (в аркадном космосе, ага). Или без rigidbody брать текущий вектор направления и медленно поворачивать в сторону пальца.
Но он тогда при достаточно низкой скорости и быстром повороте будет интерполировать траекторию в линию. Если тебе нужно, чтобы он точно повторял траекторию, тогда лучше каждые n фреймов читать положение пальца, добавлять координаты в очередь, а кораблем просто облетать все точки очереди удаляя их с конца.
> о идее надо что бы один вектор как-то параллельно другому двигался, что ли
Вектор не двигается. Двигаются объекты и их движение в каждый конкретный момент можно показать векторами.
Я это к тому, что тебе надо записывать координаты пальца в массив, пока рисуешь жест. Затем этот массив использовать ка навигационный путь. Когда палец касается, записываем Х1 = 0, 0. Когда палец едет, периодически записываем Xn = Xn-1 + текущие_координаты. Когда палец отпустили - массив завершен и мы запускаем корабль, интерполируя его позицию с позициями точек в массиве.
>>28594
А я вот как понял его ^
Не будет. Пружина настраивается.
Да мне на словах сложно объяснить, поэтому я привел в пример игру, можешь ее скачать и посмотреть как там сделано.
Сейчас у меня упрввление такое, я просто ловлю точку в которую мы тыкаем, и корабль летит от своей позиции к этой точке. Но на самом деле это не очень удобно.
В той игре сделано так, можно в любой точке экрана тыкнуть, но корабль остаётся на месте пока мы не начнем двигать пальцем. Когда мы начинаем двигать пальцем, корабль со своей позиции начинает повторять траекторию наших жестов. Таким образом можно из любой точки экрана управлять кораблем. По сути считываются вектора нашего пальца и как-то пропорционально передаются в игрока
В мои времена школьники изучая погроммирование на каком-то этапе обязательно писали свой недоПейнт.
Хуйзнает вас миллениалов, какие-то вообще не можете в мышление.
Да мне 27, я просто тупой и ленивый. Сам пробую сижу, но подумал параллельно спрошу тут, вдруг быстрее подскажут. Я даже не кодер, так самоучка
Ну так посмотри, как посоны пейнт пишут в мануалах, а потом эти точички не на экран бери клей, а массивом на вход твоему треугольнику чтобы по ним летел, епта.
Какой нахуй пэинт, я спэйс шутер делаю. Я просто проиллюстрировал как выглядит управление, которое я хочу. Пунктиры условные.
Сейчас он у меня вот так летает:
https://pastebin.com/weDZAUvK
Там по игрику его подымаю, что бы палец спрайт не закрывал.
Но недавно увидел в игре falcon squad круче управление, я его описал выше. Вот не могу додуматься как сделать лучше всего.
> Какой нахуй пэинт, я спэйс шутер делаю.
Такой.
Чтобы делать игры, сначала надо научиться делать программы вообще. Потому что игры это программы. Причем не самый простой их вид.
Так что брысь курить матчасть и чтобы пока не сделаешь свои пейнт, блокнот и телнет, чтобы и не заикался мне тут о спейс-шутерах!
Мы здесь не для толка, а для постинга своего прогресса с обсуждением и лулзами. Хочешь толка учи матчасть на unity.com/learn
действительно?
Я вот читал что есть ASO или как то так - короче продвижение под маркет, что так никуда не зайдёшь.
В принципе мой опыт с ютубом показывает что так оно и есть - даже имея канал мультфильмов мне приходилось скажем так покупать рекламу чтобы хоть куда-то выстрелить.
Ты знаешь что-нибудь про маркет - неужели правда сейчас всё ещё можно делать игры и надеяться что какая-то зайдет?
Договорились, скачай игру которую я называл, посмотри там управление и запили такое же через методы rigidbody
>не тривиальной задачи
>не тривиальной
Может за тебя hello world еще написать? Иди матчасть учи.
Это делается 5 строками кода. Не позорься.
У тебя неправильный подход к разработке. Без базовых знаний ты все равно не сможешь ничего сделать. Будешь все время просить написать за тебя игру? Серьезнее нужно относится к делу. Без труда не вытащишь рыбку из пруда.
>Я имел ввиду поля static. Приватные с маленькой, публичные с большой?
https://github.com/ktaranov/naming-convention/blob/master/C# Coding Standards and Naming Conventions.md
А компонент должен вроде как то отлавливать эти события
там static в примере только публичные, и они с большой. А приватные значит с маленькой?
не туда ответил
Это имеет смысл, если у тебя десяток скриптов, опрашивающих инпут каждый апдейт.
Если же при нажатии на пробел у тебя прыгает и всегда будет прыгать один объект, нет особого смысла делать отдельный менеджер. Проще сделать одну проверку внутри этого же объекта.
>Если же при нажатии на пробел у тебя прыгает и всегда будет прыгать один объект, нет особого смысла делать отдельный менеджер
Вот, классы никуда не делись. ООП никуда не делся. Какие ещё вам нужны доказательства, что ецс - это одна из многих техник ООП?
А как сиплюсплюсы работают? Там, вроде, только додиком и можно много объектов делать. Следовательно, ЕЦС - это шаг назад
Открыв проект после товарища, обнаружил, что он изменил интерфейс под себя, и сохранил в репозитории.
В каком файле сохраняются настройки интерфейса?
До плюсов я ещё не доразвился, но тех знаний, что у меня есть, хватает, чтобы заявить, что плюсы - это мультипарадигменный язык. В нём нет жесткой привязки ни к чему. Хочешь ООП - вот те классы. Хочешь функционалки - вот те лямбды с замыканиями. Хочешь императивки - вот те модули с функциями и точкой входа.
Бешенно стуча пальцами по клавиатуре напишу за джве недели игру мечты во вселенной наоборот с толщеходами.
> за джве недели игру мечты во вселенной наоборот с толщеходами.
Тьфу ты, я думал ты нормальный кент, а ты оказывается гей-пидор
Ты же в юнити-треде. Алё!
Да я то сделал. Просто ваше отношение мудакское не переношу, чмыри.
https://pastebin.com/T2kKQXUu
Приватные переменные так помечаются. Мне решарпер навязал, я и привык. Ещё у других ребят встречал.
>Приватные переменные так помечаются
Так только питонодауны делают, потому что у них приватных переменных нет.
В C# любые префиксы, постфиксы и проч. мусор являются дурным тоном.
Только загаживаешь код.
У всех свое мнение на тот или иной счёт, думаешь ребята из JetBrains дауны? Мне то все равно, можно залезть в настройки да убрать, чтобы решарпер не ругался.
>думаешь ребята из JetBrains дауны?
Я не думаю. Я в этом уверен.
Ты просто добавляешь грязь в код. А мокрописька от jetbrains поощряет это.
Иди в жопу, тупой двачер. Интерфейсы например помечают префиксом I, локальные переменные помечают, чтобы отличать их от переданных аргументов. Кто как хочет так и дрочит, пиздовал бы ты со своим экспертным мнением куда подальше.
Ты просто попугай, который бездумно копирует.
>Интерфейсы например помечают префиксом I
Я не помечаю. Потому что не вижу в этом смысла. Так-же и со всякими префиксами. Я просто не вижу смысла писать это. Это просто ухудшает читаемость кода.
От этого нет никакой пользы, но есть реальный вред.
Да, да, только не кричи.
в чем ты уверен?
метки для приватных членов (_ или m или m_) улучшают читаемость кода - потому что вот так визуально сразу видно где приватный член, а где публичный
(ну если ты конечно не любитель радуги и твой код не раскрашен всеми цветами радуги).
>улучшают читаемость кода
улучшают читаемость, добавляя мусор?
>сразу видно где приватный член, а где публичный
1. ты и так знаешь что приватное, а что нет.
2. тебе это не нужно знать.
Двачую. В век существования разнообразных ИДЕ, которые подсвечивают всё что можно и всё что нельзя, использовать какие-то префиксы - анахронизьм. Мы же не в блокноте пишем.
мусор у тебя в голове, а в коде это просто еще один символ. если тебя бомбит от _, то для тебя придумали добавлять m
И да, он улучшает читаемость - потому что ты видишь с какой переменной ты работаешь - с локальной, глобальной, со свойством, статик или может у тебя там вообще делегат
>>28831
>1. ты и так знаешь что приватное, а что нет.
когда перестанешь писать хеловорды и начнешь писать серьезный код в сотни тысяч строк кода минимум - тогда и приходи.
Ишь знает он
>>28831
>2. тебе это не нужно знать.
нужно если ты хочешь узнать куда идут те или иные данные и кто что меняет.
>> которые подсвечивают
это:
>>твой код не раскрашен всеми цветами радуги
А теперь вопрос на миллион, открой свою ИДЕ и посмотри как в ней выделена глобальная, статическая и локальная переменные. Вангую что одинаково. Будешь мышкой елозить?
Решарпер, конечно, дикая годнота, но помимо подчеркиваний он также навязывает динамическую типизацию, что полезно использовать в очень редких случаях.
Обе фичи я настроил под себя - количество копий, сломанных в спорах о данных случаях, намекает, что нет однозначного решения, а мое мнение не обязано совпадать с решарповским. Лично я вижу код без подчеркиваний более аккуратным и никогда не путаю приватные поля.
Кстати, кекнул от того, что в райдере 2019.3 подсказывают использовать динамическую типизацию, а потом у динамических переменных автоматом подсвечивают тип данных. И нахуя тогда нужно было писать var'ы?
>глобальная
С большой.
>локальная
С малой без подчеркиваний.
>статичная
Так же, как публичная или локальная. У них очень ограниченный юз-кейс, так что если у тебя в каждом втором классе статики путаются с локальными, ты что-то делаешь не так.
Константы с большой.
Единственный реально годный аргумент - возможность отличать аргументы функции от локальных переменных. Все остальное - самодроч.
К слову, если происходит путаница в переменных, класс нужно декомпозировать до тех пор, пока путаница не исчезнет. Независимо от тысяч строк.
>А теперь вопрос на миллион, открой свою ИДЕ и посмотри как в ней выделена глобальная, статическая и локальная переменные. Вангую что одинаково. Будешь мышкой елозить?
Ты ответь сначала, зачем с точки зрения метода, ему нужно различать природу переменных?
Ты просто типичный токсичный пидоран-полуёбок, который не может ни секунды прожить, не указывая другим как им жить и дрочить. Соси хуй, быдло.
мимопроходил
>Единственный реально годный аргумент - возможность отличать аргументы функции от локальных переменных
Если у тебя есть такая проблема - то это явно code smell. Не представляю как можно спутать это. У тебя вся игра записана в одной функции что-ли?
Что за решарпер? Он платный? Пиратить надо?
В чем его соль вообще?
У меня вижуал студио 2017 и так автодополняет иногда что-то, а решарпер зачем нужен?
Подскажите чайнику :3
Ох етить он там навыделял мне, ифы на свитчи поменял, названия все сказал неправильные. Мне мои названия нравились, хуле он доебался.
> Что за решарпер?
> В чем его соль вообще?
Это инструмент для профессиональных ентерпрайз-кодеров. В геймдеве на юнити нинужна. Юнити тебе сам все необходимые правки в код внесёт.
>Что за решарпер? Он платный?
Ты напросился на простыню, приятель!
Пользовался бесплатным месяцем решарпера. Это расширение на студию, привносит тысячи правок, помогает в назывании переменных, дабы избежать срачей выше по треду. Ловит null'ы, я только за неделю пользования избежал полудюжины ошибок благодаря его подсказкам. Очень круто преобразует циклы в LINQ или сокращает их, поддерживает чистоту кода и ловит все ненужности. По сути, это Intellisence, только под спидами.
Месяц кончился, я уж думал покупать, но решил поставить Rider от них же.
Это чувство не описать словами! По сравнению с ванильной студией это все равно что сесть за нормальную IDE после того как всю жизнь программировал в блокноте. Он великолепно заточен под юнити, проводит огромное количество проверок и чистит говнокод. Есть плагины, отслеживающие генерацию мусора, которые помогают избегать пролагов в игре. Проверяет наличие говна в апдейтах и тычет тебя носом в них.
Если ты хочешь не просто писать скриптики, а профессионально заниматься разработкой в гибко настраиваемой и заточенной под юнити IDE, то накатывай Rider, ставь плагин для юнити, плагин аллокаций, цикломатическую сложность, когнитивную сложность и наслаждайся жизнью. После бесплатного месяца тебе придется купить его или воровать, это как наркотик.
Там также неплохая поддержка бд, scv и тестов, но я их ещё не шатал подробно.
Решарпер это лайт версия для нищих и для тех кто прикипел к VS и не умеет в новое. Но и для него мастхев плагин на юнити.
Ля, звучит очень круто, спасибо за ответ.
Я в целом пока что новичок, мне и студия устраивает, я её настроил под себя аккуратненько, но ты убедил попробовать что-то новенькое.
Хм, плагин аллокаций в самом начале мне предложили поставить, а вот что это такое-
>цикломатическую сложность, когнитивную сложность
я вообще хз, погуглил и не нашел. Как это ставить?
Хипстерские расширения, позволяющие видеть метрики сложности для твоих функций:
https://plugins.jetbrains.com/plugin/11625-cyclomaticcomplexity/
https://plugins.jetbrains.com/plugin/12024-cognitivecomplexity/
Это не так важно как аллокации, но помогает держать код чистым и разбитым на понятные куски. Чисто на вкус.
Спасибо большое!
А щас бля покупаю ассет за 86 долларов и еще 17 накидывает налог! Это тысяча рублей просто подари им сукам! Как его избежать и что это за хуйня ебаная этот налог?
Тож заметил такое, я думаю это как-то связано с налоговым законодательством сша, хз как избежать, если найдешь как расскажи, возможно это вообще или нет?
А что ты решил за 80 бачей брать?
+15 рублей
Ищу анона >>544086 который был некоторое время назад. Вопрос есть!!!
Стандартная, если кодишь по утрам, темная, если по вечерам.
А как без них?
Дверь изнутри и не открывается. Ты её ломаешь нахуй.
Джоинты специально сделаны "мягкими", чтобы поддерживать механику поломок.
Тебе нужно не перетаскивать объект мышкой, а протестировать его поведение в реальных условиях, если у него не 10кк килограмм в массе, то мб он и не будет выпиливать дверь.
> дверной косяк как ирл, чтобы он физически держал дверь от открывания
Такое умеют делать только дорогие закрытые физические движки с полной симуляцией. Или я отстал от прогресса?
Все же просто, хуле ты. Показать, как сэкономить на дорогом закрытом движке?
Я тоже с середины ноября горю в ожидании. Единственная надежда, что они выкатят стабильную версию, на которой можно будет разрабатывать проект без миграций и заплаток.
Сделай миллион кнопок с этим градиентом и миллион кнопок с пнг. Сравни быстродействие. Выбери.
Не совсем корректно вопрос задал. У меня есть отдельный скрипт и мне нужно в нем прописать
if(объект с тэгом №1 соприкоснулся с объектом с тэгом №2)
как такое написать?
Проще всего не писать такой скрипт.
Как это можно проверить извне? Хранить список всех объектов-тегов1, список всех объектов-тегов2 и каждый фрейм делать перебор обоих списков и сравнивать их координаты/коллайдеры? Удачи.
Очевидно, что "объект с тэгом1 соприкоснулся с объектом с тэгом2" - это некий ивент, и ты отслеживаешь его срабатывание (в данный апдейт? за последнюю секунду игры? случалось ли вообще в игре?). Срабатывание можно легко написать изнутри.
Делаешь как описано выше и в момент срабатывания кидаешь ивент или ставишь глобальный флаг или посылаешь инфу куда надо. А дальше твой менеджер либо ловит ивент, либо делает проверку, но не как описал ты, а по выставленному флагу, меняемому в момент срабатывания.
А, но если тебе нужно проверить соприкосновение двух конкретных объектов, и ты знаешь, каких именно, то перебор двух коллекций делать не нужно и можно придумать какую-то особую логику. Но готовых вариантов никаких нет, так что быстрее и проще придерживаться первого варианта.
Спасибо за разъяснение, придумал логику
Блять, спасибо большое.
всм
640x480, 1:00
Чел удерживает кнопку мыши, и отлавливается его движения. Если чел ухватил дверную ручку и куда то движется, то дверь ведет себя так, словно чел реально ухватил дверную ручку. Если идет назад - дверь закрывается, например. Я не могу сообразить, как такое сделать, точнее, идеи есть, но реализация сложной получается.
В SOMA, например, чтобы открутить вентиль, надо по кругу мышкой елозить.
Поэтому я хочу сделать так: тупо отлавливать колесо мыши. Если чел подошел к двери и крутит колесико - то дверь медленно открывается (или закрывается).
Нормальное решение?
Просто изи, в определённые моменты (к примеру нажал на нужный обьект), считываешь движения мыши, типо если игрок тянет её с зажатой клавишей влево то дверь закрывает, если в право то открывается, ну ты понел да? Это дело модифицируешь формулой и делашеь что те надо, к примеру опять же добавляешь силу к физ обьекту(двери) с вектором направления в нужную сторону, ну короч суть ты уловил.
Это всё делается инверсной кинематикой. Гугли.
>А получится ли сделать так?
Ёбаный рот анон, попробывать не судьба? Если лень гуглить готовые решения или делать велосипед то фантазируй!
Очень костыльно. Юнити уже разработал hinge joint для дверей, тебе нужно лишь настроить его и прикладывать любую силу к объекту без изобретания велосипедов.
Другое дело - если у тебя есть выдвижные шкафы.
Пацаны, как сделать чтобы кнопка со своим спрайтом кликалась только когда мышь над спрайтом, а не над всем квадратом? Ну, например, когда спрайт в форме круга. Там вроде нужно включить use sprite mesh, и в импорте картинки mesh type tight, но не работает.
Есть одна игра, нужны шейдеры (обводки и нормал мапы генерируемые), ничего прям криминального, воду или лавовые взрывы генерировать не надо.
Я бы сам сделал, но у меня не очень получается.
Unity LWRP с шейдер графом если что.
Если есть желающие помочь, то пишите:
Бочку сделаешь?
это нужно читателю твоего кода который не знает твоего кода.
>>28899
>И в самом деле, зачем нужны эти префиксы, подчеркивания, если все можно разграничить строчной и заглавной буквами
У тебя есть класс. В этом классе есть приватные члены и публичные свойства. Допустим ты приватные переменные пишешь со строчной, свойства с заглавной...
А теперь у тебя есть метод класса, в котором есть локальные переменные (все то что будет объявлено внутри функции, а также аргументы).
Скажи как ты их отделишь от приватных членов?
А вот если бы ты помечал приватные члены _ или m - ты бы сразу видел где временные переменные, а где классовые члены. Для другого программиста который твой код видит первый раз в жизни - это серьезно упрощает чтение (сразу видно где временные переменные, а где те в которых будет хранится результат)
Далее, есть еще и статические константы - их бы тоже стоило отделить от публичных свойств (хотя это не так востребовано, так как редко появляется в коде, можно и забить)
class Foo
{
private int size;
public int Size {
get { ... }
set { ... }
}
int Bar(int arg_size) {
int local_size = ExtractSize(arg_size);
Size = local_size;
}
Ну и? ты же не будешь везде писать эти arg и локал? Или под одну сущность будешь юзать стопятсотслов? как же тогда отличить все эти 4 переменных?
пилю игру и не ебет.
(как будто там большая разница в количестве багов между альфой и релизом)
UEBS на юнити?
А вообще
- инстансинг и батчинг для однотипных персов (привет годотерам у которых батчинг не нужОн)
- генерация билбордов с моделей (ака импостор) (видел ассет который генерит на лету)
- oclusion culling (скорее всего самописный, в юнити из каробки вроде работает как дерьмо)
А вот лоды тут не сильно помогут. Юнити из каробки даже миллион кубиков не прожует (это если что из оффициальной презентации - типа в 2020 версии в следующем году юнити наконец-то сможет осилить миллион кубиков)
1080x800, 0:09
вообще я не проверял сделали ли уже аниматор для ECS чтобы делать такое щелчком пальцев. рендери лучше. рендерить то не проблема. проблема чтобы двигалось.
>>29392
>Юнити из каробки даже миллион кубиков не прожует
да жует оно всё. помню некоторое время назад в тред выкладывал сортировку где обана и рендерилось 100к кубиков. ниче особо не поменяется если 1кк рендерить.
Так есть что-нибудь бесплатное? И чтобы в этом было не сложно разобраться
DOTS канает если у тебя много объектов и на них много логики и бутылит именно в неё. То есть если ты делаешь RTS в духе суприм командера или какой-нибудь другой мясной Alien Shooter, где сотни юнитов/мобов набигают.
Если у тебя упирается в рендер - тот тут уёбс не поможет.
Юнитипараша во всей красе. Какое же юнитипидарье жалкое
http://unity3d.ru/distribution/viewtopic.php?f=105&t=49626
>Ебанутая специфичная задача, которую толком описать не можешь
>РЯЯЯ ПОЧЕМУ ЭТОГО НЕТ ИЗ КОРОБКИ
>Ебанутая специфичная задача, которую толком описать не можешь
Что ты несешь, ебанько? Есть кнопка в форме звезды на прозрачном фоне, нужно чтобы она кликалась только по звезде, а по фону нет. Если для тебя это специфичная задача, то ты конченный аутист-сын шлюхи.
>кнопка в форме звезды
Да, у всех кнопки в форме звезды с кликом не по квадрату, а именно вот по форме звезды. И нахуя такое нужно в UI? Какое реальное применение?
>Ряяяя, нинужнаааааа
Дура блядь, мне нужно, и в юнити есть реализация этого (только через сраку), значит не мне одному. Такие же тупые отмазки как в у годотеров, тебе показывают сука вот косяк, ты включаешь дауна про нинужно, кусок ебанины.
Я не говорю не нужно в принципе. Ты совсем в глаза ебешься? Я говорю что это нихуя не типовая задача в UI, что бы ещё делать "ползунок в инспекторе". Решается одной строчкой с eventAlphaThreshold, но это же так сложно, это же код писать, а нужно всё на ползунках.
Типовая и есть. Загружаешь в кнопку свое изображение, оно может быть чем угодно, от просто прямоугольников со скругленными краями, до кружков, облачек и тд. Там полно галочек непонятно для чего нужных в кнопке и при импорте изображения стоит, пусть их все удаляют и кому нужно через скрипт включают. Есть поле advanced, туда бы вставили.
>галочек непонятно для чего нужных
Так бы и сказал, что ничего не понимаешь и разбираться не собираешься, а хочешь просто ассетов натаскать и получить играбельный продукт. Только так не бывает, и тут дело не в движке, а в голове разраба. Через eventAlphaThreshold эта задача решается элементарно и никаких проблем.
>Так бы и сказал, что ничего не понимаешь и разбираться не собир
Начал съезжать, сучка, с обсуждения проблемы перешел на личности. Понимаешь, вот я сначала сидел на годоте, и поливал говном юнити, так что вы тут верещали от боли. Стоит только начать что-то реально делать, как вылазят баги. Сейчас я, конечно, на юнити, после обсера хуана с рендером, в сраче треде поливаю годотеров, но все равно, как только начинаешь реально пытаться в игру, на самых начальных этапах вылазят баги. При смешивании анимаций, при клике блять на кнопку, это же элементарные вещи. Вот ты говоришь, что эта хуйня с кнопкой прекрасно работает, и на нескольких пикчах было все нормально, но внезапно на третьей пикче посмотри на вебмке, сетка спрайта будто смещена, почему так, ммм, уеба?
>почему так, ммм, уеба?
Потому что ты криворукий. Попробовал сделать вот прямо сейчас - всё прекрасно работает, никакого сдвига нет. А уж где ты там проебался я не знаю.
>У меня все работаит, видио не доказатильства, падстроина
Классика отрицания, стоит только немного всковырнуть, как оказывается, что не только у годотирав манямирок больших размеров. Заткнись уже, черт позорный.
Так вопрос не в том, можно ли ее заставить работать, а в том почему две картинки идеально заработали, а третья мозги ебет.
В 99,9999% случаев это ты сам обосрался, просто нужно понять в чём. Очень удобно винить движок, и в юнити реально есть баги, но они совсем другого уровня и глубины.
Может у тебя разные какие-то настройки, разные форматы, просто опечатка где-то, хуй знает. Ну давай тогда и те, другие пикчи.
И ты в png спрайты хранишь все?
Только мне кажется, что на картинке хуй?
Какая разница в чем храню, я для теста сделал несколько картинок и все. У тебя заработала эта пикча, или ты так попиздеть?
Там из настроект только read/write галочку поставить, все.
Ну я кажется нашел обсер, у пикчи с боков есть пустые поля, если их кропнуть начинает нормально работать. Маска эта в левый нижний угол уходит
Я спросил, потому что пикча вот так импортнулась с ходу, значит ты в png какой-то хуйни (кроме собственно пикчи хуя) напихал.
А я и не пизжу. Я что вижу, о том и пою. А вижу я неосилятора, который нихуя не умеет, а виноват у него движок.
Кликни на картинку и в импортере так как на пикче сделай. И это чудище мне еще доказывает что-то.
>>29537
Ну так ты расскажи, почему сетка сваливается в левый нижний угол, если там прозрачное поле есть? Может где в документации про это сказано, юнитипидар?
>>29539
Вы вообще по ходу тут нубье, про настрой импорта пикч не слышали, шакалы.
Именно так. Ниже объясняю этому неоссилятору что и как.
>>29540
У меня всё с ходу заработало, даже с учётом кривого png. И я понял, в чём твоя криворукость. Ты тупо отказываешься читать доки. Почитай что такое при импорте выбор mesh type и чем tight mesh отличается от full rect mesh. Подсказка - в одном режиме будет "криво", а в правильном - всё работает с исходной пикчей.
https://docs.unity3d.com/ScriptReference/SpriteMeshType.html
вот этот UEBS https://store.steampowered.com/app/616560/Ultimate_Epic_Battle_Simulator/
вообще игра сделана на отъебись, и я не верю что там были какие то дохуя крутые самописные вещи, поэтому не могу понять, в чем же секрет?
Неоссилятор, тебе отвечали только что бы ты принял порцию урины в свой рот. Удаляй юнити, это слишком сложно для тебя, если ты даже базовые доки освоить не смог.
>>29545
секрет в том что нет никаких геймобжектов.
Там уже все готово типа того, что я перечислил? Если да то качну.
Кто-нибудь знает, почему для спрайта в 2D такая схема наложения процедурной карты нормалей не работает, а для 3D обьекта работает?
1680x966, 0:51
>>29574
а хуй его знает. наверняка как всегда суешь не то не в ту конечную ноду. кстати разве там есть какие-то различия особые между спрайтом и не спрайтом? их же одним и тем-же шейдором рисовать можно.
Ого, вот это штукенцию ты собрал там, восхищаюсь :3
Ну я использую Unity LWRP 2D Renderer новый, там для шейдеров свои 2D ноды экспериментальные используются. Выбрал этот тип из-за 2D освещения нового.
А что, в обычной версии LWRP на спрайты можно обычные PBR шейдеры кидать?
Сам себе отвечу- можно использовать, туплю просто.
Ууу сука, а когда напрямую через текстурку подключаешь мапу то все работает. Ну какого хуя?
Мне кажется, что генерируемую нормаль надо переработать как-то в текстуру и её уже через "Спрайт семпл текстур 2Д" подключить к нормалмапе, но я не ебу как это сделать. Хотя может быть я хуйню сказать.
Вот на скрине приложенном все работает, но только с текстуркой простой. А мне генерировать надо.
на самом деле говна собрал. дольше тупил-тормозил с написанием всего этого. само уравнение мелкой воды то не сложное. сложно быть тупым когда его пишешь.
пару раз оси перепутал, целый вечер проебал на осознание того что я в формулу сую отрицательную, вместо положительной гравитацию. когда узнал что семантику можно описывать через дефайны типа
#define OFFSET(tex, x, y) ((tex[id.xy + uint2(x, y)]))
#define LEFT(tex) (OFFSET(tex, -1, 0))
#define RIGHT(tex) (OFFSET(tex, 1, 0))
то всё сразу стало проще
>>29588
вообще я его уже в тредах юнити показывал.
простенький однонаправленный нодовый редактор по типу шейдор графа этого, только не компилит все это в шейдор, а на цпу выполняет. сделал чтобы редактировать генерацию земли, как-то шумы накладывать друг на друга в массивах, полезное чет делать, параметры передавать. с многопоточностью, рефлексией, няшными аттрибутами и всё такое.
недавно потыкал-потыкал и понял что карты плосковаты получаются. а задавать какие-то четкие правила генерации мне не захотелось. думал-думал как же мне сделать всякие там горы и возвышенности и решил "а пускай компьютор за меня думает" и решил поизучать эрозию, которую давно хотел глянуть.
>>29591
наверняка как всегда какая-нибудь хуйня с UV координатами. наверно надо воткнуть какую-то ноду чтобы правильно читать че ты там сгенерировал? может быть?
Етить ты суровый.
Ты работаешь где-то программистом и тут для фана постишь или как?
Мне кажется с такими навыками можно реально 300кк\наносекунду зарабатывать.
https://assetstore.unity.com/packages/tools/utilities/blockchain-sdk-by-enjin-124133
Опустим генерацию подземелья, как осуществить поиск пути?
На любом языке программирования изучаешь как сделать поиск пути, как только поймёшь суть сможешь такое же реализовать хоть на листке, главное понять как, а сделать легко.
Есть для 3д режима.
В юнити есть по навмешу, но для рогалики или стратегии такой не пойдет, там по гриду нужен. По гриду ни в одном движке нет из коробки, насколько я знаю
> По гриду ни в одном движке нет из коробки
Есть в одном. Прямо искаропки. Но нет оклюжен куллинга.
Подобным образом теперь хочу анимировать (я изменяю именно animator.SetFloat() а не сам transform), выдвижные шкафчики и дверцы шкафов. Поэтому из моего текущего кода я сделаю компонент, типа AnimateByInput, и навешу на эти геймобжекты, В компоненте надо будет указать: название переменной аниматора (в случае с дверью это Angle), скорости, Min и Max, чтобы дверцы не улетали, и тп.
Даж не представляю как ты собрался получать встроенный поиск пути для неизвестных обьектов, которые не известно как располагаются в пространстве 3Д или 2Д.
Есть встроенный нав меш агент для 3д, там надо запекать карту передвижения с параметрами агентов, вне этих карт они работать не буду, но на самих картах передвигаются идеально без глитчей.
Если же брать 2Д, то прежде чем делать карту надо сделать структуру этой карты, тобишь сеточку, искаропки в юнити можно запечать в 2Д, но лично не делал лишь видел видосики, не сильно отличается от 3Д, думаю по аналогии также.
Хотел назвать тебя извращенцем, но, вроде, норм система. Не очень гибкая и требует дополнительной работы с каждым новым этапом, зато не нужно пилить полноценный фреймворк.
Но все равно кто физику через анимации делает? Извращенец!
Кстати, переносных предметов не будет? Что если открыть дверь, положить в проходе ящик и попытаться закрыть?
Для протокола заявлю, что встроенная система в юнити чисто для галочки, там очень кастрированная настройка навмеша. А на гите лежит неофициальный плагин от создателей юнити (NavMeshComponents), вот там и генерация навмеша в рантайме, и хождение по стенам, и навмешлинки нормальные. Мне он даже больше, чем A* понравился.
У них еще по моему авто лоды есть, тоже недоделаны на гите тухнут
>Кстати, переносных предметов не будет?
Не, таскать ничего не надо будет.
>то если открыть дверь, положить в проходе ящик и попытаться закрыть?
Попробовал - дверь толкает куб, сама дверь кинематик.
>Но все равно кто физику
Я вообще не думаю, что в моей игре важна физика. Но сейчас че то думаю, что было бы неплохо, если бы дверь была свободной, болталась, когда мимо нее пробегаешь, чтобы можно было открыть туловищем, и не нажимать на мышь. Хм, надо еще раз попробовать, в прошлый раз мучался с hinge joint,так и не смог нормально сделать
>Для протокола заявлю, что встроенная система в юнити чисто для галочки, там очень кастрированная настройка навмеша
Хз что ты там заявляешь лично юзая встроенную, ваще проблем не наблюдаю, всё супер.
ГГ ВП, бро!
Пробовал создавать агентов с разными размерами, м?
Открывать двери таким способом можно было ещё в этой технологически отсталой игре
https://www.youtube.com/watch?v=1qVzZFYZEus&t=681
и без всяких джойнтов
1680x966, 0:18
лол. на самом деле у меня вполне обычные навыки для человека который ушел несколько дальше базовых вещей.
то что я показал - умение дорабатывать юнити напильником и немного шейдорной магии совсем не требуют каких--то продвинутых навыков.
>>29663
https://ru.wikipedia.org/wiki/A*
настоятельно советую заимплементить его самостоятельно. как колдун навигации тебе говорю.
>>29773
тебе тогда Rigidbody.AddTorque уже наверно надо же. ты же крутишь а не толкаешь. но можно и аддфорсом конечно, перпендикулярно плоскости двери.
1680x966, 1:00
вообще да, приятно смотреть как машина за тебя песочек пересыпает. дрыгаемое значение это допустимое соотношение между высотой и шириной.
Что тогда продвинутые навыки по твоему?
И в итоге, это у тебя хобби или ты все же в индустрии работаешь?
>тебе тогда Rigidbody.AddTorque уже наверно надо же. ты же крутишь а не толкаешь.
AddTorque вращает объект вокруг его origin'а. В то время как система джоинтов настроена так, что объект пол воздействием сил будет вращаться вокруг оси hinge joint'а прямо из коробки.
У меня в большинстве случаев AddTorque либо не работала, либо приводила в контринтуитивному поведению (именно в контексте джоинтов), так что ему нужно использовать как раз AddForce или AddForceAtPosition.
928x644, 0:23
как всегда. продвинутые навыки, разумеется, это те навыки которые можно продать. те навыки которые получил занимаясь каким-то говном достаточно долго чтобы другие нихуя не понимали что за колдовство ты делаешь, или мочь сделать это в несколько раз быстрей и лучше чем другие.
а по поводу моей деятельности - тут нет однозначного ответа. я действительно подрабатываю в этой сфере, но не больше чем чтобы не подохнуть с голоду. так что скорее это что-то из категории увлечений, которое иногда становится профессией.
>>29871
всегда можно иметь пивот прямо на джойнте же и в целом это самый разумный способ взаимодействия с джойнтами. по моему в юнити так и не завезли приложение торка к какой-то конкретной позиции до сих пор.
ну и в конце концов джойнты можно крутить через лимиты, да. но там конечно надо понимать как колдовать с ротациями.
так то джойнты весело. много весёлого с ними можно сделать. могу показать забавную анимацию через лимиты. помню наверно года 3-4 назад тут был анон который всего человечка так анимировал.
>всегда можно иметь пивот прямо на джойнте же
Как? Я видел только два решения:
- Редактировать модель самостоятельно или заранее ставить ТЗ с четко обговоренным ориджином.
- Пихать объект внутрь пустого геймобжекта с необходимым отступом.
Мне категорически не нравятся оба способа. И я подозреваю, что AddForce - ожидаемый разработчиками способ взаимодействия с джоинтами. Когда ты телом игрока толкаешь дверь, ты прикладываешь не вращение, а силу. Скриптами ты должен действовать по аналогии.
AddTorque я использовал, когда писал полностью самостоятельные двери без джоинтов с настроенным ориджином и, откровенно говоря, они получались хуже оригинала.
в целом второе решение - правильное. едва ли не все интерактивные предметы требуют коррекции позиции(и не только её). так что как правило следует подготавливать префабы разделяя объекты которые отвечают за визуализацию, за физон, за что угодно. нет ничего зазорного в использовании геймобжектов как "папок" в сцене. и как правило это очень ускоряет дальнейшую работу с ними. 111 скейл самого верхнего объекта решает огромное количество проблем, например.
хотя, конечно, это не применимо ко всем случаям.
что касается способа взаимодействия - ваще похуй, до тех пор пока это происходит через физон. это целиком зависит от контекста. торк в работает более предсказуемо, так как точка приложения усилия это то на чем легко проебаться.
если то что прилагает усилие - какая-то виртуальная рука игрока, или конкретная точка то я бы и вовсе прилагал усилие через джойнт висящий на руке игрока. так как там можно настраивать плотность киселя который замедлял бы движение при близости к анкору.
>я бы и вовсе прилагал усилие через джойнт висящий на руке игрока. так как там можно настраивать плотность киселя который замедлял бы движение при близости к анкору
Где про это подробнее почитать?
а сильно ли надо где-то про это читать? открой юнити, потыкай там конфигурабл джойнт. джойнты же могут магнитить одно к другому. для держания/хватания самое заебись. много че сделали искаропки, типа скейла массы между объектами.
попробуй спроси у гугла ченить типа "unity portal picking holding", в портале же предметы на физоне в руках болтались.
небольшой видосик в тему хватания держания предметов.
Выйду ночью в поле
с конем
Ночкой темной тихо
пойдем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Ночью в поле звезд
благодать
В поле никого не
видать
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Сяду я верхом на
коня
Ты вези по полю
меня
По бескрайнему полю
моему
По бескрайнему полю
моему
По бескрайнему полю
моему
По бескрайнему полю
моему
Дай-ка я разок
посмотрю
Где рождает поле
зарю
Ай, брусничный цвет
Алый да рассвет
Али есть то место,
али его нет
Ай, брусничный цвет
Алый да рассвет
Али есть то место,
али его нет
Полюшко мое,
родники
Дальних деревень
огоньки
Золотая рожь да
кудрявый лён
Я влюблен в тебя,
Россия, влюблен
Золотая рожь да
кудрявый лён
Я влюблен в тебя,
Россия, влюблен
Будет добрым
год-хлебород
Было всяко, всяко
пройдет
Пой, златая рожь,
пой, кудрявый лён
Пой о том, как я в
Россию влюблен
Пой, златая рожь,
пой, кудрявый лён
Мы идем с конем по
полю вдвоем...
Выйду ночью в поле
с конем
Ночкой темной тихо
пойдем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Ночью в поле звезд
благодать
В поле никого не
видать
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Сяду я верхом на
коня
Ты вези по полю
меня
По бескрайнему полю
моему
По бескрайнему полю
моему
По бескрайнему полю
моему
По бескрайнему полю
моему
Дай-ка я разок
посмотрю
Где рождает поле
зарю
Ай, брусничный цвет
Алый да рассвет
Али есть то место,
али его нет
Ай, брусничный цвет
Алый да рассвет
Али есть то место,
али его нет
Полюшко мое,
родники
Дальних деревень
огоньки
Золотая рожь да
кудрявый лён
Я влюблен в тебя,
Россия, влюблен
Золотая рожь да
кудрявый лён
Я влюблен в тебя,
Россия, влюблен
Будет добрым
год-хлебород
Было всяко, всяко
пройдет
Пой, златая рожь,
пой, кудрявый лён
Пой о том, как я в
Россию влюблен
Пой, златая рожь,
пой, кудрявый лён
Мы идем с конем по
полю вдвоем...
Круто!
А то я сам разрабатывал подобную систему. Джоинты для дверей и механизмов, а перенос предметов чистой физикой. Интересно изучить альтернативы.
Получается фрилансер?
Прости, что лезу с допросами, но почему не найдешь себе постоянную работу программистом? Мне всё еще кажется ты без проблем бы нашел себе место в любом достойном проекте с такими навыками и знаниями.
Или ты пилишь свой проект мечты какой-то?
Я не он, но отвечу. 80% геймдева в снг - мобилкоговно в духе 3 в ряд и онлайн казино. 15% оставшегося - браузерки и интерактивные системы для бизнеса. Уныние и боль.
В оставшихся 5% конкуренция и требования настолько бешеные, что быстро подскочить представляется проблематичным. И требования там зачастую выдвигаются очень узкие. Проще пилить самому игори по фану, чем удрачиваться неинтересными бездушными проектами.
> Проще пилить самому игори по фану, чем удрачиваться неинтересными бездушными проектами.
А кушать как?
Т.е нормальных игор не делают. Что там было за последнее время, метро да пасфайндер.
Открываем студию и организуем какой-нибудь мегапроект чисто под СНГ-аудиторию. Вроде танков или фортнайта со специфичным колоритом и шапками-лутбоксами. Проект должен выстрелить, тут зависит от маркетинга и удачи.
Итак, у нас будет свой фортнайт с блэкджеком и шлюхами, многие в него пойдут, потому что тут будет свой пацанский колорит, который чужд буржуям. Тут главное продумать сеттинг - на ум приходит совок и красные-белые, царская Россия, Сталкер (заезжено пиздец, но ещё можно придумать что-то оригинальное), вторую мировую лучше вообще не брать, слишком заезжено.
И открываем свою платформу, продаём игру эксклюзивно на ней только на территории СНГ. Будет магазин от "наших" для "наших", и не нужен никакой Габен с буржуями.
Туда же принимаем всех инди. Произойдёт сразу расцвет инди в СНГ и поднятие индустрии с колен, а мы заработаем много денег, т.к. ниша не занята от слова совсем. Идём чисто по стопам эпик геймс.
Я вам охуенную бизнес-идею подкинул, как реализуете, заплатите мне роялти (а то по судам затаскаю).
>80% геймдева в снг - мобилкоговно в духе 3 в ряд
Уже давно перешли на 3Д игры. Всякие хорроры, сурвайвалы, сетевые игры.
>Проще пилить самому игори по фану, чем удрачиваться неинтересными бездушными проектами.
Что это за игры такие? И почему ты не можешь по фану сделать моб игру и зарабатывать на ней баксов 100 в день?
> И почему ты не можешь по фану сделать
Так ему для этого придётся трудиться, а не в интрнетах срать.
>Уже давно перешли на 3Д игры. Всякие хорроры, сурвайвалы, сетевые игры.
Возможно. На игры перешли, а разработчиков новых почему-то не ищут.
>Что это за игры такие? И почему ты не можешь по фану сделать моб игру и зарабатывать на ней баксов 100 в день?
Так я и не говорю, что по фану - обязательно бесплатно. Посыл в том, что дома ты можешь пилить то, что интересно тебе, а на работе с большой вероятностью это будут клоны-кликеры.
Пока это выглядит так, что Юнити вообще не рассчитана на нормальную работу с динамичными тенями, и больше подходит для мобилкогейминга и инди со стилизованной графикой вообще без теней. Это так?
Так это запеченые тени, а меня сейчас интересует динамическое освещение, которое, похоже, в Юнтити рудиментарное и очень плохо работающее. Это если не считать HDRP, которое я еще не тестировал.
Оно везде такое. Newsflash - динамическое освещение внехуенно дорогое. Именно поэтому мы имеем RTX мем
Хм, ну окей. Я успел протестировал пару юнити-туториалов с освещением и запеканием, и мне показалось, что получается какое-то говно. Что ж, пойду луркать дальше, а то я уже был готов плюнуть на все и пойти скачивать UE4.
у UE4 больше свистоперделок изкаропки, возможно тебе он пбольше по вкусу будет. Попробуй
Спасибо, добрый анон. Попробую еще покопаться в Юнити, если не сдвинусь с места - потестирую Анрил.
Охуеть манямирок.
Свет - очень обширная тема, тянет на отдельную профессию. Из коробки действительно получается говно, а в настройке очень много подводных.
У URP (LWRP) довольно паршивая поддержка реалтайм теней. Хоть они и позиционируют себя универсально, но лучше оставить его для мобилок и казуального графона.
HDRP, в свою очередь, имеет хуеву тучу настроек из которых можно сделать конфетку.
Да, посоветованный постпроцессинг помогает картинке, но не конкретно с тенями и светом.
Спасибо, что даешь ориентиры, это то, что мне сейчас нужно.
Как я и думал, пора вкатываться в HDRP.
К слову, сейчас меня больше всего обеспокоит peter panning (тени находятся на расстоянии от объекта), shadow acne (жуткий баг, появляющийся при попытке исправить первую проблему с помощью bias) и низким разрешением теней в целом, особенно при удалении от источника света.
>>30084
Спасибо. конечно, но я не очень понял, как это может конкретно с тенями. Так что тут я соглашусь с аноном выше, который сказал, что:
>постпроцессинг помогает картинке, но не конкретно с тенями и светом.
Проверил. Оставил только вращение по одной оси. И она проваливается. Хотя у двери 1к масса, а у чарактера 10. И я даже не знаю, как сделать, чтобы у двери ось вращения была сбоку. Пытался сделать костыль из скриптов по фану - начал проходить сквозь дверь. Такие дела.
Да, симуляция физики в современных движках имеет ряд фундаментальных проблем, которые приходится обходить всяческими ухищрениями.
Но спасение уже есть! Купи HAVOK!
Печально. Я думал, сработает Теперь вопрос на миллион: как ты перемещаешься персонажем?
> как ты перемещаешься персонажем?
При получении данных с устройства ввода я начинаю плавно увеличивать скорость в направлении перемещения, до тех пор, пока скорость не станет максимальной. При исчезновении данных с устройства ввода я начинаю плавно уменьшать скорость, немного быстрее, чем до этого наращивал.
Угу, на триггер-вольюмах и миллиарде скриптов. Это пастген, ты еще предложи освещение и блики в текстуре рисовать d 20 20
Я создатель тредов и автор постов!
Во первых, ускорение-торможение уже придумано в виде переменной gravity в input'е.
Во-вторых, я спрашивал про конкретную функцию, которой ты заставляешь объект двигаться. Я это к тому, что в юнити достаточно способов передвинуть объект игнорируя физику мира. Если ты используешь один из них, то дверь, естественно, не может устоять перед объектом, который телепортируется прямо в нее, и начинает пидораситься.
Ну, сколько я ассетов контроллера ни качал, во всех используется интерполяция трансформа. Какая физика, ты о чём вообще? А так можно было?
Я мимо проходил, но спрошу.
А посоветуй какой-нибудь годный контроллер для первого лица. Физика rigged body не нужна, достаточно плавного и естественного хода камеры. Хорошо бы еще бесплатный (но если можно своровать, то тоже ок).
Конешно. От лучшего к худшему:
1. rigidbidy.AddForce. Неудобно настраивать для аркадного управления, ибо адовая инерция. Зато крутые реалистичные перемещения физических объектов (если ты пилишь космические симуляторы).
2. rigidbody.MovePosition, rigidbody.velocity. Удобно настраивать, но нереалистичное перемещение без инерции. Обычно это то, что нужно. Инерция допиливается самостоятельно.
3. Character controller. Классика. Удобный компонент исключительно для перемещения персонажей, но не принимает в расчет физику. Обычно на нем строят FPS-контроллеры.
3.5. NavMeshAgent. Для point-n-click систем. Тоже игронит физику, но там можно играться с обходом и толканием препятствий.
4. Манипуляции с трансформом. Для месье-извращенцев.
>>30319
Не, не то. Прогулялся по коду, а батчинг у меня уже включен, хотя и работает через раз за счёт не помню уже каких ограничений в пропертиблоках.
Слишком слабый комп. Сделал тыщу моделек на одной сцене, загрузка ЦП под 95%. Ну не буду же я их все в один меш объединять ради СЕБЯ одного, это слишком много оптимизации для корректной работы на ржавом железе. У них и анимации, и прочая чушь.
Из игр на юньке похожего жанра и, следовательно, похожих игродизайнерских решений, которые пробовал сам играть, Тирания стабильно вылетала в городе с водопадами из-за нехватки ЦП, а Тея едва играбельна с теми самыми 95% загрузки. Стоит ли мне вообще с этой проблемой заморачиваться?
Тысяча моделек по миллиону поликов каждая
Очень неудобно когда открываешь что нибудь из секции widows переключаться на главный моник и перетягивать окно обратно на тот, на котором работаешь.
У меня есть пк с шиндоусом, не хочу себя насиловать этим говном, на маке все равно удобнее. Тем более что освноной таргет - айфоны, сомневаюсь что на винде я смогу нормально подебажить через юнити ремоут.
Ньюфаг на связи.
У меня сцена состоит из нескольких зон, которые могут стыковаться друг с другом рандомно (планирую их из префабов загружать и расставлять на сцене скриптом). Пикрелейтед, вид сверху.
Как быть с запеканием освещения? Можно запечь его для префаба, как бы для сцены внутри сцены? Или из-за динамического окружения я сосу?
Как правило - нет. Симуляция физики несовершенна, и если 60-килограммовый персонаж слегка заденет легкий объект, результат будет не из лучших. Куда важнее правильно настроить Drag.
Проще настроить несколько предметов, чтобы их взаимодействия через массу смотрелись органично, а затем подгонять остальные объекты под них.
Так-то lightmap можно прилепить к объекту, но я не нашел способа подружить всю эту систему, когда я пилил нечто подобное.
В любом случае у тебя на стыках будут происходить странные вещи. Лучше придерживаться динамического освещения.
> слегка заденет легкий объект
Иначе говоря, правильный ответ такой: если проставлять массы - то абсолютно всем объектам в игре, и горе тебе, если забудешь хоть одну маленькую чашечку!
ну как можно сделать одну фичу и получать пару десятков багов совершенно в других местах?
Я бы понял если бы ошибки были связаны с новыми фичами (новый код, все дела)...но ошибки рандомные, никак не связанные.
Я бы понял если бы движок только вчера сделали, и до сих пор не обкатали... но движку уже больше 10 лет
Да еще и баги в разных версиях из близких областей - то есть один баг пофиксили, а один оставили на будущее?
Или еще забавней, это переходы на новую версию - вот была 2019.3 альфа. все вроде затестили, перенесли в бету и тут в 2020.1а опять сплошной поток багов, как? они еще даже фич не успели туда добавить.
Даже возникает такое ощущение что у них есть специальный спец задача которого наделать 10500 ошибок чтобы в следующей версии патчноут был не из одной строки, а из 10500 фиксов багов (создаем видимость работы, да)
А ведь я смотрел код юньки (ну 4 версии) - он был вполне себе годный, без всяких там хаков и прочей вуду-магии после которой код бы падал по средам в полночь в дождь.
Так что реально кажется что баги делают умышленно
В годоте тоже ничего не добавляют уже год, но баги фиксятся пачками ежедневно, это норма видимо для движков
Пацаны, котята, помогите, как сделать увеличение скорости при таком 2д свайп контроллере:
https://pastebin.com/3NNuyWdQ
В скрипте понятно в чём ошибка и почему багует, игрок при каждом щелчке по экрану отлетает в сторону кратно скорости, но зато после этого движется ускоренно и плавно, как надо. Все другие способы которые я пробовал, делают движение либо ломанным, либо не точным.
С меня тонны нефти.
У тебя твои сотни префабов от силы будут занимать пару мегабайт. Ничего страшного не случится от того, что они всем скопом загрузятся в память игры.
Я сделал так же для автоматизации библиотеки префабов, подводных пока не нашел. надеюсь и не найти
Как лечить такое? раньше этого не было. мало того что теперь когда я создаю скрипт в юнити редакторе, он показывает такой вопрос, но и он еще перетирает все несохраненные файлы (я так целый скрипт потерял:( )
Это норма, жмешь обновить все и обновляешь. Потом создаешь новые скрипты через саму визуалку.
попробовал через визуалку - оно пишет что проект был изменен вне среды и обновляет вообще все.
Там явно что-то надо сделать
Вот зашел в студию, создал скрипт, развернул редактор юнити, оно там что-то поделало (полоса загрузки), развернул студию и написало так
и на каждый скрипт надо заменять все данные? я задолбаюсь
а еще прикол в том что раньше-то (до перестановки винды и софта) все работало, ровно в той же сборке - unity 2020 и vs 2019. Как-то же я раньше это настроил
Можешь попробовать снести все нахер и начать с установки юнити. Он вроде умеет VS сам накатывать.
Пройдись по всем настройкам юнити, проверь, что VS выставлен стандартным редактором. Проверь package manager, там есть расширения для VS.
Была такая же проблема, не помню, с чего началась и чем закончилась.
Есть группа обьектов с круглыми 2D коллайдерами на них.
Есть игрок, который перемещается среди них.
Задача- сделать так, чтобы мы тригерели ивент на входе во всю эту группу и на выходе из всей группы.
OnTriggerEnter2D срабатывает на каждом этом обьекте по отдельности.
А нужно один раз его вызвать на входе в такой тип обьектов и один раз на выходе. Типа проверять, остался игрок внутри них или нет.
Ладно, как мне просто проверить что игрок НЕ ТРОГАЕТ слой с определенным тегом/леером?
Что может быть проще? Добавь int в игрока, или в твой менеджер коллизий, или в игровой менеджер. При заходе в триггер инкрементируй, при выходе - декрементируй. В таком случае условие "вошёл в группу" срабатывает только при смене 0->1, а " вышел из группы" - при 1->0.
Сделай ход конём и организуй так, чтобы при нажатии дверь толкалась вперёд. Отпадут все вопросы, а взаимодействие будет органичным и предсказуемым для игрока.
О блин, я думал о таком, но построил ебанутую систему с таймером в итоге, типа игрок проверяет на выходе не попал ли он снова в етот коллайдер, лол.
ps но предсказуемость это хорошо
Ты вообще тот солюшен то открываешь? Попробуй открыть из Юнити наверху assets-> open c# project.
transform.forward
Продолжать. В этом и смысл.
Б-же, оно сработало! Спасибо тебе дорогой!
Я целый час ебался и пробовал писать 100 разных вариантов, а все оказалось так просто, я в ахуе.
В интернете вообще не встречал таких систем ни разу, спасибо тебе, спас меня!
Нахуя делать дверь джоинтом если можно просто сделать анимацию открывающейся двери?
Ладно, вроде прблему решил. Просто дверь дочерняя, локальные rotation и position у нее по нулям, так что векторы взял локальные. Хз, как это работает, надо подумать
Зато дверь можно толкать туловищем. А если я запущу анимацию, а дверь столкнется с препятствием?
Еще упростил код. Бля, я тупица. Мозг после работы не фурычит. Как же плохо работать прогером (не геймдев, жалкий вэб), домой придти и опять кодить
Зачем ты игры делаешь? Лучше бы новый веб фреймворк выучил.
Да, лимиты приходится перенастраивать. Как вариант, напиши простенький скрипт, который будет на старте брать текущее вращение и вычитать из лимитов.
Во время обучения всегда так. Если анон его переживет, то будет ебашить скрипты десятками. Года через три.
Все равно плохо. Что за магическая константа 33? А если ты захочешь сделать открывание на 40 или 45? Будешь каждый раз в скрипт лезть? А ну марш выносить константы в сериализованные переменные!
Алсо, пилю лайфхак. Твоя система плоха тем, что не учитывает положение игрока относительно двери. Игрок интуитивно будет ожидать одного, подходя к двери с разных сторон, а получать - другое. Вот как это решил я.
Передаешь в скрипт управления двери данные об игроке (или камере). При удерживании двери накладываешь силу на дверь:
force = player.transform.forwardInput.GetAxis("Vertical")+player.transform.rightInput.GetAxis("Horizontal");
При клике по двери игрок толкает ее вперёд: force=player.transform.forward*pushForce;
Таким образом игрок может открывать, закрывать и быстро толкать дверь.
С такой системой можно делать рычаги и сундуки, если догадаешься, как менять векторы направлений в зависимости от типа взаимодействия.
Это был упрощенный код, специально для треда
>Мозг после работы не фурычит
Ты весь день занимаешься умственной работой, приходишь домой и занимаешься тем же. Мозг просто физически не может делать одно и то же. У тебя голова не нагревается к вечеру? И как ты ещё в депрессию не скатился?
>force = player.transform.forwardInput.GetAxis("Vertical")+player.transform.rightInput.GetAxis("Horizontal");
В смысле дверь двигается вместе с игроком? Не лучше ли тогда связать дверь и игрока?
Ну а чё ещё делать, у меня больше нет увлечений. А так да, депрессую. Особенно когда хочется проект попилить, а мозг устал, и я сижу кинчик смотрю
1008x492, 0:11
Похоже, что нужно переходить на годот
Quaternion.FromToRotation(transformA.position, transformB.position) не туда поворачивает почему-то. Дебажить кватернионы я не могу, надеюсь на какую-нибудь встроенную функцию. Заранее спасибо.
На всякий случай объясню задачу. Нужно повернуть игрока в сторону врага. Мой контролер, который отвечает за перемещение, принимает кватернионы, чтобы вращать персонажа. Вот тот, который получается из FromToRotation вращает персонажа не туда.
Да, я проебался. Имелись в виду Mouse X и Mouse Y. Хотя движение игрока тоже можно включить, чтобы взаимодействия на ходу воспринимались нормально.
>Дебажить кватернионы я не могу, надеюсь на какую-нибудь встроенную функцию. Заранее спасибо.
https://docs.unity3d.com/ScriptReference/Quaternion.html
>You can use the Quaternion.operator * to rotate one rotation by another, or to rotate a vector by a rotation.
возьми вектор, поверни его на кватернион, отдебаж вектор.
алсо на той-же странице. какая из перечисленных функций описывает то что нужно тебе? кубик надо совать в круглую дырку, квадратную, или треугольную?
Можешь попробовать Quaternion.FromToRotation(transformA.forward, transformB.position-transformA.position). Ты юзаешь вектора отвечающие за положения объектов, а нужно - вектора направлений.
LookAt проще, как тебе ответил анон.
Лоды не менялись уже 5 лет, значит на эту ошибку всем похуй, никто ее исправлять не собирается, юнитиговно-классик
>LookAt
на самом деле так себе затея пользоваться им. колдовство дельта-ротаций куда лучше. FromToRotation - правильный ответ.
>>31439
суешь векторы, получаешь ротацию на которую надо умножить вектор А чтобы получить вектор Б. понимаешь? то насколько надо повернуть один вектор, чтобы получить второй вектор. поворачивание через оператор умножения. в эту функцию суешь не позицию. а вектор. направление. куда он смотрит.
Vector3 forwardA = A.transform.forward;
Vector3 forwardB = B.transform.forward;
Quaternion rot = Quaternion.FromToRotation(forwardA, forwardB);
Debug.DrawRay(Vector3.zero, Vector3.forward, Color.magenta);
Debug.DrawRay(Vector3.zero, rot * Vector3.forward, Color.red);
Debug.DrawRay(A.transform.position, forwardA, Color.magenta);
Debug.DrawRay(B.transform.position, forwardB, Color.red);
понимаешь? оппа и если повернуть форвард вектор А на эту ротацию то он будет смотреть туда-же куда форвард вектор Б.
Это всё хорошо, если бы мне нужно было смотреть туда, куда смотрит противник. Но мне нужно было смотреть на него. Но всё равно спасибо, ты няша.
поэ-э-этому тебе надо повернуть текущую ротацию, на текущую ротацию + дельта-ротацию до противника. круто да? в дополнение к коду выше можно написать
A.transform.rotation = Quaternion.Lerp(A.transform.rotation, A.transform.rotation * Quaternion.FromToRotation(forwardA, forwardB), 0.1f);
тогда А будет крутится в то-же направление в которое смотрит Б. например. а можно совать туда и направление от текущего форварда до противника.
а вообще, этот пример с FromToRotation я привел чтобы повернуть одно в сторону другого. но ты учитывай что оно поворачивает вектор. а вот ориентацию вдоль вектора оно тебе сделает скорей всего не ту которую ты ожидаешь увидеть. поэтому лучше воспользуйся Quaternion.AngleAxis, сунь в него угол между форвард вектором и направлением до противника, получишь дельта-ротацию с сохранением UP вектора. это будет куда приятней результат.
Большие игровые студии частенько набирают джуниоров, которые ещё только обучаются. Чекай их сайты, спрашивай их ХРов. Чем быстрее к ним устроишься, тем лучше. Буду платить мало скорее всего(если не дс), но зато реальный опыт и после тебя повысят.
В геймдеве бешеная конкуренция. На опытного разработчика обычно собеседуют несколько десятков кандидатов. На должности джунов-ньюфагов мне даже сложно представить какой ад творится.
Особенно после того, как развелись всякие скиллбоксы и подобное дерьмо. Теперь любой долбоеб за трёхмесячный курс превращается в конкурентоспособного кандидата. Нужно реально сиять или иметь нехилую удачу, чтобы выделиться среди них.
>>31511
В течение недели чётко мониторь потраченное на геймдев время. Тебе может казаться, что ты дохуя работаешь, но не факт, что это правда.
Если ты тратишь 3-4 часа 3-4 раза в неделю, причём не только бесконечно учишься, но и занимаешься рутинной работой над игрой (диздоки, настройка сцен, префабов, света), то тебе потребуется ещё около 11 месяцев, чтобы работодатель тебя хоть как-то рассматривал как вариант.
Если ты ебашишь каждый день по паре часов, то может через 8-9 месяцев у тебя будет достаточно опыта для минимальной планки. Если ты ебашишь стандартный восьмичасовой день, в чем я сильно сомневаюсь, то у тебя есть шансы стать персонажем историй об успехе месяца через четыре.
Моя история - около года задрачивал свои проекты, активно при этом искал работу, еженедельно рассылая резюме в две-три компании. Ни-ху-я. В итоге вкатился обычным джуном программистом в левую контору. С тех пор уже наыармил прилично опыта, продолжаю ковырять юнити почти ежедневно, вырастил зарплату в два с половиной раза, но в геймдев так и не попал, лол. Отчасти потому что сейчас я обнаглел, прошу в полтора раза больше нынешней зарплаты и отказываюсь работать над казино и матч-3.
>на самом деле так себе затея пользоваться им. колдовство дельта-ротаций куда лучше. FromToRotation - правильный ответ.
Почему? Чисто чтобы знать кухню кватернионов и не пользоваться простыми функциями для неосиляторов?
Я же говорю, обычный погромист. Сначала работал над умным домом, сейчас работа с банками в крупной корпорации. Скучно,но есть деньги и время на игрострой в перерывах.
Меня вштырило написание скриптов, и это стало моей основной профой. И несмотря на то, что под Юнити кодить я могу в разы лучше, чем под .net, предложений очень мало. В то время как обычные конторы меня с руками отрывают, лол.
600x422, 0:09
эти функции будут далеко не везде, а вот проблемы ротаций всюду. например вот тот удивительный человек верху дверью хлопает, половину его удивительных проблем с джойнтами можно было давно уже решить с помощью колдовства ротаций.
или например видеорелейтед. помню наверно месяцев 8 назад тут был другой интересный человек, он хотел нажатием кнопки крутить кубик, но так чтобы оси его ротаций всегда были кратны 90. как решить эти проблемы? с геймобжектами ещё можно поколдовать немного. но далеко не все эти проблемы - проблемы геймобжектов.
>>31555
чё к резюме то прикладывал? какие проекты?
>чё к резюме то прикладывал? какие проекты?
Поначалу - ничего, а сейчас - гитхаб с полудюжиной рабочих библиотек под Юнити, написанных мной.
Портфолио определенно помогает, но если ты - хуй, на техническом собеседовании это вскроется.
Охуительные истории про годы поисков могут казаться преувеличением, но:
1. Казино и браузерки сразу нахуй.
2. Портфолио у меня не было около года.
3. Работать бесплатно я не готов.
Готов предположить, что если анон возьмёт себя в руки и за месяц выпустит с пяток топов продаж в гуглплее, то с трудоустройством проблем у него будет меньше.
1152x776, 0:22
да вообще чисто так интересно что другим людям показывал то, что были такие проблемы с поиском. на этой доске не часто люди делятся таким опытом.
лично у меня особых проблем не возникает, но мне и показать в целом есть что. вот только начинал я тыкать всё это как увлечение и проёбывал тонны времени на него без цели найти работу в этой сфере. а когда в животе заурчало то внезапно оказалось что мои скиллы в целом востребованы. так что я скипнул тот этап неопределённости и даже рассказать по этому поводу нечего. а вопрос то важный.
Недавно, к примеру, собеседовался в одно место. Рекрутер разоткровенничался и сообщил, что я у них 47й кандидат. Ищут человека второй месяц.
Пиздеть ему смысла нет, меня все равно не взяли. Разговаривал он открыто.
И это компания, ищущая специалиста с 3 годами опыта работы с разнообразными навыками и узкими критериями.
А теперь представь, какой поток людей на стартовые вакансии. Любой человек полгода потыкавший кнопки в юнити уже мнит себя специалистом.
Ощущение, что сейчас везде избыток людей и работ нет, у нас продаваны в тц сидят на этих островках перчатками торгуют за 800 рублей + 5% с продаж в день, но там продаж почти нет, три через три и ведь все забито
Это относится к неквалифицированному труду в основном. Когда я менял работу меня буквально завалили спамом с предложениями (не геймдев).
Все хотят себе погромиста, который уже что-то умеет, но ещё не нюхал настоящих денег. Он за копейки вьебывать будет и ещё и довольным останется. Я эту фичу просек и теперь на собеседованиях требую зарплату на 30-40% дороже, чем себя оцениваю сам. Поэтому меня никуда не берут, лол.
>Он за копейки вьебывать будет и ещё и довольным останется.
Так в итоге что продаван за копейки будет работать, что прогер. Когда тебе или такому как ты жрать нечего станет и это место займет.
Нету в юнитипараше такого, они лучше еще какой-нибудь дотс запилят, чем нужные фичи для игростроя.
Там по наступлению ивента вызывается функция, которая выполняет detectedObjects.Remove(other.gameObject). Когда она будет вызвана, она удалит именно тот геймобджект, который был в контексте на момент подписки именно этой функции, я правильно понимаю?
Или мне надо как-то явно в делегат передавать, какой геймобджект выстрелил ивент?
Вроде все верно.
Протестируй, хуле ты. Всего-то кинуть в пустую сцену геймобжект, триггер и вызов твоего ивента. Получилось бы быстрее, чем пост на двач писать.
Алсо, защиту от множественных срабатываний не забыл на случай, если объект несколько раз входит в триггер? В курсе, что лямбды невозможно отписывать от ивентов оператором "-="?
Да в том и дело, что у меня потом в этом списке уничтоженные геймобджекты возникают иногда, хотя перед уничтожением должны ивент отправить и съебаться из списка. Вот и пытаюсь понять, откуда такое.
Так-то дохуя вариантов может быть, начиная от нескольких коллайдеров и кончая случайной очисткой или игнором событий. Логами обмазал бы каждую строчку и проблем бы не знал. Или вынос операций с листом в отдельные функции и расстановка брейкпоинтов.
Братан, была абсолютно такая же проблема.
У меня проблема была в том, что я вместо RawImage использовал простой Image (хз почему, но просто image не выводится на экран)
Ещё я установил размер канваса равный разрешению экрана.
Если хочешь, можешь связаться в дискорде, я тебе могу всё показать
Привет юнитологи, ищу вот такую книгу "Гейг - РАЗРАБОТКА ИГР НА UNITY 2018 ЗА 24 ЧАСА". Скиньте ссылку пж если у кого есть. Заранее спасибо
Это копия, сохраненная 13 апреля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.