Обосрался ты Оп, сслыку на прошлый тред кинул на тред для ньюфагов.
И что это за говно на 4 пике? Где ГРОФОН?
>Обосрался ты Оп
Похую, я торопивси >>631674 (OP)
Мотивирующий ролик, о том что народ занят делом, А не как я, долбоебизмом занимается
>Девчонка из ue4. Юньку ещё дет десять надо пилить, чтобы такую графику выдать.
Что несешь, пидар-сын шлюхи?
https://twitter.com/Yokohara_h/status/1222612651630444544?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1222612651630444544&ref_url=https%3A%2F%2F2ch.hk%2Fgd%2Fres%2F631674.html%23631674
Тогда еще ассет не купил, потом с волосами появилась.
Попробуй читать не жопой
>>641967
проще спросить что пытаешься сделать. без абстракции.
пытаешься таскать зеленый шарик за середной между двумя другими шариками? зеленый шарик летит только в сторону центра, или ещё и толкается им? нужен ли физон?
>>642157
всегда было интересно чем это мешает
>>642118
всегда можно сунуть кнопку в текст лол
В rb просто можно по всякому с физикой играть, делать скольжения, етц?
Как принято у нормальных пацанов?
>Мотивирующий ролик
Так вот, большую часть логики я прекрасно представляю себе на основе событий, но не нажатия на клавиши. Сколько ни гуглил, везде нажатия проверяются через Update, то есть каждый кадр спрашивают, не нажата ли клавиша. Потому хочу спросить, нельзя ли и нажатия на клавиши проверять вне Update, через события?
И вообще сильно ли роляют проверки нажатий в Update? Быть может, я гоняюсь за мизерным выигрышем по производительности, и все процы начиная с 386 нихуя не почувствуют от таких проверок? Мне просто очень страшно, что я сделаю неоптимизированное говно (хотя я в принципе не сделаю ничего цельного, это да).
а нахуй тебе это вообще надо ? твой персонаж будет нажимать кнопки всю игру ? или я че то не понимаю. Есть другие вещи которые сильнее влияют на оптимизацию и о которых надо заботиться сильнее. Я делал саундборды на юнити и вообще похуй на эти кнопки на любой мобилки нормально, нету проблем С ОПТИМИЗАЦИЕЙ
Ты на миллионе персонажей будешь интпут проверять что ли?
Да даже если и на миллионе, операция сравнения ничего не стоит.
И многую логику кроме как в апдейт пихать некуда, если только ты не будешь пользоваться вот той другой архитектурой
Разве что не стоит очень тяжелые вещи выполнять в апдейте каждый фрейм. Чекать хп персонажа на предмет сдыхания можно и раз 30 в секунду, а всякие статусы обновлять вообще 1-2 раза в секунду, а не 50-100
> да хоть че.
Могу пофантазировать с дивана.
Например, закладываешь в уровень несколько слоёв, выключаешь видимость всем неактивным слоям. Рисуешь шейдер с эффектом перехода при котором слой 1 плавно исчезает, а слой 2 плавно появляется. И всё, дальше в зависимости от игровой механики скармливаешь шейдеру два слоя 1 который надо скрыть, 2 который надо показать.
Типа если ты до 100000 зеленых не поднял на игре, то ничего не платишь, а если поднял, то покупаешь лицензию и все?
Da. https://store.unity.com/#plans-individual
???
Я просто бомж-студент без стипендий, у меня даже на доширак денег нет, жру что есть в общаге
ну или что-то подобное
Нет, я не делаю убийцу dark soul. я хочу сделать нечто большее - наследника Severance Blade of Darkness :)))))
Народ, я крч топдаун игрушку пилю спрайтовую в 2д, сейчас думаю над алгоритмом поиска пути. Сильно ли затратно будет каждый фикседапдейт посылать коротенькие сквозные рейкасты[ ] допустим в шесть сторон, или может стоит триггер повешать и чекать им коллизии на расстоянии от объекта, который ищет путь?
Нормально всё будет. Можешь хоть сотни этих лучей пускать. Вот тебе статейка по теме:
https://gamedevelopment.tutsplus.com/series/understanding-steering-behaviors--gamedev-12732
Ясно, спасибо.
Ламерский вопрос но всё же, у меня есть префаб со стандартным спрайтом (таких будет дофига), нужно по условию (время) менять ему спрайт. Насколько я понял стандартно это делается по убогому, нужно на скрипт повесить 100500 спрайтов в виде public и использовать что-то вроде:
GetComponent<SpriteRenderer>().sprite = sprite2;
Можно ли обойтись без этих перетаскиваний а сразу из скрипта их указывать?
Могу предложить два способа через ScriptableObject. Я использовал первый способ, но в следующем проекте использую второй наверное.
Значит, пишем ScriptableObject, который будет выступать контейнеров спрайтов. Из редактора он будет принимать массив ссылок на спрайты. Внутри будет хранить их в словаре по имени, чтобы ты мог удобно с ними работать. А в твоём префабе тебе нужно будет задать ссылку на один лишь инстантс этого ScriptableObject. Вот как примерно может выглядеть код:
https://pastebin.com/ipdykLQs
Второй способ развивает первый. Вместо того, чтобы задавать ссылки на списки каких-то объектов, мы используем синглтон, который будет представлять базу данных игры. Скины, оружие, портреты, всё что угодно. Внутри себя синглтон будет использовать списки из ScriptableObject и предоставлять тебе результат в скрипте.
Внутри префаба нужно будет написать типа:
GetComponent<SpriteRenderer>().sprite = Database.GetSkinSprite("skin_sprite_name");
Думаю ты идею понял короче.
Я так понял что блендер.
Нашел курс на юдеми, но его обновляют до 2.8 версии блендера. Что бы можно было поучить за это время? Прошел уже курс на юдеми по юнити и на сайте юнити пару курсов для новичков. Хочется что-то средней углубленности.
Больше же ничего не надо для норм гейдева, только знания по юнити и блендеру? Или может стоит пройти курс по рисованию в гимпе?
Что мне пояснять? В па висит тред, зайди до смотри, самым лучшим будет всегда очевидный самый дорогой ваком синтик за 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$ в год, вроде. Лучше обучиться крите или гимп (шо лучше для гемдев рисования, скажите плис). Так как надо выбрать чему обучаться.
>>643718
Я даже хуже хочу, чем тут, но может даже так-же. Лучше всего что-то логическое придумать... у меня еще проектов нет, просто хочу сперва обучиться всяким плюшкам, чтобы потом не переделывать.
гимп может почти во все что и фотошоп, для геймдева за голову, просто надо переучиться и многое не интуитивно. Как по мне, лучше сразу обучиться бесплатному оперсорсному. Хотя я и выбрал проприетарную юнити, но тока из-за бесплатности для низких заработков (до 100 000 баксов в год).
>>643723
А я говорил что хочу делать гта? Я говорил что у меня будет лучше всех, самый топовый графон и все самое-самое? Нет, я понимаю свои силы и сразу сказал что скорее всего буду делать 2.5Д дрочильню.
>>643726
пинус охуенный
>гимп может почти во все что и фотошоп
Нет не может.
>для геймдева за голову
Для дрысни за 100р\шт, говори правильно
>просто надо переучиться
Не просто
>и многое не интуитивно.
Не интуитивно. Как пользователь линуха (второй системой стоит) это тебе говорю
>Как по мне, лучше сразу обучиться бесплатному оперсорсному.
Зачем ?
Это ухудшит разработку и качество
> Хотя я и выбрал проприетарную юнити, но тока из-за бесплатности для низких заработков (до 100 000 баксов в год).
Типо пропиетарность это для пидарасов, но если в жопу ебать через пакетик то не считается, верно ?
>>643726
Двочую, так же подумал. Видимо совсем ньюфане голову вскружило.
>пинус охуенный
Только вот бесполезный дома, если у тебя задачи для пеки не уровня посидеть в интернетике\музыку послушать.
>я понимаю свои силы и сразу сказал что скорее всего буду делать 2.5Д дрочильню
Силы ты свои поймёшь, когда хотя бы один рабочий мини-проектик сделаешь с напизженных ассетов, баги отладишь, интерфейс там, все дела. Или хотя-бы попытаешься 3д модельку сделать анимированную.
>из каропки могут
Вопрос не в том что это могут макс или майя, а в том чтоб это умел сидящий перед монитором человек. Как сделать скелет, как настроить констрейны, как сделать удобный риг, как настроить для него инверсную кинематику, как расставлять и редактировать ключи, плюс сами принципы анимации - walk cycle и вот это вот все.
>збраш не нужен.
В любом случае хайполи где-то нужно делать, и намного удобнее скалптить в збраше чем моделить.
>Делается в два счёта штатными средствами макса\майки
Допустим у тебя есть хайполи модель, тебе нужно сделать лоуполи. В топогане ты рисуешь полигоны поверх имеющейся модели, в максе или майе ты просто заново моделишь из кубов. Можно и так, но первое быстрее. И нет, это далеко не в два счета.
По поводу нормалей - опять, смысл не в том чтоб это умела программа, а чтоб это умел пользователь. Чтоб он знал какой формы должна быть геометрия чтоб с нее нормально запекалось, как расположить кейдж, как разнести меши в пространстве чтоб запеклось только то что нужно, как сделать юв развертку именно под запекание. И опять - это далеко не в два счета.
>>643718
Не вводи людей в заблуждение, это стандартный пайплайн вообще для всего геймдева. Даже в дазодрочильнях про мамок идут примерно по такому же пути. Ну и Зельда как бы тоже ААА тайтл.
С помощью этого говна можно вытащить некоторые ресурсы
https://7daystodie.com/forums/showthread.php?22675-Unity-Assets-Bundle-Extractor
все можно. юнити дырявый.
есть бесплатный uTinyRipper - он полностью востанавливает весь проект для юнити редактора (но без кода)
код можно вытянуть через dnSpy и аналоги
Есть платный DevXUnityUnpackerTools - по идее в платной версии он должен востановить вообще все - даже IL2CPP
Допустим, делаю я гоночки онлайн, хочу сделать магазин с скинами, таблицу лидеров и мультиплеерный режим с созданием комнат и общей игрой. Не ммо, максимум создание комнат игровых
И вот тут я сильно путаюсь в доступных вариантах- Photon PUN, Playfab, сюда еще можно всякие Google Play прикрутить и еще наверное много разных сервисов, о которых я еще не знаю.
Анон, как в самом минималистичном варианте реализовывается простенький мультиплеер по сети? Чем Photon от Playfab отличается? Я так понял, их вместе можно использовать? Кто-нибудь вообще сталкивался с таким? Или всё это можно реализовать с помощью API Google Play? И как ко всему этому еще магазин со скинами прикрутить, он то какой системой крепится?
>Господа, а поясните за сетевую составляющую Unity игр на мобилки
>>487807 →
>>643893
Речь о нормальной двушке. То есть это должен быть центр, это должен быть хороший дом и так далее.
В таком случае, логичнее всего наверное запилить демку и уже с ней искать издателя, который поможет с деньгами и с поиском сотрудников для создания полноценной сетевой составляющей?
Если решил стать инди или даже с друзьями пилить что-то интересное, то это минимум пару лет сидеть дома и работать над своим проектом в надежде, что он вообще кому-то понравится.
С другой стороны можно уйти в студию на зарплату и работать в ней, но блин, смотрю вакансии, а там какие-то проекты дурацкие, то казуалки-клоны, то какие-то хардкорные нишевые РПГ, которые я не особо люблю и не разбираюсь в них.
Еще и если решил работать как инди, то это постоянное давление и саморефлексия по поводу того, что ты делаешь какую-то хуйню, сомневаешься в себе постоянно, думаешь о том, что сидишь на шее, а мог бы уже устроиться на работу и зарабатывать деньгу нормальную.
Думаю, может быть уже пора изучить весь оставшийся необходимый стак технологий и пиздовать работать в студию программистом, а то сидеть дома и пилить свои проекты это какой-то ад, каждый день просыпаешься и сидишь за компом, даже на улицу не выходишь толком. И всё ради того, чтобы через год или два найти издателя? Это действительно стоит того?
Как блядь сложно жить.
Да, я на нулевой стадии, всё верно, просто изучаю технологии и требования, которые нужны для онлайна, пытаюсь понять, насколько это будет сложно. Интересная же тема, приятно играть с друзьями, социальные взаимодействия и всё такое. Но чувствую что сложность возрастает в десятки раз, по сравнению с сингловыми проектами.
Инди же как раз и делает сейчас упор на сингл, те же разные платформеры и игры с историей интересной неплохо взлетают.
Эх.
>Блин, я так понимаю
Ты неверно понимаешь. Статью прочитай
https://habrahabr.ru/company/pixonic/blog/346374/
Тебе нет смысла делать мультиплеер с выделенными серверами, авторитарной логикой, античитами и т.п.. Это сложно, долго. И вряд ли ты окупишь такую разработку. С Photon PUN даже новичок может создать сетевую игру. Блять, даже создатель копателя смог добавить сеть в свою игру.
Наверное сперва стоит делать что-то небольшое, выпустить штук 5 такой фигни, посмотреть, изучить что заходит, сделать потом проект покруче или просто апдейтнуть полностью тот проект что выстрелил больше всех, добавив больше уровней, глубины, веселья.
И опыта наберёшься. А сразу лезть в что-то непонятное довольно опасно, но раз уже начал, то продолжай. Можно пару уровней сделать, типа ирли эксес, потом доделать.
Ага, план такой есть.
Сделал уже фигни, сейчас как раз занимаюсь апгрейдом.
Просто понимаю, что скилов уже нормально так накапливается, можно было бы и на работу попробовать устроиться.
С одной стороны стабильность и работа на дядю, с другой свобода и независимость. Но с этой свободой приходит и мучительная ответственность.
Все вокруг работают, деньги зашибают, а я сижу как сыч и программирую какую-то хуйню, которая еще и может никому не понравится, в надежде, что когда-нибудь её доделаю и смогу заработать хоть что-то. Но пока что не заработал почти ничего, кроме жопоболи, садящегося зрения и тревожного состояния.
Начинал так же - делал игрули с друзьями и в одиночку, которые никогда не выходили в свет. Накопил опыта и портфолио, которое потом показывал на собеседовании. Инди не взлетело по понятным причинам, поэтому выбор пал на работу в компании. Делаю не совсем то, что нравится, но скилл растет. Пилю по вечерам своё детище, чтобы творческие позывы находили выход. Коплю портфолио, которое потом можно будет показать другому дяде за бугром.
Продолжай оттачивать мастерство, желательно, на небольших проектах разных жанров. Новичкам долгострои очень тяжело даются, появляется много архитектурных проблем из-за которых разработка буксует и останавливается совсем. Показывай свои проекты близким, знакомым, это помогает поддерживать мотивацию. Если делать игры - твоя мечта, то иди к ней и страдай.
Устройся на работу сторожем сутки трое или охранником в пятёрочку или возьми удалёнку на 3 часа в день, короче найди РАБоту не сильно занимающую время, тогда не будешь сидеть на шее и будет время пилить игоря. Ну что вы как маленькие.
Разраб стардью валлей билетёром каким-то работал и игоря пилил в оставшееся время.
Я 5/2 херачу и всё равно что-то делать успеваю.
Блин, анон, я тоже думаю о таком варианте- накопить портфолио и показать дяде за бугром. Сколько, два-три года усердной работы и можно спокойно переезжать?
>Продолжай оттачивать мастерство на небольших проектах разных жанров
Хорошая мысль, я так и делаю, правда подгоняю жанры под стак технологий.
Сейчас вот как видишь мультиплеер захотел изучить, потом собираюсь в DOTS поковыряться, шейдеры подучить, Zenject и разработку под мобилки подтянуть. Пока я всё это изучаю может быть и проект свой соберется к релизу.
>Если делать игры - твоя мечта
К сожалению, я не из тех людей, у кого геймдев это настоящая мечта. Скорее, я просто выбрал этот путь как единственный, который соответствует моим жизненным принципам. Прозвучало как-то высокомерно и напыщенно, но думаю вы понимаете
>>643975
Да, ты всё верно говоришь, выход можно найти всегда. Ты молодец, что еще и время на проект свой находишь.
Я вот понимаю, что проблема у меня не столько даже с деньгами, сколько в самоидентификации, постоянные самокопания и какая-то неуверенность в том, что я делаю. Еще и хиккование это давит, сижу за компом целыми днями и кажется, что вся жизнь мимо проходит. Все гуляют, что-то делают, а я друзей не видел уже несколько недель.
Но вот сейчас пообщался с вами и стало полегче, спасибо большое.
Тут как повезет. Но везение это такое. Главное сделать кросиво, стильно, чтобы приятно было пользоваться, не забивать на анимации, самая главная часть. И тогда, если механика хоть немного будет привлекать, должно набрать лойсов/отзывов и чутку взлететь.
Я встречал чела в б, он что-то вроде 30 игр наделал в гугл плей, говорил что збс, капает со всего и нормас. Запомнилось что он сказал что похрен на негативные отзывы, если много хороших, а так, из-за него я и взялся за юнити.
Если не взлетит, делай еще, но уже что-то менее серьёзное. К тому же опыт реальный, портфолио, не зря проебываешь время. У меня прога в гугл плей не сразу набрала колво установок что сча, где-то год-полтора набирала популярности, хз как это работает, какие-то алгоритмы гугл. Так что не ожидай что сразу игра реализирует весь потенциал популярности. В первый месяцы может быть по 20-40 закачек в месяц.
Спасибо за поддержку, анончик, очень помогает.
>К тому же опыт реальный, портфолио, не зря проебываешь время
Да, точно, это ж ещё на портфолио всё работает, надо не забывать об этом.
Ладно, решить бы проблемы с тем, чтобы не сойти с ума в четырех стенах и было бы всё получше. Надо может быть гулять почаще. Но это уже такое, тараканы в голове.
>Сколько, два-три года усердной работы и можно спокойно переезжать?
Если под усердной работой ты понимаешь 8-12 часов работы каждый будний день без отговорок, то да. Но я тебе точно говорю, что это нереально.
Если, как я, и как большинство свободных людей, работать 3-6 часов с разовыми перерывами на подработки, то за год-полтора можно только выйти на уровень, когда тебя начинают серьезно воспринимать на собеседованиях. Ещё через год-два можно говорить: "да, я шарю", но крутым спецом называть себя ещё рано.
Чтобы сьебнуть за бугор чисто за счёт скилла, думаю, придется батрачить лет 5, чуть меньше, если работать в компании, чуть больше - если в свободном плавании.
На многое влияют твои амбиции. Если ты делаешь простые мобилки месяца за 4, то у тебя будет и портфолио, и минимальный доход. Если же ты собираешься за полгодика запилить игру мечты, то готовься, что ты убьешь на неё два года, психику и душу. И скорее всего она даже не выйдет.
В общем, работаю на юнити, по каким-то причинам в инспекторе не показываются некоторые методы. Иногда каждый первый идёт нахуй. Так же с массивами, если после объявления массива куда-нибудь его вставить, то в инспекторе посылают нахуй. Приходится объявлять сохранять, потом продолжать писать.
Это вообще нормально или это можно исправить? Я уже заебался на залупе перед этими методами стоять, чтобы они появились в инспекторе.
Если это поможет, то ПК у меня очень старый, если нужно скину характеристики
Заранее благодарю.
Сколько по времени вы занимаетесь делом каждый день, в среднем? Не отвлекаетесь постоянно на интернет, ютубчик, телеграмм, двач? Над чем лучше работается, когда делаете свой проект или когда учите что нибудь для своего проекта?
О себе: жутко ленился раньше, 2 курсы по юнити которые можно было закончить за пару недель-месяц, делал больше полугода, хотя раньше по андроду ебашил каждый день 3 часа глубокого курса, изменилось только то что раньше я жил сам, а сча с родителями. Подозреваю что они как-то подавляют мотивацию из-за чувства безопасности, мол, мамка рядом, если что, поможет и не парюсь, хотя страдаю от этого. Впал в депрессию из-за лени и почему-то боялся продолжать учиться. Сча начал инъекции тестостерона (не просто так, просто у меня проблемы с либидо, мне показано), начал снова ходить в зал и как-то снова вкатился, легче намного учить, дело идет вперёд.
Может какие-то препараты есть для бустинга мотивации? только без нарко жести, вроде спидов. Из того что я знаю: физ упражнения помогают собрать себя в руки и легче учиться.
У меня схожая ситуация, но я уже понял, что самое простое решение это жесткие дедлайны. Если просто учиться хочешь то выбирай любой джем на итче подходящий по срокам и ебаш. Либо сам себе ставь жесткие рамки, мол через 2 месяца релиз. Распиши четко что тебе надо сделать, архитектуру, требования, задачи. Короче главное- четкий дедлайн.
Когда входишь в режим разьеба, то время как будто ускоряется, только что сел за комп и уже вечер, а ты весь день просидел в юнити и что-то делал. Охуенное чувство. Когда дедлай близко так вообще режим берсеркера врубается, начинаешь невероятные вещи делать. Огонь в глазах главное поймать и всё будет.
>Сколько по времени вы занимаетесь делом каждый день, в среднем?
Это всё крайне индивидуально. К каждому свой подход. Если сможешь организовать себе режим, то тебе будет гораздо легче. Разделяй отдых, спорт и разработку. У меня вообще всё через жопу было, но мне это не помешало, так как если ты реально увлечён разработкой, то она у тебя пойдёт в любом случае. А если ты будешь через силу этим заниматься, то скорее всего опустишь руки. Нужна серьёзная мотивация.
Я работаю в пятидневку, а потом дома 2-4 часа ебашу игры. Иногда засиживаюсь до часа ночи, не высыпаюсь, опаздываю на работу и чувствую себя как говно. Но ничего не могу с собой поделать, руки чешутся.
Что интересно, в праздники и выходные я с трудом заставляю себя хоть на часок засесть за проекты и чувствую при этом огромное внутреннее сопротивление.
Есть очень много приемов для сохранения мотивации!
- Видь объем сделанной работы. Если не используешь VCS - используй. Заливай любое мало-мальски серьезное изменение коммитом и описывай его. Это не только упорядочит проект, обеспечит бекапы и упростит управление. Также ты будешь видеть десятки успешных изменений проекта прямо перед глазами и чувствовать удовлетворение от того, что все это сделал сам.
- Точно знай, что ждёт тебя впереди. Одна из самых частых причин прокрастинации - неопределенность поставленной задачи. Составь для игры roadmap, разбей на этапы: преальфа, альфа, бета, релиз. Для каждого этапа максимально подробно составь список необходимых фич. В процессе разработки иди по списку и отмечай сделанное. Помогает упорядочить проект, избавиться от говна в голове, трезво оценить объем работы, грамотно расставлять приоритеты. Всегда можно зайти, посмотреть и сказать себе: "ага, сейчас мне пора делать визуальный эффект для системы экспы. Вообще фигня, за три часа управлюсь".
- организация задач. Можно вести систему карточек типа трелло, хотя это несколько дублирует первые два пункта. Суть: для каждой задачи создаёшь карточку, крупные задачи разбиваешь на несколько карточек. Когда приступаешь к работе, смотришь список карточек,берешь понравившуюся и выполняешь, после чего кидаешь в архив и наслаждаешься ростом самомнения. Может показаться лишней работой, если работаешь в одиночку, но дробить задачи на небольшие составляющие очень важно, чтобы преодолеть нежелание начинать. Психологически проще брать на себя маленькую задачу, даже если она часть большой. А если в команде больше одного человека - карточки неописуемо удобны.
- награды. Дрессируй свой мозг. После каждой выполненной задачи награждай себя. Это может быть конфетой или газировкой. А лучшая награда - играбельный билд того, что ты закончил. Не пиши абстрактные механики в надежде собрать их вместе через два месяца, вставляй их в игру как можно раньше. Будешь наслаждаться результатом, упростишь отладку и сразу задетектишь несовместимые механики.
В общем, все советы - платина менеджмента. Они не сделают игру за тебя. Но это кирпичики, которые укрепят твою мотивацию удержат интерес к разработке.
А ещё поначалу ты будешь думать "чёт хуйней занимаюсь, время трачу". Но когда втянешься, то без этих ритуалов уже не сможешь.
>>644057
Мозг не приучен к мотивации планированием. "Вот когда-нибудь в будущем..." - работает очень плохо, а "вот прямо сейчас" - хорошо. Нужен источник ежедневной мотивации, например, реализовывать крутые фичи и сразу вставлять их в игру. Но если разработка медленна, то очень тяжело черпать в ней вдохновение.
Ещё вариант: работать с кем-нибудь в команде. Таким образом будете друг друга мотивировать. Допустим, художник сделает спрайт - замотивирует тебя. Ты заставишь двигаться спрайт - замотивируешь художники. А звуковик замотивируется от вас и выдаст крутой сонг. Это реально работает, но тяжело найти подходящих людей.
Достаточно начать позиционировать свои утилиты как продукт!
Делаешь утилиты для создания игры - продаешь утилиты - понимаешь, что игры делать уже не нужно.
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
Думаю что по блендеру дальше пройти..
Бля, извини, я не посмотрел на какой ты пост ответил, думал ты ответил на пост >>644116 , где я спрашивал советы за курсы обучения. Извините, простите и никуда не уходите.
Теперь по делу:
Обычно комманды как раз формируются на идее, не? Если уже в процессе, то это больше похоже будет на то что творец идеи берет кого-то на работу с хорошими условиями и большой властью. Но хз, вообще ты прав. Мне просто чел предлагал в универе учиться вместе делать игры и я сразу насторожился, лучше одному просто, жаль сразу ему все не сказал, может он бы сам начал учить это, хотя у каждого свой путь, сча он работает в компании что занимается разработкой комп. архитектур, делает всякие чипы для устройств и тд и наверное зарабатывает уже много.
>Обычно комманды как раз формируются на идее, не? Если уже в процессе, то это больше похоже будет на то что творец идеи берет кого-то на работу с хорошими условиями и большой властью
Думаю, это во многом зависит от того, кто берёт, и того, кого берут. Если команда сформирована на энтузиазме без оплаты, то в ней по умолчанию все равны.
Если у "чужого" человека хватает наглости перелопачивать игру на ходу, а у автора хватает гибкости соглашаться на годные идеи несмотря на то, что игра отходит от его видения "игры мечты", то все в таких командах хорошо.
Я раз в неделю-две испытываю прилив отчаяния от того, что при разработке игры приходится заниматься вещами, не входящими в мою профессию, отчего выходит плохо и медленно. При взятии гипотетического единомышленника, скажем, дизайнера, я соглашусь с тем, что его опыт - это его опыт, и нехуй мне, программисту, лезть своими загребущими руками в его область. Пусть делает так, как видит сам.
У меня есть два канваса, две камеры. На левом у меня выделенная область - это под текст. Трабл таков, что когда я на правом ставлю кнопки в ту же область, они наотрез отказываются работать. Переключение между камерами осуществляется активацией/отключением нужной камеры. Вопрос, а какого вообще хуя, если это разные канвасы, они расположены в разных местах, и там разные камеры? Почему находящийся на левом обьект мешает взаимодействовать с обьектом на правом канвасе?
Привет, анон. Мне нужно сгенерировать на сцене определенное число кругов разного размера. Как расставить их так, чтобы они не пересекались?
Ну есть плагины с нодами, есть уже какой-то встроенный визуал скриптинг, но я бы советовал сразу учить си шарп, потому что лучше ничего не придумают, больно только по началу (первые пол года). Веди документацию, записывай названия и решения, так гораздо легче
Нет, другой и не нужен, сисярпа топ, но любовь к нему приходит через анальную боль. Советую не тратить время на обходы и изъебы, если настроен делать игры учи сишарпу, это мощный инструмент. Лучше сразу перетерпеть. Я вот что только не юзал, и констракты и блюпринты, все хуйня, только время проебал.
Вообще я тут нагуглил и везде сказали, что мне надо на ECS переходить. Что это новый передовой подход, особенно для ртсов, а старый гавно и для пидоров. Вы вообще его пробовали?
https://www.youtube.com/watch?v=j111eKN8sJw
Или вот тут хороший туториал по прыжку, но чел разносит логику между Update и FixedUpdate.
Или пойдет любой хороший пример скрипта с управлением 2d персонажа, чтобы прям продакшн-реди, чтобы я посмотрел исходники.
С ECS легко ебануться, плюс система до сих пор в превью, что не очень хорошо. Если у тебя не тысячи юнитов, не уверен в целесообразности перехода.
Через триггеры - стандартный подход. Динамичный радиус обзора легко прикручивается изменением радиуса триггера. Если настроить слои для триггеров, чтобы они не ловили всякий мусор из окружения, то будет вообще волшебно.
Или можно сделать менеджер юнитов, содержащий их список и по запросу возвращающий юнитов в заданном радиусе. Но тут думоть надо и десятки векторных операций скорее всего будут дороже одного OnTriggerEnter. Архитектура сложнее, сущности множиш.
>Например перемещают героя в Update, а не FixedUpdate.
Это нормально, поскольку инпут читается в апдейте. И рендеринг в апдейте. Я недавно перенес персонажа из FixedUpdate'а и охуел, насколько динамичней и отзывчивей он стал.
И разносить по разным апдейтам логику нормально, если по каким-то причинам тебе нужно более/менее детально моделировать физику.
Фреймонезависимая скорость достигается не только за счёт юза Fixedupdate, но и, например, через перемножение deltaTime.
Да я вот тоже погуглил, говорят что встроенный ECS в юнити еще пиздец сырой и половина фич с ним не работают, а остальные надо с нуля заново писать. Про триггеры спасибо, понял.
А какой патфайндинг лучше пихать, если тебе local avoidance нужен? Без него-то можно и самому написать а-стар обычный, но для ртса он нужен позарез; а на дефолтный навмеш из юнити все регулярно и жидко срут.
>на дефолтный навмеш из юнити все регулярно и жидко срут.
Чому? Джве проблемы, с которыми я сталкивался сам - нет поддержки разных типов агентов и отсутствие генерации навмеша в рантайме.
Это фиксится navmeshcomponents, которые валяются где-то в гитхабе и понемногу допиливаются полуофициальный командой юнити. В остальном я плюс-минус доволен.
>отсутствие генерации навмеша в рантайме
Задавался раньше этим вопросом и все таки навмеш в рантайме высрать удавалось, юзая NavMeshBuilder.BuildNavMeshData
Но. Чтобы получить этот навмеш нужно было высирать его в ассет, а все что связано с ассетами это UnityEditor онли.
Да я несколько раз читал что у него как раз с производительностью проблемсы. Но сейчас вот посмотрел сравнения с другими решениями (то есть с а-старом арона гранберга, других-то и не завезли) и судя по всему навмеш всё равно самый быстрый. У меня самого-то всё равно ума не хватит написать local avoidance алгоритм, так что выбор невелик, спасибо за советы анон.
Вернулся, спустя несколько лет, к одному проектику.
В тот период когда я над ним работал, у меня на ПК стояли две версии юнити - 5.3.5f1 (большинство того, что я делал, делалось в нём) и 2017.
Не долго думая я запустил проект в 5.3.5f1 и пошёл заваривать чай.
Вернулся и успел заметить как компилился какой-то скрипт.
Так вот, как понять в какой версии изначально был проект? Есть в файлах какие-то следы предыдущей версии? Конфликтов вроде не возникло, но как-то неприятно.
И из этого возникает второй вопрос - как в дальнейшем узнавать версию проекта, чтобы таких ситуаций не возникало?
Да это просто код автоматически вставляется. Например пишешь for жмешь два раза таб и вставляется шаблон лупа. Ну есть готовые, можно свои делать. Корутин не было я себе сделал, чтоб сразу старт писало все дела.
>>644595
>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 под райдер и выставить его как редактор по умолчанию.
Слушай, это не ты случайно в прошлых тредах мне райдер посоветовал?
Я на триале 30 дней посидел, охуел от удобства, еще накатил по совету когнитивную и еще какую-то сложность плагинами, настроил всё окружение, миллион плагинов, но потом 30 дней кончились и пиздец, пришлось скачивать пиратку, пол дня ебался его крякать.
Но в общем да, охуенная штука, распечатал себе на стену хоткеи, иногда блин тянешься к мышке, а хотелось бы вообще всё делать с клавы, ех.
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);
}
}
С этим скриптом машина будто движется рывками, как дёрганая анимация или просадка фпс.
ЧЯДНТ?
>>644626
Короче все заработало без ошибок. В инструкции по кряку в адресе слеш стоит сбивающий с толку, даже не запустилось сначала, если его убрать все гуд. И ссылка на сервер устаревшая, в комментах написали новую.
В вижуал студии такая минимапа удобная, а в райдере какой-то плагин от васяна с 18 года не обновлявшийся, мелкий сильно, и в нем не подсвечивается ничего. Плагин для скролла средней кнопкой мыши годный, но не скроллит по горизонтали, пиздец неразрешимая задача. А так вроде годно.
>Хуй знает, у меня тоже самое. Вообще много всего подчеркивае
У меня уже перестало подчеркивать.
>>644672
>Это та, которая справа показывается? Никогда ей не пользовался.
Ну там удобно когда выделенное на карте отмечается если документ большой просто на карту тыкаешь и сразу переносит туда, очень удобно. И скролл колесиком во все стороны
У меня недавно похожая хуйня была, думал движение криво написал, а оказывается это камера мозг ебала, жесть.
>>644679
А нахуя такие сложности? Просто храни звуки в папке со звуками, выстави им только настройки нужные и всё.
https://habr.com/ru/post/437474/
Чекни в плагинах включенный Unity. Если нету - то теряется половина мотивации использования райдера, лол.
>>644668
Русский текст не нужен Райдер помимо прочего ищет очепятки в названиях, стрингах и комментах. Либо гугли русскоязычный словарь для него (ни разу не пользовался), либо через Alt+Enter отключай предупреждение на незнакомые слова. Либо вручную каждое слово ебаш в словарь.
Я в отображении настроил так, что хинты не подчеркиваются вообще, и все маловажные предупреждения отправил в раздел хинтов. Таким образом код не засирается ненужными подчеркиваниями, но при анализе кода Ctrl+I предупреждения все равно остаются, на всякий случай.
>>644672
>я половину всего не понимаю, что он хочет вообще, даже Debug.Log() подчеркивает
Так мышкой наводи, тултипа подскажет. Debug.Log - дорогая операция, как GetComponent или FindWithTag. Он рекомендует не юзать его в апдейтах.
> Либо гугли русскоязычный словарь для него (ни разу не пользовался), либо через Alt+Enter отключай
Он сам как-то починился, когда начал всю эту хрень фиксить. Еще везде неймспейсы объявляет, независимо от папок, я вообще не знаю нафиг это нужно, сломает мне проджект нахуй.
Это не критично если мне нужно подкорректировать его размер с 1 на, скажем, 1.2 ?
Или лучше всё-таки исправить в 3Д редакторе?
Ибо в сцене скейлятся вместе с родителем его компоненты и дети. Если ты поставишь персонажа со скейлом 1.2, а потом тебе нужен будет дочерний объект с глобальным скейлом 1, то локальный скейл придется ставить 0.833. Также по пизде пойдут дочерние расстояния, захочешь ты прикперить к персонажу, скажем, нимб на расстоянии 1, а на деле он будет висеть на 1,2. В целом правило работы в юнити - везде где можно юзать скейл 1, а остальное по нулям.
Внезапно, на rigidbody это тоже влияет, хотя я не знал:
https://docs.unity3d.com/Manual/class-Rigidbody.html
Где можно найти нормальный пак с 3d моделями популярных персонажей? На рутрекере одна мебель
Кстати минимапу тоже починил, она оказывается начинает совпадать с полосками (error strip mark) когда в документе строчек 200 и больше. Просто пустых ставлю до двухсот и карта идеально работает, блять какой же я царь, сделал из райдероговна конфетку.
>Какая же я сука, какая тварь.
>>644805
>блять какой же я царь
И он мне пишет:
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'ами.
QualitySettings.vSyncCount = 0; // VSync must be disabled
Application.targetFrameRate = 60;
Они что ебанутые всинк отключать?
Или эта разница в скорости только в редакторе, а при билде не будет? Просто билдится по пол часа не потестишь. Как то стремно все, еще дельтатайм нужно ставить, но непонятно где, один раз из ста забудешь и пиздец
Перекатываюсь в юнити из <движокname>.
Подскажи, в какую версию с пикрелейтеда вкатываться, так чтобы потом не больно было?
А зачем пустые? Тег тебе нужен для идентификации объекта, но его можно идентифицировать и без тега. Если объект интерактивен, то у него, вероятно, есть компонент интерактивного обьекта. Если объект сохраняемый, то у него прицеплен скрипт сохранения. Передвижной/статичный определяется через Rigidbody.isKinematic. Анимируемый через Animator.
Приведи пример объекта, которому необходимо хотя бы два-три тега и для чего они нужны.
Множественные теги были бы, безусловно, полезными и удобными во многих ситуациях. Просто лично я считаю теги плохим решением в большинстве задач - сам использую только тег Player для триггеров, и то потому что мне лень изъебываться с качественной архитектурой.
> с качественной архитектурой
Стоит читать приклейд, чтоб понимать си шарп для юнити?
Если ты спрашиваешь, необходимо ли, то ответ - нет. Можно делать простое мобилкоговно в одиночку без особого умения программировать.
Если хочешь фундаментальных знаний по программированию, чтобы в дальнейшем расти как программист и делать крутые проекты соло или в командах - то безусловно. Не обязательно пикрелейтед.
if (Input.GetKeyUp (KeyCode.W)) на протяжении N секунд, то...
?
>У тебя уже установлена, 2019.3.2f1
Ну я, как бы, с разбегу установил , а потом попробовал загрузить примеры, а они 2018-ю требуют. Вот и решил у анона уточнить.
>>645139
>>645140
>Для реальной разработки - любой ЛТС.
Ок. Спасибо. Почитал про 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))
{происходит что-то}
}
А ещё можно так:
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; // Вот здесь обнуляем!
}
}
Из первой части кода мы сможем отображать в интерфейсе прогрессбар с прогрессом удерживания клавиши, во второй части мы его скрываем там же, где обнуляется таймер.
Если планируется использовать удерживания нескольких кнопок вместе или раздельно, то придется завести таймер на каждую. То же самое по рейтам, если на каждую клавишу свой - заводим отдельный рейт.
Так в своём пасфайндере локал авойданса не будет и придётся его страшными костылями дописывать, а в навмешагенте он уже есть. А тут вычисление путей для навмешагентов будет в джобах, на всех ядрах будет работать, по идее быстрее должно быть. И чего ты на меня ругаешься? Я тебя не обзывал. Ты сам маня, а еще пидорас, хуй, говно и ебать.
>>645042
Вощем, держу в курсе. Один инспектор панацеей не оказался, маловато инфы именно по фичам, которые мне нужны. А так большая часть функционала мне вообще не нужна, я же сам себе злобный буратино эдиторы пишу. Извернулся пока так: у класса анатомия есть заранее заданный перечислением массив регионов тела, каждый регион содержит массив конечностей. Конечность содержит свой тип, массив дочерних конечностей (помню про лимит циклической сериализации, 7 у меня быть в принципе не должно, максимум 1-2) и массив характеристик. Каждая характеристика содержит свой тип и значение. В процессе выполнения это все правдами и неправдами приводится к необходимого типа перечислениям (ажно рефлексию задействовал, благо это только в эдиторе). По скринам думаю более понятно, каков на самом деле пиздец, и как было бы проще и понятнее, умей юнити сериализлвать полиморфизм.
Объясните, в чём именно я тупой.
Перенёс передвижение объекта через transform.Translate() из апдейта в фикседапдейт, но не сразу заметил, что непосредственное перемещение всё ещё использует deltaTime, а не fixedDeltaTime.
И при этом похоже вообще нет разницы. Пробовал двигать в апдейт или фиксед апдейте, используя разные делтаТайм в разных комбинациях - и объект всегда движется одинаково.
Даже делал два перемещения в противоположных направлениях в разных комбинациях апдейтов и объект просто висел на месте.
В редакторе фиксированные фпс для апдейта или что как куда?
>>645276-анон
>>645284
Короче написал вот такое:
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;
Есть проблема - во время движения фара не светит а мигает.
Что исправить?
Ёбаная макаба, вот код:
https://pastebin.com/6dja2VaP
Пиздец, я это сразу понимал. С такой реализацией у меня в принципе возможно голове приделать характеристику ноги, а на ноге могут быть головы, руки, ноги и все, что угодно.
Отображение пока не планирую, я просто графоний делать не умею. Выглядеть будет так: менюшка с фигурой телки, и на частях тела интерактивные элементы. На них наводишь, вываливается список мяса и модификаций этого региона.
У меня не получается сделать партикл систем на канвасе. Просто не видно эффектов.
Сталкивался кто с таким? Или вы просто создаете на UI элементе партикл систем и все работает без проблем?
Вот я нашел сам себе ответ. Но это же хуйня какая-то. Камера отдельная, Што бля.
https://answers.unity.com/questions/1169898/hi-guys-i-need-some-help-with-gui.html?childToView=1169946#answer-1169946
Забавно. По изначальному описанию я представлял себе механику в духе DF, где мобу может зарандомиться сколько угодно щупалец, хвостов, голов, ядовитых желез и конечностей, не говоря уже о материале плоти и типах атак.
Долго размышляю над тем, как стабильно подружить процедурную генерацию мобов и их визуальное отображение. Пока в заметках одни костыли.
Представь - шутер с видом сверху, где ты проходишь арену за ареной в пару экранов размером. На арене десяток-два мобов. Редко разбросаны препятствия, через которые ни пройти, ни пострелять. Как сделать, чтобы мобы умели прятаться за ними?
Пока придумал два способа.
Способ 1.
- Разбивать арену на сетку.
- Запомнить координаты каждой ячейки.
- Когда моб принимает решение, кинуть 200 рейкастов от игрока в сторону каждой ячейки. Те ячейки, куда рейкаст дошёл - "опасные", те, где рейкаст прервался по пути - "безопасные".
- Моб выбирает ближайшую безопасную ячейку и идет туда.
Даже учитывая, что ячейки можно делать не слишком мелкими (арена 50х20 метров), что не каждый моб прячется и решение принимается не каждый апдейт и не каждую даже секунду, 200 рейкастов как-то дохуя. Полуметровые ячейки навскидку оптимальная точность потребуют уже 800 рейкастов. Можно делать расчеты безопасной сетки динамично без перерывов и размазать на разные апдейты, но все равно я не в восторге от бросков по десятку-два рейкастов каждый апдейт.
Способ 2.
- Хранить список всех препятствий в коллекции.
- Когда моб принимает решение, брать ближайшее препятствие к нему.
- Ставить точкой назначения область с противоположной от игрока стороны укрытия магическим образом определяя размеры препятствия чтобы сделать отступ от его центра? или через SamplePosition?.
Звучит как фигня с точки зрения производительности, но трекинг препятствий, их размеров, размеров безопасной области вокруг них... Очень много работы по настройке системы, в то время как первая будет работать из коробки. А тут большой круглый камень и маленькую длинную стену придется рассчитывать совершенно по разному.
Что думаете?
(Алсо это не будет считаться кражей, если движок не с нуля делал?)
> Что думаете?
Может лучше GOAP?
>>645414
Пять секунд в ютубе
https://www.youtube.com/watch?v=N-AVCWbA4OA&list=PLFkIehRqW5mlR3t34bs3nAELzZpVT0gb0
Алсо, у фунгуса есть лицензия. Читаешь - делаешь выводы для себя.
Няшечка покажи писечку!
хочу написать простейшую 2d игру типо шашек. Точнее уже написал на чистой java и потом переписывал под swift. сейчас хочу переписать все это под единую кодовую базу, + чтобы была возможность хоть какие-то эффекты/анимацию прикрутить и при этом держать 60fps (сейчас все рисуется в onDraw). Стоит ли юзать для этого unity? Не слишком ли он тяжел для простой игры? Легко ли нарисовать 2д гуй, можно ли по прежнему пользоваться старыми либами от ведра и ios ?
>Может лучше GOAP?
ГОАП - способ организации фсм, вопрос о организации одного из конечных действий. В контексте гоап это скорее реализация сенсора укрытий.
>>645410
Первый способ лучше, рейкасты нихуя не стоят, ручной работы меньше. Второй лучше если только у тебя будет какое то хитрое взаимодействие с конкретными укрытиями.
И первый способ хорошо сочетать с многими другими системами. Например, игрок кинул гранату или бочка загорелась, - и ты просто инвалидируешь дополнительные ячейки.
>где мобу может зарандомиться сколько угодно щупалец, хвостов, голов, ядовитых желез и конечностей, не говоря уже о материале плоти и типах атак
Тащемта, это есть в планах, но в отложенных. Пока я хочу полностью поставить на ноги хотя бы человеков и им подобных существ. Большой класс Person у меня отвечает за все, что может происходить с человекообразными существами. Они должны работать, разговаривать, обмениваться с игроком и с игровыми менеджерами, носить тряпки, давать задания, участвовать в случайных событиях, драться и ебаться.
В игровом мире будет четкое разделение на персон и не-персон (Creatures, позже допишу). Все, что носит компонент Person, должно уметь все вышеназванное. Но по первоначальной задумке я хотел реализовать сам класс Person как очень гибкий, чтобы персоной мог считаться даже не слишком похожий на человека организм.
Я в принципе отлично представлял себе все, что хочу реализовать, в рамках чистого шарпа. Но в юнити об неожиданный хуй споткнулся. Ну и поделом, тащемта. Не надо воображать до того, как начнешь постигать.
> Все, что носит компонент Person, должно уметь все вышеназванное. Но по первоначальной задумке я хотел реализовать сам класс Person как очень гибкий, чтобы персоной мог считаться даже не слишком похожий на человека организм.
Какая-то смесь из антипаттерна класс-бог и композиции. Зачем делать класс-бог, который может всё, если нужно наоборот делать отдельные компоненты (работать, разговаривать, обмениваться с игроком и с игровыми менеджерами, носить тряпки, давать задания, участвовать в случайных событиях, драться и ебаться) после чего навешивать их на персонажей, в том числе генератором.
Я бы добавил компонентам тэги и генератор бы накидывал компоненты пачками (исключая повторяющиеся). Например, генерируя человека, ему накидываются компоненты с тэгом person, потом еще с тэгами merchant, citizen, noble получаем персонажа, который обладает умениями разумной сущности, торговца, живущего в городе, благородного происхождения. Но список тэгов конечно же надо тщательно продумывать. Тут я с потолка взял.
Да, класс-бог, я это сразу себе так представлял. Я просто первый раз на юнити что-то делаю. Пока гуглил, создалось впечатление, что вызовы GetComponent лучше сокращать, дескать они съедают оптимизацию. А потом, когда начал планировать "логичную" архитектуру, я понял, что в принципе классы, которые исполльзуются в Person не используются больше нигде, так что зачем делать их компонентами и таскать с собой мусор от 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
И вообще не парься о таком, пока ты слишком нихера не знаешь
Создаешь публичный массив как поле своего скрипт компонента наследуюшего MonoBehaviour
public Sprite[] sprites;
или приватный с атрибутом
[SerializeField]
private Sprite[] sprites;
В инспекторе появляется соотвствуеющее поле Sprites. Ставишь нужный размер массива как число и ручками тягаешь нужный спрайты из ассетов (например колоду карт)
Если их много можно через Find их циклом достать. Или положить в ресурсы и Resources.LoadAll взять. Сам же написал, чё ты хочешь-то блядь?
А вообще если их прямо 5000 то зачем их грузить все в один объект. Пусть каждый объект смотрит своё имя и через Find грузит только свой спрайт и ставит себе при инициализации
А если кто-то захочет сказать, что Find это дорого, то грузите ресурсами, создавайте фабрики, которые будут создавать геймобжекты
Но вообще вся эта оптимизация должна быть по требованию и в руках тех, кто понимает, что под капотом. Искать конкретные решения частных ситуаций, роняя кал по форумам это неадекат какой-то. Это я не про анонов выше, а потенциальным спорщикам за Find
>>645515
А если мне нужно тайлы заменять (допустим на 1 тайл = 4 его варианта в зависимости от ситуаций), меняю так:
public TileBase Tile1;
public TileBase Tile2;
private Tilemap map;
...
map.SwapTile(Tile2, Tile1);
но нужно руками в инспекторе тащить каждый тайл что накладно т.к. их будет дохуя. Даже по одному ссылку на него получить не удалось, их вообще можно через find все в массив загнать и как конкретно это сделать?
а если я беру создаю класс GameResources и один его инстанс, и в нём лежит словарь всех WeaponTemplate-ов. У него есть метод GetWeapon, который принимает обычную строку, ищет по ней в словаре темплейт и возвращает его. А у юнитов записана просто строка-индекс оружия, и когда юниту нужны статы оружия, он каждый раз получает темплейт из инстанса GameResources и берёт из него статы. Так лучше получится или нет?
>>645507
Ой, спасибо за ответ, чувствуется, что преподавал раньше, понятно объясняешь.
Можешь оценить, правильно ли я ООП понимаю- в отличии от компонентно-ориентированного программирования (упрощенная/устаревшая парадигма) в ООП мы используем абстракции реального мира для упрощения восприятия программного кода и взаимодействия с ним.
Мы можем сами создавать новые виды обьектов, которые являются абстракциями реального мира, например, машину. Делается это так:
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-ом найти, ни руками таскануть? Так погугли примеры
>>645521
>>645523
В целом так получится, но почему бы тебе собственно один WeaponTemplate не хранить в самом юните? Т.е. есть у тебя этот склад теймплейтов в SceneController-е например. Вот есть у юнита оружие по умолчанию, он его в Start ищет в складе, и статы себе сохраняет. А если оружие изменилось, то снова ищет и снова меняет. Попробуй так сделать. По пути поймешь лучше задачу и разберёшься
>>645529
Воу-воу-воу, полегче. У тебя турбо каша в голове из отрывков модных книг про ООП для новичков
Компонентно ориенитрованное программирование не устарело. Это другой подход, отличающисяй от ООП и имеет свои плюсы. Такой подход как раз активно применяется в игровых движках (юнити). Как раз игровой объект юнити имеет нарор компонентов (скриптов, српайтов, трансформ и т.п.)
ООП это подход основной для языка C#. Если разбирать твой код
>private class Car
В сишарпе классы (не внутренние) не могут быть приватными это раз. Зачем тебе поле того же типа внутри класса это два? (так делают связанные списки в чистом Си, но я не думаю, что ты это хотел)
>>645530
>>645531
>>645533
Насчет интерфейсов. Я уже писал выше, что это. Если ты этого не понимаешь, значит тебе ещё рано это понимать. Ты ещё не понимаешь в принципе основы ООП. Потому что ты написал 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 байта на юнита на адрес ссылки)
>>645538
Удачного развития братиш, когда-то давно я думал, что программирование это слишком сложно и не для меня
>>645536
Чувак, пойми правильно, я это не тебе писал, а челу выше. Разным людям, разный подход, не нужны ему эти ньюнсы. То что ты говоришь для него уже сложный проект. И ты говоришь про абстракции, а вопрос про интерфейсы. Вот я кубы делаю (игра на прикрепленной гифке), без интернфейсов спокойно обхожусь, но с абстракциями минимальными
У меня был проект глобальной стратегии раньше 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. А для мобов ты делаешь любую другую логику, которая будет производить вычисления и тоже вызывать передвижение персонажа.
Твоему персонажу можно будет подключить любую внешнюю логику и он будет работать корректно, потому что анимации и передвижение не связаны с логикой, а просто вызываются функцией.
Как создать пустой префаб? Версия 2018.4, в гугле бан
В общем понял, что у меня это не взлетит с моим инструментарием. Под 2д он не сильно заточен, а что-то другое качать-изучать или тем паче велосипедить с нуля слишком долго, уже к нему привык.
Он не умеет двигать ригидбоди 2д, двигает только CharaterController, а если не находит - двигает трансформом, отсюда и мои траблы, что скрипту было пофигу на проверку rigidbody.velocity - ригидбоди просто не двигается.
Проще наверно делать микс 3д и 2д, что-то вроде ортографической камеры со спрайтовыми персонажами как в фф тактикс, только камеру зафиксировать. Мб схавает немного больше ресурсов, зато смогу в короткий срок прототип запилить без.
> эту парашу в лучших традициях современности не приобретаешь, а арендуешь
Почему-то это не написано прямо, но тебе дают бесплатную вечную лицензию купленной версии. Просто по истечении подписки обновлять ее не сможешь. Работает вроде при покупке на год.
>>645903
Делать коммерческие игры на пиратском софте, такое себе.
И вообще ,какие плюсы за порталом кроме графена есть?
Анрил для 2д не оче, зато там ежемесячно раздают оче годные крупные ассеты.
На шарпе начать пилить говноскрипты проще. Визуальное программирование и блюпринты будет говном в любом случае, если тебе нужна сколько-то хитрая логика.
Юнька очень дружелюбна к новичкам и имеет огромное коммьюнити, которое засрали вопросами на совершенно любой вкус - тяжело столкнуться с проблемой и не нагуглить решения. Но развивается она не в очень хорошем направлении. От года в год производительность редактора падает, некоторые фичи юзеры ждут годами, некоторые фичи выпускают и перестают поддерживать через год-два, некоторые попросту оставляют сырыми.
Остается надеяться, что они возьмут свои яйца в руки и сделают хорошо, так как движок-то классный. Для казуальщины в одно лицо, думаю, он по-прежнему самый лучший. Если же хочешь делать игру мечты три года - то анрил зайдет.
Об этом я в курсе, только если учесть что всё в 2д, его прицепить не получается - конфликтует с collider 2d, rigidbody 2d и этим всем.
Он заточен под триде по сути, а если начинаешь цеплять его для 2д, получаются странные вещи типа провалов сквозь спрайты, по моему ему пофиг на 2д коллайдеры, нужно компоненты для 3д цеплять чтобы всё работало. Поэтому и хочу теперь делать псевдо-2д в 3д пространстве, чтобы работал этот несчастный контроллер как положено.
>но тебе дают бесплатную вечную лицензию купленной версии
Да, тоже читал об этом, когда собирался покупать Райдер. Но надо целый год подписку оформлять. Не уверен, что надо обязательно прям покупать сразу на год, может быть можно и просто в течении года подписку продлевать.
Читал предпоследнее издание. Если ты ультра-новичок, то зайдет, иначе узнаешь мало нового. Мне не понравилось обилие воды.
>>646101
Неплохой способ быстро научиться тому, что тебе нужно, но это приводит к тому, что ты два года городишь костыли, а потом такой: "ебать, так можно было?" - открываешь уже давно встроенный в юнити велосипед. Книги (по идее) в этом помогают, давая краткий обзор сразу всего. Или как вариант смотреть рандомом все подряд курсы на ютубе.
Принято, в след раз будет мп4. Кстати, народ, кто хочет поучаствовать? скинов порисовать рофла ради. я скидываю образец, надо по немурисовать, примерно соблюдая те же края. И работать над где нить типа фотошопа, чтоб прозрачность сохранить. Потом запишу видос с теми скинами, которые нарисуете
> почему так?
Потому что, манюнь, когда лезешь в чужой код, будь готов принять на рот.
Ты ведь без исходников не можешь знать пайплайн работы/вычислений навмешагента, соответственно, затея с выемкой калькуляций в части расчета путей в отдельные потоки с высокой вероятностью была обречена на провал. Тут надо понимать, что НМА - это готовый инструмент, не надо лепить к стулу пятую ножку. Хочешь высокую производительность - пиши с нуля. Для большинства кудахтерных игрулек по графам через дейкстру можно решить большинство задач по пасфайдингу с учетом препятствий и т.д., вычисления там последовательнные, так что их легко на потоки распределять даже без джобов, т.к. не требуют юнити-апи как таковые.
инби4 мой мозг
https://pastebin.com/pd5xGPrW
да блять ну ты хоть объяснил бы что именно хочешь
Что-то вроде:
DayWeek D;
D = DayWeek.Sunday;
D++; // D = Monday
D += 2; // D = Wednesday
D += 10; // D = 13
Но после ++ результат число а не название
Если у ГО куча скриптов навешана, тупо же для каждого делать строчку типа:
(hui.GetComponent("zalupa") as MonoBehaviour).enabled = false;
https://pastebin.com/f7AP0f0C
Подскажи, а....
(если про идею - то хочу сделать мясную игру в аниме стиле - чтобы лоли потрошили врагов с морем крови
Новый гуй редактора выкатли ещё год назад нахуй. Лучше бы старый оставили, в новом окно иерархии попердолило, нам же пиздец, как нужны кнопки "СКРЫТЬ ОБЪЕКТЫ", но они, правда, не скрываются, пока ты не нажмёшь "СКРЫТЬ СКРЫТЫЕ ОБЪЕКТЫ", но они и тогда скроются только в окне сцены, не более. Мегапиздатая кнопка, примерно такая же пиздатая, как кнопка "ЗАПРЕТИТЬ ВЫБИРАТЬ ОБЪЕКТ".
Вообще я про юиэлементс, которые тоже уже год обещают. И уже таки выкатили, двач традиционно бесполезная хуйня.
https://youtu.be/t4tfgI1XvGs
Олсо заметил, что после перехода с семёрки на десятку юнька стала втрое больше RAM поглощать, пиздос.
Если "заглушить мотор" машина не стартует вперёд пока не нажмёшь сначала "S" т.е. задний ход.
Это баг или фича? Как пофиксить?
Я думал это я напартачил, скачал официальный пак - там то же самое.
При попытке скомпилировать любой скрипт говорит что скрипт должен наследоваться от какой-то хуеты(от которой он уже наследуется при создании).
Это траблы семерки или есть какой-то способ подвыпрямить мои кривые рученьки?