Это копия, сохраненная 26 мая 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Обосрался ты Оп, сслыку на прошлый тред кинул на тред для ньюфагов.
И что это за говно на 4 пике? Где ГРОФОН?
>Девчонка из ue4. Юньку ещё дет десять надо пилить, чтобы такую графику выдать.
Что несешь, пидар-сын шлюхи?
https://twitter.com/Yokohara_h/status/1222612651630444544?ref_src=twsrc^tfw|twcamp^tweetembed|twterm^1222612651630444544&ref_url=https://2ch.hk/gd/res/631674.html#631674
Все будут ходить в очках дополненной реальности, и вместо твоего коростного ебальника будет на автомате подставлять личико этой тянки.
Трюки для реалистичности из доков уе применил в юнити, обоссанный тупой сын шлюхи, пиздец ты даун.
Идиот сам твит почитай и теги к нему. А это фраза которую ты как орангутанг цитируешь - очевидной кривой инглиш автора, у которого он не основной язык
Если я тебя правильно понял, то так:
Transform.position = (T1.position - T2.position).normilized * distance;
>расстояние от зеленого до середины между объектами не меняется
То есть он может находиться в любой из этих позиций?
Тогда можешь сделать пустой объект и повесить на него такой скрипт:
transform.position = Vector3.Lerp(T2.position, T1.position, .5f);
Чтобы он был посередине и уже к этому объекту как-то сам крепить объект с камерой.
Так и сделал.
Я хочу использовать тёмную тему, а также не хочу показывать Splash Screen с логотипом Unity
А ты делай текст под размер кнопки, и всешеньки.
Не нравится - сделай свой движок. Сколько можно ныть?
Он не ноет. В годототреде он обсирает годот, в юнититреде он обсирает юнити. Просто репорти его и отправляй в бан. По другому он не поймёт.
А ты что делаешь?
за нарушение манямирка вахтёрящей совкогниды
1680x966, 0:15
>>41967
проще спросить что пытаешься сделать. без абстракции.
пытаешься таскать зеленый шарик за середной между двумя другими шариками? зеленый шарик летит только в сторону центра, или ещё и толкается им? нужен ли физон?
>>42157
всегда было интересно чем это мешает
>>42118
всегда можно сунуть кнопку в текст лол
1680x966, 0:15
чет лиса ошибку выдает при попытке воспроизвести. да и весит много. сделал вебм
>пытаешься таскать зеленый шарик за середной между двумя другими шариками?
Да неважно, я уже сделал и мне не подошло.
>какую клевую хуйню теперь умею. зеленым завихрённость, синим давление.
Да ты вообще отморозок, демон
В rb просто можно по всякому с физикой играть, делать скольжения, етц?
Как принято у нормальных пацанов?
все, понял
зачем через консоль и без интерфейса? Скачай хаб и ставь через хаб нужную версию, все ставится нормально. Вот раньше без хаба была жопа. А сейчас работай - не хочу.
Так вот, большую часть логики я прекрасно представляю себе на основе событий, но не нажатия на клавиши. Сколько ни гуглил, везде нажатия проверяются через Update, то есть каждый кадр спрашивают, не нажата ли клавиша. Потому хочу спросить, нельзя ли и нажатия на клавиши проверять вне Update, через события?
И вообще сильно ли роляют проверки нажатий в Update? Быть может, я гоняюсь за мизерным выигрышем по производительности, и все процы начиная с 386 нихуя не почувствуют от таких проверок? Мне просто очень страшно, что я сделаю неоптимизированное говно (хотя я в принципе не сделаю ничего цельного, это да).
Ну создай иф инпут и скопируй миллион раз, посмотри тупой что будет.
Не надо преждевременно оптимизировать. Проверять инпут в апдейт наверное не плохая идея. Даже если бы ты это сделал через события, думаешь они не проверяются каждый кадр где-то там внутри юнити?
а нахуй тебе это вообще надо ? твой персонаж будет нажимать кнопки всю игру ? или я че то не понимаю. Есть другие вещи которые сильнее влияют на оптимизацию и о которых надо заботиться сильнее. Я делал саундборды на юнити и вообще похуй на эти кнопки на любой мобилки нормально, нету проблем С ОПТИМИЗАЦИЕЙ
Ты на миллионе персонажей будешь интпут проверять что ли?
Да даже если и на миллионе, операция сравнения ничего не стоит.
И многую логику кроме как в апдейт пихать некуда, если только ты не будешь пользоваться вот той другой архитектурой
Разве что не стоит очень тяжелые вещи выполнять в апдейте каждый фрейм. Чекать хп персонажа на предмет сдыхания можно и раз 30 в секунду, а всякие статусы обновлять вообще 1-2 раза в секунду, а не 50-100
> да хоть че.
Могу пофантазировать с дивана.
Например, закладываешь в уровень несколько слоёв, выключаешь видимость всем неактивным слоям. Рисуешь шейдер с эффектом перехода при котором слой 1 плавно исчезает, а слой 2 плавно появляется. И всё, дальше в зависимости от игровой механики скармливаешь шейдеру два слоя 1 который надо скрыть, 2 который надо показать.
>
>
Тоже думал о таком костыле. Впринципе Игрок схавает. Можно сделать как ты предложил. Мне Тоже кажется что это просто Игра с Слоями.
Типа если ты до 100000 зеленых не поднял на игре, то ничего не платишь, а если поднял, то покупаешь лицензию и все?
Умный ход.
Да по условиям лицензии надо 100 000 зеленых. В бесплатной версии еще Начальное лого Unity нельзя убирать Когда игру запускаешь.
Эти может волновать только школьников, которые даже близко не подойдут к этим 100к. Серьезных людей эти лимиты вообще не парят, т.к. стоимость лицензии копеечная по сравнению с вложенными трудочасами в коммерчески успешный проект.
Да эти 100к сделаны для галочки, все равно никто не проверяет.
>100к зеленых это средняя западная зарплата в год
>в США средняя зарплата 1200-2000 зеленых в месяц
И сколько же месяцев в твоем году?
Сто тысяч долларов это пиздец какие огромные деньги, особенно для мухосрансков.
>огромные деньги, особенно для мухосрансков
В мухосранске ты на эти деньги даже нормальную 2х комнатную квартиру не купишь.
???
Я просто бомж-студент без стипендий, у меня даже на доширак денег нет, жру что есть в общаге
ну или что-то подобное
Нет, я не делаю убийцу dark soul. я хочу сделать нечто большее - наследника Severance Blade of Darkness :)))))
Сто тысяч долларов в год имеется ввиду же
Народ, я крч топдаун игрушку пилю спрайтовую в 2д, сейчас думаю над алгоритмом поиска пути. Сильно ли затратно будет каждый фикседапдейт посылать коротенькие сквозные рейкасты[ ] допустим в шесть сторон, или может стоит триггер повешать и чекать им коллизии на расстоянии от объекта, который ищет путь?
>каждый фикседапдейт посылать коротенькие сквозные рейкасты[ ] допустим в шесть сторон
Если на один скрипт только на сцене то не сильно, если на 10+ то уже начнёт кушать ресурс
НЕ СМЕЙ БЛЯТЬ ЮНИТИ ВЗОРВЕТЬСЯ!
Нормально всё будет. Можешь хоть сотни этих лучей пускать. Вот тебе статейка по теме:
https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732
Бля, написал и понял что нужно его прилепить к пустышке и уже ее крутить изъебнувшись.
1600x752, 0:17
Ясно, спасибо.
Ламерский вопрос но всё же, у меня есть префаб со стандартным спрайтом (таких будет дофига), нужно по условию (время) менять ему спрайт. Насколько я понял стандартно это делается по убогому, нужно на скрипт повесить 100500 спрайтов в виде public и использовать что-то вроде:
GetComponent<SpriteRenderer>().sprite = sprite2;
Можно ли обойтись без этих перетаскиваний а сразу из скрипта их указывать?
Могу предложить два способа через ScriptableObject. Я использовал первый способ, но в следующем проекте использую второй наверное.
Значит, пишем ScriptableObject, который будет выступать контейнеров спрайтов. Из редактора он будет принимать массив ссылок на спрайты. Внутри будет хранить их в словаре по имени, чтобы ты мог удобно с ними работать. А в твоём префабе тебе нужно будет задать ссылку на один лишь инстантс этого ScriptableObject. Вот как примерно может выглядеть код:
https://pastebin.com/ipdykLQs
Второй способ развивает первый. Вместо того, чтобы задавать ссылки на списки каких-то объектов, мы используем синглтон, который будет представлять базу данных игры. Скины, оружие, портреты, всё что угодно. Внутри себя синглтон будет использовать списки из ScriptableObject и предоставлять тебе результат в скрипте.
Внутри префаба нужно будет написать типа:
GetComponent<SpriteRenderer>().sprite = Database.GetSkinSprite("skin_sprite_name");
Думаю ты идею понял короче.
Но это же мальчик.
Бамп
>Подскажите, какую версию качать. Тупо последнюю, которую предлагает установщик (2019.3.1f1)
Да.
А в первом варианте допустим я создал класс Sprites, а как туда добавить собственно все спрайты?
И как использовать например в скрипте Player?
Просто про ScriptableObject первый раз слышу, видео посмотрел не до конца понял как его использовать.
На самом деле можешь 2017 скачать, она попроще, меньше заебов со всякими hdrp
>видео посмотрел не до конца понял как его использовать
Ну, бля, посмотри ещё видео. Почитай статьи. Это простая вещь. Если ты будешь так лениться, то заебёшься игру создавать.
Хорошо, а вот почему у меня меню создания ScriptableObject не появляется, в чём проблема?
[CreateAssetMenu(menuName = "Sprites123", fileName = "SpriteData")]
public class Sprites : ScriptableObject
Разобрался, были ошибки в другом скрипте
Я так понял что блендер.
Нашел курс на юдеми, но его обновляют до 2.8 версии блендера. Что бы можно было поучить за это время? Прошел уже курс на юдеми по юнити и на сайте юнити пару курсов для новичков. Хочется что-то средней углубленности.
Больше же ничего не надо для норм гейдева, только знания по юнити и блендеру? Или может стоит пройти курс по рисованию в гимпе?
У тебя хоть планшет есть графический, чтобы нормально блеедером пользоваться?
>больше же ничего не надо для норм гейдева, только знания по юнити и блендеру?
Да, ничего больше не нужно, можешь приступать к работе над собственной жта или калофдутией.
Нет.
Ну так пояснил бы за графические планшеты бы, я в этом никуку. Но думаю для всякой 2.5д дрочильни не надо будет так заморачиваться, хотя...
Посмотрю по делу, мб и возьму. Главное не забить на все и не сидеть на дваче сраться.
Что мне пояснять? В па висит тред, зайди до смотри, самым лучшим будет всегда очевидный самый дорогой ваком синтик за 200к
А так тебе китайщина сойдет, но если у тебя нет скилла рисования, тебе будет потежелее, да и вообще, к планшету придется привыкать, но мышкой никто не скульптит
>знания по юнити и блендеру
Еще нужно как минимум:
1) Анимация
2) Збраш (ну или хз, в блендере можно скалптить хайполи)?
3) Сабстанс пеинтер
4) Топоган или любой софт для ретопологии, плюс скилл ретопологии
5) хнормалс или любой софт для запекания, плюс сам скилл запекания
6) Марвелоус дизайнер
7) Мейкхуман, даз и все-такое для моделирования людей.
Вроде все упомянул?
Круто, спасибо за списочек. Половину не знаю что это, видимо мне еще долго учиться.
И будет и профит, выпущу игру в плей маркете, будет 2000 закачек. Но все равно интересно вкатиться.
Анимации учил в курсах юнити, но там по быстрому. Я так понял их лучше в блендере делать, в блендере можно текстурами тоже модельки покрывать. Все это должны учить в курсе по блендере на юнити, но они апдейтят до 2.8, так что жду.
>1) Анимация
Макс или майа из каропки могут
2) Збраш (ну или хз, в блендере можно скалптить хайполи)?
Можно но больно и неудобно, збраш не нужен.
3) Сабстанс пеинтер
Да, ещё желательно субстан дезигнер, для своих материалов.
4) Топоган или любой софт для ретопологии, плюс скилл ретопологии
5) хнормалс или любой софт для запекания, плюс сам скилл запекания
Делается в два счёта штатными средствами макса\майки
6) Марвелоус дизайнер
Двочую, для одежды лучше нет ничего.
7) Мейкхуман, даз и все-такое для моделирования людей.
Хорошие заготовки но если юзать только их - оче всратые гг выйдут.
Вроде все упомянул?
Нет, забыл мармосет указать для красивых рендеров. И любой растровый редактор или фотошоп на крайняк для рисования UI
Ты только учти, что все что он перечислил нужно если ты планируешь делать ААА модели. Для графона уровня пикрил одного блендера хватит вполне.
>Maya
>Price: 1470$ / year
>3Ds Max
>Price: 2.141,70 € / year
>OS: Windows
Чуть не поперхнулся. Это дорого.
Уверены что блендер новой версии не умеет во все то же?
Фотошоп тоже недоступен на линукс и 120$ в год, вроде. Лучше обучиться крите или гимп (шо лучше для гемдев рисования, скажите плис). Так как надо выбрать чему обучаться.
>>43718
Я даже хуже хочу, чем тут, но может даже так-же. Лучше всего что-то логическое придумать... у меня еще проектов нет, просто хочу сперва обучиться всяким плюшкам, чтобы потом не переделывать.
Ты не задумывался почему в инди геймдеве практически одно 2д, а полноценные 3д проекты, типа Kenshi, делаются по 12 лет, из которых последние лет пять разработки автор уже работал не в одиночку?
гимп может почти во все что и фотошоп, для геймдева за голову, просто надо переучиться и многое не интуитивно. Как по мне, лучше сразу обучиться бесплатному оперсорсному. Хотя я и выбрал проприетарную юнити, но тока из-за бесплатности для низких заработков (до 100 000 баксов в год).
>>43723
А я говорил что хочу делать гта? Я говорил что у меня будет лучше всех, самый топовый графон и все самое-самое? Нет, я понимаю свои силы и сразу сказал что скорее всего буду делать 2.5Д дрочильню.
>>43726
пинус охуенный
>гимп может почти во все что и фотошоп
Нет не может.
>для геймдева за голову
Для дрысни за 100р\шт, говори правильно
>просто надо переучиться
Не просто
>и многое не интуитивно.
Не интуитивно. Как пользователь линуха (второй системой стоит) это тебе говорю
>Как по мне, лучше сразу обучиться бесплатному оперсорсному.
Зачем ?
Это ухудшит разработку и качество
> Хотя я и выбрал проприетарную юнити, но тока из-за бесплатности для низких заработков (до 100 000 баксов в год).
Типо пропиетарность это для пидарасов, но если в жопу ебать через пакетик то не считается, верно ?
>>43726
Двочую, так же подумал. Видимо совсем ньюфане голову вскружило.
>пинус охуенный
Только вот бесполезный дома, если у тебя задачи для пеки не уровня посидеть в интернетике\музыку послушать.
пиздец пассивно-агрессивный спермо-фанбойский манямир не соответствующий реальности.
>я понимаю свои силы и сразу сказал что скорее всего буду делать 2.5Д дрочильню
Силы ты свои поймёшь, когда хотя бы один рабочий мини-проектик сделаешь с напизженных ассетов, баги отладишь, интерфейс там, все дела. Или хотя-бы попытаешься 3д модельку сделать анимированную.
>из каропки могут
Вопрос не в том что это могут макс или майя, а в том чтоб это умел сидящий перед монитором человек. Как сделать скелет, как настроить констрейны, как сделать удобный риг, как настроить для него инверсную кинематику, как расставлять и редактировать ключи, плюс сами принципы анимации - walk cycle и вот это вот все.
>збраш не нужен.
В любом случае хайполи где-то нужно делать, и намного удобнее скалптить в збраше чем моделить.
>Делается в два счёта штатными средствами макса\майки
Допустим у тебя есть хайполи модель, тебе нужно сделать лоуполи. В топогане ты рисуешь полигоны поверх имеющейся модели, в максе или майе ты просто заново моделишь из кубов. Можно и так, но первое быстрее. И нет, это далеко не в два счета.
По поводу нормалей - опять, смысл не в том чтоб это умела программа, а чтоб это умел пользователь. Чтоб он знал какой формы должна быть геометрия чтоб с нее нормально запекалось, как расположить кейдж, как разнести меши в пространстве чтоб запеклось только то что нужно, как сделать юв развертку именно под запекание. И опять - это далеко не в два счета.
>>43718
Не вводи людей в заблуждение, это стандартный пайплайн вообще для всего геймдева. Даже в дазодрочильнях про мамок идут примерно по такому же пути. Ну и Зельда как бы тоже ААА тайтл.
Вот только на модельке линка меньше 5к полигонов. Думаешь такое нельзя сделать в блендере?
Декомпилер есть но он вроде только код показывает
С помощью этого говна можно вытащить некоторые ресурсы
https://7daystodie.com/forums/showthread.php?22675-Unity-Assets-Bundle-Extractor
Собранные через моно игры разбираются любым шарп-декомпилером. А вот собранные IL2CPP вроде как должны быть нативными бинарниками и декомпилироваться только как ассемблер? Профи, проясните.
Это старьё.
Завтра может буду разбираться, надо чтоб как в репае по полочкам деархивирвалось, скрипты, пикчи и т.п. (но мне кажется нет такой)
В юнити можно делать переменные [SerializedField]
Инструктор на курсах говорил что это защищает от реверсной инженерии игры. Или это все хуйня и код всегда будет всем кому нужно виден?
все можно. юнити дырявый.
есть бесплатный uTinyRipper - он полностью востанавливает весь проект для юнити редактора (но без кода)
код можно вытянуть через dnSpy и аналоги
Есть платный DevXUnityUnpackerTools - по идее в платной версии он должен востановить вообще все - даже IL2CPP
херня, DevXUnityUnpackerTools умеет восстанавливать IL2CPP (там прямо в настройках есть) - что означает что никакой реальной компиляции в CPP там на самом деле нет, а юнити маркетингово врут и их IL2CPP - это все тот же интерпретатор
Допустим, делаю я гоночки онлайн, хочу сделать магазин с скинами, таблицу лидеров и мультиплеерный режим с созданием комнат и общей игрой. Не ммо, максимум создание комнат игровых
И вот тут я сильно путаюсь в доступных вариантах- Photon PUN, Playfab, сюда еще можно всякие Google Play прикрутить и еще наверное много разных сервисов, о которых я еще не знаю.
Анон, как в самом минималистичном варианте реализовывается простенький мультиплеер по сети? Чем Photon от Playfab отличается? Я так понял, их вместе можно использовать? Кто-нибудь вообще сталкивался с таким? Или всё это можно реализовать с помощью API Google Play? И как ко всему этому еще магазин со скинами прикрутить, он то какой системой крепится?
Вот к примеру- хранение данных об игроке. Уровень, статус, инвентарь. Это где вообще делается всё?
>Господа, а поясните за сетевую составляющую Unity игр на мобилки
>>487807 →
>>43893
Речь о нормальной двушке. То есть это должен быть центр, это должен быть хороший дом и так далее.
Спасибо, понятно, играл в эту игру в браузере, забавно, не думал, что это наши челики делали.
В таком случае, логичнее всего наверное запилить демку и уже с ней искать издателя, который поможет с деньгами и с поиском сотрудников для создания полноценной сетевой составляющей?
Если решил стать инди или даже с друзьями пилить что-то интересное, то это минимум пару лет сидеть дома и работать над своим проектом в надежде, что он вообще кому-то понравится.
С другой стороны можно уйти в студию на зарплату и работать в ней, но блин, смотрю вакансии, а там какие-то проекты дурацкие, то казуалки-клоны, то какие-то хардкорные нишевые РПГ, которые я не особо люблю и не разбираюсь в них.
Еще и если решил работать как инди, то это постоянное давление и саморефлексия по поводу того, что ты делаешь какую-то хуйню, сомневаешься в себе постоянно, думаешь о том, что сидишь на шее, а мог бы уже устроиться на работу и зарабатывать деньгу нормальную.
Думаю, может быть уже пора изучить весь оставшийся необходимый стак технологий и пиздовать работать в студию программистом, а то сидеть дома и пилить свои проекты это какой-то ад, каждый день просыпаешься и сидишь за компом, даже на улицу не выходишь толком. И всё ради того, чтобы через год или два найти издателя? Это действительно стоит того?
Как блядь сложно жить.
Может быть, пока ты еще на нулевой стадии, еще не поздно перепрофилировать гоночки-онлайн на гоночки-офлайн?
Да, я на нулевой стадии, всё верно, просто изучаю технологии и требования, которые нужны для онлайна, пытаюсь понять, насколько это будет сложно. Интересная же тема, приятно играть с друзьями, социальные взаимодействия и всё такое. Но чувствую что сложность возрастает в десятки раз, по сравнению с сингловыми проектами.
Инди же как раз и делает сейчас упор на сингл, те же разные платформеры и игры с историей интересной неплохо взлетают.
Эх.
>Блин, я так понимаю
Ты неверно понимаешь. Статью прочитай
https://habrahabr.ru/company/pixonic/blog/346374/
Тебе нет смысла делать мультиплеер с выделенными серверами, авторитарной логикой, античитами и т.п.. Это сложно, долго. И вряд ли ты окупишь такую разработку. С Photon PUN даже новичок может создать сетевую игру. Блять, даже создатель копателя смог добавить сеть в свою игру.
Хм, окей, попробую вникнуть в тему получше.
>даже создатель копателя
Хех, вообще не представляю, как он это сделал, мне кажется это невероятно сложно.
Спасибо за ответ, буду разбираться тогда.
Наверное сперва стоит делать что-то небольшое, выпустить штук 5 такой фигни, посмотреть, изучить что заходит, сделать потом проект покруче или просто апдейтнуть полностью тот проект что выстрелил больше всех, добавив больше уровней, глубины, веселья.
И опыта наберёшься. А сразу лезть в что-то непонятное довольно опасно, но раз уже начал, то продолжай. Можно пару уровней сделать, типа ирли эксес, потом доделать.
Ага, план такой есть.
Сделал уже фигни, сейчас как раз занимаюсь апгрейдом.
Просто понимаю, что скилов уже нормально так накапливается, можно было бы и на работу попробовать устроиться.
С одной стороны стабильность и работа на дядю, с другой свобода и независимость. Но с этой свободой приходит и мучительная ответственность.
Все вокруг работают, деньги зашибают, а я сижу как сыч и программирую какую-то хуйню, которая еще и может никому не понравится, в надежде, что когда-нибудь её доделаю и смогу заработать хоть что-то. Но пока что не заработал почти ничего, кроме жопоболи, садящегося зрения и тревожного состояния.
Начинал так же - делал игрули с друзьями и в одиночку, которые никогда не выходили в свет. Накопил опыта и портфолио, которое потом показывал на собеседовании. Инди не взлетело по понятным причинам, поэтому выбор пал на работу в компании. Делаю не совсем то, что нравится, но скилл растет. Пилю по вечерам своё детище, чтобы творческие позывы находили выход. Коплю портфолио, которое потом можно будет показать другому дяде за бугром.
Продолжай оттачивать мастерство, желательно, на небольших проектах разных жанров. Новичкам долгострои очень тяжело даются, появляется много архитектурных проблем из-за которых разработка буксует и останавливается совсем. Показывай свои проекты близким, знакомым, это помогает поддерживать мотивацию. Если делать игры - твоя мечта, то иди к ней и страдай.
Устройся на работу сторожем сутки трое или охранником в пятёрочку или возьми удалёнку на 3 часа в день, короче найди РАБоту не сильно занимающую время, тогда не будешь сидеть на шее и будет время пилить игоря. Ну что вы как маленькие.
Разраб стардью валлей билетёром каким-то работал и игоря пилил в оставшееся время.
Я 5/2 херачу и всё равно что-то делать успеваю.
Блин, анон, я тоже думаю о таком варианте- накопить портфолио и показать дяде за бугром. Сколько, два-три года усердной работы и можно спокойно переезжать?
>Продолжай оттачивать мастерство на небольших проектах разных жанров
Хорошая мысль, я так и делаю, правда подгоняю жанры под стак технологий.
Сейчас вот как видишь мультиплеер захотел изучить, потом собираюсь в DOTS поковыряться, шейдеры подучить, Zenject и разработку под мобилки подтянуть. Пока я всё это изучаю может быть и проект свой соберется к релизу.
>Если делать игры - твоя мечта
К сожалению, я не из тех людей, у кого геймдев это настоящая мечта. Скорее, я просто выбрал этот путь как единственный, который соответствует моим жизненным принципам. Прозвучало как-то высокомерно и напыщенно, но думаю вы понимаете
>>43975
Да, ты всё верно говоришь, выход можно найти всегда. Ты молодец, что еще и время на проект свой находишь.
Я вот понимаю, что проблема у меня не столько даже с деньгами, сколько в самоидентификации, постоянные самокопания и какая-то неуверенность в том, что я делаю. Еще и хиккование это давит, сижу за компом целыми днями и кажется, что вся жизнь мимо проходит. Все гуляют, что-то делают, а я друзей не видел уже несколько недель.
Но вот сейчас пообщался с вами и стало полегче, спасибо большое.
ну не знаю, везде пишут что Эрик Бароне свою стардювали пилил три года сидя на шее у своей тян и не работал нигде
Тут как повезет. Но везение это такое. Главное сделать кросиво, стильно, чтобы приятно было пользоваться, не забивать на анимации, самая главная часть. И тогда, если механика хоть немного будет привлекать, должно набрать лойсов/отзывов и чутку взлететь.
Я встречал чела в б, он что-то вроде 30 игр наделал в гугл плей, говорил что збс, капает со всего и нормас. Запомнилось что он сказал что похрен на негативные отзывы, если много хороших, а так, из-за него я и взялся за юнити.
Если не взлетит, делай еще, но уже что-то менее серьёзное. К тому же опыт реальный, портфолио, не зря проебываешь время. У меня прога в гугл плей не сразу набрала колво установок что сча, где-то год-полтора набирала популярности, хз как это работает, какие-то алгоритмы гугл. Так что не ожидай что сразу игра реализирует весь потенциал популярности. В первый месяцы может быть по 20-40 закачек в месяц.
Не, если верить книжке "кровь пот и пиксели" то он действительно работал в кинотеатре, когда его совсем заебало хиккование и сидение на шее.
Спасибо за поддержку, анончик, очень помогает.
>К тому же опыт реальный, портфолио, не зря проебываешь время
Да, точно, это ж ещё на портфолио всё работает, надо не забывать об этом.
Ладно, решить бы проблемы с тем, чтобы не сойти с ума в четырех стенах и было бы всё получше. Надо может быть гулять почаще. Но это уже такое, тараканы в голове.
>Сколько, два-три года усердной работы и можно спокойно переезжать?
Если под усердной работой ты понимаешь 8-12 часов работы каждый будний день без отговорок, то да. Но я тебе точно говорю, что это нереально.
Если, как я, и как большинство свободных людей, работать 3-6 часов с разовыми перерывами на подработки, то за год-полтора можно только выйти на уровень, когда тебя начинают серьезно воспринимать на собеседованиях. Ещё через год-два можно говорить: "да, я шарю", но крутым спецом называть себя ещё рано.
Чтобы сьебнуть за бугор чисто за счёт скилла, думаю, придется батрачить лет 5, чуть меньше, если работать в компании, чуть больше - если в свободном плавании.
На многое влияют твои амбиции. Если ты делаешь простые мобилки месяца за 4, то у тебя будет и портфолио, и минимальный доход. Если же ты собираешься за полгодика запилить игру мечты, то готовься, что ты убьешь на неё два года, психику и душу. И скорее всего она даже не выйдет.
В общем, работаю на юнити, по каким-то причинам в инспекторе не показываются некоторые методы. Иногда каждый первый идёт нахуй. Так же с массивами, если после объявления массива куда-нибудь его вставить, то в инспекторе посылают нахуй. Приходится объявлять сохранять, потом продолжать писать.
Это вообще нормально или это можно исправить? Я уже заебался на залупе перед этими методами стоять, чтобы они появились в инспекторе.
Если это поможет, то ПК у меня очень старый, если нужно скину характеристики
Заранее благодарю.
Сколько по времени вы занимаетесь делом каждый день, в среднем? Не отвлекаетесь постоянно на интернет, ютубчик, телеграмм, двач? Над чем лучше работается, когда делаете свой проект или когда учите что нибудь для своего проекта?
О себе: жутко ленился раньше, 2 курсы по юнити которые можно было закончить за пару недель-месяц, делал больше полугода, хотя раньше по андроду ебашил каждый день 3 часа глубокого курса, изменилось только то что раньше я жил сам, а сча с родителями. Подозреваю что они как-то подавляют мотивацию из-за чувства безопасности, мол, мамка рядом, если что, поможет и не парюсь, хотя страдаю от этого. Впал в депрессию из-за лени и почему-то боялся продолжать учиться. Сча начал инъекции тестостерона (не просто так, просто у меня проблемы с либидо, мне показано), начал снова ходить в зал и как-то снова вкатился, легче намного учить, дело идет вперёд.
Может какие-то препараты есть для бустинга мотивации? только без нарко жести, вроде спидов. Из того что я знаю: физ упражнения помогают собрать себя в руки и легче учиться.
У меня схожая ситуация, но я уже понял, что самое простое решение это жесткие дедлайны. Если просто учиться хочешь то выбирай любой джем на итче подходящий по срокам и ебаш. Либо сам себе ставь жесткие рамки, мол через 2 месяца релиз. Распиши четко что тебе надо сделать, архитектуру, требования, задачи. Короче главное- четкий дедлайн.
Когда входишь в режим разьеба, то время как будто ускоряется, только что сел за комп и уже вечер, а ты весь день просидел в юнити и что-то делал. Охуенное чувство. Когда дедлай близко так вообще режим берсеркера врубается, начинаешь невероятные вещи делать. Огонь в глазах главное поймать и всё будет.
> кто работает дома над своими проектами сам на себя, без кнута работодателя:
> Сколько по времени вы занимаетесь делом каждый день, в среднем?
Жутко ленюсь. Мотивации нет вообще. Памахити!
>Сколько по времени вы занимаетесь делом каждый день, в среднем?
Это всё крайне индивидуально. К каждому свой подход. Если сможешь организовать себе режим, то тебе будет гораздо легче. Разделяй отдых, спорт и разработку. У меня вообще всё через жопу было, но мне это не помешало, так как если ты реально увлечён разработкой, то она у тебя пойдёт в любом случае. А если ты будешь через силу этим заниматься, то скорее всего опустишь руки. Нужна серьёзная мотивация.
Я работаю в пятидневку, а потом дома 2-4 часа ебашу игры. Иногда засиживаюсь до часа ночи, не высыпаюсь, опаздываю на работу и чувствую себя как говно. Но ничего не могу с собой поделать, руки чешутся.
Что интересно, в праздники и выходные я с трудом заставляю себя хоть на часок засесть за проекты и чувствую при этом огромное внутреннее сопротивление.
> Нужна серьёзная мотивация.
Легко сказать. Все и так это понимают. Но что делать, если мотивация была в первый месяц, а потом резко пошла на спад?
Тогда мотивируй себя финансовой независимостью. Тебе не нужно будет ходить на работу, сможешь купить себе квартиру, денег будет хватать на всё. И для этого совсем не обязательно выпускать инди-хиты.
Есть очень много приемов для сохранения мотивации!
- Видь объем сделанной работы. Если не используешь VCS - используй. Заливай любое мало-мальски серьезное изменение коммитом и описывай его. Это не только упорядочит проект, обеспечит бекапы и упростит управление. Также ты будешь видеть десятки успешных изменений проекта прямо перед глазами и чувствовать удовлетворение от того, что все это сделал сам.
- Точно знай, что ждёт тебя впереди. Одна из самых частых причин прокрастинации - неопределенность поставленной задачи. Составь для игры roadmap, разбей на этапы: преальфа, альфа, бета, релиз. Для каждого этапа максимально подробно составь список необходимых фич. В процессе разработки иди по списку и отмечай сделанное. Помогает упорядочить проект, избавиться от говна в голове, трезво оценить объем работы, грамотно расставлять приоритеты. Всегда можно зайти, посмотреть и сказать себе: "ага, сейчас мне пора делать визуальный эффект для системы экспы. Вообще фигня, за три часа управлюсь".
- организация задач. Можно вести систему карточек типа трелло, хотя это несколько дублирует первые два пункта. Суть: для каждой задачи создаёшь карточку, крупные задачи разбиваешь на несколько карточек. Когда приступаешь к работе, смотришь список карточек,берешь понравившуюся и выполняешь, после чего кидаешь в архив и наслаждаешься ростом самомнения. Может показаться лишней работой, если работаешь в одиночку, но дробить задачи на небольшие составляющие очень важно, чтобы преодолеть нежелание начинать. Психологически проще брать на себя маленькую задачу, даже если она часть большой. А если в команде больше одного человека - карточки неописуемо удобны.
- награды. Дрессируй свой мозг. После каждой выполненной задачи награждай себя. Это может быть конфетой или газировкой. А лучшая награда - играбельный билд того, что ты закончил. Не пиши абстрактные механики в надежде собрать их вместе через два месяца, вставляй их в игру как можно раньше. Будешь наслаждаться результатом, упростишь отладку и сразу задетектишь несовместимые механики.
В общем, все советы - платина менеджмента. Они не сделают игру за тебя. Но это кирпичики, которые укрепят твою мотивацию удержат интерес к разработке.
А ещё поначалу ты будешь думать "чёт хуйней занимаюсь, время трачу". Но когда втянешься, то без этих ритуалов уже не сможешь.
Есть очень много приемов для сохранения мотивации!
- Видь объем сделанной работы. Если не используешь VCS - используй. Заливай любое мало-мальски серьезное изменение коммитом и описывай его. Это не только упорядочит проект, обеспечит бекапы и упростит управление. Также ты будешь видеть десятки успешных изменений проекта прямо перед глазами и чувствовать удовлетворение от того, что все это сделал сам.
- Точно знай, что ждёт тебя впереди. Одна из самых частых причин прокрастинации - неопределенность поставленной задачи. Составь для игры roadmap, разбей на этапы: преальфа, альфа, бета, релиз. Для каждого этапа максимально подробно составь список необходимых фич. В процессе разработки иди по списку и отмечай сделанное. Помогает упорядочить проект, избавиться от говна в голове, трезво оценить объем работы, грамотно расставлять приоритеты. Всегда можно зайти, посмотреть и сказать себе: "ага, сейчас мне пора делать визуальный эффект для системы экспы. Вообще фигня, за три часа управлюсь".
- организация задач. Можно вести систему карточек типа трелло, хотя это несколько дублирует первые два пункта. Суть: для каждой задачи создаёшь карточку, крупные задачи разбиваешь на несколько карточек. Когда приступаешь к работе, смотришь список карточек,берешь понравившуюся и выполняешь, после чего кидаешь в архив и наслаждаешься ростом самомнения. Может показаться лишней работой, если работаешь в одиночку, но дробить задачи на небольшие составляющие очень важно, чтобы преодолеть нежелание начинать. Психологически проще брать на себя маленькую задачу, даже если она часть большой. А если в команде больше одного человека - карточки неописуемо удобны.
- награды. Дрессируй свой мозг. После каждой выполненной задачи награждай себя. Это может быть конфетой или газировкой. А лучшая награда - играбельный билд того, что ты закончил. Не пиши абстрактные механики в надежде собрать их вместе через два месяца, вставляй их в игру как можно раньше. Будешь наслаждаться результатом, упростишь отладку и сразу задетектишь несовместимые механики.
В общем, все советы - платина менеджмента. Они не сделают игру за тебя. Но это кирпичики, которые укрепят твою мотивацию удержат интерес к разработке.
А ещё поначалу ты будешь думать "чёт хуйней занимаюсь, время трачу". Но когда втянешься, то без этих ритуалов уже не сможешь.
>>44057
Мозг не приучен к мотивации планированием. "Вот когда-нибудь в будущем..." - работает очень плохо, а "вот прямо сейчас" - хорошо. Нужен источник ежедневной мотивации, например, реализовывать крутые фичи и сразу вставлять их в игру. Но если разработка медленна, то очень тяжело черпать в ней вдохновение.
Прокрастинация это не лень, не путай. Когда нихуя не делаешь - это лень. А прокрастинация - это например когда на полном серьёзе кинулся делать свой аналог карточек трелло, потому что имеющиеся не устраивают.
Но ты же не сидишь и не пялишься в стену вместо работы. Ты все равно чем-то занят. Делаешь клон трелло, залипаешь в дотан или ютубчик при наличии актуальной задачи - все это суть прокрастинация.
>Разделяй отдых, спорт и разработку
Я РАБотаю 5/2, как мне что-то разделять?
Или увольняться нахуй и переезжать к вечно пилящим родителям, или положить болт на личную жизнь и себя. Я выбрал второе, а какие ещё варианты?
Именно так. Моя прокрастинация многослойна: вместо того, чтобы делать игры, я начинаю делать утилиты для деланья игр, но при этом вместо того, чтобы доделывать утилиты, я сижу на дваче, а под браузером торчит открытый проект.
Да, точно! Прокрастинировать - так по крупному. Подписаться на десяток тредов в психаче. Возможно завести свой и поддерживать. Ммм... Да! Лишь бы игры не делать.
Ещё вариант: работать с кем-нибудь в команде. Таким образом будете друг друга мотивировать. Допустим, художник сделает спрайт - замотивирует тебя. Ты заставишь двигаться спрайт - замотивируешь художники. А звуковик замотивируется от вас и выдаст крутой сонг. Это реально работает, но тяжело найти подходящих людей.
Достаточно начать позиционировать свои утилиты как продукт!
Делаешь утилиты для создания игры - продаешь утилиты - понимаешь, что игры делать уже не нужно.
Flickr - огрызок от мертворождённой ммо. Slack разрабатывался чисто как внутрикомандный инструмент при создании очередной дрочильни. Да что уж там, думаю, анрилы не знали будущее своего детища, когда делали движок чисто под себя.
Ужас, у меня всегда наоборот, одному легче учиться. Если вместе, кто-то будет учить и тянуть за уши другого. Зачем это, ненужно.
Прошел:
1) по юнити начальный https://www.udemy.com/course/the-ultimate-guide-to-game-development-with-unity/
2) по юнити начальный https://learn.unity.com/course/create-with-code
3) по юнити 2д https://learn.unity.com/project/ruby-s-2d-rpg
Cча прохожу по блендеру 2.8, но это по быстрому, не углубленно: https://www.youtube.com/playlist?list=PLjEaoINr3zgEq0u2MzVgAaHEBt--xLB6U
Думаю что по блендеру дальше пройти..
Какое обучение, наркоман? Речь о прогрессе. Если ты ноль, то конечно ни о какой команде речи идти не может.
социопат, свали
Бля, извини, я не посмотрел на какой ты пост ответил, думал ты ответил на пост >>44116 , где я спрашивал советы за курсы обучения. Извините, простите и никуда не уходите.
Теперь по делу:
Обычно комманды как раз формируются на идее, не? Если уже в процессе, то это больше похоже будет на то что творец идеи берет кого-то на работу с хорошими условиями и большой властью. Но хз, вообще ты прав. Мне просто чел предлагал в универе учиться вместе делать игры и я сразу насторожился, лучше одному просто, жаль сразу ему все не сказал, может он бы сам начал учить это, хотя у каждого свой путь, сча он работает в компании что занимается разработкой комп. архитектур, делает всякие чипы для устройств и тд и наверное зарабатывает уже много.
>Обычно комманды как раз формируются на идее, не? Если уже в процессе, то это больше похоже будет на то что творец идеи берет кого-то на работу с хорошими условиями и большой властью
Думаю, это во многом зависит от того, кто берёт, и того, кого берут. Если команда сформирована на энтузиазме без оплаты, то в ней по умолчанию все равны.
Если у "чужого" человека хватает наглости перелопачивать игру на ходу, а у автора хватает гибкости соглашаться на годные идеи несмотря на то, что игра отходит от его видения "игры мечты", то все в таких командах хорошо.
Я раз в неделю-две испытываю прилив отчаяния от того, что при разработке игры приходится заниматься вещами, не входящими в мою профессию, отчего выходит плохо и медленно. При взятии гипотетического единомышленника, скажем, дизайнера, я соглашусь с тем, что его опыт - это его опыт, и нехуй мне, программисту, лезть своими загребущими руками в его область. Пусть делает так, как видит сам.
У меня есть два канваса, две камеры. На левом у меня выделенная область - это под текст. Трабл таков, что когда я на правом ставлю кнопки в ту же область, они наотрез отказываются работать. Переключение между камерами осуществляется активацией/отключением нужной камеры. Вопрос, а какого вообще хуя, если это разные канвасы, они расположены в разных местах, и там разные камеры? Почему находящийся на левом обьект мешает взаимодействовать с обьектом на правом канвасе?
Разобрался, надо деактивировать обьект с первого канваса при переключении камер.
Привет, анон. Мне нужно сгенерировать на сцене определенное число кругов разного размера. Как расставить их так, чтобы они не пересекались?
Создаешь, если пересекаются удаляешь, опять создаваишь.
Отметь на пике хоть одну точку пересечения
Я могу дать формулу расстановки если тебе такая "сетка" нужна, можешь рандома сам добавить потом
Обязательно.
Ну есть плагины с нодами, есть уже какой-то встроенный визуал скриптинг, но я бы советовал сразу учить си шарп, потому что лучше ничего не придумают, больно только по началу (первые пол года). Веди документацию, записывай названия и решения, так гораздо легче
Нет, другой и не нужен, сисярпа топ, но любовь к нему приходит через анальную боль. Советую не тратить время на обходы и изъебы, если настроен делать игры учи сишарпу, это мощный инструмент. Лучше сразу перетерпеть. Я вот что только не юзал, и констракты и блюпринты, все хуйня, только время проебал.
Бери анриал тогда.
Вообще я тут нагуглил и везде сказали, что мне надо на ECS переходить. Что это новый передовой подход, особенно для ртсов, а старый гавно и для пидоров. Вы вообще его пробовали?
Просто в нем производительность выше, что важно для твоей игры, а так то и без ECS как то жили
2.79
https://www.youtube.com/watch?v=j111eKN8sJw
Или вот тут хороший туториал по прыжку, но чел разносит логику между Update и FixedUpdate.
Или пойдет любой хороший пример скрипта с управлением 2d персонажа, чтобы прям продакшн-реди, чтобы я посмотрел исходники.
С ECS легко ебануться, плюс система до сих пор в превью, что не очень хорошо. Если у тебя не тысячи юнитов, не уверен в целесообразности перехода.
Через триггеры - стандартный подход. Динамичный радиус обзора легко прикручивается изменением радиуса триггера. Если настроить слои для триггеров, чтобы они не ловили всякий мусор из окружения, то будет вообще волшебно.
Или можно сделать менеджер юнитов, содержащий их список и по запросу возвращающий юнитов в заданном радиусе. Но тут думоть надо и десятки векторных операций скорее всего будут дороже одного OnTriggerEnter. Архитектура сложнее, сущности множиш.
>Например перемещают героя в Update, а не FixedUpdate.
Это нормально, поскольку инпут читается в апдейте. И рендеринг в апдейте. Я недавно перенес персонажа из FixedUpdate'а и охуел, насколько динамичней и отзывчивей он стал.
И разносить по разным апдейтам логику нормально, если по каким-то причинам тебе нужно более/менее детально моделировать физику.
Фреймонезависимая скорость достигается не только за счёт юза Fixedupdate, но и, например, через перемножение deltaTime.
Да, хак с умножением я заметил в другом туториале. Я попробую всё делать в Update, потому что до этого я пытался в апдейте только инпут фиксировать, а в fixed этот инпут использовать. Но это создаёт некоторые неудобства.
>потому что до этого я пытался в апдейте только инпут фиксировать, а в fixed этот инпут использовать
Так и делай. Например, в апдейте лови input.getAxis, в фиксед апдейте используй их.
Хм. Ладно.
В моем мухосранске двушку в центре за 3 ляма изи найти это с евроремонтом и прочим говном для выебонов, еще 3 ляма останется на всякую сраку.
Да я вот тоже погуглил, говорят что встроенный ECS в юнити еще пиздец сырой и половина фич с ним не работают, а остальные надо с нуля заново писать. Про триггеры спасибо, понял.
А какой патфайндинг лучше пихать, если тебе local avoidance нужен? Без него-то можно и самому написать а-стар обычный, но для ртса он нужен позарез; а на дефолтный навмеш из юнити все регулярно и жидко срут.
>на дефолтный навмеш из юнити все регулярно и жидко срут.
Чому? Джве проблемы, с которыми я сталкивался сам - нет поддержки разных типов агентов и отсутствие генерации навмеша в рантайме.
Это фиксится navmeshcomponents, которые валяются где-то в гитхабе и понемногу допиливаются полуофициальный командой юнити. В остальном я плюс-минус доволен.
>отсутствие генерации навмеша в рантайме
Задавался раньше этим вопросом и все таки навмеш в рантайме высрать удавалось, юзая NavMeshBuilder.BuildNavMeshData
Но. Чтобы получить этот навмеш нужно было высирать его в ассет, а все что связано с ассетами это UnityEditor онли.
Да я несколько раз читал что у него как раз с производительностью проблемсы. Но сейчас вот посмотрел сравнения с другими решениями (то есть с а-старом арона гранберга, других-то и не завезли) и судя по всему навмеш всё равно самый быстрый. У меня самого-то всё равно ума не хватит написать local avoidance алгоритм, так что выбор невелик, спасибо за советы анон.
Вернулся, спустя несколько лет, к одному проектику.
В тот период когда я над ним работал, у меня на ПК стояли две версии юнити - 5.3.5f1 (большинство того, что я делал, делалось в нём) и 2017.
Не долго думая я запустил проект в 5.3.5f1 и пошёл заваривать чай.
Вернулся и успел заметить как компилился какой-то скрипт.
Так вот, как понять в какой версии изначально был проект? Есть в файлах какие-то следы предыдущей версии? Конфликтов вроде не возникло, но как-то неприятно.
И из этого возникает второй вопрос - как в дальнейшем узнавать версию проекта, чтобы таких ситуаций не возникало?
Почему? Я правда его немного тыкал пока, но вроде недурно авойдит. В конце концов мне не нужен супер-точный расчёт тут, мне нужно чтобы сто юнитов не влезали все в одного как профессор Вагнер нахуй.
Я вот вообще очень хочу функцию, чтоб фразы частоиспользуемые типа Debug.Log(); вызывались одной кнопкой. Может быть там есть такое? Типа макросов?
Да это просто код автоматически вставляется. Например пишешь for жмешь два раза таб и вставляется шаблон лупа. Ну есть готовые, можно свои делать. Корутин не было я себе сделал, чтоб сразу старт писало все дела.
>>44595
>Debug.Log();
Проблема с ней, что она и так короткая, нет смысла под нее сниппет делать, проще в кейменеджере на хоткей повесить впечатывание
Вязкий аргумент номер один: это пиздец.
Страубструдель обезумел, сам не знает чего хочет, парадигмы меняются чаще, чем идеи новых революционных тем в юнити.
Из коробки нихуя не может, нужно обмазать сторонними либами всё тело.
Зато есть богатый выбор возможностей по стрельбе себе в ногу.
Есть. Плагин решарпер. Но он имеет только 30 дней триала, а дальше покупать или брать с торрентов.
Охуенный анализатор, заточенный более-менее под юнити, особенно с установленным соответствующим расширением. Не срет варнингами от якобы неиспользованных Update'ов или сериализованных полей. Довольно часто ловит null'ы и вообще всячески тебе намекает, когда ты начинаешь писать хуйню.
Ещё работа с VCS сделана в студии удобно. Запомнил буквально 3-4 кнопки - и можешь срать коммитами ежедневно. Про брейкпоинты и быструю навигацию "to declaration", "to usages" рассказывать, думаю, не нужно?
А вообще если проганье у тебя - основная профессия - а юнька - основной фреймворк, то посылай нахуй вижл студию и воруй покупай Rider. Это решарпер на спидах, IDE, заточенная под юньку, позволяющая охуенные интеграции. Очень удобно дебажить и хуячить тесты в студии я это не проверял, я уже не говорю про тысячи проверок, автозамен и шаблонов.
Я когда читал Страуса , мне показалось что у него проблема с головой, он хотел чипировать деньги! наверно у него не все дома
>воруй покупай Rider
Такой пойдет или он какой-то специально для юньки есть?
https://rutracker.org/forum/viewtopic.php?t=5730477
нет, только можешь вставлять кубы, сферы или там плейны. Можешь собрать минарет из кубов.
Плагины можно скачивать и ставить локально, если твоя грязная пиратская версия ругаться не будет - то отлично. Чтобы было хорошо - тебе нужен встроенный плагин Unity и скачиваемый плагин Heap Allocations Viewer.
В самом юнити тоже нужно качнуть package под райдер и выставить его как редактор по умолчанию.
Про for слышал да, про то, что самому такую логику можно делать это круто, я с Raider сижу, там вроде дополняет, но можно еще больше дополнений. Спасибо за инфу.
Слушай, это не ты случайно в прошлых тредах мне райдер посоветовал?
Я на триале 30 дней посидел, охуел от удобства, еще накатил по совету когнитивную и еще какую-то сложность плагинами, настроил всё окружение, миллион плагинов, но потом 30 дней кончились и пиздец, пришлось скачивать пиратку, пол дня ебался его крякать.
Но в общем да, охуенная штука, распечатал себе на стену хоткеи, иногда блин тянешься к мышке, а хотелось бы вообще всё делать с клавы, ех.
Тут не так много упоротых фанатов джетбрейнсов, лол.
>распечатал себе на стену хоткеи
Есть плагин key promoter, но мне он не сильно помог. Проще большинство клавиш под себя перелопатить.
using UnityEngine;
using System.Collections;
public class SmoothFollow2 : MonoBehaviour {
public Transform target;
public float distance = 3.0f;
public float height = 3.0f;
public float damping = 5.0f;
public bool smoothRotation = true;
public bool followBehind = true;
public float rotationDamping = 10.0f;
void Update () {
Vector3 wantedPosition;
if(followBehind)
wantedPosition = target.TransformPoint(0, height, -distance);
else
wantedPosition = target.TransformPoint(0, height, distance);
transform.position = Vector3.Lerp (transform.position, wantedPosition, Time.deltaTime damping);
if (smoothRotation) {
Quaternion wantedRotation = Quaternion.LookRotation(target.position - transform.position, target.up);
transform.rotation = Quaternion.Slerp (transform.rotation, wantedRotation, Time.deltaTime rotationDamping);
}
else transform.LookAt (target, target.up);
}
}
С этим скриптом машина будто движется рывками, как дёрганая анимация или просадка фпс.
ЧЯДНТ?
using UnityEngine;
using System.Collections;
public class SmoothFollow2 : MonoBehaviour {
public Transform target;
public float distance = 3.0f;
public float height = 3.0f;
public float damping = 5.0f;
public bool smoothRotation = true;
public bool followBehind = true;
public float rotationDamping = 10.0f;
void Update () {
Vector3 wantedPosition;
if(followBehind)
wantedPosition = target.TransformPoint(0, height, -distance);
else
wantedPosition = target.TransformPoint(0, height, distance);
transform.position = Vector3.Lerp (transform.position, wantedPosition, Time.deltaTime damping);
if (smoothRotation) {
Quaternion wantedRotation = Quaternion.LookRotation(target.position - transform.position, target.up);
transform.rotation = Quaternion.Slerp (transform.rotation, wantedRotation, Time.deltaTime rotationDamping);
}
else transform.LookAt (target, target.up);
}
}
С этим скриптом машина будто движется рывками, как дёрганая анимация или просадка фпс.
ЧЯДНТ?
Попробуй не в Update а в FixedUpdate запихать
>>44626
Короче все заработало без ошибок. В инструкции по кряку в адресе слеш стоит сбивающий с толку, даже не запустилось сначала, если его убрать все гуд. И ссылка на сервер устаревшая, в комментах написали новую.
В вижуал студии такая минимапа удобная, а в райдере какой-то плагин от васяна с 18 года не обновлявшийся, мелкий сильно, и в нем не подсвечивается ничего. Плагин для скролла средней кнопкой мыши годный, но не скроллит по горизонтали, пиздец неразрешимая задача. А так вроде годно.
>Хуй знает, у меня тоже самое. Вообще много всего подчеркивае
У меня уже перестало подчеркивать.
>>44672
>Это та, которая справа показывается? Никогда ей не пользовался.
Ну там удобно когда выделенное на карте отмечается если документ большой просто на карту тыкаешь и сразу переносит туда, очень удобно. И скролл колесиком во все стороны
>Ну там удобно когда выделенное на карте отмечается если документ большой просто на карту тыкаешь и сразу переносит туда, очень удобно.
Ну то же самое что и в райдере по умолчанию но там ползунок узкий, не попасть
Хм, а у меня нет в том меню настроек пункта "Unity"...
Ты просто установил Raider официальный или у тебя ломанный?
У меня ломанный 2018, и нет такого пункта :(
Проверь машину со статичной камерой. Если рывков нет - дело в рассинхронах между камерой и машиной. Попробуй LateUpdate.
У меня недавно похожая хуйня была, думал движение криво написал, а оказывается это камера мозг ебала, жесть.
>>44679
А нахуя такие сложности? Просто храни звуки в папке со звуками, выстави им только настройки нужные и всё.
https://habr.com/ru/post/437474/
Чекни в плагинах включенный Unity. Если нету - то теряется половина мотивации использования райдера, лол.
>>44668
Русский текст не нужен Райдер помимо прочего ищет очепятки в названиях, стрингах и комментах. Либо гугли русскоязычный словарь для него (ни разу не пользовался), либо через Alt+Enter отключай предупреждение на незнакомые слова. Либо вручную каждое слово ебаш в словарь.
Я в отображении настроил так, что хинты не подчеркиваются вообще, и все маловажные предупреждения отправил в раздел хинтов. Таким образом код не засирается ненужными подчеркиваниями, но при анализе кода Ctrl+I предупреждения все равно остаются, на всякий случай.
>>44672
>я половину всего не понимаю, что он хочет вообще, даже Debug.Log() подчеркивает
Так мышкой наводи, тултипа подскажет. Debug.Log - дорогая операция, как GetComponent или FindWithTag. Он рекомендует не юзать его в апдейтах.
> Либо гугли русскоязычный словарь для него (ни разу не пользовался), либо через Alt+Enter отключай
Он сам как-то починился, когда начал всю эту хрень фиксить. Еще везде неймспейсы объявляет, независимо от папок, я вообще не знаю нафиг это нужно, сломает мне проджект нахуй.
Так мне нужно их из ресурсов грузить. Например в xml-ке лежат разные виды оружия, у них прописаны звуки выстрела (путь к ним в папке ресурсов). Когда нужно выстрелить, он подгружает из ресурсов звук.
Я тоже в белой, например, на темной сильно глаза болят. У тебя и в браузере везде темная тема?
Дак а как правильно-то, блядь?
Выжигаю себе мелатонин яркими цветами, чтобы лучше работалось.
По ночам без света не работаю, иначе, наверное, привыкал бы к темной.
Иногда превьюшки беленькие, типа как с глобал илюминейшн.
А иногда серые, типа блендеровского шейдера solid.
От чего это зависит?
Это не критично если мне нужно подкорректировать его размер с 1 на, скажем, 1.2 ?
Или лучше всё-таки исправить в 3Д редакторе?
>Это что за лайфхаки такие, лол. И как, помогает?
На уровне плацебо.
Так-то у всякой дичи типа пикрелейтеда доказана эффективность, но до такого я ещё не дошёл. Лишь соблюдаю рекомендации: утром и днем побольше синего, вечером побольше желтого.
Ибо в сцене скейлятся вместе с родителем его компоненты и дети. Если ты поставишь персонажа со скейлом 1.2, а потом тебе нужен будет дочерний объект с глобальным скейлом 1, то локальный скейл придется ставить 0.833. Также по пизде пойдут дочерние расстояния, захочешь ты прикперить к персонажу, скажем, нимб на расстоянии 1, а на деле он будет висеть на 1,2. В целом правило работы в юнити - везде где можно юзать скейл 1, а остальное по нулям.
Внезапно, на rigidbody это тоже влияет, хотя я не знал:
https://docs.unity3d.com/Manual/class-Rigidbody.html
Вообще хуй знает, специфическая пробелема какая-то. Сделай предварительную загрузку нужных звуков при загрузке сцены, для этого лоадинг скрины и изобрели, лол.
Где можно найти нормальный пак с 3d моделями популярных персонажей? На рутрекере одна мебель
И что ты будешь с этими моделями делать?
Проще всего будет, наверное, качнуть один из официальных паков юнити с примерами игр. Там есть интересные и уже настроенные.
а почему сразу готовую игру не скачать?
> но не скроллит по горизонтали, пиздец неразрешимая задача
Какая же я сука, какая тварь. Так бы и мучился годами.
У плагина всего 2 492 скачек, дауны даже не подозревают как это удобно. К слову у вижуал студии такое же только корявее 77,623 installs
Кстати минимапу тоже починил, она оказывается начинает совпадать с полосками (error strip mark) когда в документе строчек 200 и больше. Просто пустых ставлю до двухсот и карта идеально работает, блять какой же я царь, сделал из райдероговна конфетку.
И он мне пишет:
All compiler errors have to be fixed before you can enter playmode!
UnityEditor.SceneView:ShowCompileErrorNotification() (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:2935)
Чего ? Такого пути и близко у меня на компе нет.
Версия 2018.4.17f1
Как вариант, юнити криво поставился. Если у тебя ошибок в твоих скриптах нет.
Возможно путь к юнити содержит кириллицу, вроде тоже может проблемы вызывать
Скрипт WheelEffects применяю к ГО, на которых навешаны wheel collider-ы.
В окошке скрипта назначены перфабы со скриптом SkidTrail.
Так вот, проблема в том, что следы не рисуются по центру коллайдера/колеса а разлетаются шире.
Скейл всюду на 1, если это важно.
В чём подвох?
https://pastebin.com/Bdk1eWfS
https://pastebin.com/NKhCkLBv
Тут само собой напрашивается унаследовать типы конечностей от абстрактного типа конечность и хранить в боди массив этого абстрактного типа. Но я везде читаю, что юнити не умеет сериализовать такие коллекции.
Дайте что ли советов мудрых? Может, я что неправильно понимаю?
Нельзя очистить консоль и потом запустить?
Открой скрипт, на который указывает ошибка. Посмотри что неправильно. Но скорее всего проблема в .net . Поставь все что можно, дотнет девелопер, дотнет 3 и 4. У меня такая хуйня на линуксах когда дотнет был криво поставлен была.
А тебе зачем их сериализовать, ты конкретные элементы массива хочешь в редакторе редактировать?
Именно так. Хочу запилить удобные редакторы для всех основных компонентов игры, чтобы потом просто разбрасывать их по сценкам, чуть корректируя циферки.
Тебе тогда надо кастомные инспекторы изучать и писать для твоих классов наверное
Есть ещё мощный плагин для инспектора, Один инспектор называется, поизучай его, может там можно их сериализовать
Понял, спасибо за наводку, анон! Похоже, именно это мне и нужно.
Стандартный костыль - написать AbstractBodyPart наследуемый от ScriptableObject'а. SO, по сути, единственный вариант из коробки, позволяющий создание класса как файла и последующее его перетаскивание в инспекторе. Дальше пишешь сколько угодно наследников и в любой комбинации перетаскиваешь их на персонажей.
Впрочем, в твоем случае можно сделать элегантнее, написав обычный класс с атрибутом Serializable и енумом BodyPartType {Head, Arm, ...}. Таким образом обычным листом можно объявить сколько угодно частей тела, каждой из которых потом выставить свой тип.
Но все зависит от содержимого твоих конечностей, можно заебашить крутую сменную логику через strategy или factory паттерн. Для каждой части тела пишешь логику, обертывая ее в интерфейс. А в части тела создаёшь единственную переменную этого интерфейса, в которую динамично льешь нужную логику. С сериализацией разных характеристик будет сложнее.
В инспекторе будет не так красиво выглядеть, зато не нужно засирать прожект бесконечными scriptableobject'ами.
Добавь в коде костыль в виде доп вектора смещения вот тут
m_SkidTrail.localPosition = -Vector3.up*m_WheelCollider.radius;
И настрой в инспекторе
Хз вроде самый простой варик
Спасибо.
Хроший фильм, провалился в прокате, хоть бы и ты провалился, пидар.
QualitySettings.vSyncCount = 0; // VSync must be disabled
Application.targetFrameRate = 60;
Они что ебанутые всинк отключать?
Или эта разница в скорости только в редакторе, а при билде не будет? Просто билдится по пол часа не потестишь. Как то стремно все, еще дельтатайм нужно ставить, но непонятно где, один раз из ста забудешь и пиздец
Перекатываюсь в юнити из <движокname>.
Подскажи, в какую версию с пикрелейтеда вкатываться, так чтобы потом не больно было?
2017 попроще, 2018 понавороченней, 2019 сыровата ещё на мой взгляд
Если начинаешь с нуля то я бы рекомендовал 2017 но другие могут со мной не согласиться
Для обучения - любой стейбл.
Для реальной разработки - любой ЛТС.
Для обкатки фич и запила туториалов по ним (а так же для фидбека юнитекам, если ты прям фанат-фанат) - самый свежий анстейбл.
Всю геймплейную логику вообще нужно в fixedupdate пихать, чтоб не зависело от фпс, по крайней мере движение или боевку
Почему ты написал "m_SkidTrail"? К чему эта m_.
Я вот начал читать "совершенный код", и там тоже эти m_ иногда встречаются. Они что-то обозначают?
Насколько я знаю то никак. Ну так в гугле писали вроде
Венгерская нотация. Это устаревшая херня со времен когда не было нормальных IDE, программисты на си ставили префиксы к переменным чтобы было легче читать код - в частности m_ от member для приватных полей. Но зачем сейчас так пишут мне не понятно.
Да, короче эта хуйня только в редакторе, в билде обрезается до 60. Ну вот вообще не понимаю нахуя так делать? Придется всегда теперь ставить ограничение для редактора
Ты уверен, что тебе нужны несколько тегов? Есть же божественные слои, плюс проверку CompareTag("Player") можно заменить на GetComponent<PlayerController>(), например. Если не херачишь проверки каждый апдейт.
Ну то есть можно сделать пустые скрипты с названиями как теги и вешать на объекты и это выгоднее?
Сделал цикл на миллион и на сто объектов в котором просто получаю с тегом объекты, или с компонентами. С тегом в 3 раза быстрее
Могли бы сделать галочку и возможность несколько тегов вставлять, я думал там в сто раз разница.
А зачем пустые? Тег тебе нужен для идентификации объекта, но его можно идентифицировать и без тега. Если объект интерактивен, то у него, вероятно, есть компонент интерактивного обьекта. Если объект сохраняемый, то у него прицеплен скрипт сохранения. Передвижной/статичный определяется через Rigidbody.isKinematic. Анимируемый через Animator.
Приведи пример объекта, которому необходимо хотя бы два-три тега и для чего они нужны.
>Тег тебе нужен для идентификации объекта, но его можно идентифицировать и без тега.
> НИНУЖНА, ВЕДЬ МОЖНА ИЗЪЕБНУТЬСИ!
Зачем тогда в юнити есть теги и слои, умник?
Множественные теги были бы, безусловно, полезными и удобными во многих ситуациях. Просто лично я считаю теги плохим решением в большинстве задач - сам использую только тег Player для триггеров, и то потому что мне лень изъебываться с качественной архитектурой.
Короче на моем тестовом говне FindGameObjectsWithTag 3.39с, а поиск по слоям 18.84 секунд
Стоит читать приклейд, чтоб понимать си шарп для юнити?
Если ты спрашиваешь, необходимо ли, то ответ - нет. Можно делать простое мобилкоговно в одиночку без особого умения программировать.
Если хочешь фундаментальных знаний по программированию, чтобы в дальнейшем расти как программист и делать крутые проекты соло или в командах - то безусловно. Не обязательно пикрелейтед.
Да и не только мобилко говно, весь гринлайт завален ассетфлипами
if (Input.GetKeyUp (KeyCode.W)) на протяжении N секунд, то...
?
Vector 3 lastPos;
void Check(){
Vector3 delta = gameobject2.position - lastPos;
lastPos = gameObject2.position;
gameobject1.SetActive(delta.magnitude >0);
}
Getkeyup ты не получишь на протяжении никак, оно мгновенное
чтобы получить getkey
запоминаешь время getkeydown, а на getkeyup сравниваешь с текущим, если больше n
Я хотел как-то так сделать, но ума не хватает:
float holdTime = СКОЛЬКО ВРЕМЕНИ ПРОШЛО С МОМЕНТА ОТЖАТИЯ КЛАВИШИ
void Update ()
{
if ((Input.GetKeyUp (KeyCode.W)) && (holdTime >= 5 секунд))
{происходит что-то}
}
>У тебя уже установлена, 2019.3.2f1
Ну я, как бы, с разбегу установил , а потом попробовал загрузить примеры, а они 2018-ю требуют. Вот и решил у анона уточнить.
>>45139
>>45140
>Для реальной разработки - любой ЛТС.
Ок. Спасибо. Почитал про LTS, пожалуй остановлюсь на 2018.4.17f1(LTS)
-----------
Еще ньюфажный вопрос. Как у юнити производительность на андроиде при использовании тайлмапов?
Суть в чем. Планирую делать 2Д-пиксельарт платформеро-квест (вроде недометроидвании). Основная платформа ПК, но хочу сделать версию и для андроида. В другом движке столкнулся с проблемой, что при использовании тайлмапов на андроиде, FPS сильно падает до 5...15, всяческими изъебствами можно поднять его раза в 2, что тоже не айс. Хочу честные 60FPS (при физике в 120), чтобы скроллинг был плавный и без рывков. Нормально ли у юнити с этим? Или мне следует похоронить идею делать билд под ведро?
float holdRate = 5000.0; // Период задержки в миллисекундах, означающий долгое нажатие
float holdTime = 0.0; // Сюда будет прилетать актуальное время задержки
bool isHolding = false; // Флаг удерживания клавиши
void Update()
{
if (Input.GetKeyDown(KeyCode.W)
{
isHolding = true;
holdTime = 0;
}
else
{
isHolding = false;
}
if (isHolding)
{
holdTime += DeltaTime; // Не помню как там у вас дельту извлекают.
}
if ((Input.GetKeyUp (KeyCode.W)) && (holdTime >= holdRate))
{происходит что-то}
}
C тайлмапами всё заебок!
> if ((Input.GetKeyUp (KeyCode.W)) && (holdTime >= holdRate))
> {происходит что-то}
> }
Разве киАп возвращает тру не только в момент отжатия клавиши?
А ещё можно так:
float holdRate = 5000.0; // Период задержки в миллисекундах, означающий долгое нажатие
float holdTime = 0.0; // Сюда будет прилетать актуальное время задержки
bool isHolding = false; // Флаг удерживания клавиши
void Update()
{
if (Input.GetKeyDown(KeyCode.W))
{
isHolding = true;
holdTime = 0;
}
else
{
isHolding = false;
}
if (isHolding)
{
holdTime += Time.deltaTime;
}
if (Input.GetKeyUp (KeyCode.W)
{
if (holdTime >= holdRate)
{//Обрабатываем длинное нажатие}
else
{//Обрабатываем короткое нажатие}
}
}
А ещё можно так:
float holdRate = 5000.0; // Период задержки в миллисекундах, означающий долгое нажатие
float holdTime = 0.0; // Сюда будет прилетать актуальное время задержки
bool isHolding = false; // Флаг удерживания клавиши
void Update()
{
if (Input.GetKeyDown(KeyCode.W))
{
isHolding = true;
holdTime = 0;
}
else
{
isHolding = false;
}
if (isHolding)
{
holdTime += Time.deltaTime;
}
if (Input.GetKeyUp (KeyCode.W)
{
if (holdTime >= holdRate)
{//Обрабатываем длинное нажатие}
else
{//Обрабатываем короткое нажатие}
}
}
Падажжи... блять... Время не будет накапливаться. Щас код переделаю.
float holdRate = 5000.0; // Период задержки в миллисекундах, означающий долгое нажатие
float holdTime = 0.0; // Сюда будет прилетать актуальное время задержки
bool isHolding = false; // Флаг удерживания клавиши
void Update()
{
isHolding = Input.GetKeyDown(KeyCode.W); // Здесь иф вообще не нужен, просто юзаем keyDown как флаг
if (isHolding) // Пока мы удерживаем клавишу, эта ветка работает и накапливает время удерживания
{
holdTime += Time.deltaTime;
}
if (Input.GetKeyUp (KeyCode.W) // Теперь обработаем keyUp
{
if (holdTime >= holdRate)
{//Обрабатываем длинное нажатие}
else
{//Обрабатываем короткое нажатие}
holdTime = 0; // Вот здесь обнуляем!
}
}
А, ну и флаг вообще не нужен. Можешь его из кода выпилить. Домашнее задание тебе))
Из первой части кода мы сможем отображать в интерфейсе прогрессбар с прогрессом удерживания клавиши, во второй части мы его скрываем там же, где обнуляется таймер.
Если планируется использовать удерживания нескольких кнопок вместе или раздельно, то придется завести таймер на каждую. То же самое по рейтам, если на каждую клавишу свой - заводим отдельный рейт.
Так в своём пасфайндере локал авойданса не будет и придётся его страшными костылями дописывать, а в навмешагенте он уже есть. А тут вычисление путей для навмешагентов будет в джобах, на всех ядрах будет работать, по идее быстрее должно быть. И чего ты на меня ругаешься? Я тебя не обзывал. Ты сам маня, а еще пидорас, хуй, говно и ебать.
Разобрался. Надо было использовать ClosestPoint.
>>45312 (Del)
Я же тебе два изображения сделал. Мне надо было переписывать скрипт, чтобы показать, что синяя нормаль идёт от второй платформы? Неужели итак не ясно?
>>45042
Вощем, держу в курсе. Один инспектор панацеей не оказался, маловато инфы именно по фичам, которые мне нужны. А так большая часть функционала мне вообще не нужна, я же сам себе злобный буратино эдиторы пишу. Извернулся пока так: у класса анатомия есть заранее заданный перечислением массив регионов тела, каждый регион содержит массив конечностей. Конечность содержит свой тип, массив дочерних конечностей (помню про лимит циклической сериализации, 7 у меня быть в принципе не должно, максимум 1-2) и массив характеристик. Каждая характеристика содержит свой тип и значение. В процессе выполнения это все правдами и неправдами приводится к необходимого типа перечислениям (ажно рефлексию задействовал, благо это только в эдиторе). По скринам думаю более понятно, каков на самом деле пиздец, и как было бы проще и понятнее, умей юнити сериализлвать полиморфизм.
Объясните, в чём именно я тупой.
Перенёс передвижение объекта через transform.Translate() из апдейта в фикседапдейт, но не сразу заметил, что непосредственное перемещение всё ещё использует deltaTime, а не fixedDeltaTime.
И при этом похоже вообще нет разницы. Пробовал двигать в апдейт или фиксед апдейте, используя разные делтаТайм в разных комбинациях - и объект всегда движется одинаково.
Даже делал два перемещения в противоположных направлениях в разных комбинациях апдейтов и объект просто висел на месте.
В редакторе фиксированные фпс для апдейта или что как куда?
>For reading the delta time it is recommended to use Time.deltaTime instead because it automatically returns the right delta time if you are inside a FixedUpdate function or Update function.
Ясно, тупой потому что сперва надо заглядывать в доки
>>45276-анон
>>45284
Короче написал вот такое:
public GameObject Car;
public GameObject Light;
Vector3 lastPos;
Vector3 currentPos;
void Awake()
{
lastPos = Car.transform.position;
}
void Update()
{
currentPos = Car.transform.position;
if (currentPos.x != lastPos.x)
{
Light.SetActive(true);
}
else if (currentPos.x == lastPos.x)
{
Light.SetActive(false);
}
lastPos = currentPos;
Есть проблема - во время движения фара не светит а мигает.
Что исправить?
>>45284
Короче написал вот такое:
public GameObject Car;
public GameObject Light;
Vector3 lastPos;
Vector3 currentPos;
void Awake()
{
lastPos = Car.transform.position;
}
void Update()
{
currentPos = Car.transform.position;
if (currentPos.x != lastPos.x)
{
Light.SetActive(true);
}
else if (currentPos.x == lastPos.x)
{
Light.SetActive(false);
}
lastPos = currentPos;
Есть проблема - во время движения фара не светит а мигает.
Что исправить?
>во время движения фара не светит а мигает.
Замени лампочку в фаре, проверь проводку и систему освещения, мб коротит где-то что-то или контакт просто плохой.
Выглядит круто, анон. Хоть и пиздецово реализовывать и настраивать все это будет.
Текстовый рогалик пилишь или как ты планируешь отображение динамичных частей тела?
Пиздец, я это сразу понимал. С такой реализацией у меня в принципе возможно голове приделать характеристику ноги, а на ноге могут быть головы, руки, ноги и все, что угодно.
Отображение пока не планирую, я просто графоний делать не умею. Выглядеть будет так: менюшка с фигурой телки, и на частях тела интерактивные элементы. На них наводишь, вываливается список мяса и модификаций этого региона.
У меня не получается сделать партикл систем на канвасе. Просто не видно эффектов.
Сталкивался кто с таким? Или вы просто создаете на UI элементе партикл систем и все работает без проблем?
Подозреваю что он у тебя заскейлился как-нибудь хуёво и его просто не видно оттого что он слишком маленький.
Не, он не показывается на UI элементах, типа вне UI панелек партиклы видно, а внутри они как-будто не рендерятся. Хотя они на леере UI находятся. Может быть надо что-то сделать с ними, чтобы они на рендер UI попали?
Вот я нашел сам себе ответ. Но это же хуйня какая-то. Камера отдельная, Што бля.
https://answers.unity.com/questions/1169898/hi-guys-i-need-some-help-with-gui.html?childToView=1169946#answer-1169946
adasd s df sd
Забавно. По изначальному описанию я представлял себе механику в духе DF, где мобу может зарандомиться сколько угодно щупалец, хвостов, голов, ядовитых желез и конечностей, не говоря уже о материале плоти и типах атак.
Долго размышляю над тем, как стабильно подружить процедурную генерацию мобов и их визуальное отображение. Пока в заметках одни костыли.
Представь - шутер с видом сверху, где ты проходишь арену за ареной в пару экранов размером. На арене десяток-два мобов. Редко разбросаны препятствия, через которые ни пройти, ни пострелять. Как сделать, чтобы мобы умели прятаться за ними?
Пока придумал два способа.
Способ 1.
- Разбивать арену на сетку.
- Запомнить координаты каждой ячейки.
- Когда моб принимает решение, кинуть 200 рейкастов от игрока в сторону каждой ячейки. Те ячейки, куда рейкаст дошёл - "опасные", те, где рейкаст прервался по пути - "безопасные".
- Моб выбирает ближайшую безопасную ячейку и идет туда.
Даже учитывая, что ячейки можно делать не слишком мелкими (арена 50х20 метров), что не каждый моб прячется и решение принимается не каждый апдейт и не каждую даже секунду, 200 рейкастов как-то дохуя. Полуметровые ячейки навскидку оптимальная точность потребуют уже 800 рейкастов. Можно делать расчеты безопасной сетки динамично без перерывов и размазать на разные апдейты, но все равно я не в восторге от бросков по десятку-два рейкастов каждый апдейт.
Способ 2.
- Хранить список всех препятствий в коллекции.
- Когда моб принимает решение, брать ближайшее препятствие к нему.
- Ставить точкой назначения область с противоположной от игрока стороны укрытия магическим образом определяя размеры препятствия чтобы сделать отступ от его центра? или через SamplePosition?.
Звучит как фигня с точки зрения производительности, но трекинг препятствий, их размеров, размеров безопасной области вокруг них... Очень много работы по настройке системы, в то время как первая будет работать из коробки. А тут большой круглый камень и маленькую длинную стену придется рассчитывать совершенно по разному.
Что думаете?
(Алсо это не будет считаться кражей, если движок не с нуля делал?)
> Что думаете?
Может лучше GOAP?
>>45414
Пять секунд в ютубе
https://www.youtube.com/watch?v=N-AVCWbA4OA&list=PLFkIehRqW5mlR3t34bs3nAELzZpVT0gb0
Алсо, у фунгуса есть лицензия. Читаешь - делаешь выводы для себя.
Няшечка покажи писечку!
хочу написать простейшую 2d игру типо шашек. Точнее уже написал на чистой java и потом переписывал под swift. сейчас хочу переписать все это под единую кодовую базу, + чтобы была возможность хоть какие-то эффекты/анимацию прикрутить и при этом держать 60fps (сейчас все рисуется в onDraw). Стоит ли юзать для этого unity? Не слишком ли он тяжел для простой игры? Легко ли нарисовать 2д гуй, можно ли по прежнему пользоваться старыми либами от ведра и ios ?
>Может лучше GOAP?
ГОАП - способ организации фсм, вопрос о организации одного из конечных действий. В контексте гоап это скорее реализация сенсора укрытий.
>>45410
Первый способ лучше, рейкасты нихуя не стоят, ручной работы меньше. Второй лучше если только у тебя будет какое то хитрое взаимодействие с конкретными укрытиями.
И первый способ хорошо сочетать с многими другими системами. Например, игрок кинул гранату или бочка загорелась, - и ты просто инвалидируешь дополнительные ячейки.
>И первый способ хорошо сочетать с многими другими системами.
Тоже об этом подумал. Наверное, буду допиливать в сторону более универсального и легковесного менеджера ячеек, если других гениальных идей не придет.
>где мобу может зарандомиться сколько угодно щупалец, хвостов, голов, ядовитых желез и конечностей, не говоря уже о материале плоти и типах атак
Тащемта, это есть в планах, но в отложенных. Пока я хочу полностью поставить на ноги хотя бы человеков и им подобных существ. Большой класс Person у меня отвечает за все, что может происходить с человекообразными существами. Они должны работать, разговаривать, обмениваться с игроком и с игровыми менеджерами, носить тряпки, давать задания, участвовать в случайных событиях, драться и ебаться.
В игровом мире будет четкое разделение на персон и не-персон (Creatures, позже допишу). Все, что носит компонент Person, должно уметь все вышеназванное. Но по первоначальной задумке я хотел реализовать сам класс Person как очень гибкий, чтобы персоной мог считаться даже не слишком похожий на человека организм.
Я в принципе отлично представлял себе все, что хочу реализовать, в рамках чистого шарпа. Но в юнити об неожиданный хуй споткнулся. Ну и поделом, тащемта. Не надо воображать до того, как начнешь постигать.
> Все, что носит компонент Person, должно уметь все вышеназванное. Но по первоначальной задумке я хотел реализовать сам класс Person как очень гибкий, чтобы персоной мог считаться даже не слишком похожий на человека организм.
Какая-то смесь из антипаттерна класс-бог и композиции. Зачем делать класс-бог, который может всё, если нужно наоборот делать отдельные компоненты (работать, разговаривать, обмениваться с игроком и с игровыми менеджерами, носить тряпки, давать задания, участвовать в случайных событиях, драться и ебаться) после чего навешивать их на персонажей, в том числе генератором.
Я бы добавил компонентам тэги и генератор бы накидывал компоненты пачками (исключая повторяющиеся). Например, генерируя человека, ему накидываются компоненты с тэгом person, потом еще с тэгами merchant, citizen, noble получаем персонажа, который обладает умениями разумной сущности, торговца, живущего в городе, благородного происхождения. Но список тэгов конечно же надо тщательно продумывать. Тут я с потолка взял.
Да, класс-бог, я это сразу себе так представлял. Я просто первый раз на юнити что-то делаю. Пока гуглил, создалось впечатление, что вызовы GetComponent лучше сокращать, дескать они съедают оптимизацию. А потом, когда начал планировать "логичную" архитектуру, я понял, что в принципе классы, которые исполльзуются в Person не используются больше нигде, так что зачем делать их компонентами и таскать с собой мусор от MonoBehaviour, если можно без этого?
>зачем делать их компонентами и таскать с собой мусор от MonoBehaviour, если можно без этого?
Это ты правильно. Наследоваться от monobehaviour там, где это не надо - типичная ошибка новичка в Юнити.
Как загнать в массив все тайлы? И как вообще получить ссылку на тайл по имени?
>у фунгуса есть лицензия. Читаешь - делаешь выводы для себя.
Какие выводы? Скажи так. Делаю игру на бесплатном движке с помощью бесплатных ассетов и продавать игру не получится?
В этом случае
1) Как фунгусы узнают что я их поделие юзаю?
2) У юнити какая-то планка в виде годового оборота за игру что-то около 100К баксов, возьму и куплю лучшуую версию, это будет копейками на тот момент.
Я до этого читал "Паттерны программирования", сейчас читаю "Совершенный код", и тут вот пишут:
Интерфейс должен представлять хорошую абстракцию, скрывающую детали реализации класса... Должен представлять собой группу методов, четко согласующихся друг с другом
И я блядь не понимаю, как это использовать в Unity. Много я делаю интерфейсов. Надо ли мне их делать. Нормально ли в одном классе наследовать два, три, четыре интерфейса. Как именно надо к классам делать интерфейсы.
Типа интерфейсы помогают избегать прямого наследования классов, типа как в скриптах мы пишем и потом в Эдиторе переносим
publuc TestScript testScript;
А с интерфейсом мы просто бы унаследовали его интерфейс? Или что, как, я не понимая, скажите, я один не понимаю? Мне реально кажется, что это очевидно, но я блядь не понимаю. И видео смотрел, и читал про ООП, что бля хуле так сложно.
Двачая этого. Почему нельзя делать игры скажем на Питоне?
Короче поясняю за интерфейсы и зачем они нужны. Представь что ты делаешь взрыв. Взрыв должен дамажить разные объекты. Как ты будешь это делать? Вариант 1 - сделать общий класс с параметром здоровье и функцией Нанестиурон(), и от него наследовать все другие классы. Так делают лохи. Пацаны пишут интерфейс ИДамажить с методом Нанестиурон() и вешают его на все классы где нужно дамажить.
Если коротко не надо тебе использовать интерфейсы. Такого рода асбтракции нужны для крупных проектов, где много когда и сложная архитектура и для разработчиков библиотек в вакууме. Проблемы без них бывают чисто технические
C# язык типизированный. Если метод Foo(Car car) принимает параметр типа Car значит только Car и ничего больше. Это не совсем правда. Правда в том, что можно передать и класс -- наследник Car. Это и называется полиморфизм или истинный полиморфизм (полиморфизм в ООП)
Получается, что разработчик библиотеки должен реализовать полезный алгоритм, например сортировки, каких-то объектов. А каких он не знает, т.к. будешь их ты писать ПОТОМ. Поэтому он пишет базовый абстрактный класс/интерфейс и работает с ним. Потом ты свой конкретный класс наследуешь от этого интерфейса и пихаешь в код библиотеки и всё
А в РФ этому не учат в большинстве университетов, я много лет преподавал онлайн, знаю о чём говорю
Когда ты пишешь в файле
class Car
{
string name;
}
Это называется class declaration объявление класса, аналог ты нарисовал чертёж машины. Память пока (ну почти) не выделена, всё хорошо
Когда ты где-то типа в Main обычного приложения или в Start юнити пишешь new Car() ты создаешь экземпляр класса, аналог создаешь на заводе машину по чертежку. Каждый вызов new выделяет память
Тоже самое работает и с полями fields класса (name у нашей Car). Если у тебя есть поле WeaponTemplate у твоих юнитов, то на каждого юнита будет создаваться своей экземпляр WeaponTemplate
Если у каждого юнита свои данные (значения) элементов WeaponTemplate, то так и надо. Если данных у всех одинаковые, то не клади в юнити WeaponTemplate
И вообще не парься о таком, пока ты слишком нихера не знаешь
Ну массив я знаю что такое, могу его создать, а как туда все спрайты из assets запихнуть?
Создаешь публичный массив как поле своего скрипт компонента наследуюшего MonoBehaviour
public Sprite[] sprites;
или приватный с атрибутом
[SerializeField]
private Sprite[] sprites;
В инспекторе появляется соотвствуеющее поле Sprites. Ставишь нужный размер массива как число и ручками тягаешь нужный спрайты из ассетов (например колоду карт)
А если их у меня 5000, то каждый спрайт нужно перетаскивать, а если я например 4-й варианты одного из 5000-го спрайта забуду туда перетащить? Можно их как нибудь через Find/Load туда циклом запихнуть?
Если их много можно через Find их циклом достать. Или положить в ресурсы и Resources.LoadAll взять. Сам же написал, чё ты хочешь-то блядь?
А вообще если их прямо 5000 то зачем их грузить все в один объект. Пусть каждый объект смотрит своё имя и через Find грузит только свой спрайт и ставит себе при инициализации
А если кто-то захочет сказать, что Find это дорого, то грузите ресурсами, создавайте фабрики, которые будут создавать геймобжекты
Но вообще вся эта оптимизация должна быть по требованию и в руках тех, кто понимает, что под капотом. Искать конкретные решения частных ситуаций, роняя кал по форумам это неадекат какой-то. Это я не про анонов выше, а потенциальным спорщикам за Find
Да я чёт тупил всё как ентот центр вытащить, вот докумекал - лучик.collider.bounds.center;
>>45515
А если мне нужно тайлы заменять (допустим на 1 тайл = 4 его варианта в зависимости от ситуаций), меняю так:
public TileBase Tile1;
public TileBase Tile2;
private Tilemap map;
...
map.SwapTile(Tile2, Tile1);
но нужно руками в инспекторе тащить каждый тайл что накладно т.к. их будет дохуя. Даже по одному ссылку на него получить не удалось, их вообще можно через find все в массив загнать и как конкретно это сделать?
а если я беру создаю класс GameResources и один его инстанс, и в нём лежит словарь всех WeaponTemplate-ов. У него есть метод GetWeapon, который принимает обычную строку, ищет по ней в словаре темплейт и возвращает его. А у юнитов записана просто строка-индекс оружия, и когда юниту нужны статы оружия, он каждый раз получает темплейт из инстанса GameResources и берёт из него статы. Так лучше получится или нет?
и вообще стоит ли об этом думать, если там только простые данные хранятся, строки и флоаты? Сколько они там памяти займут, копейки какие-нибудь. ХУЙ ЗНАЕТ!
>>45507
Ой, спасибо за ответ, чувствуется, что преподавал раньше, понятно объясняешь.
Можешь оценить, правильно ли я ООП понимаю- в отличии от компонентно-ориентированного программирования (упрощенная/устаревшая парадигма) в ООП мы используем абстракции реального мира для упрощения восприятия программного кода и взаимодействия с ним.
Мы можем сами создавать новые виды обьектов, которые являются абстракциями реального мира, например, машину. Делается это так:
private class Car
{
private Car car;
}
Пока что вроде правильно, да?
Но, допустим машину нужно заправлять. Сделаем другой класс GasStation и метод для заправки в нем:
private void SetCarFuel(Car car,int fuel)
{
car.GetCarFuel += fuel;
}
Вот. Как теперь всё это дело совместить? Для взаимодействия с этим всем же интерфейс должен помочь? Типа у нас все максимально приватное, а интерфейс обеспечивает связь. Но я нихуя не понимаю. Приватные поля и методы не получить, если не юзать прямое наследование, еще и сделав их пабликами. Это вообще возможно или я хуйню делаю?
Или интерфейс можно юзать только для обьектов типа
IClickable, IDamagebl, IKillable и всё в таком духе?
Если это так, то подскажи пожалуйста, если я использую в классе по 4-5 таких интерфейсов- это норм? А то мне всегда кажется, что я хуйню делаю, потому что у меня много интерфейсов собирается.
Вообще ладно, я хз как это понять, может быть надо пару конкретно специальных тестовых проектов написать, чтобы понять интерфейсы и как создавать связи между классами правильно :(
Вообще забей, что я здесь написал, хуйета какая-то.
Как говорят, в геймдеве главный враг программиста- перфекционизм. Делай как делается и там видно будет.
Но очень хочется понять, как делать интерфейсы, а то я себя отсталым чувствую
Я вот чего не пойму, если у тебя дохуя разных юнитов со своими тайлами (по 4 на каждый), то какая тебе разница руками в инспеторе их натаскать или путь прописывать для Find в методе Start?
Может ты просто не можешь ни Find-ом найти, ни руками таскануть? Так погугли примеры
>>45521
>>45523
В целом так получится, но почему бы тебе собственно один WeaponTemplate не хранить в самом юните? Т.е. есть у тебя этот склад теймплейтов в SceneController-е например. Вот есть у юнита оружие по умолчанию, он его в Start ищет в складе, и статы себе сохраняет. А если оружие изменилось, то снова ищет и снова меняет. Попробуй так сделать. По пути поймешь лучше задачу и разберёшься
>>45529
Воу-воу-воу, полегче. У тебя турбо каша в голове из отрывков модных книг про ООП для новичков
Компонентно ориенитрованное программирование не устарело. Это другой подход, отличающисяй от ООП и имеет свои плюсы. Такой подход как раз активно применяется в игровых движках (юнити). Как раз игровой объект юнити имеет нарор компонентов (скриптов, српайтов, трансформ и т.п.)
ООП это подход основной для языка C#. Если разбирать твой код
>private class Car
В сишарпе классы (не внутренние) не могут быть приватными это раз. Зачем тебе поле того же типа внутри класса это два? (так делают связанные списки в чистом Си, но я не думаю, что ты это хотел)
>>45530
>>45531
>>45533
Насчет интерфейсов. Я уже писал выше, что это. Если ты этого не понимаешь, значит тебе ещё рано это понимать. Ты ещё не понимаешь в принципе основы ООП. Потому что ты написал private void SetCarFuel(Car car,int fuel) тем самым выдав себя, что мыслишь ещё на уровне т.е. процедурного программирования
Оно исторически раньше появилось и легче людьми воспринимается. Посмотри мою лекцию по парадигмам программирования на этот счёт
https://www.youtube.com/watch?v=Jvn3TU8RE_U
>асбтракции нужны для крупных проектов, где много когда и сложная архитектура и для разработчиков библиотек в вакууме
Как соло разработчик, обладающий опытом нескольких лет стрельбы себе в ногу, авторитетно заявляю, что это заблуждение.
Абстракции и паттерны - единственное, что спасает проекты от превращения в спагетти. В одиночку поддерживать чистоту архитектуры ещё важней, чем в команде, поскольку тебе приходится самому создавать и модифицировать разные модули. Тебе нужно держать в голове не только их содержание, но, что важнее, и взаимодействия между ними.
Согласиться я могу с тем, что из-за специфики юньки интерфейсы здесь менее востребованы. Но если ты делаешь что-то сложнее кликера или матч3, то ты должен выжимать все, чтобы не получить нестабильный говнокод.
Пример из практики. Нужно сделать мобов. Чтобы не херачить их где попало, выношу их в отдельную assembly. В ходе долгих ковыряний у меня выходит 1(!) класс врага с модульными логикой и внешкой, из которых я могу собрать любого моба или даже главного героя, подключив логику игрока.
Все скрипты аккуратно рассортированы и имеют доступы через internal, таким образом мне не нужно ломать голову ни сейчас , ни через полгода, о том, как моя система персонажей общается с внешним миром. Все взаимодействия защищены внутри assembly.
Но внешнему миру нужно отдавать команды персонажам. Таким образом я делаю интерфейс ICharacter, несмотря на то что у него лишь один наследник с модификатором public, создавая таким образом точку входа в мою либу персонажей.
Теперь, какие бы костыли я ни нагородил в игре в будущем, я точно знаю, что система персонажей стабильна, не пересекается с другими модулями в тысяче мест и не приводит к неожиданным багам от того, что я добавил в комнату трёх собак вместо четырех кошек. Но при этом все равно имею ограниченное влияние на персонажей через ICharacter, могу иметь список мобов, телепортировать их, перемещать, удалять.
>выдав себя, что мыслишь ещё на уровне т.е. процедурного программирования
Да, так и есть, пытаюсь это исправить :(
>У тебя турбо каша в голове из отрывков модных книг про ООП для новичков
Вообще ни одной книжки по ООП не читал, походу надо почитать, мб встанет что-нибудь на место. Спасибо за советы, пойду разбираться.
Хуя ты мутишь, даже канал есть, я на тебя в ВК подписан, а ты оказывается еще и ютюбер, лол. Когда только всё успеваешь...
>от есть у юнита оружие по умолчанию, он его в Start ищет в складе, и статы себе сохраняет. А если оружие изменилось, то снова ищет и снова меняет.
Так я именно так сначала и сделал, просто меня побеспокоило, что так у каждого юнита сохраняется своя копия темплейта и лишняя память занимается (поскольку темплейт может быть один и тот же у многих юнитов). Но потом я подумал что это всё равно мизерное количество памяти и погоды не сделает.
Погоды действительно не сделает. Но если ты так хочешь, то в складе у тебя есть массив/словарь по строке
WeaponTemplate[] templates;
И тогда каждый юнит может находить нужный себе темплейт и сохранять у себя ссылку на теймплейт, т.е. у юнита будет поле
WeaponTemplate myTemplate;
Тогда копирования не будет (за исключением 4 байта на юнита на адрес ссылки)
>>45538
Удачного развития братиш, когда-то давно я думал, что программирование это слишком сложно и не для меня
>>45536
Чувак, пойми правильно, я это не тебе писал, а челу выше. Разным людям, разный подход, не нужны ему эти ньюнсы. То что ты говоришь для него уже сложный проект. И ты говоришь про абстракции, а вопрос про интерфейсы. Вот я кубы делаю (игра на прикрепленной гифке), без интернфейсов спокойно обхожусь, но с абстракциями минимальными
У меня был проект глобальной стратегии раньше https://xgm.guru/p/sqworld (см пик 2), всё очень абстрактно, минимум юнити, максимум кода. Почему я так делал? Потому что юнити плохо знал. Когда знаешь юнити и понимаешь компонентную систему лучше, наоборот перекладываешь всё что можешь на юнити и компоненты, без ООП
В этом и смысл игровых движков отчасти. Конечно это всё работает пока я делаю идни говно средней руки, для более крупных проектов свои требования
Еще и звучит книжка как страшно- Обьектно ориентированное мышление... Не зря говорят, что программисты мышастые чуваки, совсем по другому даже мир воспринимают... Конечно, такие книжки почитаешь, потом вообще поехавший будешь, классами обмазался и пошел делегатами и интерфейсами братишку кормить
Окей, вроде понял, спасибо друг анон.
> Какие выводы? Скажи так.
Блять, я про фунгус слышу второй раз в жизни и читать его лицензию за тебя нет желания. Сорян, бро! Но давай-ка сам.
Брофист, бро!
Ну смотри, лично я понимаю интерфейсы, как тэги. Вот есть у тебя некоторая музывальная библиотека на твоём харде. Есть треки спокойные, есть агрессивные, есть рок, есть металл, есть попса, есть ретро, есть живая музыка, есть электроника, и ещё куча тегов. На каждом треке может быть тобой или кем-то повешен один или несколько тэгов. Тэг означает, что в треке ЕСТЬ то, что написано в тэге.
И вот ты такой думаешь, хочу послушать спокойный рок, в поиске по тэгам ты пишешь "добавить в плейлист треки с тегами (рок, спокойные)".
Ровно то же самое и делают интерфейсы в кодинге. Интерфейс означает, что в классе, который изволил унаследоваться от интерфейса ЕСТЬ всё, что объявлено в интерфейсе. При этом, если в разных интерфейсах объявлена одинаковая функция "ТУПИТЬ()", она должна присутствовать в классе одна. Если функции с одинаковым именем и разными аргументами или возвратом, то разные языки относятся к этому по разному. Сишарп требует реализовать обе как перегрузки (?вроде).
После этого ты, имея интерфейсы IТупой, IУмный, IПрямоходящий, IЧетвероногий и классы Человек : IПрямоходящий, Собака : IЧетвероногий и ещё классы Вася : Человек, IТупой, Аристарх : Человек, IУмный, Тузик : Собака, IТупой сможешь создать массив тупых IТупой тупые = new IТупой() в который могут попасть как люди, так и собаки, важно что все в этом массиве будут тупые и будут реализовывать тупость.
IТупить, да, что ты несешь вообще, я хуею, сук, насмешил.
Я попытаюсь завтра на свежую голову понять, что ты написал, пока что я в ахуе жостком с твоих сравнений :D
Довай!
Забавная аналогия. Вполне себе точная.
https://www.youtube.com/watch?v=tywt9tOubEY
Игрок ходит как положено, анимации играются, но теперь возникает вопрос.
Как сделать контроллер анимаций для неуправляемого нпс?
Я могу двигать нпс, могу заскриптовать его движение, форсировать проигрыш нужных анимаций.
Но допустим он должен искать игрока и нападать на него - как задать ему всё то же самое, что и игроку в этом туториале, но без Input.GetAxis?
Чтобы скрипт сам определял, двигается объект или нет, в какую сторону повёрнут и в соответствии с этим играл нужные анимации? Мб нужно заменить инпуты чем-то другим, но не могу сообразить (rbody.velocity?).
Тарас, но ведь ИРЛ вы сдали Крым без всякой борьбы. Лучше бы ты в АТО пошёл.
Смотря как будешь двигать нас
Если через ригидбади то ригидбади.велосити, если через изменение координат то запоминает предыдущее значение и вычисляет дельту
Двигать нпс*
Так проблема не в тебе, а в масштабе игры. Придумывай мега-охуенную механику для очень простой игры. Или объединяйся в команды и ленитесь вместе
Потому что у тебя изначально сделано плохо. Анимации привязаны не к персонажу, а к инпуту. А нужно наоборот.
Самое простое - делаешь функцию движения персонажа public void Move(Vector3 direction). И всю логику зашиваешь в него. Без инпута.
Таким образом, для игрока ты делаешь скрипт InputReader, который читает инпут и вызывает передвижение персонажа через Move. А для мобов ты делаешь любую другую логику, которая будет производить вычисления и тоже вызывать передвижение персонажа.
Твоему персонажу можно будет подключить любую внешнюю логику и он будет работать корректно, потому что анимации и передвижение не связаны с логикой, а просто вызываются функцией.
Вот даже моя небольшая игра, из-за того, что я хочу её сделать сочной, требует больших затрат времени. Настройка света, звука, пост проца, анимаций, движения... много всего. А я один. Но да, в командах попроще, безусловно.
В юнити консоль можно открыть? я нубло просто, начал изучение с курса на курсере от MSU
Нельзя
Стрелять надо пулей, а не пустышкой.
В общем понял, что у меня это не взлетит с моим инструментарием. Под 2д он не сильно заточен, а что-то другое качать-изучать или тем паче велосипедить с нуля слишком долго, уже к нему привык.
Он не умеет двигать ригидбоди 2д, двигает только CharaterController, а если не находит - двигает трансформом, отсюда и мои траблы, что скрипту было пофигу на проверку rigidbody.velocity - ригидбоди просто не двигается.
Проще наверно делать микс 3д и 2д, что-то вроде ортографической камеры со спрайтовыми персонажами как в фф тактикс, только камеру зафиксировать. Мб схавает немного больше ресурсов, зато смогу в короткий срок прототип запилить без.
В эту консоль только сообщения выводятся, об ошибках, например. Тебе надо создать скрипт и добавить его как компонент на объект.
Какаята коммерческая платная параша с триалом. За 8К в год по подписке, то есть ты эту парашу в лучших традициях современности не приобретаешь, а арендуешь. Или ты предлагаешь воровать?
>Или ты предлагаешь воровать?
Естественно
>параша
Заставлять не буду, вообще зря быдлу годноту засветил
> эту парашу в лучших традициях современности не приобретаешь, а арендуешь
Почему-то это не написано прямо, но тебе дают бесплатную вечную лицензию купленной версии. Просто по истечении подписки обновлять ее не сможешь. Работает вроде при покупке на год.
>>45903 (Del)
Делать коммерческие игры на пиратском софте, такое себе.
И вообще ,какие плюсы за порталом кроме графена есть?
Я как вкатывальщик попробовал оба и выбрал урину т.к. блюпринты и обучающего материала на русском языке стало больше за год. Но моя цель мультиплеерный дуэльный шутат с примитивной графикой, и по моим расчётам реализовать его в урине проще.
Анрил для 2д не оче, зато там ежемесячно раздают оче годные крупные ассеты.
На шарпе начать пилить говноскрипты проще. Визуальное программирование и блюпринты будет говном в любом случае, если тебе нужна сколько-то хитрая логика.
Юнька очень дружелюбна к новичкам и имеет огромное коммьюнити, которое засрали вопросами на совершенно любой вкус - тяжело столкнуться с проблемой и не нагуглить решения. Но развивается она не в очень хорошем направлении. От года в год производительность редактора падает, некоторые фичи юзеры ждут годами, некоторые фичи выпускают и перестают поддерживать через год-два, некоторые попросту оставляют сырыми.
Остается надеяться, что они возьмут свои яйца в руки и сделают хорошо, так как движок-то классный. Для казуальщины в одно лицо, думаю, он по-прежнему самый лучший. Если же хочешь делать игру мечты три года - то анрил зайдет.
Если не планируешь делать ААА игру, бери юнити. Если планируешь - уеч соответственно. Но если выбрал уеч, блюпринты крайне не рекомендую, только потратишь время разбираясь в них. Лучше дрочи плюсы для уеча.
Понял,значит анриал лесом пока что
Об этом я в курсе, только если учесть что всё в 2д, его прицепить не получается - конфликтует с collider 2d, rigidbody 2d и этим всем.
Он заточен под триде по сути, а если начинаешь цеплять его для 2д, получаются странные вещи типа провалов сквозь спрайты, по моему ему пофиг на 2д коллайдеры, нужно компоненты для 3д цеплять чтобы всё работало. Поэтому и хочу теперь делать псевдо-2д в 3д пространстве, чтобы работал этот несчастный контроллер как положено.
> Лучше дрочи плюсы для уеча.
А хули там дрочить-та? Вместо точки в методах ::, вместо точки в ссылках ->. Всё, краткий курс си окончен. Диплом можешь в интернетах скачать.
>но тебе дают бесплатную вечную лицензию купленной версии
Да, тоже читал об этом, когда собирался покупать Райдер. Но надо целый год подписку оформлять. Не уверен, что надо обязательно прям покупать сразу на год, может быть можно и просто в течении года подписку продлевать.
Спасибо, проиграл.
Одна из запланированных фич - разные приемы в зависимости от положения атакующего и жертвы, Но сейчас первостатейная задача - игра по сетке. Дальше буду добавлять разнообразие приемов
Ты не мог бы выводить видео ОБС в другой формат? мп4 или мов. А то в браузере (ФФ в убунте) не воспроизводится, приходится скачивать и смотреть плеером. Заранее спасибо.
Не стоит. Начинаешь так - хочу подвинуть кубик, не знаю как, вбиваю в гугел - unity move object, читаешь, смотришь, записываешь, чтобы потом быстро вспомнить, когда опять понадобится.
Читал предпоследнее издание. Если ты ультра-новичок, то зайдет, иначе узнаешь мало нового. Мне не понравилось обилие воды.
>>46101
Неплохой способ быстро научиться тому, что тебе нужно, но это приводит к тому, что ты два года городишь костыли, а потом такой: "ебать, так можно было?" - открываешь уже давно встроенный в юнити велосипед. Книги (по идее) в этом помогают, давая краткий обзор сразу всего. Или как вариант смотреть рандомом все подряд курсы на ютубе.
Принято, в след раз будет мп4. Кстати, народ, кто хочет поучаствовать? скинов порисовать рофла ради. я скидываю образец, надо по немурисовать, примерно соблюдая те же края. И работать над где нить типа фотошопа, чтоб прозрачность сохранить. Потом запишу видос с теми скинами, которые нарисуете
Нам бы кто нарисовал. Моделеры и художники в жоском дефиците и почти сразу сливаются.
мимо девочка-волшебница из ААААААА-треда
Хоспаде, дякую за мп4!
Угарный прототип! Уж не собираешься ли ты покуситься на славу счастливых колёс?
весело
не, даж не близко. ЭТо будет ближе к Duck Game
Может Far clip plane низковат? попробую камере установить более серьезные значения на ее Z, near clip plane и far clip plane, чтобы проверить наверняка
> почему так?
Потому что, манюнь, когда лезешь в чужой код, будь готов принять на рот.
Ты ведь без исходников не можешь знать пайплайн работы/вычислений навмешагента, соответственно, затея с выемкой калькуляций в части расчета путей в отдельные потоки с высокой вероятностью была обречена на провал. Тут надо понимать, что НМА - это готовый инструмент, не надо лепить к стулу пятую ножку. Хочешь высокую производительность - пиши с нуля. Для большинства кудахтерных игрулек по графам через дейкстру можно решить большинство задач по пасфайдингу с учетом препятствий и т.д., вычисления там последовательнные, так что их легко на потоки распределять даже без джобов, т.к. не требуют юнити-апи как таковые.
инби4 мой мозг
https://pastebin.com/pd5xGPrW
> ну оно мб и исполняется, но сразу заменяется теми двумя ифами сверху
Да, на миллисекунду успевает сработать и мигнуть.
Но как сделать, чтоб нормально было?
Чтобы светило с заданным intensity пока нажата кнопка.
А когда отжата - возвращалось к первым двум условиям.
>А когда отжата - возвращалось к первым двум условиям.
Добавь тем условиям условие что клавиша не нажата
if (Input.GetKey(KeyCode.Space))
Точно что взять оттуда зверушек и автор не будет говниться? Если вспомните сайты, накидайте подобного.
Лол, че ты там решил то с редактором, у тебя стоит ; на строчке с if вот он и ругается
Тоже вспомнил, как из-за ; после if все нахуй работать перестало, а я дико не одуплял, какого хуя. Было как-то так:
if(...);
return true;
if(...) ...
Знатно я тогда вздристнул, когда понял, почему код после ретурна считался недостижимым.
Что-то вроде:
DayWeek D;
D = DayWeek.Sunday;
D++; // D = Monday
D += 2; // D = Wednesday
D += 10; // D = 13
Но после ++ результат число а не название
Как-нибудь так можешь попробовать:
DayOfWeek currentDay;
IEnumerable<int> dayNums = Enum.GetValues(typeof(DayOfWeek)).Cast<int>();
foreach (int dayNum in dayNums)
currentDay = (DayOfWeek)dayNum;
Даже вот так, если число надо:
DayOfWeek currentDay;
int currentDayInt;
IEnumerable<int> dayNums = Enum.GetValues(typeof(DayOfWeek)).Cast<int>();
foreach (int dayNum in dayNums)
{
currentDay = (DayOfWeek)dayNum;
currentDayInt = (int)currentDay;
}
Если у ГО куча скриптов навешана, тупо же для каждого делать строчку типа:
(hui.GetComponent("zalupa") as MonoBehaviour).enabled = false;
Я сейчас заметил что проблема видимо в другом - когда я запускаю сцену,
этот объект, который нужно заморозить, исчезает из окошка, куда он назначен.
Очевидно, не навешивать тысячи скриптов. Или сгруппировать их в дочерний объект и тупо отключить его.
Или написать что-то вроде:
foreach (var script in GetComponentsInChildren<MonoBehaviour>()) script.enabled = false;
Это может быть баг инспектора, у меня такое было пару лет назад. Надо чекать дебаггером или логами, что компонент действительно обнуляется.
Подскажи, а....
(если про идею - то хочу сделать мясную игру в аниме стиле - чтобы лоли потрошили врагов с морем крови
Новый гуй редактора выкатли ещё год назад нахуй. Лучше бы старый оставили, в новом окно иерархии попердолило, нам же пиздец, как нужны кнопки "СКРЫТЬ ОБЪЕКТЫ", но они, правда, не скрываются, пока ты не нажмёшь "СКРЫТЬ СКРЫТЫЕ ОБЪЕКТЫ", но они и тогда скроются только в окне сцены, не более. Мегапиздатая кнопка, примерно такая же пиздатая, как кнопка "ЗАПРЕТИТЬ ВЫБИРАТЬ ОБЪЕКТ".
Вообще я про юиэлементс, которые тоже уже год обещают. И уже таки выкатили, двач традиционно бесполезная хуйня.
https://youtu.be/t4tfgI1XvGs
Олсо заметил, что после перехода с семёрки на десятку юнька стала втрое больше RAM поглощать, пиздос.
> сделали физику, логику и анимации всех объектов работающими во всей сцене разом
> потом убрали, оставив их только в зоне видимости камеры
> Оптимизация
Если "заглушить мотор" машина не стартует вперёд пока не нажмёшь сначала "S" т.е. задний ход.
Это баг или фича? Как пофиксить?
Я думал это я напартачил, скачал официальный пак - там то же самое.
Спасибо
Спасибо, а как назначить разрешение постоянное, что онли 16:9 я хочу, а не любое из предложенных.
как ты вообще этот тред нашел
При попытке скомпилировать любой скрипт говорит что скрипт должен наследоваться от какой-то хуеты(от которой он уже наследуется при создании).
Это траблы семерки или есть какой-то способ подвыпрямить мои кривые рученьки?
по привычке нет, но тащемта похуй, названия суть стринги, можешь хоть одинаковые давать всем обжектам, ни на что это не влияет. а вот в геймейкере такое не прокатит.
А вот поворачивать только через трансформ
Это копия, сохраненная 26 мая 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.