Прошлый: >>626966 (OP)
Поясни плиз, что за хуйня с шапкой? Может мне что нить придумат ьи написать? Ну нихуя же не понятно, без сыллок и всей хурмы, прям стыдно за юнити становится после таких тредов.
думаю тут пояснено всё что тебя интересует
https://blogs.unity3d.com/ru/2018/01/12/unity-labs-autolod-experimenting-with-automatic-performance-improvements/
Как ставить игру на паузу? Например, чтобы показать меню паузы. Или залезть в инвентарь.
Через timescale? Или через прописывание паузы в каждом скрипте, который что-то делает в апдейтах, в каждом аниматоре?
Какие лучше практики?
Внутри скриптов куча разных функций, переменных и т.п
Обращаюсь я к разным скриптам из других скриптов так getcomponent<Scriptname>.мояФункци(нужное вставить или полчить).
Вроде всё норм и устраивает, но меня таит вопрос что как то можно реализовать классы вне стандартного мона, и типо их вызывать или чтот такое.
Нужно ли это? или продолжать ебошить как делаю?
Можно, нужно. Классы же это лишь способ структурировать всё твоё говно. То чему не нужно API юнити тем разумеется никакого монобихейвора не нужно. Есть же например static классы, к которым можно обращаться по типу, а не дёргать инстанс из каждой жопы.
Но ты давай, приведи лучше конкретные примеры где твоя текущая хуйня выглядит подозрительно. Мы посмотрим, подумаем и скажем что мы об этом думаем.
Если устраивает - то и не парься. Но в крупных проектах стараются избегать большого использования MonoBehaviour классов по двум причинам - на каждый бехейвор класс создаются два объекта: С++ класс с которым непосредственно работает движок, плюс C# обертка с которой ты работаешь, это все плохо сказывается на производительности в том числе из-за особенности реализации АПИ движка, второе - многопоточность внутри бехейворов невозможна.
Сукач уже 2020 на носу, а эти говноеды 2019.3 нк релизнули. Пиздец.
Пацаны, котята, помогите, как сделать увеличение скорости при таком 2д свайп контроллере:
https://pastebin.com/3NNuyWdQ
В скрипте понятно в чём ошибка и почему багует, игрок при каждом щелчке по экрану отлетает в сторону кратно скорости, но зато после этого движется ускоренно и плавно, как надо. Все другие способы которые я пробовал, делают движение либо ломанным, либо не точным.
С меня тонны нефти.
Для 80% классов нет никаких причин делать их monobehavior'ами. У меня как правило один моно для прикрепления функционала к объекту и ещё десяток для его реализации.
Стройная структура скриптов может показаться самодрочем и прерогативой крупных команд, но поверь мне, любая разработка более полугода превратит твои скрипты в спагетти, в которых ты сам не сможешь разобраться, если только не будешь постоянно следить за порядком. Потом будешь охуевать, пытаясь вспомнить смысл своих действий и переделывать десятки раз.
Как сделать мошн трейл эффект? Гуглятся только древние туториалы для спрайтов, для 3д нет
Даже китаец знает, как убрать загрузочный экран юньки. Ну, тот, где выбирать качество, разрешение экрана, кнопки настраивать. Какие ваши оправдания?
Я гуглил, там хуйня одна. Хороший только здесь нашел
https://github.com/edom18/Fur-shader-sample
Но он похоже с hdrp не работает, развили хуйни
https://www.google.com/search?q=unity%20fur%20hdrp ? вон там про енота было, возьми оттуда.
Это что качать весь проект с енотом чтобы вытащить шейдеры что ли? ДА ТЫ АХУЕЛ?
дык ведь для этого попенсорсные проекты и сделаны? наверняка если ещё чет в запрос гугла написать то можно найти шерсть енота уже выковыряной.
можешь свой шейдор сделать, https://roystan.net/articles/grass-shader.html вон полистай про няшную траву, думаю понятно как сделать шерсть глядя на это.
Зачем мне делать, если уже сто раз до этого сделали, и юнитеки много раз сделали, где фурьфайлы, вась? Какое же юнити свинособачье говно, эта хрень с енотом в июне вышла, пишет, что мы начинаем усиленно допиливать мех. Наверное, обосрался и умер, иначе что там можно столько хуярить. Опять на пол пути дропнули
дык енота вроде доделали, не? ну поищи кроме енота ченить, если лень его ковырять. наверняка уж что-то кроме енота найдется.
ну а самому делать - будет как надо тебе. у тебя там похоже какие-то особые фурфажеские запросы, наверняка ещё и не каджый мех понравится. нормально делай - нормально будет.
>наверняка если ещё чет в запрос гугла написать то можно найти шерсть енота уже выковыряной.
Да ты заебал своими догадками, нихуя там нет
>>631968
>у тебя там похоже какие-то особые фурфажеские запросы
Просто обычный мех как здесь >>631960
Короче качаю ракуна ебаного (10.7 свинособачьих юнити гигабайт) ради одного фурфайла. Их там в комментах просили выложите, ответом было - хуй вам за щеку
я думаю что ты пиздишь и уж найти какой-то шейдор шерсти с несколькими слоями можно без особых проблем.
http://wiki.unity3d.com/index.php?title=Fur&oldid=8730 даже на вики все это говно есть.
за 7 часов мог бы свой шейдор шерсти нарисовать, или заставить работать другой.
на вопрос не ответил. она и в юнити за пять секунд делается c URP. с HDRP скорей всего тоже, просто вместо того чтобы трусы рисовать с роботами надо недельку другую потыкать всё это говно. или что ты там, слишком занят? нет времени получить новые скиллы? надо рисовать аниме-трусы? что тебя на юнити то держит? пересаживайся на стул с шерстью.
>в юнити за пять секунд делается c URP. с HDRP скорей всего тоже
Что ты пиздишь, черт? То ссылки на гугл тупые постил, то еще какие-то догадки, ну перепиши этот >>631960 на HDRP за пять секунд и тысячам людей не нужно будет дрочиться с этим никогда. Но ты же не сделаешь, кудахтер, потому что там пиздец сложно и долго, а про пять секунд пизданул тупой школьничек внутри тебя, иначе это уже давно бы сто раз сделали. И в самой юнити
>надо недельку другую потыкать всё это говно
я тебе святой что-ли? если у меня найдется свободной неделька другая, или мне вдруг внезапно захочется овладеть HDRP то конечно я сделаю между делом тебе твой сраный шейдор.
я вчера, кстати, поковырял немного. там долго, но не очень сложно. я конечно удивился от того какой интересный шейдоркод выдала мне обычная PBR нода, но не то что бы там было что-то такого совсем уж совсем заоблачного. читабельно. даже комменты есть.
но сейчас я лучше всю эту срань с гидродинамикой поковыряю. это куда интересней.
вопрос остается открытым. зачем ты пердолишся с HDRP?
Затем что красивая картинка получается, и я не пердолюсь с ним. Я вообще не понимаю как такое может быть, чтобы было полно реализаций меха, и даже в официальной демке, но в итоге просто нету ничего рабочего. Они в блоге про этого енота про целый разрабатываемый инструмент говорили, чтобы шерсть расчесывать и карта создавалась, а сами в мари рисовали, но в большинстве случаев нужно просто мех по цветовой карте и чтобы вниз свисал, и маску элементарную. Все уже сделано сто раз. В еноте у них ебануться карт, кому это нужно вообще непонятно
имхо в жопу такую картинку, если вместе с ней такая цепочка проблем. проще наляпать графона. я вчера даже скачал последний превью билд, там до сих пор трава на земле с поломанным шейдором. одно дело когда пользуешься ECS, где всё в целом работает, но просто некоторого функционала не хватает и его можно допилить в процессе. а другое дело когда перед тобой пиздец и из вариантов у тебя либо ждать когда починят(и в процессе поломают то что сделали другие), либо пердолится и смотреть как всё это работает, либо надеяться что кто-то уже это сделал за тебя и его труды не превратились в тыкву. либо пользоваться шейдорной лапшой, где до сих пор нет ни тесселяции, ни возможности подёргать геометрию, нихуя. всё это звучит как сомнительное удовольствие, если тебе от юнити нужен только графон.
лол клёвый шейдор показал огромный сука. небось интересное чтиво на ночь.
я бы не твоем месте не надеялся большой поддержки того что до сих пор не вышло из превью. могу ещё посоветовать делать кота прямо в проекте с енотом на его версии юнити где всё работает.
>>632126
ты же уже тыкаешь этот инструмент лол. вон например я когда-то нацепил на болванчика юбку. выглядит нормас. если подольше потыкать то можно сделать красиво.
ВОТ! Вот ты-то мне и нужен, доброанон. Расскажи процесс, если не трудно. Я накидываю коллайдер на юбку отдельно от модели(хотя юбка по сути является чайлдом всего .fbx), накидываю на нее cloth, но при старте игры юбка почему-то отдельно улетает вниз, оставляя саму модельку. Скажи, пожалуйста, как это можно исправить? Что я не так делаю?
Кароче я присобачил к кости ту часть плаща, который по идее должен развиваться при ходьбе и он действительно при анимации стал двигаться вместе с моделькой, но, разумеется, не как плащ, а как жесткая планка. При накидывании cloth’а - плащ улетает вниз, а моделька стоит с голой жеппой. Понять бы как сделать правильно, эх.
какой процесс лол. кнопки нажал, членом покрутил, всё заработало. констрейны настрой, там кнопочка есть для этого. только учитывай что там из версии в версию ткань раз за разом ломают и ломают. если честно то хуй даже знает что и как делать чтобы не ломалось. иногда вертексы неправильно отображаются, иногда они, блять, перемешиваются, иногда всё просто взрывается.
на тебе экзампл, хули.
https://drive.google.com/open?id=1smUZfs8aemSkIjlQTOwRL1BnTax24DNg
Ебать и впрямь заработало с констреинтом. Я люблю тебя, анонче. Весь вечер ебся и тут выручил.
> из версии в версию ткань раз за разом ломают и ломают
Это смешно просто, ебаные козлы
А сам сидишь на 2018.1 и не можешь обновиться, пушто проект распидорашивает и проще сидеть на старой версии, чем чинить это всё потом.
https://www.raywenderlich.com/2573-unity-4-3-2d-tutorial-getting-started
Если нет, то что анончик может посоветовать вместо него?
надо допустим переместить юнит к цели плавненько
выходит надо получать расстояние до цели каждый кадр
если в апдейте это делать то будет лишняя нагрузка типа
а корутины я слыхал вообще вредно для здоровья
к примеру мне хотса передавать туда реф, а реф в корутину низя передавать
как делать вообще нормально чтобы?
Не поверишь, но я заебашил почти всю логику игры на корутинах, внутри каждой вызывается гора функций, даже апдейтом не пользуюсь, тупо при старте запускается одна из неё по логике всё остальное расставляется, БРАТ ЖИВ, ЗАВИСИМОСТЬ ЛЮТАЯ.
мне нравится необычный подход и интересная реализация
А через корутину нагрузки от перемещений значит не будет?
Корутины тяжело дебажить и от их избытка код превращается в ебаный спагетти.
Если нужно каждый фрейм считать расстояние, то ты один хуй будешь считать его апдейтом или корутиной. Функционально шо то цикл, шо это цикл, но аптейд органичен для перемещения, а корутина костыль какой-то. Кешируй расстояние если это возможно и не парься.
Если ты делаешь перемещения одного персонажа, то переставай выебываться. Если у тебя два десятка персонажей, которые перемещаются очень редко, а остальное время апдейтятся вхолостую, то тоже ок.
Если количество персонажей доходит до сотни, тогда уже думай об оптимизации. А вообще юзай навмешагента или сделай менеджера, который будет раскидывать задания на перемещение для активных персонажей.
вот я так сделал на корутинах сначала, а потом какие-то смутные сомнения закрались и пошёл мозг ебать и переделал, но стало только хуже, так что теперь думаю обратно переделать, просто боюсь если абузить корутины то потом можно наткнуться на какие-нибудь скрытые неприятности
>>632820
>А через корутину нагрузки от перемещений значит не будет?
так от корутины получается нагрузка только во время перемещения, а от апдейта всегда
хотя я слыхал что корутины ещё мусор плодят
>так от корутины получается нагрузка только во время перемещения, а от апдейта всегда
Пишешь в начале апдейта:
if (NotMoving)
return;
И у тебя нагрузки - проверка одной булевой переменной. Как я написал, если у тебя меньше сотни таких апдейтов - разницы ты не почувствуешь. Если сильно угораешь по оптимизации, то вырубаешь нахуй моно скрипт, пока он не должен работать.
Ты должен понимать, что ты не сможешь написать код быстро и понятно и эффективно. Придется искать баланс. Чаще всего недостижим вообще ни один из трех показателей.
Сравнивая корутины и апдейты тебе нужно оценить:
- Быстродействие. Чаще всего это нужно либо в детальных симуляциях, либо с сотнями одинаковых объектов, либо в случаях, когда ты пишешь катастрофический говнокод. В остальных случаях результата ты не увидишь. Оптимизации нужно делать тогда, когда они нужны.
- Генерация мусора. Оно, в отличие от времени выполнения, довольно быстро выходит из-под контроля. Пустые апдейты не генерируют мусор, но слегка замедляют время выполнения, а корутины могут создавать мусор, а могут не создавать.
- Читабельность. Если ты считаешь, что вызовы туда-сюда корутин выглядят понятней - то вперед. Иначе - юзай апдейты.
- Поддерживаемость. Опять же, я не в восторге от цепочек вызовов корутин, в то время как апдейты более-менее независимы друг от друга. Проще отладка и допил.
- Простота написания. В ряде случаев корутина помогает легко и быстро создать сложную механику, в остальных - нет.
Анализируя эти простые параметры и принимая осознанное решение ты создаешь адекватную архитектуру игры, чтобы через год не хуесосить самого себя, когда возникнет необходимость дописывать или отлаживать какой-нибудь древний модуль.
А важнее всего пилить модули под себя, так, как тебе удобней и приятней, иначе какой смысл вообще заниматься разработкой того, что тебе не по душе?
такие то микро-оптимизации!
извлечение квадратного корня не такая тяжелая операция чтобы творить такую хуйню. если хочется поаутировать то просто сохрани дистанцию в приватную переменную.
алсо корутины полезны для того что они делают. а делают они много что. например, их можно сохранить и передавать одну корутину из другой корутины делая таким образом процедурные цепочки действий с таймерами.
>>632817
гвозди микроскопом забиваешь. когда случится пиздец - будешь выть.
дело не в оптимизации а скорее чтобы удобно пользоваться было по жизни, поддерживаемость там, вот это всё.
не особо хочется базовые какие-то вещи начинать со всяких костылей на хитровыебанных корутинах, оно хоть и выглядит всё нормально с ними и довольно просто, да и так на вскидку должно нормально работать, но я же чую что потом вылезет какая-нибудь дикая хуйня
главное хочется попроще сделать, так что попробую ещё обойтись без корутин где можно
спасибо за советы
>>632811
Корутина запускается в мейн треде, так что вместо оптимизона ты получаешь головку от хуя. Пили уже на джоб системсах.
>интересует рогалик
Татрикс? Надо было доёбывать его, пока он треды вёл. Да и там лисп, такое себе.
>помню. я бы почитал
Ты тот единственный анон, который читал? Лол.
>>632965
Ну тогда надо хуярить через апдейт. Корутина по сути тот же апдейт. Вообще главная проблема всех туторов по юнити это то, что всё через монобех\корутины\паблик переменные. Накидать 20 строчек и минимальный функционал так проще всего, но расширять чуть позже просто адовый пиздец. Возможно в новых туторах что-то поменялось, пару лет уже не читаю их.
Даже когда ты делаешь ранний выход в начале апдейта это превращается в 4 проверки на каждый фрейм, а не 1 - юнити перед вызовом апдейта делает проверки жив ли объект. С корутиной лучше - один раз в начале генерируется класс который захватывает переменные используемые в корутине, соответсвенно потери только по памяти совсем незначительные.
Проблема с корутиной что она зависит от активности гейм обджекта - умер или выключился объект - корутина не дошла до конца, а ты думаешь что дошла.
>Татрикс? Надо было доёбывать его, пока он треды вёл. Да и там лисп, такое себе.
а татрикс то тут причем? он успешен по меркам раздела. тот самый рогалик который оставил след в гд. я до сих пор помню его прекрасный тред. и дрокона. были времена!
>Анонимус не забывает и не прощает.
Охуеть же ты вспомнил. Этого рогалика я иначе, как ААА-рогаликом и не называю. Олсо треды в гд были не единственными его тредами, в тд он тоже побывал. И не сравнивай меня с этим шизиком, у меня всратый будет код, а не арт, тут шиза другого толка.
>.2
Там точка три выходит. И это - пиздец? Я просто охуел из-за стены плача на форуме. Народ реально уже хоронит юнити нахуй. Причём не долбоёбы с двача, а люди, которые юнити пользовались на самом деле.
https://forum.unity.com/threads/2019-3-entered-the-final-stages-of-beta-testing.792882/
Если вкратце, народ жалуется на то, что новые "готовые" версии охуеть, как бажные и сырые, производительность от релиза к релизу только падает, некоторые жалуются, что багрепорты закрываются с причиной "не смогли воспроизвести" раз за разом, чуваки с несколькими тысячами сообщений заявляют, что перекатываются с юнити, ибо заебло. Нереально много воя по поводу неисправленных багов, вой на Ричителло, который пизданул, что игры похуй, юнити хочет рыночек софта для визуализации и обучения. Да ещё и в 2020 собираются торговать акции фирмы на бирже без ограничений. Я читаю всё это и просто охуеваю. Там реально бунт нахуй.
Посмотри анонсированные фичи в Юнити за последние 3 года,
и посчитай из них тех что вышли из беты. Анонсируется дохуя - делается нихуя, сюда dots, render pipeline, shader graph, ui elements, incremental gc и прочее, один маркетинг остался. Сами инженеры в Юнити не имеют игровых проектов, в отличии от того же Анрила, и поэтому часто не видят очевидных проблем с движком и редактором - что выливается в например UI систему которую перепиливают каждые пару лет, анимации с которыми каждый ебется как хочет, и постоянные вопросы с производительностью.
6 лет лабаю на Юнити и кажется ухожу в этом году, дальше расти с этим движком очень сомнительное вложение труда.
Видимо, где-то в 2014 к ним прибыл "эффективный менеджер", который устроил полнейший хаос. Ты ещё не упомянул охуительную историю с новым мультиплеером(UNET), который они в один прекрасный момент объявили устаревшим и закрыли нахуй. И вроде как теперь они по новой всё делают в сотрудничестве с какой-то там компанией.
>сюда dots
В дотс есть поддержка анимаций и скиннед мешей! Ретаргетинг! Чтобы установить - нужно включить пакет. В менеджере пакетов этого пакета нет. Вообще пакеты ёбаное зло.
>кажется ухожу в этом году
Только куда, даже со всеми проблемаи юнити стабильнее уе4, который у меня крашится чаще, чем юнити серит ошибками в лог.
>>633483
В 2014 к ним пришёл прямиком из ЕА новый гендир, мистер "я хочу тебя оттрахать" Джон Ричителло.
Если совсем в фундамент хочешь упороться, то почитай Game programming patterns. Половина книги - лирика, которую тем не менее интересно читать, но и полезных приемов хватает.
А конкретно по юнити - годноту надо по крупицам собирать из отдельных туториалов и постов.
>>633478
Как по мне то с первого взгляда понятно что оно обречено на вымирание.
Вот открыл я этот ваш Юнити и такое чувство что это какой-то бутафорский движок.
Как понимать что у тебя нет возможности создать на сцене объект своего класса? Это полный пиздец.
Возможность наследовать от гейобжекта этого ебаного специльно закрыта. Как это вообще понимать? Как плевок в лицо?
И чё я теперь должен ебаться с этими сраными компонентами? Нахуя? Потому что 10 лет назад это была модная молодёжная концепция?
Нет спасибо, я буду писать так как МНЕ удобно, раз в Юнити такой возможности нет, то мне с ней не по пути.
мимо-медленный-вкатывальщик
>будет работать абсолютно так же
Дык компонент на сцене не создать так же как объект.
А если для этого придётся пердолиться с какими-то огромными косталями типа ЕЦС, то чем это вообще лучше ебли с компонентами? С ЕЦС ещё разобраться надо, не придётся ли на каждую new Zalupa() там писать по десять классов ещё чего-нибудь?
...Может действительно разъебаться с ЕЦС? Стоит оно того?
>Потому что 10 лет назад это была модная молодёжная концепция?
Ты пишешь про устаревшие концепции, при этом просишь возможность наследования. Ты чё — ебанутый нахуй? Как раз наследование это рак ёбаный для дебилов. Composition > Inheritance. Если ты таких элементарных вещей не понимаешь, то как можешь рассуждать о движке? Ты же хуесос.
1. Как раз композиция это и есть устаревшее говно для даунов. Юнити тому наглядный пример.
К тому же композиция и наследование разные вещи абослютно. Они сравнимы так же как тёплое с мягким.
2. Если ты таких элементарных вещей не понимаешь то как можешь рассуждать о движке?
3. Хуесос - твой дед.
какая нахуй разница в сцене ли находится твой объект лол. иерархия сцены это просто няшный способ отображать че ты там сделал.
если тебе API юнити не нужен - не пользуйся им. если он тебе нужен - пользуйся компонентами, или ещё какой залупой. у тебя есть возможность создавать объекты, за тебя дергают твои методы, юнити рисует какую-то хуйню в сцене какую прикажешь. как ты там всё это между собой свяжешь абсолютно похуй. что тебе ещё надо то?
>>633531
>Как раз наследование это рак ёбаный для дебилов. Composition > Inheritance
ебаный рак это считать что одно превосходит другое.
>можно еще потрахаться с ЕЦС
GameObject - мы создаём на сцене объект и навешиваем на него компоненты. Этот подход устарел, так что мы переходим к
ECS - мы создаём на сцене объект и навешиваем на него компоненты! Инновации нахуй. Ну, поддержки юнити редактора в ецс не завезли, так что эти объекты не отображаются в иерархии. Поддержку скиннед мешей завезли, но только через ручную правку конфигов. И там не будет меканима, аниматора и вообще нихуя. Старые геймобъекты были переусложнены невыпиливаемыми вещами, например, трансформами. Ну, на новые энтити тоже нужно лепить подобные компоненты, если вы собираетесь двигать свои объекты или хотя бы рендерить. Только писать их нужно вручную. Кстати, раз уж вы пишете свои компоненты с флоатами, то не забудьте переключить билдинг на il2cpp, потому что в моно есть баг, который ебёт скорость работы с флоатами вдвое. Ну как в моно, в моно его пофиксили 2 года назад через флаги компиляции, но юнити всё некогда. А ещё с ецс весь ваш код превратится в плоскую лапшу и вы проклянёте того долбоёба, который это всё придумал. А потом начнёте писать фабрики, ООП-абстракции и т.д потому что с чистым ецс невозможно работать.
ебать байты ты и в шарпе можешь лол.
всегда зависит от того что ты хочешь иметь быстрым и как ты это хочешь сделать быстрым. никто не мешает тебе пользоваться всей той хуйней что предлагает юнити чтобы всё взлетало и летало. LLVM компилятором, многопоточностью, хуйнёй-муйнёй, шейдорами там вычислительными если уж совсем что-то быстрое надо.
>многопоточностью
Вот завезли джоб системс для удобной многопоточности, охуенно? Или не особо? Вся хуйня, которая касается юнити апи всё равно происходит в однопоточном режиме. Плюс синхронизация потоков через мейн тред. Ты как бы можешь себе сказать, что у тебя быстрая многопоточность, но как бы это и раньше было точно так же - вручную треды создавал и по тем же принципам работал. Есть реально многопоточная вещь, ParallelForTransform, которая ебёт трансформы в действительно многопоточном режиме. Кстати, эту фичу обещают выпилить.
>шейдорами там вычислительными
Вычислительные шейдеры есть в легаси рендеринге. А он устарел и скоро будет выпилен. Есть они в SRP? Нет. Как и геометрические шейдеры. Кажется, там уже почти прикрутили тесселяцию и обещали материал проперти блок, ну, из старого рендера. Да, SRP крутой, но в нём меньше фич и он медленнее старого.
> тру сишники посмеиваются
Net.Core работает с той же скоростью, что и кресты, тут уже как бы и похуй, чем байты ебать.
>какая нахуй разница в сцене ли находится твой объект лол
Подходит как-то Петька к Василиванычу и спрашивает:
-Василиваныч, а что такое НЮАНСЫ?
А Василивааныч и говорит:
-Снимай Петька штаны.
Петька снял...
Василиваныч достает хуй и сует Петьке в жопу...
Вот смотри, Петька, у тебя хуй в жопе, и у меня хуй в жопе, НО ЕСТЬ НЮАНСЫ!
а потом ты такой пишешь волшебный [BurstCompile] и обана у тебя как бы и шарп а как бы и не шарп! все летает и улетает. и теперь уже ты смеешься над ними.
вообще конечно если билдить в il2cpp то вся эта байтоебля не особо то медленней. проверять производительность в редакторе это такое.
>>633550
>Вот завезли джоб системс для удобной многопоточности, охуенно? Или не особо?
Ну так то многопоточность и до этого была. Не так сильно отличается чтобы как-то выгодно выделятся. В целом нормас. Пользоваться можно. IJobParallelFor мне например нравится, чтобы пройтись по массиву и при этом поставить это в очередь за другим джобсом заебись. Немножко меньше гемороя с зависимостью одного потока от другого.
Но конечно JobHandle.IsCompleted дрочить чтобы узнать закончилось оно там или нет тоже такое. Хотелось бы нормальные каллбэки.
>Плюс синхронизация потоков через мейн тред.
Да, вот это конечно хуево сделали. Некоторое говно вроде ИИ по хорошему надо вообще не пускать в основной поток а где-то в паралельном держать всё время и ещё и оттуда в другие потоки пихать. Джобсы такое не дают. Но с другой стороны это не так и часто надо, а обмазывание всего подряд многопоточностью они упрощают. Плюс пихают джобсы в всё остальное что делают и как-то связывают все это между собой. Сунуть ECS в потоки и правда довольно просто.
>Вычислительные шейдеры есть в легаси рендеринге. А он устарел и скоро будет выпилен. Есть они в SRP? Нет.
Никуда они не делись и всё так-же работают. И сомневаюсь что перестанут. Я то про https://docs.unity3d.com/ru/current/Manual/ComputeShaders.html
Хотя когда я последний раз проверял HDRP мне и правда не дали сделать Graphics.Blit. гондоны.
Вообще на самом деле никуда старое не делось, можно так-же из шейдорной лапши скомпилировать себе шейдор а потом дописать к нему внутри недостающее. Просто пиздец как неудобно.
Пиши на ассемблере, хуле.
Вся хуйня с высокоуровнемыми абстракциями придумана для того, чтобы писать медленный код быстро. В 95% современных игр неважно, твой расчет вектора произойдет за одну наносекунду или за четыре. Зато удобная работа с векторами позволит тебе за неделю написать механику без изобретения велосипедов, на которые ушло бы полгода.
Мы не в прошлом тысячелетии живём, сейчас фокус смещен в сторону поддерживаемости и переиспользуемости кода, а не его скорости. И это круто.
вот кстати с LLVM компилятором в юнити впихнули возможность пользоваться SIMD инструкциями не через жопу. хопа и быстрые векторы! хорошо сделали.
>>633565
какая толерантность может быть к людям которые спрашивают у людей вопросы до того как спрашивают их у машин? в гугл то задавал твой вопрос?
лол ну отключи гравитацию. или добавь коллайдеры.
Так-то похуй, кто там дрыснул. В net core есть ещё киллерфича tiered compilation, с ней разница в скорости с крестами на уровне погрешности. Хотя памяти отъедается больше.
>BurstCompile
Эта хуйня не дружит со сложными типами.
>>633561
>Ну так то многопоточность и до этого была.
Так о том и речь. По-моему, кастомные менеджеры даже не медленнее, чем джоб системс.
>обмазывание всего подряд многопоточностью они упрощают
Ещё бы редактор обмазали этим говном, чтобы небыло локов при компиляции. Кстати, ебать же долго собирается на 2019.3.
>можно так-же из шейдорной лапши скомпилировать себе шейдор
Можно даже руками написать подходящий под SRP шейдор. Там требуется от шести проходов для всей малафьи, на первом пике как раз шейдер под hdrp. А, погоди, в SRP пайплайне нет доступа к трис стрим и всё-таки нихуя, нельзя. Ты такой думаешь "бля, как так-то?" идёшь на юнити форум, а тебе говорят - сасай-кудасай, писать шейдеры руками нельзя, используйте шейдер граф. А в нём нет нужных нод, нет людской возможности пилить кастом ноды, а в кастом нодах нет доступа к нужным апи, нет возможности пилить шаблон для генерации шейдера? Сасай-кудасай.
>И сомневаюсь что перестанут. Я то про https://docs.unity3d.com/ru/current/Manual/ComputeShaders.html
В SRP это не компилируется, смотри второй пик, примитивный геометрический шейдер в hdrp и без srp соответственно.
>Graphics.Blit
Используй рендер в текстуру. Кстати, если ты будешь рендерить в текстуру в анлит шейдере, то не сработает. Почему? Да хуй знает.
Происходит смена погоды - начинает идти снег и все объекты покрываются снегом. Или идёт дождь и всё становится мокрым.
Смена материала по скрипту, спаун объектов с другими текстурками? Как-то очень плавно происходит, с переходом.
Вообще насколько хуево строить свои объекты так ?:
public class Govno {
GameObject view;
Vector3 position;
someData model;
void update на делегате, крутящемся где-то в мастер сцене
}
игнорируя сцены, зато имея доступ к объекту вне сцены и юнити манямирка ?
Накажет ли меня юнити каким нибудь анальным подводным камнем где-нибудь в середине разработки?
Есть ли примеры, которые юзают юнити только как рендер своего говна?
(знаю например, что юнити навмеш можно грузить и юзать без привязки к сценам, правда пока не понял можно ли разные навмеши одновременно или только один статик на всю игру)
Юзаем в достаточно крупном проекте такой подход, гейм луп действительно на отдельном делегате, но мы стараемся и от него избавится юзая C# таймеры где это возможно. Подводных немного, главное не забывать чистить говно со сцены которое ты туда вытаскиваешь, т.е. в твоем примере надо не забывать вызвать дестрой для view, простого зануления ссылки мало. Но вообще рекомендовать подход не стал бы, из плюсов только прозрачность структуры и упрощение отладки.
Чисто для отделения view от логики игры?
Так-то стандартная практика (для нормальных разработчиков по крайней мере) создавать менеджеры и объекты чистыми классами и цеплять к объектам там где надо.
У меня по сути все классы игрового цикла существовали в астрале и не были привязаны к геймобжектам, а просто дергали ивенты и вызывали друг друга.
Другое дело - геймобжекты с логикой. Делать отдельный класс и как-то его цеплять выглядит чрезмерно громоздким:
- В одном случае у тебя класс, представляющий объект, наследуемый от моно, прицеплен к нему и способен вызывать любую внешнюю логику, какую назначишь.
- В другом случае у тебя точно такой же класс, но "чистый", и тебе нужно дополнительно искать объект в сцене, сохранять ссылку на объект, проверять существование объекта и настраивать логику при смене сцен.
> В другом случае у тебя точно такой же класс, но "чистый"
Вы забываете, коллега, самую главную плюшку такого подхода. Если игровая логика на чистых классах, дёргающих объекты движка из астрала, то она не привязана к движку и в любой момент его можно сравнительно безболезненно сменить. Или даже вести разработку на двух движках одновременно. Скажем, один для пека, другой для консолей.
Сомнительный плюс, поскольку 99% проектов не меняют движок в процессе разработки.
Значит ты скорее всего лишь намеренно усложняешь структуру проекта ради потенциальной возможности, которой никогда не воспользуешься.
А если воспользуешься, то гарантированной ебли все равно будет достаточно. Редактор предоставляет очень много возможностей - таги, слои, методы вроде OnTriggerEnter, рейкасты, физика... Это все придется адаптировать под новый движок, ну или не использовать совсем и изобретать собственные велосипеды, неоправданно увеличивая объем работы.
Мелкие проекты, пилимые в одиночку, не имеют такой долгий цикл разработки, чтобы закладываться на смену движка.
Крупные командные проекты переносить вообще нереально.
Единственный вариант, когда я вижу такой подход оправданным - если ты собираешься 10 лет пилить игру мечты в одиночку. Тогда уж чего мелочиться, лучше писать игру без сторонних движков, как какой-нибудь dwarf fortress.
Создал новый проект для андройд, не могу настроить обработку нажатий.
Код точно как на картинке, только вместо Дебаг.Лог - нормальное действие.
У слову, код на второй картинке работает как надо, но только если нажать мышкой. Телефон же просто игнорирует любые прикосновения.
>тебе нужно дополнительно искать объект в сцене, сохранять ссылку на объект, проверять существование объекта и настраивать логику при смене сцен
зачем искать, если ссылка есть?
плюс я могу обьект няшно создать конструктором (от которого у монобехевиора очко сжимается) и даже вводить параметры (!)
Это реально очень круто, я сразу начал пускать слюни на такой концепт, но вот проблемы, которые придется решать:
1. Получать ссылку на геймобжект. При его ручном создании ещё ок, но если его надо находить самостоятельно внутри сцены...
2. Отслеживать жизнь геймобжекта. Гарантировать, что он не будет уничтожен в рандомный момент или писать обработку уничтоженных объектов.
3. Ебаться с очищением/наполнением сцен при смене сцены.
4. Самый большой минус - плохая поддержка инспектора. Как ты будешь настраивать параметризацию скриптов?
Я это вижу так:
- Сохраняем ссылки на префабы внутри моно или scriptableobject. Параметризация сохраняется там же.
- Создаем builder, наследуемый от моно и располагаемый внутри сцены. Он содержит ссылки на вышеуказанную инфу.
- Он эти данные данные инжектит в наш новый чистый класс объекта.
- Наш чистый класс сохраняет данные, и сам создает и отслеживает жизненный цикл геймобжектов сцены.
Получится очень крутая структура с точки зрения программирования, но количество лишних действий по сравнению с обычным моно (и будущая поддержка всех этих дополнительных классов!) вызывает головную боль.
Что, в объем-то и писал анон выше, практиковавший нечто подобное.
>Эта хуйня не дружит со сложными типами.
Чтоу? С какими там типами она не дружит то? Нука пример дай.
>Так о том и речь. По-моему, кастомные менеджеры даже не медленнее, чем джоб системс.
Смотря о чем речь. А) когда потоки менеджит одна и та-же хуйня то результат будет явно лучше. Б) джобсы быстрей в общем и целом. в частности меньше оверхеда при создании джобса по сравнению например с тасками.
>SRP
В этой части поста я уже не уверен что ты пишешь. под SRP подразумеваешь URP/HDRP? Так как SRP в целом просто же позволяет тебе из шарпокода управлять тем че там как рисуется. Можеш хоть 2CHRP написать на нём, сделать свой RP с игрищами и блудницами.
>А, погоди, в SRP пайплайне нет доступа к трис стрим и всё-таки нихуя, нельзя. писать шейдеры руками нельзя, используйте шейдер граф
Wut? Да есть там всё. Открыл юнити, сделал проект в URP, сделал простенький шейдор который лезет в тристрим. Первый скриншот. Работает нормас. Ну как нормас, теней нет, но рабтает.
>В SRP это не компилируется, смотри второй пик, примитивный геометрический шейдер в hdrp и без srp соответственно.
Чтоу? Вот тут ты уже откровенно пиздишь. Сделал HDRP проект, сунул старый добрый Result[id.xy] = float4(id.x & id.y, (id.x & 15)/15.0, (id.y & 15)/15.0, 0.0); он нормально скомпилировался и диспатчнулся. Второй скриншот.
>>633694
а ответ то прост - материал блендит одно с другим цыферкой.
>>633706
имеешь все возможности получить по лбу черенком от граблей в виду интересного способа юнити уничтожать объекты. как бы когда ты геймобжект задестроишь то по логике шарпа он не перестанет быть null. а по логике юнити - станет. поэтому юнити просто скажет тебе что твоего геймобжекта нет при попытке к нему обратится.
ну а так нормас. подводных камней нет. я и сам люблю так делать когда хочется связать например массив структов и какие-то геймобжекты в сцене.
>>633723
>Чисто для отделения view от логики игры?
нахуй надо. лучше комбинировать подходы. то что абстрактно пускай себе сидит отдельно, то что взаимодействует через сцену разумеется пускай там и находится.
>С какими там типами она не дружит то? Нука пример дай.
Строки например, лол. По факту он дружит только с нейтив аррай, а всё остальное не ускоряет.
>под SRP подразумеваешь URP/HDRP?
Очевидно, что да.
>Можеш хоть 2CHRP написать на нём
Нет, не могу, потому что нет никакой документации.
>Работает нормас.
Хуй знает, у меня ни один шейдер под старый пайплайн не компилируется под новым. Да, возможно, если написать ещё один шейдер на 30 тысяч строк, то я смогу получить результат, которого добивался под старым рендером за 30 строк.
Ещё решил потыкать дотс анимацию, скачал самплы, а там 8-20 фпс. Ну ясен хуй, кто же в редакторе производительность смотрит? Скомпилировал всё, значит, запускаю и сразу краш. Заебись вообще, чётко сделали.
Посмотрел я тут видосик про классы, и понял что это пиздец, нахуй нужны свои классы если всё можно пихать в ванильный монобехав?
Офк для одного инди разработчика, не для команды и т.д.
Есть ли проблемы если не делать свои классы, а пользоваться одним монобеах с кучей своих функций?
Подводный камень состоит в том, что не выстраивая стройную архитектуру, ты превращаешь игру в спагетти, если она сложнее тетриса. Ты столкнешься со следующим:
- Захочешь добавить функционал в старый класс спустя полгода и охуеешь разбираться, что и зачем в нем понаписано было полгода назад.
- Хуй что вырежешь или модифицируешь, поскольку не подумал о декомпозиции классов, и теперь у тебя любое изменение тащит за собой десяток изменений в смежных классах.
- Заработаешь боль в глазах, просматривая стены кода в здоровенных монобехах, где все свалено в один класс, вместо отдельных модулей.
Я открыл для себя, что грамотная архитектура проекта при разработке в одиночку даже важней, чем при работе в команде. Ибо ты должен сам держать в голове все механики игры и взаимодействия между ними. Если они превращаются в мешанину, ты теряешь контроль над разработкой и начинаешь городить костыли на костылях, пока все не сломается к хуям.
У кого-то такое было?
Попробовал менять о 5 до -5. Обьекты находятся на 0, кнопки на -1, попробовал ставить на 0, -0.5 — не помогло.
Алсо обнаружил что если у Canvas поменять Render mode с Overlay на Camera или World Space, и назначить туда камеру, то кнопочки становятся невидимы уже в самом редакторе. Обнаружил что в этом режиме можно указать расстояние от камеры до Canvas, разместил все так что UI находится перед объектами, и точно в поле зрения камеры (обьекты на 0, кнопки на -1 (9 единиц от камеры), Depth -5), не помогло. Сама камера находится на -10.
Там есть только Default layer, попробовал слой самого canvasа поменять с UI на Default, толку никакого.
Проблема скорее не в том что мне нужно UI поверх обьектов показать, он и так находится поверх обьектов, и насколько следует из описания, в режиме канваса Overlay, UI должен отображаться поверх всего, как наклейка на экране. Проблема в том что даже если убрать все обекты кроме кнопок UI, в камере UI не отображается вообще. А в режиме Screen Space Camera, UI перестает отображаться даже в редакторе.
Я перешел на 2019 и отхватил две недели ебалова с тем что Amazon SDK не работает на андройде, даунгрейдится уже было поздно. https://github.com/aws/aws-sdk-net/issues/1286 Лучше бери LTS
Чтобы этого не происходило, есть идея запилить панель-заглушку уровня "Loading please wait", которая будет делать SetActive(false) после получения ответа от гуглплея. Как это реализовать?
Да, я именно так и делаю. Только картинку не прозрачную, а с имитацией загрузки.
Вопрос в том, куда лучше воткнуть деактивацию заглушки. В GooglePlaySaving залезать немытыми руками не хочется лишний раз. Пока думаю сделать так: bool "загружено" при старте false, в data он true, получив значение true он убирает заглушку при следующем апдейте. Логично?
В душе не ебу что у тебя за архитектура, лучше всего проверку делать корутиной раз в сек, или сколько там нужно(по ресурсам в отличии от апдейта намного лучше), а еще лучше если сам ответ с сервера единожды вызовет нужную функцию без каких либо проверок.
Вариантов на самом деле думаю можно бесконечность придумать.
Задаю скриптом в Start параметры, которые должны поменять у Area Effector. Когда играю в этой сцене- все ок, скрипт задает нужный параметр в Area Effector.
Но когда перехожу в эту сцену из других сцен- настройки из скрипта не применяются.
Что это вообще значит? Старт же вызывается как раз при старте сцены. Не понимаю.
"Огромное количество" это растяжимое понятие. Сколько объектов надо двигать, чтобы заметить разницу? Один, два, тысячу? И вообще - будет дохуя объектов, но управляемых менеджером, без скриптов на объектах. Выиграю ли я что-то, использовав ецс? Или затраты на сам рендер будут настолько высокими, что уже как бы и похуй? Вообще я вижу, что надо вкатываться в ецс, но пытаюсь найти отмазы.
>>634664
Так-то я его поковырял и он реально сырой, но ведь игра будет делаться не полчаса, а за год-полтора многое изменится.
Уже посмотрел ряд туторов и общие представления о юнити и c# имею.
Если ты не из тех, у кого атрофировалась способность читать, то рекомендую любую книжку по юнити для начинающих.
Потратишь на нее пару дней или неделю, если будешь вдумчиво выполнять упражнения, но зато познакомишься с большинством важных систем, научишься в казуальщину и заполнишь все фундаментальные пробелы. Туториалы обычно не способны глобально охватить все и сразу.
Обычно анон игнорирует этот совет и ебется с простейшими задачами, изобретая велосипеды, а в юнити дохуя уже встроено за нас.
Если мне не изменяет память, то на официальном сайте юнити полно видосов как раз по созданию казуалок разных жанров. Смотри их неделями, пока не начнёт тошнить.
Там и крутить ничего не надо все по дефолту ахуенно выглядит, каким тупицей нужно быть таким как ты
Я читал первое издание Unity in action. Сейчас оно довольно старое, но недавно вышло второе издание.
Не скажу, что был в восторге, но приличную книгу по юнити вообще найти нереально. В принципе неплохо, если нужно изучить азы работы с юнити и разобраться в том, как делать простые 2д и 3д игры.
Как (возможно ли) сделать, чтобы анимация от первого и 3 лица были разные?
Как в кс, что перезарядка от 1 лица чёткая, а со стороны ты просто руками машешь?
С меня как всегда благодарсвенное нихуя
мимо хвастунишка
Я знаю, что его можно сделать одной строчкой в скрипте, но это лишние Update'ы и необходимость лепить скрипт на каждый объект.
Частицы, значит, есть, а биллборда - нет? Создавать ParticleSystem с одной частицей просто для отрисовки спрайта в определенной части сцены? Или ручками подгонять каждый объект? Они там шутят?
>Но если проект не супер громозский, думаю и скрипт с этим справится, особого загруза не будет.
Конечно справится, он нагрузки даже сотни билбордов не заметит.
Проблема в другом. Я ярый противник лишних действий.
Например, я не нашел встроенного способа рандомизации анимации, скажем, отсрочить старт на рандомное количество миллисекунд, чтобы рассинхронизировать объекты. Пишется также в одну строчку, а в итоге лепится к каждому анимированному префабу.
Автоматизация цепляния ScriptableObject'ов к менеджеру городится через костыли и Resources, а всего-то нужно автоматически выгружать все файлы из указанной папки. Или каждый объект создавать ручками, цеплять к менеджеру ручками и проверять дубликаты ручками.
В итоге если я проебу часть проекта или префаб сам помрёт, будет настоящей болью вспоминать, какие таги цеплять, слои, полдюжины monobehaviour плюс настройки... Не говоря о внешних менеджерах, куда этот префаб не забыть прикрепить.
Поэтому я горю каждый раз, когда встречаю очередную, казалось бы, простую штуку, которую приходится самому делать через костыли и помнить о ней.
Это какой-то баг или фукнционал еще недоступен? 2019.2.17 если что. По докам пакета вроде как все должно работать. Сам Unity Remote в плеймоде отрабатывает.
Подскажите, пожалуйста, что мне делать.
Пытаюсь поставить якори на то, что находится под Content (вроде, child называется, Button, Text TMP, Panel), но эти стрелочки не хотят меняться, они просто остаются сверху слева. Если выбираю Stretch у якорей подобъектов, тогда объект вообще выворачивается на изнанку.
При этом в Content пишет ошибку как на 3 пике.
Вертикальная работает, всё остальное работает, но горизонтальную никак не могу нащупать. Перепробовал все доступные оси. С самим падом всё нормально.
На других падах пока нет возможности проверить.
У меня сейчас скрипт который спамит шарики каждую секунду( не помню через какую команду) и префаб в котором скорость.
Как эту проблему решить самым простым способом? По сути ведь это нужно в любой ендлес игре
Будешь на каждые 30 секунд делать новый метод?
Проще так:
[SerializeField] float speed = 10;
[SerializeField] float difficultlyTimeStep = 30;
[SerializeField] float difficultyMod = 1.1f;
А дальше на скорость ссылаешься не напрямую, а через метод:
GetSpeed()
{
int steps = Time.realtimeSinceStartup / difficultyTimeStep;
return speed * Mathf.Pow(difficultyMod, steps);
}
Метод каждые 30 секунд возвращает скорость на 10% выше прошлой. Причем параметры настраиваются.
Что-то у меня твой метод не сработал, хотя вроде все поменял что надо. Сделал так как ниже написал. Теперь пытаюсь сделать так чтобы обновлялся таймер, а то когда я перехожу на сцену геймовер и начинаю с нуля у меня скорость остается прежней.
if (Time.time > 5)
{
transform.Translate(Vector2.down currentSpeed 1.2f Time.deltaTime);
}
transform.Translate(Vector2.downcurrentSpeed Time.deltaTime);
if (Time.time > 20)
{
transform.Translate(Vector2.down currentSpeed 1.4f Time.deltaTime);
}
transform.Translate(Vector2.down currentSpeed Time.deltaTime);
У тебя таким образом получается 14 строчек кода, которые делают одно и то же, при том, что обрабатывают они только первые 20 секунд. Если захочешь получасовую сцену делать, будешь скрипт на тысячу строк писать просто для падения шарика?
Тебе нужно это дерьмо либо обернуть в цикл в 2-3 строчки, либо написать функцию зависимости скорости от времени, как показано выше. А лучше позадрачивай чисто шарп, за теми же уроками далеко на Ютуб ходить не надо. Очень много времени сэкономишь.
Сам как то интересовался, материал выше начального-среднего уровня очень сложно найти. Вот парочка
http://www.squidi.net/three/
https://catlikecoding.com/unity/tutorials/
Сейчас думаю может свой блог/канал запилить, правда не уверен насколько востребовано будет в русском сегменте, а мой англ как у индусов.
У меня игра в которой больше и не продержишься. Но вообще ты конечно прав надо подходить системно а не расставлять костыли.
Я открывал уроки по сишарпу и там немного другой язык если не в юнити, но попробую еще раз. А так я посмотрел немного туторов и сейчас просто сижу и пытаюсь понять каким образом добавлять простые вещи а затем гуглю и сам пытаюсь сообразить как это закодить.
Например вот мобильная игра, я добавил управление куда тапнул в ту сторону и полетел( спиздил из интернета под чистую), врагов, зеленыое усиление +1жизнь, увеличение сложности со временем, экран старта и рестарта, отображение очков сверху( надо бы еще добавить результат на геймовер)
Но вообще думаю надо и правда учить уже что-то, слишком уж слабый у меня запас знаний. Например хотел бы сделать прототип игры где надо считать в уме и выставлять необходимое время.
Кстати а как и где правильно делиться играми? Я вот вам так просто кину сборку из юнити( если кто-то не боится). Если кто скачает можете предложить что я могу усовершенствовать и добавить чтоб было интереснее и лучше и я заодно продолжу изучать юнити и сишарп продолжая этот проект.
- ссылку на игру - https://easyupload.io/f2isx2
Сорян за кривую пунктуацию и блуждание мыслей, почти не спал и не ел, а еще болит всё.
>>635623
Материала на английском много, сложно найти подходящий именно тебе, на русском тоже наверное нужен, но ты думаешь у тебя получится сделать то, что раньше другим не удалось? Ну тогда попробуй. Но это ведь много усилий надо, чтобы даже простой ролик записать надо сначала материал разложить, сделать план и тд. И таких много.
Решил глянуть что это такое за юнити хуюнити. Вкатился сегодня.
Первая же проблема, что за дауны писали названия функций и переменных в нем? Mathf.Cos Начинается с большой буквы, Debug.Log тоже, а блять Rigidbody.useGravity нихуя нет. И там такого говна дохуя. Если уже взяли шарп то следуйте его дизаену называйте все с большой буквы, там же регистрозависимость названий.
Вопрос такой, че там с блюпринтами? Если я сеньйор помидор в програмировании стоит их брать или самому пытаться что то накалякать?
Я хочу сделоть 2дэ экшон суть токова... но опыт у меня есть только с 3д движками, и я себе смутно представляю как коллизии и взаимодействие объектов друш с другом в юнитовском 2д, которое 3д на самом деле, происходит.
>>635628
В юнити шарп каличный чутка.
Не знаю что там в других ААА движках, но сравнивая с самопальными юнеити проигрывает.
>Я открывал уроки по сишарпу и там немного другой язык если не в юнити
Так может казаться и так будет казаться, только через пару лет работы на чистом шарпе и в юнити научишься различать особенности и схожие приемы. Лучше смотри туториалы по проганью именно под Юнити, чтобы было проще, хотя основы везде одинаковые.
Хе-хе, да ты сгоришь нахуй, когда захочешь контролировать жизненный цикл monobehaviour'ов или поймёшь, что любую инкапсуляцию можно нарушить простым SendMessage, не говоря о возможности получить любую информацию откуда угодно и о чем угодно.
Блюпринты не нужны, да и нету их в Юньке, если не считать левых ассетов.
Пацаны, можно ли сделать во вьюпорте юнити навигацию как во всех 3д редакторах, конкретно zoom to mouse position и auto depth (это когда центр вращение камеры ставится в точку пересечения луча с мешем пущенного из позиции мыши)?
Unity 2019.3.0f5: Не так быстро, пидор
Бля, я не понял.
Я задаю указатель на ригидбоди в скрипте, цепляю скрипт к объекту и чтобы эта ссылка была валидна я должен перетянуть объект сцены который хочу видеть в это ссылке в поле этого скрипта?! Просто так я не могу получить ссылку, тупо из кода, там проверяю спавн объектов и если объект is "player" цепляю сссылку на поле?
Ригибоди на том же обьекте, что и скрипт? Тогда в Awake пишешь getcomponent, а чтобы ссылка всегда была валидна, юзаешь requirecomponent.
Если тебе нужно получить левый объект, то вариантов море. От хуевого к нормальному:
- FindGameobjectWithTag
- сделать либо скрипт искомого объекта синглтоном, либо менеджер-синглтон, в который объект при создании сам записывается. После этого у тебя есть глобальная ссылка на объект откуда угодно и когда угодно.
- добавить триггер и ловить все новые объекты внутри него. И проверять, игрок ли это. Сюда же OverlapSphere, что по сути то же самое, но без триггера.
- прицепить на объект скрипт, который сам сохраняет себя куда нужно.
- Ты обьект создаёшь скриптом? Нет? Инициализируй скриптом! А при создании сохраняй ссылку и передавай куда надо.
Написал много чего интересного. Только я нихуя не понял.
-FindGameobjectWithTag это обычный итератор? Дохера ресурсов жрет? Тег это название объекта которое я задаю?
-как менеджер синглтон сделать? И как его потом распихивать по всем остальным скриптам, типа "обжект хуй заспавнился, вставляем через метод хуя ссылку на менеджер в поле хуй.менеджер"
- как прицепить чтобы он сохранял?
- куда скрипт добавить чтобы он инициализировал хуйню всю? Глобальные классы как делать?
>Дохера ресурсов жрет?
Как говорится, "один раз - не пидорас". Вряд ли у тебя будут десятки тысяч объектов в сцене, так что эта функция не подвесит тебе игру. Но это очень легкий способ получить какой угодно объект, отчего им легко злоупотреблять, к тому же этот метод вредит быстродействию И архитектуре.
Есть варианты поиска по тегу (быстрее) и по имени объекта (медленнее): https://docs.unity3d.com/ScriptReference/GameObject.html
>как менеджер синглтон сделать?
https://pastebin.com/rtr7ipsK например.
Ещё одна крайне удобная хуйня, которой очень легко злоупотреблять: там прописал глобальную переменную, тут прописал, а потом понимаешь, что у тебя вся архитектура строится на синглтонах, отчего у тебя получаются слишком связные между собой модули, которые сложно тестировать и расширять. Зато такая реализация очень экономит время: захуячил менеджер интерфейсов в пару строк, захуячил менеджер звука, и ничего цеплять не нужно, все глобально доступно.
>как прицепить чтобы он сохранял?
Как в примере с синглтоном. Если оставить в стороне греховное создание синглтона, то это распространенная практика - создавать объект и внутри Awake() рассылать информацию о нем куда надо. Не обязательно в синглтон.
>куда скрипт добавить чтобы он инициализировал хуйню всю?
Ну смотри, вместо того, чтобы натыкивать в сцену кучу всякой хуйни, ты чистишь сцену вилкой, а объекты сохраняешь префабами. Зачем тебе вручную размещать игрока внутрь каждой новой сцены? Простопишешь менеджер сцены, который будет находиться в сцене и создавать все, что нужно, и раздавать объектам ссылки друг на друга:
https://pastebin.com/VDhC53jy
Экземпляр игрока передается в созданных менеджером врагов, или враги сразу были в сцене, а ты просто перетащил их в менеджера. Или ссылка на игрока опять же сохраняется глобально, как с синглтоном, и любой враг может запросить её сам... Варианты ограничиваются твоим воображением.
Глобальный объект удобен для реюзанья хуйни типа сфх, чтобы каждый объект мог дернуть заранее заспавненный и ожидающий в массиве объект чтобы показать что то типа дымы, огоня, искр, крика, шума, гама, гомопидоров.
Я пока так только юнити тыкаю, тут есть такое что мне не нравится с точки зрения програмирования. Глянуть надо что в анриле, годоте и остальных есть.
И в итоге твоя система спецэффектов размазана по сотне классов. И переделать ее нормально не получится, и дополнять гемор.
Если хочешь быстро сделать и не париться - делаешь через статики\синглтоны, если хочешь качественно - то пишешь собственный сервис локатор или юзаешь костыльные DI под Юнити. Что по сути те же статики, но в обёртке.
Других методов реализации мало-мальски крупной архитектуры под Юнити я что-то не видел.
ну и второй вопрос - есть какие советы как организовать хранение всех этих проектов? а то делаешь проект, потом хочется по бырику отвлечься на другой, между делом хочется потестить разные ассеты (и делать это на рабочем проекте хреновая идея - все ломается)... и в итоге на диске все забито кучей папок с проектами, а я даже не могу вспомнить где что и для чего
может есть какие-то методики чтобы этот хаос упорядочить?
У меня просто большая папка называется исходники, в ней всякая хуйня со скачанными прогами и кряками, я все подписываю в текстовый док инстукции пишу, скрины делаю, они удобно в файл .rtf вставляются прямо в текст, кладу в каждую папку. Есть папка с туторами, например, как поэтапно ретоп делать, горячие клавиши, по каждой проге инфа из уроков и хитрости, потому что потом забывается. Все скачанные ассеты достаю из
C:\Users\Maxim\AppData\Roaming\Unity\Asset Store-5.x
и перекидываю в папку юнити в исходниках.
Как-то странно, в энтерпрайзе почти поголовное требование.
В играх вообще с качеством кода беда-беда. Люди мало того, что не умеют выстраивать архитектуру, так и учиться не хотят. На stackexchange я видел посты, где человек на полном серьезе говорил, что паттерны созданы для энтерпрайза, а в создании игр они только замедляют скорость разработки.
Задел на будущее. Больше гибкости, позволит потом добавить какую-никакую логику. Более упорядоченный код. Вообще расширения редактора мастхев, привыкайте-с. Там скоро ещё скриптабле буилд пайплайн подъедет, весь редактор на скриптах и расширениях скоро будет.
Сейчас пилю два расширения - одно будет отображать заспавненные энтити, второе для редактирования игровых предметов - мечей там всяких и т.д.
Если потом окажется, что твою статическую функцию нужно менять, то менять придется не одну функцию, а все вызывающие классы. А что хуже, если ты захочешь потестировать какой-нибудь модуль, то тебе придется в него нести заодно и весь статический класс спецэффектов, потому что на него ссылаются.
Лучше делать через интерфейс, а интерфейс уже регистрировать в каком-нибудь статическом service locator'е. Тогда можно творить любую хуйню внутри менеджера спецэффектов, пока не нарушается интерфейс, или написать десяток реализаций на любой вкус и переключаться между ними, в том числе и тестовый вариант.
Подскажи какой софт?
Чтобы без смс, и чтобы оно было под юнити и в один клик мыши. Я знаю что есть куча декомпиляторов шарпа - но в них надо вникать
отчасти он прав.
Почему в энтепрайзе оно нужно?
Потому что софт там пишется на десятилетия. Надо так написать чтобы через 10 лет в этот код можно было вносить изменения.
Потому что энтерпрайз - это очень серьезно - любые ошибки могут приводить к человеческим смертям (например в медицинском софте - и такие случаи уже были) либо к миллионным расходам (типа дыр в банках)
Скорость в энтерпрайзе не важна - во-первых нет таких реалтаймовых тяжелых задач и расчет можно подождать и недельку.... да и начальство купит новые железки если надо.
Паттерны и алгоритмы унифицируют код. Они выстраданы 50 годами развития софта и миллионами проблем.
Методики тестирования также выстраданы годами и человеческими жертвами
А что такое геймдев? это грязный софт. В геймдеве ошибки ничего не стоят. Вообще ничего (вспомните такие хиты как готика, которые в первые дни даже не запускались... или вон дагерфол)
Качество кода также не имеет значения - игры не живут больше года, их не нужно сопровождать. А так как игровые технологии развиваются сверх быстро -каждый новый проект скорее начинают с нуля (это сейчас с эпохой юнити всё более-менее устаканилось, а раньше каждый месяц всё менялось в науке геймдева - и написанный тобой сегодня код, завтра уже безбожно устареет)
И конечно же, игры в отличие от энтерпрайза сверх требовательны. Понимаешь, когда какой-то код унифицируют, то как раз жертвуют эффективностью. (хотя людям избалованым сахарком C# возможно этого не понять, чтобы в этой теме разбираться, надо писать на низкоуровневом ЯП - чтобы появилось понимание - как эти паттерны обрабатывает процессор - и откуда потеря производительности....
кстати, можете меня не слушать - в гугле можно найти исходный код внутреннего движка юнити (на С++ который). Вот сами посмотрите как написан ваш юнити... там даже примитивные фабрики не используются.
>Качество кода также не имеет значения - игры не живут больше года, их не нужно сопровождать.
А потом появляются печально известные игры от парадоксов, в которых говнокод не могут разгрести годами, а игроки жалуются на производительность.
В последнее десятилетие сильно развилась очень интересная концепция бесконечных длс или перепилов баланса, это вышло за пределы ммох и моба игр. Сейчас уже никого не удивляют выходы обновлений на игру, которой уже 3-4 года.
Геймдев идёт по стопам энтерпрайза, но с задержкой в десятилетия.
Может быть у меня уже энтерпрайзная психдеформация, но в дополнение к этому
>>636729
анону скажу, что после начала использования, например, UoW и репозитория, без него я свой код уже представить не могу, т.к. паттерны качественно меняют код и его восприятие, поднимая код на новый уровень.
Нужно добавить новую фишку? Легко - добавляешь новый репозиторий или расширяешь старый и всё - старый код ломается с очень низкой вероятностью, т.к. связанность кода низкая.
А без паттерна нужно распутывать старый "Грязный" спагетти-код, впендюривать туда новые методы, все нахуй рушится в самый непредсказуемый момент и пиздец.
>Геймдев идёт по стопам энтерпрайза, но с задержкой в десятилетия.
В отличие от энтерпрайза - в геймдеве меньше денег. Поэтому говнокод в геймдеве будет преобладать
Хотя конечно свои паттерны появились и в гаймдеве - например тот же ECS не имеет никакого смысла в энтерпрайзе - там нет таких задач в которых важно чтобы данные были кешфрендли.
Кстати раз речь про паттерны - напомните мне тот ассет в котором были специальные C# паттерны заточенные под особенности юнити, как раз тут понадобился, а не могу вспомнить
Есть карта провинций в пнг, нарисованная разными цветами.
По клику по карте берется пиксель и по его цвету из массива достается нужная провинция.
Каким образом можно сделать отображение названия провинции на карте? Нужен какой-то шейдер или что? В какую сторону копать?
Ну так-то это не обфускация, просто невозможно достать код в исходном виде, но в виде псевдокода легко. К счастью, если кто может разобрать псевдокод, тому и воровать нихуя не надо. А так il2cpp чуть быстрее моно, потому что в моно все флоаты это даблы. В остальном скорость будет та же, что и при компиле в дотнет. Хочешь профиты - юзай жоп системсы.
https://metanit.com/sharp/mvc5/23.3.php
Если очень кратко - вся логика у тебя сосредоточена в репозиториях,а через UoW ты просто вызываешь методы репозитория
Vector3 relativePos = target.transform.position - transform.position;
Quaternion toRotation = Quaternion.LookRotation(relativePos);
transform.rotation = Quaternion.Lerp(transform.rotation, toRotation, lerpSpeed * Time.deltaTime);
Очень долго ебался с этой хуйнёй когда анимированные обьекты из блендера кидал в юнити, ох наебался знатно.
Вот мои советы - 1.Чекай инглишь видосики и гугол, читай что делать. 2. Пытайся разными способами это преодолеть, не бросай. 3. В конце концов эту хуйню ты преодолеешь, но надо приложить усилия инфа 146%.
Это лечиться не скриптом, а обьектом и его окружением.
Неправильно. Основной Трикс - заменить ООП-объекты ЕЦС-сущностями у которых поля хранятся ресурсами в файлах. При обращении к одному полю поднимается файл этого поля у всех сущностей. Благодаря этому ты сможешь сделать волны зомби, которые на максималках польются даже на ноутбуке для учебы.
>Неправильно. Основной Трикс - заменить ООП-объекты ЕЦС-сущностями у которых поля хранятся ресурсами в файлах. При обращении к одному полю поднимается файл этого поля у всех сущностей. Благодаря этому ты сможешь сделать волны зомби, которые на максималках польются даже на ноутбуке для учебы.
Но зачем заниматься процедурным программированием и стрелять себе в ногу, если я могу точно вычислить сколько зомбей помещается на экране и создать коллекцию постоянного размера в которой зомбаки будут повторно утилизироваться?
А что касается пеки для учебы, то кто мне мешает во время экрана загрузки сделать бенчмарк с офскрин-рендером и понять насколько у юзера тянет его калькулятор и спавнить росно столько зомбей, сколько его калькулятор потянет?
Это не говоря уже о разумном для геймплея на конкретной платформе количестве зомбей. На сраном китайском телефоне с тормозящим ведром делать элиен шутер такая себе затея.
>Это фича чисто Юньки или есть другие солидные движки, работающие на этом подходе?
Да, практически все консолесовместимые движки начиная со второй волны игр прошлого поколения консолей по причине убогости кеша у этих самых консолей.
Вот , например, про эту хуиту уже писали авторы Анчарча но ещё не называли её ECS
https://www.slideshare.net/naughty_dog/multiprocessor-game-loops-lessons-from-uncharted-2-among-thieves
Собственно, для консольного портирования и мобилок эту фичу и добавили, и добавил её чувак которого сманили из студии ОТСОСОНИ Insomniac Games.
>Разницы между обоими способами я не заметил.
Есть разница, если модель из нескольких объектов, у меня конкретно из двух, база и башня, твоим способом нужно у башни было -90 ставить, а у базы 90, и применять, короче какая-то хуйня. Через Experimental! Apply transform проблема решается, но мне нравилось просто закинуть бленд файл в юньку и можно прям оттуда редактировать, и при сохранении он автоматом подгружался, а через фбх постоянно экспортить лень.
Осваиваю юнити, делаю всё по урокам, периодически пропадает движение мыши по вертикали после билда. В редакторе всё работает, как соберу экзешник, запускаю, лево право движется, на стрелки реагирует, пытаюсь мышью вверх-вниз и ничего не происходит (не могу посмотреть на небо или на землю). Системы не заметил, раньше появлялось после импорта дополнительных ассетов, сейчас сделал игровое меню и движение пропало.
Как в процессе игры открыть меню паузы? В туториалах только начальное меню, по ним сделал, всё работает, а я хочу нажать esc в процессе игры, чтобы открылось окно с "Новая игра", "Настройки", "Выход".
Крайэнжин работает на ецс. В юньке просто, как обычно, делают эпиляцию ног через анальное отверстие. Поля в скриптах ресурсами в файлах это шизофрения, юнити работает не так. Ни один движок так не работает. Главный трюк - подавать данные порционно, чтобы в L1 влезло. А как ты их будешь подавать уже дело десятое.
>делать элиен шутер такая себе затея.
И тем не менее, я играл в элиен шутеры в доисторическую эру на коре дуба, когда о ецс ещё никто даже не думал. И получал высокий фпс. Повод задуматься.
Есть в юнити кнопка, нажав на которую мне откроются все используемые скрипты, чтобы я в редакторе мог их редактировать, искать и т.п. Уж больно они интересно подключаются, не удивлюсь, если там они в ресурсах еще где-нибудь прячутся.
Нет.
MonoBehaviour'ы подключаются к геймобжектам как компоненты и настраиваются там, ScriptableObject'ы создаются отдельными файлами и настраиваются там. Чистые классы настраивать либо скриптами, либо сериализовать и засовывать внутрь первых двух вариантов.
Других интерфейсов не завезли.
https://github.com/Unity-Technologies/UnityCsReference
Вот тут есть скрипты юнити из дефолтной поставки. Раньше для "редактирования" хватало просто взять любой скрипт, схоронить с тем же именем и засунуть в папку проекта, хуй знает, как теперь, давно не пробовал. Ясно дело, что зависимости тоже придётся совать в ассетс. Но всё равно интересности никуда не денутся, юнити ещё не весь шарповый.
Перекатываюсь меж движками как йоба между укрытий.
Вопрос, есть какой то список наиболее часто используемых функций? Типа как зассумонить что то, как провести хитскан атаку, как заварпить хуйню, сменить текстурку, т.д.
Как бы потому не оказалось, что класс на половину состоит из таких "промежуточных" звеньев.
Я понимаю, что описанная мной система больше релевантна в средне-крупных компаниях, когда тебе при изменении внешнего менеджера нужно также "попросить" три соседних отдела переписать кодовую базу.
Но лично мне после всех собранных костылей даже в домашнем проекте проще всю логику прятать внутрь модулей, а наружу их выставлять абстракциями. Так проще держать в голове архитектуру игры и не путаться в перекрестных ссылках.
Ну смотри какой способ я уже реализовывал и который работает, правда не в юнити.
Создаю класс спецефекты, в нем приватный массив со ссылками не все спецефекты. Класс имеет пуцбличную функцию показать_хуйню()
Дальше я ивентом отправляю ссылку на этот класс во все объекты которые спавнятся во время игры в заранее созданный указатель в базовом классе.
В базовых классах делаю враппер для показа спецефектов (так как для валыны нужна одна логика для просто акторов другая) который вызывает метод показать_хуйню() через ссылку и автоматически подгоняет эффекты для нужного вида и использую его, враппер, вместо ебли со ссылками.
Пока ни разу не переписывал это все так как написал так что покрывает все потребности мои.
Где проебался?
Написал вот так
> float y = n / ncount;
но получается пик 2.
25 января
@
2019.3 не вышла из беты
пиздец. О 2020.1 можно даже не мечтать.
Пытаюсь реализовать разрушаемый пиксельный объект.
Допустим, есть такое облачко. Цель - сделать так, чтобы при "распиливании", допустим, очередью пуль пополам , облачко бы развалилось на две части, которые бы имели физику, то есть вели себя бы как отдельные объекты.
Простую разрушаемость с последующим "зависанием" в воздухе я реализовал.
Каждый пиксель - отдельный объект.
Были мысли связать пиксели между собой Fixed Joint, однако не нашел информации о привязывании сразу нескольких объектов.
Может сталкивался кто с такими задачами?
Не нашел способа через ивенты создать нормальную логику удерживания кнопки. Можно, конечно, в апдейте написать input["Move"].ReadValue<Vector2>() - но стоило ли переходить на новую систему чтобы потом писать такой же код, что и раньше?
Ещё видел прикольный шизофренический метод через корутины - запускать при нажатии, останавливать при отпускании - а решений из коробки не нашёл. Их тупо не допилили?
>>639144
Да вот мне очень нравится LTS версия 2018й, но в 2019 завезли фичи, которые были бы очень кстати. Но там в 2019м LWPR, HDPR, измененные префабы, новый инпут, еще всякая хуйня которую я не ебу. Может глюки еще какие. В общем не знаю...
Вообще хотелось бы чтоб Юнитеки уже б запилили 2019 LTS, но пока увы.
Народ, помогите, заебала эта юнити, никак не хочет vscode интегрироваться с unity. Пробовал качать в юнити плагин для vscode, в самом редакторе уже скачал плагин для юнити, ничего не помогает.
Наконец добился неведомой хуйни что вообще теперь правки не сохраняет.
Уже думаю кодить в visual studio и там писать свой движок, благо опыт уже есть.
Гуглил про всякую root animation, но в итоге не получается то, что мне надо. Если двигать весь объект персонажа сразу, то ноги двигаются вместе с ним, и в итоге их сложно устанавливать на землю. А если двигать только кость таза, то всё хорошо, но не работает root animation. Не могу допереть, как сделать, чтоб грамотно было.
Ну то есть если это юзать для спрайта - то понятно - выбраь тип спрайт, открыть спрайт эдитор
Но я хочу такие текстуры натянуть на 3д модели. резать руками лень - как?
А ещё у меня ёба-ошибка при запуске:
Error loading launcher://unity/C:/Users/Alex-Admin/AppData/Roaming/Unity/Packages/node_modules/unity-editor-home/dist/index.html?code=8f7YvOcy8YYAwaOWHoybvQ009f&locale=en&session_state=2f4839fbd2db1918c1c227a02a400bbf89c746b92d6fe3c82bbd225900071d1d.QZ6FyWH1FStNgZRa-_VBrg00af
Весь что ли? Ну вот
https://pastebin.com/4sygesqe
так погоди
а почему у тебя на land вообще висит rigidbody? как так вышло то?
возможности как со спрайтами нет, но ты можешь сделать своим скриптом такой же интерфейс как и у спрайтиков. у материалов есть короче тайлинг и оффсет, тайлинг у тебя соответственно 1/8, а оффсет по х-у нутыпонел, всё это через material.SetFloat() или как там, я зобыл
Прочитал статью, возник вопрос, как они сделали эффект как на пикриле? Написано, что просто добавили коллайдеры к эффекторам, но это ж нихуя не работает. Ригидбоди тоже вставлял, с ними всё пидорасится нахуй.
Или это уже на скриптах оформлено?
>Или это уже на скриптах оформлено?
>2d-inverse-kinematics
ну сам как думаешь?
полагаю эффекта на пике можно добиться добавив вот к этим ступням ригидбади с коллайдером и Spring Joint 2d. ну и 2д ИК туда для коленей.
впрочем я могу и обосраться, ведь я такой же осел как и вы, сэр.
Как правильно сделать подъем по изметрической лестнице чтобы игрок также поднимался а не создавалась иллюзия подъема?
Лайтвейт был раньше, теперь упоминаются только URP и HDRP, но пакетов всё равно три.
Версия: 2019.3.0f6
Создал пустой проект
Запустил "C:\Program Files\Unity\Editor\Unity.exe" bla-bla -buildWindowsPlayer bla=bla
В логе такое:
>Failed to load 'bla-bla/library/scriptmapper' because it was serialized with a newer version of Unity. (Has a higher SerializedFile version)
Все свежее и обновленное, что её надо? Переустановить?
1) объявление метода (скрипт1) публичным для вызова его из (скрипт2) напрямую
Или
2) объявление пользовательского ивента в скрипте2 и подписка метода скрипта1 на пользовательский ивент скрипта2?
Полагаю 2, особенно если будет более одного слушателя.
Хуйню пишу? Не хотелось бы велосипеды писать, может и проще способ есть? Что вообще покурить на такую тему?
В общем вот такой код работает, но вдруг есть лучше вариант...
https://pastebin.com/Y5XUmbi6
Зависит от архитектуры. Обычно используются оба способа.
Публичные ивенты в скриптах это заебись, однако я помимо этого угораю по созданию своего ивент аггрегатора, который, собственно, управляет подписчиками с разными типами ивентов. Это круто использовать в случаях, когда тебе незачем связывать отправителя и получателя, просто кидаешь ивент в пространство, а аггрегатор уже рассылает его по подписчикам.
Так-то идея норм как локальное решение, а если оно расрастется, то ты ебанешься постоянно кастовать переменные. Если активно упаковывать value типы, тогда плюсом получишь ебейшую генерацию мусора и периодические пролаги. А ещё это создает сильные связи между скриптами, что ухудшит тебе жизнь в будущем.
Данные хранятся элементарнейшим образом хоть в одном, хоть в десятке скриптов. Как только выводишь все свои системы вне monobehaviour'ов, они автоматом становятся хранилищами твоей даты. От смены сцены они ничего не теряют, просто уничтожаешь текущий мусор сцены и создаешь мусор на следующей. Можно даже обойтись без централизованного хранилища.
есть объект2 с координатами (0,0) https://prnt.sc/qwx1jv
Вкладываем один в другой. У обоих координаты (0,0). НО СУКА ЕБАНАЯ В РОТ, КАКОГО ХУЯ ИХ НУЛЕВЫЕ КООРДИНАТЫ ОТЛИЧАЮТСЯ ОТ ОСТАЛЬНЫХ ОБЪЕКТОВ В СЦЕНЕ? А? https://prnt.sc/qwx310
Прохладная:
using System; // без этой либы отказывались работать стандартные делегаты лямбд типа Func<T,TResult>
Два часа еботы с этой хуйней, дощитэ??? дощитэ, минасан???
Нет, я конечно все уже попередумал... но чтобы так тупить.
https://unity3d.com/get-unity/download/archive
С оффициального сайта юнити можно скачать любую версию начиная с 3.4.0 (26 Jul, 2011).
>что если за 2 года кодинга у тебя слетит винда а новый юнити твой код не захочет воспринимать
Ебанушки тупые
https://unity3d.com/ru/get-unity/download/archive
Нюфаг
>если за 2 года кодинга у тебя слетит винда
В интернетах слишком дохуя манулов как на русском, так и на английском. Но все они какие то поверхностные слишком.
На сайте юнити норм туториалы
https://learn.unity.com/tutorial/create-your-first-unity-project
Самый известный это Fungus https://assetstore.unity.com/packages/templates/systems/fungus-34184
Те, кто делал на нем проект, пару лет назад, жаловались на баги, что там сейчас хз.
А где вообще получить образование если я собираюсь сделать не просто внку, а ещё с элементами игры и анимациями?
Мне как для тупых нужны уроки, мотивируещие что посмотрел одно видео и похвалил себя.
Я собираюсь проходить курс Foolish Mortals и делать как он, надеюсь годное.
>А где вообще получить образование
Если у тебя такие вопросы то, ответ нигде. Если есть интерес заниматься юнити, то нужно начать с https://learn.unity.com
Ну да, пошел я нахер со своим -3.
Второй вариант гораздо экономичнее с точки зрения количества кода и расширяется легче. Но тогда при каждом изменении любого ресурса будут опрашиваться все обработчики событий и придется отдельно проверять в обработчике, его ли ресурс был изменен. Как тут лучше поступить?
Лол, у меня 2019.2.18f1
Благодарю, анон, поставлю новее, а то глаза мне дороги.
Ты не станешь успешным в любом случае.
Очень мутный реквест, но мне из головы приходит сразу идея обернуть каждый ресурс в объект, и внутри обьекта сделать значение, ключ-id, методы изменения, событие OnChanged, ...
А менеджер будет просто коллекцией ресурсов. Это эргономичней в плане архитектуры и расширяемости, и у тебя не будет помойки из кучи однотипных полей/событий.
Если делать ресурс классом, то нужно будет, конечно, делать так, чтобы у тебя не создавалось по сотне ресурсов каждый фрейм.
Или это все работает через начальную скорость, продолжительность жизни и появление новых частиц?
1. Автонаводка реализована через тангенс.
float a = transform.position.y - spaceship.transform.position.y;
float b = transform.position.x - spaceship.transform.position.x;
float lookangle = Mathf.Atan2(a,b) 180 / Mathf.PI;
transform.rotation = Quaternion.Euler(0, 0, (-90+lookangle));
-90 - для того, чтобы правильно угол определяло. А то поворот от нуля не наводит ствол на цель.
2. Этот код дает верную траекторию для пули, но когда пули летят выше турели, то они перевернутые. Не могу подобрать правильные градусы для исправления.
Instantiate(rocket, Dulo.transform.position, Quaternion.Euler(0, 0, ((lookangle >= 0) ? (90+lookangle) : (270 - lookangle) )));
3. А вот сам код для полета пули. Использовал синусы и косинусы, чтобы скорость была одинаковая. Но тут опять сильно напутано. В одном случае абсолютное значение, в другом нету. Я уже и забыл, почему так делал.
distance = speed Time.deltaTime ((Mathf.Cos(transform.eulerAngles.z / 180 Mathf.PI) < 0) ? -1 : 1);
y += distance Mathf.Abs( ((Mathf.Cos(transform.eulerAngles.z / 180 Mathf.PI))) );
x += distance ((Mathf.Sin(transform.eulerAngles.z / 180 Mathf.PI)));
Спасибо за ответ, я уже разобрался.
>Математика, конечно, хорошо
Я делаю первые шаги и кругом вижу препятствия и хитрые математические формулы. Допустим, написать ускорение для автомобиля, его заносы на поворотах.
Я не понимаю, как работает эта физика. Этот Addforce. Такое впечатление, что почти всё нужно писать самому.
У меня все наоборот.
Практически нигде в примерах не вижу сложной математики, но изредка она сильно спасает. Делаешь охуевший алгоритм для маятников или колебаний, а потом такой: "ебать, можно же через sin это сделать в две строки!"
Или расчет отступов для камеры пропорционально её наклону. Но это все тригонометрия уровня класса восьмого. В остальном только задрачивание векторов и кватернионов. Ни разу не сталкивался с задачкой, где реально нужно было сложные формулы расчехлять.
>не вижу сложной математики
>тригонометрия уровня класса восьмого
Для меня вся математика сложная, кроме счета яблок 2+2=4. В школе ты решал стандартные и готовые задачи по учебнику, где можно было и не вникать в суть тригонометрии.
Тогда в программировании ты даже не получаешь готовую математическую задачу, где нужно найти неизвестное, а ты сам должен додуматься, как с помощью математики реализовать ускорение автомобиля, инерцию, торможение, заносы на поворотах.
>где реально нужно было сложные формулы расчехлять.
Я сомневаюсь, что для физики автомобиля в 2д игре понадобятся очень сложные формулы. Но всё же я вижу перед собой головоломку. К некоторым задачам я даже не знаю, как правильно подступиться.
Что это? Глюк системы или это запланировано физикой?
1) Я сделал билд для Виндовс. Он весит почти 55мб, хотя игра простая. Место занимают не ресурсы игры, а сами файлы юниты. Например, UnityPlayer.dll весит 24мб.
2) В билде видно не только камеру, а и то, что за ней находится.Пробовал поставить в оконном режиме, всё равно видно то, чего бы не хотелось видеть.
3) Я сделал сборку ВебГЛ. Но её не запускает ни один браузер, хотя я копался в настройках, как советовал гугл. Не знаю куда заливать эти файлы. Можно ли их добавить ВК или Фейсбук?
Типо чтобы при загрузке они сразу были поделены на отдельные плитки
https://dotnetfiddle.net/TZSNeS - вот скрипт.
В интернете не нашёл того, что бы помогло.
