Прошлый: https://2ch.hk/gd/res/619490.html#626766
Перекатился на LWRP с год назад, охуел от сырости. Поверил, что потихоньку допилят. Прошел год и... Я по-прежнему охуеваю!
Создаю десктоп игру с упрощённым графонием уровня симсов. Настал момент создания локаций - пора выбрать пайплайн и не оглядываться назад.
Продолжать жрать кактус с URP или перекатиться в легаси/HD? Тяжёлую фотографичную картинку делать намерений нет, но со светом, тенями, материалами, постпроцессингом буду играться много по ходу дела.
Изначально выбрал lwrp ради шейдер графа, но теперь имеется аналогичный инструмент от Amplify, поддерживающий все режимы.
Я его только начал ковырять. А так:
- удобней, больше функционала (?)
- поддерживает легаси и hd
- может сразу показывать сгенерированный код шейдера - очень удобно для обучения.
- много темплейтов.
Короче, то же, что встроенный, только лучше. Не уверен, что стоит перекатываться, если и так все устраивает.
>>627066
И, откровенно говоря, видя ебанутую политику юнити касательно существующего функционала, я не уверен, что встроенный шейдер граф будут развивать, или даже поддерживать. Вполне может стать, что через год-полтора его поддержка прекратится, а дальше его переведут в deprecated.
К Amplify доверия побольше, так что мне не жалко было расстаться с 2к.
ЕО3Оесть один три дэ обьект с моделью, текстурой. Таких обьектов создается несколько штук на сцене одновременно и они активны. Каждый обьект рано или поздно будет уничтожен. В этот момент надо ему проиграть анимацию смены цвета альфа из 1 в 0.
Я попробовал у MeshRenderer.materials у них color менять. Возрасло количество draw callov в 5-10 раз. Использовал стандартный шейдер с mode=Fade и mode=Transparent. Оно еще и проглючивает.
Может кто-то сталкивался?
https://blogs.unity3d.com/2015/12/23/1k-update-calls/
отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
Много апдейтов это хуево, да, уже много лет все это знают.
Поэтому всегда говорят удалять пустые апдейты например.
>отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
В теории да, но тут больше вопрос о том сколько у тебя объектов активных на сцене в одно и то же время. Если у тебя 100-200 объектов, то это даст маргинальный буст производительности, а если у тебя 10000 объектов то у тебя будет нагрузка в любом случае, и ты что-то делаешь неправильно (либо нужно придумывать продвинутые способы оптимизации)
>отсюда вопрос - если иметь один апдейт на всю игру и все остальное вызывать в нем через евент будет типа быстрее?
https://www.youtube.com/watch?v=mQ2KTRn4BMI
Смотри все
спасибо за интересный видос, аутизм начинается на 28:34
про мастер сцену с саб сценами юнити сам учит в адвенчур гейм туториале, другого подхода в юнити просто не должно быть если игра сложнее геймджем перделки
то что я понял:
>сделоли Update() с форлупом на 1000 колов
>выиграли 1-2 мс (говорит на 49:27)
на этом вопрос можно закрывать
не юзать апдейт это скорее вопрос принципа, когда следуешь mvc или типа просто больной аутист как я
>>627150 >>627223 вы правы короч
Рендер пайп это заебись когда свой пишешь, под свои нужды. 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 иконки или подсказки, чтобы чел знал, что можно нажать.
интерфейсы? 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, что печально, он мне нравится.
Точно, я сонный даже не увидел ее. Если через lwrp делаешь, посмотри что рисуется через frame debugger, возможно это из за постобработки или вот эта залупа даже на 1 сглаживает пиксили.
Помоги, пожалуйста с таким вопросом.
Есть части двигателя. В майке они выглядят нормально, трансформы заморожены, все путем. Но после экспорта в юнити, данные нифига не сохраняются, и если сбросить их на ноль, то меш будет помещен в центр мира. Я уже пробовал делать parent, группы, но все фигня. В чем тут дело ну, кроме того, что я туповат? Как сделать, чтоб все данные о расположении, в Юнити были так же на нуле, как и в Майе?
А чего подробнее, когда в интернете мануалов навалом?
https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnMouseOver.html
Выстреливает каждый фрейм по аналогии с апдейтом, когда курсор находится поверх предмета. Также есть mouseEnter и mouseLeave. У предмета должен быть коллайдер.
Избавляет от необходимости писать любые виды обнаружения предметов (я тоже раньше через рейкаст делал), проверять нужно лишь дистанцию до игрока, чтобы не ворочал мешками из другого конца комнаты.
Получится много копирования кода для каждого класса(активация, деактивация, сайд-эффекты), либо выносить все в родителя, а тогда будет громоздкий родитель и широкое некрасивое дерево наследования.
Лучше сделать систему модулей, где каждый модуль опционально подключаем и выполняет кусок своей логики. Тогда очень круто играет open-closed принцип: для расширения логики тебе не нужно ничего переписывать, ты просто добавляешь новый модуль.
Я сделал один компонент, а внутри него enum с атрибутом [Flags]. Для каждого префаба нужно прикрепить один компонент, а флаги выставляешь любой комбинацией для создания гибкой логики.
Это мне нравится больше, чем создание тысяч InteractableDoor, InteractableChest, InteractableItem, InteractablePotion, ...
Мой случай слишком специфический чтобы ответить тебе что-нибудь внятное. У меня только базовые классы (юнит, обстакл, дудад), а всё взаимодействие вынесено в заменяемые скрипты на луа. То есть InteractableDoor и InteractableChest, но я их читаю из текстовых файлов снаружи юньки.
>А подписчики уже сами решают, что с этими данными делать.
Это говно очень быстро вырастет до внушительного по размерам пакета, который будет пересылаться всем-всем-всем как только появится нужда в follow-up ивентах вроде парирования, доджей, чеков на proximity чтобы реакцию какую-то сделать и т.п. Видел, как икскомы виснут, иногда напрочь, когда в конце стрельбы очень дохуя эффектов разом срабатывают? По сути, я спрашиваю, как с такой ерундой справился Хартстоун.
Хз, тогда можно посылать ивентом только отправителя и получателя. Получатель ловит ивент и запоминает отправителя, после чего они начинают срать данными между собой. А в другие модули данные отправлять небольшими сообщениями-ивентами, без мусора.
Хотя.. как ты будешь пересылать получателя ивентом, если у тебя изначальное требование не быть связанным прямыми ссылками? Хуй знает короче.
Лол, пока спрашивал нашёл у себя в коде типа-решение - разбивать ивент на куски, которые выстроены в последовательность, и каждый кусок выполняет свою часть ивента, и если эта часть вызывает какой-то другой ивент, то он кусками встраивается в уже имеющуюся последовательность.
Это... менеджер, который курирует последовательность ивентов, собирая по пакету на каждый из них заново по требованию ивентов? Ну, в другом месте кода это работает, надо repurpose'ить
Ты ещё здесь?
И вообще здесь есть именно те кто удалённо зарабатывает, чтобы не надо было ходить в офис.
У меня был свой источник дохода - в лучшие времена до $5000 в месяц, сейчас упало до $1500-2000, сам я бывший веб программист, но не хочу ходить в офис, интересует данная тема на пообщаться
Лови: https://pastebin.com/hahTUw1d
В эту систему можно дописывать любого вида модуль:
1. Создаёшь новый наследник.
2. Добавляешь новый флаг в enum.
3. Пишешь две строчки на создание нового модуля.
Третий шаг можно автоматизировать, но это выглядит грязно. Быстрее вручную дописать, на мой вкус.
А ещё можно создавать не только опциональные, но и обязательные, и взаимоисключающие модули!
Конечно, я не стал писать тысячи null чеков и других проверок, а надо бы.
Ты издеваешься?
>this.rb = rb;
>rb.isKinematic = false;
Весь функционал твоего "модуля" - это сменить значение одного буля. Это гораздо проще и быстрее и чище сделать без таких извращений.
>>628292
Ладно, похуй на один буль. У тебя идея в том, чтобы "расширять" 3 метода в зависимости от тэгов. Как насчёт сделать круче - для каждого возможного модуля сделать менеджер, и вместо того чтобы подключать модули к объектам заносить объекты в списки этих менеджеров, а затем звать апдейт, дестрой и что там ещё из менеджера проходясь по списку?
>Ты издеваешься?
Да. А теперь посмотри на другие модули. Они тоже написаны в две строчки. Можно написать ещё штуки две- три таких же с базовыми функциями.
И нахуя их плодить, да?
Но вот если все их запихнуть в один мегакласс, получится дикая мешанина из событий при каждом старте/стопе взаимодействий. Это не очень хорошо.
- Я знаю, где расположен кинематический модуль и мне не нужно искать нужную строчку в стене общего кода.
- Легко расширять логику. У меня, например, там торчит таймер, снимающий кинематику не сразу, а через какое-то время. Я могу навесить в модуль ещё две-три простых функции, прежде чем он потребует декомпозиции.
- Почему скрипт взаимодействия должен что-то делать с rigidbody? Это нарушение принципа SRP и засорение логики. Его задача - создавать и поддерживать модули, а все взаимодействия должны располагаться в них.
Да, у меня ОКР, да, я угораю по аккуратному и структурированному коду. Да, это мешает продуктивности, но с моими библиотеками мне потом необычайно легко работать
Не совсем тебя понял. Сделать модули scriptableobject'ами, а в объекте создать их список, наполнять через инспектор и пробегаться по списку?
Пожалуй. Но я предпочитаю "чистые" классы, а делать менеджер scriptableobject'ом нет никаких причин. Енум это простейший способ работать с чистыми классами через инспектор.
_canJump?
У тебя сейчас дохуища экземпляров разных модулей. Я предлагаю взять объекты, к которым цепляются модули, и распихать по менеджерам, выполняющим функции этих модулей. Это как если вместо того чтобы иметь 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 - тут суть в том, что вот эти вот отдельные поля могут использоваться в совершенно различных сущностях, позиция может быть не только у моба, но и у игрока, источника света, итемов на уровне.
Так что мы из сущности вот эти вот поля нахер убираем и передаем их отдельной системе - двигательной, поворачивательной, осветительной, ИТД. А в сущностях мы лишь оставляем упоминание что вот моб умеет двигаться поворачиваться атаковать с помощью этих вот систем. Таким образом поля стали отдельными компонентами, их логику обслуживают системы, а сущность - это просто такая хуитка с айдишником и списком того в каких системх она учавствует.
Ну и третья составляющая - сделаный с блекджеком и шлюхами низкоуровневый диалект сисярпа, вместе с кастомным компилятором этого диалекта в нативный код.
Ах да, вы спросите, причем тут Unity?
По причине воя школоты о низкой производительности Unity, юнитеки пригласили одного из этих соневских байтолюбов себе в контору. Знакомьтесь, Mike Acton, он же Миша-Оптимизатор, автор DoD, любитель пердолить байты.
Вот он сейчас и занимается DOTS
https://www.youtube.com/watch?v=rX0ItVEVjHc
На второй фотке - его коллега по команде, Jason Gregory, всё оттуда же из сони, нотидог, тоже пилил дрейкфейс, автор книги Game Engine Architecture/
Оба они - главная причина влажных дрочек сониблядей из /cg/ по ночам.
1. Какого-то хуя билборд не генерируется снова после смены цвета через метод Terrain.terrainData.SetTreeInstance, а только через установку всего массива деревьев в Terrain.treeInstances ? Баг?
2. Раз SetTreeInstance не вариант при смене цвета, то мне каждый раз весь огромный массив из 10000 деревьев ставить? Насколько это затратно или может одна установка массива лучше чем сотня вызовов SetTreeInstance? В документации что _конкретно_ делает и регенерирует каждый метод нет.
3. Какой лучше использовать подход, чтобы расширить свойства деревьев? Допустим я хочу хранить где-то жизнь и возраст каждого дерева. Пока в голове висит вариант вести параллельный массив к массиву всех деревьев и в нем уже структуры с нужными свойствами. Звучит достаточно костыльно и нихуя не ООП, но как быть еще? Как привязать к деревую нужную структуру данных?
Подскажите начинку для .gitignore, пожалуйста.
Стандартный, который предлагает github выполняет свои задачи?
Пробежался по статье. Большая часть перечисленного - мастхев, который должен знать любой уважающий себя юнитидел большую часть перечисленного я узнал только на третий год разработки.
90% актуально и не для VR.
Не согласен только с заявлением про интерфейсы. Вот так и рождаются говнокодеры, оправдывающие свой говнокод мифической прибавкой в 0,002% к фпс.
Тут анон пишет
>>628300
>, публичные свойства - с большой
Он прав? В юнити они вон с маленькой, да и этой статье они с маленькой
Ты путаешь свойства и поля. Свойства:
>public Speed { get; set; } = 10;
Поля:
>private speed = 10;
Свойства имеют геттер и сеттер и пишутся с большой буквы, обычно они нужны для открытия внутренних переменных внешнему миру.
Поля не имеют геттеров и сеттеров, пишутся с маленькой буквы и всегда должны быть приватными, за публичные поля в нормальном обществе сразу пиздят ногами. Используются для внутренней логики скриптов.
Почему во всех мануалах пишут публичные поля? Потому что долбоебы Чтобы они отображались в инспекторе юнити. Так пишут для простоты понимания ньюфагами скриптов, нормальные посаны пишут:
>[SerializeField] private speed = 10;
Тогда у нас получается няшное приватное поле с маленькой буквы, с ним не нахуевертить внешними скриптами и при этом оно отображается в юнити.
На самом деле таких тонкостей много, со временем понимаешь, что в мануалах часто пишут хуйню, просто чтобы максимально примитивно показать функционал не заморачиваясь лучшими практиками. Хочешь заморочиться - читай статьи и блоги программистов.
Да, тот анон прав, потому что это я.
Нет, почему же. Статичное следует тем же правилам, что и обычное.
Константы внутри клаcса - с большой буквы.
Константы внутри метода - с маленькой.
Но это уже менее устоявшиеся правила. Кто-то их хуячит капсом с подчеркиваниями.
Но важно понимать, что каждый дрочит как хочет. Можешь вообще изучать Swift и юзать эмоджи вместо названий переменных. Там можно.
А как их ограничить если большинство скриптов наследуются от MonoBehaviour? в котором уже есть пустые Update()?
или стараться по минимуму наследоваться от MonoBehaviour?
Синглтон не нравится. FindComponent тоже херня
Пытался гуглить но нашел только всякие MVC (а я не фанат этого паттерна - мой мозг не может думать видами и контроллерами).
Для поиска компонентов ничего лучше getcomponent не изобрели. Причем я предпочитаю писать ленивую инициализацию, а не засирать Awake. Получается не так чисто, но зато не будет лагов при инициализации сразу сотни объектов.
А для поиска абстрактного объекта сцены я угораю по servicelocator'у. Статический класс с глобальным доступом, удобнее синглтона, не имеет недостатков синглтона, легко переиспользуется. Поддерживает интерфейсы, в отличие от синглтона, что позволяет писать охуительные вещи. Имеет два недостатка (прячет зависимости и превращает ошибки компилятора в рантайм ошибки), за что адепты ентерпрайза нежно окрестили его антипаттерном. На мой взгляд для юнити это не применимо.
Название намекает - его лучше использовать для служб, существующих в единственном числе. Причем их даже не обязательно наследовать от monobehaviour. Я его обычно использую для кастомного логгера, ивент менеджера, менеджера сцен и сохранений и... Для игрока. Это наверное не очень хорошо, но охуенно удобно.
Для взаимодействий десятков объектов же ничего лучше observer'а нет. Пишешь свой ивент менеджер и подписываешь сотни объектов совершенно не парясь о перетаскивании их мышью. В юнити есть встроенный ивент менеджер, он чуть удобнее своего, но гораздо медленнее.
Всё зависит от задачи. Тут нужно в каждом случае индивидуально подходить. Либо ты делаешь лоадскрин, в котором всё инициализируется "трудолюбиво", либо юзаешь ленивую инициализацию и имеешь некоторые просадки фпс.
Этот принцип я запалил, например, в ведьмаке втором (подчёркиваю, втором). У меня была слабая машина тогда и была такая тема: Когда идёшь медленно и находишься в пределах локации (чанка), то игра работает нормально. Когда начинаешь ускорятся, то при смене локация начинаются лаги. Если во время лагов притормаживать, то игра продолжается. Если пришпорить плотву и втопить - врубается лоадскрин.
Плохо понимаю, чего ты хочешь. Рисовать пальцем на экране, чтобы потом корабль летел по нарисованной траектории?
Я бы просто каждый фрейм ловил положение пальца и говорил кораблю: лети в данную точку имея при этом такой-то velocity. Можно поиграться с rigidbody и менять направление с помощью addforce, для создания интересной инерции (в аркадном космосе, ага). Или без rigidbody брать текущий вектор направления и медленно поворачивать в сторону пальца.
Но он тогда при достаточно низкой скорости и быстром повороте будет интерполировать траекторию в линию. Если тебе нужно, чтобы он точно повторял траекторию, тогда лучше каждые n фреймов читать положение пальца, добавлять координаты в очередь, а кораблем просто облетать все точки очереди удаляя их с конца.
> о идее надо что бы один вектор как-то параллельно другому двигался, что ли
Вектор не двигается. Двигаются объекты и их движение в каждый конкретный момент можно показать векторами.
Я это к тому, что тебе надо записывать координаты пальца в массив, пока рисуешь жест. Затем этот массив использовать ка навигационный путь. Когда палец касается, записываем Х1 = 0, 0. Когда палец едет, периодически записываем Xn = Xn-1 + текущие_координаты. Когда палец отпустили - массив завершен и мы запускаем корабль, интерполируя его позицию с позициями точек в массиве.
>>628594
А я вот как понял его ^
Да мне на словах сложно объяснить, поэтому я привел в пример игру, можешь ее скачать и посмотреть как там сделано.
Сейчас у меня упрввление такое, я просто ловлю точку в которую мы тыкаем, и корабль летит от своей позиции к этой точке. Но на самом деле это не очень удобно.
В той игре сделано так, можно в любой точке экрана тыкнуть, но корабль остаётся на месте пока мы не начнем двигать пальцем. Когда мы начинаем двигать пальцем, корабль со своей позиции начинает повторять траекторию наших жестов. Таким образом можно из любой точки экрана управлять кораблем. По сути считываются вектора нашего пальца и как-то пропорционально передаются в игрока
Какой нахуй пэинт, я спэйс шутер делаю. Я просто проиллюстрировал как выглядит управление, которое я хочу. Пунктиры условные.
Сейчас он у меня вот так летает:
https://pastebin.com/weDZAUvK
Там по игрику его подымаю, что бы палец спрайт не закрывал.
Но недавно увидел в игре falcon squad круче управление, я его описал выше. Вот не могу додуматься как сделать лучше всего.
> Какой нахуй пэинт, я спэйс шутер делаю.
Такой.
Чтобы делать игры, сначала надо научиться делать программы вообще. Потому что игры это программы. Причем не самый простой их вид.
Так что брысь курить матчасть и чтобы пока не сделаешь свои пейнт, блокнот и телнет, чтобы и не заикался мне тут о спейс-шутерах!
действительно?
Я вот читал что есть ASO или как то так - короче продвижение под маркет, что так никуда не зайдёшь.
В принципе мой опыт с ютубом показывает что так оно и есть - даже имея канал мультфильмов мне приходилось скажем так покупать рекламу чтобы хоть куда-то выстрелить.
Ты знаешь что-нибудь про маркет - неужели правда сейчас всё ещё можно делать игры и надеяться что какая-то зайдет?
Это делается 5 строками кода. Не позорься.
У тебя неправильный подход к разработке. Без базовых знаний ты все равно не сможешь ничего сделать. Будешь все время просить написать за тебя игру? Серьезнее нужно относится к делу. Без труда не вытащишь рыбку из пруда.
>Я имел ввиду поля static. Приватные с маленькой, публичные с большой?
https://github.com/ktaranov/naming-convention/blob/master/C%23%20Coding%20Standards%20and%20Naming%20Conventions.md
А компонент должен вроде как то отлавливать эти события
Это имеет смысл, если у тебя десяток скриптов, опрашивающих инпут каждый апдейт.
Если же при нажатии на пробел у тебя прыгает и всегда будет прыгать один объект, нет особого смысла делать отдельный менеджер. Проще сделать одну проверку внутри этого же объекта.
>Если же при нажатии на пробел у тебя прыгает и всегда будет прыгать один объект, нет особого смысла делать отдельный менеджер
Открыв проект после товарища, обнаружил, что он изменил интерфейс под себя, и сохранил в репозитории.
В каком файле сохраняются настройки интерфейса?
До плюсов я ещё не доразвился, но тех знаний, что у меня есть, хватает, чтобы заявить, что плюсы - это мультипарадигменный язык. В нём нет жесткой привязки ни к чему. Хочешь ООП - вот те классы. Хочешь функционалки - вот те лямбды с замыканиями. Хочешь императивки - вот те модули с функциями и точкой входа.
Да я то сделал. Просто ваше отношение мудакское не переношу, чмыри.
https://pastebin.com/T2kKQXUu
Ты просто попугай, который бездумно копирует.
>Интерфейсы например помечают префиксом I
Я не помечаю. Потому что не вижу в этом смысла. Так-же и со всякими префиксами. Я просто не вижу смысла писать это. Это просто ухудшает читаемость кода.
От этого нет никакой пользы, но есть реальный вред.
мусор у тебя в голове, а в коде это просто еще один символ. если тебя бомбит от _, то для тебя придумали добавлять m
И да, он улучшает читаемость - потому что ты видишь с какой переменной ты работаешь - с локальной, глобальной, со свойством, статик или может у тебя там вообще делегат
>>628831
>1. ты и так знаешь что приватное, а что нет.
когда перестанешь писать хеловорды и начнешь писать серьезный код в сотни тысяч строк кода минимум - тогда и приходи.
Ишь знает он
>>628831
>2. тебе это не нужно знать.
нужно если ты хочешь узнать куда идут те или иные данные и кто что меняет.
Решарпер, конечно, дикая годнота, но помимо подчеркиваний он также навязывает динамическую типизацию, что полезно использовать в очень редких случаях.
Обе фичи я настроил под себя - количество копий, сломанных в спорах о данных случаях, намекает, что нет однозначного решения, а мое мнение не обязано совпадать с решарповским. Лично я вижу код без подчеркиваний более аккуратным и никогда не путаю приватные поля.
Кстати, кекнул от того, что в райдере 2019.3 подсказывают использовать динамическую типизацию, а потом у динамических переменных автоматом подсвечивают тип данных. И нахуя тогда нужно было писать var'ы?
>глобальная
С большой.
>локальная
С малой без подчеркиваний.
>статичная
Так же, как публичная или локальная. У них очень ограниченный юз-кейс, так что если у тебя в каждом втором классе статики путаются с локальными, ты что-то делаешь не так.
Константы с большой.
Единственный реально годный аргумент - возможность отличать аргументы функции от локальных переменных. Все остальное - самодроч.
К слову, если происходит путаница в переменных, класс нужно декомпозировать до тех пор, пока путаница не исчезнет. Независимо от тысяч строк.
>Ты просто типичный токсичный пидоран-полуёбок
>Что за решарпер? Он платный?
Ты напросился на простыню, приятель!
Пользовался бесплатным месяцем решарпера. Это расширение на студию, привносит тысячи правок, помогает в назывании переменных, дабы избежать срачей выше по треду. Ловит 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 накидывает налог! Это тысяча рублей просто подари им сукам! Как его избежать и что это за хуйня ебаная этот налог?
Дверь изнутри и не открывается. Ты её ломаешь нахуй.
Джоинты специально сделаны "мягкими", чтобы поддерживать механику поломок.
Тебе нужно не перетаскивать объект мышкой, а протестировать его поведение в реальных условиях, если у него не 10кк килограмм в массе, то мб он и не будет выпиливать дверь.
Проще всего не писать такой скрипт.
Как это можно проверить извне? Хранить список всех объектов-тегов1, список всех объектов-тегов2 и каждый фрейм делать перебор обоих списков и сравнивать их координаты/коллайдеры? Удачи.
Очевидно, что "объект с тэгом1 соприкоснулся с объектом с тэгом2" - это некий ивент, и ты отслеживаешь его срабатывание (в данный апдейт? за последнюю секунду игры? случалось ли вообще в игре?). Срабатывание можно легко написать изнутри.
Делаешь как описано выше и в момент срабатывания кидаешь ивент или ставишь глобальный флаг или посылаешь инфу куда надо. А дальше твой менеджер либо ловит ивент, либо делает проверку, но не как описал ты, а по выставленному флагу, меняемому в момент срабатывания.
А, но если тебе нужно проверить соприкосновение двух конкретных объектов, и ты знаешь, каких именно, то перебор двух коллекций делать не нужно и можно придумать какую-то особую логику. Но готовых вариантов никаких нет, так что быстрее и проще придерживаться первого варианта.
Чел удерживает кнопку мыши, и отлавливается его движения. Если чел ухватил дверную ручку и куда то движется, то дверь ведет себя так, словно чел реально ухватил дверную ручку. Если идет назад - дверь закрывается, например. Я не могу сообразить, как такое сделать, точнее, идеи есть, но реализация сложной получается.
В SOMA, например, чтобы открутить вентиль, надо по кругу мышкой елозить.
Поэтому я хочу сделать так: тупо отлавливать колесо мыши. Если чел подошел к двери и крутит колесико - то дверь медленно открывается (или закрывается).
Нормальное решение?
Просто изи, в определённые моменты (к примеру нажал на нужный обьект), считываешь движения мыши, типо если игрок тянет её с зажатой клавишей влево то дверь закрывает, если в право то открывается, ну ты понел да? Это дело модифицируешь формулой и делашеь что те надо, к примеру опять же добавляешь силу к физ обьекту(двери) с вектором направления в нужную сторону, ну короч суть ты уловил.
Пацаны, как сделать чтобы кнопка со своим спрайтом кликалась только когда мышь над спрайтом, а не над всем квадратом? Ну, например, когда спрайт в форме круга. Там вроде нужно включить use sprite mesh, и в импорте картинки mesh type tight, но не работает.
Есть одна игра, нужны шейдеры (обводки и нормал мапы генерируемые), ничего прям криминального, воду или лавовые взрывы генерировать не надо.
Я бы сам сделал, но у меня не очень получается.
Unity LWRP с шейдер графом если что.
Если есть желающие помочь, то пишите: moonroll.art@gmail.com Не бесплатно офк
это нужно читателю твоего кода который не знает твоего кода.
>>628899
>И в самом деле, зачем нужны эти префиксы, подчеркивания, если все можно разграничить строчной и заглавной буквами
У тебя есть класс. В этом классе есть приватные члены и публичные свойства. Допустим ты приватные переменные пишешь со строчной, свойства с заглавной...
А теперь у тебя есть метод класса, в котором есть локальные переменные (все то что будет объявлено внутри функции, а также аргументы).
Скажи как ты их отделишь от приватных членов?
А вот если бы ты помечал приватные члены _ или 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 версии в следующем году юнити наконец-то сможет осилить миллион кубиков)
вообще я не проверял сделали ли уже аниматор для ECS чтобы делать такое щелчком пальцев. рендери лучше. рендерить то не проблема. проблема чтобы двигалось.
>>629392
>Юнити из каробки даже миллион кубиков не прожует
да жует оно всё. помню некоторое время назад в тред выкладывал сортировку где обана и рендерилось 100к кубиков. ниче особо не поменяется если 1кк рендерить.
Так есть что-нибудь бесплатное? И чтобы в этом было не сложно разобраться
Пять тактов процессора в гугле: https://www.jetbrains.com/ru-ru/decompiler/
DOTS канает если у тебя много объектов и на них много логики и бутылит именно в неё. То есть если ты делаешь RTS в духе суприм командера или какой-нибудь другой мясной Alien Shooter, где сотни юнитов/мобов набигают.
Если у тебя упирается в рендер - тот тут уёбс не поможет.
Юнитипараша во всей красе. Какое же юнитипидарье жалкое
http://unity3d.ru/distribution/viewtopic.php?f=105&t=49626
>Ебанутая специфичная задача, которую толком описать не можешь
Что ты несешь, ебанько? Есть кнопка в форме звезды на прозрачном фоне, нужно чтобы она кликалась только по звезде, а по фону нет. Если для тебя это специфичная задача, то ты конченный аутист-сын шлюхи.
Я не говорю не нужно в принципе. Ты совсем в глаза ебешься? Я говорю что это нихуя не типовая задача в UI, что бы ещё делать "ползунок в инспекторе". Решается одной строчкой с eventAlphaThreshold, но это же так сложно, это же код писать, а нужно всё на ползунках.
Типовая и есть. Загружаешь в кнопку свое изображение, оно может быть чем угодно, от просто прямоугольников со скругленными краями, до кружков, облачек и тд. Там полно галочек непонятно для чего нужных в кнопке и при импорте изображения стоит, пусть их все удаляют и кому нужно через скрипт включают. Есть поле advanced, туда бы вставили.
>галочек непонятно для чего нужных
Так бы и сказал, что ничего не понимаешь и разбираться не собираешься, а хочешь просто ассетов натаскать и получить играбельный продукт. Только так не бывает, и тут дело не в движке, а в голове разраба. Через eventAlphaThreshold эта задача решается элементарно и никаких проблем.
>Так бы и сказал, что ничего не понимаешь и разбираться не собир
Начал съезжать, сучка, с обсуждения проблемы перешел на личности. Понимаешь, вот я сначала сидел на годоте, и поливал говном юнити, так что вы тут верещали от боли. Стоит только начать что-то реально делать, как вылазят баги. Сейчас я, конечно, на юнити, после обсера хуана с рендером, в сраче треде поливаю годотеров, но все равно, как только начинаешь реально пытаться в игру, на самых начальных этапах вылазят баги. При смешивании анимаций, при клике блять на кнопку, это же элементарные вещи. Вот ты говоришь, что эта хуйня с кнопкой прекрасно работает, и на нескольких пикчах было все нормально, но внезапно на третьей пикче посмотри на вебмке, сетка спрайта будто смещена, почему так, ммм, уеба?
Так вопрос не в том, можно ли ее заставить работать, а в том почему две картинки идеально заработали, а третья мозги ебет.
В 99,9999% случаев это ты сам обосрался, просто нужно понять в чём. Очень удобно винить движок, и в юнити реально есть баги, но они совсем другого уровня и глубины.
Может у тебя разные какие-то настройки, разные форматы, просто опечатка где-то, хуй знает. Ну давай тогда и те, другие пикчи.
И ты в png спрайты хранишь все?
Какая разница в чем храню, я для теста сделал несколько картинок и все. У тебя заработала эта пикча, или ты так попиздеть?
Там из настроект только read/write галочку поставить, все.
Ну я кажется нашел обсер, у пикчи с боков есть пустые поля, если их кропнуть начинает нормально работать. Маска эта в левый нижний угол уходит
Я спросил, потому что пикча вот так импортнулась с ходу, значит ты в png какой-то хуйни (кроме собственно пикчи хуя) напихал.
Кликни на картинку и в импортере так как на пикче сделай. И это чудище мне еще доказывает что-то.
>>629537
Ну так ты расскажи, почему сетка сваливается в левый нижний угол, если там прозрачное поле есть? Может где в документации про это сказано, юнитипидар?
>>629539
Вы вообще по ходу тут нубье, про настрой импорта пикч не слышали, шакалы.
Именно так. Ниже объясняю этому неоссилятору что и как.
>>629540
У меня всё с ходу заработало, даже с учётом кривого 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/
вообще игра сделана на отъебись, и я не верю что там были какие то дохуя крутые самописные вещи, поэтому не могу понять, в чем же секрет?
Кто-нибудь знает, почему для спрайта в 2D такая схема наложения процедурной карты нормалей не работает, а для 3D обьекта работает?
>>629574
а хуй его знает. наверняка как всегда суешь не то не в ту конечную ноду. кстати разве там есть какие-то различия особые между спрайтом и не спрайтом? их же одним и тем-же шейдором рисовать можно.
Ого, вот это штукенцию ты собрал там, восхищаюсь :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))
то всё сразу стало проще
>>629588
вообще я его уже в тредах юнити показывал.
простенький однонаправленный нодовый редактор по типу шейдор графа этого, только не компилит все это в шейдор, а на цпу выполняет. сделал чтобы редактировать генерацию земли, как-то шумы накладывать друг на друга в массивах, полезное чет делать, параметры передавать. с многопоточностью, рефлексией, няшными аттрибутами и всё такое.
недавно потыкал-потыкал и понял что карты плосковаты получаются. а задавать какие-то четкие правила генерации мне не захотелось. думал-думал как же мне сделать всякие там горы и возвышенности и решил "а пускай компьютор за меня думает" и решил поизучать эрозию, которую давно хотел глянуть.
>>629591
наверняка как всегда какая-нибудь хуйня с UV координатами. наверно надо воткнуть какую-то ноду чтобы правильно читать че ты там сгенерировал? может быть?
https://assetstore.unity.com/packages/tools/utilities/blockchain-sdk-by-enjin-124133
>>629648
>>629649
Спасибки, мальчики!
Опустим генерацию подземелья, как осуществить поиск пути?
>>629671
В юнити нет встроенного поиска пути? Позор, пиздецский, ой стыд.
Подобным образом теперь хочу анимировать (я изменяю именно 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
и без всяких джойнтов
лол. на самом деле у меня вполне обычные навыки для человека который ушел несколько дальше базовых вещей.
то что я показал - умение дорабатывать юнити напильником и немного шейдорной магии совсем не требуют каких--то продвинутых навыков.
>>629663
https://ru.wikipedia.org/wiki/A*
настоятельно советую заимплементить его самостоятельно. как колдун навигации тебе говорю.
>>629773
тебе тогда Rigidbody.AddTorque уже наверно надо же. ты же крутишь а не толкаешь. но можно и аддфорсом конечно, перпендикулярно плоскости двери.
вообще да, приятно смотреть как машина за тебя песочек пересыпает. дрыгаемое значение это допустимое соотношение между высотой и шириной.
>тебе тогда Rigidbody.AddTorque уже наверно надо же. ты же крутишь а не толкаешь.
AddTorque вращает объект вокруг его origin'а. В то время как система джоинтов настроена так, что объект пол воздействием сил будет вращаться вокруг оси hinge joint'а прямо из коробки.
У меня в большинстве случаев AddTorque либо не работала, либо приводила в контринтуитивному поведению (именно в контексте джоинтов), так что ему нужно использовать как раз AddForce или AddForceAtPosition.
как всегда. продвинутые навыки, разумеется, это те навыки которые можно продать. те навыки которые получил занимаясь каким-то говном достаточно долго чтобы другие нихуя не понимали что за колдовство ты делаешь, или мочь сделать это в несколько раз быстрей и лучше чем другие.
а по поводу моей деятельности - тут нет однозначного ответа. я действительно подрабатываю в этой сфере, но не больше чем чтобы не подохнуть с голоду. так что скорее это что-то из категории увлечений, которое иногда становится профессией.
>>629871
всегда можно иметь пивот прямо на джойнте же и в целом это самый разумный способ взаимодействия с джойнтами. по моему в юнити так и не завезли приложение торка к какой-то конкретной позиции до сих пор.
ну и в конце концов джойнты можно крутить через лимиты, да. но там конечно надо понимать как колдовать с ротациями.
так то джойнты весело. много весёлого с ними можно сделать. могу показать забавную анимацию через лимиты. помню наверно года 3-4 назад тут был анон который всего человечка так анимировал.
>всегда можно иметь пивот прямо на джойнте же
Как? Я видел только два решения:
- Редактировать модель самостоятельно или заранее ставить ТЗ с четко обговоренным ориджином.
- Пихать объект внутрь пустого геймобжекта с необходимым отступом.
Мне категорически не нравятся оба способа. И я подозреваю, что AddForce - ожидаемый разработчиками способ взаимодействия с джоинтами. Когда ты телом игрока толкаешь дверь, ты прикладываешь не вращение, а силу. Скриптами ты должен действовать по аналогии.
AddTorque я использовал, когда писал полностью самостоятельные двери без джоинтов с настроенным ориджином и, откровенно говоря, они получались хуже оригинала.
в целом второе решение - правильное. едва ли не все интерактивные предметы требуют коррекции позиции(и не только её). так что как правило следует подготавливать префабы разделяя объекты которые отвечают за визуализацию, за физон, за что угодно. нет ничего зазорного в использовании геймобжектов как "папок" в сцене. и как правило это очень ускоряет дальнейшую работу с ними. 111 скейл самого верхнего объекта решает огромное количество проблем, например.
хотя, конечно, это не применимо ко всем случаям.
что касается способа взаимодействия - ваще похуй, до тех пор пока это происходит через физон. это целиком зависит от контекста. торк в работает более предсказуемо, так как точка приложения усилия это то на чем легко проебаться.
если то что прилагает усилие - какая-то виртуальная рука игрока, или конкретная точка то я бы и вовсе прилагал усилие через джойнт висящий на руке игрока. так как там можно настраивать плотность киселя который замедлял бы движение при близости к анкору.
а сильно ли надо где-то про это читать? открой юнити, потыкай там конфигурабл джойнт. джойнты же могут магнитить одно к другому. для держания/хватания самое заебись. много че сделали искаропки, типа скейла массы между объектами.
попробуй спроси у гугла ченить типа "unity portal picking holding", в портале же предметы на физоне в руках болтались.
небольшой видосик в тему хватания держания предметов.
Выйду ночью в поле
с конем
Ночкой темной тихо
пойдем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Мы пойдем с конем
по полю вдвоем
Ночью в поле звезд
благодать
В поле никого не
видать
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Только мы с конем
по полю идем
Сяду я верхом на
коня
Ты вези по полю
меня
По бескрайнему полю
моему
По бескрайнему полю
моему
По бескрайнему полю
моему
По бескрайнему полю
моему
Дай-ка я разок
посмотрю
Где рождает поле
зарю
Ай, брусничный цвет
Алый да рассвет
Али есть то место,
али его нет
Ай, брусничный цвет
Алый да рассвет
Али есть то место,
али его нет
Полюшко мое,
родники
Дальних деревень
огоньки
Золотая рожь да
кудрявый лён
Я влюблен в тебя,
Россия, влюблен
Золотая рожь да
кудрявый лён
Я влюблен в тебя,
Россия, влюблен
Будет добрым
год-хлебород
Было всяко, всяко
пройдет
Пой, златая рожь,
пой, кудрявый лён
Пой о том, как я в
Россию влюблен
Пой, златая рожь,
пой, кудрявый лён
Мы идем с конем по
полю вдвоем...
Получается фрилансер?
Прости, что лезу с допросами, но почему не найдешь себе постоянную работу программистом? Мне всё еще кажется ты без проблем бы нашел себе место в любом достойном проекте с такими навыками и знаниями.
Или ты пилишь свой проект мечты какой-то?
Я не он, но отвечу. 80% геймдева в снг - мобилкоговно в духе 3 в ряд и онлайн казино. 15% оставшегося - браузерки и интерактивные системы для бизнеса. Уныние и боль.
В оставшихся 5% конкуренция и требования настолько бешеные, что быстро подскочить представляется проблематичным. И требования там зачастую выдвигаются очень узкие. Проще пилить самому игори по фану, чем удрачиваться неинтересными бездушными проектами.
Т.е нормальных игор не делают. Что там было за последнее время, метро да пасфайндер.
Открываем студию и организуем какой-нибудь мегапроект чисто под СНГ-аудиторию. Вроде танков или фортнайта со специфичным колоритом и шапками-лутбоксами. Проект должен выстрелить, тут зависит от маркетинга и удачи.
Итак, у нас будет свой фортнайт с блэкджеком и шлюхами, многие в него пойдут, потому что тут будет свой пацанский колорит, который чужд буржуям. Тут главное продумать сеттинг - на ум приходит совок и красные-белые, царская Россия, Сталкер (заезжено пиздец, но ещё можно придумать что-то оригинальное), вторую мировую лучше вообще не брать, слишком заезжено.
И открываем свою платформу, продаём игру эксклюзивно на ней только на территории СНГ. Будет магазин от "наших" для "наших", и не нужен никакой Габен с буржуями.
Туда же принимаем всех инди. Произойдёт сразу расцвет инди в СНГ и поднятие индустрии с колен, а мы заработаем много денег, т.к. ниша не занята от слова совсем. Идём чисто по стопам эпик геймс.
Я вам охуенную бизнес-идею подкинул, как реализуете, заплатите мне роялти (а то по судам затаскаю).
>80% геймдева в снг - мобилкоговно в духе 3 в ряд
Уже давно перешли на 3Д игры. Всякие хорроры, сурвайвалы, сетевые игры.
>Проще пилить самому игори по фану, чем удрачиваться неинтересными бездушными проектами.
Что это за игры такие? И почему ты не можешь по фану сделать моб игру и зарабатывать на ней баксов 100 в день?
>Уже давно перешли на 3Д игры. Всякие хорроры, сурвайвалы, сетевые игры.
Возможно. На игры перешли, а разработчиков новых почему-то не ищут.
>Что это за игры такие? И почему ты не можешь по фану сделать моб игру и зарабатывать на ней баксов 100 в день?
Так я и не говорю, что по фану - обязательно бесплатно. Посыл в том, что дома ты можешь пилить то, что интересно тебе, а на работе с большой вероятностью это будут клоны-кликеры.
Пока это выглядит так, что Юнити вообще не рассчитана на нормальную работу с динамичными тенями, и больше подходит для мобилкогейминга и инди со стилизованной графикой вообще без теней. Это так?
Свет - очень обширная тема, тянет на отдельную профессию. Из коробки действительно получается говно, а в настройке очень много подводных.
У URP (LWRP) довольно паршивая поддержка реалтайм теней. Хоть они и позиционируют себя универсально, но лучше оставить его для мобилок и казуального графона.
HDRP, в свою очередь, имеет хуеву тучу настроек из которых можно сделать конфетку.
Да, посоветованный постпроцессинг помогает картинке, но не конкретно с тенями и светом.
Спасибо, что даешь ориентиры, это то, что мне сейчас нужно.
Как я и думал, пора вкатываться в HDRP.
К слову, сейчас меня больше всего обеспокоит peter panning (тени находятся на расстоянии от объекта), shadow acne (жуткий баг, появляющийся при попытке исправить первую проблему с помощью bias) и низким разрешением теней в целом, особенно при удалении от источника света.
>>630084
Спасибо. конечно, но я не очень понял, как это может конкретно с тенями. Так что тут я соглашусь с аноном выше, который сказал, что:
>постпроцессинг помогает картинке, но не конкретно с тенями и светом.
> как ты перемещаешься персонажем?
При получении данных с устройства ввода я начинаю плавно увеличивать скорость в направлении перемещения, до тех пор, пока скорость не станет максимальной. При исчезновении данных с устройства ввода я начинаю плавно уменьшать скорость, немного быстрее, чем до этого наращивал.
Во первых, ускорение-торможение уже придумано в виде переменной gravity в input'е.
Во-вторых, я спрашивал про конкретную функцию, которой ты заставляешь объект двигаться. Я это к тому, что в юнити достаточно способов передвинуть объект игнорируя физику мира. Если ты используешь один из них, то дверь, естественно, не может устоять перед объектом, который телепортируется прямо в нее, и начинает пидораситься.
Конешно. От лучшего к худшему:
1. rigidbidy.AddForce. Неудобно настраивать для аркадного управления, ибо адовая инерция. Зато крутые реалистичные перемещения физических объектов (если ты пилишь космические симуляторы).
2. rigidbody.MovePosition, rigidbody.velocity. Удобно настраивать, но нереалистичное перемещение без инерции. Обычно это то, что нужно. Инерция допиливается самостоятельно.
3. Character controller. Классика. Удобный компонент исключительно для перемещения персонажей, но не принимает в расчет физику. Обычно на нем строят FPS-контроллеры.
3.5. NavMeshAgent. Для point-n-click систем. Тоже игронит физику, но там можно играться с обходом и толканием препятствий.
4. Манипуляции с трансформом. Для месье-извращенцев.
>>630319
Не, не то. Прогулялся по коду, а батчинг у меня уже включен, хотя и работает через раз за счёт не помню уже каких ограничений в пропертиблоках.
Слишком слабый комп. Сделал тыщу моделек на одной сцене, загрузка ЦП под 95%. Ну не буду же я их все в один меш объединять ради СЕБЯ одного, это слишком много оптимизации для корректной работы на ржавом железе. У них и анимации, и прочая чушь.
Из игр на юньке похожего жанра и, следовательно, похожих игродизайнерских решений, которые пробовал сам играть, Тирания стабильно вылетала в городе с водопадами из-за нехватки ЦП, а Тея едва играбельна с теми самыми 95% загрузки. Стоит ли мне вообще с этой проблемой заморачиваться?
Очень неудобно когда открываешь что нибудь из секции widows переключаться на главный моник и перетягивать окно обратно на тот, на котором работаешь.
Ньюфаг на связи.
У меня сцена состоит из нескольких зон, которые могут стыковаться друг с другом рандомно (планирую их из префабов загружать и расставлять на сцене скриптом). Пикрелейтед, вид сверху.
Как быть с запеканием освещения? Можно запечь его для префаба, как бы для сцены внутри сцены? Или из-за динамического окружения я сосу?
Как правило - нет. Симуляция физики несовершенна, и если 60-килограммовый персонаж слегка заденет легкий объект, результат будет не из лучших. Куда важнее правильно настроить Drag.
Проще настроить несколько предметов, чтобы их взаимодействия через массу смотрелись органично, а затем подгонять остальные объекты под них.
ну как можно сделать одну фичу и получать пару десятков багов совершенно в других местах?
Я бы понял если бы ошибки были связаны с новыми фичами (новый код, все дела)...но ошибки рандомные, никак не связанные.
Я бы понял если бы движок только вчера сделали, и до сих пор не обкатали... но движку уже больше 10 лет
Да еще и баги в разных версиях из близких областей - то есть один баг пофиксили, а один оставили на будущее?
Или еще забавней, это переходы на новую версию - вот была 2019.3 альфа. все вроде затестили, перенесли в бету и тут в 2020.1а опять сплошной поток багов, как? они еще даже фич не успели туда добавить.
Даже возникает такое ощущение что у них есть специальный спец задача которого наделать 10500 ошибок чтобы в следующей версии патчноут был не из одной строки, а из 10500 фиксов багов (создаем видимость работы, да)
А ведь я смотрел код юньки (ну 4 версии) - он был вполне себе годный, без всяких там хаков и прочей вуду-магии после которой код бы падал по средам в полночь в дождь.
Так что реально кажется что баги делают умышленно
Пацаны, котята, помогите, как сделать увеличение скорости при таком 2д свайп контроллере:
https://pastebin.com/3NNuyWdQ
В скрипте понятно в чём ошибка и почему багует, игрок при каждом щелчке по экрану отлетает в сторону кратно скорости, но зато после этого движется ускоренно и плавно, как надо. Все другие способы которые я пробовал, делают движение либо ломанным, либо не точным.
С меня тонны нефти.
Как лечить такое? раньше этого не было. мало того что теперь когда я создаю скрипт в юнити редакторе, он показывает такой вопрос, но и он еще перетирает все несохраненные файлы (я так целый скрипт потерял:( )
Можешь попробовать снести все нахер и начать с установки юнити. Он вроде умеет VS сам накатывать.
Пройдись по всем настройкам юнити, проверь, что VS выставлен стандартным редактором. Проверь package manager, там есть расширения для VS.
Была такая же проблема, не помню, с чего началась и чем закончилась.
Есть группа обьектов с круглыми 2D коллайдерами на них.
Есть игрок, который перемещается среди них.
Задача- сделать так, чтобы мы тригерели ивент на входе во всю эту группу и на выходе из всей группы.
OnTriggerEnter2D срабатывает на каждом этом обьекте по отдельности.
А нужно один раз его вызвать на входе в такой тип обьектов и один раз на выходе. Типа проверять, остался игрок внутри них или нет.
Что может быть проще? Добавь int в игрока, или в твой менеджер коллизий, или в игровой менеджер. При заходе в триггер инкрементируй, при выходе - декрементируй. В таком случае условие "вошёл в группу" срабатывает только при смене 0->1, а " вышел из группы" - при 1->0.
Б-же, оно сработало! Спасибо тебе дорогой!
Я целый час ебался и пробовал писать 100 разных вариантов, а все оказалось так просто, я в ахуе.
В интернете вообще не встречал таких систем ни разу, спасибо тебе, спас меня!
Все равно плохо. Что за магическая константа 33? А если ты захочешь сделать открывание на 40 или 45? Будешь каждый раз в скрипт лезть? А ну марш выносить константы в сериализованные переменные!
Алсо, пилю лайфхак. Твоя система плоха тем, что не учитывает положение игрока относительно двери. Игрок интуитивно будет ожидать одного, подходя к двери с разных сторон, а получать - другое. Вот как это решил я.
Передаешь в скрипт управления двери данные об игроке (или камере). При удерживании двери накладываешь силу на дверь:
force = player.transform.forwardInput.GetAxis("Vertical")+player.transform.rightInput.GetAxis("Horizontal");
При клике по двери игрок толкает ее вперёд: force=player.transform.forward*pushForce;
Таким образом игрок может открывать, закрывать и быстро толкать дверь.
С такой системой можно делать рычаги и сундуки, если догадаешься, как менять векторы направлений в зависимости от типа взаимодействия.
Ну а чё ещё делать, у меня больше нет увлечений. А так да, депрессую. Особенно когда хочется проект попилить, а мозг устал, и я сижу кинчик смотрю
Quaternion.FromToRotation(transformA.position, transformB.position) не туда поворачивает почему-то. Дебажить кватернионы я не могу, надеюсь на какую-нибудь встроенную функцию. Заранее спасибо.
>Дебажить кватернионы я не могу, надеюсь на какую-нибудь встроенную функцию. Заранее спасибо.
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.
возьми вектор, поверни его на кватернион, отдебаж вектор.
алсо на той-же странице. какая из перечисленных функций описывает то что нужно тебе? кубик надо совать в круглую дырку, квадратную, или треугольную?
>LookAt
на самом деле так себе затея пользоваться им. колдовство дельта-ротаций куда лучше. FromToRotation - правильный ответ.
>>631439
суешь векторы, получаешь ротацию на которую надо умножить вектор А чтобы получить вектор Б. понимаешь? то насколько надо повернуть один вектор, чтобы получить второй вектор. поворачивание через оператор умножения. в эту функцию суешь не позицию. а вектор. направление. куда он смотрит.
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 вектора. это будет куда приятней результат.
ты это. у угла то проси. https://docs.unity3d.com/Manual/SpriteEditor.html
https://youtu.be/gbgIA3pwpHcю вдруг ты читать не умеешь
В геймдеве бешеная конкуренция. На опытного разработчика обычно собеседуют несколько десятков кандидатов. На должности джунов-ньюфагов мне даже сложно представить какой ад творится.
Особенно после того, как развелись всякие скиллбоксы и подобное дерьмо. Теперь любой долбоеб за трёхмесячный курс превращается в конкурентоспособного кандидата. Нужно реально сиять или иметь нехилую удачу, чтобы выделиться среди них.
>>631511
В течение недели чётко мониторь потраченное на геймдев время. Тебе может казаться, что ты дохуя работаешь, но не факт, что это правда.
Если ты тратишь 3-4 часа 3-4 раза в неделю, причём не только бесконечно учишься, но и занимаешься рутинной работой над игрой (диздоки, настройка сцен, префабов, света), то тебе потребуется ещё около 11 месяцев, чтобы работодатель тебя хоть как-то рассматривал как вариант.
Если ты ебашишь каждый день по паре часов, то может через 8-9 месяцев у тебя будет достаточно опыта для минимальной планки. Если ты ебашишь стандартный восьмичасовой день, в чем я сильно сомневаюсь, то у тебя есть шансы стать персонажем историй об успехе месяца через четыре.
Моя история - около года задрачивал свои проекты, активно при этом искал работу, еженедельно рассылая резюме в две-три компании. Ни-ху-я. В итоге вкатился обычным джуном программистом в левую контору. С тех пор уже наыармил прилично опыта, продолжаю ковырять юнити почти ежедневно, вырастил зарплату в два с половиной раза, но в геймдев так и не попал, лол. Отчасти потому что сейчас я обнаглел, прошу в полтора раза больше нынешней зарплаты и отказываюсь работать над казино и матч-3.
Я же говорю, обычный погромист. Сначала работал над умным домом, сейчас работа с банками в крупной корпорации. Скучно,но есть деньги и время на игрострой в перерывах.
Меня вштырило написание скриптов, и это стало моей основной профой. И несмотря на то, что под Юнити кодить я могу в разы лучше, чем под .net, предложений очень мало. В то время как обычные конторы меня с руками отрывают, лол.
эти функции будут далеко не везде, а вот проблемы ротаций всюду. например вот тот удивительный человек верху дверью хлопает, половину его удивительных проблем с джойнтами можно было давно уже решить с помощью колдовства ротаций.
или например видеорелейтед. помню наверно месяцев 8 назад тут был другой интересный человек, он хотел нажатием кнопки крутить кубик, но так чтобы оси его ротаций всегда были кратны 90. как решить эти проблемы? с геймобжектами ещё можно поколдовать немного. но далеко не все эти проблемы - проблемы геймобжектов.
>>631555
чё к резюме то прикладывал? какие проекты?
>чё к резюме то прикладывал? какие проекты?
Поначалу - ничего, а сейчас - гитхаб с полудюжиной рабочих библиотек под Юнити, написанных мной.
Портфолио определенно помогает, но если ты - хуй, на техническом собеседовании это вскроется.
Охуительные истории про годы поисков могут казаться преувеличением, но:
1. Казино и браузерки сразу нахуй.
2. Портфолио у меня не было около года.
3. Работать бесплатно я не готов.
Готов предположить, что если анон возьмёт себя в руки и за месяц выпустит с пяток топов продаж в гуглплее, то с трудоустройством проблем у него будет меньше.
да вообще чисто так интересно что другим людям показывал то, что были такие проблемы с поиском. на этой доске не часто люди делятся таким опытом.
лично у меня особых проблем не возникает, но мне и показать в целом есть что. вот только начинал я тыкать всё это как увлечение и проёбывал тонны времени на него без цели найти работу в этой сфере. а когда в животе заурчало то внезапно оказалось что мои скиллы в целом востребованы. так что я скипнул тот этап неопределённости и даже рассказать по этому поводу нечего. а вопрос то важный.
Недавно, к примеру, собеседовался в одно место. Рекрутер разоткровенничался и сообщил, что я у них 47й кандидат. Ищут человека второй месяц.
Пиздеть ему смысла нет, меня все равно не взяли. Разговаривал он открыто.
И это компания, ищущая специалиста с 3 годами опыта работы с разнообразными навыками и узкими критериями.
А теперь представь, какой поток людей на стартовые вакансии. Любой человек полгода потыкавший кнопки в юнити уже мнит себя специалистом.
Это относится к неквалифицированному труду в основном. Когда я менял работу меня буквально завалили спамом с предложениями (не геймдев).
Все хотят себе погромиста, который уже что-то умеет, но ещё не нюхал настоящих денег. Он за копейки вьебывать будет и ещё и довольным останется. Я эту фичу просек и теперь на собеседованиях требую зарплату на 30-40% дороже, чем себя оцениваю сам. Поэтому меня никуда не берут, лол.
https://docs.unity3d.com/Manual/class-Cloth.html
возьми ткань и запили через неё.
Там по наступлению ивента вызывается функция, которая выполняет detectedObjects.Remove(other.gameObject). Когда она будет вызвана, она удалит именно тот геймобджект, который был в контексте на момент подписки именно этой функции, я правильно понимаю?
Вроде все верно.
Протестируй, хуле ты. Всего-то кинуть в пустую сцену геймобжект, триггер и вызов твоего ивента. Получилось бы быстрее, чем пост на двач писать.
Алсо, защиту от множественных срабатываний не забыл на случай, если объект несколько раз входит в триггер? В курсе, что лямбды невозможно отписывать от ивентов оператором "-="?
Нет, не будет. Я буду.
ПЕРЕКАТ
>>631674 (OP)
>>631674 (OP)
>>631674 (OP)
Братан, была абсолютно такая же проблема.
У меня проблема была в том, что я вместо RawImage использовал простой Image (хз почему, но просто image не выводится на экран)
Ещё я установил размер канваса равный разрешению экрана.
Если хочешь, можешь связаться в дискорде, я тебе могу всё показать
Привет юнитологи, ищу вот такую книгу "Гейг - РАЗРАБОТКА ИГР НА UNITY 2018 ЗА 24 ЧАСА". Скиньте ссылку пж если у кого есть. Заранее спасибо