Давным-давно я пытался освоить такую штуку, как GameDev, и пробовал работать с Unity и другими подоб
Аноним
27/03/26 Птн 01:20:33
№
1
В итоге я пришёл к данному творению и понял, что для меня это самый оптимальный вариант, в котором есть всё для создания моих простых 2D-игр. И, типа, что ещё нужно для счастья? Всё понятно по малым гайдам из интернета для таких тупых, как я. Мол, зачем кому-то учиться, мучиться с кодом, если ты делаешь или пытаешься что-то сделать как простое, банальное хобби?
>Из-за своей тупости и так далее я утыкался в одну проблему под названием "код": слишком сложно для меня, как и программирование.
Чел сейчас можно тупо нейронке сказать написать код а она и напишет.
Ну некоторые малые познания в программировании у меня есть благодаря шараге и я понял что на одной нейронке далеко не уедешь без норм знаний. Она как по мне пишет бюрократичный код, мол если делать как профессионал то он будет проще + к оптимизации
Да и в принципе один хуй когда юзаешь нейронку для какой либо работы, нужно понимать базу
Ну я это ты, я потыкался был в 22 году в это дело когда еще сычиной был сельской безработной и понял что я в тех условиях не осилю, а денег чтобы нанять нормального кого-то чтобы мне разжевал у меня не было.
Сейчас я уже встал на ноги и решил попробовать снова, так что нанял таки кое-кого который мне разжевывает когда надо, а когда и подсказки дает куда копать.
Я пока не сильно долго говорю сразу, лишь с начала зимы начал, но результаты потихоньку начинают появляться, пусть и в виде чтения кода и понимания примерное что делает этот скрипт.
Что, я считаю, немало важно.
Код сам по себе я не напишу, разве что Math.clamp какой поставить между двумя точками, где надо будет, да перемещение персонажа разное.
Но потихоньку идем, что меня и моего внутреннего пездюка, несомненно радует.
Так что желаю удачи и тебе, пробуй ошибайся и самое главное, найди того кто тебя будет поддерживать, а не дизморалить.
Это очень важно в любом деле, как показала моя практика.
>под названием "код":
это же самое интересное в разработке
Наверное, но и в клик тиме тоже прикольно. Вот скажи мне анончик как ты изучал прогу, может я просто это не правильно делал
я тыкал несколько дней его, норм фишка, но выбрал в итуге конструкт
Чел, сейчас есть нейросети которые тебе любую тему разжуют, дадут примеры, да еще и за тебя сделают при надобности. Нахуя тебе это визуальное программирование? Сам начинал с Scirra Construct в свое время (но я еще зеленым школяром был тогда), даже пару относительно популярных игр на нем сделал, но тогда же и понял что нихуя не хватает такого функционала для нормального создания игр. И начал потихоньку выдрачивать программирование. Причем тогда и близко не было такого количества туторов как сейчас, и учился я на уроках всяких индуссов-джамбо. Нихуя не понимал, дальше дрочил код и в конце концов стал йоба программистом, который щас с наскоку любую ебалу сделает. Короче, в любом случае начнешь программировать рано или поздно, но после этого визуального кала будет сложнее адаптироваться. Ну а если хочешь увязнуть в этом болоте то лучше уж Construct ковыряй. Он в разы мощнее кала из твоего поста будет.
Ну и если решишь все таки включить котелок и делать правильно - дрочи Godot. Он очень простой, удобный и язык в нем крутой для начинающего. Если не знаешь как что-то сделать - пишешь в чат гпт(или гроку), объясни мне, как пню ебанному, как сделать X в Godot 4. Если не поймешь ответ - проси объяснить проще. И так до понимания. Если освоишь хорошо годот, потом сможешь без особых проблем на юнити пересесть. А там практически вся работа в гд, которая есть сейчас.
Спасибо за совет анон, будет время и мотивация возможно попробую, да я и сам понимаю что констракт по лучше будет, но в клике меня что-то цепляет. Как бы и и забил на него из-за того что видно как клик умирает, но когда узнал что готовиться третья версия вдруг загорелся надеждой что выходит самый лучший мега супер пупер движок для меня.
По поводу нейронки я капец как скептически отношусь к ним ещё с учебы, ибо они были такими себе источниками информации и понимания.
Ну думаю сейчас они шагнули хоть сколько в программирование и типа хули нет
Я решил начинать свой путь с Unity и долгое время пытался по книгам, гайдам и видеоурокам научиться в нём что-либо делать. В итоге понял, что по большей части вся информация — шлак. Книги резко из понятной информации вдруг переходят к сложному материалу без нормального объяснения, и вообще будет хорошо, если к моменту прочтения код в них не устареет и будет работать. Видеоуроки нужно смотреть сотнями и пытаться слепить что-то своё из всего разного, что показали. Я, наверное, практически не видел, чтобы кто-то по частичкам показывал каждое слово в коде таблицей с объяснением, для чего это нужно и что оно делает.
Чет я сбился с темы. Гадот я пробовал и он мне каким-то хуем оказался сложнее чем unity.
Хз как так вышло
Unity не лучший движок для начала. Он довольно своеобразный. Годот в плане входа гораздо лучше и под него на ютубе миллион туторов есть, на все возможные темы.
Плюс начинать лучше с 2д, а с ним годот в разы лучше справляется. Юнити все таки очень сильно под 3д заточен.
1) Нейросети. Сначала использовал буквально для пошаговых инструкций покажи какую кнопочку где нажимать). Когда появилась необходимость писать скрипты, нейронка это делала. НО, почти всегда в проекте что- то или работало не так, или ломалось после добавления/ обновления скрипта. В итоге на то, чтобы с помощью нейросети выяснить где ошибка тратились буквально часы. Спустя какое- то время начал сам изучать код. В итоге научился делать шарик, который может прыгать и двигаться по дороге. Зато, я понимаю как я это сделал и в случае чего могу найти ошибку. Вывод- нейросеть хороша для объяснений, дополнений, подсказок. Если не понимаешь то, с чем работаешь- не поможет.
2) Отсюда вопрос к знатокам. Так же, как и многие другие, смотрел книги, видосики, что- то конспектировал. Но пока не нашёл чёткой программы обучения, которая была бы грамотно структурирована, с понятными этапами и целями, объяснениями, упражнениями. В общем, как цикл предметов в учебном заведении. Что посоветуете? Книги, курсы (платные пока не смотрю), материалы, сайты. Будет здорово, если напишите с объяснением почему советуете.
3) Увидел, что тут хвалят Godot. Чем Godot так лучше Unity? Чем он лучше в итоге, после того, как человек будет обладать минимальными знаниями и навыками?
> Чем Godot так лучше Unity?
Он не лучше юнити. Он проще для изучения новичку, за счет питоно-подобного языка и в целом логичной и понятной нодовой структуры движка. Плюс он изначально больше был нацелен для 2д, и по 2д есть куча туториалов на ютубе, включая русскоязычные. По юнити ты хуй что найдешь по 2д адекватное, а сразу в 3д лезть - себе дороже, на старте обучения. К этому добавляется что в юнити 2д это по сути тоже 3д, только с другой камерой, поэтому в изучении будет больше сложностей. По факту будешь тоже 3д дрочить.
С годота ты сможешь потом без проблем пересесть на юнити, потому что в целом поймешь как игры устроены. В юнити есть свои нюансы, но ты их с базовым пониманием работы вещей без проблем освоишь. Если с нуля это дело ковырять то в итоге проект уровня б выйдет, в лучшем случае. В годоте же есть шанс что сразу хоть что-то адекватное получится.
Но это мое мнение, по своему опыту. Есть знакомые кодеры которые в целом ничего кроме юнити не трогали, сразу его задрочили и всю жизнь на нем сидят. Но это скорее исключение, тот путь что я описал должен быть гораздо профитнее в перспективе.
>Увидел, что тут хвалят Godot. Чем Godot так лучше Unity?
Всем лучше.
>Увидел, что тут хвалят Godot
Увидел, как в интернете хвалят линукс...
>Чем Godot так лучше Unity?
Плюсы Godot как опенсурс движка под лицензией MIT (любой другой мог бы так же):
- Можешь заглянуть в исходники, изменить их по вкусу и сделать личную сборку - бесплатно!
- Никаких обязательств при публикации игры, кроме короткого указания "сделано на Godot".
- Сообщество и сам движок активнее развиваются, т.к. все взаимодействуют с исходниками.
- Более дружная интеграция с другими сильными опенсурс проектами наподобие Blender.
Плюсы Godot с точки зрения юзабили (конкретно решения, принятые в Godot):
- Редактор стремится предоставить максимально целостный опыт использования.
- Лёгкость расширения редактора как своими скриптами, так и чужими плагинами.
- Можно интегрировать практически любой язык программирования как скриптовый.
- Удобная система GUI как для игр, так и для приложений - и на ней сделан редактор.
Другие плюсы Godot:
- Минорные обновления почти ничего не ломают, до мажорного Godot 5 ещё лет 5.
- Лёгкая система сборки движка из исходников - тебе не нужно разбираться в C++.
- Стандартный экспорт на все официальные платформы происходит очень быстро.
- И редактор, и движок в целом не сильно требователен к ресурсам компьютера.
Минусы у Godot минимальные и ситуативные. Вряд ли ты на них намотаешься как в юнити.
Наверное, единственный неустранимый минус Godot - на него меньше вакансий кабанов.
Но работа в геймдеве - это абсурд, который тебе не нужен. В кафе заработаешь больше...
Спасибо. Это больше для развлечения, возможно дополнительный доход когда- нибудь. Нормальная работа есть
Не верь годотям, говорю как пересевший с юнити на годот по идеологическим причинам. Если тебя не смущает факт того что и игра и проект и движок принадлежат непонятному дяде, без разрешения которого или без кряка от умельцев - ты даже свой же проект не откроешь, в общем если тебя такие ньюансы не напрягают - юнити лучше годота во всем, и в 2д, и в 3д, голов на десять. Вагон ассетов, которые можно пиздить и внедрять, лучше производительность, лучше поддержка платформ, буквально нет ни одного пункта по которому годот лучше (кроме разве что более удобной системы ресурсов, но это вопрос техники а не принципов, да и чтобы реализовать эту удобность - придется прям жестко познать годот).
>Плюс он изначально больше был нацелен для 2д, и по 2д есть куча туториалов на ютубе, включая русскоязычные. По юнити ты хуй что найдешь по 2д адекватное, а сразу в 3д лезть - себе дороже
Звездеж, именно по юнити больше материала, причем два на годоте немного буллшитные (один просит купить ассеты, хотя говорит по ссылке, другой с ошибками, как-будто байт на комменты).
>Минорные обновления почти ничего не ломают
Сразу видно ньюфага. Помню как пытался проект с 2 на 3 перенести, когда тот вышел. Отлетел буквально весь проект. Полагаю что при попытке миграции с 3 на 4 будет нечто похожее.
>>1082158
Ай не пизди, есть моменты в которых годот гораздо лучше. Говорю как человек который постоянно чередуя юнити и годот игры ебашит. Под 2д годот по большей части лучше. Учитывая что под него и только под него заточена половина движка. В юнити 2д - это просто надстройка над 3д. По производительности юнити и правда очень хорош (если знать что делаешь), но вроде как в 2д годот его даже выигрывает. Если конечно не юзать пресловутый DOTS в юнити, который ни один человек в здравом уме не захочет использовать из-за его сложности. С ним конечно юнити выиграет годот по производительности в разы. Но с ним и скорость разработки проекта замедлится раз в 10-15.
Кстати в скорости работы годот как раз юнити ебет. Я уже привык в юнити после каждого изменения скриптов сидеть чиллить 40 секунд, пока он всю свою залупу прогрузит. В годоте тебе все что нужно - это запустить проект.
Короче лень дальше расписывать, и тот и тот движок пиздатый по своему. Но юнити будет бабки сдирать, если вдруг проект стрельнет, а годот полностью бесплатный. Поэтому стоит в первую очереди с этой позиции над выбором думать.
Стоит понимать что над юнити постоянно работают 1000 человек на зарплате. А над годотом по большей части энтузиазты. Поэтому ясен хуй, что юнити более отполированный и профессиональный.
Вон кстати пока альтабался пошла база в юнити. Если хотите видеть эту плашку секунд 20-30 (при среднем проекте),после каждого изменения скриптов - смело качайте юнити.
Не большая цена за шарпик вместо говноскрипта. У тебя HDD? Почему так долго?
Вроде слышал что можно какую-то доменную фигню отключить чтобы шустрее было.
>есть моменты в которых годот гораздо лучше
Расскажи конкретнее, твои примеры сомнительные
>Под 2д годот по большей части лучше
На основании твоего вайба? У юнити есть все что есть у годот по 2д, и даже больше.
>В юнити 2д - это просто надстройка над 3D
Минусы? Встраивание 3д обьктов в 2д благодаря этому происходит без каких-либо проблем в рамках единой сцены, без надобности колдовать с сабвьюпортами
>но вроде как в 2д годот его даже выигрывает
>вроде
>как бы
Интересные аргументы. Я могу сказать точно где годот не выигрывает. Это его ебучее апи к движку, которое срет аллокациями, и от которых невозможно избавиться даже если пилить игру чисто на с++(ведь апи у всех языков одно), что вынуждает обходить эти приколы разными ухищрениями, навроде рейкаста нодой, чтобы фпс не умирал жидко пукнув
>Я уже привык в юнити после каждого изменения скриптов сидеть чиллить 40 секунд
Ну это чисто твоя проблема. Купи ссд, и 40 превратится в 10. А если ты еще и поменяешь свой пенек на какой-нибудь райзен 7 - ты это окно даже успевать замечать не будешь. Ну, либо отключи в настройках автопересборку домена.
>Поэтому стоит в первую очереди с этой позиции над выбором думать.
Годот с тебя сдирает время разработки, а юнити - деньги. Решать каждому надо отдельно.
>Годот с тебя сдирает время разработки, а юнити - деньги. Решать каждому надо отдельно.
Лол, выбор очевиден. Там где можно не платить - выбирут не платить. Тебя и так все подряд доят, а шанс успешной игры, которая обеспечит хотя был 5+ лет, близок к лотерейному билету.
> Расскажи конкретнее, твои примеры сомнительные
Я хоть какие-то примеры привел. Ты же просто вбросил свои мысли и еще обвиняешь меня в этом
> На основании твоего вайба?
> Это его ебучее апи к движку, которое срет аллокациями
Чел, ты сишарп вообще трогал чтобы об аллокациях говорить? Вот кто срет аллокациями так это он.
> Купи ссд, и 40 превратится в 10.
Это на ссд. Просто проект довольно большой и пк уже не самый новый (но и не слабый нихуя ). Однозначный плюс годота, лично для меня, это то что его можно на деревянный ноутбук 99 года поставить и спокойно себе работать на даче где-нибудь. Или в кровати лежать и кодить. В то время как ебанный юнити постоянно задыхается от любого чиха. Если у тебя проект чуть сложнее чем три в ряд.
> отключи в настройках автопересборку домена
>>1082367
Отключено
Дружище, если что я сам постоянно работаю и на юнити (на юнити в энтерпрайзе уже 5 лет) и на годоте. Они оба хороши. Юнити однозначно самый удобный движок из коммерческих вариантов, годот лучший среди бесплатных. О чем спор вообще?
>Я хоть какие-то примеры привел
>как бы
>вроде как
>по большей части
>Короче лень дальше расписывать
>Ряяя кок пок кок 40 секунд пересборка домена
Это не примеры, анон, это твои вайбы
>Разьебал по пунктам == Ты же просто вбросил свои мысли
Понял тебя
>Вот кто срет аллокациями так это он.
Ну так не сри. Родина дала тебе структуры, спаны, берст. Это если нужно вообще zero allocation код писать, что не требуется в 99% случаев, если ты не делаешь ртс с миллиардами юнитов. К тому же аллокации внутри шарпа - это того, кого надо аллокации(с оптимизацией внутри виртуальной машины), в отличии от того, что исполняет апи годота, аллоцируя бешеные обьемы памяти из-за того что апи не предполагает строгую типизацию, на посошок генерируя память даже для пустых словарей при рейкасте.
>Дружище, если что я сам постоянно работаю и на юнити (на юнити в энтерпрайзе уже 5 лет)
Человек якобы работает в юнити энтерпрайзе 5 лет и не знает про asmdef, жалуясь на длительность сборки. Как говорится - выводы делайте сами.
>Разьебал по пунктам
Ты походу реально дурачек. Или у тебя такой "Вайб" (всегда знал что люди которые используют это слово недалекие).
P.S. Нихуя ты умный. Про asmdef вспомнил. А ты пробовал работать с ними Алёша? И потом ты мне рассказываешь про скорость разработки на юнити. Конечно ебля с асмдефом чтобы хоть как-то ускорить компиляцию очень способствует скорости разработки.
- а на юнити ассетов много!
>Разьебал по пунктам
Может тут ты разъебал по пунктам?
Пиздец, аргумент так аргумент. Короче предлагаю тебе пойти пропердется
А ну и по поводу твоих кукареканий об аллоках в годоте, скинь посмотреть код твой на нем. Раз ты такой умудренный опытом, получше меня знаешь, давай посмотрим, как ты проекты пишешь. Что-то мне подсказывает что проблема не в годоте, а в том кто перед монитором.
>А ты пробовал работать с ними Алёша?
А че пробовать то? Берешь и делишь свой ебаный монолит на дллки
>Конечно ебля с асмдефом
В чем конкретно заключается сложность раздробить код? Не считая того что кабанчик видимо за такое не платит, но тогда не понимаю бугурта в сторону юнити по вине техдолга отдельно взятого проекта. У годота с# тот же самый msbuild один в один, точно такая же длительнвя компиляция на больших проектах (только там вместо удобного asmdef хуй без соли и без масла, конпелируй как есть или рожай проброс нугет пакетов с дллками, собранными в другом годот проекте). Если ты на годоте еще и на гдс пишешь - земля пухом, лол
>по пунктам
Я тебе конкретно написал где ты хуйни понаписывал, перемогай тупостью дальше
>>1082511
>скинь посмотреть код твой на нем
А ключ от квартиры где деньги лежат тебе не надо скинуть? Впрочем - пожалуйста
https://pastecode.io/s/iziwmntk
В редакторе все это выглядит как на пикриле
Physics под капотом сам управляет рейкаст нодами. Это черновой код, для тестов, потому без использования нормального инпута, да и код управления камерой переносила нейронка с юнити
Ну во первых годот это не про сишарп. Я про него вообще сказать ничего не могу, он явно под gdscript заточен. Может у тебя оттуда аллоки и берутся.
Во вторых я не понимаю, а нахуя ты всю эту информацию в ресурсы выносишь? MoveSpeed, Distance и тд. Если что ресурсы это аналог SO в Unity. Ты там все эти параметры (которые просто в инспекторе показывать можно) в ScriptableObject выносишь? Если ты хочешь сделать компонент в годоте не нужно ресурс отдельный под него создавать.
Создаешь Node, как child например для родительского Player и называешь его - EntityMove. И там уже логику движения делаешь, которую сможешь потом куда угодно прилепить. Там же можно и хранить нужные данные - скорость, хуерость и прочее, и в редакторе их менять через @export var speed: float. Тоже самое как в Unity SerializeField.
Местные ресурсы это пакеты однотипных данных (как и SO в Unity). В них предполагается хранить информацию о предметах/скиллах/оружии, а не какие-то базовые данные.
Только заметил - ECSEntity. Ты блять на ECS в годоте пишешь? Серьезно? Даже если так то у тебя для ECS очень корявая структура скрипта. Если это какое-то ТИПА ООП (просто со старым каким-то названием), то это вообще ужас. Все намешано в кучу. Очень спагетти код.
Ты так юнити хвалишь но где компонентная структура? Годот позволяет ее делать без особых проблем.
И ты скинул пример кода который я вообще хз как может какие-то аллоки вызывать. Но я сишарп в годоте вообще не трогал. Это пока что мазохизм.
Вот тебе пример как я скрипты в годоте делаю. Это недоделанная игра которую я сделал за выходные.
Базовый скрипт игры внутри которого создаются уровни:
https://pastecode.io/s/7qvubs53
Скрипт руки с картами:
https://pastecode.io/s/c5ywfxz2
и тд и тп
Суть в строгой иерархии.
Game
GameUI
-- Level
-- CardsHand
--- CardsHandInput
И тд.
Все четко разделено по своей зоне ответственности.
Никакой лишней инфы о других скриптах нет. Чистая нодовая струтура, которую и предполагает годот.Ты пытаешься какую-то ебалу в годоте реализовать, еще и на сишарпе который скорее как доп. опция в нем присутствует.
> про него вообще сказать ничего не могу
Я тебе уже третий раз говорю про апи движка. Gdextension. Есть такая статья, godot is not new unity. Советую ознакомиться.
>Во вторых я не понимаю, а нахуя ты всю эту информацию в ресурсы выносишь
Видишь ли, это не ресурсы. Это иллюзия. Она генерируется автоматически на основании полей и свойств компонентов в tool режиме. На самом деле никаких ресурсов нет, они начинают существовать с момента открытия сцены с этим обьектом и перестают существовать в момент закрытия сцены. Я просто манипулирую редактором, чтобы организовать себе юнити-лайк работу редактора и обойти ограничения на типизацию нод. Ведь я не терпила чтобы терпеть говноноды и не настолько ебанутый, чтобы перестать использовать редактор. И такой подход открывает мне много интересных возможностей в вопросе компоновки сцен, не говоря о том, что я больше не подстраиваюсь под ноды годота.
>Создаешь Node, как child например для родительского Player и называешь его - EntityMove. И там уже логику движения делаешь, которую сможешь потом куда угодно прилепить.
Мне это больше не нужно. Я так делал когда-то. Сейчас - я пишу совершенно независимые от годота компоненты. Этот компонент, класс которого ты видишь - не наследник Godot.Node. Смекаешь? При этом я могу спокойно работать с деревом, а nodepath + сущность-контейнер компонентов позволяют мне корректно пробрасывать инстансы в компонент через getnode.
>Если это какое-то ТИПА ООП
Скажем так - это очень особенный EC фреймворк, обьяснять суть работы ооочень долго, потому можешь его воспринимать просто как не совсем обычный компонент из юнити.
>Все намешано в кучу
А что конкретно намешано то? Компонент описывает свою логику работы, свои зависимости и цикл жизни. Все просто и понятно. Есть компонент, на который он опирается, и контейнер обеспечивает его появление. Там еще есть Changed метод, но он типа тут не применим
>Годот позволяет ее делать без особых проблем.
>Предлагает срать Node дочерними контейнерами зависимостей, удлиняя собственно доступ к зависимостям, при этом ноды-компоненты все так же остаются зависимыми от Godot.Node, что осложняет их интеграцию в архитектуру(датамодель) вне дерева Godot.Node, вынуждая рожать очередной mvc
Ну да, никаких проблем. Для три в ряд игр.
>И ты скинул пример кода который я вообще хз как может какие-то аллоки вызыват
Ну потому что ты хэллоуворлдщик, вот и не знаешь ничего.
>Суть в строгой иерархии.
Ты описываешь иерархию сцен кодом. Я описываю иерархию сцены композицией компонентов и сущностей, их содержащих, которыми я управляю в редакторе, и которые я могу подмешивать друг к другу (с сервера прилетела сущность условной машины, а я на клиенте ей подмешал физику из одних наборов компонентов, визуал из других наборов компонентов, при этом это все та же серверная сущность, которая не зависит от Godot.node). Где больше гибкости - думаю догадаться не сложно.
>Ты пытаешься какую-то ебалу в годоте реализовать
Я просто познал годотовский дзен. Я отказался терпеть говноноды, и вообще отказался терпеть сам факт того что я должен подстраивать свою архитектуру под движок. А ты не юнитист, ты говнотя обычная(местная, движкосрачерская, рассказывающая всем как хорошо прототипировать в годоте), которая юнити хорошо если по скриншотам видела, учитывая что ты предлагаешь мне в качестве решения проблемы нод.
> Я просто манипулирую редактором, чтобы организовать себе юнити-лайк работу редактора и обойти ограничения на типизацию нод.
Дружище, так в этом и проблема. Ты хочешь из годота сделать юнити. И потом предъявляешь к нему претензии, на основании того что "ебать а почему не как в юнити сделано?".
> Мне это больше не нужно. Я так делал когда-то. Сейчас - я пишу совершенно независимые от годота компоненты
Чел, ты хочешь не игры делать а движок. Есть такая каста программистов. Именно поэтому ты пытаешься ебаться с абстракциями и генерировать какой-то функционал движка внутри движка. Нахуя ты при этом хуями закидываешь годот? Я не понимаю. Он вообще про другое. Тебе дают бесплатный мощнейший инструмент, опенсурс, а ты просто его помоями поливаешь. Честно, просто не понимаю откуда этот хейт.
> это очень особенный EC фреймворк
Бляяя годот не ЕЦС!!! Это тебе в Bevy нужно зарываться. Я вообще ецс не признаю, но если уж хочется в него погрузиться, то лучше специализированные инструменты юзать. Или на крайняк какие-то либы для юнити. Ты сейчас пытаешься в движок, который СОВЕРШЕННО другой по архитектуре - ецс засунуть, и горишь что что-то не так.
> Ну да, никаких проблем. Для три в ряд игр
Я на похожей структуре, в юнити сделал огромную игру со скиллами, кучей предметов, статус эффектами, модификаторами и прочей ебалой. При этом ее легко можно поддерживать и расширять. Не на годоте да, но в целом и на годоте похожую архитектуру можно запилить без проблем.
> Я отказался терпеть говноноды
Ну чел, вот в чем проблема. Тебе не понравилась архитектура движка и ты ходишь его активно хейтишь. Зачем? Мне ецс не нравится или какой-нибудь lua. И че мне теперь ходить и рассказывать какой Bevy или Love2D хуевые?
>Ты хочешь из годота сделать юнити.
Нет, я сделал лучше, чем в юнити. Если нелегкая занесет обратно в юнити - я и там на бис повторю аналогичную хуйню, потому что не зависеть от движка это круто.
>Чел, ты хочешь не игры делать а движок.
Весь этот функционал реализован специально для игр. Этот функционал - следствие всех шишек, которые мне не понравились когда я делал свои первые проекты в годоте, в частности node контроллер одна из них, с которой мне пришла идея максимально отделиться от дерева годота
>Тебе дают бесплатный мощнейший инструмент, опенсурс, а ты просто его помоями поливаешь
Я не поливаю годот помоями, я честно говорю, что юнити лучше годота во всем (неиронично, в любом из пунктов). То что ты не дробишь свой проект на длл - это только твои проблемы. Я вообще не представляю как после шарпа можно даунгрейднутся до говноскрипта, это как с бэхи пересесть на жигули блять. Я годот юзаю считай только ради с#, за который годоту простить можно реально много, включая ньюансы по слишком жирному по памяти апи, тем более что проблема терпимая, если держать ее в голове.
>Бляяя годот не ЕЦС!!!
Мой код похож на ecs? У меня компонент код выполняет. По меркам ecs это самая натуральная ересь, собственно поэтому я и говорю, что мой ecs ближе к юнити EC, просто со своими ньюансами.
>Я на похожей структуре, в юнити сделал огромную игру со скиллами, кучей предметов
Да можно и микроскопом гвозди забивать.
>Тебе не понравилась архитектура движка
Все гораздо хуже. Мне впервые за долгое время не понравился сам факт того что я обязан подстраиваться под архитектуру движка. И я решил дать бой данной проблеме. И эта проблема относится как юнити, так и к годоту или любому другому движку с уже готовой сценой.
Ладно дружище удачи тебе с твоим боем против архитектуры. Правда нахуя ты дерешься с ним никто не знает. Под любой движок надо так или иначе подстраиваться. Если не хочешь - пили свой, а это все похоже на выебоны ради выебонов, честное слово.
Ответ простой - игры делать с таким подходом гораздо проще. Любой человек, который знаком с проблематикой глобализированной управляемости процессов между игровыми обьектами - сразу почувствует что в моем коде есть интересного, такого, что заметно упрощает производство и тестирование игр. А без этого понимания - обсуждать буквально нечего, тебе недоступно понимание о чем идет речь. И это не плохо и не хорошо, просто такова данность.
> Любой человек, который знаком с проблематикой глобализированной управляемости процессов между игровыми обьектами
Ахаха друг без обид, но о таком только ты один думаешь. Я же говорю ты хочешь не игры делать, а движки. Признай это. Это нахуй не нужно при разработке ИГРЫ. Это блять функция движка. Приведи пример игры где такой функционал который ты описываешь обязателен? Гонять компоненты игры между движками это критически важно по твоему? Это всего лишь удобная для тебя фича. Из-за чего ты и зарываешься в абстракции вместо того чтобы делать игру. Посмотри на код Terraria, Balatro, Quake 1, Team Fortress 2. Все они блять сделаны без какой-то хитровыебанной архитектуры, которая будет работать на всех движках. Terraria будет работать только на Monogame, и только на нем. Но при этом она остается пиздатой игрой, где разрабы не ебали себе мозг великими абстракциями, а просто делали игру.
>Гонять компоненты игры между движками
Я этого не делаю. Скорее - у меня есть свой архитектурный фреймворк, редактором к которому выступает редактор движка + DI. Моя архитектура позволяет мне писать достаточно сложные игры (сессионки разной направлености), а вот дружба с движками до сих пор шла не очень.
>О чем спор вообще?
Годот после юнити кажется сырым говном, если честно.
У годота есть удобные мелкофичи для вката, но на этом как-будто все.
Альтернативы конечно есть, если убрать хайп, то годот такое же экзотическое говно как остальные.
Организация API в юнити выглядит лучше. В годоте очень много подводных камней (поддержка 32битных чисел вместо 64 инта) и есть не интуитивные решения (позиция вьюпорта).
Взять даже синглтон Input, до сих пор указывают его в туториалах, а это мина замедленного действия (он вообще бессмысленнен если в игре будет gui, а gui в игре будет всегда, почему он вообще существует?).
Много чего, я уже не вспомню.
Потом краш редактора (с @tool это прям пару раз на день), магические проблемы типа просто пропали юзер инпуты в игре (многое лечится перезапуском). Очень спасает сейв сцены перед запуском билда, иначе ел говно ложками.
Я в ИТ много лет, но такого низкокачественного софта не видел давно.
>поддержка 32битных чисел вместо 64 инта
Юнити - позиция 32битная бай дефолт и соси
Годот - просто собираешь с флагами double precision и у тебя все 64 битное, это если очень надо
>Взять даже синглтон Input, до сих пор указывают его в туториалах, а это мина замедленного действия
У тебя хотябы есть выбор, _Input или Input использовать, но я в душе не ебу чем тебя это напрягает, у юнити аналогичный статический класс с инпутом
>Потом краш редактора (с @tool это прям пару раз на день)
Да лан, у меня тройка падает пару раз за 2 часа, а тут за день. Нашел на что жаловаться, кек.
>Очень спасает сейв сцены перед запуском билда, иначе ел говно ложками.
Годот и так сохраняет сцены сам перед билдом, так что можешь не париться если редактор умрет на билде. Вот реально - быстрый запуск годота, хорош только тем, что он быстро стартует после крашей и тратится мало времени на открытие сцен
> Я в ИТ много лет, но такого низкокачественного софта не видел давно.
Ахаха
>>1082540
Согласен с этим господином
Отборная шиза, после непонимания зачем нужен Input в играх все становится ясно. Управление WASD ты тоже через гуй делать собрался?
GUI (потомки Control) - это тормозная абстракция, предназначенная для WYSIWYG редактора, которая, разумеется, хороша для сложных интерфейсов и для некоторой категории игр (idle clicker, головоломки), но большинство экшн-игр требуется источник ввода на максимальной скорости, быстрее частоты кадров. По умолчанию ты используешь обработчики _input, где самостоятельно обрабатываешь InputEvent. А Input (синглтон) необходим в случаях, когда тебе нужно определить мгновенное состояние средств ввода. Принципиально разные инструменты разработки.
>краш редактора (с @tool
Краш не из-за @tool, а твоей шизы: >>1082519
>Видишь ли, это не ресурсы. Это иллюзия.
>>1082528
>сессионки разной направлености
Не мог бы ты назвать их, чтобы я их избегал?
>Краш не из-за @tool, а твоей шизы:
Получается из-за tool? Ведь эта хуйня на тулах работает. Впрочем нет, не из-за моей шизы, еще до того как я ввел в строй эту штучку - редактор стабильно валился. Тут возможно виновник сам моно/с#, ну и это тройка, а тройка это дааа...
>Не мог бы ты назвать их, чтобы я их избегал?
Зачем? Если игра говно - ты и так ее избежишь.
>Если игра говно - ты и так ее избежишь.
Часто бывает такое, что художники постарались - и выглядит игра привлекательно, а как скачаешь - так компьютер/телефон разогревается словно ядерный реактор, хотя на экране 3 штуки 2D спрайта и кнопка. Наверняка такие же умники, которые налепили 9000 абстракций, лишь бы "не зависеть от движка"...
>Получается из-за tool?
Нет же, из-за шизанутого кода, который ты в tool оборачиваешь. В документации чётко и ясно всё это описано: использование tool приведёт к багам или к падению редактора, если насрать говнокодом. Т.е. необходимо быть максимально аккуратным и не редакторировать этот код без необходимости. Лучше отключать режим tool, когда нужно внести правки, в противном случае риск влететь в бесконечный цикл, сломать данные или крашнутся намного выше.
Я написал много @tool-скриптов на многих версиях, подвешивал и крашил редактор много раз, но всегда, повторюсь, всегда это было из-за моего говнокода, случайно зациклившегося или дёргающего что-то критически важное. Т.е. это буквально skill issue.
>как скачаешь - так компьютер/телефон разогревается словно ядерный реактор
Чел, я годот использую только потому что комп юнити не тянет. Как ты думаешь, насколько хороший у меня перфоманс и быстро ли до меня доходят метрики падения производительности? У меня в компе двухядерный пенек на ддр3. Мой телефон и то помощнее будет(раз в 10).
>скилл ишуе детектинг
Анон, я тройку моно знаю как облупленую. Если ты думаешь что ты написал много тул скриптов - поверь, я написал раз в 10 больше, я по максимуму использую эту фичу, потому что это единственный способ вызывать логику внутри редактора для любых целей. Генерация, обрезка геометрии, генерация ресурсов, вот эти вот приколы как на скрине с виртуальными полями - это мой ежедневный рацион потребления. Редактор у меня падает только на билде(часто, иногда очень часто), иногда зависает сканирование ресурсов, оно вот никак с тулами не связано.
Ой, всё, забудь о производительности, я шутил так. Странные у тебя махинации с этими Resource и всё. Выглядит так, будто тебе Godot не нужен совсем.
Если у тебя комп не тянет и ты на C#, то почему не MonoGame? Или как он там сейчас называется... Визуальные редакторы не особо нужны реальным программистам, а графику можно в Tiled (2D) или же Blender (3D) настраивать, полно всяких альтернатив.
>Редактор у меня падает только на билде
Ты имеешь в виду экспорт? "Билдов" в Godot нет же. Попробуй экспортировать игру через консоль, тогда крашиться будет только отдельный экземпляр, а не открытый в данный момент редактор. Или что-то связанное с "билдами" C#? Но это ж скриптовый ЯП? Неужели байткод .NET настолько проблемная штука?
А почему не C++?.. У него же шире поддержка, любой игровой движок должен с ним взаимодействовать. Прикручивать интерпретатор байткода .NET сложнее.
>то почему не MonoGame
>Визуальные редакторы не особо нужны реальным программистам
Ошибочное мнение. Редактор, особенно редактор, который реальный программист©™ настроил под себя и свою архитектуру, чтобы работало без написания всякого промежуточного говна - это пушка. Бонусом идет сама по себе система ресурсов годота, где можно генерировать эти самые ресурсы на лету и встраивать в ноды. Я могу собрать 10-20-30-1000 сцен с компонентами и их нодовыми зависимостями в один обьект-сущность, с тонкой настройкой для корректной работы ресолвинга nodepath (если это требуется, а если не требуется - просто высрать все под один обьект и все nodepath все равно будут работать кооректно). При этом каждую сцену я настрою в удобном редакторе, только с теми компонентами, которые относятся к этой сцене.
>"Билдов" в Godot нет же.
Ну есть молоточек сверху справа, это и есть билд в моно версии. Насчет гдс - хз. Можно назвать еще - компиляция.
>Неужели байткод .NET настолько проблемная штука?
Насчет NET не в курсе, у меня тройка, там mono. Ну, игровые сборки работают исправно, а вот редактор с msbuild и с самим моно дружат так себе, часто при билде бывает монокраш или редактор просто зависает.
>А почему не C++
Рефликсии - нет, кодогенерации - нет, за памятью - следи, компиляция (особенно на моей "основной" машине) - могу себе представить какая будет. Я годот выбрал из-за с#, я его знаю очень хорошо, написал вагон инструментов еще до годота, так что я с него не слезу
>Рефликсии - нет
Нафиг не нужный медленный костыль, особенно в геймдеве, у тебя же не амнезия забывать какие классы и объекты используются.
>кодогенерации - нет,
Макросы, внешняя генерация, работает с 80-х.
>за памятью - следи,
Так у тебя ее и так мало на некрокомпе, конечно следи. RAII, ArenaAllocator в помощь. Да и в геймдеве опять же нинужно, ты и так можешь зачастую статично преаллоцировать..
>Нафиг не нужный медленный костыль
Можно и хуй сдуру сломать. А если действовать по уму - это суперсила. Даже авторы стандарта доперли до этой мысли в конце концов, но я все равно в рот ебал плюсы
>Макросы
Это компайл-тайм генерация. А без рефлексии - она еще бесполезнее. Рослиновский генератор благодаря рефлексии может прям реально дохуя (но мне автокодоген все равно удобнее)
>внешняя генерация
Сплю и вижу как мне для того чтобы сбилдить проект - приходится обновлять метаданные и перезапускать генерацию. Кроме того, она не всесильная, и работает только с простыми типами, без дженериков.
>конечно следи
Зачем? За меня мусорщик последит. Я уже наелся этой говнины полной ложкой, больше неохота.
Ну вот ты и ломаешь. Я вот вообще вспомнил, что рефлексию на куче платформ нельзя юзать, то есть ты еще и кроссплатформенность себе отстреливаешь.
> вот вообще вспомнил, что рефлексию на куче платформ нельзя юзать
Ну начнем с того что не "нельзя", а ограниченно нельзя. И ограниченно нельзя только при компиляции АОТ/il2cpp, в виду ограничений самого режима выполнения. В справке юнити они описаны, есть кое-что проблемное, но не смертельное, основной функционал, включая кодогенерацию через деревья выражений остается активным. И единственная платформа, требующая AOT/il2cpp - айсось по требованиям безопасности (на маке без проблем). Я пока туда даже близко не спешу.
Мне незачем уточнять, потому что не в платформах дело. Дело исключительно в режиме компиляции. На айсось до обновления требований по безопасности тоже все работало, и сейчас будет работать, просто тебе не апрувнут приложение. Если для тебя этот вопрос волнителен - во всех перечисленных платформах (коробка буквально винда с другой wm, было бы странно если бы на ней шарп не работал) - все отлично работает в полном виде.
Какие? Все из перечисленных тобой - точно разрешают, просто потому что на них на всех вышел силксонг, который выпускался с jit компиляцией
Ну лан, кроме wasm, но там с# моно работает, иначе бы мои билды не запускались на мобильных браузерах (да и впринципе на браузерах)
На реддите пишут, что там некий custom reflection-to-delegate compiler. В такое могу поверить, если вся динамика по факту превратиться в статику.
Это о чем речь? О il2cpp? У силксонга обычный il netstandart, который можно посмотреть любым декомпилятором il. Ну да хрен с ним, на этих же платформах вышел salt and sanctuary 1/2, оба из которых на моногейме, с jit компиляцией
> Это на ссд. Просто проект довольно большой и пк уже не самый новый (но и не слабый нихуя ). Однозначный плюс годота, лично для меня, это то что его можно на деревянный ноутбук 99 года поставить и спокойно себе работать на даче где-нибудь. Или в кровати лежать и кодить. В то время как ебанный юнити постоянно задыхается от любого чиха. Если у тебя проект чуть сложнее чем три в ряд.
Reload domain отключи.
У меня 20 сек на очень большом проекте(много людей работвют) измененич подхватываются и это при включенном релоад домейне.
>>1082510
> Конечно ебля с асмдефом чтобы хоть как-то ускорить компиляцию очень способствует скорости разработки.
Какая ебля? В начале сделал несколько папок с асмдефами, прокинул их за 5 минут логически куда надо и всё, дальше трогаешь раз в месяц когда какую-то стороннюю библиотеку или сдк юзаешь.
>>1082521
> Бляяя годот не ЕЦС!!!
Ецс это паттерн. Вообще поебать какой движок.
>>1082527
> Чел, ты хочешь не игры делать а движок. Есть такая каста программистов. Именно поэтому ты пытаешься ебаться с абстракциями и генерировать какой-то функционал движка внутри движка.
> Это нахуй не нужно при разработке ИГРЫ. Это блять функция движка. Приведи пример игры где такой функционал который ты описываешь обязателен? Гонять компоненты игры между движками это критически важно по твоему? Это всего лишь удобная для тебя фича. Из-за чего ты и зарываешься в абстракции вместо того чтобы делать игру. Посмотри на код Terraria, Balatro, Quake 1, Team Fortress 2. Все они блять сделаны без какой-то хитровыебанной архитектуры, которая будет работать на всех движках
Какую-то хуйню несешь. Все архитектурные решения принимаются исходя из одгого - удешевление стоимости разработки.
То есть ты когда делаешь игру - думаешь какие тебе нужны для этого инструменты и как проект организовать чтобы по итогу реализовать то что тебе надо(в плане фичей и стабильности) максимально быстро.
Думать, что паттерны и архитектура - это какая-то специальная олимпиада и дроч ради дроча - очень наивно и просто показывает твою неопытность.
То что террарию сделали как говно изначально(а потом кста зарефакторили))))) - не говорит о том, что это быстрее чем если бы делали сразу нормально.
Зачем делать что-то дольше, когда можно быстрее?
То что ты не умеешь и не разбираешься в этом - не значит, что этому нельзя научиться и что в этом нельзя разбираться.
Скорее всего ты всё пропустишь это мимо ушей и ща выдашь "ну террария супер успешная плохой код не помешал!!!", и я еще раз повторю - успех игры зависит от перспективности идеи, набора фичей и маркетинга, а не от кода. От кода зависит срок разработки. Чем меньше срок разработки тем лучше.
Если ты будешь как нубас программировать отрицая необходимость поддержания кодовой базы в порядке - скорость создания игр, либо их отполишенность, либо набор фичей, будет проседать.
Чем больше проект и чем больше людей над ним работают - тем это критичнее.
Если ты посмотишь на актуальные самые успешные игры, а не ископаемые 1998 года либо виральные инли хиты - то заметишь, что кодовую базу стараются держать в адекватном состоянии, часто используют ецс, и всчкие разные удивительные вещи которые ты назвал бы "противоречием арзитектуре движка".
На юнити сейчас вообще традиционные подходы на реальных проектах очень далеки от того, что ты увидишь в тутораж или демках от самих юнитеков. Просто потому что так лучше и эффективнее оказывается.
Короче не инструмент определяет пайплайн работы и арзитектуру, а наоборот. Если тебя не устраивает подход форсируемыц юнити и годотом - можешь вообще на него забить и юзать движок как рендер и набор базовых фичей типа юи звуков и т д. Даже фищику можешь кастомную делать. Главное понимать что ты и зачем делаешь.