Скоро в юнити динамик ги, вау, майонез!
Ясно хуита, Годот лучше
/тхреад
Где шапка? Где ФАК? Хоть что нибудь? Почему так пусто и холодно......
лол могу показать категоризацию и группировку агентов по целевому вектору движения. я вот полез в очень интересную тему.
>>588462
>Как же будет похуй, когда уже месяца три, когда она не рендерится вообще в одном из двух скриптовых рендеров?
траву то и сам рендерить можешь лол.
>Меканим написан с ипользованием SIMD библиотеки и совместим с ецс, Animation C# Jobs выкатили ещё в юнити 2018
не я не про это. одно дело вычисление блендинга анимаций и новой позиции для костей, другое дело что скелетная анимация как правило требует наличие скелета и прочее говно, что не так и просто двигать исключительно на видеокарте. вертексы там дрыгать процедурно типа хвостиков у рыбок легко, а дрыгать гуманойдом уже не так легко.
>У меня инстансируется дохуя объектов в рантайме, так что я заменил пару строк кода на код инстансирования из гитхабовского демо. Юнити это переварить не сумела, а GC вообще обезумел. Но кубы спавнятся исправно, работают быстро. Нахуй кубы.
в душе не ибу что и как ты там делал, хули.
>И что? Это говно говна по сравнению с юнитековским ецс. Всю магию без переписывания крестового ядра реализовать было невозможно. Да они, блядь, свой компонент на трансформы вешают, а ты мне говоришь, что это то же самое.
под капот загляни. сделать карту говна и совать все в биты чтобы удобно было таскать туда-сюда не так и много мозгов надо, а хранится будет все точно так-же в нескольких массивах и структах.
>>588638
делегаты на кнопках тоже ецс да? а тексты как у UI элементах то хранить?
да ладно помню в позапрошлом треде был занятный человек который делал ИК у рагдоллов. интересно достиг ли он успеха.
могу вот ещё показать клевое решение проблемы встречи на углах через приоритизацию агентов, вроде не показывал. очень вот не очевидная проблема.
Хочу вкатить я в юнити, в частности в изометрию. Посоветуй годный тутор, чтобы там мир нарисовать квадратиками, двигать-шатать всего
literally https://docs.unity3d.com/Manual/Example-CreatingaBillboardPlane.html
только это не единственный подход. чё делать то хочешь? если только квадратики рисовать то шейдор ебош. синтаксис даже к самому юнити мало отношения иметь будет.
Захотелось сделать один 3д-проект, но анрыл вконец заебал насаждением блюпринтов, так что снёс его к хуям и поставил таки юнити. Всё оказалось не так страшно, как я ожидал, но вот только...
Блджад, почему тут всё так бедно? Вообще нихуя нет, никаких фич и удобств в редакторе, которые, казалось бы, должны быть стандартом де-факто давно. Тайлмапы делать - боль, анимировать - боль, всё через боль или хардкодить. И это самый популярный движок? Как так вообще?
>от уечебляди
Выползай из чёрно-белого манямирка. Я вообще велосипедист так-то, для основного своего проекта собственный движок использую.
А так я в основном на отсутствие удобных средств анимации жалуюсь. После годотовского плеера анимаций тут всё пиздец бедно.
плюс юнити в том что его функционал можно быстренько допилить где надо. сделать быстренько собственное окошко для редактирования собственных данных, перехуячить инспектор чтобы вместо говна и палок все сверкало и пердело, чтобы гизмосами всю сцену засрало. и это, кстати, в юнити просто заебись сделали. это как раз то чему надо учится после самых базовых вещей: сериализация в юнити, скриптабл обжекты, окошки, IMGUI.
например хопа понадобилось указать маршрут патруля. и хули, патруль чтоли вручную там массив точек редактировать? разумеется нахуй такое, быстренько набросал редактор, чтобы кнопку нажал все случилось, другое случилось, чтобы в сцене патруль рисовался и его дрыгать можно было. удобно же.
ну а фича с анимациями она как бы есть. анимировать открывание двери, нажатие кнопки и тому подобное то с избытком хватит. для персонажей то его никто в своем уме не будет использовать.
Ох, есть что-нибудь попроще для начала? Я практически 0 во всем этом, могу в графику, да слегка в программинг. Хочу пока просто экспериментировать, что-то типа песочницы-аркады, нов изометрии, т.к. не видел такого исполнения ещё. Понял что нужны ассеты, скачал несколько плиточек для основы, потом сам уж нарисую свои, пока просто бы понять куда тыкаться.
да ладно некоторые важные вещи теперь в пакаж менеджер суют. понадобилась хуйня для прототипирования уровней - ткнул "хочу пробилдер", понадобилось говно для камеры - ткнул "хочу синемашину", захотел графона - ткнул "хочу пост процессинг" и сразу всё как надо. и в ассет сторе куча бесплатных и платных инструментов на любой вкус. и самое то главное что новый функционал прикручивается легко и обычно не ломается с обновлением версии.
>>592012
если ты учишься, а не игры делаешь то ассеты тебе нахуй не нужны. в пэйнте хуй нарисуй и сойдет. если совсем ноль то хули, ты сам знаешь как тебе лучше учится. ролики там на ютубе посмотри, дохуилион всяких видосов "а сегодня мы двигаем куб", книжку прочитай. документацию почитай. официальный канал ютуба юнити наконец открой https://www.youtube.com/watch?v=Z0Z7xc18CcA&list=PLX2vGYjWbI0S9-X2Q021GUtolTqbUBB9B туда регулярно суют что-то.
да наверно и есть заточены под 2д говно то. для которого сейчас в юнити инструментов чуть ли не больше чем для 3д.
https://www.youtube.com/watch?v=2DsKCJsEzSA&list=PLX2vGYjWbI0TPcPOKW6GxwuY18eg7CjKZ
уж этого добра на ютубе то навалом.
у юнити в мануале горы золота зарыты
https://docs.unity3d.com/Manual/AdvancedEditor.html
особенно тут ваще заебись
https://docs.unity3d.com/Manual/ExtendingTheEditor.html
У меня есть идея создания игры, смести RTS и TD, но я понимаю, что мне не помешал бы еще один программист. У меня уже есть два человека, я думаю через месяц завершить стадию прототипирования.
Если всё будет хорошо, может быть хочешь присоединиться к нам потом? Зарплата тоже будет
Если что, не прошу ответа сейчас, я как закончу с прототипом напишу еще здесь.
В конце 6 главы там есть "УПРАЖНЕНИЕ: ИЗМЕНЕНИЕ СКОРОСТИ ГЕНЕРИРУЕМЫХ ВРАГОВ"
Как вы его решили?
Я сделал публичным OnSpeedChanged() у WanderingAI, а в SceneController для enemyPrefab и _ebemy поставил тип WanderingAI, чтобы после
_enemy = Instantiate<WanderingAI>(enemyPrefab);
добавить
Messenger<float>.AddListener(GameEvent.SPEED_CHANGED, _enemy.OnSpeedChanged);
Можно как-то по-другому сделать с большей инкапсуляцией?
Я не очень понимаю, как конструкторы работают с Instantiate? Их вообще используют?
Хуй знает че за таск, но я бы сделал корутину, которая принимает время на проход цикла, а в теле содержит инстантиейт, что-то типа
IEnumerator Zaloopa(float rpm){
while(true){
GameObject Hui = Instantiate (Resources.load("hui", typeof(GameObject)) as Gameobject;
Hui.transform.position = yourass.position;
Hui.transform.rotation = Quaternion.identity;
Yield return new Waitforseconds(rpm);
}
}
Спасибо, но там проблема в другом немного, если я верно понял твою мысль:
Есть класс WanderingAi. У него есть поле speed. В update он двигаетсч на значение speed.
При Awake() этот клас подписывается на эвент, связанный с изменением скорости.(есть приватный метод changespeed, который меняет скорость)
Есть класс настроек, где можно задавать скорость игры и, если это происходит, дёргается мессенджер и всем подписавшимся классам передается новое значение скорости.
Есть класс SceneController, он при каком-то условии создаёт новые wanderingai(там он представлен с типом gameobject). Но они не являются лисинерами мессенджер и изменение скорости на них не влияет.
Вопрос, как это поправить, чтобы это было максимально красиво?
Почему awake не используется после Instantiate?
Сори за опечатки, пишу с телефона.
Пусть Йоахим на этом сам попробует игру сделать. Типичный кукаретик не сделавший ни одной игры и не понимающий каким должно быть API движка. Зато в синтетических тестах быстро, ага.
Забавно, что когда в юнити делают свои мелкие демки вылезает куча неудобств и багов, из-за которых они перелопачивают движок. Юнити не приспособлен даже для таких мелких демок.
Набегайте, братцы, учитесь!
https://blogs.unity3d.com/2019/07/09/upgraded-and-updated-scripting-your-next-game-with-visual-studio-and-unity/
Хули ты такой токсичный?
Сделай скрин задания. Я приьлищительнт понял о чем ты, но там могут быть неточности.
Предварительно, я бы сделал так: в классе, содержащем метод changespeed создал публичный лист, куда бы помещал ссылки на вновь создаваемые wonderingai, а в самом методе пробегался по этому листу и менял значения в каждом wonderingai.
В классе wonderindai в функции Start пишешь типа:
Start(){
waiList.Add(this);
}
...
Awake вызывается единожды призапуске программы до загрузки сцены, причем независимо где в коде ты пропишешь вызов этой функции. Instantiate же можно вызвать только в загруженной сцене.
>Типа находимся мы вот в 3.12, а я нажал 1
При смене вкладки закрываются предыдущие начиная от корня
К примеру при открытии 3.1, он сначала закрывает 3,2 и 3,3 и только потом открывает 3,1
При переходе в вкладку 1, он закрывает 2,3, 4, причем при закрытии 1, должно автоматически закрываться 1,1 и 1,1,1
Делается просто, процедура заппускается при открытии вкладки каждый раз, памяти жрет минимум
Особенно тот где карты случайно генерируется в зомби дрпг, пиздец он там говно людям заливает, как такое пропустили
Лучше совсем никаких как в годоте, чем такие
>>592219
Да, так примерно и сделал. У меня вот есть инвентарь. Но ему нужен включенный геймобжект который при включении генерирует слоты инвентаря. Сейчас у меня этот обьект включается на старте и выключается функцией под инвоком спустя 0.1f, но на экране все равно это видно. Вопрос как эту инициализацию красивее запилить? Скрыть это экраном загрузки?
Нужно с помощью черно-белой маски jpg отображать картинку тоже jpg чтобы получалось обрезанное изображение
просто вычисляй нормаль в самом шейдоре, хули. тебя интересует кросс-продукт. https://en.wikipedia.org/wiki/Cross_product
https://www.photonengine.com/en-US/Server
А есть ли подобная тулза для обычных мешей? Может среди платных ассетов встречается? Inb4 сабстенс пейнтер, но хотелось бы прямо в движке (для террейна же сделали, думаю можно и для любых мешей в принципе).
Есть мультиплеер без сервера. Один из клиентов выступает главным. Если он выходи, то главный(мастер) клиент сменяется.
https://www.photonengine.com/en-US/PUN
Другие решения тебе не подойдут.
https://playerio.com/documentation/services/multiplayer/serverside
Туда можно загружать свою серверную логику. Но Photon, конечно, лучше заходит, особенно в риалтайм играх. И особенно для новичков.
Мой луч, который я отправляю от координаты (x, y, z) до (x, y - 6, z), ловит коллайдеры, которые находятся вообще в другом месте (например, в (x, y, z + 20) координате), и их коллайдеры в теории никаким боком не могут быть пойманы рейкастом. В чём может быть дело?
Или может знаете, где можно найти?
> Дело в том, что я привык, что начало системы координат начиналось слева вверху экрана (т.е. там должна находиться точка (0;0) ), но в юнити эта точка находится посередине
отвыкай, это говно из древних времён.
> А также там значения измеряются в своих "юнитах", т.е. 1 юнит = 100 пикселей, можно ли как-нибудь эти значения поменять,чтобы можно было измерять в пикселях, а не юнитах, и можно ли поменять расположения центра системы координат?
в настройках текстуры ставишь вместо 100 там пусть 32, если у тебя 32х32 основная сетка. потом крч у камеры масштаб задаешь в соответствии с высотой экрана и будет у тебя пихель перфект.
> можно ли поменять расположения центра системы координат?
нет. понятия "ЕКРАН" в юнети нету. там есть камеры и бесконечная плоскость.
из гамака вылез шоле
1) тупо хреначить драг-дропом аудиоклипы в паблик массив аудиоклипов скрипта и грузить оттуда
2) запихнкть в ресурсы и юзать LoadAll
3) писать через system.io с чёткой пропиской всех путей
Что делать?
>Что делать?
У аудио клипов с музыкой задай Load Type = Streaming.
https://docs.unity3d.com/Manual/class-AudioClip.html
https://habr.com/ru/post/437474/
>Каждый тип данных за исключением Streaming по умолчанию загружает звук в ОЗУ и оставляет его там, пока сцена не будет выгружена.
>Note: Streaming clips has an overload of approximately 200KB, even if none of the audio data is loaded.
Короче говоря, делай всё красиво, со ссылками на клипы. Без ебатни с ресурсами и, упаси господь, с system.io. Главное настройки покрути.
Если тебе надо мгновенной реакции, то объявляй классы игровых объектов в скрипте уровня как минимум (или в синглтоне открытого мира, который тебе динамически локации подгружает).
Далее логика такова:
Если (кабанчик != нулль) { ПустьКабанчикПорешаетВопросик( кабанчик, телДляСозвона ); }
Да сам я не использую сендмессадж. Его использует фреймворк с которым я работаю. У меня игроки иногда проваливаются сквозь объекты после спавна. Игрок спавнится на полу, у него Y = 0 и тут хуякс он летит вниз за пределы карты, игнорируя коллайдер пола. Такое в целом возможно, но только если сендмесседж будет получен с задержкой в несколько кадров, например.
Анон, что есть "красиво" и с ссылками на ресурсы?
Я пробовал сделать через корутины в связке с WWW подгрузкой из StreamingFolder - оно работает, память не жрёт, но любая смена музыки стопорит игру на добрую секунду - фриз на 1 секунду - профайлер указывает на корутину.
Сейчас ради интереса закинул посмотреть сколько будет жрать оперативы прямое назначение через паблик в едиторе эти клипы и загрузка через присвоение клипа к источнику музыки и последующим UnloadAudioData - вроде норм, не лагает, память освобождает. Какие тут проблемы могут быть? Что ты имел ввиду.
Да и вообще аноны, кто может сталкивался -как правильно юзать много локальных аудио материалов в игре?
Го к нам в Годот! Там нет таких проблем >>583342 (OP)
https://github.com/godotengine/godot/issues/23998
Yes, go к ним, 19FPS ждут тебя
23 года-с нульчика-кун
Что происходит с префабами лежащими в SerializedField геймобжекта при его создании? Они тоже все создаются? Можно ли сделать так, чтобы не создавались до первого к ним обращения?
Допустим, у меня несколько десятков сериалайздфилдов со ссылками на префабы, многие из которых тяжелые, но активными одновременно бывают один-два. Как тут быть?
Например
15000 => 9999 если n = 4
15000 => 999 если n = 3
Ответ кажется очевидным но я что-то туплю
>>595035
>Короч засунул n*девяток в стрингу и запарсил его в инт, вроде лучшего решения нет
Mathf.Max(value, Mathf.Pow(10, n) - 1);
Народ! Ну-ка скажите-ка мне, где скачать анимаций для персонажа, чтобы как в ГТА 5 было?
Сколько террэйнов можно в сцене делать? Как лучше: заебашить один террэйн и сделать на нем больше разрешение текстур и полигонов или много дефолтных террэйнов сделать?
https://github.com/nxrighthere/ENet-CSharp
Вот я хочу сделать так, дабы при выстреле из условной пушки у меня летел быстро шарик из дула в точку хита луча И ПОСЛЕ САМОГО ПОПАДАНИЯ ШАРИКА ПО ЦЕЛИ у меня делались разные вещи. Проще говоря, луч здесь используется как направление траектории полёта шарика и его конечная цель спавна, а не как точка спавна. Надеюсь понятно высрал что я хочу сделать.
Такое возможно сделать вообще? Есть какие-то подсказки как это реализовать, а то я уже не понимаю как это сделать.
Пока что да. В будущем и в едитор завезут, не ну а чо б и нет, это же неплохо. Особенно если сложную менюху можно будет заебашить на одном ректТрансформе чтоб сложная система не жрала ресурсы и не нужно было ебаться с разбивкой на канвасы, кешированием и прочим шлаком когда у тебя сотни элементов
Вроде гуглил, а чёт нихуя подобного найти не могу, только всякие автозаполняторы текста, которые просто пишут рандом хуетень и всю сразу, а не постепенно. На английском сформулировать мысль не удалось.
Может есть примерная конструкция для таких вещей?
нуфаг
RectTransform.anchoredPosition vs RectTransform.position vs transform.position vs RectTransform.localPosition vs transform.localPosition
Почему именно твой вариант? Или вообще похуй?
Пацаны, где эта хрень включается?
Не вижу никаких проблем, всё просто реализуется. Создаешь ГО, инстансишь к дулу, задаёшь ему нужные параметры (скорость,направление etc.), следом он запускается, на этом обьекте висит скрипт в котором вызывается функция тригеринтер либо клааидер стэй ор интер, посмотри что тебе надо и используй нужную функцию она уже родная от юнити, ничего велосипедить не надо, и в конце как только эта функция срабатует тобишь обьект(шарик) соприкасается с целью делаешь нужную действия, всё изи.
ориджин значит смещение координат вершин модели относительно нуля. чтобы сменить ориджин тебе нужно изменить положения всех вершин.
Может написать скрипт который работает с Mesh если хочешь. Может в пробилдере можно это сделать. Но я бы лучше в блендере изменил на твоем месте.
>ориджин значит смещение координат вершин модели относительно нуля.
В блендере или юнити? Я нахожу центр модели через (сумма трансформ.позишенов всех детей) / (число детей), вроде бы с ориджином не совпадает.
Да, запоминать и записывать ориджин из блендера звучит как самое простое решение. В любом случае спасибо, знаю теперь, куда копать.
>В блендере или юнити?
Везде. Ориджин всегда ноль в локальных координатах. Когда ты в блендере изменяешь ориджин объекта, например опускаешь его вниз модели, то на самом деле происходит транформация всех вершин модели когда они перемещаются на столько же вверх. Ориджина как отдельного свойства модели нет.
В принципе если очень нужно, то можно в вершинном шейдере добавлять вектор к каждой вершине.
>а ничего не получается, юнити крепнет
Хуепнет. Еще раз пост перечитай.
>Пока на анриле пилят какие-нибудь условные mass effect, DmC, серию batman, deus ex, на юнити пилят очередной три в ряд и прочий подзалупный творог.
Сколько бы он там не креп, шедевры продолжат делать на анриле.
> многословесность
Сокращай, шакал.
> низкоуровневость
> лягуха пизданулась вконец, несите следующую.
> ждать компиляцию при любом изменении
Пекарню обнови.
> Хочу писать игры на javascript или lua.
Неее. Ты хочешь прокрастинировать. Постоянно изучать новые движки, оттягивать момент, когда надо уже начинать делать игоры.
> скриптовые динамические языки
Ой, всё, INSTALL GODOT и проваливай из треда.
>Это как всю жизнь прожить с закрытыми глазами, а потом внезапно тебе в губы упирается толстая запашистая сордэлька (хуй).
>Для игр нужны скриптовые динамические языки.
Ты скозал? Нет, не нужны, скриптовая динамическая дрисня не нужна, это прямой путь к тормозным и глючным играм. Строгая типизация исключает баги и косяки на этапе компиляции, позволяет писать софт, который не вылетает и не падает.
Если не хватает мозгов осилить полноценный код, пили логику на блюпринтах.
Это говорит мой опыт разработки игр. У программирования игр своя специфика и правила программирования для бизнеса здесь неприменимы. Для бизнеса главное надежность и поддержка кода, а для игр главное скорость разработки и частота итераций.
Одно только ожидание компиляции и типы замедляют разработку во многое число раз.
>>596627
> static typing
> алгоритмы
Чего вы за хуйню несете, тупые мамкины выродки, которых из ПТУ исключили? Static typing языки были придуманы для того, что бы не тратить время на бессмысленный дебаг такой мелочи как опечатки, неккоректное наследие типов или преобразования, и т.п. Это вообще ничего общего ни с алгоритмами, ни с парадигмами (прерогатива CS) не имеет.
Это как иметь ручку для ножа, вместо того, что бы хвататься за голое лезвие. Однако ручка не научит тебя арт выстругивать из дерева
>если человек шарит в алгоритмах, он и на динамическом языке может конфетку сделать.
Может, но это в разы сложнее, зачем рвать себе очко, если можно получить гарантии на этапе компиляции?
На динамическом языке проще и быстрее накидать что-то небольшое, типа скрипта на 50 строк, а при разработке большого проекта это только замедляет.
При статической типизации ты открываешь любой файл из нескольких сотен, и сразу видишь, какие типы данных на входе, какие на выходе, сразу в голове выстраивается полная картина. В динамической дрисне такого нет, ты открываешь код, который сам же писал пару недель назад, и начинаешь плыть, потому что не помнишь, какие данные приходят в метод, в каком формате, с какими ключами, и чтобы выяснить это, нужно или писать руками комментарии к каждому методу, как макака делая руками то, что дает автоматом статическая типизация, либо разгребать кучу файлов, восстанавливая в памяти цепочку вызовов.
>>596631
>Значит чловек сам криворукий долбаёб, если он умудряется попадать в аварию при езде без ремня и вылетать через лобовое стекло, пропахивавя ебальником об асфальт два десятка метров
> а то человек может забыть добавить лишнюю скобочку и создать продукт, который будут падать и зависать.
Как раза таки опечатка в статическом языке отлавливается на этапе компиляции и делает невозможным попадание таких багов в продакшен. Так что ты опять поссал себе на лицо, зачем ты так с собой?
Есть один спавнер префабов ака говнокод на подобие каста фаерболлов и он во время броска префаба по лейнкасту в игрока дамажит его 2 раза, хотя спавнится всего 1 префаб. Самое забавное, когда происходит типо смерть - он дамажит игрока 1 раз как положено, лол.
Код проверял, ссылки смотрел, префаб чуть ли не с лупой сидел разглядывал - всего 1 итерация нанесения урона и всего 1 спавн префаба на кадр. Где я проебался? Раньше мне от этого помогал костыль в виде задержки в спавне длинною в атак кулдаун, но чёт оно перестало помогать.
Пикрл 1 - скрипт реакции на коллюжн, пикрл 2 - сам лейнкаст и спавнер префаба, пикрл 3 - вырезка из скрипта АИ самого моба, где и происходит вызов самого начала цепочки методов. Да, я тупой даун и держу всё это в 3-х разных скриптах.
Какую хуйню? Я написал что из моего опыта динамические языки лучше подходят для кодинга игр. Игры пишутся быстрее и легче чем на C#. Недостатки отсутствия строгих типов сильно преувеличены.
Это начал верещать что-то. Попробуй написать хотя бы одну игру на lua или gdscript, а потом повтори это мне в лицо что я пишу хуиту.
Спасибо.
Я лучше сделаю scale сразу всех объектов, когда дом целиком будет готов. А в блендере я просто буду делать объекты с реальными размерами своего дома, а не делать на глазок и не тягать каждый раз новый объект в Юнити, чтобы посмотреть, как он отображается.
Например, эту комнату в блендере я создал с вполне жизненными размерами 7.6x3.6x2.5м. В сравнении с кубом в этой комнате, который имеет размер 1x1x1, это прослеживается. Потом создам стол, и тд
Я уже писал об этой проблеме, что в юнити все мелко >>595972 мне посоветовали настройки камеры покрутить, но я еще не пробовал, потом. Вроде field of view за это отвечает,
https://blogs.unity3d.com/ru/2019/07/30/heres-whats-in-the-brand-new-unity-2019-2/
>We have over 1000 developers dedicated to extending and improving Unity for you
>ProBuilder 4.0 ships as verified
>Polybrush is now available via Package Manager
и еще куча мелких фиксов. самым большим изменением является инкрементный сборщик мусора.
охуенно 1000 дармоедов за полгода фич наделали.
Когда импортирую модель (из блендера или с Mixamo), обычно armature видно в иерархии и можно цеплять к отдельным костям всякое.
Что произошло сейчас не вдупляю - костей нет в иерархии, анимации каким-то раком работают, что за магия?
Как мне вынести кости в иерархию, чтоб их было видно?
Это реалии разработки, я делаю сайты на реакте, кодовая база так разрослась что я боюсь что то менять или внести фичу что бы что то не поломать, внесение фичи занимает все больше и больше времени.
Например разработчику нужно внести фичу в движок, но в коде объекты между собой взаимосвязанные, это значит что изменения в одной части кода будут иметь последствия на другие части кода, а так как в движке миллионы строк кода то разработчик в душе не ебет где там и что там может поломаться.
Что бы такой хуйни не возникало нужно в 2-5 раз больше времени на разработку движка, нужно в раз несколько лет переписывать движок под новые фичы, инвесторам это не выгодно ведь нужно побыстрее выкатывать фичи и обновления.
Во-первых, юнити это движок, а не конечная программа для пользователя, и юнитеки не могут переписывать движок постоянно как раз потому что у них есть пользователи, у которых от таких манёвров слетит всё нахуй. Это наоборот умный подход, что они вместо полных перелопачиваний выпускают модулями новые фичи и оставляют всё старьё у коде ради совместимости.
Во-вторых, юнитекам не нужно переписывать движок с нуля чтобы ввести какую-то фичу. Да-да, в отличие от годота юнити сделан хоть по каким-то стандартам качества и отвечает заявленным требованиям, модульный и вообще как раскладушка. В отличие от некоторых они могут ввести ЕТЦ, и у них не отвалится от этого ВСЁ.
В-третьих, скорее всего юнитеки не могут просто взять и выкатить официальную фичу, которая бы копировала фичу, сделанную кем-то и выложенную в магазине за деньги. Каждый раз они такое дело покупают у автора и только затем себе добавляют. Не уверен насчёт этого момента.
Этот их форс DOTS это их первая попытка сделать что-то по другому. И заодно их эпичный обосрамс.
Как мне лучше всего это воплотить в жизнь? Не думаю, что с точки зрения движка будет здраво все 256+ частичек одной картинки одновременно рендерить, а потом ещё и выискивать где именно и кого именно из них мышь нажала. Собирать из них одну текстуру в рантайме? Ещё какой-нибудь вариант есть?
Ну и раз уж речь зашла - хочу чтобы как в веб 2.0 картинка не просто расширялась под масштабы окна, а резалась в нужных местах и повторялась в требуемых местах. Общую идею как это сделать я уже имею и кое-какие части её уже воплощены, но может какие-нибудь советы имеются?
Так это же торможной говнокод получится. Лучшим решением был бы массив тэгов, который бы хранился как битовая маска. Нахуя один тег-то делать? Неужели юнитеки не подумали, что может понадобиться 2 тега, или даже 3?
Только начинаю изучать юнити и пока какое-то разочарование, все его так хвалили, мол, лучший движок и все такое. Но что-то пока такое себе. В плане работы с ассетами, анимациями, посасывает у анрила. Удобство работы с префабами посасывает у прости господи, системы сцен годота. Скриптовое АПИ какое-то хуёвое, антипаттерн на антипаттерне, MonoBehavior просто какой-то огромный перегруженный god object, неужели не могли сделать отдельные базовые классы для компонентов, поведения, сервисов. Надо ECS попробовать вкурить, может хоть там можно чистую архитектуру без говнокода запилить.
Открываешь инспектор, назначаешь тэг объекту. Он может быть только один. Т.е. если ты назначишь тэг player, ты не можешь назначить ему второй тэг, отвечающий за класс, команду или расу, чтобы потом фильтровать объекты по нему.
Почему он мне вот такое пишет? Я ничего не нажимал. Мои тэги реально удалятся, как только я закрою?
>>597400
Всё, разобрался. Это я старый проект открыл, а там пиздец полный, всё поломано. На новом чистом проекте никаких предупреждений нет.
И так работает и эдак. Ну всё, щас я точно сделаю игору мечты!
Студия какая-то тормозная и тяжеловесная по сравнению с code, дает ли она какие-то профиты, чтобы перевесить удобство и скорость?
Все нахваливают документацию юнити, говорят, что она лучше анриловской. Но там даже такая простая вещь не описана.
Т.е. влияет ли их размер или нет?
>не могут переписывать движок постоянно как раз потому что у них есть пользователи, у которых от таких манёвров слетит всё нахуй.
То та я вижу блядь что стандартные ассеты не работают когда выходит новая версия.
>Во-вторых, юнитекам не нужно переписывать движок с нуля чтобы ввести какую-то фичу. Да-да, в отличие от годота юнити сделан хоть по каким-то стандартам качества и отвечает заявленным требованиям, модульный и вообще как раскладушка.
Откуда ты знаешь что их код пиздец какой охуеный сделанный по всема стандартами разработки. Если бы было как ты говоришь, то фичи были бы более пиздатые и частые.
>В-третьих, скорее всего юнитеки не могут просто взять и выкатить официальную фичу, которая бы копировала фичу, сделанную кем-то и выложенную в магазине за деньги.
Все они могут, просто вносить кардинальные изменения в код они не могут так как все может поломаться.
>Если бы у них был охуенный код, они бы не зассали выложить его в опенсорс, как анрил сделал.
Ты так ненавязчиво наекаешь что код анрила БОЖЕСТВЕННЫЙ.
А ты сам его видел? Точно видел, сучечке пиздливый? Потому как я сношался с ним месяц, делай кастомный парсер ассетов и я знаю что за говно их код.
Пидрило. Съеби нахуй всвоб помойку-тред.
>делай кастомный парсер ассетов и я знаю что за говно их код.
А мог бы игры делать вместо ковыряния в говне.
> и я знаю что за говно их код.
Тут скорее обратная проблема, ты страдаешь синдромом NIH, как Хуан.
Хуан видит бесплатные охуенные текстовые редакторы, типа visual studio code, но не может позволить себе запилить интеграцию с ними для своего движка. Его анус болезненно сжимается, когда он видит код, написанный другими людьми. И неважно, хороший ли это код, или не очень, одна лишь мысль о том, чтобы использовать код, написанный посторонними людьми, заставляет волосы на анусе Хуана вставать дыбом. И Хуан идёт пилить кривое, убогое подобие текстового редактора, по фичам и юзабилити покрывающее 5% условного visual studio code. Кривое, уродливое, неюзабельное говно, зато своё, родное. При мысли о том, что Хуан сам написал этот редактор, потратил на него несколько месяцев времени, за которые мог бы например допилить рендеринг до приемлимого состояния, или пофиксить сотни багов, его крошечный сморщенный член, заросший густыми кудрявыми волосами, наливается кровью и привстаёт, Хуан начинает яростно дрочить его и кончает через 20 секунд, размазывает желтоватую вонючую сперму о внутреннюю поверхность своего рабочего стола и идёт переписывать классы строк и контейнеров для годота, т.к. по идеологии Хуана в годоте запрещено использовать стандартные классы из stl. Примерно так выглядит разработка годота. По этой причине годот не использует SDL, Box2d и десятки других библиотек, ставших стандартами индустрии.
У тебя, видимо, та же история, раз ты решил, что стандартных фич для работы с ассетами тебе мало и полез пилить что-то кастомное. Разработчикам условных mass effect и devil may cry хватило этих фич, а пидорашке с двача - нет, и она полезла пилить кастомный парсер. Так что проблема не в коде анрила, а в твоей голове, к сожалению.
> его крошечный сморщенный член, заросший густыми кудрявыми волосами
Часто фантазируешь о крошечном членике Хуана?
>ряя, я кавырялся в коде уеча, там фсе сложно и нипанятна((
>поставлен на место
Проиграл. Ты бы еще поссал себе на голову при людях, и сказал, что этим ставишь их на место.
Все, что ты доказал - что дети и умственно отсталые неспособны разобраться в коде уеча, это вроде и так всем было понятно.
И не первую юнити игру такую встречаю.
Если это обычное 2D без лишних наворотов, то какие подводные камни могут возникнуть? Может быть есть какие-то тонкости, с которыми анон уже сталкивался?
Может быть какие-то ограничения по фпс или размерам файлов, которые следует учитывать? Какая-то особая настройка проекта?
бакенд юнит - делоет патфайндинг, скорость, ну вся важная дата короче
фронтенд юнит - геймобжект манябехевиор который нихуя не решает а просто двигается и делает анимации, когда игрок уходит со сцены, просто удоляется. а бакенд переходит в слоу мод, чтоб не сильно грузить проц своей "жизнью".
Двигать юниты решил по 2д массиву.
Понимаю что это почти как сервер-клиент, хотя у меня опыта по этой хуйне нет.
Есть ли у кого литература почитать про этот "сетевой" подход? Лучше на англ конеш.
> геймобжект манябехевиор
лампово ибо тнус за щеку СЖВ слился
Из того что нашёл в основном предлагают делать скриптабал объекты, но этож надо будет хранить 200+ таких для каждого внутриигрового предмета.
И второй вариант это парсить не юнитовские форматы файлов типа XML.
Так второй вариант лучше и стоит с ним работать? Или есть ещё другие варианты, хранения кучи разных предметов.
Ну вот например, string и vector. Хуан просто взял и нагородил свои велосипеды, вместо того чтобы взять из std.
https://github.com/godotengine/godot/blob/master/core/ustring.h
https://github.com/godotengine/godot/blob/master/core/vector.h
Префаб настраивает себя по данным из базы. Неважно какая у тебя база данных, текстовые файлы или реляционная БД. Префаб в старте получает из своей настройки индекс на данные, чем он будет в игре. Ну, в общем случае, само собой. Например префаб-фурнитура с полем kind равным "терелка", в старте ищет данные о тарелке и загружает их в себя. Путь до меша тарелки, координаты где тарелка лежит и т.п.
>>597788
Дам тебе менее абстрактный пример. Более насущный.
Допустим у тебя в игре есть города с населением. И всё это неписи. На них на всех есть префаб "NPC", который у себя в скрипте, в старте, загружает себе меш, морфы, диалоги, маршруты на навмеше. Всё это реально численно инкапсулировать в текстовых файлах (или БД), не используя эти самые меши, держа их так же в единственном экземпляре.
Допустим у тебя имеется процедурный генератор. Однако ты же не будешь сразу всех генерировать, нет, генерация будет идти лениво, чтобы не создавались неписи во всех закоулках, в которые игрок даже не зайдёт. Процедурная генерация может быть весьма ресурсозатратной, поэтому ты можешь в первый раз генерировать непися и все параметры записывать в файл сохранения, например (лучше конечно в отдельный файл, сделать отдельную папочку кэша в юзерской директории и ебашить туда файлы с васями, машами и петями). Таким образом, при первом посещении локации непись генерируется, в следующие посещения просто поднимается уже сгенерированный непись из файла.
Синдром Даннинга-Крюгера детектед.
В скриптовом языке у тебя будет сцена "NPC.tscn" (ну ты понел), которая у себя в скрипте, в _ready, загружает себе меш, морфы, диалоги, маршруты на навмеше. Всё это реально численно инкапсулировать в текстовых файлах (или БД), не используя эти самые меши, держа их так же в единственном экземпляре.
Естественно, ты не понял. У тебя же синдром Даннинга-крюгера!
Так и в юнити можно создать 1000 скриптов для 1000 предметов, но так только говнокодеры делают. Нормальный подход - создать один общий скрипт, отвечающий за предмет, а различные вариации получать комбинациями атрибутов. Если еще ECS добавить, то вообще очень гибко получается, можно представлять предмет как набор компонентов, логика поведения которых разнесена по разным подсистемам. Например, пока макака пытается захардкодить меч на скрипте, с ECS подходом ты собираешь этот меч из компонентов, назначаешь ему модельку, иконку, вес, стоимость, признак оружия, тип урона - режущий и т.д. Какая-нибудь броня будет тоже иметь вес, стоимость, но не будет иметь компонент оружия, вместо него будет компонент брони. Фляга может иметь компонент объема, что позволит хранить в ней воду или любое зелье. Такой подход позволяет собирать составные предметы, например, можно совместить в шлеме компонент брони и оружия, добавив ему атаку рогами. Или добавь броне компонент емкости, чтобы можно было носить воду во встроенной фляге.
Я понимаю, что скриптовой макаке сложно осознать все плюсы такого подхода, но ты хотя бы попытайся.
>избавишься от синдрома
Сначала ты от своего
>Давай тогда вместе с юнити вместо компилятора C#
В юнити свой компилятор c#, который идет в комплекте. Вижуал студио это отдельный софт от других разрабов, не связанный с юнити. То, что юнити запускает инсталлер от этого софта еще не значит, что оно может что-то там тебе дополнительно установить. Настроить вижуал студио через инсталлер, чтобы там были компоненты для c# - твоя личная забота и проблема.
>>597823
>Слышь обезьяна
Зачем ты так про своего батю, что он тебе сделал плохого в этой жизни?
В этом видео в конце чувак говорит что-то про интермидиэт левел. А где серия видео для бегинеров?
Импортнул тайлсет с анимациями на сотню кадров со spriters resources, час сидел в спрайт эдиторе, размечал кадры анимаций руками, потому что там не было выравнивания по гриду. Потом понял, что импортнул с билинейной фильтрацией, нажал на ре-импорт, не выскочило даже никакого предупреждения - вся моя разметка на кадры проебалась, тайлсет снова превратился в один большой спрайт.
Это что, шутка какая-то? Даже в гондоте такой хуйни не было.
Где почитать, как сделать "не хуйню", чтобы было без таких глитчей? Делаю все стандартными средствами, по официальной документации, пока получается только хуйня.
>И как с этим жить?
Смирится и научится обходить баги.
>Использовать движок как низкоуровневый фреймворк, и велосипедить всё самому?
Займет дохуя времени и будут те же баги.
Здесь нужно придумать новые принципы программирования, например довести до ума визуальное програмирование что бы вся сложная часть была спрятана под капотом а пользователь только проводил линии между блоками.
Скажи пожалуйста, как мне кнопку обычную UI нажать через пробел, а не через нажатие мышки по ней?! Кнопка обычная Button, на неё накидано много разных действий, надо просто её нажать через пробел а не мышку!
С меня тонна нефти.
Можешь попытать счастья с NavMesh Components, это более up-to-date ветка Юнити навмеша, доступно на Гитхабе.
Но так же есть вероятность что ты хуй и делаешь какую-то хуйню (а мог бы делать игры), и вместо того что бы поправить свой код нашёл первый вайнер тред по запросу фича_нэйм из багд и сидишь довольный, ведь главное что ты не лох.
Спасибо большое, спас меня, от Юнити блин, на кнопку уже нажать нельзя нормально. Думал уже убрать ету кнопку и сделать все скриптом голым, а вот оно как получилось, спасибо :3
Вообще-то, в больших и сложных приложениях (а игры безусловно таковы) принято создавать менеджеры действий (action manager) которые содержат в себе реально выполняемый код этих самых действий, а кнопки, хоткеи, тач-ярлыки и любой другой ввод только обращаются к экшонам экшонманагера.
И тут мы снова упираемся в невежество
https://learn.unity.com/tutorial/create-a-simple-messaging-system-with-events
Сдаётся мне у тебя ссылка на что-нибудь побилась. При копировании/реактивации кнопки попробуй заново расставить все переменные как надо.
Чтобы кнопку "видела" мышка в кнопке должна быть картинка с включённым рейкастом и альфа-каналом выше нуля. Сам текст, вроде, тоже можно целью рейкастов задать, но насколько я помню один только текст плохо или и вовсе не работает.
Установил лайтвайт рендер по инструкции: https://answers.unity.com/questions/1535235/shader-graph-error-the-current-render-pipeline-is.html
Всё по пизде пошло. Я так охуел, что аж руки трясутся.
Не трясись, всё нормально.
Я вот сегодня импортнул тайлшит размером 1024 на 1024, и пытался порезать на слайсы, так у меня юнити завис, и пришлось прибивать процесс через диспетчер задач.
Просто прими факт, что ты жрёшь говно, но альтернатив нет, гондот еще хуже, а анрил слишком тяжеловесный для инди и небольших игр.
Могу по своему опыту сказать - скорость и отсутствие мозгоёбства. Проект на 100гб разворачивать и собирать из VCS будет намного дольше (и не факт что успешно с первой попытки) чем просто из бэкапа образ достать. Т.е. что бы отследить изменения, в команде работать и т.д. - конечно VCS, но если в обед сгорел HDD, то куда как проще и быстрее просто развернуть утренний образ системы и продолжить работать.
Но судя по дрожащим рукам, этот "разработчик" ничего вообще не делал для сохранности своей работы.
А что если я скажу тебе, что можно не переходить, а юзать оба движка параллельно?
>>598335
О, спасибо, неочевидная хуйня.
>>598355
Таки да, вкатился недавно. Читаю, смотрю, делаю тестики. Хотел один свой существующий проект по быстрому воспроизвести в юнити, чтобы заценить хвалёную простоту и скорость разработки. Но чот обосрался.
Студия в которой я работаю пользуется инхаус втулкой для конвертации флеш анимаций в плоские меши (вертекс колоред, по мешу на кадр) которые потом используем в движке. Со сложными градиентами правда что-то там не срослось (нам и не надо, рисовка специфичная). Ну и т.к это покадровая анимация, мячики плющит, ноздри натягиваются заебок.
Но открытые ассеты для такого ищи сам, чё ахуел?
Не слушай этого обоссаного дауненка..>>598593
На самом деле можно использовать один материал, просто во время запуска приложения можно получать доступ к материалу и менять его цвет.
Переименуй один из кубов на сцене в CubeZaloopa, создай файл скрипта, помести его на камеру, допустим...
Чисто для примера:
void Update()
{
If (Input.GetKeyDown(KeyCode.Q))
{ Gameobjet.Find("CubeZaloopa").GetComponent<MeshRenderer>().material.color = Color.red.
}
}
При запуске игры, если нажмешь q - цвет куба с белого на красный должен поменяться. При этом на оьоих кубах будет один и тот же материал, но там где сменится цвет, будет создан экземпляр материала.
Прыгать между шарпом и крестами один хуй мозг сломишь.
>мэйнлуп с коллбэками
Я к ецс приноравливаюсь, есть мейнлуп, а есть некая абстрактная асинхронная ебатория. В принципе, мне нравится даже.
>>598601
А можно использовать MaterialPropertyBlock и рисовать два куба с одним материалом и разным цветом всего за 1 дроуколл.
> А можно использовать MaterialPropertyBlock и рисовать два куба с одним материалом и разным цветом всего за 1 дроуколл.
Можно. Можно и атласами решит эту же задачу. Можно и писю в попу принять. Вот только судя по вопросам задающего, ему в такие дебри лезть рано, только запутается больше.
И это получается гораздо свободнее. Юнити может реализовать иерархию годота, а годот не может реализовать иерархию юнити.
Хотел это в движкосрач запостить, но у меня нет цели сраться. Просто инфа к размышлению для адекватов.
>Сравнивает суперпрофессиональный двиг за 6млрдов с хобби поделкой ленивого композитора хуанга
>адекват
>>598611
>MaterialPropertyBlock
С каждым днём я всё больше убеждаюсь что юнититред знает ответы на все мои проблемы, но выдаёт он их рандомными интервалами случайным людям и с неопределённым количеством ненависти направленной на них. Просить ответы бесполезно, нужно только терпеливо ждать, и тогда вселенская истина сама к тебе придёт. Может быть.
> Чтобы собрать в юнити годот-стайл сцену, вы должны делать все геймобджекты только с одним компонентом и одним скриптом.
Попробовал сейчас так сделать. Сцена моментально затормозила. При запуске сначала пусто, потом из пустоты вываливается этот композитный кадавр пиксрилейтед. Хотя рядом с ним такой же на одном геймобджекте появляется моментально и скачет по канве. Кажется, я начинаю понимать суть ЕЦС.
>https://www.youtube.com/playlist?list=PLX2vGYjWbI0RfcpqpKlmLEy7NteIog8g4
Понял все что делает код, но не представляю как я должен придумывать такие конструкции сам.
>https://www.youtube.com/playlist?list=PLX2vGYjWbI0RZ3M5zSs-cegtIzv-FBi4q
Ну тут понятно, простейший курс
>https://www.youtube.com/playlist?list=PLX2vGYjWbI0SKsNH5Rkpxvxr1dPE0Lw8F
Понял только первые четыре видео, дальше идет полный пиздец, который в игре даже проверить нельзя, потому что для того чтобы увидеть изменения нужно написать еще миллион функций и классов.
Посмотрел в факе https://noobtuts.com/unity Но по моему тут слишком легкие примеры. Наверное в каждом 80% содержимого будет руководство о том как загрузить спрайт в геймобджект.
Как дальше развиваться? Я впринципе могу начать делать игру, но мне кажется я буду писать дикий баганый говнод от которого я заплачу и брошу изучение юнити навсегда
> Как дальше развиваться?
Гугли и кури материалы по шарпу. Тебе нужно общее копутер сцаенс, чтобы быть уверенным в себе и писать говнокод, от которого ты не заплачешь, а заухмыляешься. Особенно когда у другоих от твоего говнокода бомбанёт. Ни с чем не сравнимое ощущение.
Так. Кроме шуток. Учи шарп. Учи алгоритмы. Учи паттерны.
С обычными рогаликами вроде все понятно. Там просто состояние игры представлено как данные, которое изменяются каждый ход, а потом просто каждый раз перерисовывается заново.
А как быть в юнити, я же не могу просто удалять и создавать объекты каждый фрейм. К тому-же хочется сделать разные анимации и т.д. В общем непонятно.
Есть у кого-то опыт нормальных пошаговых рогаликов на юнити?
Хуя себе как у скотопидорахи разворотило очко. Тебе разработчики юнити кончали в горло и клали потные яйца на лицо, что ты их так рьяно отстаиваешь?
К посте нет ни слова о том, что надо хранить набор тегов как массив, есть более оптимальные способы, такие как битовые поля (упомянут в посте, на который ты бомбанул), сеты. Теги необязательно хранить и применять внутри движка как ссылочные типы данных, можно запросто приводить их к инту как enum.
Ну не пизди, даже не самый быстрый двиг типа юнити не стал бы тормозить на трех гейм обжектах на сцене.
А еще смак в том, что раньше в юнити нельзя было делать вложенные префабы, и Хуан выебывался своим наследованием сцен, мол, уникальная фича, ты можешь сцену внутри сцены внутри сцены внутри другой сцены, и так до бесконечности. Но потом юнитеки запилили вложенные префабы и Хуан жидко пукнул со своими сценами.
ЛЕГАСИ
Е
Г
А
С
И
Уверен, если бы они сейчас запилили двиг с нуля, в его последнем состоянии, отбросив все говно мамонта 10 летней давности, он получился бы легковесным и быстрее в несколько раз. Но нельзя вот так просто выбросить поддержку легаси говна, в мире полно калоедов, которые продолжают дрочить на старьё, типа тех, кто продолжает сидеть на хп, не переходит на блендер 2.80 с 2.79, сидит на втором питоне вместо третьего, и т.д.
> не переходит на блендер 2.80 с 2.79
Этой проблемы вообще бы не было, если бы они не перепутали интерфейс. Нахуй это было делать? Есть вообще еще примеры чтобы большие проги перепутывали интерфейс просто так? Ведь там все то же самое везде, просто панель слева убрали, все перетасовали, делать нехуй.
Они неспроста это сделали. Над новым интерфейсом работали спецы по UX и юзабилити, этот интерфейс делали в том числе и с учетом пожеланий крупных студий и профессионалов (сейчас вот юбисофт начал в блендере 2.80 анимировать).
Так что надо просто смело отбросить привычку и идти вперед, навстречу прогрессу, а не быть калоедом-пидорахой, поднимающим вой. Поверь, все изменения обдуманы по 100 раз, разрабы понимали, что калоеды поднимут вой, но все равно нашли силы сделать эти изменения, и правильно сделали, потому что легаси нельзя поддерживать вечно. Старой схеме все-таки уже больше десятка лет было.
Именно так, берешь и делаешь, только не крузис, а какую-нибудь мелочь для начала, тетрис, марио, змейку какую-нибудь. Главное доводи до конца, даже с говнокодом. В следующем проекте будет уже меньше говнокода, появится опыт, сделаешь ошибки и в будущем уже не будешь их допускать.
Есть 2д проект.
Есть анимация того, как персонаж стоит.
Есть анимация того, как персонаж идет.
Есть анимация переходит из "стоит" в идет". (и обратная)
Как корректно осуществить переходы? Анимация "перехода" из "стоять" в "бег" должна быть отделена от бега?
На рилейтед пике мой вариант. Все ок, кроме того, когда переключаешь резко справа налево (или наоборот) - повисает в анимации перехода вместо бега.(если отключить has exit time для анимации "перехода", то он ее вообще игнорирует почти что)
Установил в юнити, вставил скриптбл в нужный слот, где его надо вставить и в итоге у меня вместо текстур - розовая залупа без текстур. Без этой ебалы у меня всё нормально, но мне охота сделать пару шейдеров, ибо графон уровня б ещё и лоу поли игра, лол.
Орнул с порвавшегося хуесоса. Щас бы лепить костыли из битовых масок, переходных enum-ов вместо использования instanceIDs. Тебя, пидорана, какая блядь высрала из своей разъебанной сраки, а потом костылем пизданула по твоей обоссаной башке да так, что ты теперь без костылей жить не можешь, чмошка?
Бесполезное дело. Чтобы это в памяти осталось нужно пользоваться им постоянно. Ну, пролистаешь ты документацию, поможет это тебе в деле? Это, может, ты у нас из компуктер сцайенс вышел, у тебя на занятиях сформировали память таким образом, чтобы документация по полочкам раскладывалась. Но мы-то здесь самоучки с вышкой в каком-нибудь маркетинге а то и вовсе без образования, нам-то какой толк от документации? Вот ты инструкции к стиральной машине новой читаешь, ты сразу весь функционал запоминаешь и можешь из памяти использовать?
Вся проблема в том, что нет единого решения для какой то задачи. И в каждом туториале люди показывают тот или иной вариант. Поэтому важно понять как работать именно с инструментами, а как уже из них слепить что-то желательно думать самому. Ну и лично по моему маняопыту, когда сам даже говнокодишь но ты понимаешь как это работает и как это можно улучшить, чем когда повторяешь за кем то, даже если он хорошо обьясняет.
https://blogs.unity3d.com/2019/08/06/dont-miss-unite-copenhagen-where-creativity-and-technology-converge/
То состояние движка, когда даже уже на пиар-вечеринках нечего рассказывать.
Сказками про ECS уже все объелись видимо.
>документация для уточнения а не для обучения, опыта работы с движком она не даст
Ебать дебил.
Документация даст тебе представление об устройстве движка и его возможностях. Прочесть документацию - это первое что ты должен сделать перед использованием программы. А ты тратишь время на бесполезные ролики с ютуба.
Ты пытаешься решить проблему с помощью инструмента, не зная инструмента. Не зная инструмента, ты можешь самостоятельно составить план решения проблемы, поэтому тебе как тупому дауну только остается как макаке повторять за идиотами с ютуба.
Иди бегом читай все доки от корки до корки.
Дело в том, что "мастера" из ютуба (и даже авторы официальных туториалов) используют только базовые вещи. Как объекты двигать, как коллизии чекать, риджидбади ебать, рэйкастики кидать и всё такое.
Хуеву кучу возможностей они не используют. Вот, например, захочешь ты себе упросить жизнь и автоматизировать рутину, а нихуя не знаешь как использовать Editor. Потому что про него вспоминают единицы ютуберов. Даже использование того же OnValidate я видел только в одном видео.
Это, конечно, не означает, что если ты залпом въебёшь всю документацию, то точно всё запомнишь и сразу начнёшь хуярить как царь. Но очень может быть, что ты наткнёшься на несколько методов, функционал которых ты раньше потом и кровью велосипедил, и от которых скажешь "ебать, а что, так можно было?"
Что читать? АПИ?
>VisionUtility
>class in UnityEngine.AccessibilityLeave feedback
>Description
>A class containing methods to assist with accessibility for users with different vision capabilities.
>Static Methods
>GetColorBlindSafePalette Gets a palette of colors that should be distinguishable for normal vision, deuteranopia, protanopia, and tritanopia.
Ммм, уже чувствую, как растет понимание движка.
Или мануал, про то как скрипты добавлять и компоненты настраивать?
Нет, мне нужна не инфа по отдельным частям, мне нужно усвоить как это все вместе использовать. Т.е. не учить словарь и грамматику, а пожить год в среде нэтивспикеров, если проводить аналогию.
Хватит выебываться своим Даннинг-Крюгером.
>мне нужно усвоить как это все вместе использовать
Использовать то, не знаю что. Пиздец, зумерки реально ебанутые.
Что "вместе использовать"? Никто тебя не научит делать игры вообще.
Объясняю еще раз для даунов как это работает. Ты сам должен решать эти проблемы. Чтобы что-то сделать, ты должен составить план в голове "чтобы получить такое-то конечное состояние, мне нужно сделать такое-то и такое-то действие в юнити". Так как ты нихуя не знаешь какие действия ты можешь делать в юнити, ты самостоятельно не можешь решить проблемы. Поэтому тебе остается только повторять по шагам что показывает в роликах.
Это не обучение, а копирование.
>Даннинг-Крюгером.
>зумерки
Хватит одни и те же словечки в каждый второй пост пихать, это не добавляет убедительности..
Во-первых, о степени моих знаний о том, что можно делать в Юнити ты можешь только догадываться.
Во-вторых, твое мнение я понял, хватит его навязывать. Тем более, что я о нем не спрашивал.
А вот как все увязать вместе - этому нигде не учат. Потому что у тебя уже должны быть базовы знания. Типичный ютуб-сенсей этими знаниями не владеет, а кто владеет тому не интересно преподавать азбуку. В лучшем случае поделитсях на уровне "дорисовать остаток совы".
>Во-первых, о степени моих знаний о том, что можно делать в Юнити ты можешь только догадываться.
Эта степень знаний стремится к нулю, очевидно же. Чего еще ожидать от просмотрщика ютуба, который только СМОТРИТ, как другие делают, вместо того, чтобы делать самому, фундаментально изучать вопрос и нарабатывать опыт на практике.
Посмотри на код из реальной игры
https://github.com/NoelFB/Celeste/blob/master/Source/Player/Player.cs
Даже заставить спрайт нормально двигаться - это не хуе-мое.
В оригинале правило 20/80, но чтобы оно заработало, нужно чтобы были готовы все необходимые вещи на 80%. Если ты реализовал пару основных фич в прототипе, то это нифига не 80%, ибо еще надо графон, звук, интерфейс и все прочее пилить.
Так-то прототип за пару дней можно наляпать. Но за 10 дней ты не доведешь его до отличного состояния.
По опыту своей работы, могу сказать что это действительно пиздец насколько дольше, чем кажется. Особенно если вас не сильно дохуя.
Графон — это пол беды. Для этого художники есть. Но и с ним проблем хватает. Дохуя времени уходит чтобы его вставить, чтобы везде всё ровно было, ничто друг на друга не налезало. Ненавижу графон в юнити вставлять, а особенно его анимировать.
Но всё это хуйня. Самый ад — это правки. Сколько бы диздоков у вас не было — проект будет меняться. В процессе разработки постоянно вылезают какие-то нюансы, которые могут привести к перепиливанию большого участка кода и контента. И чтобы всё это не превратилось в башню из костылей — ты будешь рефакторить. И не один раз. И заново вставлять перерисованный графон. И интерфейс. И звуки.
И да, я же говорил что после каждого нового модуля (или перепиливания) это всё надо тестить? А это опять же время, которое тебе приходится тратить.
Хотя, у нас ещё и вечные войны с психологами и методистами (у нас довольно своеобразный контент, без них никак), которые постоянно свои правки вносят, и их мало ебёт сколько всего для этого придётся менять, так что не уверен что те же разрабы Хотлайна сталкивались и такими проблемами тоже.
И да, хуярить 3D намного быстрее, чем 2D. И дешевле.
"У класса есть некие состояния, весь вывод берет на себя некий другой код"
Это говорили к тому, что не надо из скрипта player выводить сразу на UI значения.
И у меня нубский вопрос- как правильно передавать значения из одного скрипта в другой?
Я пробовал использовать сначала просто static переменные, лол. Потом научился передавать сам скрипт. Сейчас вот пытаюсь понять интерфейсы и синглтоны. Но не догоняю пока.
Наверное вопрос платиновый и гугл знает лучше, но скажите, я вообще в правильном направлении копаю?
Как правильно передавать значения между классами это весьма абстрактный вопрос.
В случае с UI примером, можно пользоваться ивентами.
В игроке у тебя есть ивент
public event System.Action<float> OnHealthChanged;
тригеришь этот ивент из какой-то внутренней функции обновляющей хп или из сеттера проперти,
Есть так же скрипт PlayerUI, который на OnEnable подписан на ивент игрока (не забудь отписаться на OnDisable)
m_PlayerReference.OnHealthChanged += UpdateHealthUI;
и реагирует на него фунцией а-ля
private void UpdateHealthUI(float health) {}
которая что-то там делает.
В итоге весь вывод состояния (а точнее изменения состояний) таки берёт на себя другой класс, о существовании которого класс игрока даже не догадывается (и ессесна не контролирует).
Можно это всё ещё сильнее абстрактировать при желании и сделать UI елемент-хелсбар которому только и нужен реф на носителя IAlive (интерфейс всех живых - имеющих ХП болванок). Но у задающего вопрос, как мне кажется представления о композиции нет, так что похуй.
>>599397
Забудь про это дерьмо и никогда не юзай.
Щас бы харкодед функциями передавать броадкасты в пустоту
Нет уж, дружек, никогда не программировал полноценный геймплей тут ты. твои соло огрызки не в счёт
Если ты считаешь что скинутый код сниппет это норма, то ты как раз и являешься представителем ютуб туториал макак которые считают что от сложности код маштабируется только в длинну.
5 блядских тысяч строк отборного говна никак не взаимосвязаных друг с другом. Класс должен выполнять одну очевидную функцию, в данном примере же они решили впихнуть сюда хендлинг всех возможных контролов, тут у тебя и передвижение, и прыжки и вол джампы и даже какие-то специальные абилки доступные только наличием каких-то специальных предметов в инвентаре, специальные эфекты того как тебя в какой-то катсцене отбрасывает босс (!) и, внезапно, даже вообще отдельный котроллер для какого-то Star Fly State, очевидно не имеющему отношение к чему-либо из 3 тысяч строк выше.
Оболтусы которые это писали даже распилили свои испорожнения регионами (видимо что бы сворачивать куски которые им не нужны в редакторе), но не додумались что можно просто подумать больше 15 секунд об архитектуре своей игры и разбить всё это на компоненты поменьше.
Но макак типа тебя это всё равно впечатляет, мол, ебать какие боги геймдева, аж 5к строк в скрипте!
мимопрограммист
Как ты научился всему этому?
Я пробовал читать книжки по шарпу, но они или слишком простые, или слишком углубленные. Понимаю, что надо изучить разные фабрики, подробнее изучить все классы и функции, лямбда выражения и вот это всё, а еще ООП понять окончательно и блин, столько всего надо знать.
Много времени у тебя ушло на это? Учился на прогера?
Я вот попробовал курс купить Unity для профессионалов | От Junior до Middle Да, ебобо совсем, многого не понял до конца, но мне кажется, что-то проясняется потихоньку.
Что вообще посоветуешь? Больше кода писать? Больше книжек читать? Или всё вместе, еще присыпать бессонными ночами и тогда может быть месяцев через 6 у меня начнет что-то получаться нормальное не вырвиглазное?
О, вот я с тобой согласен.
Но по сути у них видишь, всё работает. Игру делали всего 2 человека. А написание хорошего кода требует больше времени, как мне кажется. А они решили поступить просто- экономят время на коде и отрабатывают геймплей. Поэтому игра и стала такой хорошей. А не из-за того, что там код в 150 абстракций обернут.
Но это опять же моё мнение новичка.
Если есть большая команда то конечно, поставить спец программиста и пусть пишет идеальный код. А когда там всего 2 человека, им же важнее геймплей отработать и иметь стабильный простой скрипт.
Но их игра стала игрой года, они теперь могут не работать остаток жизни. А ты мимо-программист, сосущий хуй за копейки. Тебя правда греет мысль, что ты что-то там шаришь в архитектуре?
Какая разница, что у них не идеальный код, важнее, что получился хороший продукт. Игры создают не для того, чтобы потом игроки сидели и охуевали "ебаать, да там ни одного файла больше 50 строк, все разбито на компоненты, ебать там архитектура".
Да всем похуй на это. Главное - конечный продукт.
Вылизанный код не сделал бы игру лучше, он только убил бы кучу времени и игра могла бы выйти позже или вообще не выйти.
Так что не еби мозг, всем поебать на твою архитектуру ровно до тех пор, пока в ней не возникла острая необходимость. Ты бы еще до хелло ворлда доебался, что там паттернов мало, абстрактные фабрики не юзаются и все в одном файле.
> уже почти год программирую потихоньку
Ну если "потихоньку" это пара часов в субботу вечером, то для года это ещё относительно нормально.
Если устроишься куда-нибудь джуном, то будешь по 8 часов в день хуярить и, возможно, чужой код перелопачивать, вот там быстро придётся понять что к чему.
Не согласен.
Хороший модульный код разбитый на абстракции (в здравых количествах) упрощает и ускоряет работу. Геймдев это сверх итеративный процесс, ты постоянно вносишь куда-то изменения. Чем проще твой код читается и понимается, тем проще тебе будет через две недели поймать странный баг с неправильно переключающимися стейтами или добавить специальный кейс для супер-прыжка при наличии спец предмета. Чем меньше времени ты тратишь листая вот такой пиздец на 5к строк и добавляя костыли костылям, тем больше времени у тебя есть реально заняться геймплеем.
Не имея опыта собрать проект с адекватной архитектурой конечно очень сложно, и каждый напишет пару полотен по тысяче+ строк перед тем как познает дзен (потому этот процесс в реальном продакшене обычно курируют бородатые дяди в свитерах, а не мы с вами двачеры-дегенераты), но я блядь уверен что не нужно иметь семь пядей во лбу что бы увидеть [на этапе продакшена] что скинутый код это просто пиздец и надо менять подход.
Закончили разработку, наверное, чисто на мотивации никогда больше этот понос не видеть.
Ух блядь, я забыл, игры это исскуство, а миллион мух не могут ошибаться!
Смысл в архитектуре в том что он ускоряет, а не замедляет процесс. И если бы они писали всё по-человечески - было бы больше времени посвятить реально важным моментам разработки. Потому что как ты заметил, главное - конечный продукт, а наступая самому себе на пятки добиться чего-либо как минимум сложнее.
Ну и, просто что бы ты понимал, если уж они открыли исходники и они были выложены тут, возможно в целях того что бы показать вкатыльщикам как должен выглядеть код, есть смысл обьяснить почему этот код хуёв и стремиться к нему не надо. К их успеху и решениям в геймдизайне - да. К коду - нет.
и чет орнул с сосания хуев за копейки, ты-то уж точно добился успехов вместе с разработчиками игры, ух, тоже наверное до конца жизни не будешь работать и сидя у мамки на шее строчить хуйню в юнититреде?
Ну давай разберем по частям тобою написанное.
500000 20 / (7 3) = 428к долларов.
Что примерно равно 28 миллионам рублей. Если представить, что ты будешь жить еще 40 лет, то это 700к в год, или 60к в месяц. Так что таки да, можно не работать до конца жизни. А если еще и с умом подойти к этой сумме, можно её и приумножить.
Вот только разрабы из Канады, и тут получать, скажем, 100к/год в большом городе это не так и много. Не говоря уже про то что разрабатывая игру, разрабы скорее всего делали это фулл-тайм, следовательно их расходы за период разработки стоит вычесть из профита.
Хватит жить в маня-мирке, далеко не все успешные инди девы выстрелили как Нотч. Они заработали себе приличные суммы, но даже не в стравнении с фулл-таймом на какой-то большей кодо-галере. В инди идут за другим.
Например выставляю Input.GetButtonDown("cancel") - ноль эмоций.
Выставляю Input.GetButtonDown("pause") - работает?
Что за ебанина? Настройки одинаковые.
Эти быдлокодеры издеваются надо мной?
Отдельно объект с анимацией и отдельным объектом коллайдером или все в одном объекте?
Проблема в том, что чарактер "застревает в текстурах" при смене анимации
Проверь что бы у тебя GetButtonDown чекался в Update(), а не FixedUpdate(), у меня с таким были проблемы. FixedUpdate() скипает кадры и может скипнуть кадр где кнопка была зарегистрирована нажатой (этот метод возвращает положительный ответ равно один кадр - проебал - сасаи).
Я когда увидел, что так можно, ахуел и подумал что было бы очень круто такое реализовать. Там игра на компанию, на телефон выводятся разные штуки типа (выбери кто из твоих друзей смердящая мошонка) и всё в таком духе.
Видели? Узнали? Помните?
Интересно, юнька так сможет? Там телефоны вроде по вайфай к ней подключались или типа того.
Tiled говорит о том, что, внезапно, спрайт надо тайлить, а не растягивать. В принципе, это даже достаточно, в большинстве случаев Full Rect даже включать не надо. Это, скажем так, сугубо для подстраховки что меш твоего спрайте — это прямоугольник, а не полигон.
Есть компонент, который отвечает за горизонтальное движение персонажа.
Есть компонент, который отвечает за какое-то особое движение (рывок, например)
Допустим, в компоненте горизонтального движения есть булева переменная, которая определяет, разрешено ли горизонтальное движение для персонажа.
Как корректно менять эту переменную из других компонентов?
Вариант 1: Просто задавать ей значение через сеттер (свойство)
Вариант 2: Сделать нотификацию через систему ивентов (компонент горизонтального движения будет подписчиком)
Я начал проект с попыткой сделать всё на ЕЦС, начал просто по фану сетевое приложение - юнити ецс и сервер дотнет с самописным ецс, чтобы глубже осознать концепцию, так сказать. Начал скатываться в момент, когда понял, что не нужен ецс для одиночных компонентов - тот же контроллер камеры или персонажа. Создал отдельные классы, не монобех, просто подписанные на события апдейтов. Потом понял, что мне нужен объект, который будет кешировать ссылки на компоненты. С моей колокольни получилось, что дата ориентед подход нужен, но ецс говно.
Там же в секунду будут создаваться тысячи переменных?
>все локальные переменные "создаются" в момент вызова функции в стеке,
Не все, зависит от типа. Сложные типы могу и в heap идти, лишь референс на стеке
>>599601
> Само собой зашквар. Выноси всю эту херню за циклы. Был бы в юнити шарп - таких проблем бы не было, но у нас древнее говно мамонта МОНО.
Хуету сморозил.
>>599605
Не используй unsafe никогда в Юнете. Там с++ база может двигать вещи местами и ты можешь нехуева так акесс вайлануться.
>что быстрее, копировать память 1000000 раз или не копировать память
ты ебанутый?
разберись уже в терминологии. ты создаешь локальную и присваеваешь ей значение. это 2 разных вещи.
Тебя это интересовало? Нужно или не нужно выполнять лишние операции в цикле?
правильный тест
Vector3 test;
for (int i =0; i < 1000; i++)
test = new Vector3(1,1,1);
for (int i =0; i < 1000; i++)
var test = new Vector3(1,1,1);
При нажатии один раз ТОТЧАС ЖЕ test.x = 9999999 станет. Если ты хочешь, чтобы при нажатии один раз test.x каждый фрейм на единичку больше становился делай корутину. В начале корутины ставь проверку на то, бежит ли уже экземпляр этой корутины, внутри цикла ставь yield return null
Молодец, к успеху идешь. Скоро будешь пилить шедевры как кудесник из этого треда >>599527 (OP)
Есть разница между значимыми и ссылочными типами. Значимые типы создавай в цикле, хоть усрись. Память под них выделяется в стеке один раз за запуск приложения (а потом просто адреса переназначаются, если это нужно) и их объявление ни как на производительность не влияет. Значимые же типы, совсем другая история. Память под них выделяется в куче, потому каждое такое объявление ведет к новой аллокации памяти каждый раз,когда этот кусок кода выполняется. В твоем примере ты выделяешь память под массив, который является ссылочным типом. Потому у тебя и и происходит пиздосий с производительсностью. Попробуй заменить свой массив на любой значимый тип (int, float, bool etc).
>у тебя и и происходит пиздосий
У меня не происходит, я так не делаю никогда.
>заменить свой массив
Давай на строки? Вот хочу я и всё, мне на дваче сказали, что можно так делать, какая-то умная хуйня про аллокацию и всё такое. Ну или второй вариант, аж юнити перезапускать пришлось.
> struct
> string
Пернул с маньки
Поясните неофиту, чем под капотом шарпа
List<BlaBla> MamkuEbal = new List<BlaBla>();
отличается от
var MamkuEbal = new List<BlaBla>();
И так по инициализации понятен тип, разве нет?
Мне наоборот решарпер постоянно говорит, мол, не еби мозги, юзай var
Не надо его слушать?
Нет никаких претензий, 708, 709, 710 посты просто от местного шизика-серуна. Наоборот, мелкомягкие советуют юзать вар.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/inside-a-program/coding-conventions
>это как-то на производительность может влиять
Хуй там, шарп строго типизированный. В говне вроде джаваскрипта или пхп повлияло бы, а тут похуй.
Пиздец вы тут ебанулись.
var это чисто синтаксический сахарок, чтобы не писать
MySuperList<MySuperClass> a = new MySuperList<MySuperClass>();
Вместо этого пишешь
var a = new MySuperList<MySuperClass>();
И экономишь себе 5 секунд времени, всё. Типизация никуда не пропадает, компилятор знает тип по правой части выражения.
Это нужно чтобы не дублировать два раза тип. Всё. Ни типизация, ни производительность никак не меняются. Внутреннее представление у обоих этих примеров будет одинаковое.
А вы тут просрались на десяток постов как дауны.
написано же, shit.
Тебе внутри метода в принципе не нужно знать конкретные типы объектов. Типы нужны конпелятору.
Зависимость от конкретных типов это все последствия процедурного мышления. Ты рассматриваешь переменные как данные, а не как объекты.
Наверняка у тебя бы там был какой-нибудь код shit.x = 10; shit.collection.Add(new Object()); и т.д.
Так в таких случаях не надо, мелкомягкие же все расписали
>// When the type of a variable is clear from the context, use var
>// in the declaration.
>var var1 = "This is clearly a string.";
>var var2 = 27;
>var var3 = Convert.ToInt32(Console.ReadLine());
>Do not use var when the type is not apparent from the right side of the assignment.
>// When the type of a variable is not clear from the context, use an
>// explicit type.
>int var4 = ExampleClass.ResultSoFar();
Потому что переменные и есть данные, сейчас же дата драйвен кодинг в тренде. Если выбирать между array of structs и struct of arrays, я возьму второе.
>shit.x = 10
Shitter.AddShit(shit, shitsCount);
Надо же отслеживать обновление данных, события вызывать. Можно, конечно, через геттеры, но тогда классы будут длинные, не особо люблю такое, лучше менеджеров наворотить.
>>600086
Значит, иногда вар всё-таки плохо. Но плохо не для конпилятора, очевидно, а для самого кодера.
Профайлером прохожусь по андроид билду на своем телефоне, профайлер показывает, мол, все отрисовывается быстро, около 100 фпс, хотя на телефоне явно виден просед до ~25 фпс (тоже самое говорит и средство диагностики, встроенный в ось андроида). Меня наебывает профайлер? Или это я долбоеб?
Хуярить пол и стены одним мешем всё-таки хуже, чем делать модульные? Occlusion culling не работает при таком раскладе и всё добро честно просчитывается.
Или делать модульные меши, но с одним текстурным атласом на все объекты?
> Occlusion culling не работает
Ахаха! Соснули! Побегу в годотред наябедничаю!
И второй. В билде тени перестают быть мягкими и становятся очень грубыми, как будто soft shadows выключен. В едиторе все в порядке. Использую lightweight pipeline renderer. Чому так?
Петух малолетний, где они там советуют вар использовать? Они, наоборот, не рекомендуют его использовать, особенно там где возвращаемый тип неочевиден, еб твою мать! А то что ты там накукарекиваешь var-ом при объявлении переменных, только путает людей, тухлодырец ты проткнутый.
Хуесосина двухизвиленная, тебе, бляди тухлодырой в голову не приходит, что на практике свободных от контекста данных не бывает, кроме как разве что в дебаг-логах каких-нибудь обоссаных, где все на вывод идет сразу?
Пидрилы, блядь, ебаные, мозгов ни на что не хватает кроме как везде пихать сови обоссаные var, даже в свои анусы. А то чот код нечитаем становится, вам, кириллам проткнутым, невдомек. Обоссал тебя дауненка.
var iEnemyCount = 10;
var fPlayerHealth = 98.99f;
var v3PlayerPos = new Vector3(2f, 13.3f, 10f);
var sPlayerName = "Yebanashka";
Вопросы?
Хуй соси, даун, когда у тебя десятки полей, пока ты среди десятков варов найдешь нужное поле, уже нахуй второе пришествие настанет, еб твою мать, дебил ты ебаный. Не знаю как унтерменши, а люди читают слева на право, поэтому быстрееиискать переменную с приписанным типом данных. Конечно, для хеоллоуворлдщиков обоссаных типа тебя, это, допускаю, не актуально, но в крупных проектаз только так.
Ты заебал. Проблема высосана из жопы. Просто не существует такой проблемы, не нужно знать типы локальных переменных. Они ни к чему. У тебя есть имена функций, имена переменных. Используй их для документации кода.
Я уже писал что само по себе знание типа Petuh petuh = new Petuh(); ничего не значит
>Нипанятна!
>A a = GetA();
>B b = GetB();
>Func(a, b);
>Вот теперь заебись!
Вряд ли всё дело в юнити, там бы хватило на самом деле пяти файлов. Я же учитываю только папку "Code", а не все пакаджи.
>>600490
Мне норм. Это только это окно такое, так оно светло серое на темном фоне.
Куб имеет наглость пересылать своё положение по сети во время движения. Так что, 16 папок, 43 файла ответного дотнет приложения. Я получаю позицию куба.
>Давай на строки?
Строки это тоже ссылочный тип. И память под них выделяеся в куче, а не в стеке.
https://metanit.com/sharp/tutorial/2.16.php
> люди читают слева на право, поэтому быстрееиискать переменную с приписанным типом данных
Ради такой мелочи создавать дублирование информации (т.е. типа) и тем самым усложнять модификацию кода в дальнейшем? Нет, спасибо, сомнительное это удовольствие.
>в крупных проектаз
Вот как раз внося большие изменения в крупный проект и увидите воочию какую могилу себе вырыли.
https://blogs.unity3d.com/ru/2019/08/13/faster-c-scripting-with-jetbrains-rider/
jetbrains занесли чемоданы юнити.
как-же заебали пиарить везде свое тормозное bloatware, жрущее всю оперативную память..
Далее, типов данных по пальцам пересчитать, каким надо быть долбаебом, чтобы, например, сначала от фонаря выбрать целочисленный тип, а потом, скажем, с плавающей точкой. Да даже децималы всякие с лонгами - оин хуй, если ты такой долбаеб что не в состоянии загодя определить назначение той или иной пепеменной, то тебе не программированием надо заниматься, а посасывать хуй за свободной кассой.
Я, конечно, понимаю, нынче высралось поколение двухизвиленных долбоебов-зумерков, у которых уже мозгов не хватает даже на два хода вперед думать, либо это 30-летние вкатывальщики, но это еще не повод жертвовать внятностью кода в угоду сваливания полномочий на компилятор самостоятльно назначать тип данных просто потому что у обоссаного кодерка не хватило мозгов понять нахуя ему нужна эта переменная в программе. Не говоря у же о том, если кому-то со стороны придется работать с этим говнокодом.
>либо это 30-летние вкатывальщики, но это еще не повод жертвовать внятностью кода в угоду сваливания полномочий на компилятор
мимо 30-летний вкатывальщик
>типов данных по пальцам пересчитать, каким надо быть долбаебом, чтобы
Я продолжаю усиленно нипанимать логику залётного ентерпрайзника с крупными проектами:
var listOfKnownEnemies = RaycastStorageClass.SelectMetod<EnemyClass>();
vs
list<EnemyClass> KnownEnemies = RaycastStorageClass.SelectMetod<EnemyClass>();
>если кому-то со стороны придется работать с этим говнокодом.
Давайте будем честны, никому не обосралось работать с чужим говнокодом. Большинство тут сидящих соло пилят что-то в стол и иногда высирают это в стим, ни о какой работе в команде не идёт речи. И хуевертить там они могут что душе вздумается, лишь бы сами понимали свои простыни.
Минутка тупых вопросов от ньюфагов
У меня есть ХП систем. В скрипте в апдейте я проверяю:
if (HP == 0) ты умер;
Вопрос: нормально ли в if апдейта проверять такие штуки, типа умер игрок или нет, и можно ли изьебаться и не делать такие проверки каждый кадр?
Это ж влияет на производительность, наверное? Или не влияет и я ебнутый и можно спокойно в if апдейта проверять всякую хуйню?
Почему какая-то сторонняя система знает о параметрах персонажа игрока? Инкапсулируй, сучка! Персонаж сам считает свои ХП, и посылает сообщения о своём состоянии, на которые подписаны, например, ХУД, ему прилетают сообщения с пакетом данных, хп, мана, стамина, хуйнина; и система гейм-овера, ей прилетает сообщение "игрок умер" - она активируется и показывает экран смерти.
Что может быть проще и понятнее?
Я ебал делать отдельные методы для смены одной-двух переменных, которые затем всё равно надо возвращать через ещё один метод назад. Прямой публик сокращает количество кода в разы.
Вообще охуеть, зачем юниту самому своё здоровье регулировать? Как вы собрались для сотни юнитов, например, серьёзные вычисления статов относительно друг друга делать? Допустим, шкала инициативы - куда вы её инкапсулировать собрались, где инкапсуляцию внутри юнита делать? Юнит это вам не предмет, который никому кроме одного другого класса не нужен, это ёбаная херь которая со всеми остальными системами бодается. Даже если распилить юнита на куски и засунуть статы для шкалы инициативы в один кусок, статы для боёвки в другой, статы для баффов и дебаффов в третий, всё равно необходимо это говно смешивать, а потом для уменьшения количества головной боли и для понятности кода в том числе необходимо открывать прямой доступ к полям и свойствам.
Ну во первых что значит правильно? Для меня правильно как мне удобно и если оно работает збс. Для больших студий правильно по другому, что мне неудобно и не нужно. Во вторых, ТНН. Я потом продам свою игру за 100500 миллионов в стиме и ещё десяток таких шаболд будут готовы прыгнуть мне на хуец, увидев мои доходы.
>>601675
Лол.
>>601589
О, прикольная система, попробую так сделать. Я правда до сих пор не особо понимаю как именно следует пользоваться Get и Set (хотя это самые основы, но я как-то без них обходился всё время)
>>601683
Всплакнул. А я думал вот выпущу игру и сразу тяночки появятся, ых.
Умничка! Маладэц!
Я так вообще снейк_кейсом хуячу код.
У меня такое получается физически легче и быстрее чем, печатать верхний регистр
> Я правда до сих пор не особо понимаю как именно следует пользоваться Get и Set (хотя это самые основы, но я как-то без них обходился всё время)
Всё очень просто сеттеры и геттеры нужны для очень простой вещи:
Сеттер вызывается при установке значения свойству и ты можешь проконтролировать корректность установки значения. Например, есть у тебя свойство MyHitpoints и в сеттере такой код: if (value <= 0) GameOver() else if (value > 100) MyHitpoints = 100 else MyHitpoints = value; с таким сеттером ты можешь быть уверен, что хитпоинтов у тебя всегда будет не больше 100, даже если игровая логика насчитает ему аптечками +100500, а так же если она туда же насчитает уроном ноль или минус, то автоматически вызовется метод гейм овер.
Геттер нужен при обращении к свойству и ты можешь контролировать, какое значение получит вызывающая это свойство сторона.
Например, ты обращаешься к свойству MyCamera, а у него в сеттере if (MyCamera == null) MyCamera = GetComponent<Camera>; return MyCamera; и ты сразу получаешь камеру. Причём, при первом обращении юнити достаёт компонент камеры (здесь я привёл без обработки ошибок, но ты можешь добавить таковую в геттер) а в последующие обращения компонент уже получен, хранится в свойстве и выдаётся сразу.
А у вас бывает такое, что вы целый день сидите в IDE, а потом заходите сюда отправить пост и нажимаете ctrl-s чисто на автомате?
Это что за ебанина? Т.е. чтобы что-то загружать из кода, это что-то должно быть в специальной папке? При том, что как бы уже есть Assets. А сразу предупредить нельзя было? Пиздец, в такие моменты не хочется продолжать пользоваться движком.
inb4: сосу конец
Спасибо, долго ж я до этого допирал.
>Короче нужно подключить неймспейс эдитора и использовать AssetDatabase, ну спасибо что хоть так.
Бля, как жопой чуял. В билде конечно же не работает.
Пиздец конечно, придется над струкутрой проекта измываться. Начинаю понимать откуда в геймдеве такое отношение к пользователям движка.
>референси из ассетов.
А если мне динамически в коде надо решать какой именно префаб загружать?
Вообще я охуеваю, такая простая банальная вещь как загрузка ресурсов в юнити превращается в эпопею. Охуенный движок, где половину вещей можно только дрэг-н-дропом в эдиторе делать.
Через что загружать-то блять? Есть Resource.Load, но чтобы он работал, нужно чтобы префаб лежал в папке Resources. Что значит, придется хуй пойми как переделывать структуру проекта. Есть еще AssetDatabase, но оно только в эдиторе работает. Как еще можно получить объект по указанию пути?
>Есть Resource.Load, но чтобы он работал, нужно чтобы префаб лежал в папке Resources.
Так точно.
> Что значит, придется хуй пойми как переделывать структуру проекта.
СУКА НЕТ БЛЯТЬ
RESOURCE LOAD ВООБЩЕ ДЛЯ ШЕНАЙНИГАС В ЕДИТОРЕ ТОЛЬКО ПРИДУМАН
ОН ДЛЯ ФИНАЛЬНЫХ БИЛДОВ ВООБЩЕ НЕ ДОЛЖЕН ИСПОЛЬЗОВАТЬСЯ
Але, а AssetDatabase для чего тогда? Resource.Load именно для билда, смысл этих папок в оптимизации, так в доках сказано. Но это порнография, создавайте файловую структуру проекта внутри файловой структуры проекта, да проще тогда просто сразу держать все в Assets/Resources.
>>601968
В любом нормальном движке можно загружать ассет из кода без танцев с бубнами.
Корень твоей проблемы в том, что ты думаешь об Assets как о простой папке с файлами, хотя на самом деле это нихуя не так. Это система по учёту данных, которая подгружает когда нужно и выгружает когда можно. Её не ебёт, что ты хочешь "все префабы из той папочки" - она хочет конкретные, блядь, референсы на объекты.
На практике, когда возникает такая необходимость, есть два стула: либо на этапе эдитора нужные ссылочки автоматически собираются с помощью AssetDatabase (правильно) и сериализуются в массивчики, либо используется магическая папочка - Resources (легче). Вот это именно та папка, о которой ты говоришь в других движках. Данные, которые ты сам, лично контролируешь - в т.ч. выгружаешь.
Стало понятнее, дорогой друг?
>ОН ДЛЯ ФИНАЛЬНЫХ БИЛДОВ ВООБЩЕ НЕ ДОЛЖЕН ИСПОЛЬЗОВАТЬСЯ
>Enjoy your 10fps and 5m load times>>601998
С чего бы у меня было 10 фпс из-за загрузки маленького спрайтика пару раз за игру, например?
>>601998
>Нет, иначе бы при перетаскивании из папки в другую весь сетап нахуй бы ломался.
Ну, наверное это для юнитигоспод большая проблема, а если я негодую от невозможности через код загружать ресурсы напрямую из файловой системы, наверное мне привычен такой воркфлоу.
Если ты дохуя костылебоярин, то никто не мешает тебе грузить все ресурсы из файловой системы, и вообще забить на понятие ассетов, только вот нахуя?
Если по какой-то причине ты брезгуешь использовать GUI, и все делаешь через код, то запихай все свои ассеты в бандл и грузи их из него. Хоть не так тормозить будет, как если ты будешь ресурсы использовать, которые действительно легаси и лучше дальше прототипов нигде не использовать.
Для небольшой 2D игры, я думаю, нормально будет.
>Если по какой-то причине ты брезгуешь использовать GUI
Для дизайна, например указывать ссылке на интерактивные связанные объекты на уровне, или для каких-то уникальных событий - удобнее в редакторе, не спорю. В других случаях это не только отнимает время на лишние телодвижения, но и ухудшает целостность кода, когда часть внутренней логики зависит от каких-то внешних факторов, определяется в другой среде - в коде ведь даже не видно, что за префаб установлен, и установлен ли вообще. Это не правильно, и к тому же приходится переключаться туда сюда, открывать эдитор.
>Загрузить fbx или шейдеры будет сложнее.
Нет ничего невыполнимого.
Медленнее распаковка (особенно на мобилах), больше памяти жрет. Еще вдобавок ко всему всё содержимое этой папки пакуется в билд, даже если фактически не нужно (особенно весело это если в проекте есть пачка third-party штук из стора, хранящих свои ассеты в ресурсах)
>>602018
Хардкодить пути к ассетам в коде тоже не самое мудрое решение.
Если следовать подходу, который предлагает движок, никаких особых проблем с использованием ссылок и загрузкой ассетов быть не должно. Большая часть явно референсится в сценах (учитывая что их можно грузить аддитивно), остальное можно запаковать в бандлы (да и сцены можно туда же), и работать с ними как с обычными ресурс-паками.
Я ScriptableObject'ы использую. В идеале, эдитор скрипт, который создаёт скриптейбл для каждой категории объектов и сам заполняет. Нажал кнопочку, все объекты из папочки залились в массив и готово. Пик для ебанатов от ебаната.
Вот недавно доделал урок на catlikecoding из серии object management.
https://catlikecoding.com/unity/tutorials/object-management/persisting-objects/
И у меня по итогу выполнения возник вопрос.
В ходе урока, автор делает несколько доп классов для генерации объектов, сохранении и прочего.
И такой подход существенно отличается от того, что я видел раньше в различных видеоуроках (как от самой Unity, так и от сторонних разработчиков).
Имеет ли смысл вообще так париться для генерации объектов, делать доп.классы и тд.
Насколько понял я на данный момент, автор использует язык на полную катушку.
Имеет ли это смысл для большей производительности в более крупных проектах.
Например, функции сохранения и загрузки в уроке, почему бы не использовать уже какие-то готовые решения (сам не знаю, но уверен, что они есть).
По-моему, абсолютно энтрилевельный урок. Да. Нужно. Такого "уровня запарки" хватит на игру уровня гд, но для чего-то сложнее этого мало. Для обучения сойдёт.
>автор использует язык на полную катушку.
Ноуп. Он даже интерфейсы не использует, нет множественных наследований, да и виртуальные у него только методы, а могли быть и абстрактные классы нахуй, нет событий, объект менеджеров, экстеншенов и прочей хероборины. И близко не на полную катушку. Вон на пик глянь, это дефолтная юнити хуйня из ЕЦС. Одно <T> осознавать надо не меньше часа, а учиться пользоваться ещё дольше. Кек.
У меня сейчас из установленных юнити игр есть только клифф эмпайр. Заглянём в код. Ух, не ассасин крид, но всё же. Вся сложная херота, о которой я писал, писалась в контексте "язык на полную катушку". Ну да, возможно, оно вам и не надо. Но, очевидно, с этим всем жить будет легче.
>>602234
Оно осознаётся, как GetComponent(typeof(T)). Чем и является по факту. Когда пишешь что-то вроде GetComponent<T>(this T ComponentData, ComponentSystem system) where T : struct, IJob это уже по-другому воспринимается.
>У меня сейчас из установленных юнити игр есть только клифф эмпайр. Заглянём в код. Ух, не ассасин крид, но всё же. Вся сложная херота, о которой я писал, писалась в контексте "язык на полную катушку". Ну да, возможно, оно вам и не надо. Но, очевидно, с этим всем жить будет легче.
Вот же тупой ретард.
> 99.99784% i
> https://store.steampowered.com/app/809140/Cliff_Empire/
CLiff EMpire, как и Skyline - эти самые 0, 003% тупой пездло.
Если ты хочешь что-то доказать докажи что более 0,003% это нужно.
У него там все ошибки в консоли, пусть исправляет.
>>602242
Мне предлагает за 120. Не просто, а очень просто. У них там есть переменные DULO, OBOJMA и логика в апдейтах. И геймплея кот наплакал, хотя задел интересный. Было бы заебок сделать такое в онлайне с соседями-сычами на ближних скалах. Вот ещё подороже Universim за 380 рублей, но тут уже и игра побольше, чем на 30 минут.
>
Хочу предложить свои услуги по созданию музыки для ваших инди-игр . Вот группа с примерами моих работ https://vk.com/sentaimask
Environment.Exit(0)
я вам говорил, что чибиков в 3д не сложно делать
https://www.reddit.com/r/Unity3D/comments/crpt46/working_on_a_harvest_moon_style_deposit_box/
Игра не загружает сцену. Игра на Android. Я тыкаю на кнопку, но она не переходит на новую сцену. Я только недавно начал заниматься Геймдевом и уже сломал голову почему не работает переход.
Им не надо знать даже что такое юнити, чтобы увидеть популярный ассет и понять что это вонючий ассетфлип.
https://youtu.be/jsh0q_22leU?t=115 1:15
Это лучше чем высасывать из жопы абстрактное число треугольников.
Фпс зависит от кучи деталей. Материалы, батчинг, производительность скриптов.
Для своей игры выбираешь базовый фпс и стараешься делать так, чтобы он не проседал. Запускаешь профайлер и смотришь. Ага, на этой сцене со столькими-то моделями фпс проседает.
Упёрся в дк, фиксишь-фиксишь, 60 фпс стабильно. Повод вздохнуть с облегчением? Разве что серануть в портки, ведь у тебя не самая днищекарта и не кор два дуо мобильный в троттлинге. Даже если у тебя всё заебись, всё равно откуда-то раздастся вскрик "тормозит!".
>Без компонента ...боди твой объект не влияет на физический движок. Коллайдер это всего лишь геометрия, как меш, например.
Доки говорят об обратном
https://docs.unity3d.com/Manual/MobileOptimisation.html
>Never ever move a static collider (ie a collider without a Rigidbody) as it causes a big performance hit. It shows up in Profiler as "Static Collider.Move’ but actual processing is in Physics.Simulate. If necessary, add a RigidBody and set isKinematic to true.
https://docs.unity3d.com/Manual/CollidersOverview.html
>Colliders interact with each other differently depending on how their Rigidbody components are configured. The three important configurations are the Static Collider (ie, no Rigidbody is attached at all), the Rigidbody Collider and the Kinematic Rigidbody Collider.
>Static Collider
This is a GameObject that has a Collider but no Rigidbody. Static colliders are used for level geometry which always stays at the same place and never moves around. Incoming rigidbody objects will collide with the static collider but will not move it.
>The physics engine assumes that static colliders never move or change and can make useful optimizations based on this assumption. Consequently, static colliders should not be disabled/enabled, moved or scaled during gameplay. If you do change a static collider then this will result in extra internal recomputation by the physics engine which causes a major drop in performance.
Вдогонку
https://forum.unity.com/threads/what-exactly-is-considered-moving-static-colliders.159434/
>Moving a collider that doesn't have a rigidbody is moving a static collider.
Хуже террейна ничего нет. Тот долбоёб выше скорее всего писал про шейдер граф, потому что по шейдерам документация есть, а по графу нет. Но граф превью. Он охуенен, но технически слабый, ущербный, как и в уе. А кастом ноды пока не завезли, хотя обещают, но пока превью хуй дождёшься.
Рилтайм терраморфинг без фризов на полсекунды? Более адекватная сетка? Дыры, сквозь которые райкаст проходит, а не упирается в террейн? Переопределение материалов травы без ебли в жопу? А на hdrp даже ебля в жопу не спасает. Несколько материалов для террейна? Адаптивная деградация сетки? И при всём при этом террейн просто пиздец насколько тяжёлый.
>>602980
А там сабшейдер с сабпассом. Без поддержки геометрических и вычислительных шейдеров. Вообще никому в голову не приходило, что каждая нода шейдер графа делается через сабпасс сабшейдера, а 10-20 проходов шейдера на материал это многовато, никто так не считает?
>А там сабшейдер с сабпассом
Нет, там 2к строк шейдерного говнокода без возможности что-то изменить. Юнитивские материалы это полное убожество. Ты можешь или сделать unlit shader для 2д и пост-процессинга, или т.н. surface, который есть захардкоженный генератор шейдерной портянки. Все.
В том-же xenko например охуенная модульная система материалов.
>Нет
Да. Я про субноды писал. Добавил ты в граф ноду - а эта нода сабшейдер с проходом. Шейдер граф превью, он не готов, совсем не готов. Можно установить, потыкать, пользоваться нельзя.
>без возможности что-то изменить
Код генерируется по шаблону. Шаблон обещали дать изменить, пока фича не готова. Можно установить не из пакета, а из гита, изменить шаблон и проебать все шейдеры, которым нужен был старый шаблон. Можно делать кастомные субноды, если знаешь hlsl, но когда я тыкал в них последний раз, они были не готовы.
>xenko
Но это не отменяет того, что хенко хуже червя-пидора.
>>603027
Сетку с ландшафтом я и сам генерировать могу. Мне террейны нужны, а не сетки.
>Я про субноды писал
Я имел ввиду стандартный surface shader, а не shader editor.
>Добавил ты в граф ноду - а эта нода сабшейдер с проходом.
С чего ты взял? Нету там такого. Там генерится что-то вроде обычного surface shader'а.
В каждой ноде захардкожена строка, которую эта нода выводит в код шейдера и все.
>С чего ты взял? Нету там такого.
Чтобы не выбрал, даже констракт с гамаком, все равно, рано или поздно придется писать переменные, какие-то функции, которые обслуживают игровой мир.
Т.е. в принципе разницы нет. Можно сразу вкатываться в EU4, все равно везде одно и тоже. Только сразу придется синтаксис C+ учить, а не тратить время на мертворожденные языки.
>Вкатываться в мертворожденный движок чтобы не учить мертворожденные языки
>Можно сразу вкатываться в EU4, все равно везде одно и тоже. Только сразу придется синтаксис C+ учить
Если ты думаешь, что для тебя, как для полного нуба, какой-нибудь С# и С++ это "одно и то же", тебя ждет много открытий.
Но на УЕ4 есть визуальное программирование, в которое для таких как ты намного проще влиться только не рассчитывай, что когда освоишься с блюпринтами, сразу перескочишь на С++
>Но на УЕ4 есть визуальное программирование
Так вы заманиваете ленивых ньюфагов в свою секту?
Блюпринты это бесполезная игрушка для дизайнеров карт, чтобы интерактивные двери делать. Больше они ни на что годятся.
Даже если бы эпики оставили unreal script, от него и то бы пользы было в 100 раз больше чем от всратых блюпринтов.
не ленивых нюфагов а неокученных зумеров с мышлением ГРОГ СОЗДАВАТЬ ОКОШКИ, ГРОГ ПРОГРАММИРУЕТ
кто-то из них правда со временем начинает подозревать в чем наеб и соскакивают с этого хуя и идут учить настоящие языки (что от них честно говоря и требовалось кек)
Неокученный зумер итт, так и пересел с playmaker на нормальный шарп когда заебался делать 50 кликов мышкой и 7 лагучих драгендроп окошек просто чтобы персонаж ходил и прыгал на пробел вместо пяти строк кода, ни о чем не жалею эта залупа помогла освоиться в среде юнити. А еще я охуел от возможностей ооп классов и прочих интерфейсов. Вспомнил еще ебучее - в плеймейкере онли одномерные массивы. Короче просто хотел сказать что визуальное программирование не такая уж и бесполезная вещь.
1. несколько 2д гридов [x, y] вертикально, каждая нода с переменной h (патфайндер не будет считать маршрут всего здания, а только до лестницы к следующему этажу)
2. 3д грид [x, y, z] (патфайндер маршрутизирует на все три оси, не нужно ебаться с линкованием этажей, но насколько понимаю аллочится дохуя ненужных блоков, даже если они null?)
https://docs.google.com/document/d/1HJLsUXklwVgaOJsnias0GoyW2i0tFmE4cae-IbUsq20/edit
Я только начал изучать униту но с программированием я знаком немножко больше.
Как мне показалось с точки зрения кода задача очень проста для мидла.
Или она трудна и я просто не могу осознать этого в силу своих малых знаний?
Я
Это фантазия специальная на алгоритмы. Есть художники которые классно раскрашивают, но построения проебывают, у них своя специальность, даже в рисовании разделяется, не говоря уже про разные области. 3дскульпторы в большинстве хуевые концептеры, про прогеров и говорить не приходится