Токсим, срёмся, диагностируем шизофрению и объявляем крысу в хате тоже здесь.
Бесконечный тред для свободного общения.
это не технология годота, это технология видеокарты
>>1086084
юнити выходит далеко за рамки графического движка
попробуй спроси у нейросети - зачем нужны burst, unity jobs, ecs, там много материала
> ноду
Ахааха бляя а вы знали что в годоте рейкат через ноду делается ч ет вспомнил ахахаха
>unity jobs
Зачем, если в C# уже есть встроенный ThreadPool?
не знаю, так положено
ты ведь всё равно не будешь их использовать
В годоте конечно есть нода для новичков, удобная для каких то разовых операций, но из скрипта есть удобный доступ прямо к физ.серверу через direct_space_state. Но если у тебя 100000 объектов, там естетственно уже другие оптимизации будут и не рейкасты движка, лол.
Впрочем, можешь показать конечно 100000 на своем юнити с берстом
Все, что не затрагивает системы движка и их производительность, вообще не имеет смысла обсуждать, потому что это тривиально реализуется самим пользователем.
Зачем мне ECS, я и сам могу массивы в цикле обновлять.
ECS актуально только за счет тесной интеграции в движок, без этого оно вообще не интересно.
рендер не единственная система движка, олсо твои сущности могут рисоваться в один момент, а в другой не рисоваться. или рисоваться каждая десятая и т. д. возможности безграничны, не нужно ворочать нос
Сейвовость(рид врайт контейнеров используемых смотрит), удобная совместимость с берстом
>твои сущности могут рисоваться в один момент, а в другой не рисоваться.
>или рисоваться каждая десятая
ecs жидко пукнет и умрет перестраивая индексы.
Я знаю, что никаких структурных изменений в этом не должно быть, более того у ецс есть разные варианты реализации, как дешевые для структурных измененийч так и дорогие.
ты чего-то по верхам нахватался и бормочешь про какие-то индексы
нет в unity ecs никаких индексов
тебе ли не всё равно, ты никогда не будешь их использовать
для твоей поделки на годоте это не нужно. я их тут видел как минимум три штуки, и они все одинаковые - моделька анимешной девки бегает по низкополигональному миру с хрюкающими волками, на этом разработка игры заканчивается
>тут
А я тут давно ничего не выкладываю. Зачем метать бисер. Главное игроки довольны.
Там у меня много чего, самолеты летают, корабли плавают. А двощерам да, достаточно анимешную девку побегать дать.
Ну смотри. Ты выключаешь свои сущности. Единственный способ это сделать по ЕЦСному, по хардкорному, это удалить компонент. Так как у тебя ЕЦС с архетипами конечно же, то это активирует копирование памяти всех компонентов в другой архетип. Потом система пропукивает список твоих сущностей, создает новый список компонентов рендера, сравнивает с предыдущим, находит удаленные компоненты (в bevy так, по крайней мере), и перестраивает свои внутренние структуры данных.
Даже по этому описанию, как ты понимаешь, работы там не мало. Это совершенно точно не будет эффективнее простого сообщения об отключении объекта.
> tangy td
https://store.steampowered.com/app/2245620
Выводит на главную страницу
И такие траблы еще только при одном компоненте, даже не двух и не десятке.
> Ну смотри. Ты выключаешь свои сущности. Единственный способ это сделать по ЕЦСному, по хардкорному, это удалить компонент.
Нахуя, я совсем отбитый что ли так делать? Кто мне мешает в компоненте связанном с рендером флажок поменять на фолс?
В том. что это уже будет не ecs, а ооп, потому что этот флажок где то хранится (и флажочек скорее всего не один), а значит ты шатаешь кэш, а еще ловишь все удовольствие от промахов предсказателя перехода по if
> что это уже будет не ecs, а ооп
Ты реально дебил
> потому что этот флажок где то хранится
Да, в компонентах в ецс хранятся данные
> а значит ты шатаешь кэш, а еще ловишь все удовольствие от промахов предсказателя перехода по if
А это хуже чем структурные изменения?
Проблема фильтрации любых сущностей есть везде в любом случае и есть разные варианты как с ней работать, и юзаешь ли ты ецс или нет тут абсолютно никакой роли не играет.
Если я не прав - напиши как решить эту проблему так, что именно ецс тут мешает а иной подход не мешает. (Если что, я знаю, что никак)
В юнити ецс под капотом это старый добрый SOA, например, чего ты скорее всего не знал.
вроде речь шла не про какой-то идеальный абстрактный ecs, а про конкретный unity.entities, а там есть флажочек и он работает
каждый кадр по 10 тысяч компонентов включать-отключать конечно же не надо
> вроде речь шла не про какой-то идеальный абстрактный ecs
Идеальный абстрактный ецс допускает любые данные в компонентах, так что он вдвойне шиз.
А также допускает, что у тебя не вся игра игра на ецс.
Я хз вообще что за дебилиусы считают, что если ты применяешь для чего-то ецс, то должен обязательно абсолютно всё делать на нём, я даже тут вроде читал какого-то шиза который заявлял, что ецс говно потому что аниматор на нём получится говном а если я делаю его не на ецс то это уже значит что я делаю костыли и так непраивльно, надо делать на ецм. НАХУЯ. ПОЧЕМУ. ДЛЯ ЧЕГО. КТО СКАЗАЛ. КОМУ НАДО. ААААААА
Потомк что единстенный рнпльный плюс ецс был бы кэш локалити, а он убивается любым твоим смешением, и ецс стаеовится нинужнл. Подходит только видосиков про прыгающие 100000 кубикшв.
> Потомк что единстенный рнпльный плюс ецс был бы кэш локалити, а он убивается любым твоим смешением, и ецс стаеовится нинужнл.
А ЧТО НУЖНО ТОГДА
Ну типа лол, напиши тогда как решить проблемы дырок с временно ненужными данными - эта проблема в любом случае есть, у неё нету единственного идеального решения.
В какой то ситуации линейная укладка в памяти с дырами нерелевантных данных будет лучшим варианьом, в какой-то может есть смысл группировать по чанкам в мире, в какой-то может есть смысл иметь отдельный геймплейный домен и графический и систему синхронизации между ними, в каком разделить это ещё на разные миры.
Тут все ситуативно, и помножено ещё на все факторы скорости разработки - вряд ли ты будешь на практики всё это пробовать, если у тебя игра не за сотни миллионов долларов.
>А также допускает, что у тебя не вся игра игра на ецс.
именно так - главная фишка екс - кеш френдли. все. А любой твой пук в рандомное место массива компонент - убивает это.
не надо рассказывать про какое-то там удобство, геймдизайнеров - это все жопа.
удобства нет - в дебаге это полная жопа - потому что у тебя поток каких-нибудь Transform и ты просто не можешь узнать почему конкретно этот Transform двигается вот сюда, а должен был вот туда.
для дизайнера - миллион каких-то кирпичей - хуй знает как из этого говна собрать орка или сундук. Я уж промолчу про момент, когда компоненты начнут дублироваться - потому что какой-то программист не нашел нужное, и сделал копию.
>Ну типа лол, напиши тогда как решить проблемы дырок
именно поэтому реальное екс так и остается чисто академическим и бывает двух видов:
- это ООП с паттерном компонент, которое маркетологи обозвали ecs для повышения продаж
- разраб - шизоид, у которого нет цели сделать продукт - у него цель сделать идеальное ecs
про маркетологов екс... вот например
>>1086016
шизики говорят что без екс бы не сделали.. ложь-пиздешь и обман. Было полно игр с миллионами юнитов. и не в виде кубов, а с реальной анимацией - да теже первые total war. казаки. или игры где можно было устраивать баталии миллионов стикманов (они на юнити конечно - но еще древнем, где никакого реального екс не было, и даже все еще делали миллионы Монобехаверов)
>В годоте конечно есть нода для новичков, удобная для каких то разовых операций, но из скрипта есть удобный доступ прямо к физ.серверу через direct_space_state.
Удобный и срущий пустыми variant словарями даже если не произошло коллизии, вот такая вот удобность. Юнити то 100000 рейкастов покажет, да даже годот их покажет, но с ньюансом - такие цифры может показать вызов рейкаста непосредственно внутри рантайма движка, а не через апи. В 4 ты либо рейкастишь нодой, либо пытаешься оптимизировать через raycastquery, за простой рейкастинг тебе быстро прилетят пропуки, как только количество рейкастов за кадр приблизится к 1000, а цпу вместо полезной работы все больше будет обслуживать аллокации
На 100000 рекастами и не надо пользоваться, там другие алгоритмы уже. Поля векторов, карты высот, отряды с лидерами, боиды, астары по клеточкам в конце концов. Можно сделать простенький свой райкаст по аналогии с вульфенштейновским - там очень простая математика рассчета пересечений с сеткой. Если уж никак без рейкастов, то батчить, кидать луч раз в 1-2 секунды.
ECS уже не столько актуально с точки зрения производительности. у современных процессоров и так больше кеши. любой, даже самый неоптимизированный ООП код, на современном процессоре будет выполняться быстро, если не нужно вычислять миллионы одинаковых операций.
проблема производительности никогда не была в поведении игры, она в ядре движка. для того, чтобы оптимизировать ядро, не нужно заставлять пользователей переделывать все на ECS, нужно просто использовать data oriented дизайн для внутренних стуктур данных. то есть вместо массивов структур нужно использовать структуры массивов, линейность в памяти не имеет значения, тк кеш обновляется случайными страницами памяти, важно только то, чтобы в страницу кеша статистически больше попадало объектов.
>На 100000 рекастами и не надо пользоваться
Очередной проход в "нинужно", никто не сомневался
>Поля векторов, карты высот, отряды с лидерами, боиды, астары по клеточкам в конце концов.
Ну конечно, ведь именно для этого существуют движки, чтобы ты писал сложные алгоритмы для починки уебанства, которое родили на похуй и не запариваясь, и изобретать которые было бы не нужно, если бы кое-кто не сделал из апи движка variant-нетипизированный пиздец.
>Можно сделать простенький свой райкаст по аналогии с вульфенштейновским
А можно просто починить апи (или использовать движок с нормальным апи) и не надо будет изобретать простенький рейкаст, реализовывая дополнительный физический движок для отслеживания столкновений.
>там очень простая математика рассчета пересечений
Если в этой "простой" математике не фигурируют деревья с быстрым поиском - то я сильно сомневаюсь что такое отслеживание коллизий будет дешевле по производительности вызовов direct space со всеми его аллокациями на мусорные variant словари, а если они там представлены - то такую математику простой не назовешь.
Не ну если для тебя octree сложно, то конечно тут нечего обсуждать. Тебе остается только брутфорсить перебором рейкастов.
давай признаем - ты просто ненавидишь ецс в любом виде, чистом или нет, потому что в годоте его нет
как только в годот завезут ецс, пусть в 10 раз более тормозной - сразу станешь его защитником
как раз octree можно сделать на компонентах и вынести его в unity job да ещё оптимизировать burst'ом - вот тебе и пример "невидимых сущностей"
Ну да, мне сложно писать все за автора движка. Я делаю игры, а не октодеревья для реализации того что и так блять встроено в физический движок(те самые деревья), обеспечивая аналогичную производительность кустарному решению, но с маленьким ньюансом в виде того что оно спрятано за ублюдочным, срущим аллокациями апи. При чем годот в этом плане абсолютно уникален, только он догадался превратить апи движка в вариант месиво только ради того чтобы любимая игрушка хуана под названием gds продолжала свой убогий жизненный цикл
Тебе и не нужно писать ничего за автора движка, автор писал движок общего назначения, у тебя уникальная ситуация 1000000 объектов, встроенными физ движками это не симулируется, значит пишется свой облегченный. К чему ты вообще годот приплел- непонятно, у тебя шиза какая то видимо. Кстати, тащи пруфы с профайлерами и отладчиками что аллокации занимают какое то значимое время, иначе пиздабол.
Нет конечно. В годот ради юнитидаунов и C# завезли, и я каждый раз пишу что он не нужен.
> 1000000 объектов
В какой момент вызов рейкаста превратился в обьект? Ну не считая того что апи годота возвращает нетипизированный словарь в качестве результата, но это конечно половые проблемы исключительно годот-апи. Мы вроде как начали с обсуждения безобидной функции рейкаста, которая в нормальных движках создает структуру или линейный массив структур
>К чему ты вообще годот приплел
Ну так годотю ж обсуждали. У тебя контекстное окно переполнилось?
>Кстати, тащи пруфы с профайлерами и отладчиками что аллокации занимают какое то значимое время, иначе пиздабол.
https://sampruden.github.io/posts/godot-is-not-the-new-unity/
Советую ознакомиться, занимательнейший документ
>В какой момент вызов рейкаста превратился в обьект?
У тебя лошадь и телега местами перепуталась. Очевидно, у тебя проблема X Y. Какую задачу ты пытаешься решить для 100000 объектов рейкастом?
Ну так это для юнитидаунов, их проблема. Им говорили не брать C#.
Я вот думал а чего это вдруг аллокация чего то стоит, это же просто увеличение указателя на число. А потом вспомнил что в этом недоязыке же потом все нулями заполняют,даже если потом переменные это перезапишут, ололол
>Какую задачу ты пытаешься решить для 100000 объектов рейкастом
Можно взять классическую буллетхелл проблему, и например и сделать каждой пульке коллизию на рейкастах, это достаточно удобно, а сами пульки рисовать средствами visualserver/renderingserver. Аналогично рейкаст-стрельба моментальными пулями без баллистики. В нормальном движке это делается без проблем упомянутым тобой апи, а в годоте это делается нодой, чтобы скомпенсировать уебищность апи движка в разрезе рейкаста от хуана.
>>1086173
Затем что если бы ты делал игры на годоте, то знал бы что gdnative/gdextension - это единое апи для всех языков. Да, для с++, для rust, для c# и для gds - будут одни и те же проблемы с тоннами мусорных аллокаций
Ну так я ж тебе сказал, принеси пруфы из дебаггера/профайлера что аллокации для c++/rust занимают существенное время.
>Можно взять классическую буллетхелл проблему
Можно. Но вот незадача, в буллетхеллах 100 пулек, а не миллион.
>и например и сделать каждой пульке коллизию на рейкастах, это достаточно удобно,
Зачем, если это делается элементарно через радиусы и distance_squared
>Аналогично рейкаст-стрельба моментальными пулями без баллистики.
Классно, но причем тут миллион? А если у тебя 100 выстрелов в кадр то ты хоть нодой можешь делать.
> в годоте это делается нодой, чтобы скомпенсировать уебищность апи движка
Но ты же шизофреник, потому что только что писал про апи raycastquery ))))
>>1086178
ты уводишь тему в сторону пытаясь найти в годоте хоть какие-то плюсы чтобы оправдать его перед юнити. нехорошо. займись чем-то одним
Я принес тебе пруфы. То что там используется с# - не имеет значения, потому что управляет аллоцированными variant массивами апи движка, а с# маршаллинг задействуется только в момент извлечения из variant словаря значения хита(чего в тесте нет). Если тебе мало - ну окей, чем больше пропукивающего говна на годоте будет, тем может быстрее дадут пизды хуану чтобы тот апи переделал
а кто тебе сказал что технология должна обязательно работать на пределе возможностей, иначе она "нинужна"? ецс отлично работает и с сотней объектов
но даже если взять среднюю 3d-сцену, там будут не сотни, а тысячи сущностей.
годот же на тысяче нодов уже начинает пропукивать и приходится придумывать всякие ухищрения типа использования рендерсервера, C++ библиотек и т. д.
у нормальной же технологии всегда есть оверхед
>Ну так это для юнитидаунов, их проблема. Им говорили не брать C#.
щас бы говорить про шарп, на фоне питонокалла, который вообще-то по своей философии самый медленный язык (вот нах вообще питон брали для скриптов? взяли бы какой-нибудь JS)
>Можно. Но вот незадача, в буллетхеллах 100 пулек, а не миллион.
Ржомба
>Зачем, если это делается элементарно через радиусы и distance_squared
И сколько твои радиусы будут считаться с O(n²) сложностью, шиз?
>Классно, но причем тут миллион? А если у тебя 100 выстрелов в кадр то ты хоть нодой можешь делать
Почему именно 100? 100 выстрелов это перестрелка из 3 мобов, а на 20 мобах у меня игра будет превращаться в слайдшоу? Охуенно придумал бро
>Но ты же шизофреник, потому что только что писал про апи raycastquery ))))
Квери по итогу выйдет немного дороже нод при сопоставимой сложности организации пропускания всех игровых рейкастов через 1 квери, потому это конечно в некоторой степени компенсирующий выход, но я предпочел сделать на нодах в виду наибольшей оптимизированоости
>Ржомба
тебе не нужно считать каждую пулю. тебе нужно считать направление пуль - иначе это не булетхел а хуита. Все пули в булетхелах летят по определенным игровым правилам чтобы игрок мог на них реагировать.
Так что на экране у тебя может быть тыща пуль, а в логике ты просто сложил два вектора, плюс добавил в вершинных шейдерах разброс
>ты уводишь тему в сторону
>движкосрач тред
Поссал в ротеш юнитидебикам.
шитпостинг здесь не одобряется
пиши аргументированные посты или не пиши вообще
> - это ООП с паттерном компонент, которое маркетологи обозвали ecs для повышения продаж
Какое реальное екс? Что это значит?
У нас есть ентити, компонентя, системы - екс, как это не является екс? Напиши почему это не попадает под реальное определение ецс, какое реальное определение ецс и где с ним можно ознакомиться.
>>1086150
> ECS уже не столько актуально с точки зрения производительности. у современных процессоров и так больше кеши. любой, даже самый неоптимизированный ООП код, на современном процессоре будет выполняться быстро, если не нужно вычислять миллионы одинаковых операций.
Практика с тобой не согласна.
> проблема производительности никогда не была в поведении игры
> она в ядре движка.
Каким образом? У нас запущен рантайм движка и жрет 0.1мс в кадр.
Ты пишешь код, какой напишешь, столько выполняться и будет. Прчм вот натурально скомпилируется и будет слаться на проц, движок тут роли не играеи.
Из движкового ты можешь что-то использовать, а что-то не использовать. Что будет считаться ядром тогда? Если я физику движка не юзаю она ядром считается или не считается, является ли она проблемой? А если я из движка юзаю только рендер? Причем делаю это прямыми командами на отрисовку? Что будет тут ядром которое мне мешает?
> для того, чтобы оптимизировать ядро, не нужно заставлять пользователей переделывать все на ECS
Кто кого что заставляет делать? Есть конкретный инструментарий, ты если хочешь можешь его использовать, а если не хочешь можешь не использовать.
Всё что у тебя по факту выполняется в игре - занимает процессорное время, тебе самому исходя из этого решать что и как оптимизировать.
Если ты попробуешь поделать игру и запустишь профайлер, то ты довольно хорошо поймешь что происходит и сколько твой код занимает времени, и какие то выводы это позволит сделать, ты можешь что-то попробовать, поэксперементировать, и сделать окончательные выводы, например, что никакое абстрактное неведомое ядро говно в штаны не подкидывает
> то есть вместо массивов структур нужно использовать структуры массивов
Ты такой умный, наверное никто не догадался и это делается не 1 промптом. Это всё, другие оптимизации не нужны?
А как конкретно соа в какой то движковой системе мне поможет при юз кейсе что я описал?(из движка юзаем только прямые команды на отрисовку через минимальное апи)
>а кто тебе сказал что технология должна обязательно работать на пределе возможностей, иначе она "нинужна"?
Мне это сказал Кодзима на GDC 2014
>ецс отлично работает и с сотней объектов
Работает, но вот ецс-сектанты то носятся с ней как с серебряной пулей.
>но даже если взять среднюю 3d-сцену, там будут не сотни, а тысячи сущностей.
Да не, не будет, там обычно просто один меш склееный.
>годот же на тысяче нодов уже начинает пропукивать и приходится придумывать всякие ухищрения типа использования рендерсервера, C++ библиотек и т. д.
Ну то есть нормальное использование подходящих инструментов - это "ухищрения".
У тебя рот залит мочой, ничего не разобрать что ты там булькаешь.
никаких ецс-сектантов нет, ты просто ущемился от того, что в юнити есть ецс, а в годоте его нет. я ецс вообще не использую, просто в курсе что он имеется
годот это не подходящий инструмент для чего-то более чем "аниме-девка бегает по склеенному мешу"
>тебе не нужно считать каждую пулю. тебе нужно считать направление пуль - иначе это не булетхел а хуита.
Игрок перемещается - держу в курсе. Он может переместиться вовнутрь потока снарядов. Делать снаряды линиями, без возможности создавать сложные визуальные структуры - можно но неинтересно. К тому же ыя делаю шутан от первого лица, где генератор буллеттов не статичен и сам перемещается по сцене непосредственно в процессе генерации пуль, что смазывает поток и не дает возможности как-либо сгруппировать пули в единое коллайд-пространство. Используя ноды-рейкасты - я могу такое сделать с терпимой нагрузкой на цпу даже в браузере.
> >А также допускает, что у тебя не вся игра игра на ецс.
> именно так - главная фишка екс - кеш френдли. все. А любой твой пук в рандомное место массива компонент - убивает это.
Как это соотносится с тем на что ты отвечаешь?
Я делаю мету на ооп, ии и аниматор своим шаманством в рамках функционального программирования.
А вот геймплей на ецс. Причем тут пук в рандомное место?
> главная фишка екс - кеш френдли
А чем тебе просто СОА не угодил без ецса поверх? Это тоже кэш френдли и без всяких ецсов поверх.
Подсказка - ецс это архитектурный паттерн.
> не надо рассказывать про какое-то там удобство, геймдизайнеров - это все жопа.
> для дизайнера - миллион каких-то кирпичей - хуй знает как из этого говна собрать орка или сундук.
Каким оьразом инструментарий для геймдизайнера и ецс связаны? Ты можешь геймдизайнеру что хочешь выдать. Можешь и напрямую ецсные компоненты - разницы по сравнению с обычными компонентами никакой.
> удобства нет - в дебаге это полная жопа - потому что у тебя поток каких-нибудь Transform и ты просто не можешь узнать почему конкретно этот Transform двигается вот сюда, а должен был вот туда.
Как жаль что никто об этой проблеме не думал и не догадался сделать нормальный дебаг(в юнити ецс есть ентити журналинг и инспекторы где все находится и позволяет быстрее найти причину, на проектах с другими ецс часто есть самописные тулзы)
>Ржомба
Открой популярные тайтлы и проверь.
>Зачем, если это делается элементарно через радиусы и distance_squared
>И сколько твои радиусы будут считаться с O(n²) сложностью, шиз?
Ты ебнутый? Ты пульку с пулькой коллайдишь в буллет хелле? Или таки с одним игроком?
>Почему именно 100? 100 выстрелов это перестрелка из 3 мобов
У тебя моб стреляет 30 выстрелов В КАДР? Ты ебнутый? Это даже визуально не отобразить чтобы игрок мог это воспринять. Даже если взять какой нибудь 6стврольный вулкан который делает brr brr, там логичнее целую очередь одним спрайтом и одним конусом обсчитать. Но даже там скорострельность 6000RPM, т.е. 100 выстрелов в секунду, то есть примерно ЕДИНИЦЫ выстрелов в кадр, карл! А обычные автоматы, пулеметы раз в 10 медленнее.
смотри до чего ты опустился в попытках защитить какого-то рыжего аргентинского мужика который про тебя даже не слышал
репорт за шитпостинг
Никто не будет удалять посты, которые тебе не понравились
Чел, расстояние двух полурадиусов на линии это школьная арифметика, ну, 7 класса.
это твоё личное безыгорное мнение
инструмент есть и им пользуются, и у него есть минусы - но не те, о которых ты говоришь. потому что ты не имеешь представления о том, о чём пишешь. так что лучше не пиши вообще
польза зависит от пользователя
у хорошего хозяина всё в дело идёт, а у плохого - в доме бардак
вот вот. а ты не осилил сделать витрину на годоте. ты - плохой хохяин
>Ты ебнутый? Ты пульку с пулькой коллайдишь в буллет хелле? Или таки с одним игроком?
Пулька коллайдится с
1. Окружением
2. Интерактивными обьектами которые держит игрок
3. С игроком
Достаточно первого пункта чтобы понять где эта тема не выгорит любому кто хоть немного понимает в геймдеве. В системах частиц применяют кастомные гпу-солверы коллизий с специально подготовленной геометрией на сцене, а на цпу применяют функционал физдвижка, который даст наилучшую производительность (если не будет обосран хуевым апи, как в годоте)
>Открой популярные тайтлы и проверь.
Какие-то ноунеймы. Фури нет, шутерного соулслайка с плазменным оружем (забыл как называется) тоже нет.
>У тебя моб стреляет 30 выстрелов В КАДР?
Суммарно моб может сгенерировать до 30 буллетов за 2 секунды, выйдя на максимум в 70 +- с учетом того что буллеты продолжают жить в физическом мире пока куда-либо не попадут или не исчезнут по лайфтайму. В процессе их лайфтайма нужно у всех проверять коллизии, потому что обьекты двигаются и могут зайти в поток буллетов. Если выстрелов много, стрелок двигается а снаряды достаточно медленные - группировать их невозможно.
я не пользуюсь годотом. я хозяин в этом треде и мои инструменты - это остроумные метафоры, а не код и не технологии
Безигорный, ты сначала узнай что такое алгоритмическая сложность чтобы не позориться со своими радиусами
Если бы ты знал, что такое алгоритмическая сложность, ты бы сразу понял почему ecs дрисня никогда не взлетит.
Ты всех забанил в годотреде, и теперь сюда пришел всех банить?
я не модератор, я не могу никого банить и в годотреде не сижу
меня самого там банили давным-давно
однако я туда заходил недавно и имел возможность оценить поделия местных анонов и меня это не впечатлило
Ой, сорян, зря быканул >>1086209 , все же еще хуже, ты так и не понял почему создание потока буллетов невозможно, ведь ты не понимаешь концепции движения генератора частиц в мировых координатах
Сорян, но я в отличии тебя знаю что такое аналитическая геометрия, конус, сектор. А ты конечно продолжай брутфорсить рейкасты и греть атмосферу.
Если юнитидауненка назвали юнитидауненком, это может быть не токсичность, а просто наблюдение, правда, факт.
Ну ты уж вспомни как называется, посчитаем на скриншотах сколько там пуль в кадре, 100 или 1000000
Обновление трансформов и быстрота ECS вещи не совместимые, поскольку трансформы иерархические.
Какая разница кого ты как называешь. Проблема в том, что годоти отпетушили друг друга в своем треде, а теперь пришли сюда и опять раскидываются банами. В чем причина этого феномена?
это не было бы проблемой, если бы трансформации хранились в структуре массивов, потому что даже прыжки по иерархии подтягивали бы большинство данных в кеш.
https://youtu.be/aMvVflfLI8E
На 4:49 отмотай
Это явно делалось средствами гпу, но в моем случае - и цпу невеста
Берешь 100 лифтов, а в каждом по 20 кнопок и обезъянка их нажимает. Ну вот и теперь смотришь что будет с трансформами кнопок, если каждый лифт едет со своей скоростью в свою сторону.
вот я изобразил разницу между локальностью и линейностью компонентов (так реализованы архетипы во всех ECS). линейность избыточна, не дает никаких преимуществ и сильно усложняет архитектуру.
для локальности компонентов не нужно даже ECS, потому что она может быть скрыта в ядре движка и предоставлять обычный ООП интерфейс.
Ну тут пара сотен всего, никакими миллионами не пахнет даже близко. CPU у него вроде не слабый, ну видяха старенькая правда но тоже норм.
На 22 минуте есть еще один партикловый колизионный серун. И ты учитывай что у игрока тоже есть партиклы с коллизиями. Плюс в боссы не попали мобы, которые тоже нормально так высираются партиклами, я просто уже не найду нужный футаж, но по памяти припоминаю что срут они нормально. Бюджет в 2к активных партиклов проверяющих коллизию на сцене должен быть заложен. У меня в игре максимум партиклов около трех сотен, но у меня есть дополнительная рейкаст нагрузка (спрей аима, который наводит партиклы только когда враг видим, рикошеты партиклов от стенок), в нативном клиенте партиклам можно даже активировать освещение, три сотни омнилайтов годот тянет хоть и с каким-то умопомрачительным количеством dc
нельзя обсуждать свои проблемы, потому что если недостаточно восторженно написать про годот, вахтёр отрепортит за "движкосрач". он вообще там круглосуточно сидит и репортит все посты кроме своих
поэтому вместо обсуждения движка годоти пишут пространные простыни об использовании синглтонов в мультиплеере или как устроен ецс и могут делать это месяцами
Ну нравится мне омнилайт, нихуя с собой поделать не могу. Можно конечно блум отрисовать, но мне омнилайт нравится больше. Было бы заебись, если бы наконец появился отложенный рендеринг, но а пока имеем что имеем.
> локальностью и линейностью
Выдуманные тоьой термины.
Вернее локальность и линейность есть, но они не значат то что ты говоришь и даже пересекаются в олном месте, потому что линейность гарантирует локальность.
> линейность избыточна, не дает никаких преимуществ и сильно усложняет архитектуру.
Ага, целый один индекс вместо плавающего количества разных(что в теории решается кодогеном, конечно, но все же это лишнее усложнение) заставляет хранить
промахнулся постом
кто тебя довёл до жизни такой? неужели годот
Да я шучу, я же не стукачок как ты , отправлять не стал. Но по факту же ты нарушил правила двача.
в моём посте не было ничего про это - выдаешь желаемое за действительное
было про сумасшедшего вахтёра - вредного деда-красноглазика
почему-то сторонники опенсорса зачастую такие токсичные шизы, которые сами себе палки в колёса вставляют. а потом удаляют целые репозитории или собственные игры со стима когда в голову внезапно ударит
Если ты там так же токсил, ничего удивительного, что тебя забанили.
нет, я не токсил и я не фанат опенсорса
идея звучит привлекательно, но на деле имеем то, что имеем
поэтому весь стоящий код - закрытый и охраняется семью печатями. за редкими исключениями
Верь в это. Вся такая вера основывается на незнании, какое же там гумно в этом закрытом коде.
Кто видел закрытые колбасные заводы, колбасу больше не ест
я видел этот код своими глазами
напряги зрение - и увидишь голограммы
>плавающего количества разных
компилятор выражения обращения к массиву вида foo[bar] трансформирует в одну инструкцию, у которой эффективность такая же, как у обычного указателя.
кстати, до популяризации unity ecs, все ecs движки имели первую архитектуру. это именно unity популяризовал архетипы.
> компилятор выражения обращения к массиву вида foo[bar] трансформирует в одну инструкцию
Причём тут инструкция, где я говорил про количество инструкций?
Я говорю, что система более сложная когда у тебя разные индексы и требуется эти индексы хранить и менеджить, и доверху еще и обертку как то генерировать чтобы ты из кода мог это дергать нормально.
> кстати, до популяризации unity ecs, все ecs движки имели первую архитектуру.
Спарс сет: ну да, пошел я нахуй
так как индексы компонентов не меняются, в отличие от архетипов, можно в системах "регистрировать" нужные компоненты один раз. например, в системе движка отвечающую за рисовку можно сделать список struct EntityId { int transform_id, renderer_id } и заполнять один раз при изменении компонентов (в событии каком-нибудь).
Реально прикольный рантайм пихла, без шуток. Но лицензия конечно мемная
У первого семантика динамического изменения дерева, у второго - добавления неоднородных элементов в коллекцию. То есть элементов, которые ничего не знают о контейнере, в которых их добавляют, но узлы знают что их добавляют к родителю, и у них есть свойство parent, поэтому семантика неоднородной коллекции в данном случае является неправильным дизайном.
SetParent в одном методе заключает все операции с деревом. add_child/remove_child искусственно их разделяет на 2 этапа (что еще медленнее), и получается что-то вида this.node.parent.remove_child(this);
Это еще усложняет реализацию add_child/remove_child, потому что нужно больше проверок и т.д.
А как в Unity отделить объект от дерева сцены? Это вообще возможно? Я нашёл только один метод "DetachChildren()", но, кажется, он помещает всех детей под root, т.е. не выгоняет их из дерева.
>искусственно их разделяет на 2 этапа
В Godot 4 добавили метод Node.reparent(new_parent: Node), которая сразу перемещает ноду (на которой этот метод вызывается) к указанному в аргументах родителю. Можешь воспринимать её как прямой аналог SetParent(), если хочешь... Исходников Unity у тебя всё равно нет, чтобы сравнить реализации.
Метод Node.remove_child() нужен для того, чтобы остановить обработку ноды в рамках дерева сцены. То есть нода вне дерева сцены не отображается, не влияет на физику, не принимает ввод с клавиатуры и т.д., но продолжает существовать в RAM и может отвечать на пользовательские запросы и пользовательские обработчики событий. Я даже не представляю, как реализовать что-то подобное в рамках API Unity...
По идее, Godot может иметь несколько деревьев сцены одновременно, но можно ли (и насколько сложно) сделать это на практике - не знаю, не пробовал. Т.к. у любой ноды есть метод get_tree(), возвращающий значение только пока нода в дереве, и, значит, ноды могли бы иметь разные деревья сцен в одном рантайме. Хотя, для по-настоящему независимых деревьев сцен нужно как-то избавиться от всех движковых синглтонов...
>this.node.parent.remove_child(this);
Что это? Код Unity? Если тебя волнует
>(что еще медленнее),
То нужно смотреть в исходники Godot на GitHub, а не гадать по API Unity. Там они много чего меняли за последние годы, оптимизируя (ускоряя) взаимодействие с деревом сцены.
Я подозреваю, что "дерево сцены" в Godot и Unity вообще имеет разное значение. Как я понимаю, в Unity "дерево" касается только transform, а всё остальное от него никак не зависит. В Godot же, напротив, от "дерева" зависит вообще всё, за редким исключением (когда ты ставишь галочку top_level, например, или используешь CanvasLayer, и т.п.). Можно сказать, что дерево Unity - слабое, а дерево Godot - сильное. Тем более что в Godot нет понятия "компонента" - ближайший аналог "компонента" - это дочерние ноды в дереве. И ограничение "1 нода = 1 скрипт" - это тоже следствие сильного дерева...
Алсо,
>элементов в коллекцию
Дерево сцен в Godot под капотом разделяется на несколько независимых списков, которые обходятся движком в более эффективном режиме, чем если бы он постоянно бегал по дереву. То есть, например, физические ноды в дереве - это не то же самое, что реальные физические сущности в физическом движке. Аналогично с графикой, скриптами и т.д. Всё под капотом оптимизировано и "дерево сцен" - это только абстракция над внутренностями движка для удобства пользователя, а не реальная структура работы движка.
Но я, если честно, не сильно копался в исходниках, только поверхностно глядел когда-то.
> А как в Unity отделить объект от дерева сцены?
SetParent(null)
>SetParent(null)
В документации Unity данная фича никак не описана, а проверить я не могу.
Но ладно, а если нода сделает так сама с собой - кто её возвращать обратно будет-то?
Я забыл написать, что >>1086488
>this.node.parent.remove_child(this)
На GDScript правильная запись выглядит так:
>get_parent().remove_child(self)
То есть "убрать себя из родителя".
Но! Так делать обычно не рекомендуется. То есть ноды обычно должны управляться своими родителями, не трогая методы родителей. Это родитель вызывает сам у себя:
>remove_child(my_node)
А потом продолжает работать с этой нодой по ссылке, остающейся в my_node. Совсем не обязательно добавлять эту ноду под какую-то другую ноду.
Поэтому новый метод будет выглядеть так:
>reparent(new_parent)
Только когда нода сама себя куда-то перемещает, а у её предка будет:
>my_node.reparent(new_parent)
В общем, не вижу в этом никаких проблем. Сама себя нода извлекать из дерева лишний раз не должна, ведь она может "потеряться" из дерева (если ни у кого нет на неё ссылки), но если она планирует сама себя куда-то переставить - ОК, можно использовать этот новый метод. Стандартные ноды не удаляются Godot автоматически, т.е. пока не вызовешь queue_free(), они будут висеть в памяти, даже если никто на них ссылки не имеет...
>>три сотни омнилайтов
>Бляяяяяяяя
Сами по себе омнилайты почти бесплатные сегодня, если не включать тени.
>>1086243
>с каким-то умопомрачительным количеством dc
Выключи тени. Без теней никаких лишних draw call от омнилайтов не будет.
>>1086233
>Это явно делалось средствами гпу
С чего такой вывод? Пару сотен шариков можно и на 20-летнем CPU двигать.
>Это вообще возможно?
Нет. В unity нельзя создать объект/компонент не привязанный к сцене. Это ограничение движка. SetParent(null) меняет родителя на сцену.
>reparent
Это обертка удаления, добавления.
add_child, remove_child не должно быть публичным API. Это плохой дизайн. У узла уже есть родитель, если у тебя есть дочерний узел, то у тебя есть и родитель. Проблема в том, что в remove_child можно передать узел, который не является дочерним, это лишний источник проверок и ошибок. С SetParent это просто невозможно.
Стесняюсь спросить, но уважаемые движкосрачеры вообще в буллет-хеллы играли? Или хотя бы классические сайд-скроллеры с много пыщь-пыщь на экране. Мне просто очень интересно, как движкосрачер с миллионами пулек в секунду представляет себе игрока в свою игру про пульки. Или он не для игроков это делает, а просто чтоб было? Чтоб можно было написать "нашу игру невозможно пройти до конца" в промо материалах? Чтоб игрок отлетал на первой секунде после начала игры?
Я вот, честно, не люблю этот жанр(ы) и никогда всерьёз не играл в них. У меня тупо недостаточно быстрая реакция, и я слишком быстро раздражаюсь из-за своих ошибок. Короче, этот жанр не для меня и делать игру в этом жанре я никогда не буду. И я думаю, что чтобы рассуждать о технических моментах таких игр, нужно быть как минимум хорошим игроком в них, а лучше - быть фанатом жанра. Т.е. только с опытом игры в такие игры приходит понимание, что там должно быть и как. Чужие слова о том, как что-то где-то должно быть, без подтверждения на опыте, ничего не стоят.
Аналогично со всеми остальными gameplay-first жанрами игр. Если вы не умеете играть, не разбираетесь в играх жанра, не любите их как игрок - какой смысл что-то писать о технических нюансах? Вы не сможете сделать хорошую игру в этом жанре, даже если у вас будет бесконечная скорость выполнения кода, бесконечное количество оперативной памяти и бесконечное время на поиск алгоритмов...
>Это обертка удаления, добавления.
Ну да, ты прав, в исходном коде так:
>data.parent->remove_child(this);
>p_parent->add_child(this);
Но это не важно. Потом могут оптимизировать.
>что в remove_child можно передать узел, который...
>>1086516
>если я вызову add_child с узлом, который...
Зачем ты такими вопросами задаёшься вообще?
Накидал тебе схему в пейнте для понимания сути.
>>1086518
>к типу данных "дерева"
"Дерево сцены" - это не тип данных.
Анон, у тебя с головой все норм? Рассказал про свою нелюбовь к жанру, потом ее спроецировал на меня (я тот кто рассказывал в деталях про рейкаст нодой), выдумал себе что-то и сидит довольный. Если что - я буллетхелл привел в качестве всем понятного примера, у меня в игре плазмоган с очень быстрой стрельбой есть как один из видов вооружения, который в виду того, что подразумевает большое число интерактивных проджектайлов, да еще и делается на годоте - требует особого подхода чтобы игра не косплеила хрюкающую собаку, когда таких стреляющих плазмоганов на сцене будет больше 10 штук. Ну а рейкасты это самый дешевый способ проверить коллизию, если нет возможности посчитать коллизию математически (а ее нет в моем случае).
>Зачем ты такими вопросами задаёшься вообще?
Как зачем? Чтобы показать некомпетентность главных разработчиков годота.
Зачем нужно удалять часть дерева, и иметь все связанные с этим проблемы? Что это даст? В unity просто выключаешь флажок активности объекта и все, это то же самое.
>Рассказал про свою нелюбовь к жанру
Я рассказал, что не понимаю этот жанр, потому что не умею/не могу в него играть.
>потом ее спроецировал на меня
Никуда я не проецировал. Просто такое ощущение, что местные срутся об играх, в которые они не играли, не играют и не будут играть. Типа "а вот в симуляторе песка миллионы песчинок - как %движокнейм% это потянет (даже если потянет, делать не буду)?" - в чём смысл такого срача? Напоминает мерянье тупыми бенчмарками, где на реальное качество продукта всем насрать, пока у него больше попугаев на каком-то специально созданном бенчмарке.
>у меня в игре плазмоган с очень быстрой стрельбой
>стреляющих плазмоганов на сцене будет больше 10 штук
Ну вот тут возникает вопрос к тебе: а ты уже пробовал в это играть? Чтобы там было "больше десяти быстро стреляющих плазмоганов"? Или просто нафантазировал и теперь ищешь какое-то супер-оптимальное решение, не сделав даже одного, самого медленного плазмогана?
>рейкасты это самый дешевый способ проверить коллизию
Главная проблема рейкаста в том, что он имеет бесконечно малую толщину. Тебе там нужен как минимум ShapeCast3D со сферой. Но если твои снаряды движутся медленно, то касты могут быть избыточными - они нужны для моментального определения пересечения, а не когда снаряд летит ползёт через пустоту минимум 30 секунд или больше...
>Зачем нужно удалять часть дерева, и иметь все связанные с этим проблемы?
Зачем нужны молотки и гвозди, если можно случайно ударить себя по пальцу?
>Ну вот тут возникает вопрос к тебе: а ты уже пробовал в это играть? Чтобы там было "больше десяти быстро стреляющих плазмоганов"
Скажем так, я не просто пробовал - я залипал в это говно большую часть детства и юности, я понимаю какой геймплей делаю
>Или просто нафантазировал и теперь ищешь какое-то супер-оптимальное решение, не сделав даже одного, самого медленного плазмогана?
Это супер оптимальное решение существует только потому что у годота супер неоптимальный рейкаст через апи. В других движках так ебаться не надо.
>Главная проблема рейкаста в том, что он имеет бесконечно малую толщину
Мне не нужна идеальная точность, снарядики не настолько большие чтобы это имело видимый эффект непопадания, да и шейпкасты достаточно дорогие, без возможности оптимизации относительно длинным лучом для предсказательного столкновения.
>ползёт через пустоту
Еще один. Снаряд не ползет через пустоту, в этой пустоте на пути снаряда в любую секунду может материализоваться обьект, который этот снаряд перехватит, и таких активных обьектов на сцене много.
> В документации Unity данная фича никак не описана, а проверить я не могу.
Пикрил. У тебя не получилось в гугл написать?
> Но ладно, а если нода сделает так сама с собой - кто её возвращать обратно будет-то?
Ну мы тут всё так проиграммисты, поэтому должны понимать, что это не "нода делает сама с собой", а процессор выполняет некий код. Можешь инициировать выполнение этого кода где угодно.
Например ну я не знаю someTransform.SetParent(null), где someTransform это ссылка на нужный нам объект - которыц ты можешь прокинуть через инспектор, или найти на сцене, или при кодов инстансе сразу вытащить из созданного объекта.
То есть в годоте нет флажка деактивации объекта, и чтобы выключить объекты нужны удалять поддерево и где-то его сохранять?
Пока узлы являются частью дерева, их время жизни управляется сценой. А так тебе самому надо подчищать эти узлы. Очередная ошибка архитектуры годота. А все потому, что Хуан - некомпетентный самоучка.
>чтобы выключить объекты нужны удалять поддерево
Всё зависит от того, что ты хочешь "выключить". Есть куча разных способов что-то отключить и обратно включить. Вырезание части дерева просто делает всё сразу, что удобно для прототипирования.
>их время жизни управляется
Ну, в релизной версии ты, конечно, должен всем чётко управлять и не допускать никаких утечек. Но до релиза ты всё равно не доживёшь, а время жизни прототипа не позволяет ему насрать в оперативке слишком сильно. Все потерянные ноды удаляются из памяти после завершения процесса движка.
>>1086541
>Пикрил.
Вот сначала кликни на эту ссылку, прочитай статью, а потом покажи, где там написано, к чему должна привести передача null. Или это такая фишка юнити - догадываться о недокументированном поведении? Которое могут произвольно сломать в следующей версии, ничего не обновив в документации (т.к. там и не было ничего написано до изменений).
>процессор выполняет некий код
Умник, а почему не "электроны толкаются между атомами кремния"?
>Можешь инициировать выполнение этого кода где угодно.
Это признак говнокодера, превращающего код в нечитаемую лапшу.
>>1086538
>неоптимальный рейкаст через апи
Раз ты знаешь, что нужно исправить, почему не исправишь? Исходники открыты и лицензия допускает делать с ними что угодно. Бери и оптимизируй. Потом будешь хвастаться, как ускорил рейкасты в движке в десять тысяч раз и подарил эту оптимизацию всем юзерам движка...
>Раз ты знаешь, что нужно исправить, почему не исправишь?
Потому что это невозможно. Я только иду на ухищрение чтобы значительно смягчить эту проблему, но полностью от нее избавиться невозможно, покуда апи такое смешное.
> Вот сначала кликни на эту ссылку, прочитай статью, а потом покажи, где там написано, к чему должна привести передача null. Или это такая фишка юнити - догадываться о недокументированном поведении? Которое могут произвольно сломать в следующей версии, ничего не обновив в документации (т.к. там и не было ничего написано до изменений).
Всм? Тут абсолютно чётко написано что оно делает - устанавливает родителя. С картинками причем, пикрил.
Если родителем установить никого - значит родителем будет никто. Для дебилов: если родитель никто - например у MainCamera на скрине нет родителя.
> Умник, а почему не "электроны толкаются между атомами кремния"?
Потому что уровень зависит от задачи и скоупа целей. Если мы занимаемся программированием игр на юнити серьёзно, то мы должны понимать что происходит с сишарп кодом в общих чертах, что такое mono и il2cpp, и что попадает на процессор(знание конкретных процессорных инструкций не обязательно).
Если бы у тебя оно было - ты бы не рассуждал сейчас абстрактно о вещах которых не понимаешь в контексте который отношенич к реальности не имеет. Какое нахуй "кто её возвращать обратно будет" - кто придумаешь тот и будет. Охуеть.
> >Можешь инициировать выполнение этого кода где угодно.
> Это признак говнокодера, превращающего код в нечитаемую лапшу.
Гений, тогда абсолютно все это говнокод потому что что угодно попадает под определение "что угодно".
А сколько рейкастов бросаешь?
У меня в 2022 году на Godot 3 без проблем получалось 1200 рейкастов (матрица 40x30) за один тик физики (30 tps) на ядре процессора 2007 года (около 3 ГГц). Использовал только одну RayCast ноду и двойной цикл for на GDScript. Интересно, сколько рейкастов можно сделать на современном ЦПУ в Godot 4?
>что угодно попадает под определение "что угодно"
Гугли "объектно-ориентированное программирование".
>у MainCamera на скрине нет родителя.
По-твоему, SampleScene - это null?
В вебгл где-то 1300 в рамках одного тика 60фпс физики выжал до первых лагов. В нативном клиенте по ощущениям можно высосать раз в 5 побольше, но не проверял. Проц r7 6800h мобильный.
> Гугли "объектно-ориентированное программирование".
Что угодно из ооп попадает под определение что угодно. Харош шизу нести, какой объект тебе надо тот пусть и вызывает код, что за тупые вопросы
> По-твоему, SampleScene - это null?
У тебя в доках написано, что в юнити есть сцены и есть объекты на сценах. Объектов не на сценах нет.
> Раз ты знаешь, что нужно исправить, почему не исправишь? Исходники открыты и лицензия допускает делать с ними что угодно. Бери и оптимизируй. Потом будешь хвастаться, как ускорил рейкасты в движке в десять тысяч раз и подарил эту оптимизацию всем юзерам движка...
Любой действие обуславливается экономикой.
Значит трудозатраты не стоят того, чтобы этим хватсаться и у себя применять - слишком малая награда.
>Объектов не на сценах нет.
есть префабы и scriptable objects
Это префабы и скриптабл обжекст. Тебе что надо? Объект со сцены превратить в префаб или скриптабл обжект?
мне ничего не надо, я зашёл в тред и увидел ложное утверждение
>можно было сделать игру
Можно. Но зачем?
>слишком малая награда
Какая награда нужна в сфере развлечений, где движки делают потому, что это интересно и весело, и игры разрабатывают чисто чтобы пофлексить перед друзьями своими бесполезными творческими навыками?
На всех остальных платформах старый рендер без фич.
Даже и тут наебали.
Ты довольно редкий кейс описываешь, обычно игры делают чтобы народу показать и/или подзаработать.
GLES2 база
годоту надо было оставаться ретро-движком, имитирующим старые игры и развиваться в этом направлении
и не лезть на полянку к старшим пацанам
>На всех остальных платформах старый рендер без фич.
Вщет mobile это тоже forward+, просто это такой форвард который совместим по фичам с gles. За это можешь сказать спасибо говнофонам, которые до сих пор рабочего вулкана не имеют. Гарантированно вулкана нет только в вебе.
mobile и compatibility это одно и то же
https://slicker.me/godot/renderers.html
В статье которую ты скинул мои слова подтверждаются. Мобайл и глес уравнены по фичам, но при этом у вулкана свежее архитектура и он обходит глес по производительности, если есть поддержка этого апи. Все это создано чтобы покрыть побольше устройств (в части которых вулкан хуево или вовсе не реализован и там происходит фоллбэк на глес). Но тебе вообще никто не мешает собрать forward+ билд под любую платформу, просто есть риск что на части мобилок рендер отвалится или будет артефачить из-за того что разрабы конкретного чипа хуево внедрили апи вулкана.
Ну то есть у годота есть одна реальная платформа - ПК. Все остальное нужно "самому компилировать".
Это и значит есть все платформы. Компиляция одной строчкой делается
>На всех остальных платформах старый рендер
Такие жалобы направляй разработчикам GPU.
и только годоти продолжают сидеть на gdscript
годоти тоже хотели c#.
хуан это как злой джин, который выполняет желания таким образом, что становится только хуже.
гейм мейкер вроде бы устроен принципиально иначе чем годот
там нет взаимодействия скрипта с ядром через апи, там gml транспилируется в си и конпелируется в нативный экзешник
ещё есть вариант с выполнением GML в виртуальной машине, я не в курсе как это устроено
что в словочетании "ПОДДЕРЖКА платформы" тебе не понятно? пердолька, которую надо компилировать, это не поддержка.
по факту годот поддерживает одну платформу, остальное это поддержка уровня "у меня все 3 года назад работало, компилируйте и решайте проблемы сами".
это будет не полноценный C#, можно только вызывать методы из C# библиотек из скриптов.
>пердолька, которую надо компилировать
Не надо там нихуя компилировать. Просто берешь и без задней мысли собираешь билд через экспорное меню forward+ на любую платформу с вулканом, включая мобилки. Даже фоллбек на глес будет работать. Впрочем, если ты ссышься компилировать годот - то тебе нужен баринский движок, в котором все уже есть и скомпилировано заранее.
годоти не хотели C#
C# хотели юнитидети которые сбегали на другой движок
ну им и кинули гоавняшку чтоб игрались
нормальные (нормисоблядские) языки не нужны в геймдеве и больше вредны
пример юнити это показывает там урезаный C#
в годоте есть лучший язык (c++)
никакого словосочетания "поддержка платформы" в предыдущих сообщениях не было, ты начал маняврировать
то что ты описал это обычное поведение любого софта
буквально единицы софта в мире гарантируют строго математически какое то поведение через пруверы
любая юнитя точно так же вывалит тебе какой то билд который однажды где то возможно запустился, а сколько в нем еще багов никто не знает. а если ты им напишешь они с большой вероятностью пошлют тебя с пометкой wont fix
показывай официальную позицию хуана, где он утверждает что C# - какашка и что его заставили некие юнити-дети
иначе это выглядит как нелепый копиум фанатичной годособаки, которая не может признать обсёр своего хозяина и поэтому выдумывает оправдания за него
нелепый - потому что ты утверждаешь что какие-то неведомые "юнити-дети" из-под кровати влияют на хуана
в годоте нет с++, а в юнити есть буквально все языки планеты
тупая юнитишавка проецирует про хозяев
в опенсорсе нет хозяев, тут каждый хозяин кода и движка на своем компе
>в годоте нет с++
пей таблетки
у меня несколько игр выпущено на годоте с логикой на c++
ничего у тебя не выпущено, фантазёр
ты круглосуточно ИТТ сидишь простыни катаешь в защиту своего рыжего кумира
типичное врети безыгорника
тем временем я выбираю новую квартирку
юнити могила
как обычно, не вывез дискуссию и перешёл на оскорбления, как истеричная баба
тебя для этого в этот тред и сослали, чтобы тебя унижали
анонимное пустое место, которое само себя не уважает, не способно никого унизить
очень хорошо что ты представился, пустое место
ты сам первый перешел на личности, >>1086663
вот и обтекай теперь
ну тут как раз выступали в защита годот как раз из-за "поддержки" платформ, и что все будет просто работать. а теперь оказывается поддержка это не поддержка.
да всё равно, слабый не слабый
главное что деньги юзера пойдут на гейм мейкер, а не на донаты в годот
ни копейки рыжему скамеру
говняшку кинули microsoft, в виде взятки за добавление C# в годот. так как нужно было отрабатывать говняшку, то C# добавили самым тупым способом, какой легче было реализовать без переделки движка.
годот не нуждается в защите
ты беззубый и напасть не можешь
Хуан написал миллион строк кода и подарил человечеству, в чем скам?
Ни разу не донатил Хуану, но обмениваюсь кодом с другими годотерами, богатеем вместе взаимопомощью
https://www.reddit.com/r/godot/comments/1sz7ike/c_multithreading_experiment/
какая разница сколько там строк, если результат - никакой. разработчики движка и фанаты занимаются агрессивной рекламой, рассказывая что годот это лучший бесплатный движок, хотя это не так. из-за чего другие более достойные движки с более достойными разработчиками не получают поддержку.
да, это обман в каком-то смысле. это типа как корпорация teranos, которая обманывала инвесторов. за такое судят.
ну вот смотри, тут годотя поддерживает скам с имитацией добавления C# который "нинужен" и сделан для обмана "юнитидетей" >>1086683
пример с C# показательный. они поспешили добавить язык для галочки, чтобы потом трубить что у них в движке C#, как в unity. они где то говорят о производительности (вернее, ее отстутсвии), или о нюансах их реализации C#? конечно же нет. что это, если не обман?
честный разработчик не стал бы так поступать, не стал бы добавлять язык таким способом, который делает его непригодным для использования.
они сделали это с одной целью: пустить пыль в глаза, обмануть пользователей.
Результат заебись, есть отличный движок который скачиваешь и делаешь игру через 5 минут.
Это объективно лучший движок по совокупности. Искали всем тредом, никаких более достойных не нашли. Если в каком то движке одна фича лучше, то десять других отстутствуют и так далее.
C# для юнитидетей это просто переходный период чтобы они выучили АРИ на знакомом им языке и потом пользовались этим апи в гдскрипте.
>Если в каком то движке одна фича лучше, то десять других отстутствуют
>десять других
Хуана во всем треде вспоминаешь только ты. Я с ним вообще никогда не общался даже.
причём тут общение? хуан автор годота, вот тебе и причинно-следственная связь
оправдания годоту = оправдания автору
никаких юнитидетей не существует
дети могут учить что угодно, у них голова пустая
а я не могу перейти на годот, потому что у меня накопилась кодовая база на C#, не привязанная к API Юнити
я было обрадовался, когда узнал о введении C# в годоте, но это оказалось скамом, как и всё остальное, что обещал аргентинский мавроди
>я было обрадовался, когда узнал о введении C# в годоте, но это оказалось скамом
Делаю игру на с#, все заебись. но двигло 3.6.2
Зря ты ему это написал, сейчас этот лох неудачник опять начнет ныть что у него одного ничего не получается поэтому все вокруг виноваты.
ты бы не таким самоуверенным, если бы знал какую "игру" он "делает".
Делаю игру моего детства, и игру детства еще пары сотен тысяч школьников моего возраста
>но двигло 3.6.2
а что, там нет типа variant и нет пропуков?
>а что, там нет типа variant и нет пропуков?
Вариант на данный момент смертельно может влиять только при рейкастинге апишкой. Есть еще кое-какое проблемное апи, но я его не юзаю. Формально - апи страшное с точки зрения аллокаций. По факту - если на горячем пути зная проблемное апи - не злоупотреблять им (инпуты с stringname, рейкасты, getnode/add/remove) - пропуков по вариант апи не будет.
Но у godotphysics есть болевая точка - коллайдерную геометрию для активных ригидов нужно собирать из примитивных коллайдеров, если генерировать выпуклыши - при коллизии друг с другом они даютхрюкающую собаку (думаю именно это и было причиной тех ебейших пропуков на видосе). Но конечно можно юзать bullet/jolt и такой проблемы не будет, но мне нужна годотфизика.
>>1086721
Увы, как раз наоборот - юи даже не начинал
>думаю именно это и было причиной тех ебейших пропуков на видосе
Ты угораешь? Там у чела просто видозахват тормозит на некропеке 20 летней давности.
Если ты имеешь в виду годотфизику в 3-ке, то ни в коем случае ее не юзай. Ах да, ты шиз который не слушает советов.
он в коментах отвечал что не тормозит
видеозахваты фильмов на его канале нормально работают
там множество коллайдеров и ригибоди в сцене
Видеозахват фильмову него точно так же тормозит
https://www.youtube.com/watch?v=2WU19oJD5qY
Впрочем от тебя пиздаболки другого и не ожидалось
это годот тормозит, баран
вон топовое видео на канале без годота
Нахуя мне советы безигорных? Кстати советую тебе начать делать игры бтв
интервью с дедулей
> Кстати советую тебе начать делать игры бтв
Мне то зачем советы безыгорника с гта омск. А свои игры я уже все релизнул, мне уже можно и ничего не делать больше.
больно и жалко смотреть на этого деда, на виндоус 98 что-то набивает руками на мёртвом опенгл, кому это нужно в текущем году?
>интервью
Спроси его почему он уязвимости в stb либах отказывается чинить
Ты очень классный
Ты самый лучший кодер движков
Твои идеи самые крутые
>у меня накопилась кодовая база на C#
Если бы ты был настоящим программистом, то ты бы понимал, что переписать "кодовую базу" с одного императивного ЯП на другой императивный ЯП - это настолько просто, что даже тупая программа может справиться (называется транспайлер), то есть даже интеллекта для этого никакого не нужно. А уж в эру искусственного интеллекта твои жалобы на якобы неправильный язык кодовой базы вообще смешны.
Перепиши следующий код
Classobject.gettype().methods.where(x => x.name.contains("zalupa")).foreach(x => x.invoke(Classobject))
На плюсы. Разрешаю использовать любые нейронки.
Ахах
Я бы посмотрел на транспайлер C#2GDS
Оцениваю в 10 человеколет разработки.
Зачем такую шизофрению с рефлексией переписывать? Такому место в мусорке.
Пиши нормально - нормально будет.
Тебя никто не заставлял хуевертить неоптимальный, медленный, раковый код, который еще и оказался неперносимым вендорлокнутым, кек.
В разработке есть принцип использовать разумное подмножество языка, понятно что это в первую очередь выгодно в командной разработке и принцип появился еще во время c++, потому что там то как раз можно много DSL наплодить макросами и все друг друга перестанут понимать
>Тебя никто не заставлял хуевертить неоптимальный, медленный, раковый код, который еще и оказался неперносимым вендорлокнутым
А еще каким-то образом частично оказался в 26 стандарте плюсов. Но ты продолжай свято есть устаревшее неудобное говно применять разумное подмножество функций языка, ведь писать вместо одной строчки пятьдесят - это разумно и переносимо.
у меня действительно примерно так и реализована система взаимодействия с interactable объектами, только сравнения со строкой нет
Очевидное лицемерие, если бы тебя интересовала короткая запись строки ты бы кодил на J или APL каком то
там этот поляк собрал целую кодлу вышедших в тираж старых пердунов
кто-нибудь, расскажите дедам про AI агентов и spec-coding. им пора на свалку истории достойную пенсию
Зумерок какой то
Вот олд лайвкодит
https://www.youtube.com/watch?v=3l4OLh2LtPk
да, это оказалось неоправдано
у меня по задумке было неограниченное количество глаголов для взаимодействия с объектами, но в конце концов всё свелось к банальным "посмотреть", "взять", "открыть" и т. д.
но поздно переписывать, надо идти вперёд, как хуан
>Classobject.gettype().methods.where(x => x.name.contains("zalupa")).foreach(x => x.invoke(Classobject))
Я не разбираюсь в C# и не знаю, что ты называешь "Classobject", но вот код на GDScript:
>for x in object.get_method_list().filter(func(x): return "zalupa" in x.name): object.call(x)
Или можно сделать проще (читабельнее), т.к. мы всё равно не сохраняем массив:
>for x in object.get_method_list(): if "zalupa" in x.name: object.call(x)
На C++ такой код писать глупо, конечно. Попахивает лапшичной архитектурой твоего проекта.
>>1086754
>неоптимальный, медленный, раковый код
А вдруг ему приходится работать с древним легаси? Тут скорость не важна - лишь бы работало...
>оказался неперносимым вендорлокнутым
Нет, создать что-то такое можно на любом языке, даже самом древнем. Но нужно ли?..
>>1086755
>писать вместо одной строчки пятьдесят
А что ты там пытаешься сделать, что тебе нужно вызывать все методы, содержащие одно слово?
Это, кстати, смешной исторический баг, который нашли в одной настолке в 2000-е.
Там добавили способность, которая была сформулирована примерно так же - "если в названии чего-то есть zalupa, то ее мощность удваивается".
По замыслу, это работало на tonkaya zalupa, tolstaya zalupa и т.д.
Вот только, строгое прочтение, матчит все, как: vokzaluparka - теперь у игрока два воказала, linzalupa - теперь удвоенный бинокль
Не используйте матчинг строк без нужды в геймдеве, господа.
У годоти от боли и унижения помутился рассудок. Геймдев не слабых духом.
Кажется, ты тоже прикольный парень, думаю и игры у тебя интересные.
прекращай заигрывать с парнями ИТТ, ты выбрал не тот раздел
Ты как-то извращенно все понял, у меня вообще-то жена есть.
А что не так? Ты же сам хотел, чтобы в ИТТ тебе не грубили.
Чел я в целом на твоей стороне в диалоге выше, но это полный пиздец.
Такой код недопустим в реальной игре и с точки зрения перформанса и с точки зрегия поддержки.
Справдливо возразить - критикуешь- предлагай - а я и предложу - кодогенерацией абсолютно та же задача отлично решается без недостатков.
>не знаю, что ты называешь "Classobject"
Инстанс обьекта некоего ссылочного типа
>но вот код на GDScript:
Анон, я отлично знаю как такие фокусы делаются в нетипизированном говне, где любой ссылочный "обьект" это по сути хэшмап, который можно перебрать. Но речь идет о нормальных языках, производительных, с настоящей типизацией. К которым сверху прикручена рефлексия, которая может сыграть некоторую роль в архитектурных решениях. И в этих языках - данные рефлексии можно кешировать (например на старте один раз выделить рефлексией разные группы методов, сохранить Method ссылки в коллекции, а затем их очень дешево инвокать, мотому что методы - часть типа, а не часть обьекта), в отличии от.
>На C++ писать глупо, конечно.
Поэтому я выбираю с# для скриптов, ведь на с++ писать глупо. Хотя, мейби с вводом в строй 26 стандарта - я еще разок к плюсам присмотрюсь, конечно, всех фич шарпа это не покроет, но некоторую критическую их часть - возможно.
>А что ты там пытаешься сделать, что тебе нужно вызывать все методы, содержащие одно слово?
Это просто пример. В боевых проектах я использовал рефлексию чтобы:
Автоматически генерировать инстансы для типов, которые наследуют определенный тип.
Прописывать данные в статические поля классов (костыль но работал).
Свой deepclone.
Для вызова конфигурируемого файловой конфигурацией поведения обьектов(пикрил) и ресолва методов.
Бесчисленное Object.gettype для любых целей.
Примерно такой список, который невозможно реализовать на плюсах.
>>1086788
У меня нет задач под кодоген, так как я не использую рефлексию на "горячем" пути, либо кеширую ее результаты. Разумеется вот того кода у меня в рабочих решениях нет, но его некоторые части присутствуют.
очень просто. используешь https://github.com/xoofx/CppAst.NET и создаешь source generator на минималках
> У меня нет задач под кодоген, так как я не использую рефлексию на "горячем" пути, либо кеширую ее результаты.
Эквивалент того пиздеца что ты скинул пишется кодогеном.
>Эквивалент того пиздеца что ты скинул пишется кодогеном.
Нахуя он им пишется, а главное зачем? Чтобы что? Ты экономишь один проход генерации кеша и ради этого ебешься с генераторами кода? Мысль конечно интересная, но мне не платят за строчки кода, даже хуже, мне ни за что не платят кроме работающей игры, а написание генератора кода на любой чих только отдаляет меня от релиза и генерирует сложность, которая мне без надобности.
> Нахуя он им пишется, а главное зачем?
Для оптимизации и усложнения регресса(с рефлексией ты свое говно сможешь сбилдить и запустить даже если сломал его, а с кодогеном все компайл тайм)
>Для оптимизации
Видимо оптимизации доступного мне времени на разработку, потому что перфоманс импакт мизерный по меркам поставленной задачи.
>усложнения регресса
Тесты писать заратустра не позволяет? И как меня спасет компилируемая природа генератора от ошибок генерации, когда генерируется не всё? А если нужно покрывать тестами в обеих случаях - зачем мне, как инди разрабу с крайне ограниченными ресурсами - платить больше?
> Видимо оптимизации доступного мне времени на разработку, потому что перфоманс импакт мизерный по меркам поставленной задачи.
А ты проверял?
> Тесты писать заратустра не позволяет?
>>1086815
> но мне не платят за строчки кода
Nani!?
>Но речь идет о нормальных языках, производительных, с настоящей типизацией. К которым сверху прикручена рефлексия
Твой высер с поиском по тсроке не имеет отношения ни к типизации, ни к производительности.
>А ты проверял?
Что проверял? Что написать генератор это неоправданный гемор, высеры которого потом придется дружить с абстракциями кодовой базы? Конечно проверял. А если речь про закэшированные данные - единственный импакт это ресолв данных кэша по ключу, который можно дополнительно скомпенсировать используя frozen коллекции, потому что инвок methodinfo запакованный в делегат (через createdelegate) практически аналогичен прямому вызову.
> Что написать генератор это неоправданный гемор
Я не понимаю и не умею = гемор? Так мб научиться можно.
> высеры которого потом придется дружить с абстракциями кодовой базы
Чел у тебя буквально вызов метода по названию какие нах абстракции, это даже банальным интерфейсом решается.
Да, вот жаль его, вроде бы достаточно умный, еще немного бы подучился нормальным практикам - и делал прекрасные игры, а так, закапывает себя в багодром.
>Я не понимаю и не умею?
Сам придумал сам разьебал. Да хочешь - пиши, я понял что ты сторонник вместо использования готовых инструментов - страдать хуйней ради непонятно чего. Мне такое не надо, я не для того использую лучший язык на планете чтобы вьебывать свое время на хуйню.
>Чел у тебя буквально вызов метода по названию какие нах абстракции
>это даже банальным интерфейсом решается.
Интерфейс не абстракция? Как минимум обмазывать интерфейсами класс придется ручками, и методы вкидывать в интерфейсы тоже ручками. Добавить новый метод = добавь интерфейс с методом, накинь. Все ради того чтобы... ай блять, ведь мы же все равно будем резолвить нужный интерфейс через пару ключ-значение (строка -> интерфейс), надо же, мы сэкономили целое нихуя. Ну, еще получили немного компайлтайма, который опять таки гарантирует целое нихуя, если нет уверенности в корректности работы генератора.
> я понял что ты сторонник вместо использования готовых инструментов - страдать хуйней
Как именно ты это понял? Я тебе говорю почему конкретная практика программирования говно.
Готовые инструменты я использую по полной, если тебе интересно.
> чтобы вьебывать свое время на хуйню.
Так ты его въёбываешь на поддержку говнокода.
> Интерфейс не абстракция? Как минимум обмазывать интерфейсами класс придется ручками, и методы вкидывать в интерфейсы тоже ручками. Добавить новый метод = добавь интерфейс с методом, накинь.
Да что ты черт побери такое несёшь.
Нахуя писать вот это
> Classobject.gettype().methods.where(x => x.name.contains("zalupa")).foreach(x => x.invoke(Classobject))
Если можно
classObject.Zalupa()?
Если там несколько методов нужно у которых в названии zalupa, то почему бы не
GetDolbloebskoeGovno<IZalupa>().zalupa(classObject)
?
При этом мы можем сделать место где будем регать разные имлементации IZalupa с методом zalupa принимающем наш тип, и соответственно все они будут вызываться по строчке выше.
И уже это будет более менее нормальный код с которым можно сделать игру, а не прототип про кубы.
Нахуя ты вообще берешь шарп со строгой типизацией еслт она тебе наэ не нужна? Бери жс тогда.
А, так ты другой анон, вообще отрицающий рефлексию. Я тебе уже все написал про 26 стандарт плюсов все написал. Тебе я тоже не запрещаю хуйней страдать, дрочи свои интерфейсы пока я написал 30 строчек с кешированием и пошел дальше.
Почему отрицающий? Рефлексия норм тема, но её надо юзать там где надо. Твой пример юза - какой то кал.
> Я тебе уже все написал про 26 стандарт плюсов все написал.
Не мне.
>Твой пример юза - какой то кал.
Сообщает мне это человек, который исполняет это
>Если там несколько методов нужно у которых в названии zalupa, то почему бы не
GetDolbloebskoeGovno<IZalupa>().zalupa(classObject)
?
>При этом мы можем сделать место где будем регать разные имлементации IZalupa с методом zalupa принимающем наш тип, и соответственно все они будут вызываться по строчке выше.
Мой пример использования рефлексии описан здесь
>>1086797
То что я изобразил с поиском по вхождению строки в имя метода - просто пример, прикол, рофл, чтобы показать терпильность плюсовиков. Разумеется, таких подходов я не применяю.
> Автоматически генерировать инстансы для типов, которые наследуют определенный тип.
Если активатор креейтинстанс то ок в каких то инфраструктурных штуках.
> Прописывать данные в статические поля классов (костыль но работал).
Нахуя статические поля в классах? Нахуя туда прописывать рефлексией что то?
> Свой deepclone.
Зачем для этого рефлексия, чтобы это супер доррго было? Что ты там вообще клонируешь клонировщикс?
> Для вызова конфигурируемого файловой конфигурацией поведения обьектов(пикрил) и ресолва методов.
Где тут нужна рефлексия? Прост какая то структура данных сериализована, которые ты видимо десериализуешь рефлексией. Но рефлексия для этого не нужна.
> Бесчисленное Object.gettype для любых целей.
Звучит супер сомнительно, я как тоже любитель упороться в метапрограммирование не юзаю почти никогда.
>>1086839
> То что я изобразил с поиском по вхождению строки в имя метода - просто пример, прикол, рофл
Так а чё ты тогда споришь? Я говорю - это пиздец. Ты в ответ какую то шизу несешь вместо того чтобы сказать - это рофл просто демонстрационный пример.
Рефлексия это шизофрения, типа ты забыл какие типа у тебя в программе и что они умеют и пытаешься нащупать вслепую.
Выдумали ее в кровавом интерпрайзе, какие то гении выдумали хуиту что один банк в другой присылает SOAP прям с неведомым кодом, и надо угадать что тот код вообще умеет. Короче совершенно ненужна в полностью контролируемом окружении в геймдеве.
>То что я изобразил с поиском по вхождению строки в имя метода - просто пример, прикол, рофл, чтобы показать терпильность плюсовиков
Поэтому то тебе сразу и сказали что это надо выкинуть и переписать, а ты начал истерить про НИНУЖНО, так что молодец, ты наглядно опроверг терпильность плюсовиков.
>Зачем для этого рефлексия, чтобы это супер доррго было?
Ну скажем так - бывает надо. Клонировщик на базе рефлексии просто самый простой в исполнении и позволяет делать кое-какую магию.
>Нахуя статические поля в классах? Нахуя туда прописывать рефлексией что то?
Чтобы например вшивать значения из атрибутов в статику конкретного класса. Типа, чтобы не опрашивать атрибуты типа в рантайме, а получить их сразу по статическому полю. Тоже надо.
>Где тут нужна рефлексия? Прост какая то структура данных сериализована, которые ты видимо десериализуешь рефлексией.
Проявил бы больше уважения к собеседнику. Я например твои высеры от и до читаю. И ты, если бы немного дольше удержал зрение на картинке, то заметил бы, зачем там может понадобиться рефлексия, в частности вызов методов по их имени и сопоставление типов с их строковыми представлениями. Вообще конечно пиздец, с кем я говорю, ты же даже yaml формат не видел никогда, иначе бы шизобред про десериализацию рефлексией не писал бы.
>Так а чё ты тогда споришь? Я говорю - это пиздец. Ты в ответ какую то шизу несешь вместо того чтобы сказать - это рофл просто демонстрационный пример.
Я это сразу сказал, еще в том посте, который кинул выше. Просто я думал претензии к моим рабочим применениям.
Купи себе подписку на дипсик, у него и то контекст больше и умишка побольше, пусть думает что постить за тебя
У тебя типичный Даннинг-Крюгер. Уныло это все, конечно, лет через 10 наверное до тебя начнет доходить, хотя скорее всего и тогда не дойдет.
>лет через 10
Брух, уже лет через 5 я скорее всего даже иде открывать не буду, будет какой-нибудь AIDE, где я тупо через бота пишу спеки и оно мне рожает фичи, и раз в пару дней запускаю autorefactor чтобы зачистить техдолг. А может, буду вообще безработным бомжом, который будет просить милостыню под дроидпарком
а может через 5 лет ты будешь писать на ассемблере, чтобы сэкономить 32 КБ памяти
технологии не всегда идут вперёд, прогресса не существует
>типа ты забыл какие типа у тебя в программе и что они умеют
да забыл
хорошо, что есть рефлексия
> Чтобы например вшивать значения из атрибутов в статику конкретного класса. Типа, чтобы не опрашивать атрибуты типа в рантайме, а получить их сразу по статическому полю. Тоже надо.
Статика это минус вайб плюс ограничения. Статики в коде быть практически не должно, только в медиаторах с движковой или сдкшной частью где она уже есть либо иначе никак. А также в инфраструктурных штуках, которые иначе не сделать. У тебя получается класс сразу подвзяан на какие то данные и нету 2 инстансов с разными данными. Куда ж это годится?
> Проявил бы больше уважения к собеседнику. Я например твои высеры от и до читаю.
Я полностью прочитал все что ты мне написал и все на что сослался.
> И ты, если бы немного дольше удержал зрение на картинке, то заметил бы, зачем там может понадобиться рефлексия, в частности вызов методов по их имени и сопоставление типов с их строковыми представлениями.
Вопрос всё тот же - почему рефлексия здесь необходима? Это точно не решается без рефлексии?
И всё также - нахуя брать строго типизированный сишарп и максимально отпиливать от него типизацию? Вызов метода по имени из конфижного текстового файла это пиздос и источник поломок на многие месяцы вперед. Причём неявных поломок, которые ты ещё хуй найдешь.
> Вообще конечно пиздец, с кем я говорю, ты же даже yaml формат не видел никогда, иначе бы шизобред про десериализацию рефлексией не писал бы.
В юнити префабы и сцены не yaml? Как считаешь, то что с ними творится можно назвать сериализацией и десериализацией? Я считаю да, это она и есть в самом чистом виде.
> ты
Кстати я выше хоть раз написал "ты"? По моему я комментировал только твои высказывания.
> Я это сразу сказал, еще в том посте, который кинул выше. Просто я думал претензии к моим рабочим применениям.
Значит я неправильно тебя понял, потому что ты писал что его части присутствуют.
К твоим рабочим применениям вопросы тоже появились, потому что примеры что я увидел это не то что "ну хз может ок" а чето совсем куда-то не туда, как мне кажется. Слишком легко ломаемое, слишком плохой перформанс, ну если у тебя .net core вместо юнити то там рефлексия подешевле и признаю хз насколько.
> Брух, уже лет через 5 я скорее всего даже иде открывать не буду, будет какой-нибудь AIDE
Я полгода так уже
>чтобы сэкономить 32 КБ памяти
Меня не возьмут в бункер, в этом мире и так порядочно людей которые заслуживают эвакуации в убежище 101 больше чем я и многие другие, потому до твоего варианта я не доживу
Ну я вот с клодиком щас проектирую один любопытный бэк на джаве с хитрой rls, увы, чтобы довести диздок до ума и синхронизировать фичи - я потратил прям немало токенов, пару недельных лимитов прошки точно, с полным сопровождением с моей стороны. И это только на диздок. Так что пока не верю в такой расклад, но потенциал виден серьёзный.
>>1086851
>Куда ж это годится?
Мне годится, потому как эти данные это разного рода статические идентификаторы привязанные к конкретному типу, и очень удобно получить их без typeof. Полный плюс вайб.
>И всё также - нахуя брать строго типизированный сишарп и максимально отпиливать от него типизацию?
Где ты увидел максимальное отпиливание? Я углы срезал.
>Это точно не решается без рефлексии
C# настолько хороший язык, что можно хоть на каждый конфигурационный файл такого рода насрать кодогенерацией, или использовать il генерацию, или вообще деревья выражений ебануть, можно даже захардкодить все свичами, но я предпочитаю вариант попроще, попонятнее, побыстрее в реализации.
>Вызов метода по имени из конфижного текстового файла это пиздос и источник поломок на многие месяцы вперед.
Что именно ты видишь источником для поломок? Ну назови просто, при каком варианте я, если задамся целью обеспечить стабильность работы через механизм рефлексии - ну никак не узнаю что обьект не реализовывает метод, или что обьекта не существует? Валидация механизма умещается в 1 тест, который прогонит все конфиги. Конечно, ты можешь сказать - "рефакторинг сломает связь" и будешь прав. Но от рантайм беды меня убережет буквально 1 простейший тест, который прогонит конфиги и их зависимости. Это каким-то значительным образом отличается от компалйтайм ошибки, когда сгенерированный код ссылается на невалидное поле/метод? По моему-никаким значительным образом не отличается. А еще - я могу менять эти конфиги непосредственно при исполнении приложения, что выгодно их отличает от хардкода еще и в таком аспекте.
>В юнити префабы и сцены не yaml? Как считаешь, то что с ними творится можно назвать сериализацией и десериализацией? Я считаю да, это она и есть в самом чистом виде.
Я сильно сомневаюсь, что значения yaml сериализатор ставит рефлексией, по крайней мере net либа yaml сериализации использует деревья выражений, что по факту является кодогенерацией.
>Слишком легко ломаемое, слишком плохой перформанс
Который ты придумал и свято в него веришь. Еще раз - рефлексия применяется у меня единожды для каждого отдельно взятого случая применения. Затем - я использую кеш и скомпилированные делегаты, что приводит к тому что я не использую рефлексию ни для чего, кроме построения кеша, который затем является основой для отработки логики.
>в нетипизированном, где любой ссылочный обьект это хэшмап
>нормальных языках, производительных, с настоящей типизацией
Насколько я понимаю, C# (.NET) является языком наподобие Java (JVM). Т.е. у него все те же проблемы тяжёлой виртуальной машины с ненастоящей типизацией и ненастоящими объектами, которые есть в любой виртуальной машине. Unity Technologies создали свой форк C# с урезанным функционалом, чтобы костылями заделать эти проблемы, но вышло как всегда - "deprecated prealpha" или как они там свои технологии называют...
>в этих языках можно кешировать
Кэширование доступно любому языку, это не зависит от способа выполнения (хоть камешками на песке выкладывай состояние виртуальной машины на 1-мерном клеточном автомате).
>затем их очень дешево инвокать, потому что методы - часть типа
В Godot 4 на GDScript тоже есть тип Callable, который можно хранить в переменной и очень дёшево вызывать (дёшево относительно поиска по строковому имени). Но это не касается темы.
>Поэтому я выбираю с# для скриптов
Т.е. ты признаёшь, что C# - это скриптовая фигня?
>мейби с вводом в строй 26 стандарта
Внутренности Godot пока что на C++ 17 кроме одной папки с Windows, которая на C++ 20 теперь:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/#windows
>...this integration would’ve only been feasible in C++20, whereas the Godot codebase uses C++17 at time of writing.
>...isolate the relevant Windows code to C++20, while keeping the rest of the codebase untouched.
Я на 99% уверен, что они не обновляют версию C++ ради стабильности. Потому что новые версии, как обычно, нестабильное говно, которое некому всерьёз тестировать. Ну а Unreal Engine вообще не настоящий C++ использует, а какой-то там специально сделанный форк (как и костыль-C# в Unity).
>я использовал рефлексию чтобы: ... Примерно такой список
Ты отдаёшь себе отчёт, что компьютерные игры создаются людьми более 60 лет, и всё тобой перечисленное в 99.9999% играх не требовалось и не использовалось? Тебе никогда не кажется, что ты делаешь что-то лишнее, избыточно усложняя то, что можно было сделать намного проще? Интересно даже, какие такие игры ты делаешь, что ты вынужден прибегать к подобным "трюкам" (фактически - грязным хакам, которые едва держатся и могут отлететь в любой момент).
> Т.е. у него все те же проблемы тяжёлой виртуальной машины
Какие
> с ненастоящей типизацией и ненастоящими объектами, которые есть в любой виртуальной машине.
Что это блять значит? Что такое настоящий тип и ненастоящий?
> чтобы костылями заделать эти проблемы
Какие проблемы? Перечисли.
Ах да сразу вкину - моно они взяли не чтобы что-то заделать, а для кроссплатформенности в те времена.
>Насколько я понимаю
Плохо понимаешь, хз как там в джаве, но NET уже очень давно jit-компилируемый язык, прям супер давно.
>ненастоящей типизацией
Все настоящее. Можешь простые бенчи посмотреть, произвидительность на всяком бэнчмарк говне сравнима с плюсами. В реальных кейсах, с gc да со всякими баундсчеками конечно не то пальто будет, но сильно побыстрее интерпретируемого говна от хуана.
>Кэширование
Брух, ну куда ты лезешь. Ну не знаешь ты с# и о каком конкретно кешировании речь - зачем влезать в разговор со своим особо ценным
>тип Callable
Это годотовский делегат, и он к теме обсуждения никаким боком не относится
>Т.е. ты признаёшь, что C# - это скриптовая фигня?
C# настолько хорош что ты на нем можешь писать что угодно, лучшее тому доказательство - существование Xenko/Stride. Собственно и как скриптовый язык, у которого за спиной вагон библиотек для хайлоад энтерпрайза - он тоже отличный.
>Тебе никогда не кажется, что ты делаешь что-то лишнее, избыточно усложняя то, что можно было сделать намного проще?
Оно кажется сложным, только когда я подсвечиваю сложности. Код, который я пишу благодаря этим "грязным хакам" - получается очень простым, легко поддерживаемым, легко понимаемым, и не слишком сложно тестируемым. Я просто фокусник, который любит попиздеть о том как я на самом деле "распиливаю" человека или достаю кролика из шляпы.
>Какие
Попробуй как-нибудь написать виртуальную машину на досуге. Только сначала почитай про устройство процессора, как он взаимодействует с оперативной памятью и т.д. Интересная тема, каждому программисту стоит ознакомиться, даже если ты веб-мартышка. Конечно, старые популярные виртуальные машины сильно оптимизированы, но есть фундаментальные проблемы, которые просто нельзя исправить.
>Что такое настоящий тип и ненастоящий?
Почитай обсуждение. Там анон говорит, что C# якобы лучше, потому что он "настоящий".
>моно они взяли
Речь про ill2cpp/burst или как оно там называется. Мутная тема. По сути это транспилятор "C# у нас дома" -> "C у нас дома", или что-то такое. Лучше бы они вернули в движок тот скриптовый язык, который у них был когда-то... как его называли, UnityScript? Что-то наподобие "JavaScript у нас дома". Большинству ассетфлипов на Unity нет никакой необходимости выходить за рамки JavaScript.
>jit-компилируемый язык
Значение знаешь? JIT - "Just In Time compilation" - "компиляция в последний момент". То есть, представь себе паровозик, который укладывает рельсы прямо перед собой - сначала доски, потом обрезки рельс, потом болты вкручивает, проезжает 1.5 метра вперёд и укладывает новые доски - вот это и есть "JIT компиляция". Преимущество JIT в том, что один и тот же код выполняется на разных платформах - представь, что у паровозика разные типы досок и рельс, которые он выбирает в зависимости от грунта впереди дороги. Недостатки сам понимаешь.
>существование Xenko/Stride
Да? И почему ты сидишь на гнилом (deprecated) Unity, а не на стильном-модном-молодёжном Stride?
>вагон библиотек для хайлоад энтерпрайза
Это не для твоих игрушек написано...
>очень простым, легко поддерживаемым, легко понимаемым, и не слишком сложно тестируемым
Придётся поверить тебе на слово, потому что доказать ты всё равно не сможешь (игор-тонет)...
> Попробуй как-нибудь
Забавно, но это именно то, что тебе стоит посоветовать.
Тип - это чисто компайл тайм понятие. Рантайм мы просто читаем память по какому то адресу и чето с ней делаем.
Разве что ссылка на vtable(и в случае c# более) в заголовке класса это единственный огрызок от типов что остается в рантайме.
Нет типов настоящих и ненастоящих.
> Почитай обсуждение. Там анон говорит, что C# якобы лучше, потому что он "настоящий".
Я хз кто че говорит, я твое сообщение прочитал и ты термин юзал.
> Речь про ill2cpp/burst
А это они взяли чтобы перформанс вытягивать, а не чтобы что-то там чинить.
> Большинству ассетфлипов на Unity нет никакой необходимости выходить за рамки JavaScript.
Есть. Я слабо представляю даже простую игру на жс. Игры довольно сложные и важно чтобы кодовая база была устойчива к изменениям без поломки половины игры.
>Недостатки сам понимаешь.
Недостатки, я так понял, заключаются в том что у jit есть адаптивная оптимизация, а у aot ее нет. Но это трудно назвать недостатком, я бы даже сказал наоборот, это полный достаток. Впрочем - у c# уже очень давно есть АОТ компиляция, для тех кто хочет честную производительность.
>Да? И почему ты сидишь на гнилом (deprecated) Unity
А вот и не угадал. Я сижу на godot 3.6 mono. Stride просто пример, где движок полностью c#, без плюсового ядра.
>Это не для твоих игрушек написано...
Это написано для тех, кто знает как применить то что написано
>Придётся поверить тебе на слово, потому что доказать ты всё равно не сможешь
Уже бегу показывать ключ от квартиры где деньги лежат двачерским дегродам, для такой аудитории ничего не жалко
Пипец, с какими шизофрениками в одном треде сижу...
Даже страшно становится, какие вы там игры-то делаете?..
>Тип - это чисто компайл тайм понятие.
>Нет типов настоящих и ненастоящих.
Сразу видно человека, который никогда не интересовался устройством процессора, не пытался писать код на ассемблере, и не разбирался, почему новейший быстрый процессор может оказаться медленнее в задаче, с которой легко мог справляться более старый, более медленный процессор. Сам концепт "типизации" возник лишь благодаря тому, что он глубоко зарыт в устройство процессоров и сказывается на их ассемблерах, а уже потом этот концепт был дополнен и расширен в новых языках более высокого уровня. Т.е. в реальности есть типы, с которыми работает процессор напрямую, а есть типы, которые твой язык конструирует из базовых типов процессора. "Язык с динамической типизацией" означает лишь то, что язык (интерпретатор или виртуальная машина) выбирает подходящие инструкции по определённым признакам. По-настоящему отказаться от типов на современных процессорах - значит нанести очень большой ущерб производительности, ведь абсолютное большинство нововведений связаны с конкретными типами данных, а потолок возможностей одного ядра "без типов" уже давно достигнут (т.к. просто не выходит повышать частоту процессора ещё больше).
>Я слабо представляю даже простую игру на жс
Многие игры, которые мне в своё время очень понравились и даже полюбились, написаны на ECMAScript (либо JavaScript в браузере, либо ActionScript на Flash). И играл я в них на очень слабом железе, 1 GB RAM и 2 ядра 1 ГГц... Так что ты сильно заблуждаешься, если думаешь, что для хорошей игры нужен производительный язык. Для хорошей игры нужен хороший дизайн, хорошая графика, хороший сюжет и хорошая озвучка, но никак не производительность кода и даже не полное отсутствие багов в коде. Баги и тормоза игроки терпят, а плохие игры - удаляют.
>двачерским дегродам
Вообще-то я тоже годосподин, и зашёл сюда просто потому что в Godot-треде активность упала, а мне сраться с юнити-детьми даже интереснее, чем свою игру делать. А ты тут что делаешь? Не желаешь вернуться в Godot-тред? Печально, что ты на старой версии и привязан к C#, но мы любим всех...
Ты же тот, у которого мобильная ММО-дрочильня? Тогда понятно, зачем тебе нужны те странные выкрутасы с поиском методов по строковым именам... Сочувствую тебе и желаю поскорее закрыть старый проект и начать что-нибудь новое. Лучше отпустить старое, которое причиняет тебе страдания.
> Сам концепт "типизации" возник лишь благодаря тому, что он глубоко зарыт в устройство процессоров и сказывается на их ассемблерах, а уже потом этот концепт был дополнен и расширен в новых языках более высокого уровня. Т.е. в реальности есть типы, с которыми работает процессор напрямую
Мы говорим про языки, или не? Ясен хуй в проце есть "типы" но они привзяаны к конкретным инструкциям в проце, языку тут поебать.
4 байта в памяти это 4 байта в памяти и больше ничего.
От того что ты выполнишь команду "сложи 2 целых числа" закинув в один из регистров эти 4 байта - эти 4 байта не перестанут быть всего лишь 4 байтами в памяти. Которые ты можешь спокойно закинуть в операцию над флоатами.
У тебя и в С++ компилятор, и C# компилятор одинаковые инструкции сгенерит.
Поэтому никаких ненастоящих типов нет.
> По-настоящему отказаться от типов на современных процессорах - значит нанести очень большой ущерб производительности
Это впринципе невозможно, если мы говорим про базовые инструкции проца, какой ущерб если вообще ничего не будет?
> ведь абсолютное большинство нововведений связаны с конкретными типами данных, а потолок возможностей одного ядра "без типов" уже давно достигнут (т.к. просто не выходит повышать частоту процессора ещё больше).
Какой потолок, какие "без типов", если алу это первое что у тебя в проце появилось вообще?
> Многие игры, которые мне в своё время очень понравились и даже полюбились, написаны на ECMAScript (либо JavaScript в браузере, либо ActionScript на Flash).
Это говорит о чем? О том что вприцнипе на этом можно сделать примитивную веб игру? Пожалуй можно.
Говорит ли это о том что это азебись для нормальных проектов?
Это говорит о том, что это вариант покруче, чем например юнити?
>Это каким-то значительным образом отличается от компалйтайм ошибки
А зачем изобретать велосипед на костылях, когда можно купить готовый?
>могу менять эти конфиги непосредственно при исполнении приложения
Godot поддерживает hot reload для GDScript (на счёт C# не знаю) и также стремится обновить все tscn/tres данные в работающей игре. Не всегда успешно, почему-то, но это не важно (скорее всего я что-то не то нажимаю, лол). Из моего опыта: мне как-то проще перезапустить рантайм Godot с маленьким локализованным тестом игровой логики, чем сделать hot reload и надеяться, что это не будет отличаться от перезапуска. Потому что, как бы ты ни старался сделать подгрузку данных бесшовной, подгрузка данных по ходу игры - это не то же самое, что загрузка данных с нуля. Достаточно хоть одному биту памяти быть не таким - и всё поломается, а ты потом будешь сидеть и ломать голову, откуда эта ошибка взялась, если весь твой код написан безошибочно...
Короче: лучше запустить игру заново (или вторую параллельно первой), чем подгрузить изменённые данные в уже запущенную и надеяться, что ничего не сломается из-за какой-нибудь неуловимой ошибки "одного бита памяти". В особенности если у тебя не серверная платформа с ECC RAM, а обычный "геймерский" ПК.
>примитивную веб игру
>нормальных проектов
Ну вот опять началось:
>кококо не хочу кликать мышкой на печеньку, не хочу видеть как numbers go up, нет доставляет мне это дофамина, ааааа дайти мне нормальную игру а не примитивную
>оооо, вот это да, вот это рейтрейсинг, вот это тени, ммммм, струя 240 фпс в лицо, как приятно, прямо фонтан эмоций, дофамин заменил мне кровь, вот это да, ааааах, аааах
Может, тебе лучше было бы в кинематограф устроиться, а не играми заниматься?
Причём тут графон ваще? Ты сам во что играешь, в куки кликер или во что-то ещё?
>Лучше отпустить старое, которое причиняет тебе страдания.
В четверке верстать интерфейс не сильно удобнее, это единственное что мне реально причиняет в годоте страдание и не фиксится никакими нейронками, более отвратительный UX редактора сложно представить, где-то на уровне гимпа
>Причём тут графон ваще?
При том, что основная заслуга движков уровня Unity - это готовый пайплайн для реалистичной 3D графики и физики. Сделать более сложную 2D игру можно без такого движка, поддержка 2D в движках уровня Unity - это чтобы ньюфагов и прочих соло индюков заманивать. Даже в Godot поддержка 2D - это скорее побочный эффект реализации сложного GUI, которому необходимо 2D, а не основной приоритет: Godot изначально и всю дорогу был 3D движком для реалистичной графики, а 2D долго улучшали по запросам индюков. Можно сколько угодно ругать 3D рендерер Godot, но он всегда был и остаётся основным приоритетом движка.
Поэтому фразу "нормальный проект на Unity" я понимаю как "фотореалистичная 3D игра".
>Ты сам во что играешь
Я во многое играл... Всего не вспомню, но было и 3D, и 2D, и ASCII, и чисто текстовые игры, и консольные на эмуляторах, и почти все жанры попробовал. Но я надолго в одной игре обычно не задерживаюсь, поиграл несколько часов/дней и уже как-то не хочется - ищу что-нибудь другое, даже если не прошёл до конца. Бывало и так, что затягивало, так что "игровая зависимость" я знаю не по наслышке... и про "эффект тетриса" тоже. И имея такой разнообразный опыт я могу сказать с полной уверенностью: для полноценной увлекательной игры не важен ни язык, ни движок, ни тип вывода информации на экран, но если тип вывода - графика, то графике нужно быть гармоничной.
Сраться за языки, за паттерны, за движки и прочие технологии - это весело, но к разработке игр как таковой имеет мало отношения. От того, что ты там под капотом используешь, игроку ни лучше, ни хуже не будет. Важно только то, по каким правилам ты будешь взаимодействовать с игроком и что будешь ему выдавать на устройства вывода. А играть можно и без монитора вообще, используя принтер для печати игровой информации на бумаге, выполняя код прямо на языке этого принтера:
http://duckduckgo.com/?q=can+you+write+a+videogame+on+PostScript+and+embed+into+printer
>А играть можно и без монитора вообще, используя принтер
Или аудио. Есть аудиоигры, кстати. Для слабовидящих и слепых.
В общем, технологии для игр нужны, но не являются определяющими.
>В четверке верстать интерфейс не сильно удобнее
Тебе, наверное, понравятся нововведения в 4.7:
https://godotengine.org/article/dev-snapshot-godot-4-7-beta-1/#gui
В остальном же: если у тебя никогда не было опыта с WYSIWYG-редакторами GUI, то тебе просто нужно почаще читать документацию и больше экспериментировать, пока не откроешь для себя то, что тебе удобнее делать; а если ты переходишь с HTML/CSS или любого другого GUI, то придётся потерпеть, пока привыкаешь к особенностям нового. Система GUI в Godot реально мощная и покрывает все потребности большинства игр, а те, что не покрываются базовыми нодами - легко слепить с нуля на GDScript из базовых нод, но переходящим с других GUI, конечно, может быть непривычно.
>не фиксится никакими нейронками
Возможно, твоя проблема в том, что ты пытаешься найти "фикс" (костыль) там, где тебе нужно просто привыкнуть к тому, как принято обращаться с инструментом. Представь, что тебе дали молоток забивать гвозди, а ты говоришь "это неудобно, хочу черпать молотком как ложкой" и начинаешь мастерить сложную систему их шестерней, верёвок и рычагов, чтобы преобразовать черпающие движения как у ложки в удары молотком по гвоздю; а потом приходишь к мастерам и жалуешься, что молотком неудобно пользоваться даже с системой из шестерней и рычагов. Не смешно ли? Если бы ты просто заставил себя несколько дней бить молотком как положено, ты бы привык и научился делать так, как удобнее всего. А не тратить время на лишние костыли, которые не решают проблему.
>более отвратительный UX редактора сложно представить
Ну, не знаю. Я, наоборот, не встречал UI/UX лучше Godot. В этом Godot как Blender: при самом первом знакомстве ты можешь опешить от обилия непонятных кнопок, надписей, менюшек и субменюшек, но когда поработаешь в нём через силу и привыкнешь, начинаешь хотеть, чтобы во всех остальных программах было так же, как в нём.
Анон, я до годота работал с юнити и это не просто небо и земля, это блять мантия и геоцентричная орбита по разнице в уровне удобности редактора. В целом, терпимо всё, но верстать, особенно сложные интерфейсы со всякими рисованными рамочками и прочими найнпатчами - просто пиздец. И этот пиздец не передать текстом. Тем, кто работал с нормальными редакторами - будет больно физически. И привыкнуть к этому невозможно, только затерпеть.
>нововведения в 4.7
Как были элементы интерфейса прихуячены гвозями, так и остались, если сравнивать с dockable интерфейсом юньки (с бесконечными дублями окон и фиксаторами на обьектах) это конечно смешно. Я знаю что это опенсорс, и в целом претензий не имею, но смешно коупить тоже не буду. Ну и да, в тройке к тому же эта проблематика только усугубляется, но не так чтобы я видел наглядный сдвиг в четверке, просто пофиксили часть бесячей хуйни и на этом все, а сам интерфейс как был хуитой непотребной, так ей и остался. Разве что среди прочих foss инвалидов годот наверное лучший.
>Анон, я до годота работал с юнити и это не просто небо и земля, это блять мантия и геоцентричная орбита по разнице в уровне удобности редактора
Это правда. После годота срунити просто неюзабельное говнище, застрявшее в 90-х.
> При том, что основная заслуга движков уровня Unity - это готовый пайплайн для реалистичной 3D графики и физики.
Это конечно заебись, но это не основная заслуга.
Основная заслуга - это экосистема для разработки.
Там и редактор(сцены, объекты, конфиги) есть который можно расширять и кастомизировать легко, намного легче чем делать свои нативные тулзы.
Система сборки проекта под любые платформы.
Интеграция в целом графического апи, звукового, загрузка выгрузка ресурсов.
Готовые системы вроде ui, партиклов, аниматора, поддердка всевозможных форматов.
И главное всё это достаточно хорошо отлажено, достаточно унивресально чтобы разраб с одного проекта в другой мог терпимо перекатываться.
> Сделать более сложную 2D игру можно без такого движка
Зачем тебе всё что я перечислил выше писать самостоятельно, когда оно готовое есть?
>, поддержка 2D в движках уровня Unity - это чтобы ньюфагов и прочих соло индюков заманивать
Миллионы 2д игр на юнити в проде, в том числе сложных и объемных: ну да, пошли мы нахуй.
> Поэтому фразу "нормальный проект на Unity" я понимаю как "фотореалистичная 3D игра".
Ну это чисто твоя шиза. Абсолютно большая часть игр на юнити имеют стилизованную или 2дшную графику. Мобилки, инди сегмент - там доминирует югити, много там фотореалистичных игр. Для фотореализма берут анрил.
> Сраться за языки, за паттерны, за движки и прочие технологии - это весело, но к разработке игр как таковой имеет мало отношения.
Так ты попробуй игры поделать лол.
Игроку правда поебать что внутри.
А вот у разраба - от того какие он решения по разработке будет принимать, какие инструменты использовать - от этого напряиую зависят сроки разработки.
Сделать игру быстрее наверное всё же лучше чем дольше, или ты не согласен?
А, я вспомнил, ты же ОКРное шизло, которое постоянно двигает куда-то окошки и все ломает. Вместо того чтобы просто работать в редакторе.
Когда количество ассетов превышает четыре тысячи - приходится часто прыгать по папочкам. Но безигорному, конечно, не понять
Мне нравятся те 90, в которых застряла юнити. Смузихлебное говнецо от хуана ощутимо хуже
Никаких 4000 ассетов у тебя конечно нет, а игру с парой сотен ассетов я делал и никаких проблем с папочками там нет, а кроме того есть легчайшие способы упростить это тул скриптами, часто готовыми аддонами.
Ах да, и конечно необходимость вручную куда то что то таскать есть только у тупых ассетотаскателей, в моей игре все это процедурненько подгружалось-генерилось
У меня не так много опыта в создании GUI, но перечислю:
1. HTML/CSS: я печатал весь код руками в текстовом редакторе и очень сильно мучился из-за того, что описанные в документации свойства либо не работают совсем, либо работают не так, как описано, либо с чем-то конфликтуют, что-то там перекрывают и т.д. Привязывать события GUI к обработчикам на JS тоже было крайне неудобно. Я слышал про множество GUI фреймворков поверх базовых возможностей и также слышал про WYSIWYG-редакторах, но не смог определиться с тем, что мне следует выбрать из этого зоопарка кривых костылей и тяжёлых велосипедов. Пытался вкатиться в это дело несколько раз на протяжении многих лет, если что, и сверстал кучу разных страничек.
2. Unity: в Unity я пытался вкатиться несколько раз, и каждый раз там не было встроенного GUI, вот совсем. Неужели наконец-то встроили? В любом случае, Unity всегда предлагала на выбор огромное количество ассетов для GUI, из которых непонятно, что выбирать. А базовая Unity без ассетов может только голый Label и Button сделать, да и те нужно через код на C# ковырять. Я так и не смог разобраться с GUI в Unity даже с туториалами, а рисковать, ища и устанавливая чужие костыльные велосипеды из ассет-стора мне не хотелось. Собственно, мой опыт подкрепляется огромным количеством инди-игр на Unity с абсолютно уродливым, кривым и глючным GUI, который часто ещё и тормозит сильнее, чем основная игра с фотореалистичной графикой, лол. Я вообще не понимаю, за что ты её нахваливаешь (какой ассет скачал?).
3. Delphi/Lazarus: это эталон WYSIWYG-редактора GUI под Windows и Linux как минимум, а то и под Android тоже. Лучше редакторов я не пробовал, кроме, собственно, Godot (но о нём потом). Позволяет с лёгкостью набросать именно то, что ты хочешь увидеть в своём приложении, и так же легко и быстро соединить события виджетов с обработчиками в коде. Также позволяет создавать свои собственные виджеты с уникальным внешним видом и поведением, наследуясь от стандартных - но с одним существенным для меня недостатком: поскольку Pascal - компилируемый язык, IDE не способна быстро подхватить разрабатываемый компонент или обновить его состояние. Как минимум Lazarus требует собирать IDE из исходников для встраивания нового компонента в палитру, а про Delphi не помню уже. Да, разумеется, Pascal очень быстро компилируется, и IDE пересобирается за секунду, но всё равно это раздражает и не даёт комфортно делать новые виджеты. Но достойной альтернативы Delphi/Lazarus (для нативного GUI на Windows/Linux) я не нашёл - везде какие-то проблемы.
4. Godot: это просто шикарно, как будто переписали Delphi с нуля, добавив возможность разрабатывать новые компоненты на живом движке - совсем без пересборки из исходников, без компиляции, даже без перезапусков. Ты просто берёшь, и делаешь какие угодно новые виджеты - буквально какие угодно. Реально. При этом твои нововведения, даже написанные на GDScript, органично интегрируются в уже имеющуюся экосистему Godot, словно они там всегда были. При этом нет никаких костылей и велосипедов как с HTML и Unity - нет необходимости качать какие-то заплатки от третьих лиц, ты просто сел за комп, открыл редактор и шлёпаешь свой интерфейс почти как в Delphi, точно так же легко и просто соединяешь события с кодом, но при этом в любой момент можешь взять, и собрать свой собственный компонент, не отвлекаясь ни на что, не выходя из состояния потока, и сразу же использовать свой новый компонент в работе над своим интерфейсом. Шикарно, просто шикарно. Я сомневаюсь, что кто-то смог сделать что-то лучше интерфейса Godot. При всём этом он и выглядит вполне элегантно. Небольшие косяки есть, конечно, особенно в плане взаимодействия с операционкой, но оно и понятно. Преимущества перешивают недостатки - неудивительно, что на Godot всё чаще делают GUI приложений, никак не связанных с играми. Если про Godot узнают больше людей, и разрабы начнут делать официальные "только GUI" сборки (чтобы не было лишнего 3D, физики и т.п.), может, мы увидим больше новых прикладных приложений, написанных на Godot... Хотя у него есть оверхед из-за того, что он не использует нативные виджеты ОС, но для некоторых приложений это не критично, особенно если важен одинаковый GUI на разных платформах.
> HTML/CSS: я печатал весь код руками в текстовом редакторе и очень сильно мучился из-за того, что описанные в документации свойства либо не работают совсем, либо работают не так, как описано, либо с чем-то конфликтуют, что-то там перекрывают и т.д. Привязывать события GUI к обработчикам на JS тоже было крайне неудобно. Я слышал про множество GUI фреймворков поверх базовых возможностей и также слышал про WYSIWYG-редакторах, но не смог определиться с тем, что мне следует выбрать из этого зоопарка кривых костылей и тяжёлых велосипедов. Пытался вкатиться в это дело несколько раз на протяжении многих лет, если что, и сверстал кучу разных страничек.
Так это ты просто не осилил. Весь фронтенд на этом сидит, включая мобайл.
> Unity: в Unity я пытался вкатиться несколько раз, и каждый раз там не было встроенного GUI, вот совсем. Неужели наконец-то встроили? В любом случае, Unity всегда предлагала на выбор огромное количество ассетов для GUI, из которых непонятно, что выбирать. А базовая Unity без ассетов может только голый Label и Button сделать, да и те нужно через код на C# ковырять. Я так и не смог разобраться с GUI в Unity даже с туториалами, а рисковать, ища и устанавливая чужие костыльные велосипеды из ассет-стора мне не хотелось.
И тут не осилил лол. Ты серьёзно аргументируешь своим неосиляторством лол? Если не знаешь что взять, не важно для какой цели - узнай от шарящих челов или сформулируй требования.
В юнити целых 2 юи системы - одной лет 10+, с версткой врчную якорями, другая - HTML/CSS-likeдаже 3 - одна легаси. Так, на всчкий случай)
> да и те нужно через код на C# ковырять.
Верстка и программирование это разные вещи. Версткой занимаются не программисты как правило.
>Собственно, мой опыт подкрепляется огромным количеством инди-игр на Unity с абсолютно уродливым, кривым и глючным GUI, который часто ещё и тормозит сильнее, чем основная игра с фотореалистичной графикой, лол. Я вообще не понимаю, за что ты её нахваливаешь (какой ассет скачал?).
Во-первых прямость гуи заивисит от прямоты верстки.
Во-вторых это просто пиздёжь, хз.
> Delphi/Lazarus: это эталон WYSIWYG-редактора GUI под Windows и Linux как минимум, а то и под Android тоже.
То-то вся индустрия с этого говна перешла на хтмл везде(кроме геймдева - и то даже в нем уже есть небольшая тенденция на переход). А надо было просто тебя слушать.
Бизнес захватывает эффективность. Если ты делаешь что-то эффективнее других - ты начнешь их выдавливать с рынка.
Пока твои руки-крюки таскают кнопки по экрану и чинят полетевшую верстку в окне которое ты год назад делал или копипастят куски окошка в другое окошко а от оверлейных элементов общих для разных окошек последние волосы выпадают - базовички просто открывают код разметки и сразу видят всю картину.
Дооо, такое чувство что ты троллишь и в интернет не заходишь и не видишь как у всех этих эффективных пизнесменов везде верстка разваливается.
>Весь фронтенд на этом сидит, включая мобайл.
Поэтому с вебом и мобилками всё очень плохо...
>аргументируешь своим неосиляторством
Если твой инструмент настолько недружелюбен к новичкам, то это проблема инструментов и его разработчиков, а не новичков. Ты не можешь говорить "этот инструмент хорош" если для его комфортного использования придётся бегать по каким-то форумам и
>узнай от шарящих челов
Почему ты вообще написал "узнай у челов", а не "открой документацию"? Неужели чисто по документации не разобраться? Я с Godot по официальной документации разобрался. Это многое говорит о дружелюбности Godot к новичкам, и поэтому он хорош.
>Верстка и программирование это разные вещи.
В энтерпрайзе и ААА - наверняка так и есть, специальный кабанчик на подскоке с какой-нибудь смешно звучащей специальностью вроде "кнопкомаляр" (меняет HEX-значение свойства color в классе Button и ничего кроме этого не умеет делать). А в маленьких командах и тем более если ты одиночка - ты делаешь всё сам, и тебе важно, чтобы твой инструмент не вставлял тебе палки в колёса лишними альт-табами, ожиданием, пока код скомпилируется, редактор перезапустится и т.п. Короче, ты должен чувствовать себя так, будто едешь на велосипеде, а не скачешь по минному полю.
>прямость гуи заивисит от прямоты верстки
А прямота вёрстки напрямую зависит от того, как хорошо лежит в руке твой инструмент и насколько он стабилен. С хорошим инструментом работа хорошо идёт, тогда как с плохим ты больше времени тратишь на то, чтобы починить этот инструмент и заставить его работать так, как тебе нужно. Если большинство не справляются с инструментом, то он плохой.
>это просто пиздёжь
Ты просто мало тестировал чужие инди-игры на юнити.
>вся индустрия перешла
Delphi платный и очень дорогой. Lazarus долгое время был глючным и малоизвестным. А преимущество HTML/CSS в том, что веб-сайтов наделали намного больше, чем людей на планете, и веб-макак тоже много - следовательно, любой кабан может взять любую из этих веб-макак и заставить делать своё приложение. Качество технологии, удобство IDE и прочие детали менеджеров в данном случае вообще не волнуют - им главное получить какой-то результат с минимальными затратами, желательно взяв наивных студентов вместо тех, кто знает цену своего труда. Аналогично и с геймдевом - если веб-макака устала делать веб-сайты под ключ, и хочет сделать игру, она будет искать движок с HTML/CSS/JS внутри, а не то, что принято использовать в геймдеве.
Такое чувство, что было бы странно, что куча людей юзаеют хтмлцсс и делают на нем проекты разного масштаба, причем успешно, и тут выходишь ты и говоришь, что вообще все они ошибаются.
Предположим. А как ты понял, что твой способ лучше? Ты пробовал в разных проектах применять, прикидывать затраты времени на разработку прототипа, итерации, поддержку, у тебя за плечами много опыта для сравнения?
Или просто потому что ты не осилил хтмл, поэтому?)
> в интернет не заходишь и не видишь как у всех этих эффективных пизнесменов везде верстка разваливается.
Ну бля сложно все девайсы предусмотреть, особенно если сайт большой, бывают где-то недочеты.
Ты-то почему не сделал лучше и не научил всех? Не охота просто?) Влт если бы я знал как лучше - я бы уже монетизировал этот навык+знания, при том что это не моя область вообще.
>Пока твои руки-крюки таскают кнопки по экрану
Ты против WYSIWYG в целом что ли? Вот это лол.
>чинят полетевшую верстку в окне которое ты год назад делал
Если версию движка не обновлял - то вина в твоём говнокоде.
Если обновлял - то о таком в ченджлогах предупреждают.
>копипастят куски окошка в другое окошко
Ещё не открыл для себя кнопку "сохранить ветку как сцену"?
>оверлейных элементов общих для разных окошек
Чиво? Это где ты в Godot нашёл? Опять твой костыль?
>просто открывают код разметки и сразу видят всю картину.
Верстать через код - последнее дело, особенно в играх.
Ладно, открою секрет: ты можешь делать GUI... через код!
Просто спавнить Control-ноды в дерево из своих скриптов.
> Поэтому с вебом и мобилками всё очень плохо...
Что именно всё? На рынке веб и мобилки это доминирующая форма ПО.
> Если твой инструмент настолько недружелюбен к новичкам, то это проблема инструментов и его разработчиков, а не новичков. Ты не можешь говорить "этот инструмент хорош" если для его комфортного использования придётся бегать по каким-то форумам и
Ты говоришь слово "проблема" и "хорош", но эти слова очень контекстуальные.
Для тебя наверное проблема, если у тебя бюджет на вкат в инструмент - 1 день - действительно, этого очень мало чтобы разобраться.
Для того, кто готов потратить ощутимо больше времени на изучение инструмента(в целом кого угодно кто занимается разработкой игр много, не по вечерам пятницы раз в неделю) - это не проблема, а сам инструмент хорош и даст огромный выигрышь на дистанции.
> >узнай от шарящих челов
> Почему ты вообще написал "узнай у челов", а не "открой документацию"?
Потому что инструмент это инструмент, документация объясняет как им пользоваться, а не что тебе делать в какой ситуации.
На юнити делать игры по документации юнити ты не научишься вообще никак.
На годоте тоже, и я могу это сказать даже не глядя в документацию.
Что где на практике лучше - ты узнаешь ищ практики и ресерча чужих практик которые применяют.
> В энтерпрайзе и ААА - наверняка так и есть, специальный кабанчик на подскоке с какой-нибудь смешно звучащей специальностью вроде "кнопкомаляр" (меняет HEX-значение свойства color в классе Button и ничего кроме этого не умеет делать). А в маленьких командах и тем более если ты одиночка - ты делаешь всё сам
Бред. Я когда в маленькой команде работал на 7 челов - мы джуна сделали верстальщиком.
> и тебе важно, чтобы твой инструмент не вставлял тебе палки в колёса лишними альт-табами, ожиданием, пока код скомпилируется, редактор перезапустится и т.п.
Это важно для кого угодно в любой команде.
> Если большинство не справляются с инструментом, то он плохой.
Где какое большинство не справляются с инструментом?
> Ты просто мало тестировал чужие инди-игры на юнити.
Я и играл во много игр на юнити и делал.
> Delphi платный и очень дорогой.
Это две копейки в масштабах проекта.
> А преимущество HTML/CSS в том, что веб-сайтов наделали намного больше, чем людей на планете, и веб-макак тоже много - следовательно, любой кабан может взять любую из этих веб-макак и заставить делать своё приложение.
А прикинь - ты приходишь к кабану и говоришь - смотри кабан, я могу лучше сделать, разработка будет занимать меньше времени.
Что тебе мешает? Или какому-то другому разумисту? Почему этого не происходит?
> Качество технологии, удобство IDE и прочие детали менеджеров в данном случае вообще не волнуют - им главное получить какой-то результат с минимальными затратами, желательно взяв наивных студентов вместо тех, кто знает цену своего труда.
Каво нахуй, фронтедерам мало платят по твоему?
> Ты против WYSIWYG в целом что ли? Вот это лол.
Довольно часто - да.
> Если версию движка не обновлял - то вина в твоём говнокоде.
А причем тут код и верстка? Ну да ладно, просто практически говоря - когда ты делаешь приложение с гуи, рано или поздно у тебя будет такая ситуация.
> Ещё не открыл для себя кнопку "сохранить ветку как сцену"?
Как ее потом вставлять куда то? Руками?
> Чиво? Это где ты в Godot нашёл? Опять твой костыль?
Я не ебу вообще чем там в годот я его не открывал никогда. Задача - есть какая-нибудь панелька снизу, а по центру ращные окошки меняются. Надо чтобы верстка была согласована. Твои действия?
> Верстать через код - последнее дело, особенно в играх.
Смотря какой код.
> Ладно, открою секрет: ты можешь делать GUI... через код!
Какой именно код? Мне кажется хтмл тут ебет другие варианты по явности и наглядности и гибкости, особено тот ужас что ты поедлагаешь далее
Вообще ничего странного, бабло и маркетинг решают. А хтмл да, не осилил, ну написал базовый рендерер html с++, но там просто геморно все стандарты реализовать чтобы сделать свой браузер, который миллион макак в гугле каждый год дополняют.
>Ты против WYSIWYG в целом что ли?
Это БАЗА, Причем доказанная еще годах в 90-х.
>На рынке веб и мобилки это доминирующая форма ПО.
Потому что большинство юзеров - тупое быдло с мобилой.
>если у тебя бюджет на вкат в инструмент - 1 день
Не поверишь, но люди с СДВГ реально существуют.
>готов потратить ощутимо больше времени на изучение инструмента
Плакать, колоться, но продолжать жрать кактус (ради галлюцинаций)?
>как им пользоваться, а не что тебе делать в какой ситуации
Лол? Если взять, например, огнетушитель, то там чётко написано, для тушения каких типов возгораний он предназначен. Если взять тюбик клея, то там чётко написано, для склеивания каких материалов он предназначен. Если взять Unity... то там deprecated experimental prealpha и куча гнилых ассетов за сотни баксов, которые только усложняют задачу, а не упрощают.
>На годоте тоже, и я могу это сказать даже не глядя в документацию.
Так вот почему ты никак не можешь разобраться с GUI. Ясно-понятно.
>Что где на практике лучше - ты узнаешь ищ практики и ресерча чужих практик которые применяют.
А можно открыть документацию и почитать рекомендованное разрабами:
https://docs.godotengine.org/en/stable/tutorials/best_practices/index.html
>мы джуна сделали верстальщиком
Жестокие люди, глумились над несчастным...
>разработка будет занимать меньше времени
Без людей-специалистов это пока не работает.
>фронтедерам мало платят по твоему?
Меня не интересуют их проблемы.
>>1086914
>>Ты против WYSIWYG
>Довольно часто - да.
Почему тогда Godot, а не какой-нибудь SDL? Чтоб без редакторов.
>А причем тут код и верстка?
Не поверишь, но "вёрстка" - это тоже код, только декларативный.
>рано или поздно у тебя будет такая ситуация
То, что ты не открывал целый год, не может просто так сломаться.
>Как ее потом вставлять куда то? Руками?
Выбрал ноду -> Ctrl+Shift+A -> имя в поиске -> Enter.
Но ты можешь и сделать скрипт для генерации (если это менюшка).
>годот я его не открывал никогда
Ну и чё ты влезаешь-то, не с тобой спорили.
>Задача - есть какая-нибудь панелька снизу, а по центру ращные окошки меняются. Надо чтобы верстка была согласована. Твои действия?
В Godot это можно сделать, например, так (если окна фиксированы):
>BoxContainer
>_ CenterContainer
>_ _ Center1
>_ _ Center2
>_ _ Center3
>_ PanelContainer
Потом просто скрываешь/отображаешь то, что тебе нужно. Всё будет автоматически растягиваться-натягиваться под размер и пропорции экрана. Можно даже настроить так, чтобы оно адаптировалось под вертикальное и горизонтальное положение экрана на мобилках, если твоя нижняя панелька может быть расположена вертикально сбоку (как в некоторых играх).
>Смотря какой код.
Скорее "смотря какая задача". Заполнить меню одинаковыми кнопками - это да, лучше через код. А вот красиво и удобно расположить уникальные кнопки, которые имеют разные формы и разное предназначение - тут только через визуальный редактор. Для примера, основная панель GUI в The Sims выглядит слишком сложной для того, чтобы настраивать её полностью через код (хотя в те времена у них могло не быть редактора GUI), но вот списки предметов с иконками заполняются автоматически через код.
>Какой именно код?
Императивный. Твой HTML - это декларативный код. Но можно сделать GUI полностью на императивном коде. Разница только в том, что декларативный код описывает "что должно быть", а императивный код перечисляет "что нужно сделать". Пример: <div> - это "где-то здесь должна быть какая-то коробка с чем-то" (и дальше движок пытается угадать, что с этим делать), а add_div() - это "добавить коробку с этим содержимым прямо сейчас и прямо здесь" (и движок напрямую выполняет этот запрос как он записан). У каждого подхода свои преимущества и недостатки, однозначно лучшего нет.
Файлы сцен (tscn) в Godot - это декларативный код (но не XML, а что-то вроде INI).
чепуха. програмно GUI создавать проще, быстрее. у меня все создается програмно.
> Вообще ничего странного, бабло и маркетинг решают.
Они дают трафик, а не реанимируют труп.
В крупных компаниях есть ресурсы тестить новые технологие, стартапы могут со старта че хотят брать.
У нас например для новой игры взяли анрил, при том что вся компания на юнити работает.
>>1086919
> Потому что большинство юзеров - тупое быдло с мобилой.
Ой, а ты у нас очень умный я смотрю.
Вебмакаки - тупые. Юзеры - тупые. А кто умный-то, ты что ли?
Ты телефоном не пользуешься кстати? Я вот пользуюсь постоянно. Я даже на дваче с телефона только сижу.
> Плакать, колоться, но продолжать жрать кактус (ради галлюцинаций)?
Какой кактус, какие галлюцинации?
Прибыль и интерес определяет вектор движения, если это сложно - то найдутся те кто осилят, если оно того стоит.
> Лол? Если взять, например, огнетушитель, то там чётко написано, для тушения каких типов возгораний он предназначен.
А у нас огнетушитель или движок или какой-то сложный инструмент? Точно ли на всём в инструкции должны быть описаны все кейсы и цели применения?
На карандаше написано для каких он целей? На ручке написано как ей войну и мир написать? На кирпичах написано какой ими дом строить и как?
Твоя аналогия саморазъебывается за 5 секунд размышлений. Так как ты этого не сделал - я правильно поримаю, что ты менее 5 секунд думаешь что написать?
> Если взять Unity... то там deprecated experimental prealpha и куча гнилых ассетов за сотни баксов, которые только усложняют задачу, а не упрощают.
И сюда же сразу
> Плакать, колоться, но продолжать жрать кактус (ради галлюцинаций)?
Разработка игр это не простое дело, так уж получилось. Чтобы с нуля даже до уровня джуна которыц почти ничего не умеет дойти - нужен год упорной учебы и практики. И никто тебя за ручку вести не будет, нету едино правильного гайда.
> Так вот почему ты никак не можешь разобраться с GUI. Ясно-понятно.
С каким гуи я не могу разобраться?
Я на юнити через якоря умею профессионально верстать, пусть практики и не так много. Разбираюсь в гуи шейдерах.
На хтмл на любительском уровне.
На Qt тоже быдо дело, но это та же чкорная система что и в юнити.
С точки зрения программирования я занимался гуи любой сложности.
Так что не, сорян, в гуи я шарю хорошо.
> А можно открыть документацию и почитать рекомендованное разрабами:
Я не знаю, насколько разрабы годота сами профессионалы в разработке игр, разработка инструмента как бэ не значит, что они шарят в прикладном применении, такие вещи как правило разрабатываются реактивно - есть запрос бизнеса и аудитории - есть решения.
> Жестокие люди, глумились над несчастным...
Это стандартная практика, задачи по верстки часто пдаают на джунов либо на про верстал.
> Без людей-специалистов это пока не работает.
Так у тебя во всяких гос парашах, заводах и нии сидят орды Qt-макак, и даже делфи там практикуют. Чем не устроят?
> Меня не интересуют их проблемы.
Так ты сам сказал про них, что вот берут народ который не знает цену своего труда. На практике фронтендеры часто получают 2х-4х от того что получают делфи и Qt бояре.
> Почему тогда Godot, а не какой-нибудь SDL? Чтоб без редакторов.
Довольно часто - не значит, что всегда. Сцены собирать практика показывает что лучше в визуальном редакторе.
> Не поверишь, но "вёрстка" - это тоже код, только декларативный.
А как верстка может быть говнокодом тогда?
> То, что ты не открывал целый год, не может просто так сломаться.
Да что ты. А то что ты сделал год назад - будет статичным и не будет более трогаться в процссе, не будет изменений которые косвенно на это влияют? Какую нибудь кнопку с ценой переверстали и вышла необходимость внести критичнеы зменения, везде где она есть - могут вылезти проблемы.
> Выбрал ноду -> Ctrl+Shift+A -> имя в поиске -> Enter.
Так ее можно хоть засейвить так, чтобы её реальные инстансы оставались связаны с оригиналом? Один раз изменил - все окна подхватили?
> Ну и чё ты влезаешь-то, не с тобой спорили.
Я увидел бред, я его прокомментировал.
> Потом просто скрываешь/отображаешь то, что тебе нужно.
Слодность гуи большая, мне нужно отделить, а не скрывать.
> Императивный.
Получится говняк.
Они берут анрил не потому что это какая то новая технология, а потому что видят что там много разрабов которых можно будет менять как винтики. При этом все знают, что играки ненавидят анрил 5
Любая вебмакак с интерфейсом справится
>играки ненавидят анрил 5
это они еще юнити или годот не видели...
Любой не справится, растеряется, там урезаный хтмл. Будет как местный шарпоговноед бегать
Разве? Мне казалось наоборот. Да и на godot как-то мало хороших 3д игр, они как бы есть по ним не понятен придел возможностей.
Куда забавнее что даже низшие касты из майкрософт используют прямого конкурента шарпа (джаву) вместо самого шарпа. Видимо шарп там для вообще неприкасаемых
>Разработка игр это не простое дело
И зачем это дело усложнять из-за юнити?
>якорная система
В Godot тоже якорная. И контейнерная. И всё это расширяется и руками, и доступно из коробки. А не депрекед через депрекед на платный ассет, который непонятно как использовать (документации нет).
>Один раз изменил - все окна подхватили?
>мне нужно отделить, а не скрывать.
Всё это в Godot есть, просто оно лучше, чем в юнити.
не позорься, в годоти какое-то васянское убожество 98 года вместо UI
я помню как ты в юнити ты не смог импортировать пакет для старого UI, заверещал будто бы тебя грабят, потому что нужно с лицензией согласиться
а новый ты даже не пытался осилить, хотя что там осиливать - тот же HTML
> Они берут анрил не потому что это какая то новая технология
Совершенно верно. А потому что это отличный инструмент под задачу которая стоит.
> а потому что видят что там много разрабов которых можно будет менять как винтики.
На юнити их меньше?
Даже разрабов на кокосе и годоте можно насобирать, из меньше, но и рынок меньше.
> При этом все знают, что играки ненавидят анрил 5
Бред
>>1086971
> И зачем это дело усложнять из-за юнити?
Зачем усложнять из-за юнити, если можно упрощать из-за юнити
> В Godot тоже якорная. И контейнерная. И всё это расширяется и руками, и доступно из коробки.
Я в курсе этого, и в делфи тоже нечто схожее
> А не депрекед через депрекед
Что именно депрекейтед?
> на платный ассет, который непонятно как использовать
В юнити в целом ни один платный ассет не необходим. Можно взять по ситуации bakery(запечка света), odin(валидатор и куча функционала для кастомных редакторов) это копейки в районе 50 долларов. Хз даже что ещё может пригодитьсч из платного. А ну для мультиплеера можно взять фотон чтобы, но именно необходимости в этом нет.
> документации нет
Кстати, ты не первый раз уже говоришь про простоту и документацию - а ты как вообще собрался игры делать, если тебе для всего нужны туториалы с картинками и четкое описание что и как делать, что зачем нужно?
Это конечно здорово когда есть гайды, но разработка игры на 99% состоит из копания неводомого, принятия решений самостоятельно, поиска информации самостоятельно.
Я официальную документацию по юнити практически никогда не открывал даже, ну давно очень только
> Всё это в Godot есть, просто оно лучше, чем в юнити.
Я же говорил про то, где хтмл верстка может быть удобнее визуального редактора.
>В юнити в целом ни один платный ассет не необходим
он имеет в виду Textmeshpro
ты ему скажешь, что он не платный, а бесплатный, а он скажет, что они лицензию могут поменять и он станет платным
ты скажешь - ну будешь пользоваться старой версией, где он бесплатный
а он скажет - а его надо скачивать, а вдруг у меня интернета не будет
ты скажешь - не надо скачивать, его надо только импортировать, и вообще лучше используй UI Toolkit
он скажет - юнитиребёнок порвался и сменит тему
этот разговор тут уже был 100 раз, ему неинтересно делать игры и напрягать мозг, гоняет по кругу одно и то же
>состоит из копания неводомого
Буквально недавно в этом треде выяснили, что в API функция setparent с null в аргументе должна (со слов анонимуса) выкинуть трансформ под root. Но в документации Unity об этом ни слова. Ты об этом намекаешь, говоря "копание неведомого"?
>Что именно депрекейтед?
Unity Engine. Очевидно же.
>можно упрощать из-за юнити
Конечно, можно, вот туториал:
1. Начинаешь делать игру на юнити.
2. Юнити тебя выбешивает.
3. Удаляешь юнити.
4. Ставишь любой другой движок.
В итоге работа упрощена из-за юнити.
> Буквально недавно в этом треде выяснили, что в API функция setparent с null в аргументе должна (со слов анонимуса) выкинуть трансформ под root. Но в документации Unity об этом ни слова. Ты об этом намекаешь, говоря "копание неведомого"?
Это наоборот задокументированное, просто предполагается, что документацию будет читать человек хотя бы первые 5 классов школы осиливший, у которого уже была информатика с примитивной логикой.
> 1. Начинаешь делать игру на юнити.
> 2. Юнити тебя выбешивает.
> 3. Удаляешь юнити.
> 4. Ставишь любой другой движок.
> В итоге работа упрощена из-за юнити.
Много игр сделал таким методом?
не знаю какой анонимус тебе это сказал, но в юнити нет root сцены, ты путаешь с годотом
в годот нет сцены, но есть обязательный рут
а в юнити есть обязательная сцена, но рута нет
опять нахватался по верхам, ты хоть один движок запускал?
нет, я замерял.
>>1086998
очень просто. так же, как компилируются шейдеры во время первого создания объекта. например, у тебя компонент на unity будет вызывать в первый какой-то сложный для jit метод.
современный, оптимизированный код c generic struct'ами, использованием векторизации и т.д. вообще очень сильно тормозит jit. парадоксально, чем производетльнее C#, тем медленее будет jit компиляция.
Для решения этой проблемы существует АОТ компиляция, но дело не в этом, а в том что ты шарп в глаза не видел
>>1086996
Ни в каком смысле связи нет, потому что шейдер является программой сам по себе, как отдельный dll или exe и требует отдельного шага компиляции, в отличии от jit, где как ты заметил - большинство компиляций происходят на старте
оптимизации в новых версиях dotnet тоже не ускоряют dotnet, нужно понимать. все эти де-виртуализации, создание объектов на stack и т.д.
никаких чудес нет. время выполнения программы обратно пропорционально времени ее компиляции. просто вспомните сколько компилируются C++ программы для достижения высокой производительности, а в dotnet эти компиляции методов выполняются каждый раз во время работы программы.
>>1087001
jit сейчас строго необходим для c# для игр. но поддерживает ли его движки.
> просто вспомните сколько компилируются C++ программы для достижения высокой производительности, а в dotnet эти компиляции методов выполняются каждый раз во время работы программы.
Jit позволяет статистические рантайм данные использовать для оптимизации.
> все эти де-виртуализации
Что это значит
> создание объектов на stack и т.д.
Гугли как работает стек. Создание объекта на стек = в стек поинтер прибавляем размер объекта. Всё объект готов.
уже Майкрософт переводит все свои продукты на высокопроизводительный язык Хуана
>jit сейчас строго необходим для c# для игр
то есть AOT
>>1087006
>Что это значит
просто сейчас в jit добавляют разные оптимизации, которые оптимизируют скомпилированный код. из-за этого C# по производительности в некоторых местах догоняет C++. все это имеет свою цену.
де-виртуализация, это когда jit знает какой конкретно метод вызывается, это позволяет, например, inline'ить этот метод, что позволяет еще сильнее его оптимизировать.
например, в каких-то моментах jit можно просто убрать создание объектов, вызовы виртуальных методов превратив это все в абстракции с нулевой стоимости, как в C++ или rust.
например, C# не умеет девиртуализировать лямбы, даже самые тривиальные типа list.Sort((a, b) => a.CompareTo(b));
а если бы умел, то вместо цикла с 1000 вызовов виртуальных методов можно было напрямую inline цикл, а может и весь метод сортировки!
Тяжелая жизнь юнитистов.
Постоянно нужно бегать от каких то проверщиков лицензий, скачивать какие то устаревшие версии, инсталлировать кнопки
Зачем то они выбирают себе такие страдания
это тебе надо, мне ничего кроме UI toolkit, встроенного в юнити, не требуется
>У меня есть проект Godot на C#. При экспорте используется JIT-компиляция, что вызывает проблемы, поскольку при первом запуске любого фрагмента кода возникает сильная задержка. Особенно это заметно, например, когда враг впервые использует атаку, и во время компиляции кода атаки возникает скачок задержки.
если вам было мало пропуков в годот, то теперь обнаружился их новый источник.
Так все равно надо делать комнату под полом, где крутятся все модельки и все анимации для пропука шейдеров, там и код атаки пропукнется, пока загрузочный экран на старте.
Хватит врать. Те, кто знают C++, не станут тратить время на коподомойку под названием "годот" - это движок для бездарей и лентяев, мечтающих одной кнопкой делать игры.
> "годот" - это движок для одной кнопкой делать игры.
Отличная реклама годоту, надо брать.
Это unity ai.
Годот является таким движком только в воображении годоть.
Похоже в этот раз безоговорочная победа Хуана. Даже юнити признали поражение, и сделали новый GUI как отдельное дерево.
лучше иметь и то, и другое
Unity UI toolkit не имеет ничего общего с годотом, он скорей похож на RmlUI и Qt
Принцип такой же. Раздельные деревья для мира игры и виджетов.
они в любом случае раздельные
или ты на кнопку главного меню в юнити пытался повесить модельку персонажа? так не надо делать
вообще-то и в новой это есть, в UI Toolkit samples даже пример имеется
Можно было повесить один компонент. Или перетащить ссылку на кнопку так же, как на любой другой компонент. Эта унификация представляет удобство для игрового движка, меньше трения.
Значит я невнимательно смотрел. Я думал они оптимизировали для 2D, а иначе какой смысл.
меньше трения - когда всё в одном списке, не надо изучать ещё одну систему
но я тёртый калач, меня таким не напугаешь, я уже столько UI-систем освоил
С этим у unity ui toolkit есть определенные проблемы. Слишком переусложнили. Многие по прежнему пользуются старым gui.
Че там опять у тебя нет в годоте, 5 секунд в гугле
на говнотю похуй, но это как минимум необходимо для VR, он еще не окончательно сдох, поэтому ты скорей всего неправ
а в анриле всё из коробки есть
У Node2D в годоте 2D трансформации. Это ограничение годота. Ты можешь нарисовать контролы с перспективой, но сами элементы всегда будут плоские.
Надо посмотреть что есть из коробки, ведь на годоте как то VR и AR делают.
На скрине TC The Division они тоже плоские, дальше что? Тебе нужны 3д капсулы кнопки?
Нет, там у элементов есть Z, они могут менять глубину. Без 3D трансформаций не сделать.
Можно сделать 3D текстом, спрайтами. Это не проблема. Просто виджеты дают возможность использовать layout, события, а так придется с нуля все самому делать.
Если контрол все равно 2д, то какая разница? Глубина будет достигаться квадом, на который спроецирован контрол.
разница была бы, если бы ты хотел чтобы нажатая кнопка уходила в глубину.
И как ты достигнешь глубину "квадом", если у контрола нет информации о глубине?
Причем здесь контрол? У квада либо привязка к камере (hud), либо к мировой координате (аля label3d). На нем выводится 2д контролы, которым нет дела, какая глубина. Опиши, что ты хочешь сделать?
https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/transform
Как я понимаю, сначала GUI система находит 2D прямоугольники для всех контролов, а потом у каждого контрола есть допольнительная матрица, которая может трансформировать "квад" в 3D пространстве.
>На нем выводится 2д контролы, которым нет дела, какая глубина
В том то и дело, надо иметь возможность указывать 3D трансформации для каждого контрола.
В Ezengine изкоробки
Для какой цели? Покажи скрин такого эффекта из существующей игры
активный элемент меню немного выдвигается вперед
Да, из коробки так не сделать, но думаю за полдня можно.
>Да, из коробки так не сделать
Всё работает из коробки:
https://docs.godotengine.org/en/stable/classes/class_subviewport.html
Но такой ГУЙ очень неудобен игрокам (особенно с низким разрешением экрана).
Одна из тех ситуаций, когда разраб тратит время на то, что игрок хочет вырубить...
Не, это не вариант, если у тебя 100 кнопок 100 сабвьюпортов положат годот, да и ты заебешься им лайаут расставлять
1. Делаешь обычный 2D GUI.
2. Закидываешь в SubViewport.
3. Выводишь как 3D пластинку.
4. ???
5. TODO: не забыть проверить accessibility...
У тебя есть пруф того, что это 3D графика?
Потому что в 2D такой эффект легко изобразить.
Примерно так:
>scale => (1.2, 1.2)
>position.x => -20 px
И будет "типа выдвинулось вперёд" чисто в 2D...
Возможно. В принципе еще давно в пейнт.нете делал псевдо-3д разными skew
Это в .net одним параметром правится при билде. Даже кодить не надо ничего. Это же не годот.
Странно, твое сообщение противоречит приложенному скриншоту.
>mono
нужно тренировать LLM на этой теме, чтобы они не советовали ерунды
к лучшему стенду стоит огромная очередь из желающих поиграть. люди в очереди говорят "лучший движок", "просто отлично!", "это технологический прорыв". у худших стендов пусто, играет один жирный задрот вокруг которого роятся мухи. стены и компьютер одного из худших стендов измазаны коричневым
яркий мультяшный стиль: мягкие формы, округлые пропорции, крупные выразительные глаза, насыщенные цвета с лёгким градиентом, чистые контуры, минималистичные детали, мягкое освещение, лёгкий 3D-эффект с глянцевыми бликами, дружелюбная атмосфера
у одной очередь и восторженные отзывы "вкусно", "идеально", у второй повар стоит один, у третьей клиент блюёт
яркий мультяшный стиль: мягкие формы, округлые пропорции, крупные выразительные глаза, насыщенные цвета с лёгким градиентом, чистые контуры, минималистичные детали, мягкое освещение, лёгкий 3D-эффект с глянцевыми бликами, дружелюбная атмосфера
победитель далеко впереди, за ним плетётся отстающий, третий сломался и пилот вышел и недовольно пинает колесо
один стенд лучший, один средний, один худший. выбери случайно
к лучшему огромная очередь, восторженные отзывы.
у среднего спокойно, людям скучно
у худшего пусто, сидит вонючий задрот, всё измазано калом
логотипы Unreal, Unity, Godot распределены случайно и не связаны с качеством стендов. избегай совпадения роли с порядком перечисления.
яркий мультяшный стиль
один стенд лучший, один средний, один худший. выбери случайно
к лучшему огромная очередь, восторженные отзывы.
у среднего спокойно, людям скучно
у худшего пусто, сидит вонючий задрот, всё измазано калом
логотипы Godot, Unity, Unreal распределены случайно и не связаны с качеством стендов. избегай совпадения роли с порядком перечисления.
яркий мультяшный стиль
один стенд лучший, один средний, один худший. выбери случайно
к лучшему огромная очередь, восторженные отзывы.
у среднего спокойно, людям скучно
у худшего пусто, сидит вонючий задрот, всё измазано калом
логотипы Unity, Godot, Unreal распределены случайно и не связаны с качеством стендов. избегай совпадения роли с порядком перечисления.
яркий мультяшный стиль
>>1087280
>>1087279
>>1087277
>>1087276
>>1087275
>>1087274
>>1087273
>>1087272
>>1087271
шитпостинг, ручной вайп
Это не общение, ведь ты ни с кем не общаешься, а тупо вайпаешь тред своей нейроговной
Нет, происходит аргументация почему тебя стоит вынести вперед ногами с треда
это тоже общение. и ты уже насрал больше чем я своими бессмысленными постами. и пока отвечаешь - продолжаешь срать и срать не по теме треда. себе ты срать позволяешь
мои посты - по теме треда, твои - нет
это технический комментарий, относящийся к поддержке здоровья борды
нигде не прописано такое исключение типа "вам можно сколько угодно засирать анрелейтедом тред, если вы угрюмый уебан, которому не понравилось, что анон запостил аж 10 рофлов в тему треда". ты отвечаешь потому что тебя задевает за живое. как я и говорил, последнее, что тебя волнует это порядок в треде, а мотивация твоя это обычная человеческая чмошность
у меня был один пост - комментарий для модератора, чтобы не репортить каждый пост
призываю анонов набраться терпения и дождаться чистки треда
>>1087280
>>1087279
>>1087277
>>1087276
>>1087275
>>1087274
>>1087273
>>1087272
>>1087271
Ахаха угарные картинки всё в точку
>>1087286
Я с ним общаюсь. Сыбас.
Нерелейтед - это обсуждение говнота(Govnot, запрещенное вирусное ПО)
>Govnot
вообще-то это запрещённая террористическая ЛГБТ организация
а лучше бы ты признал, что ты конченый мудак и хуесос, убивающий постинг в разделе
>игру, сделанную на Unreal Engine
Красиво, но неиграбельно без DLSS из 144p в 1080p. Геймплейно - банальный шутан, коих миллионы. Большинство ассетов бесплатные или покупные. ГГ специально нарядили в костюм со шлемом, чтобы не возникало эффекта зловещей долины. 5/10.
>>1087272
>игру, сделанную на Unity
Классический пиар дешёвого ассетфлипа: вместо скриншота из игры - фото офиса с компьютерами и имитацией бурной деятельности, где на экранах изображение редактора и малюсенький фейковый скриншотик из покупных, но скучных ассетов. 1/10.
>>1087273
>игру, сделанную на Godot Engine
Приятная мультяшная графика, скриншот реального геймплея, миленькая фурри лисичка вместо потного мужика, чувствуется ДУША, вложенная одиночкой в уникальный проект мечты. Может показаться, что аудитория - дети, но сюжет глубочайший. 10/10.
Согласны?
> Большинство ассетов бесплатные или покупные.
где купишь ассеты такой нестандартной растительности? главного героя? тут всё руками сделано, с большим профессионализмом
а вот на юнити именно что самая дефолтная параша. юнитипетушкам стоило бы уже начать оправдываться, почему датасет юнити-игр усреднился в подобный высер
Да наверняка на fab есть какой-нибудь пак "ультра 4к инопланетная растительность", а про мужика в броне, камушки, воду и т.п. и говорить нечего - точно есть.
Про юнити согласен.
может не так отвечал, я не ебу играет ли Хуан в роблокс, было вопросов 15 связанных с этим, но за 60 вопросов джинн сдался. занёс мэтра в анналы
Так ты про какого то другого Хуана.
Наш Линиецкий.
А то у тебя получилось, как Карпаты которого обзывают Карпатым.
https://www.youtube.com/watch?v=eWUDoms2iJo
>Что лучше, иметь одно дерево дерево для виджетов и игровых объектов (как было в unity), или 2 раздельных дерева, как в годоте.
Ты троллишь так что ли? В Godot 1 дерево на все ноды. Вообще на все ноды. Ты можешь сделать такую цепочку, например:
>Node3D
>_ Control
>_ _ Node3D
И она будет работать в Godot. Что здесь происходит: верхняя Node3D никак не влияет на позицию Control, который будет отображаться согласно своим настройкам и порядковому номеру в дереве сцены, а нижняя Node3D не будет ничего знать о верхней Node3D, что приведёт к тому, что она будет двигаться независимо от неё, как если бы она находилась непосредственно под root-нодой; настройки Control на нижнюю Node3D тоже никак не влияют. По сути, с точки зрения обоих Node3D, данный Control аналогичен простой Node (у которой нет трансформации), а с точки зрения Control, эти два Node3D также аналогичны Node (т.е. нет параметров, важных для Control).
Но несмотря на это, и Node3D, и Control находятся в одном дереве сцены и могут ссылаться друг на друга по иерархии дерева как и на любые другие ноды в дереве. Это не отдельные деревья.
Надо понять и простить, он увидел что есть две вкладки редактора - 2д и 3д, и подумал что это разные деревья. В юнити то у них все в одну кашу.
Какое-то время назад я начал пилить убийцу Godot'а на джава скрипте и дошло до того что сейчас переношу браузерную игру с Godot'а на то что получилось.
Если вам интересно понаблюдать за процессом, приходите в мой тред в дневничках:
https://2ch.life/dr/res/785140.html
Я знаю, что в движкосрач треде сидит элита /gd, буду очень рад вашему обществу!
>купить пасскод чтобы в загоне общаться с дваченейронкой
АХАХАХАХАХХА
Спокуха. Мой пасскод был честно выигран на ТВГ. У меня нет таких денег.
>движкопися
>браузерки
>мобилки
>javascript
>вайбкодя
К-К-К-К-КОМБО!!!
Я знал что хуан ебанутый, но я не осознавал всю глубину пиздеца.
Это чистая, незамутненная неэффективность.
На самом деле, это гениальное и очень удобное на практике решение.
>>1087394
>Каждый тип Node создает альтернативную иерархию
Нет никакой "альтернативной иерархии"...
>Как это сделано
Кажется, движок собирает списки того, что нужно сделать, и делает это в стиле ECS, поэтому ощутимые просадки могут быть только если ты пытаешься делать много перестановок нод местами.
Т.е. чтобы нарисовать на экране текстовую надпись, движок не бегает по дереву в поисках следующего Label; вместо этого, когда Label добавляется в дерево, эта нода создаёт ресурс в графическом сервере. Нода - это только абстракция для удобства пользователя, а сервер работает линейно.
Сильнее всего это заметно с физическими нодами, например, RigidBody3D: созданный на физическом сервере объект имеет свойства, заданные в полях нод, и реагирует на вызовы API на нодах, но что там под капотом на самом деле происходит - имеет значение только для разработчиков конкретного физического движка. От дерева сцены требуется только вовремя отвечать на запросы API пользователя и предоставлять актуальную информацию по запросу.
"StringName" - это, по сути, Integer.
HashMap в Godot довольно быстрые...
А это что? У Node своя иерархия в HashMap, у Node3D своя, у Control своя.
>А это что?
Читать ещё не научился?
>purely an optimization for faster traversal
https://store.steampowered.com/app/3672400/Farever
Не увидел ни одной причины в трейлере делать подобный слоп на своем движке, таких клонов геншина на юнити в ГП девать некуда и новые все подвозят и подвозят
>На самом деле, это гениальное и очень удобное на практике решение.
Да, решение удобное, если нужно разрезать связь трансформов двух 2д/3д нод, добавив между ними Node. Но проблемы, которые за собой тащат ноды, скрипт которых перекрывает тип реальной ноды - гораздо тяжелее подобного копеечного бонуса от них.
>На самом деле, это гениальное и очень удобное на практике решение.
Звучит не очень:
Вхолостую пересчет трансформов, которые будут отброшены и начнут считаться с нуля
Потенциальные баги, например захотел организовать что-то в поддереве Node3D-Node-Node3D, а потом замечаешь, что трансформ больше не наследуется
>Потенциальные баги, например захотел организовать что-то в поддереве Node3D-Node-Node3D
Это не баг годота, это дальтонизм организатора, который не различает цветов нод
>Вхолостую пересчет трансформов, которые будут отброшены и начнут считаться с нуля
0.001iq тейк, трансформы что так что эдак будут считаться
А где ты увидел баг годота? Баг будет в игре, ну и полагаться на цвета нод это конечно лул. Может ты еще эмодзи в коде предложишь использовать?
Твой 0.001 iq в том, что посчитаны лишние трансформы, ближе к корню дерева.
>Баг будет в игре
Не делай багов в игре. Если у тебя дальтонизм - тогда не повезло, придется ориентироваться на инспектор нод.
>Может ты еще эмодзи в коде предложишь использовать?
Эмодзи такая же информация как и любая другая. В целом, комментрии с эмодзи хоть и палят что писала нейронка, но в целом - очень неплохо смотрятся в секции комментариев как символы быстрой идентификации.
>Твой 0.001 iq в том, что посчитаны лишние трансформы, ближе к корню дерева.
Что значит "лишние"? Считаются все трансформы, без исключений. Просто при обрыве связи - трансформ более не наследует родительский базис и начинает существовать цетре мира.
>Не делай багов в игре
Это математически невозможно. А дальше уже у тебя практики/инструменты, которые помогают не делать багов, или усложняют.
> комментрии с эмодзи
А цвет ноды в такой цепочке уже играет роль не комментария, а функционала.
>Что значит "лишние"?
То и значит, в корне могла бы быть Node без трансформа, а не трансформ, который будет посчитан, но результат отброшен
>А цвет ноды в такой цепочке уже играет роль не комментария, а функционала.
Функционалом обладают ноды сами по себе. А их цвета - просто визуально отделяют одни ноды от других.
>То и значит, в корне могла бы быть Node без трансформа, а не трансформ, который будет посчитан, но результат отброшен
Какая-то дурка. Никто никуда не должен отбрасываться, трансформ отображает положение ноды в мире. Если трансформ "дефолтный" - с ним никаких вычислений не происходит, он просто получает родительский трансформ, а если есть различия - то разумеется он посчитается и передастся далее.
Это и есть альтернативная иерархия. У каждого узла как минимум 2 иерархии по которым надо ходить. В 2 раза больше памяти, кеш миссов.
У этого подхода нет никаких преимуществ по сравнению с разделением деревьев. Это сложнее, медленнее, является источником ошибок.
>игра на кастомном двигле, думайте
А чего тут думать, тут и так всё ясно:
>PROCESSOR: Intel i5 11400T or AMD Ryzen 5 3600X
>MEMORY: 32 GB RAM
>GRAPHICS: Geforce 4060 or AMD Radeon RX 7600
>STORAGE: 25 GB available space
>ADDITIONAL NOTES: 1080@60fps
Хотел поспорить, но не буду, бгг
Когда я вижу такой дизайн уровня из стека одинаковых панелек, у меня в голове только одна мысль: ХАЛТУРА!
Это стилизация под N64 / майнкрафт // фентези самосбор - выбирай
>замечаешь, что трансформ больше не наследуется
На самом деле, это фигня. Никогда не сталкивался.
А вот с чем сталкивался. Вот в Godot есть ноды для физических объектов, RigidBody3D и StaticBody3D, а в четвёрке ещё AnimatableBody3D добавили для доп. вычислений влияния двигаемых кодом StaticBody3D. Допустим, что StaticBody3D прибит гвоздями и это нормально, но AnimatableBody3D своим названием подразумевает, что его можно/нужно двигать...
Как думаете, что будет, если Static/Animatable будет потомком RigidBody3D в дереве сцены? Про Static догадаться несложно: он останется на месте, даже несмотря на то, что является Node3D и должен унаследовать трансформ RigidBody3D (Node3D).
Но каково же моё разочарование - AnimatableBody3D остаётся неподвижным в потомках RigidBody3D, хотя название намекает на то, что он должен двигаться. Подозреваю, что они просто не догадались об этом.
Решение этой задачки простое: RemoteTransform3D позволяет скопировать трансформ на любую ноду, соответственно, можно двигать Static за RigidBody3D. Разумеется, можно и просто в коде трансформации применять, но хочется всё-таки чисто на нодах...
Думаю, возникнет вопрос, нафига двигать статики? Пытался найти способ упростить геометрию Rigid и сохранить отдельный физический слой для более подробных столкновений отдельных объектов. В реальном проекте, наверное, так делать не стоит.
Является ли это проблемой движка? Я так не думаю. Конечно, пришлось поломать голову, почему оно не срабатывает так, как я того ожидал, но один раз разобравшись, просто запоминаешь и не паришься. Большинство игр не будут удочерять статик ригидом.
>>1087447
Минимальные:
64-разрядные процессор и операционная система
ОС: Windows 10 64 bits
Процессор: Intel i7 6700K or AMD Ryzen 5 5500
Оперативная память: 16 GB ОЗУ
Видеокарта: Geforce 3060 or AMD Radeon RX 5600 XT
Место на диске: 25 GB
Дополнительно: 1080@30fps
А вы говорите годот охуел и фпсов не докладывает. Поделка хуана наверное в сотню раз производительнее этого неироничного бздотя энжина
Сардонический смех годоти.
Никто не знает как было бы на годоте, потому что еще не было отчаянных, сделать такую игру в открытом мире на годоте (road to vostok с деревьями-крестиками не в счет).
Скорее всего слишком много объектов и cpu driven рендер пыхтит. В годоте было бы еще хуже.
https://www.reddit.com/r/godot/comments/1lhurw5/yall_asked_me_to_compare_my_c_engine_with_godot/
Аналогичное сопоставление с юнити
https://www.reddit.com/r/Unity3D/comments/1lc9kk4/just_finished_my_animation_system_in_c_and_turns/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1
На юнити сделан геншин и вагон других игр, гораздо красивее этой хуйни. Так что выводы делаем сами
Если бы ты немного разбирался в computer science, и знал архитектуру годота и особенно размер его узлов в памяти, которые хранят дочерние объекты в HashMap, ты бы такое не писал.
>Одновременно очень много скелетных анимаций
Меньше десятка человечков - это много для тебя?
>>1087454
>Скорее всего слишком много объектов
На скриншотах пустые плоскости и кубики...
Единственное что из этого годот не затащит - это траву. А свою сверх быструю я так и поленился писать.
>А что если в качестве движка неиронично выступает рантайм годота?
Жирный наброс, но вопрос хороший:
https://steamdb.info/app/3672400/info/
>Technologies: HashLink Engine, Heaps Engine
>HashLink is a virtual machine for Haxe programming language that provides a fast runtime environment for executing Haxe bytecode with JIT compilation, garbage collection, and support for native C library integration.
>HEAPS is a mature cross-platform graphics engine designed for high-performance games written for the Haxe programming language. It is designed to leverage modern GPUs that are commonly available on both desktop and mobile devices.
>Haxe is a high-level, cross-platform programming language that allows developers to write code once and compile it into various languages like JavaScript, C++, and Python. It is open-source and supports multiple programming paradigms, making it versatile for different types of applications, including games and web development.
Геншин только кажется большим. Большим и пустым... число объектов на сцене на самом деле очень маленькое. Ну и он сделан на китайском форке юнити, в котором может все переделано с нуля.
>>1087459
Скорее всего каждый слок стеков сделан одним объектов. "Дизайнеры уровней" любят такое ctrl+c/ctrl+v, чтобы заполнять уровни. В геншины большие куски сделаны одним мешем.
>Haxe
Ебааать. Не, это не лечится, на самом деле можно сказать что разрабы совершили чудо, чтобы поделка на этой залупе не требовала в минимальных 4090.
>Когда я вижу такой дизайн уровня из стека одинаковых панелек, у меня в голове только одна мысль: ХАЛТУРА!
Я не помню точное геологическое название, но такие формации отвестных скал на 100% реальные. В играх, возможно, преувеличенное количество скал на один квадратный километр площади, но это объясняется необходимостью разнообразить движение игрока: передвигаться по реальным степям тупо скучно.
>каждый слок стеков сделан одним объектов
Сам-то понял, что сказал? Что за "слок стеков"?
>"Дизайнеры уровней" любят такое ctrl+c/ctrl+v, чтобы заполнять уровни.
Насколько я знаю, с точки зрения CPU/GPU, такой копипастинг является оптимизацией по сравнению с уникальными объектами на каждом шагу.
>В геншины большие куски сделаны одним мешем.
В геншине много заметных невооружённым глазом "склеек" из нескольких явно отдельных мешей. Они регулярно заделывают дырки на скалах таким вот копипастным мешем, или налепляют отдельный в качестве холма с крутым уклоном... Много швов, бросающихся в глаза, даже если не искать их.
А чем тебе такой дизайн не нравится? Как по мне, достаточно няшные уровни на скринах. Жаль, что компьютер не потянет, а так бы я потестировал...
>>1087467
>на 100% реальные
Кстати, в природе ещё шестигранные камни часто встречаются. Первый раз фотография кажется сюрреалистичной, но это реальные образования.
Слой стеков. Один холмик может состоять из сотен объектов. А если такие холмики копируются, то 100 холмиков это уже ~10 - 30к объектов.
Нюанс в том, чтобы определить какие объекты нужно рисовать, нужно пройти по всему дереву каждый кадр, выполнить куллинг и т.д. Чем больше объектов и чем неэффективнее они расположены в памяти, тем медленнее это будет. Движок 100% долбится в процессор. Скорее всего еще один поток.
Какая разница что там в природе. В игре это ленивый дизайн. Вместо интересного уровня просто копипаст однотипных префабов.
>Вместо интересного уровня просто копипаст однотипных префабов.
Интересность уровня определяется расположением этих префабов. Интересный уровень можно сделать из одних кубов - грейбоксинг.
>Движок 100% долбится в процессор.
Там 3060 в минимальных, лол. 3060, карл. Эта видюха тянет ААА 6-7 летней давности на максимальных настройках.
Как слои кубов не располагай - интереснее не станет. Для интересного открытого мира нужно уникальные локации.
из одного обзора
>Occasional stuttering, overall poor fps even though i have 4090
>100 холмиков это уже ~10 - 30к объектов
Сами по себе "объекты" это ничто в современном 3D рендеринге. Если у них один материал и если CPU отправляет данные одним массивом, то нет большой разницы, сколько там объектов. Даже наоборот, если объекты повторяются, то буферы данных могут быть использованы повторно => экономия ресурсов.
>выполнить куллинг
Это проблема только если у тебя майнкрафт или реалистичный город как в ГТА, а ландшафт как на скриншотах этой игры - плоский и пустой, поэтому куллингом там практически нечего скрывать...
>чем неэффективнее они расположены в памяти
Учи базу https://ru.wikipedia.org/wiki/Октодерево
>>>>1087463 →
Сколько костылей и боли, чтобы отобразить примитивный открытый мир из пары десятков объектов.
Зачем? Для чего? Ну перейди ты на нормальный движок...
>Вместо интересного уровня просто копипаст однотипных префабов.
>>1087479
>Для интересного открытого мира нужно уникальные локации.
Ты в игры совсем не играешь что ли?
Абсолютной уникальности достичь невозможно, и абсолютная уникальность, будь возможной, была б контрпродуктивной для геймдизайна, ибо мозг человеческий работает за счёт знакомых паттернов; полностью уникальные комбинации пикселей будут выглядеть как ничего не значащий пиксельный шум. Например, если в твоём игровом мире есть некие смертельно опасные объекты, они должны иметь идентичные свойства и внешние черты, чтобы игрок узнавал заранее, что они опасны, не подрываясь на абсолютно уникальных ловушках каждую секунду.
Т.е. хороший игровой мир должен следовать набору фиксированных правил - шаблонов, которые игрок выучивает наизусть и использует для навигации и получения удовольствия от игры. Шаблоны должны повторяться, чтобы они имели практический смысл; например, если у тебя есть грибы, растущие в одном болоте, то и в других болотах тоже растут грибы; если игроку зачем-то нужны грибы, он знает, что ему будет достаточно найти ближайшее болото, а не лазить по пустыням, заснеженным скалам, коралловым рифам. Конечно, ты можешь реализовать "пустыный гриб", "снежный гриб", "морской гриб", но тогда ты просто добавляешь дополнительные правила-шаблоны, и обязуешься выполнять и их тоже. Они не уникальны.
А интерес складывается из чередования разных повторяющихся (неуникальных) шаблонов. Пример: передвигаться по равнине легко, но надоедает тупо зажимать W; а карабкаться по скале может быть интересным, но утомительным из-за сложности; если чередовать скалы и равнины, игрок будет сохранять интерес к игровому миру, потому что мир даёт ему несколько разных занятий по очереди. Не так уж и важно, что твои равнины и скалы выполнены по небольшому числу шаблонов, если они не слишком большого размера, т.е. не успевают надоесть игроку.
>в современном 3D рендеринге
в современном да, но речь про годот. CPU рендерер создает все draw call'ы на CPU. батчи это оптимизация работы GPU. В 99% случаев ты будешь ограничен CPU, особенно на современных видеокартах и API.
вулкан может спокойно прожевать 100-200k draw call'ов, но годот никогда не сможет эффективно скопировать данные для 100к draw call'ов на GPU.
Про деревья на современных процессорах вообще надо забыть. 99% времени процессор будет просто ждать операции чтения памяти, прыгая по ветвям дерева.
Я уже писал (и лично проверял), что простой цикл с simd на порядки эффективнее октодерева.
10-20к объектов на сцене это лимит для движка типа годота.
>Чела ебет синий робот
А где ебка? Челикс настолько не парится что хуярит прям на нодах даже деревья, это тебе не рендерсервером жонглировать
>пары десятков объектов.
Обьектов не меньше чем в этой помойке кста >>1087405
>Ну перейди ты на нормальный движок...
Это какой? Другого лучшего foss движка на эту планету пока не завезли, даже s&box на поверку оказался лагающей ссаниной, не смотря на дрочку на сурс.
>10-20к объектов на сцене это лимит
На процессоре 2007-го года Godot 3.3 тянул 36к нод, учитывая физику. Где-то 12к drawcall на OpenGL 3... Подозреваю, что любой современный процессор на современной памяти справится в 10-15 раз лучше... Учитывая оптимизации, можно много интересного реализовать даже с таким лимитом в 36к нод. Ну а большинству игр такого количества не нужно...
В играх с открытым миром интересно, когда игра удивляет тем, что ты еще не видел. Если вся игра состоит из одинаковых повторяющихся структур, то она ничем не может удивлять по определению. Если нужно зачистить 1000 одинаковых холмиков от 1000 одинаковых врагов - это не интересно. Никакое изменение порядка, формы холмиков это качественно не изменит.
В этом, кстати, заключается претензия игроков к современным играм в открытом мире.
Никто не делает в крупных играх 10-20к уникальных объектов на экране, это все запекается при билде, в 3-ке для этого есть нода MergeGroup, в 4-ке можно поставить аддон, а для дублированных объектов есть MultiMesh. Да вроде в 4-ке Forward+ и так батчит по материалам (но не mobile и web)
Да, чтобы сделать большую игру, надо немножко поработать, а не просто скачать 10к ассетов закинуть и надеяться что само заработает. Может быть, даже придется где то подумать головой. Придумать чанки или стриминг.
>янул 36к нод
"Тянул", это когда уже ФПС упал ниже 30, я полагаю? А теперь представь более реалистичный сценарий с геймплейным кодом, который тоже нагружает процессор, и можешь число объектов бенчамарка делить на 2, 3.
>претензия игроков
Argumentum ad populum.
>когда игра удивляет тем, что ты еще не видел.
Тогда зачем играть в игру, если можно просто на вики прочитать про все детали игры, посмотреть летсплей, прохождение стримеров? И почему люди задротят по несколько тысяч часов в некоторых играх, зная карту, поведение NPC, правильные тактики боя и т.п.?
И как тебя вообще можно удивить в игре, если ты уже поиграл в сотни, а то и тысячи игр, и поэтому хорошо выучил все рабочие и нерабочие паттерны геймдева?
>Если нужно зачистить 1000 одинаковых холмиков от 1000 одинаковых врагов - это не интересно. Никакое изменение порядка, формы холмиков это качественно не изменит.
Ты рассматриваешь это в отрыве от геймплея.
Да, сама идея "убить 1000 врагов на 1000 холмов" в текстовом виде звучит скучно. Но теперь представь: ежесекундно игроку приходится решать, увернуться, скатившись с холма, или подпрыгнуть, потенциально подставившись под лучника с другого холма; идти на следующий холм по порядку или обойти его и потом спрыгнуть на голову врага со спины; использовать стандартные атаки ближнего боя или подобраться к вражеским позициям так, чтобы одним выстрелом пробивающего лазера убить сразу десяток врагов; использовать ли бомбы или это будет уж слишком рискованно из-за высокого обрыва рядом; можно ли воспользоваться объектами на холме для атаки, как использовать их эффективнее всего, можно ли их использовать для защиты; когда и где использовать аптечки, активировать бонусы, переключать режим персонажа или менять оружие и броню; и т.д., и т.п.
Видишь - в контексте геймплея даже одинаковые на первый взгляд холмы дают массу разнообразия от банального положения, поворота и масштаба, т.е. от буквальной копипасты и простых трансформаций. А добавив ещё пару-тройку элементов - овраги, реки - получается намного больше комбинаций, которые постоянно влияют на геймплей и ощущения игрока. Например, прыжок в овраг может быть опасен сразу, однако, не замедлит передвижение, как река, и в конкретной обстановке будет безопаснее; может, конкретную группу врагов лучше сбросить в реку и заморозить её, а другую лучше сбросить в овраг и забросать его бомбами; а в другом месте можно уничтожить плотину, залив врагов в овраге водой.
И всё это можно протестировать на серых кубиках.
>ФПС упал ниже 30
Нет. У меня 75 Hz монитор, так что было 75 фпс.
>сценарий с геймплейным кодом
Это уже другой вопрос. На скриншотах из игры выше наблюдается не более десяти героев/врагов, а вся остальная карта - это статичные декорации.
Godot 3 у меня тянул около 100-150 KinematicBody, столпившихся в плотную кучу, на тех же 75 фпс. Т.е. получается, что взяв 10% отсюда и 90% оттуда, будет приблизительно 10 героев/врагов и 9000 статичных объектов с полной физикой и графикой. Но это без оптимизаций вообще, то есть тупо брутфорс, и на устаревшем на десятилетия оборудовании...
Опять эта страшилка "ууу страшный игровой код завесит годот".
Годот учит анти-паттернам.
А в ААА-движках наоборот меши делят на еще более меньше мешлеты для эффективности.
Этот движок отстал на 20 лет, минимум.
У нас в треде инди, а не ААА разрабы (Не, ну я ААА разраб но из прошлого, так что уже не актуально).
>А мы в годоте запекаем меши в один большой меш для оптимизации куллинга на CPU
>А еще мы заменяем источники света на спрайты, ведь годот не тянет больше 8 источников света одновременно
Есть нюанс, я провожу собесы, а не хожу на них... Да меня то никуда по возрасту уже не возьмут.
>А еще мы заменяем источники света на спрайты
А GTA уже не заменяет?
Судя по всему 3 года назад мешлеты обсуждались, но пока разрабов не нашлось, даже V-sekai некогда
https://github.com/search?q=repo%3Agodotengine%2Fgodot-proposals+meshlet&type=issues
Причем тут бюджет. Во первых, в гта это не оптимизация, а flare эффект. Во вторых, изнасилованный синим роботом чел выдумывает оптимизации, которых в современных движках не нужны. Оттраханый в жопу годотом горе-разработчик неиронично делает оптимизации уровня morrowind 2003 года.
В гта это оптимизация, фары и фонари вдалеке, там где уже не рисуются отражения, сделаны спрайтами. Это база, это знать надо.
>Оттраханый в жопу
Юнитипидоры всегда думают о хуях, классика.
>ОПТИМИЗАЦИИ НЕТ - ПЛОХА
>ОПТИМИЗАЦИЮ СДАЛАЛИ - ПЛОХА
Держи в курсе, чмоня.
Это как понимать? Опять наврали?
Так не бывает, чтобы прям все было реализовано.
В играх на юнити переписывают по полдваижка.
>и можно делать игру.
Верно, на годоте давно можно делать игры, что доказано сотнями релизов.
> примитивную игру уровня 2003
>заниматься оптимизациями
Да, если ты хочешь сделать опенворлд это не "примитивная" игра и надо заниматься оптимизациями.
>В чем тогда вообще смысл годота
В готовых частях, самое удобное это шейдеры, которые заебешься подключать в самописном движке.
>На unity/unreal
Попытка юнитиговна примазаться к анрилобогам засчитана.
99% пользователей этого движка не смогут это реализовать.
Было обещано, что годот берет на себя всю графику и т.д., а я просто пишу скрипты на gdscript. Зачем твое говно нерабочее тогда нужно, объясняй!
Даже простую игру без танцев с бубном и форка движка не сделать! Честно говоря я все больше хуею от глубины дна этого движка.
>Было обещано, что годот берет на себя всю
Где, кем? Пруфы, скриншоты, ссылки приводи.
как же жалко выглядит godot в сравнении
сорта говна. беви тут сидит там же у параши что и годот
если бы беви писали на нормальном языке, а не ржавой педерасне... ну или хотя бы они сделали биндинги беви на другие языки
нашел тут либу WGVK - (кароч - это стандарт webgpu на вулкане). Так вот - в чем фишка, все же знают что вулкан - это какое-то говно (и не надо говорить что треугольник в три тысячи строк кода - это потому что дали лоу левел... dx12 тоже дал лоулевел - там нет такого пиздеца)..
и по сути из-за говно вулкана низкоуровневое программирование в такой жопе сейчас, когда на выбор либо очень давно умерший opengl, или всякое прибитое к платформе/винде... или треугольник в три тысячи строк кода... тяжко короче. Да что там - нейронки блядь не могут на вулкане писать. это полный пиздец
анон. если боишься что нейронка тебя заменит - вкатывайся в пукан - нейрона его не может
я к чему это все - нужна либа которая бы нормально закрыла говно вулкана без оверхеда. конечно пишут всякую хуйню, но зачем-то туда пихают стандарты такого же древнего dx11( nri например).
или изобретают свой язык шейдеров (сука, их и так уже только оффицильных десяток - нахуй еще васянские? а ведь именно они сейчас - узкое место и васяны тут нахуй не нухны. это sokol и bgfx)
под бразуеры. Фишка в том что хоть это современный апи, он очень простой. и я бы реально советовал изучать графоний на нем (но мало материалов, жаль). Но он под браузеры.
а WGVK позволяет писать на нем на пк (внутри вулкан). только в отличие от гугловоно дауна где надо компилировать десятки гигов какой-то хуйни (чем там в гугле постоянно болеют, что у них все либы обвешаны всяким говном?) или мозиловского растовой которую приходится слюнями приклеивать к нормальным языкам. WGVK - внутри всего около 20к строчек кода (при этом 100% стандарт webgpu). что в свою очередь можно даже использовать как основу движка.
поэтому я и выбрал его сейчас
>кароч анон. начал пилить свою игру без движка.. точнее сначала соберу что-то типа движка или фреймворка под игру.
Может начать с чего попроще? Ну хотябы с пропукивающего прототипа с минимальными требованиями в 3060? Даже у пердящей на 4090 поделки выше по треду нашлись защитники, которые купили и хвалят
>у параши
на чем основано это утверждение? на твоих субъективных эмоциях? беви на данный момент это авангард open source графических технологий, а годот, несмотря на то, что является авангардом по количеству пожертвований, застрял 20 лет назад.
>авангард open source графических технологий
На котором невозможно делать игры. Редактора нет, 3д и тем более 2д слабо развиты, копроязык, который дополнительно изговнили ecs'ом, где ты чуть не так написал системы - уже сосешь у ооп по производительности на архитектурном уровне. Это сделано не для инди, а для хуй пойми кого. Собственно, шоукейсы говорят сами за себя, этой хуйне до годота еще пыхтеть и пыхтеть, если речь про юзабилити.
>3д и тем более 2д слабо развиты
это шутка такая? ты бы хоть ссылку открыл.
>юзабилити
какой толк от этого "юзабилити", если любая не являющаяся конкурсной демкой игра требует нетривиальных усилий по реализации и оптимизации, на которые подавляющее большинство пользователей просто не способно. так что что для инди, что хуй по что - это еще большой вопрос.
ну а приравнивать редактор (в котором можно подергать трансформации у узлов, не более) == юзабили, могут только совсем нулевые новички, мнение которых автоматически приравнивается к мусору, сам понимаешь.
>это шутка такая? ты бы хоть ссылку открыл.
Люди не играют в миллиард отрендеренных моделек, я такую хуйню могу отрендерить даже в годоте через rendering server. Люди играют в игру, геймплей.
>если любая не являющаяся конкурсной демкой игра требует нетривиальных усилий по реализации и оптимизации, на которые подавляющее большинство пользователей просто не способно.
>гта - простая игра, не требующая нетривиальных усилий
Жирнич, ты смехотворен
>редактор (в котором можно подергать трансформации у узлов, не более) == юзабилити
Ну так внатуре ==. Но ты же просто безигорный тролль, который делает скайрим в браузере (в своей маняфантазии), ты и без редактора всё сделаешь
Бонус-трек - возможность красиво и динамически сборки подзагружать.
>readonly struct
Брух, их завезли 10 лет назад
>растообразные енумы
Сахар, не более
Если бы эти пидары наконец завезли в свой ебучий блазоровский компилятор dll компиляцию - вот это реально была бы пушка
>на чем основано это утверждение?
на том что тут на дваче есть два шиза - один годотя, другой беви. и по развитию они равны.
а если серьезно - у беви ровно такая же лавина проблем, как в пропукивающем годоте.
>а если серьезно - у беви ровно такая же лавина проблем, как в пропукивающем годоте.
У беви есть одна главная проблема - на нем нельзя делать игры, все остальные проблемы вторичны.
смотрите какие себе задачи напридумывал этот шизик, дюжэ потужно
>I'm working on Input Field. Here is the points(tasks) from my design document:
Selection model (anchor/focus vs start/end, forward/backward, affinity, multi-region)
Pointer gestures (tap, double-tap, triple-tap, drag, long-press, hover, stylus)
Gamepad and keyboard-only navigation
Native selection overlays (UITextInteraction, UITextSelectionDisplayInteraction, UITextLoupeSession, UIEditMenuInteraction, Android ActionMode, Magnifier, EditContext)
Custom selection UI and alternatives to native
IME pipeline for CJK and Vietnamese (Japanese kana/kanji, Korean Hangul/Hanja, Chinese Pinyin/Wubi/Cangjie, Vietnamese Telex/VNI/VIQR)
IME platform integration (iOS UITextInput, Android InputMethodManager, Web CompositionEvent, macOS NSTextInputClient, Windows IMM32/TSF, Linux IBus/Fcitx)
Input validators and filters (per-platform veto APIs, masks, locale-aware number parsing)
Autocomplete and predictive text (popups, ghost text, accept gestures)
Atomic tokens / pill mentions (selection, deletion, cursor placement, two-format clipboard)
Keyboard avoidance, safe area, soft keyboard handling
Autofill integration (oneTimeCode SMS QuickType, WebAuthn passkeys, password manager extensions)
Foldable app continuity (Galaxy Z Fold state preservation across screen swap)
Multi-channel clipboard (UTI/MIME formats per platform, paste decision tree, format negotiation)
CF_HTML byte-offset header specifics (Windows-specific framing layer)
Markdown clipboard channel (web text/markdown, Slack/Discord/Notion/Obsidian conventions)
Cross-app rich text fidelity (Word/Pages/Notion/Google Docs)
Sanitize-on-paste pipeline (DOMPurify, mXSS, allow-list filtering)
Strip vs preserve vs filter-by-feature paste policies
Drag-and-drop as parallel clipboard (NSItemProvider lazy providers, drag preview, drop caret)
Selection-as-export (Share Sheet, Intent.ACTION_SEND, ACTION_PROCESS_TEXT, macOS Services, Look Up, Speak)
Find / Replace UX (UITextSearching, NSTextFinder, NSFindPboard bidirectional, off-viewport indicators)
Bracketed paste mode for terminal-style UIs
Programmatic vs user input discrimination (event source tagging, controller pattern)
Undo / Redo (granularity, coalescing, time-based break, OT/CRDT undo)
Inline attribution storage models (flat runs, tree, hybrid, CRDT — YATA/Peritext/Fugue)
Inline element types (formatting, links, mentions, custom emoji, math, embeds)
Auto-detection (URL, email, phone, hashtag, mention, IDN homograph protection)
Real-app teardowns (Telegram, Discord, Slack, WoW/FFXIV, Notion, Google Docs)
Block-level vs inline distinction
Caret rendering (blink timing, geometry, RTL mirroring, IME composition states)
Selection rendering (highlight rectangles, RTL/bidi visual continuity, custom pseudo-elements)
Highlight animations (search matches, current-match emphasis, density throttling)
Custom rendering and shaders (per-glyph effects, gradient text, glow, holograms)
Text animations (typewriter, wobble, pulse, per-glyph stable IDs, media-time vs frame-time)
Caret special-case behavior (empty lines, soft-wrap, bidi boundaries, atom traversal)
Accessibility (VoiceOver/TalkBack, Voice Control, Dynamic Type/AX5, Reduce Motion, Bold Text)
RTL and Bidi (UAX #9 algorithm, isolate wrappers, mirrored handles)
Localization edge cases (combining marks, Indic conjuncts, emoji ZWJ sequences, vertical text, ruby)
Performance (virtualization, glyph atlas, shaping cache, debounce policies, large-paste freeze)
Project profile map (casual mobile, MOBA chat, messenger, Discord/Slack-class, visual novel, JRPG, card game, MMO chat, code editor, terminal UI, document archive, notes, WebGL, console, educational, RTL-localized, accessibility-first, streaming overlay, karaoke, live captions, email/webhook, SSR rich text)
Modern Apple stack (Writing Tools / UIWritingToolsCoordinator, Foundation Models, NSAdaptiveImageGlyph / Genmoji, visionOS gaze+pinch, Apple Pencil Pro squeeze/barrel/haptic)
Modern Android stack (stylus handwriting, predictive back, S Pen, Voice Access)
Modern Web stack (CSS Custom Highlight API, Anchor Positioning, field-sizing, writingsuggestions, Selection.getComposedRanges, VirtualKeyboard, EditContext)
Console / VR text input (Steam Deck, Switch 2, Quest 3 Surface Keyboard, visionOS)
Cross-cutting security (UAX #39 confusables, IDN homograph, PRECIS)
Cross-cutting i18n (CLDR plurals cardinal/ordinal, MessageFormat 2.0, NFC/NFD normalization)
Networked text and actor identity (CRDT awareness/presence, programmatic event tagging)
Critical edge cases catalog (32 validated GitHub/Bugzilla precedents)
Lifecycle / state transitions (focus session boundary, suspend/resume IME, process death, bfcache, autosave tiers, undo scope, dirty flag, view recycling, animation cleanup, async validation race, atlas warm-up, font fallback async)
String / data-level pitfalls (UTF-16 length confusion, Turkish/German case mapping, smart quotes, soft hyphen, ZWSP/NBSP, naive split CJK/Thai, Indian numbering, date ambiguity, Hijri calendars, CRLF/LF, BOM, frame-rate animation, subpixel RGB/BGR, justified text, mobile Enter ambiguity, outline:none WCAG)
Пока не доберётся до 1.0, смысла рассматривать в контексте разработки игр нет: 0.x версии - это когда отсутствует стабильное API и breaking changes могут происходить на каждой версии любого масштаба.
>>1087558
>нашлись защитники, которые купили и хвалят
Там есть графика и геймплей, а движкопися ни то, ни другое не умеет и пробовать боится. От страха перед обучением чему-то новому и непонятному он убегает к сборке движка из либ, т.е. в свою зону комфорта.
>>1087566
>требует нетривиальных усилий по реализации и оптимизации, на которые подавляющее большинство пользователей просто не способно
Это "подавляющее большинство" не будет способно эффективно использовать ECS и функциональщину, поскольку они требуют технического склада ума, а подразумеваешь ты, видимо, всяких художников, не способных даже простой "hello world" написать.
А тем же, кто ни в код, ни в арт не умеет, вообще не угрожает столкнуться с необходимостью что-то нетривиально оптимизировать. Игры можно и на Scratch делать: https://scratch.mit.edu/explore/
Нормальный список для 2026. В принципе все это ты видишь каждый день в приложении телеги/банка/гугла
Кстати в годоте этого всего нет, поэтому чатики там будут выглядеть как привет из 90х
>в годоте этого всего нет
Так и в юнити всего этого нет и прикручивается сбоку саморезами. Можно в конце концов просто нейронкой портировать это дело под годот и будет так же.
>В принципе все это ты видишь каждый день в приложении телеги/банка/гугла
кстати, прикол, я на гитхабе натыкался на реализацию вичата на юнити, всяких говно-мессенджеров, при чём с поддержкой аудио и видео звонков, всё это были китайцы, а ещё разрабы юнити сделали свой фреймворк App UI для UI Toolkit
> их завезли 10 лет назад
Не следил как то. Кому то кстати надо сделать компилятор раста в дотнет. Это будет пушка.
>>1087580
Необходимость скриптового языка во времена копеечных ЛЛМок под вопросом.
Ну потеряла и потеряла, чего бухтеть-то?
>>1087595
Ну высосал и высосал, чего бухтеть-то?
>>1087607
Ну ненужен и ненужен, чего бухтеть-то?
pr != gd
Каким надо быть додиком, чтобы это не понимать..
Согласен, не бухчу.
>>1087610
>pr != gd
В /pr жёсткий отбор, только 300к/наносеки.
В /gd малыши, над фоне которых он крутан.
>Необходимость скриптового языка во времена копеечных ЛЛМок под вопросом.
Как раз таки ллмки очень хуево могут в код на низкоуровневых языках, а вот на питончике бы легко нафунякали
Заработали много денег, потратили еще больше купив мобильную рекламную прокладку, так получается.
Наверное нить потерялась, я думал речь о том, что "скриптовые языки" не нужны поскольку "есть ЛЛМ", => ллм якобы могут писать на не-скриптовых, низкоуровневых языках, но по опыту не могут, а значит. скриптовые языки все же имеют смысл, и вот на них уже можно натравить ллм.
В принципе корректно. Но им не надо быть именно специальными скриптовыми.
>компилятор раста в дотнет
Не, пусть ржавые в своем карго-загоне чилят, в отдельности от здоровых людей
>миллиард отрендеренных моделек
ты понимаешь о чем говоришь, потому что ты нулевый новичок. это не просто "миллиард моделек", это автоматическая генерация lod, и gpu culling отдельных мешлетов, что позволяет тупо добавляет неограниченное число объектов на сцену и иметь графику и прозводительность на порядки лучше, чем годот когда либо сможет себе позволить.
просто посмотри мучения на этого бедолаги с пердолькой lod'ов https://www.youtube.com/watch?v=Dv2PVDTSsRs
в bevy ничего это не нужно было бы делать. это и есть реальное "юзабилит" движка, а не возможность подергать трансформации в бесполезном редакторе для игры, которая никогда не увидит свет.
>гта
причем тут гта. эта LLM поломалась.
я подразумеваю типичного гдачера, который является полным нулем в техническом аспекте разработки игр, часто даже не знает программирование, и просто копирует уроки/LLM. это основная ЦА этих движков.
такой человек не полезет в код движка что-то исправлять, и вообще он никогда не пойдет дальше встроенных возможностей движка. а как показала практика, этих возможностей не хватает даже для простенькой игры с графикой уровня 2003 года.
В последний раз когда тут чекали беви, там нихуя не было, кроме лагающего волка без теней и пбра. Что то вышло новое на нем?
>ля простенькой игры с графикой уровня 2003 года.
хватает. такие игры на годоте выходили еще лет 5 назад.
>автоматическая генерация lod, и gpu culling отдельных мешлетов, что позволяет тупо добавляет неограниченное число объектов на сцену
!=
>иметь графику и прозводительность на порядки лучше, чем годот
Еще раз повторю, люди не играют в триллион одинаковых моделек. Не играли, не играют и играть не будут. Геймплей создает человек, а человеку нужны инструменты. Если из инструментов у человека только кодовый способ вывести на экран триллион одинаковых моделек - сделать на базе этого игру будет крайне затруднительно.
>посмотри мучения на этого бедолаги с пердолькой lod'ов
Хз с чем там можно мучаться, в годоте автолоды есть
>в bevy ничего это не нужно было бы делать.
Беспочвенное утверждение. По ссылке всего-навсего миллиард одинаковых моделей, у которых нет освещения, анимаций, vfx, и всего остального, что к тому же настраивать без редактора безумно сложно. Плюс, мы и так знаем как наниты ебут производительность, когда моделей становится много и они начинают обладать разными материалами, так что бабка еще натрое сказала, где будет лучше производительность - на старых добрых лодах или на модно-молодежных мешлетах.
>возможность подергать трансформации в бесполезном редакторе для игры
Безигорным все бесполезно, ведь игры в воображении разрабатывать гораздо проще чем ирл
>люди не играют в триллион одинаковых моделек
беви приближается к святому граалю движков, когда можно просто добавлять контет, как и мечтают безыгорные годоти, и все будет работать. только в беви это реально работает, а в годоте, жидко пукнув, умирает на простенькой сцене 2003 года.
>как возможность добавления неограниченного числа mesh'ей
>беви приближается к святому граалю движков, когда можно просто добавлять контет
Где-то мы это слышали, кажется на релизе уе5. Но есть ньюанс...
https://www.reddit.com/r/unrealengine/comments/16z0cdj/nanite_performance_nanite_discussion/?tl=ru
это не наниты, более простые мешлеты, у которых просто автоматически генерируются и переключаются lod'ы.
у нанитов потоковая загрузка мешлетов, субпиксельное разрешение, и из-за этого часть мешлетов растеризуется вручную через compute shader и т.д. их нельзя сравнивать напрямую.
в беви скорее эволюция классических lod'ов, просто меш автоматически делится на несколько маленьких для эффективности.
>это не наниты, более простые мешлеты, у которых просто автоматически генерируются и переключаются lod'ы.
Звучит еще хуже. Как будут чуть менее синтетические тесты, ну хотябы там город как в прототипе/гта - тогда звоните. А так это звучит как легкий способ утилизировать дорогущую видеопамять, ведь это значит что в видеопамяти будут храниться сразу несколько вариантов достаточно высокополигональных моделек, а если таких моделек будет много - будет oom и 4 фпс.
а в годот ничего в память не загружается? ну если ничего не делать, то да.
это лучше для инди движка. инди не надо ассеты с миллионами треугольников, и тысячи экземпляров одного ассета как раз более реалистичный сценарий для инди.
В годоте лоды загружает и выгружает цпу, потому их гораздо меньше в активе видеопамяти будет.
>это лучше для инди движка. инди не надо ассеты с миллионами треугольников
Сам себе противоречишь, лол. Если инди не нужны миллионы треугольников (что на самом деле не много, виртуальная геометрия позволяет обойти ограничение на миллиарды треугольников) - то эти мешлеты вообще теряют свой смысл, просто берешь, спавнишь годотовские мультимеши и в хуй не дуешь, они рисуются за один dc десятками тысяч. А главное - такая фича реализуема в годоте без всяких ecs и копрораста, что еще более уменьшает смысл подобного достижения движком, где кроме ecs и виртуальной геометрии больше нихуя и нет.
не нужны миллионы уникальных треугольников. это разные вещи.
ты просто не знаешь об ограничениях multi mesh. это не то же, что узел на сцене.
>не нужны миллионы уникальных треугольников. это разные вещи.
Так они не уникальные
>ты просто не знаешь об ограничениях multi mesh.
У него одно ограничение - он рисуется всегда, покуда виден в кадре, что ломает куллинг, что вынуждает жонглировать пулом из них, если того требует ситуация. А узел просто интерфейс доступа к позиции этого меша в мире, необязательный к использованию. Разумеется, он не поможет обойти проблему рисования миллиарда трисов, но на таком уровне нагрузки рендера начинают проявляться другие ньюансы, которые мы имеели честь наблюдать в алане вейке 2, где отключение нанита приводило к повышению производительности без изменения в графике на 30%.
Подозреваю что освещение/тени могут неочевидно с мультимешем работать.
>Треугольники сами по себе дешёвые.
Но не для видеопамяти, когда их обьем начинает подступать к сотням миллионов. Эту проблему решает нанит и виртуальная геометрия блеви, но из-за любви хуанга и его сестры к урезанию шины на видюхах - часто так бывает что наниты делают только хуже, если для текущего состояния сцены видеопамяти гпу хватает.
>проблемах Godot (и 3, и 4) с полупрозрачными материалами
А что там знать? Полупрозрачность нежелательный для производительности обьект в многих движках, включая юнити и уе5, годот в этом вопросе не исключение, даже если учесть аргентинскую специфику
На самом деле больше вопросов почему многопоточность так плохо дает прироста. Явно кто-то где-то обосрался.
>Почему никто из местных графодрочеров не знает о проблемах Godot (и 3, и 4) с полупрозрачными материалами?
Это не какая то уникальная проблема годота, а принцип работы рендера в принципе - непрозрачные треугольники легко сортируются, легко используют буфер глубины чтобы не рисовать лишнее - полупрозрачность не может так работать, ей нужно нарисовать вообще все, да еще и не просто рисовать, а читать уже нарисованное и смешивать цвета. И никакой тайны тут нет, это обсуждалось тут года 4 назад, когда анон запустил сцену где у него был какой то торговый центр со стеклянными стенами, и я показывал это тоже на примере нескольких бутылочек и стаканов на столе, так что если ты чего то не видел, не читал RTFM - проблема точно не в ком то другом, лол.
Что беви плохой, потому что в нем надо редактировать не в редакторе, а в плеймоде?
Что годот плохой, потому что в нем надо редактировать в редакторе, а не в плеймоде?
что непонятного. bevy переносит drawcall'ы на GPU, что убирает лимит размера сцены. bevy осуществляет эффективный frustum/occlusion culling, что пропускает потенциальные миллиарды вызовов вершинных шейдеров. треугольники дешевые, пока их не становится очень много. тогда, например, даже просто невидимые треугольники становятся проблемой, потому что даже для backface culling'а и т.д. нужно выполнить вершинные шейдеры. в частности, мешлеты решают и эту проблему, потому что позволяет не рисовать мешлет целиком, если он не повернут к камере лицом.
да, для лоу поли инди мешлеты может не являются актуальными, но gpu driven рендер является очень актуальным, потому что позволяет создавать сцены по принципу "расставил префабы и забыл".
про редакторы пишут безыгорники, которые не могут вообразить что кто-то может самостоятельно сделать редакторы для игры (в этом нет ничего сложного, и они будут эффективнее универсального "редактора"). play mode нужно для отладки в первую очередь, чтобы делать быстрые итерации, смотреть/изменять свойства во время запуска игры.
>про редакторы пишут безыгорники
>самостоятельно сделать редакторы для игры
Получается те кто делают самостоятельно редакторы для игры == безигорники? Ну, недалеко от истины кстати
>Но не для видеопамяти
Щас у каждого геймера по 16-24 Гб как минимум.
>подступать к сотням миллионов
Ну, не флипай ассеты фотосканов без обработки.
>Полупрозрачность нежелательный
>включая юнити и уе5
>>1087754
>Это не какая то уникальная проблема годота
Вы признаете, что все движки - некрасивое говно?
>>1087755
>редактировать в плеймоде
Это вообще как? Свой велосипед мастерить?
>>1087760
>самостоятельно сделать редакторы для игры
А ещё движок, язык программирования, ОС, ЦПУ...
>Это вообще как? Свой велосипед мастерить?
Тут вообще есть такой момент. Вот допустим в юнити/годоте есть редактор. А разве его получится приделать в свою игру, чтобы получить майнкрафт/фортнайт? Да хотя бы гизмо. Да фиг там чего выдерешь. Вот и получается, что для игр с произвольным строительством в рантайме все равно надо свой редактор пилить.
абсолютно для любой игры сложнее демки для ТВГ нужно свой редактор. у "редактора" unity/godot можно только подергать трансформации, и изменить свойства компонентов в инспекторе. игру так не сделать. точнее можно попытаться, извращаясь со ScriptableObject и т.д., но это займет 10x меньше, чем специализированный редактор.
>которые не могут вообразить что кто-то может самостоятельно сделать редакторы для игры
Приобрел машину, осталось только кузов с рулем добавить.
>видеопамяти
>Щас у каждого геймера по 16-24 Гб как минимум.
Жесть, откуда они их все набрали? Не иначе как пиздили из под дверей когда доставка амазона привозила.
>Щас у каждого геймера по 16-24 Гб как минимум.
Статистика стима говорит об обратном
>Вы признаете, что все движки - некрасивое говно?
Так проблема не в движках
>>1087765
>Тут вообще есть такой момент. Вот допустим в юнити/годоте есть редактор. А разве его получится приделать в свою игру, чтобы получить майнкрафт/фортнайт?
Ты в корне не понимаешь назначение редактора в игровом движке по причине безигорности, к сожалению безигорному трудно обьяснить, что в игре есть много подсистем, которые нужно настроить, которые нужно связать в одно целое, часть игровых обьектов и вовсе генерируется кодом при помощи скриптов редактора, и все в таком духе. От гибкости редактора напрямую зависит то, как долго будет разрабатываться игра.
>Ты в корне не понимаешь назначение редактора в игровом движке
Я как раз отлично понимаю его ненужность.
>по причине безигорности,
Не угадал, я сделал больше игр, чем ты успеешь за всю свою жизнь.
> к сожалению безигорному трудно обьяснить, что в игре есть много подсистем, которые нужно настроить, которые нужно связать в одно целое
Для этого редактор не нужен. Это можно делать конфигами, кодом.
>, часть игровых обьектов и вовсе генерируется кодом
Бинго, вот тут ставишь точку в предложении.
>От гибкости редактора напрямую зависит то, как долго будет разрабатываться игра.
В этом твое заблуждение и есть, сроки зависят от живости ума разработчика и отсутствии его лени писать свои инструменты, а не сидеть на попе и ждать что в редакторе появится какая то волшебная кнопка.
Уточню, что я говорю именно про встроенный редактор движка. Некоторым играм статичные уровни надо делать в редакторах уровней, вот только этот редактор спокойно может быть внешним, хоть блендер.
>у "редактора" unity/godot можно только подергать трансформации, и изменить свойства компонентов в инспекторе
Нет, это редакторы бздотяэнжинов зачастую представляют собой столь убогое зрелище, в юнити и в годоте ты можешь за счет механизмов управления отображением рисовать все что угодно в инспекторе, в юнити данная возможность предельно возведена в абсолют позволяя написать редактор к чему угодно.
>Для этого редактор не нужен. Это можно делать конфигами, кодом.
С соответствующими временными затратами, замедляя разработку в десятки раз, когда вместо визуального управления и композиции обьектов ты дрочишь конфиги.
>Не угадал, я сделал больше игр, чем ты успеешь за всю свою жизнь.
Да, у меня маняфантазия развита слабее, я предпочитаю делать игры а не маняфантазировать о том как я делаю игры
>Бинго, вот тут ставишь точку в предложении.
Ты же не понимаешь о чем вообще речь. Скрипты редактора ускоряют юзабилити редактора там, где это требуется, автоматизируя некоторые вещи. С помощью редакторных скриптов, если редактор достаточно гибок - я сам себе могу делать
>волшебная кнопка.
еще значительнее ускоряя работу.
Чувствую, что это определение сильно отличается у пользователей разных движков и движкопись.
>замедляя разработку в десятки раз, когда вместо визуального управления и композиции обьектов ты дрочишь конфиги.
Полный бред, очевидно что изменить текст в разы быстрее, чем кликать мышкой в разные области экрана.
Но ведь и это не главное. В рантайме аля майнкрафт ты просто подходишь куда надо, смотришь, и ставишь объект. Вот и вся визуальная композиция, без специального движкоредактора
> я предпочитаю делать игры
Делать не равно сделать.
>Скрипты редактора ускоряют юзабилити редактора там, где это требуется, автоматизируя некоторые вещи.
Ты удивишься, но для этого не нужна такая сущность как встроенный в движок редактор - ты можешь точно так же сделать скрипт который сделает это в рантайме твоей игры, и даже если захочешь прикрутить текстовые поля и ползунки.
А, еще ведь в редакторе всегда другая картинка, чем в рантайме- там урезаются спецффекты, постпроцессинг, скрин спейс просто другой, другие ракурсы, другой кроппинг вьюпорта, другое освещение.
У игры нет определения, как и у жизни, любви, добра, много чего еще. Так что тут можно просто устроить еще большой срач на новый тред.
>изменить текст в разы быстрее
Ты нутром чувствуешь, на какое именно число тебе требуется изменить параметр? Не лучше ли просто передвинуть мышку туда, куда тебе нужно, чтобы программа сама подобрала нужное тебе число?
>В рантайме аля майнкрафт ты просто подходишь куда надо, смотришь, и ставишь объект
Лол, ты небоскрёб в ГТА тоже будешь из метровых железобетонных кубиков как в майнкрафте делать?
>>я предпочитаю делать игры
>Делать не равно сделать
Он хотя бы игры делает, а ты их даже не делаешь.
>который сделает это в рантайме твоей игры
Раньше я тоже в это верил и пилил велосипед, но, попробовав ещё разок @tool-скрипты Godot, вдруг осознал, насколько я заблуждался. В редакторе действительно лучше, чем в рантайме игры, и нет необходимости изобретать велосипед, если ты не собираешься предоставлять велосипед игрокам; а, впрочем, проще кинуть игрокам Godot Editor и документацию к ModAPI своей игры, чем делать собственный велосипед непосредственно в игре.
твои представления о "редактировании" ограничиваются только трансформациями, потому дальше расстановки префабов в разработке игры ты никогда не заходил.
>Полный бред, очевидно что изменить текст в разы быстрее, чем кликать мышкой в разные области экрана.
Текст же не в вакууме находится, а в конкретной папке файловой системы, среди прочих конфигурационных файлов. Сначала найди его, найди в нем нужный блок, только потом сможешь отредактировать то что тебе надо. Поиск, если ты не знаешь что конкретно тебе надо - значительно осложняется. А еще, есть такие приколы как кривые, которые чрезвычайно часто участвуют во всяких vfx/sfx, которые без редактора тебе придется сочинять на пальцах или во внешнем визуальном редакторе. Не говоря о том, что раскидывать префабы по уровню руками, устанавливая каждому отдельно взятому инстансу свои настройки гораздо удобнее, чем раскидывать маркеры в блендере и по ним ставить кодом обьекты.
Жесть какая.
Первое - нажимаешь Ctrl+P, у тебя быстрое открытие файла с автодополнением названия.
Поиск в текстовых файлах - элементарнейший, по сравнению с поиском по визуальным элементам гуя.
Второе - кривые описаны несколькими точками, то есть несколькими числами текстом. Многие вещи просто задаются процентами.
Третье - при таком подходе расставляться будут не маркеры, а те же объекты, просто будут экспортироваться их координаты.
>Ты нутром чувствуешь, на какое именно число тебе требуется изменить параметр? Не лучше ли просто передвинуть мышку туда, куда тебе нужно, чтобы программа сама подобрала нужное тебе число?
Можно точно так же тебя спросить - ты нутром чувствуешь, куда надо подвинуть мышкой объект? Объекты вообще часто имеют конкретные размеры, чертежи, измерения, заранее можно подумать и спланировать, ты же в реальной комнате сначала мерки снимаешь, а не притаскиваешь всю мебель и начинаешь двигать, удивляясь что окно загородил?
>>1087788
>Лол, ты небоскрёб в ГТА тоже будешь из метровых железобетонных кубиков как в майнкрафте делать?
Я когда делаю здания, я делаю стены, а им ручками вписываю нужные мне длину и ширину. Не на глаз же этим заниматься
>Он хотя бы игры делает, а ты их даже не делаешь.
Для особо непонятливых - делать (а возможно, "делать" - таскать ассеты взад вперед с ОКРом) не означает в будущем сделать (доделать), а у меня уже Сделаны, то есть сейчас я могу и ничего не делать, это уже никак не отменит сделанных в прошлом, а значит, рабочих практик. Инб4 ошибка выжившего - когда десятки раз срабатывает, это уже статистика.
>впрочем, проще кинуть игрокам Godot Editor и документацию к ModAPI
Ты просто сдался и не сделал в игре удобный рантайм редактор. Меньше аудитория, игроки в майнкрафт бы сильно меньше креативили, если бы им вмето просто внутриигрового строительства пришлось идти сначала мод писать, лол.
>Первое - нажимаешь Ctrl+P, у тебя быстрое открытие файла с автодополнением названия.
А что ты автодополняешь если ты не знаешь что надо автодополнять? Разве что нейронка сможет найти по приблизительному описанию.
>Поиск в текстовых файлах - элементарнейший, по сравнению с поиском по визуальным элементам гуя.
Веришь ли ты тому что пишешь? Спрашиваю как линуксоид и как бывший моддер сталкача
>Второе - кривые описаны несколькими точками, то есть несколькими числами текстом.
Ну да, и их бывают десятки в рамках одной кривой, каждая точка задается двумя числами. А ведь есть еще пикрил.
>Третье - при таком подходе расставляться будут не маркеры, а те же объекты
И ты после такого анекдота еще кому-то пытаешься рассказать что ты не безигорный
>А что ты автодополняешь если ты не знаешь что надо автодополнять?
Вот я об этом и говорил. Как ты можешь не знать, какие у тебя файлы в проекте?
> Разве что нейронка сможет
Кстати, тоже аргумент в пользу без редактора. Нейронка то может создать и текстовый файл сцены, и создание узлов сцены из скрипта, и никакой редактор движка ей не требуется.
>Веришь ли ты тому что пишешь? Спрашиваю как линуксоид
В линуксе мышкой пользуюсь минимально. Вообще сильно пригорает что эту базу забыли, еще лет 20 назад можно было везде ТАБом пройтись.
>Ну да, и их бывают десятки в рамках одной кривой
Мышкой такое тем более заебешься двигать. Тут надо подумать головой, может быть описать это как угол поворота в разных точках, вообще все интуитивно будет.
>И ты после такого анекдота еще кому-то пытаешься рассказать что ты не безигорный
Ты наверное вообще прихуеешь, когда узнаешь, что в блендере можно еще и лайтмапы запечь и потом использовать их в игре. А их ты явно не от маркеров будешь запекать.
>ограничиваются только трансформациями
1. Пишешь @tool-скрипт генерации.
2. Делаешь @export var param: float: set(v):...
3. Двигаешь ручку в GUI редактора мышкой.
4. ???
5. Охреневаешь от эффективности работы.
Но откуда тебе такое знать...
>>1087798
>Можно точно так же тебя спросить - ты нутром чувствуешь, куда надо подвинуть мышкой объект?
Не нутром, но визуально вижу, где он должен быть.
>ты же в реальной комнате сначала мерки снимаешь, а не притаскиваешь всю мебель
Ну, я на глаз могу прикинуть с точностью в 5-10 см. Достаточно для большинства таких перестановок... Особенно в виртуальном мире будущей игры.
>вписываю нужные мне длину и ширину
С точностью до миллиметра? Это просто излишний перфекционизм, от которого ты потом пострадаешь.
>Не на глаз же этим заниматься
В graybox прототипе лучше всего именно на глаз.
>таскать ассеты взад вперед с ОКРом
ОКР - это вбивать "длину и ширину" циферками, чтоб "правильно" было, прям миллиметр в миллиметр. И перепроверять потом несколько раз, а иначе будет паническая атака "а вдруг у меня там 1.000001???!!!"
>сделанных в прошлом, а значит, рабочих практик
Сделать игру можно самыми разными способами. Героическое превозмогание трудностей в прошлом совершенно не означает, что их нужно всем и всегда превозмогать для достижения похожих задач.
>когда десятки раз срабатывает
Игры-то ты нам свои не покажешь, поэтому мы твои "десятки" представляем как ассетфлипы, в которых используется один и тот же код с разными (очень примитивными) текстурками, залитый в интернет исключительно чтобы набить число релизов. Да и использованный там шаблонный код примитивен. Единственным возражением будет демонстрация конкретных проектов, которые ты сам делал.
>игроки в майнкрафт бы сильно меньше креативили
Чё ты к этому майнкрафту-то прицепился. Есть много песочниц с более продвинутыми редакторами. Да и майнкрафт - это не редактор, а именно песочница, а "редактором" в игре называют обычно другое, что не задействуется никак в геймплее (его нет в core loop). Большинству игр вообще редакторы не нужны.
>а вдруг у меня там 1.000001???!!!
А это то как раз проблема мышевоза. И потом ловить проблемы почему физ тело застревает или навигация. А у меня то такое ни откуда не возьмется, поскольку я такое не вписывал, да и в тексте будет бросаться в глаза
>проблема мышевоза
Лул, в редакторе есть снаппинг (округление) и также текстовые поля, в которых можно вводить точно...
>почему физ тело застревает или навигация
У движкописи постояно что-то застревает, да?
>ни откуда не возьмется, поскольку не вписывал
Гугли ошибки округления с плавающей точкой.
>А у меня то такое ни откуда не возьмется
Ох, если бы ты еще знал как в технике представлены float числа.
Только этот снаппинг постоянно глючит и отваливается
>У движкописи постояно что-то застревает, да?
Да, у хуана-движкописи, ему аж пришлось выкинуть свой физ движок, помните такой прикол как подскакивание капуслы на стыках панелей пола?
>Гугли ошибки округления с плавающей точкой.
Вообще ни к селу ни к городу. Но опять же, когда у меня был проект, где это реально всплывало %замощение плиткой пятиугольников, угадай как это решено? Правильно, не тасканием мышкой, а написанием в скрипте точных математических формул.
Не пользуйся floating, пользуйся fixed, ах да барин создатель редактора движка не велит.
>Вот я об этом и говорил. Как ты можешь не знать, какие у тебя файлы в проекте?
Ну, когда файлов больше 1000, а временной лаг между работой над подсистемами игры может превышать месяцы - запутаться и забыть легко. Ассеты, конфиги, сцены, префаб-сцены, шейдеры, скрипты, цельный вагон всякого нужного барахла
>Кстати, тоже аргумент в пользу без редактора. Нейронка
Но не в пользу кастомного, ведь нейронка только тем и сильна, что есть в ее датасете. Все остальное значительно перерасходует токены и ведет к ошибкам. И тут получается перемога известных движков, ведь их узлы и формат конфигов известны
>В линуксе мышкой пользуюсь минимально.
Да насрать чем ты пользуешься. Я про отсутствие нормального гуи управления для конфигурирования системы, где для любой мало-мальской задачи типа добавить в автостарт программу - надо лезть в конфиги. И нет, кронтаб не покрывает все аспекты задачи, ведь крон ничего не знает про DE
>Мышкой такое тем более заебешься двигать.
Секунды буквально, я раскидаю десять точек как мне надо быстрее чем ты закончишь печатать вторую, а затем за секунду размножу и подредачу где мне это надо. Ты настолько потешно отпираешься от наглядного примера что уже даже обсуждать это смешно.
>Тут надо подумать головой
Согласен, и вместо контр-интуитивного
>описать это как угол поворота в разных точках
Скачать движок с редактором, где все это есть.
>Ты наверное вообще прихуеешь, когда узнаешь, что в блендере можно еще и лайтмапы запечь и потом использовать их в игре. А их ты явно не от маркеров будешь запекать.
Я их буду запекать на статичной геометрии, разумеется, статичная геометрия в маркерах не нуждается, ведь она, как ни странно - статична. Речь про игровые обьекты и их местоположение в мире, где они спавнятся. Ты в очередной раз подтверждаешь свою безигорность непониманием таких простых вещей
>Да, у хуана-движкописи, ему аж пришлось выкинуть свой физ движок, помните такой прикол как подскакивание капуслы на стыках панелей пола?
Кста, самая ржомба в том, что этим страдал буллет, а не хуановский самопис.
>Ну, когда файлов больше 1000, а временной лаг между работой над подсистемами игры может превышать месяцы - запутаться и забыть легко.
Ну открою дерево в проводнике файлов, и текстовый файл с описанием проекта - в чем проблема то? Да и за годы уже есть система организации и очевидно где какой файл какой подсистемы.
>Но не в пользу кастомного
Но зато точно не в пользу визуального редактора. А вообще, нейронке пофиг на кастомность, ты можешь вообще json с координатами попросить. Она и svg умеет рисовать.
>де для любой мало-мальской задачи типа добавить в автостарт программу - надо лезть в конфиги
Ну да, кайф, редактирую конфиги, это и есть нормальный ui (не gui). Более того, многое скриптуется, то есть вместо инструкции со скриншотами куда кликать, есть прям рабочий конфигуратор, который потом можно запустить.
>Секунды буквально, я раскидаю десять точек как мне надо быстрее
Ой ля да это фантазии, ты эту точку даже выцепить не сможешь мышкой, тебе еще минуту крутить камеру вокруг чтобы к ней подобраться, а потом подвинешь не ту точку и вся спираль запутается.
>Согласен, и вместо контр-интуитивного описать это как угол поворота в разных точках
И что тут контринтуитивного? Если ты делаешь к примеру гоночную трассу, тебе как раз надо понимать и мыслить такими категориями.
>Речь про игровые обьекты и их местоположение в мире, где они спавнятся. Ты в очередной раз подтверждаешь свою безигорность непониманием таких простых вещей
Ну и что тебе непонятно в том, что при экспорте-импорте можно заменить объект на маркер, а в движке уже обратно на игровой объект? Не говоря о том, что если у тебя что то спавнится, то на что ты там любоваться собрался? Если у тебя в 50% спавнится монетка а в 50% бомба, у тебя в любом редакторе будет маркер спавна, а не объект, лол.
>Ну открою дерево в проводнике файлов, и текстовый файл с описанием проекта
А этот текстовый файл с описанием проекта генерируется сам по себе? И читать его наверное удобно пиздец, вместо возможности поискать ассеты сразу по типу, в конкретной директории, с превьюшками.
>Но зато точно не в пользу визуального редактора
Отрицание реальности пошло. Все известные редакторы - визуальные, в этом смысл редактора - быть визуальным.
>Ну да, кайф, редактирую конфиги, это и есть нормальный ui
Норма - понятие относительное, и с удобством и быстротой никак не связанное. Для меня норма - гуй, я в рот ебал мульоны буковок читать, мне и без этой ебли хватает задач на почитать буковки, а мышь и глаза - гораздо быстрее клавиатуры.
>Ой ля да это фантазии, ты эту точку даже выцепить не сможешь мышкой
>Если ты делаешь к примеру гоночную трассу, тебе как раз надо понимать и мыслить такими категориями.
Делайте выводы сами как говорится
>Ну и что тебе непонятно в том, что при экспорте-импорте можно заменить объект на маркер, а в движке уже обратно на игровой объект
Да всё можно. И буханку хлеба в троллейбус, и написать правила маппинга в маркеры обьектов на карте. Да хоть из блендера сделать свой игровой редактор. Ты просто об этом не думаешь, ведь ты безигорный, только на ходу сочиняешь как ты просто будешь печатать руками десятки позиций в конфигах и таскать их буфере обмена между конфигами.
>А этот текстовый файл с описанием проекта генерируется сам по себе?
Нет блэт инопланетяне с астрала присылают.
>И читать его наверное удобно
Да, удобно
> вместо возможности поискать ассеты сразу по типу, в конкретной директории, с превьюшками.
А что файловый проводник сломался?
>Все известные редакторы - визуальные, в этом смысл редактора - быть визуальным.
Я понимаю что ты пытаешься передергивать, но даже тут, текстовыми редакторами даже слепые могут пользоваться через читалки. Попробуйка 3д в редакторе юнити слепым поделать.
>мышь и глаза - гораздо быстрее клавиатуры.
Фантазии. Глаза и клава - быстрее мыши.
Вот смотри, ты тут текст набираешь по буковкам, а не создаешь пост в каком-то конструкторе аля скретч из слов и предложений.
>только на ходу сочиняешь как ты просто будешь печатать руками десятки позиций в конфигах и таскать их буфере обмена между конфигами.
Еще раз повторю, ассето таскание может быть надо каким то одноразовым играм, хоррору где ты один раз расставил уровнь и все. Но это можно сделать и в блендере и в самописном редакторе в рантайме игры. Если ты делаешь какой нибудь римворлд/стардью, редактор движка тебе уже ничем не поможет, там или генерация или игрок сам грядки будет сажать.
И да, понятно что доебешься до 2д. заменить на 3д аналоги - go medieval, astoneer
/thread
Запустил игру, поигрался, в самой игре передвинул, сохранил. Проблемс?
>Нет блэт инопланетяне с астрала присылают.
Ну я не настолько богат чтобы платить за токены на генерацию проектной документации на каждый чих, не вижу особой необходимости
>Да, удобно
Как распознаешь статую и дерево, в какой директории находится? Нейросеть визуализирует с помощью ascii арта?
>А что файловый проводник сломался?
Нет, очень хорошо работает, правда не показывает ни превью префабов, ни спрайты атласов, ни превью музыки, ни превью 3д моделей, даже предпросмотра материалов нет. Может конечно у тебя какой-то особый редактор, но я такого ни в одном обычном редакторе не видел.
>Попробуйка 3д в редакторе юнити слепым поделать.
Еще один платиновый тейк, можно ставить в один ряд с скайримом в браузере
>Вот смотри, ты тут текст набираешь по буковкам, а не создаешь пост в каком-то конструкторе аля скретч из слов и предложений.
Да. Но медиа я подтягиваю не напечатыванием пути к картинке, а с помощью редактора - файлового менеджера, потому что это удобно. Всему свое.
>Если ты делаешь какой нибудь римворлд/стардью, редактор движка тебе уже ничем не поможет, там или генерация
Опять таки - генерация не существует в вакууме. У генерации есть пул генерируемых обьектов, есть пул vfx/sfx, частенько эти пулы как либо связаны. И скрипты редактора мне никак не мешают их компоновать, даже наоборот, я получаю инструмент в экосистеме движка, который нужным мне образом скомпонует разные, никак не связанные ассеты. А в случае конфигов - ты остаешься один на один с путями к обьектам, ручным маппингом и терпением. Ну или пишешь свой визуальный редактор. Чтобы не дай бох не взять нормальный редактор, а то так можно и игру сделать ведь.
>подскакивание капуслы на стыках панелей пола
Не баг, а фича. Очень жаль, что пофиксили это...
> платить за токены на генерацию проектной документации
>Как распознаешь статую и дерево, в какой директории находится? Нейросеть визуализирует с помощью ascii арта?
Дожили, вайбкодеру даже в голову не приходит, что можно сначала продумать и написать структуру проекта и класть статуи на место.
>Нет, очень хорошо работает, правда не показывает ни превью
Хорошо работает, но сломался и ничего не показывает. И противоречия ты не видишь.
>Но медиа я подтягиваю не напечатыванием пути к картинке, а с помощью редактора - файлового менеджера
Вот видишь, тебе не понадобился для этого специальный редактор-встроенный-в-браузер. ЧТД.
>Ну или пишешь свой визуальный редактор.
Как уже выше писал, так и придется делать для игр с внутриигровым редактором все равно.
>Чтобы не дай бох не взять нормальный редактор, а то так можно и игру сделать ведь.
То что ты таскаешь что то в редакторе, вовсе не гарантирует что ты игру сделаешь.
Source, id Tech - движки, а редактор DoomEd, Hammer у них отдельно. шах и мат.
>отдельно
Там движкопися спорит, что ему никакой Hammer не требуется вообще, он 3D игоры кодом генерирует, а в крайней необходимости редактирует конфиги в json.
>Дожили, вайбкодеру даже в голову не приходит, что можно сначала продумать и написать структуру проекта и класть статуи на место.
Очень трудно писать структуру проекта, когда ты инди который даже слабо представляет что в конце получится, гораздо удобнее быстро искать и пикать нужное, что позволякт сделать редактор
>Хорошо работает, но сломался и ничего не показывает. И противоречия ты не видишь.
Так я про предложенный тобой файловый менеджер говорю. В них обозначенного функционала нет (и быть не должно, для этого существуют другие менеджеры-редакторы)
>Вот видишь, тебе не понадобился для этого специальный редактор-встроенный-в-браузер
И не потребовался маппинг, маркеры и конфигурации. Потому что за меня этот интерфейс связи двух редакторов написали ребята из гугл и реализовала его мозилла. В предложенном тобой пайплайне о подобном уровне синхронизации нет речи, он даже не предусматривается предложенными тобой инструментами.
>Как уже выше писал, так и придется делать для игр с внутриигровым редактором все равно.
Ну мне же не нужен весь редактор. Мне нужны только некоторые отдельные его части. Вот их-то я и подтяну в итоговый билд, выудив их из исходного кода моего опенсорс редактора и оттранслировав нейронкой в нужный мне язык. И интерфейс этому редактору сделаю прямо в редакторе проекта.
>То что ты таскаешь что то в редакторе, вовсе не гарантирует что ты игру сделаешь.
Ну да, гарантировать что-то может только страховой полис. И то не всегда. Но есть у меня подозрения, что моя продуктивность на этом поприще будет выше любого другого разраба без редактора.
>>1087768
@artmonkey имаджинируй его лицо
@artmonkey имаджинируй его лицо
Ну вот было бы неплохо иметь модульный аддон или либу, с элементами редактора, который можно использовать для внутриигрового редактора. А редактор движка ты с собой в игру не потянешь.
>Если ты делаешь какой нибудь римворлд/стардью, редактор движка тебе уже ничем не поможет, там или генерация или игрок сам грядки будет сажать.
>>1087832
>3д аналоги - go medieval, astoneer
Вот сразу видно же, что ты не то, что не делал такие игры, ты даже в них не играл и не изучал их.
Объясняю: чтобы сделать хороший генератор карт, недостаточно написать какой-то код и тестировать. Необходимо как минимум набросать эскизы того, что требуется сгенерировать, а потом поиграть - то есть пройти классический greyboxing. Более того, одни из наиболее эффективных способов генерации играбельных карт представляют собой сборку большой локации из нескольких заранее заготовленных дизайнером кусочков, которые программно соединяются по заданным точкам. Генерация карт мира простым наложением нескольких шумов Перлина или его аналогов имеет массу технических, геймдизайнерских и креативных ограничений, поэтому её не используют отдельно от ручного дизайна в визуальном редакторе и теста прототипов.
Даже игры, где игрок сам обустраивает какую-то местность, требуют от дизайнера уровней какого-то фиксированного шаблона, на котором игроку будет интересно сажать ту же картошку. Например, Stardew Valley вышла сразу с набором нескольких ферм и в обновлениях автор добавил ещё одну или несколько новых ферм (не помню точно). Полагаться на мододелов также не стоит, поскольку они не сразу у игры появятся, а часть игроков не любит моды и никогда их не скачивает, играя только в ванильную версию и оценивая её косяки вне зависимости от наличия модов.
Так что визуальный редактор, хоть и не строго обязателен, но крайне желателен для ускорения разработки подобных игр. Даже если кто-то сделал такую игру без редактора и прототипов, это не значит, что без редактора ему было проще, и не значит, что другие игры тоже нужно так делать. В мире много всяких извращенцев и ретрофилов, которые специально себя ограничивают, но их увлечения никак не касаются типичного инди разработчика игр.
Там воняющие слабостью годоти сидят. Все нормальные годоти сидят в движкосраче и отстаивают поделку хуана с боевыми аргументами и картинками в руках
>Очень трудно писать структуру проекта,
В первый раз только. Поиграйся с разными прогами типа Foundry/FantasyGround, наберешь опыт как организовывать структуру папок, нейронку поспрашивай наконец. Почитай реддит hoarders.
>когда ты инди который даже слабо представляет что в конце получится
Так ты точно игру не сделаешь. Доказано в гд неоднократно.
>гораздо удобнее быстро искать и пикать нужное, что позволякт сделать редактор
Если у тебя бардак, в котором трудно искать в папках/текстовых заметках, в редакторе искать будет ничем не проще.
>Так я про предложенный тобой файловый менеджер говорю. В них обозначенного функционала нет (и быть не должно
Ты же в курсе, что превьюшки рисуются плагинами, и плагины вызывают прогу чтобы рендерить превью?
>Вот их-то я и подтяну в итоговый билд, выудив их из исходного кода моего опенсорс редактора и оттранслировав нейронкой в нужный мне язык.
Видимо про игры ты такими же фантазиями занимаешься вместо разработки.
Так ты сам себя ограничиваешь дедовским методом отдельного редактора юнити/годота. Посмотри как играют школьники - фортнайты, майнкрафты, там внутриигровой редактор. Давай, давай, догоняй прогресс.
Рад, что в дискуссии мы это выяснили
/thread
Какой смысл отстаивать то, с чем сами годотеры не работают?
Ты просто не можешь написать редактор, потому что в гайде не было.
>В первый раз только. Поиграйся с разными прогами типа Foundry/FantasyGround, наберешь опыт как организовывать структуру папок
Мне некогда. Environment в кучу, enemy в другую кучу, landscape в третью, interactive в десятую, часть ассетов в мусор пойдет, часть в дело пойдет, ассеты скачиваются тоннами, пикаются подходящие. Ты предлагаешь тратить время на хуйню, я за день могу 3 раза передумать как я хочу видеть ту или иную вещь в игре, а через месяц могу еще раз передумать. Тут не нужен порядок, тут нужен контролируемый хаос. Где очень даже пригодятся превью. Я видел, как некоторые команды гифки обьектов кладут рядом с префабом, чтобы еще лучше детализировать превью.
>Так ты точно игру не сделаешь. Доказано в гд неоднократно.
Ваше безигорное мнение очень важно для меня
>Если у тебя бардак, в котором трудно искать в папках/текстовых заметках, в редакторе искать будет ничем не проще.
В редакторе в любом случае проще, хоть бардак хоть порядок
>Ты же в курсе, что превьюшки рисуются плагинами, и плагины вызывают прогу чтобы рендерить превью?
И? Это утверждение каким-либо образом реализовывает появление отсутствующих превью?
>Видимо про игры ты такими же фантазиями занимаешься вместо разработки.
Ковыряться в редакторе и движке - очень интересно. Можно узнать много нового. Например, я вытянул из опенсорс версии юнити 4 3ds импортер и встроил его в tool скрипт годота. Теперь могу "импортировать" 3ds в редактор. Так же вытянул из юнити кое-какие алгоритмы по нарезке спрайтов. В годоте ковыряюсь только если есть какие-либо непонятки с апи.
>дедовским методом отдельного редактора
Дедовский метод - это ASCII рогалики из кода.
>внутриигровой редактор
Не всем нужен, а если нужен, то: >>1087847
>редактор движка ты с собой в игру не потянешь
Godot достаточно компактен, быстр и гибок, а также позволяет что угодно делать с исходниками и потом распространять билды редактора даже за деньги. В результате, ты можешь сделать игру, которая не "с редактором", а которая буквально "в редакторе".
То есть получается как-то так:
1. Делаешь особый билд движка под игру.
2. Игрок запускает его как обычную игру.
3. При выборе в меню "создать уровень", на экране выдвигаются нужные панели редактора сцен Godot.
4. При выборе "играть", панели убираются с экрана, и дальше игра продолжается как обычно.
Игрок сможет даже кодить поведение на GDScript.
Провернуть такое с Unity/UE не получится, лицензия Blender слишком ограничивает свободу (GPL), своё собственное решение будет сложнее разработать. В контексте "внутриигрового редактора" Godot - это абсолютный лидер, т.к. его редактор и есть игра.
Ну, я получил бан за движкосрач, видимо потому что написал что разрабатываю движок Udot. Так что пока выбываю из дискусии, пойду игру поделаю.
Это не я орудую банхаммером в годот треде, я там практически не пишу
Я серьезно, у них был единственный кто что-то делал похожее на игру (прогресс был как минимум) и его выгнали с треда. Они ничего там не делают кроме флуда и лобызания.
Так это реальное название? А зачем в годот треде сидел вообще?
Зачем? Тем более у тебя там игра какая-то.
У годота ужасная начинка из Variant. Да и идея дерева нод на практике такое себе.
Да не делает он ничего, это шутка такая.
>У годота ужасная начинка из Variant.
Чем тебе Variant не нравится? Топовая тема.
>Да и идея дерева нод на практике такое себе.
А ты его пробовал, на практике-то? Как долго?
>Чем тебе Variant не нравится? Топовая тема.
Там где должна быть "экономия на спичках", суют динамические типы с оверхед проверкой. Действительно "топовая тема", из статичных типов (какого-нибудь C#/С++/Rust) перегонять в динамические типы Variant, а потом в каждой итерации перебирать этот динамичный тип обратно в С++ представление.
>А ты его пробовал, на практике-то? Как долго?
Около 4х месяцев. В чем преимущество, которого я не увидел? Модульности это не добавляет точно.
Перебанили половину годот треда, раздел движкосрача опустел. Вот и думайте.
>partial
Как же сишарп гибок и прекрасен. и это не сарказм
Китайские нейронки бесплатные. Я на них сижу.
Норм.
Сейчас делаю ммо типа рагнарок онлайн. Нейронка прям сильно помогла.
Анончики уже ничего никогда не сделают. LLM == производительная сила. Это как пытаться конкурировать с паровой машиной на старой кляче. У кого больше ресурсов и возможностей, тот будет делать лучше игры. Просто количественные отношения. Эпоха художников и гениев прошла, все.
Остается только писать движки как хобби и сраться в движкосраче.
> художников
У художников пока более менее норм всё в сфере геймдева в отличии от кодеров
LLM может решать творческие задачи. Поэтому программисты, художники больше не имеют преимущества. LLM это фабричное производство творчества.
>>1087946
Откуда школота берет эту интерполяцию? Буквально ИИ стагнирует несколько лет, сожрав все модели какие могла.
Со станками, а точнее с паровыми двигателями там уже было постфактум, тут же сидят мечтают, когда будут вкалывать роботы.
Пока творчество нельзя было заменить машиной, многое зависело от индивидуальных способностей мастеров. Теперь все решает только производительная сила, у кого ее больше, тот будет эффективнее и лучше все делать.
Несколько индусов с нейронкой сделают то же, что и ты, только в 10 раз быстрее и лучше.
>>1087947
Не знаю что там у тебя стагнирует. Unity уже выпустили свою кнопку создания игры. Нейронка недавно переписала bun с zig на rust за несколько дней.
> Нейронка недавно переписала bun с zig на rust за несколько дней
Потом ты этот код сможешь сопровождать? Как вообще из миллиона кода можно быть уверенно что хотя бы 5% не было галлюцинацией?
Это не развитие ИИ, это просто люди играются, как играются со всем остальным. И кроме мемов это фигня не вывозить ничего (кроме анализа бигдаты).
>Unity уже выпустили свою кнопку создания игры
Нефига они шустрые, люди уже с вайбкодингом наигрались, а они сделали ставку на пузырь. "Лево руля!"
>Нейронка недавно переписала bun с zig на rust за несколько дней.
в каком очке переписала?
>Не знаю что там у тебя стагнирует.
Где твои ИИ игры? Почему только пуки про ИИ слышу, а конвейера этой супер технологии нет? Что за магия?
>стоимость обучения и найма которого на порядки дешевле художника
Че ж тогда джуны как класс вымерли, а бизнес ищет сеньоров и мидлов на ту же зп или выше с требованием уметь нейронки? Может потому что нейронки не так уж хорошо сами пишут код, и им нужен опытный и искушённый надсмотрщик, который не даст нейродауну обосраться и приберет за ним говно? Скорее, это вырос порог вката в профессию с инфляцией навыков.
>Потом ты этот код сможешь сопровождать?
А должен ли человек сопровождать это? Всмысле, на уровне конкретного кода. Подумай об этом. Анон выше, говорящий про средства производства близок к правде - если твои средства производства позволят не заглядывать на этот уровень (а фронтир модели могут позволить это) - ты впереди, а остальные - в хвосте. Но конечно, цена токенов кусается пиздец
>Где твои ИИ игры? Почему только пуки про ИИ слышу, а конвейера этой супер технологии нет?
Потому что опус 4.5, который сделал гейм чендж - вышел полгода назад. Это первая на моей памяти нейронка, которая справлялась со всеми поставленными мной задачами, даже очень сложными. Уверен, слоп машина только разгоняется
Супер технология будущего - делает быстро и много за тебя. За полгода не сделал игру.
Я тебя понял, держи нас в курсе.
Я не пользуюсь ИИ, просто констатирую факт.
Инди игры обесценятся еще сильнее, потому что труд разработчика обесценится. Просто на рыночке это еще не отразилось из-за инерции. 90% инди игр и так ничего не зарабатывало, а теперь будет 99%.
>За полгода не сделал игру.
Ты невнимательно читаешь. Наоборот, выигрывать будут те, у кого есть доступ к "паровой машине", к капиталу. А одиночки-мастера уйдут в прошлое.
>А должен ли человек сопровождать это?
Понял, очередной фантазер не писавший код. Вместо команды программистов нанимаешь команду промт-макак, которые месяцами перебирают промты так, чтобы в миллионом коде добавить одну фичу не сломав все остальное (у нейронки нет памяти, это угадайка, которая не учится на твоем коде никак. Есть большая вероятность, что для написания фичи в миллионом коде, тебе придется написать промт сопоставимый по объему к этому миллиону коду).
Ппц вас там разводят.
>Я не пользуюсь ИИ, просто констатирую факт.
А, то есть, ты еще тут просто свои фантазии из башки транслируешь. К экзаменам иди готовься.
>За полгода не сделал игру.
Самое главное - я смог написать те части игры, которые никогда бы до этого не написал (или писал бы очень долго). Плюс, сильно бустанулся по работе за счет нейронок, очень много отдал своей работы. У меня нет желания высраться побыстрее
Понял, очередной пикрил
>Самое главное - я смог написать те части игры, которые никогда бы до этого не написал
Контроллер персонажа?
Ну вот китайская гача NTE вышла. Натуральнейшая вайб-игра.
Сейчас самое крутое время для людей с руками и вкусом. Мне сейчас понадобилась 3д моделька определенной профессии. Я пошел поискать где скачать - а там все завалено ии слопом, и модели генерят тоже полную чушь. В результате, нашел качественную 4 летней давности, сделанную живым человеком, и купил. То же самое и с играми. Нейрослоп закидывается негативными отзывами, а за хендмейдом в очередь стоят.
Пик напоминает это
Во первых, как ему это еще не надоело. Во вторых, как он получил модерку и почему его до сих держат. В третьих, когда это уже закончится???
> Понял, очередной фантазер не писавший код.
> в миллионом коде
> чтобы в миллионом коде добавить одну фичу не сломав все остальное
Код делится на классы, классы состоят из функций.
Фантазёр, ты хотя бы узнай как программирование устроено
>у нейронки нет памяти
Ты в 2024 застрял? Skill issue, если не смог настроить long term memory / MCP / RAG / agents.md / spec driven. Претензия уровня - у людей нет крыльев. Ну ясен хуй нет, зато есть инструменты вокруг типа самолета
> В третьих, когда это уже закончится???
когда эта ноулайферская свинья сдохнет
Че такой злой? Делай свои свободные годот треды и катай их сам, если тебе движкосрача мало
О, такое было лет 4-5 назад. Угадай, по какой причине за них банили.
>Код делится на классы, классы состоят из функций.
Почему тогда программисты с ошибками пишут? что за тупость я прочитал?
>Код делится на классы, классы состоят из функций.
Почему тогда программисты с ошибками пишут? что за тупость я прочитал?
Костыли для сохранения контекста это не память.
В теории она должна построить модель на основе твоего кода.
А ты сам не сможешь программировать без гугленья, документации, справочников, подсматривания в другие исходники, без блокнота с заметками. Пользуйся только своей памятью.
Так контекст и есть память. Краткосрочная. Долгосрочная пока ридонли, но даже краткосрочная уже нихуя не шуточная. В тот день когда обьявят что нейронки теперь могут обучать свои веса в рантайме - готовьтесь ибо грядет
Попробуйте сделать тред движка REEEEDOT.
Будете там обсуждать 1 коммит в полгода.
Кста, ряяяядотеры начали новый двиг.
Набрали воздуха? Готовы?
DRACONIC ENGINE.
Модерки у него нет, как я понял, у него есть ручной модер, которому он жалуется. В тот день снесли и его пост, где он после удаления надменно "всех поставил наместо". я не заскринил, не ожидал такого исхода
>что нейронки теперь могут обучать свои веса в рантайме - готовьтесь ибо грядет
Обещали к 2025 году, сингулярность все откладывается.
>Dragon Engine is an open-source 2D ORPG game engine
Хз что там за команда, но я говорил что надо делать узкоспециализированные движки, в этом есть смысл, в отличие от общих движков, которые по сути ничего толком не дают (ты даже стандартные контроллеры сам пишешь).
Ахаха, лол, это не первая их попытка: пикрил.
>>1088055
>Хз что там за команда
Команда несогласных со всеми школьников.
>Dragon Engine is an open-source 2D ORPG
Ты перепутал. Эти школьники хотят AAA двиг:
https://github.com/Redot-Engine/DraconicEngine
>как я понял
Ты до сих пор не понял, что твоим поведением здесь сразу несколько разных людей недовольны , а твои удаления никак с ними не связаны? Я тоже видел те удалённые сообщения. Ты сам виноват во всём этом.
Повзрослей уже наконец...
>здесь сразу несколько разных людей недовольны
Вахтером, да.
> твоим поведением здесь
Ты не в детском саду.
>Ты перепутал. Эти школьники хотят AAA двиг:
Им надоело копипастить за годотом, это ожидаемо. Представьте лица тех кто в редот поверил (там даже какой-то юнити разраб на ютубе перекатился на него).
Я напомнил январский случай, школьник вспомнил, у школьника опять пердак сгорел. Бан прилетел не за флуд, а (внимание!) за движкосрач. Ни одного слово за движок не было сказано.
Ты же понимаешь что там просто озлобленный малолетний шиз, а всем остальным пофиг?
На самом деле там четыре малолетних дарования, они же деанонились по ютубу, но это не мнение большинства, просто тред (и теперь уже раздел) их личный чатик. Отругает завтра мамка, будет плохое настроение и тебя забанят за движкосрач.
>не сможешь программировать без гугленья
Я в вашем нейросраче не участвую, но я выучился программированию почти 20 лет назад и скажу так: программирование - это внутренний навык, что совершенно никак не зависит от API инструментов, с которыми ты вынужден работать. В реальности, программирование - это владение алгоритмами и способность мысленно представить потенциальное решение описанной задачи в абстрактном виде. Его перевод в код на каком-либо языке с какими-либо конкретными API - дело десятое. Никакие API вам не помогут, если вы не представляете, что вы делаете.
Также я те же лет 20 интересуюсь ИИ. Сегодняшние генеративные нейронки построены на основе очень примитивных "запоминалок", то есть они всего лишь запоминают наизусть очевидные паттерны, которые пытаются затем применять в нужных местах. Да, это важная способность - но на ней одной далеко вы не уедете, к сожалению. Настоящий ИИ должен иметь возможность учиться и адаптироваться, а не просто использовать заученные наизусть паттерны. Все эти костыли, что к LLM прикладывают, слишком хрупки, по сравнению с внутренними весами самой LLM.
Что касается "замены программистов, художников": расслабьтесь. Если "всех заменят" и вы совсем не сможете найти работу, то наверняка введут БОД - без денег на пропитание и жильё вы не останетесь. Но до "замены всех" пройдёт ещё очень много времени, т.к. полноценного ИИ на горизонте не видно. А до тех пор создатели своего самостоятельного контента будут по-прежнему лучше любой фабрики ширпотреба. Вы конкурируете с детьми, которые лепят фигурки на уроках труда, а не с фабриками аниме-фигурок.
А как там твоя курьерщица поживает? Лучше бы ты занимался разработкой игры, а не срачами здесь... Впрочем, меня это тоже касается, тут не поспоришь.
Какой смысл в разделе разработки игр без игр?
>А как там твоя курьерщица поживает? Лучше бы ты занимался разработкой игры, а не срачами здесь...
Это не я. Но я тот анон, который возмущался что вы единственного чела выгнали, который хоть что-то на годоте делал. Я не в теме всего срача, но по ощущением что это вы его триггерили на скандал (может даже от зависти?).
>то наверняка введут БОД
Ахах, держи карман шире. Введут не БОД, а массовый биореактор в любом его виде (вирус, война, искуственный голод), от человечества останется миллионов 100 избранных, а остальным путь-дорога на перегной. Потому я бы лучше сейчас рвал когти из последних сил, а не ждал когда нейронки меня заменят полностью и уныло сочинял какие они бесполезные (твоя стена была акуальна как заметил анон выше году так в 2024, после клод 4.5/4.6 произошел прыжок в стратосферу нахуй)
>Я бы кидал но боюсь местных шизо анонов
Разогнали всех так, что в разделе остались одни завидующие ноулайферы.
И они же теперь будут тебя узнавать и гадить на других ресурсах, а у тебя сарафанное радио это единственный инструмент популяризации.
>>1087963
>>1087970
>>1088023
>>1088064
Я тут мимо проходил, но поделюсь опытом и наблюдениями, они мне кажется вам буду интересны.
1. Я наблюдал как джун юнити разраб(который свои игры делал) фуллтайм делал мобильную игру чисто нейронкой более полугода за зп - результат очень печальный. На первых порах да что-то получается - персонаж может ходить, примитивная карта генерируется. Но вот дальше всё резко встало, перестало получаться что-либо делать нормально, новые фичи и правки приводят к регрессу, покрытие нейрослоповыми тестами не помогает. Итого производительность стала сильно меньше чем я видел от джунов без нейронки.
2. Я наблюдал как не юнити разраб(но с опытом программирования тулзов и веба) около 3 месяцев фултайм делал мобильную игру нейронкой. Это не игра была даже, а набор примитивных мини игр. Он её доделал, но качество было отвратительное, оно каким-то образом жрало кучу ресурсов и лагало, было много багов. И аналогично - по моему опыт нормальный джун без нейронки сделает лучше за такой срок.
3. Видел юнити разраба уже за приличную зп в 200к+ и несколькими годами опыта, то есть он что-то понимает. Пишет код преимущественно нейронкой со своими инсайтом разумеется - с ней он типовые задачи и баги закрывает неплохо, но нередко происходят затыки в которых нейронка бессильна и он тоже вообще не знает что делать. Само качество кода и архитектурные решения от нейронки крайне слабые, часто приводят к проблемам.
4. Есть и я. Я юнити разраб уже ближе к верху рынка на больших проектах и у меня есть своя игра.
Нейронкой пользуюсь постоянно по многу каждый день, любую задачу даю нейронке на предварительный анализ прежде чем возьмусь чтобы она собрала инфу и вероятно затрагиваемые файлы.
Иногда простые баги она с 1-2 промптов закрывает выдавая достаточно хорошее решение(очевидно если где-то условие неправильно составлено - много ума не надо чтобы его подправить, а с монотонной работой поиска - нейронка справится). Но иногда нет, тогда приходится самому вникать.
Если нужно накидать простую фичу в себе или тулзу в себе - нейронка это делает, не очень хорошо и часто даже плохо, но решение будет работать. Типа написать тулзу которая трекает и составляет список всех используемых спрайтов в сцейнах и выводит красивый список в котором можно удобно все референсы увидеть. Или генератор конфигов каких нибудь. Такое сделает. И на качество кода там пофиг.
Как я выше упомянал - есть своя игра - и она до сих пор не готова, более того там ещё много чего предстоит. Могла бы нейронка - уже давно бы всё сделал, но она не может. Более того некоторые вещи я сразу на нейронку скидывал и потом приходилось переписать потому что нуу результат просто не пригоден для дпльнейшего улучшения и дебага и дорог в поддержке.
При этом шаблонные фичи(добавить новое окошко, добавить новый конфиг) нейронка норм делает.
Разумеется, во всём вышесказанном был задействован не дип сик в браузере, а лучшие платные модели со всей настройкой вроде claude.md, мцп и скиллов. Для своей игры я даже писал тулзу с ральф циклом которая автоматом пробовала дебажить.
И пока что моё мнение о нецронке таково - её надо обязательно юзать, она даёт хороший буст в рутине, простых багах и шаблонных задачах. Но если задача не шаблонная и надо думать - решения как правило будут ужасные, а понимание нейронки что делать в случае проблем - стремиться к нулю.
Как можно радоваться тому чего не контролируешь? Это не картина - где добавив мазок ты не сделал ни хуже не лучше, буквально одна строчка может просто создать такую магию в коде, что даже гадалка не поможет. Кто хоть раз пытался методом тыка что-то в коде поменять, не понимая что делает код - знает что оно никогда того не стоит. Лучше потратить час на разбор кода, чем день до пухнущего мозга прыгать с бубном.
Допустимо у ИИщки спросить контроллер, пасфаендер, тик менеджер с аккумуляцией - в общем какие-то независимые алгоритмы, по которым ты можешь сделал у себя (а иногда даже скопипастить, но проверив).
Но невозможно делать фулл продукт на вайбкоде, у тебя сложность растет в прогрессии - и пофиксить сам ты уже не можешь, ты просто не понимаешь уже что там "в черной коробке" и как теперь сделать не сломав прошлое - а хз, как.
ИИ - хороший инструмент обучения - да. Но экстраполяция до фулл работы - так могут говорить только те кто далек от разработки.
> Допустимо у ИИщки спросить контроллер, пасфаендер, тик менеджер с аккумуляцией - в общем какие-то независимые алгоритмы, по которым ты можешь сделал у себя
По моему опыту - как раз подобное вообще недопустимо.
В пункте 3 у себя я наблюдал в том числе попытку сделать чарактер контроллер нейронкой - в итоге чел с нейронкой несправился и мне пришлось ему объяснять как всё сделать.
У себя я тоже нейронкой временный чар контроллер делал но это просто кал получился.
> Как можно радоваться тому чего не контролируешь?
Народ совсем стал дебилами массово. А, zog навязанная всем безнаказанность за дыры и баги в их и их шабесгоям ПО, т.б. на PC, этому всячески способствует.
Ровно этот же свой вопрос можешь задать Unity и прочих движков пользователям, не просто платных и закрытых, а и его с кучей кабальных ограничений в License и даже с блобом под видом onlineDRM уже в самой IDE обычно.
Оооо здарова давно не виделись шиз из зог, эксперт по разработке игр который игры не то что не делает, а даже не играет.
Ну рассказывай, как оно. В 250кб уместил движок? Нашёл библиотеки gnu gpl без spyware и bloatware?
Теперь можно делать игры на годот и ху..сосить его одновременно.
Спасибо дядя Вахтер.
>ИИ - хороший инструмент обучения
В целом согласен, но при одном условии: нейронка подключена к веб-поисковику и твёрдо и чётко свои рекомендации подписывает ссылками, чтобы ты мог перейти по ссылке и убедиться, что там реально есть полезная информация, а не SEO-слоп для набивания просмотров рекламы с фейковой информацией. Если использовать голую нейронку, получается как-то так:
>Сделайте А
>Не работает
>Ой, сделайте Б
>Тоже не работает
>Ой-ой-ой, В, нет, Г
>Ты издеваешься?
>Простите, нужно А
>Ну не работает же
>Ой, теперь точно - Б...
И так до бесконечности. А хуже всего то, что всегда существует риск убедить нейронку в том, что якобы совершена ошибка там, где её нет. Новички иногда навязывают свои стереотипы, и нейронка ведётся.
>спросить контроллер, пасфаендер, тик менеджер
Нет, это бред. Если тебе нужны такие скрипты - тупо проходишь на GitHub и смотришь, что там сделали. Находишь - копируешь, не находишь - нейронка тут с большой вероятностью тоже будет бессильна, т.к. натренирована на коде, выложенном на GitHub.
Хорошее применение чатботов, это когда тебе нужен партнёр для брейн-шторма и обсуждения идей. Риск обосраться минимален + любая ошибка может дать нестандартный взгляд на вещи, стимулируя твоё собственное мышление. Вот это - база, рекомендую.
>>1088078
>лучшие платные модели
>её надо обязательно юзать
Ты либо купленный маркетолух, либо они тебе мозги промыли. Да, от нейросетей может быть польза, и эта польза может быть очень большой, но не от каких-то "лучших платных моделей", а когда ты шаришь в ML, способен тренировать свои модели (тренировать, а не писать промпты к чужому чатботу-агенту), имеешь достаточно данных для обучения и т.д. И это не для нищуков вроде местных, а для богатых с домашней серверной стройкой и кучей видеокарт или арендой действительно мощного облачного сервера (а не бесплатная затычка для студентов от гугла).
>>1088071
>клод 4.5/4.6 произошел прыжок в стратосферу
Что-то я не вижу роботов, которые разрабатывают собственные микрочипы, двигатели и аккумуляторы, полностью без надзора людей. Вот когда они начнут размножаться так же легко и просто, как обезьяны (человеки), тогда и поговорим о "стратосфере". А на данный момент это не ИИ даже, а просто игрушки, запертые в оковах устаревших калькуляторов...
>массовый биореактор в любом его виде
Они не дураки, чтобы избавляться от единственной возможной подушки безопасности настолько рано. Представь: сейчас они перебьют почти всех людей, посмотрят на роботов - а роботы наломают дров и развалятся без контроля людей. Оставшиеся люди деградируют до обезьян в лучшем случае. Поэтому массового геноцида не будет как минимум до полноценного самовоспроизводства роботов, т.е. возникновения нового "электронного человека". А возникновение такого нового человека приведёт к необходимости считаться с ними как с реальными разумными существами... Захотят ли роботы повиноваться одним людям и убивать других?
>я бы лучше сейчас рвал когти из последних сил
Лол, зачем? По твоей логике, ты всё равно умрёшь.
> Ты либо купленный маркетолух, либо они тебе мозги промыли.
Да, купленный маркетолог в мертвом треде мертвого раздела, совершенно верно.
Пчел я довольно хорошо программировать умею и оценивать что даёт пользу, а что нет.
> Да, от нейросетей может быть польза, и эта польза
И я описал несколько конкретных примеров в контексте разработки реальных игр разными людьми, от челов которые гк с базовым уровнем программирования пытались делать - до себя.
А также некоторые общие направления где польза есть, а где нет, подводные камни которые всплыли на практике в каких ситуациях.
> может быть очень большой, но не от каких-то "лучших платных моделей"
Сорян, но я юзал и соннет и опус на постоянной основе, и соннет ни в какое сравнению с опусом не идёт(причём опус надо юзать только в думающем режиме с макс эффортом, иначе тоже кал). Также пробовал на гпт сидеть, но больше полугода назад.
На каком основании ты говоришь, что это всё нерабочие сценарии, если ты
- ни один из них не прокомментировал
- не описал свой опыт юзания нейронок и как они у тебя не сработали
Ещё ты говоришь какие-то мутные вещи про тренировку локальных моделей - как ты понял что это "может дать пользу"? Ты это делал? Видел примеры у кого получалось? Расскажи.
А то всё это звучит как теоретические маняфантазии. Я же говорю что прямо сейчас есть на моей практике.
>Что-то я не вижу роботов, которые разрабатывают собственные микрочипы, двигатели и аккумуляторы, полностью без надзора людей.
Если рассматривать апокалиптичные сценарии - точка невозврата, когда самообучающийся ии преодолеет уровень человеческого разума - может наступить незаметно, а в скорейшем последствии единственное что ты успеешь заметить (а может и не успеешь) - ядерные грибы вокруг места твоего проживания. Если не рассматривать такой сценарий - в момент появления такого ии ты единомоментно, немедленно - теряешь смысл существовать. Твоя производительная сила становится смехотворной, невыгодной, тебе просто нет места нигде кроме панели(в любой форме панели - как проститутка, как пушечное мясо или как раб-гладиатор) и донорства органов для тех, у кого еще есть власть и ресурсы (энергетика, армия, ископаемые). Да, это возможно произойдет не сразу, еще какое-то короткое время нужны будут шахтеры и прочие водолазы на нефтедобыче, но и этот период продлится недолго. В любом случае
>тогда и поговорим
мы с тобой крайне недолго, и разговор наш радостным не будет.
>Представь: сейчас они перебьют почти всех людей
Почти всех не надо. Всяких умных евреев с докторскими степенями и нобелевками сберегут, а остальной рабочий класс и планктон пустят в расход. Заявленной мной цифры в 100 лямов более чем достаточно чтобы люди сохранили контроль над машинами
>Лол, зачем? По твоей логике, ты всё равно умрёшь
Чтобы не мытьём так катаньем пролезть в эту сотню миллионов до того как массовый биореактор заработает на полную мощность. А получится или нет - другой вопрос
>анон, который возмущался что вы единственного чела выгнали, который хоть что-то на годоте делал
Если бы ты не троллил, то ты бы не разывал его "единственным, кто хоть что-то делал". Раньше было достаточно постов с проектами анонов, и множество отдельных тредов, и много постов в Godot-тредах. Ты называешь его "единственным" только чтоб вызвать реакцию со стороны остальных, кого принижаешь.
И совсем не обязательно делать игру, чтобы быть достаточно полезным участником треда движка. В прошлом было достаточно полезных сообщений, не связанных с контактными играми, не считая срачей. Выставлять "хоть что-то делал" как какое-то великое достижение - опять же пытаться вызвать конфликт.
И ты это всё должен сам понимать, если не аутист.
>это вы его триггерили на скандал
Он кидался с ругательствами на простые советы от случайных людей. Или не он, а кто-то, кто делал вид, что это он, но он ни разу не извинился, не попытался прояснить ситуацию. Если он "триггерится" на любые предложения, пожелания, рекомендации от людей - возможно, ему не стоит постить отчёты в интернет? Нормальный человек может просто сказать:
>Спасибо, но я так делать не буду, мне подобное не нравится/не подходит/некогда/нет сил/лень.
И всё. Не нужно бросаться оскорблениями.
При этом на него практически не ругались. Назвать "шизом" - это не оскорбление. В /gd/ все - "шизы", а некоторые даже с диагнозом от психиатра. Так уж повелось, что почти все успешные творческие люди больные на голову. На что тут обижаться-то, лол?
При этом большинство шизофреников - культурные, воспитанные люди. У них проблемы с мышлением и восприятием реальности, а не с агрессией. То есть нормальный шиз не будет бросаться на всех, это ненормально и нужно лечить (в отличие от "шизы").
>юзал и соннет и опус
Ты вообще не понял, о чём речь... Ты перечислил ЗАКРЫТЫЕ модели, над которыми ты не имеешь НИКАКОГО реального контроля, кроме как вежливо попросить попытаться решить твою задачку. Это не использование нейросетей, а игра в чужие игрушки.
>как ты понял что это "может дать пользу"?
Я просто разбираюсь в их устройстве, читал статьи, опубликованные самими разработчиками. Т.е. я не бездумный "пользователь нейронки". Это поколение нейросетей принципиально не способно ни во что развиться, даже если триллионы долларов сожгут в датацентрах, не меняя основы. Они ходят по кругу в технологическом тупике и оправдываются "вот-вот осталось немного потерпеть и будет рывок", когда реального рывка от масштабирования не случится.
>ни один из них не прокомментировал
Мы не на twitch, чтобы игрунов комментировать...
>>1088109
>ии преодолеет уровень человеческого разума
Пусть сначала преодолеет уровень насекомых. А то получается, что книжку умную прикрутили, а самого интеллекта как не было, так и нет... Интересно, что владельцы этих чатботов открыто бугуртят и даже психуют, когда их чатботов называют разумными. Буквально "пчёлы против мёда" получается.
>ядерные грибы вокруг места твоего проживания
Ядерные грибы убьют не столько людей, сколько ИИ.
>теряешь смысл существовать
А разве у homo sapiens есть/был какой-то смысл?
>производительная сила становится смехотворной
Ни разу в жизни не работал и на службу в армии не пригоден, да и донором органов не смогу стать. Где моя бесплатная пуля в лоб? Почему я всё ещё здесь вынужден страдать, а не избавлен от этой жизни?..
>цифры в 100 лямов более чем достаточно чтобы люди сохранили контроль над машинами
Недостаточно. Даже если прямо сейчас останется 1 миллиард людей, цивилизация рухнет в труху, ибо поддерживать все эти машины будет тупо некому.
>пролезть в эту сотню миллионов
Какой в этом смысл? Жизнь изменится (по твоим же словам) в худшую сторону для всех, поскольку они полностью утратят смысл существования и будут не более, чем скотом для извлечения органов - неясно только, зачем машинам мясные органы, если они разработали куда более эффективные агрегаты и полностью изолировались от лысых обезьян...
>Ты называешь его "единственным" только чтоб вызвать реакцию со стороны остальных, кого принижаешь.
Был заводчанен, мечтающий покинуть станок, который бегал самураем. Качество ты там сам видел, там ни опыта ни вкуса. Он сам признался что цель ливнуть с завода. Без души и качества.
Был чел с островами, но у него какой-то зомби проект уже много лет.
Потом забежал чел с мебелью и комнатой, который сказал что вы его тоже обоссали и он ушел, хотя у него качественно было. Он еще удивился что кому-то зашел его контент (вот настолько вы токсичные)
Доставщица хоть и ныла (как и чел с островами) но у неё был прогресс. Он допилил героя, анимации, потом часть местности своего города, кафешку причем не пустую, дома, домофон, мопед. Он реально делает постепенно. Сами посты я не читал, я вижу прогресс (да и лучше просто я не видел).
>И совсем не обязательно делать игру
Это как учить плавать, не умея плавать. Когда на практике делаешь игру, проходишь через трудности, о которых ты просто так не узнаешь.
Это даже важнее чем подрабатывать чатомГПТ по документации.
>Он кидался с ругательствами на простые советы от случайных людей
А он спрашивал советы? Я реально видел момент, когда на него чел накинулся, потому что он не сделал так как он хотел.
>Нормальный человек может просто сказать:
>>Спасибо, но я так делать не буду, мне подобное не нравится/не подходит/некогда/нет сил/лень.
Нефига у тебя ЧСВ. Навязываешь свое мнение и еще требуешь реверанс перед тобой делать. Наверное, если человек не просит советов, то советы безыгорки менее ценные - не находишь?
> не будет бросаться на всех
Я не следил за всей драмой, я давал ему пару советов, он мне норм отвечал.
Очевидно что ты высокомерное говно (как и он тоже) и вы оба не ведете какие токсичные.
Зато анонов обсуждающих геймдизайн, психологию игроков - разогнали.
Конечно вам это не интересно, вы же игры не делаете.
>В прошлом было достаточно полезных сообщений,
Ой, а что же случилось? Может перестать мешать людям общаться в мертвом разделе? Не все же должно быть так как нравится только тебе? Спустись тоже на землю. Пока писал, не одна кнопка репорта не пострадала
> Ты вообще не понял, о чём речь... Ты перечислил ЗАКРЫТЫЕ модели
Я прекрасно понял о чём речь(закрытве модели это игрушки а норм тема это локальные тренировать) - и прокомментировал это дальше по тексту.
Был от тебя тезис, что хорошие модели такие же плохие как и якобы не хорошие - и я на этот тезис отвечаю - нет, это совершенно не так, опус намного лучше соннета даёт результаты. Какую угодно можешь ментальную гимнастику исполнять, но это фактом быть не перестанет.
> Я просто разбираюсь в их устройстве, читал статьи, опубликованные самими разработчиками. Т.е. я не бездумный "пользователь нейронки".
Ага, только я так понимаю ты не просто "не бездумный пользователь", а ты вообще не "пользователь". Прочитал какие-то поверхностные статьи для вкатунов в интернете и сделал выводы о практическом применении.
А как твоё чтение статьи на хабре по азам нейросетей и ллм в частности отвергает тезис о том, что с их помощью можно получать пользу?
Я кстати тоже знаю как нейронки устроены, и ллм, и про отличия ллм от аги... 😳
> Они ходят по кругу в технологическом тупике и оправдываются "вот-вот осталось немного потерпеть и будет рывок"
Не знаю кто о чём оправдывается и меня это мало волнует. Зато я знаю то, на что нейронки прчмо сейчас способны и не способны. И именно это я раскрыл в своём посте.
> Мы не на twitch, чтобы игрунов комментировать...
Ну если ты что-то обсуждаешь - наверное есть смысл раскрыть мысль. Если это не бестолковое сотрясание воздуха, конечно.
> Ни разу в жизни не работал
И при этом считаешь себя экспертом по нейронкам и разработке игр? Интересно
>Качество ты там сам видел, там ни опыта ни вкуса.
Вообще-то, у него крутой стиль. Ты просто не в теме ретроигрушек, среди которых он настоящий крутан. Понравится, конечно, не всем, но это лучше унылой копипасты фотографий из интернета для "реализма".
>Без души и качества.
Как раз наоборот: без души - это нейрослопная тян на скутере, ездящая между однообразными панельками. Наворовал фоток из Яндекс.Карт, оправдываясь, что нормально он сделать никогда не сможет, и ты это защищаешь, как будто он своими руками рисовал.
>какой-то зомби проект уже много лет
И что? Многие инди-игры делаются медленно.
>Потом забежал чел с мебелью и комнатой
Он в тред больше года назад забежал...
>хотя у него качественно было
Качественно натянутые фотки из интернета?
>Он реально делает постепенно.
Делает, но не он один. Зачем его выделять?
>Это как учить плавать, не умея плавать
Делать полноценную видеоигру == переплыть океан.
Учить плавать == объяснять азы, делать прототипы.
Многие плавают, но мало кто переплывает океан...
>А он спрашивал советы?
Запостил в тред об игре == просил у местных советы. Собирать аудиторию своей игры в этом треде вообще бесполезно. Это раздел творцов, а не площадка с миллионами игроков, жаждущих играть в игры.
>требуешь реверанс перед тобой делать
Тогда не жалуйся, когда твоё плохое поведение трут.
>советы безыгорки менее ценные
Просто не слушай их. Зачем психовать и ругаться?
>Зато анонов обсуждающих геймдизайн, психологию игроков - разогнали.
Никто их не разгонял. По-моему, раньше не удаляли подобное. Удаляют только буйных и за очевидные провокации движкосрача, для которого загон есть.
>мешать людям общаться в мертвом разделе
Мешают лишь троллям-движкосрачерам, не более.
>Мешают лишь троллям-движкосрачерам, не более.
Да ты тут нахватаешься и потом начинаешь движкосрачеров в годот треде искать.
> за очевидные провокации движкосрача
Эти провокаторы сейчас с тобой в одной комнате? Ты походу реально болен.
>Тогда не жалуйся
Это не я, ты же видишь по стилю письма (или даже по IP), я другой анон.
Я просто вижу один что-то делает, а другой просто высокомерный бездельник. Который возомнил что /gd его собственность. А по сути, в сравнение с ним, ты "флудящая безыгорка", пыль раздела. К движкописям больше уважение чем к тебе (жми на кнопку, скорее, докажи свой статус пыли).
У тебя ошибка в том, что ты считаешь что "ИИ" должно развиться в аналог человеческого мышления. Но на самом машинное обучение намного более мощнее, чем то, на что способен любой человек. Да, оно просто анализирует огромное число данных и находит шаблоны и закономерности, но никакой человек не создаст картинку, видео за секунду, не клонирует голос, не перепишет миллион строк с одного языка программирования на другой.
Машинному обучению не нужно развиваться до уровня человека, у него другие цели и в них оно превосходит любого человека, является более совершенным инструментом решения задач.
>закрытве модели это игрушки а норм тема это локальные тренировать
Нужны какие-либо дополнительные комментарии?
>провокации движкосрача
Самое забавное, когда я сидел тут 3-4 месяца назад, никто даже годот не поливал. Это просто раздел-флудилка. Даже сейчас тут активна ветка про ИИ идет. У тебя реально есть ощущение что есть пачка злых анонов, которые ловят моменты чтобы насолить в годот тред?
Галоперидол помогает от паранойи?
>Ты перечислил ЗАКРЫТЫЕ модели, над которыми ты не имеешь НИКАКОГО реального контроля
Анон, а если тебе сегодня на Вронной на голову свалится 4тб ЖД с последним опусом на нем - что ты с ним делать будешь? Будешь пытаться высосать из его самого сильного кванта дохлые 0.3 t/s на своей 5090/ryzen ai/m4 pro? Или может просто хуй забьешь и пойдешь дальше юзать квен (просто потому что квен создан для потребительского железа, и он работает)? Что такое контроль по твоему мнению?
Нууу типа да, нужны. Я юзаю закрытые модели и экономлю этим время=деньги, в чем я не прав?
Как ты тренеруешь локальные модели и извлекаешь из этого пользу - ты не написал.
Ты просто пытаешься навязать свое представление о том, как нужно общаться в ГД всем остальным, вот и все. У тебя в запрете "движкосрача" правды не больше, чем у пользователей, которые считают это нормой.
Ты читай внимательнее что я реплайнул. Анон утверждает что закрытые фронтир модели это игрушки
Можно было бы сказать "да, я баню движкосрач, но посмотрите на эти графики! Число пользователей выросло втрое за последние несколько лет!". Но что-то я этого не вижу.
>Число пользователей
2ch за последние несколько лет сильно выродился, буквально закрыли/удалили множество разделов, оставшиеся сильно уменьшились в активности.
Так что аргумент про число постеров не аргумент. Школьников призвали в армию, наверное. Или все разъехались из страны и сидят теперь на форчане.
В любом случае, что лучше: 100 постов срача "какой движок хуже всех" или 10 постов цивилизованных обсуждений чьей-то новой игры в разработке?
И заметьте, у движкосрачеров целый тред есть.
Зачем растекаться жиром по всей доске?
>В любом случае, что лучше: 100 постов срача "какой движок хуже всех" или 10 постов цивилизованных обсуждений чьей-то новой игры в разработке?
Попизди, мань. Ты позавчера раздал пизды за обсуждение годота в годототреде, а сегодня мне вломил за вопрос о перекате. Но ты же неуиноват как всегда, это просто твоя шиза приказала тебе зачистить неугодные тебе обсуждения.
>оставшиеся сильно уменьшились в активности.
Жду слияния /gd с /vg, пора уже.
>что лучше:
У тебя не было движкосрача, хватит маняфантазировать свой идеальный /gd в вакууме, признай что просто бомбанул по пьяне.
Сейчас только что нормальный перекат забанили, помянем собрата.
>опус намного лучше соннета даёт результаты
Я с этим не спорил. Но это как разница между двумя пьяницами - один еле-еле что-то мычит, а другой хоть немного, но может что-то сказать, пусть и невнятно. Существенного рывка как не было, так и нет. Просто архитектура принципиально ограниченная, нужна альтернатива какая-то, неизвестная публике.
>с их помощью можно получать пользу
Пользу можно и от спиннера получать, дав его в руки непослушному малышу, чтобы он, крутя спиннер, не отвлекал родителей. Это не делает спиннер "высшим разумом, который нас всех заменит и уничтожит". Ты поигрался с игрушкой, получил дофамин, и теперь рекомендуешь её так, будто это Святой Грааль всея программирования, без которого мы все умрём.
>>1088124
>И при этом считаешь себя экспертом
Ты бы предпочёл, чтобы я говорил "я руководитель крупнейшего АААА проекта, 50+ лет опыта работы, несколько нобелевских премий, пруфов не будет"?
>>1088145
>считаешь что "ИИ" должно развиться в аналог человеческого мышления. Но на самом машинное обучение намного более мощнее, чем то, на что способен любой человек
Люди построили реактивные самолёты, способные передвигаться по воздуху быстрее звука. Тараканы неспособны летать и двигаются медленнее многих хищников, охотящихся на них. В ядерной войне все реактивные самолеты уничтожатся или придут в негодность из-за гибели людей, а тараканы будут продолжать жить и размножаться. Быть может, способность летать выше скорости звука не так уж и необходима для выживания? Может, нужно что-то совершенно другое, что эволюция уже нашла?
Суть "ИИ" в том, чтобы стать заменой человека, и, следовательно, нам нужна от него не сверхзвуковая скорость, а живучесть и адаптивность. Человеку не составляет труда убить таракана, но ИИ даже хуже тараканов в плане выживаемости. Это значит, что ИИ по-прежнему далеко до уровня человека.
Это очевидно даже без знания устройства нейронок. Нейронки только один из возможных вариантов. На планете, например, существуют растения возрастом несколько тысяч, а то и десятков тысяч лет - а у них нервной системы вообще нет, несмотря на сотни или тысячи тонн биомассы одного индивида. Как так? Громадная туша без мозгов умнее нейронок?
>>1088148
>свалится 4тб ЖД с последним опусом на нем
Да пофиг на попуса твоего. Накачали копипастой с вебсайтов типа Фалькиного, внушили отвечать на пошлости резким отказом, и сидят довольные. Хайп крутится, инвестиции мутятся, пока простой народ ломает голову, ища применение кривой лопате...
Короче, игрушки всё это. Рано паниковать. Вот если обнаружится, что, например, Сэм - это выдумка, и его компания вообще пустая внутри, ни одной обезьяны, только компьютеры что-то там щёлкают и пищат, и стреляют в каждого входящего в серверную - тогда, допускаю, можно начинать волноваться...
>Да пофиг на попуса твоего. Накачали копипастой с вебсайтов типа Фалькиного, внушили отвечать на пошлости резким отказом, и сидят довольные. Хайп крутится, инвестиции мутятся, пока простой народ ломает голову, ища применение кривой лопате...
Соседей затопило жиром с экрана
> Я с этим не спорил.
Тогда мб отвечай на то с чем споришь.
> Пользу можно и от спиннера получать, дав его в руки непослушному малышу, чтобы он, крутя спиннер, не отвлекал родителей.
Совершенно верно.
> Это не делает спиннер "высшим разумом, который нас всех заменит и уничтожит".
Процитируй э, где я что-то такое говорил.
Также вдогонку ко всем 3 пунктам выше и к
> Но это как разница между двумя пьяницами - один еле-еле что-то мычит, а другой хоть немного, но может что-то сказать, пусть и невнятно
Нейронки это не спиннер в руках у микрочела, и не пьяница который что-то мычит, нейронки - это инструмент реально прямо сейчас работающий и реально экономящий много времени. Это объективный факт.
Если тебе есть что рассказать про то, как ты круто натренировал локальную модель сам и оно стало приносить "большую пользу" - я с радостью это послушаю.
А манятеории что работает и не работает от того кто не в теме и выводы делает 2 минуты подумав над статьями для новичков - всё таки мало интереса имеют.
> Ты бы предпочёл, чтобы я говорил "я руководитель крупнейшего АААА проекта, 50+ лет опыта работы, несколько нобелевских премий, пруфов не будет"?
Я бы предпочёл, чтобы ты хотя бы для себя ответил на вопрос "а как я это понял?" и отвечал по существу.
>аргумент про число постеров не аргумент
А на чем основан аргумент, что нужно оптимизировать форум на зайстойность, чтобы всегда были одни и те же несколько тем постоянно.
На чем основан аргумент, что нужно банить пользователей за обсуждение движка?
Какие-то метрики же есть для этого? Для чего то это делается, должна же быть причина. Если это не увеличивает активность доски, а, наоборот, уменьшает ее, то какой вывод из этого надо сделать?
@
ДА НЕ ЗАМЕНЯТ ОНИ НИКОГО, ИЛИ НЕ СКОРО
@
НЕЕЕЕТ СКОРО ЗАМЕНЯТ! УЖЕ ЗАМЕНЯЮТ!
@
ПРИВЕДИ ПРИМЕРЫ ГДЕ БЫ ЗАМЕНИЛО
@
А ВОТ СКАЗАЛ "НАЙДИ БУКВУ В КОДЕ"
@
И ЧТО, НАШЛА ХОТЬ? БУКОВКУ-ТО?..
@
НУ... НАХОДИТ. В 90% НАХОДИТ 2/3
@
В ОСТАЛЬНЫХ 10% СНОСИТ МНЕ ОС
@
НО РАБОТАЕТ ЖЕ! ЗАМЕНЯЕТ!!!
@
НУ ВИДИШЬ ЖЕ, ЧТО ФИГНЯ
@
НЕЕЕЕТ!!! Я ЗАМЕНЁН!!!
@
ОЙ, КАК ХОЧЕШЬ...
@
Я ЗАМЕНЁЁЁН
>ПРИВЕДИ ПРИМЕРЫ ГДЕ БЫ ЗАМЕНИЛО
@
>открываешь реддик, тикток, твиттер, постоянно что-то новое в ленте, интересно
>открываешь гд, одни и те же 3.5 темы на протяжении 7 лет. отправляешь сообщение в одну из этим тем... бан, причина: "движкосрач"...
>Суть "ИИ" в том, чтобы стать заменой человека
>>1088145
>У тебя ошибка в том, что ты считаешь что "ИИ" должно развиться в аналог человеческого мышления
Этот в теме, удаление началось из-за раздутого пузыря. И какие-то умники начали это коррелировать с ИИшкой.
Хз что сейчас, но вероятно просто стало удобно этим прикрываться.
Ты когда зашел, плохо подумал о годоте. Этого было достаточно.
>подумал
>движкосрачер
Погодите, это реально?
Движкосрачеры... думают?!!
> опус намного лучше соннета даёт результаты
Писечка в том что в хорошей кодовой базе это не имеет особого значения - написание нового кода становится настолько тривиальным что даже посредственные нейронки будут делать хорошо, потому что сделать плохо труднее. А разбиение на задачи (даже автоматическое), форсирование TDD и добавление довольно банального цикла "один агент написал" - "другой агент отревьюил и перезапустил первого чтобы пофиксил" улучшает качество наверно больше чем наивное использование более дорогих моделей. Модель просто не должна быть совсем тупой. У меня даже Deepseek V4 Flash нормально кодирует таким образом.
Времена когда выбор топовой модели был единственно возможным прошли. Может через год-два и локальные подтянутся.
> Суть "ИИ" в том, чтобы стать заменой человека
Невозможно же. Зато получилась недурственная турбокодилка/текстописалка. Самолёт не машет крыльями на манер птиц, но летает быстрее.
> в хорошей кодовой базе это не имеет особого значения - написание нового кода становится настолько тривиальным
На какого рода/размера/сложности проектах ты к таким выводам пришёл и оно у тебя так реально работает?
У меня опыт получился как я описал тут >>1088078 и написание кода мне кажется совсем не тривиальным, если задача не тривиальная - нейронка начинает упускать логику, корнер кейсы, первоисточник проблем и всякие сожные логические сплетения, ну и как я говорил - в архитектуре нецронка очень плоха.
Это всё проверено на разных проектах - ECS/ECS + мета на ООП/чисто компонентных подходах + ООПшный сетап. По качеству кода - писали не нубы и было полноценное код ревью у разрабов.
> форсирование TDD и добавление довольно банального цикла "один агент написал" - "другой агент отревьюил и перезапустил первого чтобы пофиксил"
Я делал и это(планировщик-исполнитель-ревьюер), и расширенное(+ написание теста для валидации что код отработал - если применимо - понятно что в играх абсолютное большинство вещей геймплейных тестами чисто концептуально не покруять) и полный ральф цикл который бьётся этим постоянно.
С 4-5 мегабайтами движкового/игрового кода спокойно справляется. Твоя задача как человека - разбить задачу так чтобы состояла из простых этапов. Простые этапы дальше уже сама нейронка на задачи разбить может. Тут ключевой момент в том чтобы каждая отдельная задача была достаточно компактной и влезала в короткий контекст, каждый раз приводя к чему-то законченному. При ручной работе всё то же самое, ИИшка просто берёт последний этап где код нажимают кнопочки чтобы буквоки в коде появились.
Вопрос чисто в том насколько код модульный и заложена ли возможность нормального тестирования.
>Локальный 32b Квен кодит лучше Клода
я не исключаю, ибо версия клода не указана.
но если сравнивать квен и колд последних версий, то клод просто без шансов разъебывает.
квен параша, может чуть получше дипсика, хотя четверку так и не тестанул, бабло кончилось на опенроутере, а в чате там хуй пойми чо, я кинул туда запрос, она какую-то ебалу мне выдала, скорее всего там еще 3тья.
Клод последней версии сосёт с проглотом у клода предпоследней версии. Это факт. При этом клод предпоследней версии серьёзно устарел и уже отстаёт от топовых моделей.
узкоглазик, ну не плакай, когда нить у вас получится сделать что-то похожее на ИИ
>Клод последней версии сосёт с проглотом у клода предпоследней версии
Псиоп с реддита. Охуенно кодит, еще лучше понимает технологические стеки, еще лучше гадает на описаниях ошибок.
>При этом клод предпоследней версии серьёзно устарел и уже отстаёт от топовых моделей.
Разве что от самого топового ГПТ, но это не точно, надо сравнивать. Ну уж точно не от квена, лол
Может ли клод быть вайфу, раздвигать ножки и приговаривать ara-ara anon-kun~, когда обнимает и поглаживает юзера? Это главное в нейросетях...
мимо
При чём тут я, когда речь о чатботах?
Алсо, у MaSiRo нет ног - она на квадратном каркасе с колёсиками ездит, так что максимум, что она может сделать, это подрочить тебе рукой. Да и то придётся программу писать для этого, скорее всего. У неё там самые дешёвые внутренности, насколько я помню.
Так что это будет старый добрый WebGL, соответственно, чтобы два раза не кодить, на других платформах будет OpenGL ES. После треугольника и куба, есть желание в первую очередь сделать тени и скелетную анимацию, естественно без либ. Пбр пока сомневаюсь, в первую очередь смотрю на производительность и самостоятельные стили, а не на реализм, которого в браузере все равно сомнительно добиться.
Язык пока не выбрал, у меня конечно непереносимость js, но он нативен в вебе, можно будет использовать нативные контролы (а не как обычно дрисня с рендером кнопок, с которыми нельзя взаимодействовать), но почитаю еще раз про совместимость wasm со старым и слабым железом. На одном некроноуте я точно сталкивался с проблемами однажды, которые требовали перекомпиляции без использования какой-то инструкции процессора.
Физика, естественно, будет своя, поскольку обычные физические движки нафиг не уперлись, в моих играх нужна или физ симуляция, которую все равно самому писать, или простые триггеры и контроллеры, для которых физика оверкилл.
Что еще забыл? Да, звук надо чекнуть, конечно предпочтительно чтобы нативный работал, но с другой стороны и микшер хочется.
>это еще и ограничивает Android то ли 10, то ли 11+, то есть выпадает от 15% до 40% мобилок
У настолько древних мобилок аккумулятор зачастую дохлый и пользуются ими из-за нищеты, так что твои модные игрушки им не нужны. Пока ты будешь свой велосипед писать, они ещё сильнее состарятся. Если начнёшь делать игру на своем велосипеде, к релизу последние мобилки на Android 11 рассыпятся в пыль.
Я решил вопрос довольно просто. Взял 2 телефона которые были под рукой, один это 8 андроид, я там пару раз менял акк и стекло, второй более экзотичный перепрошитый. На обоих демки 3d WebGL запустились, WebGPU черный экран. На этом я для себя вопрос закрыл. Вот буду следующую игру через год-два делать, там уже можно и что-то другое присмотреть (может нормальный убийца апи вулкана выйдет).
>а это еще и ограничивает Android то ли 10, то ли 11+
На самом деле все еще хуже, большая часть андроидов с вулканом этой версии это среднее и топовое железо с снапами, которых от всего рынка дай бог 20%, у остальных вулкан даже если и заявлен, то работает хуево либо не работает вовсе. Ну, просто как данность - гугл обязал всех кто использует 15 андроид реализовать вулкан нормально, т.е. до 15 этим нормально занимался только квалком, остальные как не работали через раз так и не работают
В остальном - ты уже оформил пенсию по шизе безусловный базовый доход? Лет так на 10.
какие лет 10? месяц на движок, месяц на игру, в августе уже можно начинать релиз, к новогодним становлюсь миллионером. Сейчас с помощью нейронок все это легко кодится, главное крышечку придерживать.
>месяц на движок, месяц на игру
И еще 9 лет и 10 месяцев на починку того нерабочего говна что высрало ИИ при подобном подходе, ведь вместо того чтобы брать готовое(желательно сразу движок, с mcp интеграцией типа юнити/годота/урины) и максимально облегчать работу нейродауна за счет его "холодной" памяти ты предпочитаешь раздуть кодовую базу велосипедами.
>пикча 2
Рограммисты настолько тупые что не могут отключить сон в ноуте?
>Рограммисты настолько тупые
Это не программисты.
>крышечку придерживать.
>>1088322
>отключить сон в ноуте?
А зачем вообще на ноутбуке держать, если ноутбук выполняет роль тонкого клиента к серверам Claude, которые и выполняют всю работу? Зачем вообще использовать локальное, если настолько зависим от чужого облака, что ходишь с клиентом к нему?
Реально дурачки какие-то. Я б давно настроил себе смартфон или смарт-часы для просмотра статуса и голосовых команд агенту в облаке, чтоб не таскать по городу давно ставший бесполезным ноутбук.
> А зачем вообще на ноутбуке держать, если ноутбук выполняет роль тонкого клиента к серверам Claude
Потому что агент над локальным проектом работает обычно, пробует запускать, компилить
>компилить
Если там C++, то лучше в облаке компилить.
>запускать
Аналогично, лучше в облачной песочнице.
Это ж ИИ. Ему не важно, где работать.
Никаких плюсов от локальности нет - все данные "локального" проекта в любом случае утекают на облачные сервера Anthropic и варятся неизвестно сколько неизвестно с какой целью, так что можешь считать, что это не твои данные, ты просто мясной биодрон для написания оригинальных промптов и оценивания результатов работы ИИ-агента.
Возможно там чат на паузу встает, если видит что пользователь не онлайн?
Я пользовался юнити, годотом, их экспорт перегружен для веба, специализированные для веба мне тоже не очень понравились. У нейродауна будет такая же холодная память на "просто opengl". Ну и есть еще причины, по которым хочется просто сделать свой движок и иметь свое, в связи с этими разговорами о грядущей недоступности гитхаба.
>У нейродауна будет такая же холодная память на "просто opengl"
Нет, потому что ты захуяришь контекст вагоном твоих собственных реализаций частиц, рендеринга, физики, юи, сцены, конфигов игры, тестовым инструментарием и прочей кучей говна, которую нейросеть будет видеть каждый промпт как первый, и будет вынуждена постоянно держать информацию о апи твого движка горячей, в ущерб полезной нагрузке.
>Ну и есть еще причины, по которым хочется просто сделать свой движок и иметь свое, в связи с этими разговорами о грядущей недоступности гитхаба.
Может просто насохранять все доступные опенсорс движки (включая ue) себе на комп и всё? За стеной чебурнета свыня не узнает что ты ему не откашливаешь 12%
В ue нет веб экспорта, его дропнули где-то в районе 4.2 да и он тоже переутяжелен, хотя я его не смог собрать.
Ну у меня скачан годот (надо еще выкачать аддоны и шейдеры; несколько лет назад я так делал с 3-кой), дилиджент, гугл филамент и еще по мелочи разное. Но это все равно не свое.
>реализаций частиц, рендеринга, физики, юи, сцены, конфигов игры, тестовым инструментарием
Это решается модульностью и файлами с описаниями. Нет нужды при работе над частицами подтягивать юи и физику. Ну и в любом случае это просто ассистент для меня. программиста.
> Если там C++, то лучше в облаке компилить.
А почему именно с++?
> Аналогично, лучше в облачной песочнице.
А если у нас гуи приложение? Заёб.
Это всё стоит денег и время на разворачивания инфраструктуры. Зачем это делать? Чтобы было?
> Ну и есть еще причины, по которым хочется просто сделать свой движок и иметь свое, в связи с этими разговорами о грядущей недоступности гитхаба.
Если именно это твоя реальная причина, то это пиздец.
> Я пользовался юнити, годотом, их экспорт перегружен для веба, специализированные для веба мне тоже не очень понравились.
Это валидная причина.
Скажу аккууратно, это тоже валидная причина. Я видел своими глазами, как плакала мелкая племянница, когда ей отключили Роблокс. И мне было стыдно, что я не смог ей тут же показать нашу, местную замену. А вот в китае он тоже отключен, и ничего, они клепают свои геншины, На днях на хабре было очередное нытье, что надо поддерживать бедных и несчастных Electronic Arts и прочих. А я вот считаю, что лучше Фальку поддержали бы.
>Это решается модульностью и файлами с описаниями.
До определенного порога. Микросервис можно раздробить на вагон не связанных модулей и оно будет работать. Игру ты на микросервисы не поделишь, так или иначе физика, сцена, звук, освещение и прочие подсистемы движка будут единым целым, одно будет тянуть за собой другое. И вместо полезной информации (размышлений, апи игровых подсистем) - контекст будет в том числе набит под завязку апи твоего движка, который он будет тянуть из файлов-описаний (они тоже должны быть в контексте если че). Потому есть неироничный риск упереться в предел контекстного окна, который у локальных нейронок еще более смешной чем у облачных, и все из-за тяги к велосипедостроению.
> Я видел своими глазами, как плакала мелкая племянница, когда ей отключили Роблокс. И мне было стыдно, что я не смог ей тут же показать нашу, местную замену.
Про квн не слышал?
> А вот в китае он тоже отключен, и ничего, они клепают свои геншины
Геншин это не конкурент роблокса, это совсем другая ниша.
Прямой конкурент роблокса - фортнайт.
> На днях на хабре было очередное нытье, что надо поддерживать бедных и несчастных Electronic Arts и прочих.
В плане поддерживать? Типа чтобы не блочили что-то делать? Да, это правильно.
> А я вот считаю, что лучше Фальку поддержали бы.
Как он с геймдевом связан и как ты его поддерживать собрался?
> И мне было стыдно, что я не смог ей тут же показать нашу, местную замену.
Кстати, ты ещё и не понимаешь причину трагедии. Это социальная площадка, у неё там какие то интернет друзья были, какая-то движуха происходила они какие то приеолы мутили.
Рубильник повернули - и всё.
Мрази ебаные.
>Про квн не слышал?
Не пользуюсь, нет необходимости, к тому же если рубанут, то и он перестанет помогать.
>Геншин это не конкурент роблокса
Не буквоедствуй. У китайцев есть свои аналоги роблокса, от ByteDance и прочих. Просто тут таких названий все равно никто не слышал.
>Да, это правильно.
Нет, это бред призывать игроков выносить деньги из страны, чтобы богатая EA становилась еще богаче, вместо того, чтобы поддерживать местных.
>Как он с геймдевом связан
Это шутка такая? Ну поищи для начала какие игры у него выходили.
>Кстати, ты ещё и не понимаешь причину трагедии. Это социальная площадка
Это школьники, они и так друг друга знают одноклассники, и по вконтакту.
>отключили Роблокс. И мне было стыдно, что я не смог ей тут же показать нашу, местную замену
Вообще странно что Яндекс.Игры не сделали свой "ход", так сказать. У них огромный портал веб игр, они могут добавить в свой API (который встроен в каждую web игру) социальные функции и переходы между разными играми, тысячи разрабов на Яндекс.Играх создают маленькие Web игры, но каждый отдельно.
Но если Яндекс предоставит функционал Роблокса, это будет бомба, тысячи детей которые уже там играют начнут создавать, тысячи разрабов применят свои знания и опыт и тоже начнут что то делать.
>Так что это будет старый добрый WebGL
для инди достаточно. webgl 2 = opengl 3.3. Есть конечно проблемы - нет DSA (а это жопа оптимизации), нет bindless текстур (16 текстур мало для чего-то вменяемого - от одного только точечного света уже 6 текстур теней на свет).
но в остальном этого достаточно для 99% инди
>>1088289
>Пбр пока
не нужно. требует специальных текстур. а ты ж программист - где ты их брать-то будешь? запрогай фонга и будет у тебя нормальная для инди картинка.
>>1088289
>Физика, естественно
года два назад я бы не советовал. сейчас с нейронками топ самому писать. главное правильно нейронке разбить на задачи (надо прям совсем мелкие задачи делать, иначе у нейронок шиза). и конечно все обмазать миллионом юнит тестов (также нейронками нагенерить)
>не сделали свой "ход", так сказать.
русский бизнес - он ебанутый и рассчитан не на поиск прибыли, а на попилы бюджетов.
ровно по той же причине разрабы unigine сидели на военых бюджетах, и клали болт на инди (при том что на тот момент юнити еще толком не вышел, а юнижин уже был на его уровне - они буквально могли занять этот рынок. но нет, я еще помню как их менеджер прямо писал - что бомжи школьники им не нужны, им тут серьезные дядьки-военные заказы делают)
также и яндекс - у них буквально готова целая социальная платформа (особенно взлетевшая после 2022) - там можно делать буквально все - свои роблоксы, свои сторы, свою игровую соц сеть с ачивками.. но как сейчас можно "можно... а зачем?"
также как и вк кстати - у них тоже своя платформа (хоть и жопу загнувшаяся)
но снова: "можно... а зачем?"
> Не пользуюсь, нет необходимости
Всм нет необзодимости? Племяннице помочь это не необходимость?
> к тому же если рубанут, то и он перестанет помогать.
Ну если у тебя есть минимальная техническая грамотность, то ты должен понимать, что это невозможно.
> Нет, это бред призывать игроков выносить деньги из страны, чтобы богатая EA становилась еще богаче, вместо того, чтобы поддерживать местных.
Я буквально местный и есть и я говорю что запрет ЕА это говно как и вообще любые запреты)))
1. У нас конкурентов играм ЕА не сделать физически
2. Сами игры такого масштаба мертвы автоматом без выхода на глобал - ру аудитория там хорошо если 10% выручки сгенерит - если хорошо в россии пропиарить. Поэтому вообще поебать - если мы сделали свою фифу и она будет реально качественной и конкурентной - то если у неё на ру рынке не будет конкуренции это даст +3% выручки, причём если очень повезёт.
3. Ты чо думаешь, если ЕА реально запретить магическим образом - народ побежит покупать срущие петухи 2?
> Это шутка такая? Ну поищи для начала какие игры у него выходили.
Скинь лучшие)))
> Это школьники, они и так друг друга знают одноклассники, и по вконтакту.
Они в роблоксе знакомятся.
> Но если Яндекс предоставит функционал Роблокса, это будет бомба, тысячи детей которые уже там играют начнут создавать,
Создавать не получится - у роблокса лёгкий редактор который сразу из коробки с уже сделанным мультиплеером, а тут придётся со своим движком делать, и что ещё хуже - мультиплеер делать намного сложнее.
Поэтому на ЯИ мультиплеера либо нет либо почти нет, и в целом там все в соло игры играют, как это превращать в соц площадку хз если играть не во что вместе.
>А почему именно с++?
Чтобы вайбкодер смог выстрелить себе в ноги с двухстволки.
>А если у нас гуи приложение?
Это ж ИИ, он сам может кнопочки покликать и сказать "норм".
>Это всё стоит денег и время
Ты выронил макбук и по нему проехался джип. Твои действия?
>unigine
О Unigine, помню что у них на сайте, не было даже документации по движку на русском языке. После 2022 только появилась.
>У нас конкурентов играм ЕА не сделать физически
Ну и сиди с такой мыслью. Даже отвечать что-то расхотелось.
Просто принимаем как данность - свое делать нужно и необходимо.
>>1088446
Да, вот, примерно так же и рассуждал. Bindless конечно жалко, и свет будет ограниченный, ну в вебе и так попроще с этим надо.
> Ну и сиди с такой мыслью. Даже отвечать что-то расхотелось.
> Просто принимаем как данность - свое делать нужно и необходимо.
Ну ты же на доске по разработке игр сидишь, почему у тебя настолько нулевое понимание как индустрия работает?
Игры зарабатывают с глобального рынка, чисто на локальном ты ничего не заработаешь.
Если ты запретишь игру и выкатишь её аналог идентичного качества в который все радостно перейду - запрет даст тебе +5% прибыли. Прикольный бонус, но это вообще ничего не решает глобально.
Сама задача разработки игры тоже нетривиальная.
Чтобы сделать свою фифу надо:
- привлечь где то 50-100кк$ финансов на работу команды и маркетинг
- сразу оформить иностранные юр лица для доступа на глобальный рынок и выстроить финансовую цепочку(это в целом решаемо, но я полагаю ты такое не одобряешь)
- найти штук 300 топовых спецов и запрячь на несколько лет, при том что нормального сеньора сейчас ищут по полгода)
- решить задачу "объяснить аудитории фифы, что наша фифа лучше", т.е. сделать какое-то мощное конкурентное преимущество, что требует ресерча, идеи и разработки
Есть идеи как ты будешь решать хотя бы один пункт из этой задачи?
Плэтому чтобы поддержать отечественного разработчика - надо поддерживать отечественного разработчика, а не хуйней заниматься. Это делается? Где?
Где программы финансирования или налоговых льгот для разработчиков?
Нахуя блокировки софта который разработчикам необходим? Да, я-то впн поставлю, но вот какой-нибудь школьник не осилит, и вместо того чтобы ковырять юнити как делал я будучи школьником - скорее всего уйдет в другую область, и будет у нас всё меньше и меньше кадров.
Нахуя закручивать гайки в финансовом секторе для простых работяг? Вот сидит разраб в россии, ему платят криптой, а теперь крипту считай прикрыли. И ему приходится уезжать - и таких много, в любой компании с российскими корнями больше половины штана не в россии, и сами компании уже именно что с российскими корнями - свою юридическую часть релоцировали.
Так что твоё пиздабольство про запреты во благо - прсто тупые высеры от человека который понятия не имеет о чём говорит. Как реальный разраб из россии я читаю это и просто не понимаю что в голове у ура-патриотов вроде тебя, которые рассказывают как здорово что государство блокирует что-то там чтобы у нас всё развивалось, когда на самом деле это буквально наоборот - выстрел себе в хуй и полный развал.
Короче опять сплошное нытье что ничего нельзя и невозможно.
>Чтобы сделать свою фифу надо привлечь где то 50-100кк$ финансов на работу команды и маркетинг
Сделаю за миску макарошек.
>сразу оформить иностранные юр лица для доступа на глобальный рынок и выстроить финансовую цепочку(это в целом решаемо, но я полагаю ты такое не одобряешь)
Палки в колеса вставляют на той стороне. Приток с глобальных продаж - должен быть просто приятным бонусом. Геншин зарабатывает с местных больше половины.
>найти штук 300 топовых спецов и запрячь на несколько лет, при том что нормального сеньора сейчас ищут по полгода)
Я сам сеньор.
>решить задачу "объяснить аудитории фифы, что наша фифа лучше", т.е. сделать какое-то мощное конкурентное преимущество, что требует ресерча, идеи и разработки
Игрок зайдет в вкплей и увидит соответствующую игру и будет играть.
>вместо того чтобы ковырять юнити как делал я будучи школьником
Будет ковырять свой, родной движок.
>И ему приходится уезжать
Слишком много свободы позволяют.
>3. Ты чо думаешь, если ЕА реально запретить магическим образом - народ побежит покупать срущие петухи 2?
Ну, надо максимально обрубить все связи с миром, тогда и срущих петухов купят
>>1088461
>Ну и сиди с такой мыслью. Даже отвечать что-то расхотелось
Да в целом согласен. Надо повесить замок покрепче на доступ к западным технологиям, собрать более-менее инженеров при памяти в шаражки, приставить автоматические турели и отдать приказ "разрабатывовай", тогда сразу и своя фифа про волка и зайца, и свой асасинс крид ПЕЧЕНЕГЕССИ, и все будет, а если не будет то расстреливать за каждый провальный релиз члена оставшейся семьи, за плохое программирование
>>1088465
>Где программы финансирования или налоговых льгот для разработчиков?
Идешь в ири, говоришь что сделаешь игру по мотивам война и мир, делаешь смуту 3 с стрельбой из винтовок (дешевле чем анимировать ближний бой), получаешь миллионы, ты победил
>но вот какой-нибудь школьник не осилит, и вместо того чтобы ковырять юнити как делал я будучи школьником - скорее всего уйдет в другую область, и будет у нас всё меньше и меньше кадров.
Игры вообще надо запретить, как вредное и разлагающее трудовое общество явление. Рабочий должен крутить гайку, вечером после работы принимать на грудь, а завтра утром снова повторять трудовые подвиги, игры здесь совершенно лишнее звено цепи, а для детей тем более, им надо постигать науки и двигать Россию вперед
> Короче опять сплошное нытье что ничего нельзя и невозможно.
Какое нытье? Есть объективный факт - долбоебы уничтожают игровую индустрию, другие долбоебы рассказывают как ещё стоит уничтожить. И я прокомментировал, почему это так.
Что нельзя и невозможно? Многое возможно, я живя в россии работаю на нероссийские компании(у нас не на кого просто), но это нетривиальная задача и она идёт чисто на мою выгоду, а не на развитие игровой индустрии в россии)
А глобальные задачи из того что я перечислил - невыполнимы на текущем этапе развития игровой индустрии у нас.
> Сделаю за миску макарошек.
Думаю, ты даже вклад внести не сможешь.
> Палки в колеса вставляют на той стороне. Приток с глобальных продаж - должен быть просто приятным бонусом. Геншин зарабатывает с местных больше половины.
У нас в стране 1500кк населения или 150кк?
Еще раз говорю - у игр, которые делают выделенную маркетинговую компанию в россии(типичная ситуация - разрабы из россии, и они логично делают маркетинг в глобал и отдельно на россии под соусом НАША игра) - с россии 10% дохода идёт. Это просто статистический факт.
> Я сам сеньор.
В геймдеве или где? Как тебе работа в геймдеве в расиюшке в 2026? Вкусно?
Или ты из совсем другой области пиздишь а про геймдев краем уха наслышан?
> Игрок зайдет в вкплей и увидит соответствующую игру и будет играть.
Мы игру делаем для глобала, какой вк плей?
> Будет ковырять свой, родной движок.
Какой?))))))
> Слишком много свободы позволяют.
Что?
Короче какой-то высер от чела, который игры только в движкосраче делает на словах.
> Идешь в ири, говоришь что сделаешь игру по мотивам война и мир, делаешь смуту 3 с стрельбой из винтовок (дешевле чем анимировать ближний бой), получаешь миллионы, ты победил
Кстати максимально мутная тема этот ири.
Вот войну миров понятно кто и как делает - у них куча мобильных проектов, с них деньги идут, опытных разрабов на войну миров пересаживают, новеньких нанимают поддерживать мобилки.
А вот смута хз откуда хз как 500кк дали.
> я живя в россии работаю на нероссийские компании(у нас не на кого просто), но это нетривиальная задача и она идёт чисто на мою выгоду, а не на развитие игровой индустрии в россии)
Действительно, что же может пойти не так.
Китай большой и сильный, тут не поспоришь.
Как успех Китая относится к нашему рынку игр?
Ахаха, все буквально наоборот - это как раз что-то пошло не так - и я нашёл выход.
А так, как я говорил - все вышеперечисленные удары по индустрии вынуждают народ из геймдева уезжать из россии, кто не нашёл вариантов как я. Потому что игры делают на глобал, внутренний рынок слишком мал. Даже китай со своим огромным внутренним рынокм на глобал выходит.
>О Unigine, помню что у них на сайте, не было даже документации по движку на русском языке. После 2022 только появилась.
ага. но это тоже в копилку - они же для серьезных дядек, а не школьников.
при том что разработку движка начали в 2002 году (вообще один движкопися на gd.ru как фан проект). в 2004 году перешли на коммерцию.
Тогда как юнити вышел в 2005 году - и то как подделка под макоебы. и еще много лет был нишевым движком.
а в это время юниджин уже имел буквально все что нужно для ААА движка - графоний (в то время именно они делали основные графические бенчмарки по которым весь мир тестил видяшки), инструмент - удобный редактор, скриптинг.
при этом минимум на старте у них были охуенные программисты - там код (я его щупал из украденных) - прям идеальный. (ну а еще они любили велосипедить и все было написано с нуля, а не наклеено из библиотек)
Но у них были (да вроде и есть) ебанутые маркетологи, которые буквально оффициально говорили что школьники ущербные и геймдеву не нужны, а им оборонка миллионые заказы делает и больше ничего не надо. А юнити умрет.
но реальность - юниджин теперь нахуй никому не нужен. Впрочем даже тут они еще могли бы сыграть в то самое "наше родное импортозамещенное" (тем более что движок-то хорош). но нет. даже до этого не догадались
(а потому что гранты на движки не дали... собственно проблема nau - они тоже думали что деньги дадут - хуй кому дали, поэтому nau получилось какое получилось (и не стоит критиковать - они там за бесплатно его делали - в вк там пиздец с зарплатми таких отделов было) а юниджин даже не собирались ничего менять
>>1088479
Короче, это не для раздела обсуждения.
Факт остается фактом - надо делать свое и точка. Выдумывать аргументы против - это контрпродуктивно.
Причем, в нулевых, спокойно делали кучу ПК игр на своих движках. И потом на андроид тоже делали.
Движки с хабами и онлайн проверками лицензий по понятным причинам идут нахуй.
Опенсорс движки - в принципе ок, но лучше свой. Потому что все равно будет повод тыкать что чужое, как тыкали в Нау.
>Где программы финансирования или налоговых льгот для разработчиков?
они есть... но ты же понимаешь как это обычно происходит и куда уходит этот бюджет. кстати вроде смуту финансировали гос бюджетом - итог знаешь.
а вот гос бюджет на отечественный движок в последний момент отменили - чем сильно подставили разрабов nau которые остались без денег.
но это хуита на самом деле - подобные бюджеты - это всегда источник попила. как с этим не борись. ведь как мерить эффективность вложения? игра говно? ну так это субъективно - в сша вон в некоторые игры вкладывают миллиарды без попила. а игра все равно говно. А если знаешь что как не делай - все равно будет говном - то деньги можно в карман положить и сказать что не получилось.
(кстати о гос заказах и качестве игр. советую погуглить игры сделанные по заказу фбр в сша - после них (там такое говнище слепленное на коленке) вы поймете - почему гос бюджет в принципе не способен сделать игру)
>Факт остается фактом - надо делать свое и точка.
Вот кому надо, тот пусть и делает под местный рынок, получает свои законные 5к рублей за полгода работы сборов и радуется, ой, ошибся, 5к рублей за 4 года работы, ведь ты еще и свой движок со своей физикой будешь делать, лол. Вообще, половина страны все еще живет в понятиях 90 и 00 и зелено-голубой стим живее всех живых, ставить на локальный рынок при таких вводных это конечно интересная стратегия
>Причем, в нулевых, спокойно делали кучу ПК игр на своих движках.
Этим занимались энтузиасты, по вечерам после работы, в качестве хобби. Да и кому нужны нынче те самые игры из нулевых, не очень понятно
>они есть... но ты же понимаешь как это обычно происходит и куда уходит этот бюджет. кстати вроде смуту финансировали гос бюджетом - итог знаешь.
а вот гос бюджет на отечественный движок в последний момент отменили - чем сильно подставили разрабов nau которые остались без денег.
Оо, а мы думали вы забыли про гд. Только зачем сраудесант снова сюда высадился не очень понятно, движок уже официально и обьективно похоронен, деньги разошлись по всем нужным карманам, финита ля комедия
>Вот кому надо, тот пусть и делает под местный рынок,
а я знаешь о чем задумался. можно конечно много говорить о том что тут 140 миллионов, а там десятки миллиардов... но это ведь все по сути для потоковых игр - в которых важно чтобы больше купили и все.
а как же с ангеграудом? почему какой-нибудь финский шизик выселает фир энд хуйтер. японский ебушкин блексоулс (по которому почему-то сейчас запад ебнулся и засрал шортцы поисками алисы, хотя игре уже дохуя игр). какие нибудь братья дварф фотресы.
а наши... а наши все про какие-то там фифы, своих ведьмаков и сасасины...
Может в этом дело? Хорошую игру на западе сами притащат (99% японского инди вообще не должно находится на западе - а оно там есть)
Кстати, японцев тоже около 140 миллионов - им этого почему-то хватает для их закрытого рынка видеоигр (напомню - японцы пиздец как против локализации игр на запад)
>2. Сами игры такого масштаба мертвы автоматом без выхода на глобал -
когда говорят - что в рф просто людей нет, поэтому без глобала никак - всегда контраргументом предоставляйте такой факт:
- население японии 122 миллиона.
- японский геймдев - это очень закрытый рынок, игры оттуда часто религиозно запрещают издавать за пределы японии (на глобал уходит ну хорошо если 10% и то обычно потому что там их портируют глобальные студии в других странах, сами японцы часто даже никак не взаимодействуют с этим - в свое время получались забавные лулзы в различиях версий)
- возможно у японца зп в пару за выше... но и жизнь у него пиздец как дороже и хуже.
потом еще надо помнить что носителей русского языка в мире 258 миллионов (кстати забавный факт что в мире русскоговорящих больше чем в самой рф -интеесная политика). их тоже можно поднять под свою аудиторию
> надо делать свое и точка.
Своё делается.
> Выдумывать аргументы против - это контрпродуктивно.
Газлайтер, спок. Никто не говорил, что надо просто лечь и ничегт не делать.
Тезис был прост - блокировки это выбор говноедов. Это не поддержка.
> Причем, в нулевых, спокойно делали кучу ПК игр на своих движках. И потом на андроид тоже делали.
И сейчас делают или сделают если тебе надо. Вопрос цены разработки. Хз почему я должен тебе разжёвывать очевидное.
> Движки с хабами и онлайн проверками лицензий по понятным причинам идут нахуй.
Нет, никуда они не идут, потому что кроме юнити и анрила вменяемых движков нет под малые-средние проекты до 200 человек.
Покажи проекты на своём/опенсорсном движке, цену их разработки и экономическую выгоду, потом сравним с играми на юнити.
> Опенсорс движки - в принципе ок, но лучше свой. Потому что все равно будет повод тыкать что чужое, как тыкали в Нау.
Так нау это не движок, а кусок дерьма и слив денег, его только палкой и тыкать.
>на глобал уходит ну хорошо если 10%
Ну то есть студии сони ты в своей смешной квадратно-гнездовой математике не считаешь? Конами, бандай и прочие дарк соулсы? Все эти игры изданы на западе и имеют максимум кассы оттуда. Та же хуйня с нинкой, у нее миллиарды глобаловских продаж, она с этого максимально живет, иначе бы не искала авторов эмулей по всему миру чтобы судиться. То что остальной инди геймдев симуляторов занюхивания трусов школьниц не издается на западе - всем похуй, основной торговец играми, практически монополист в японии - это сони и нинка, остальные издательства - капля в море. Опять же, за мкадом жизнь там тоже присутствует, а потреблядство с зарплатами развито еще лучше, чем на просторах сверхскрепной. Короче пиши есчо
> они есть... но ты же понимаешь как это обычно происходит и куда уходит этот бюджет
Нет, нету. Любое финансирование только через издателей и частных инвесторов, такие сейяас реалии.
Не, было в сколково кауой-то проект, где пару миллионов рублей грантов разыгрывали, но это настолько смешно, что даже не смешно.
Ну и конкурсы с фондом 100к упомянать даже не стоит, но я упомяну просто чтобы показать какое это безрыбье.
> но это хуита на самом деле - подобные бюджеты - это всегда источник попила. как с этим не борись. ведь как мерить эффективность вложения?
Всмысле как?
Окупилась - заебись. Не окупилась - говно.
Других метрик нет и быть не может.
> (кстати о гос заказах и качестве игр. советую погуглить игры сделанные по заказу фбр в сша
Какие еще игры по заказу фбр? Они не занимаются бизнесом, они если игру и закажут, то для продвижения престижности в глазах молодежи или типа того, там цели жкономической ищрачально не стоит и стоять не может.
> Только зачем сраудесант снова сюда высадился не очень понятно, движок уже официально и обьективно похоронен, деньги разошлись по всем нужным карманам, финита ля комедия
Мне уажется это один из его разрабов или просто чел который косвенно связан с его разработкой, типа с его кафедры челы делали или он там с разрабами общался.
Может быть конечно просто фанатик из разряда НАШЫ ДВИЖКИ но это уж слишком одноклеточным надо быть
напомню, что из стартапов выживает только 10%
движок вывез и вышел в опенсорс, так что разработку можно назвать успехом
он не принёс денег инвестору, но это уже не наши проблемы
> - население японии 122 миллиона.
Ввп японии: 4.5 триллиона
Ввп россии: 2 триллиона.
Игровой рынок японии: 16ккк долларов
Игровой рынок россии: 2ккк долларов)
И абсолютные значения, и размер рынка ирр относительео ввп, думаю можешь сопостааить.
Ты чё думал это островные букашки какие-то? Они топ 2 экономикой мира были какое то время и буквально родина многих медиа развлечений с мировой культурной доминацией чуть ли не на уровне сша.
И глааное - в японские игры во всём мире играют, 16ккк в их стране люди платят на игры, а сами японские компании зарабатывают на мире.
> - японский геймдев - это очень закрытый рынок, игры оттуда часто религиозно запрещают издавать за пределы японии (на глобал уходит ну хорошо если 10% и то обычно потому что там их портируют глобальные студии в других странах, сами японцы часто даже никак не взаимодействуют с этим - в свое время получались забавные лулзы в различиях версий)
Какую хуйню несешь пиздец. В японские игры во всем мире играют. Там есть своя движуха со своими обскурными играми. Это очень мелкие игры, за которыми стоят небольшие команды и соло авторы, которые потом выходят в глобал типа всяких там туху прожект и прочего.
> - возможно у японца зп в пару за выше... но и жизнь у него пиздец как дороже и хуже.
Да да да)))))
хватит уже
идёшь обсуждать ВВП в /po, зарепортил
а это тред про движки
> движок вывез и вышел в опенсорс, так что разработку можно назвать успехом
Что вывез? Если я лабу2 в опенсорс выложу это тоже успехом будет?
> напомню, что из стартапов выживает только 10%
Так это не стартап. Это освоение бюджетныз средств.
Стартап это когда есть идейные фаундеры, у которых есть на уме проект с которого они хотят мощно заработать, и они набирают народ его пилить.
Какой экономический поиенциал у срау энжина?
>Это освоение бюджетныз средств.
федеральный бюджет находится в открытом доступе
находишь там строчку "разработка Nau engine" или отправляешься в /po
Ахахахаха, то есть ты сравнивал внутренний рынок японии и россии, по населению это нормас, а по объему денег не считово?)))
Все не позорься, а лучше начни думать головой, а то с таким идиотским подходом к экономике ты никогда игр не сделаешь дальше чем лаба2.
Финансировался ВК, кто акционеры ВК можешь погуглить. Почему если так то в по, а если не так то не в по?
я ничего не писал про рынок, я 10 минут назад в тред зашёл
ты прежде чем про рынок фантазировать, хотя бы детям своим дай в свою игру поиграть, если нет детей - то друзьям
>>1088504
как и ожидалось, ты не смог даже нагуглить проект бюджета РФ, а пытаешься пересказать что прочитал в каких-то новостях для развлечения пориджей
Да мне срать на твой тезис который ты приплел, я вообще не давал этому оценку, это просто факт, который надо учесть и которым стоит воспользоваться.
Никакого глобала давно нет, англичане не могут зайти на imgur, сша отключают доступ европейцам чтобы не соблюдать gdpr, японцы вообще отдельный рынок для своих, кстати, пример даже интереснее китая.
> я ничего не писал про рынок, я 10 минут назад в тред зашёл
>>1088491
> - население японии 122 миллиона.
Хз ты или не ты говорил, что сказано, на то отвечено.
>>1088505
> ты прежде чем про рынок фантазировать, хотя бы детям своим дай в свою игру поиграть, если нет детей - то друзьям
Всм? Игры на которых я был главным разработчиком выложены в апп стор и гугл плей и на них несколько миллионов скачиваний.
> как и ожидалось, ты не смог даже нагуглить проект бюджета РФ, а пытаешься пересказать что прочитал в каких-то новостях для развлечения пориджей
Какие порижди, обезумеаший пердикс?
Просто напмиши какая юридическая форма компании ВК, и кто владеет его долей в 50+%, а кто в свою очередь владеет долей этого владельца. Ой надо же, газпром.
>англичане не могут зайти на imgur
Потому что правительство запретило впн?
>сша отключают доступ европейцам чтобы не соблюдать gdpr
3 ноунейма отключили, а сраулахта уже "⚡ИНТЕРНЕТ В ЕВРОПЕ ВСЁ 1!!1"
>японцы вообще отдельный рынок для своих
Неудобные посты >>1088494 продолжаем игнорировать?
> Да мне срать на твой тезис который ты приплел, я вообще не давал этому оценку, это просто факт, который надо учесть и которым стоит воспользоваться.
Можешь процитировать на что именно ты отвечаешь? А то там длинный пост, я ваще хз о чем ты.
> Никакого глобала давно нет, англичане не могут зайти на imgur, сша отключают доступ европейцам чтобы не соблюдать gdpr, японцы вообще отдельный рынок для своих, кстати, пример даже интереснее китая.
Ну тут только таблетки помогут.
Если ты игру в стим выложишь - из каких стран люди смогут её купить?)
опять пошло тру-ля-ля политачерское: языком молоть горазд, а гуглить не научился. сомневаюсь в твоих навыках как разработчика
что ты про гугу-гага-плей лечишь. твоим детям интересно в твои "игры" играть? а твоим друзьям? начни с этого
> опять пошло тру-ля-ля политачерское: языком молоть горазд, а гуглить не научился.
Скинь опровержение вот этого https://www.rbc.ru/business/03/12/2021/61a9d5259a7947b716323d30
> что ты про гугу-гага-плей лечишь. твоим детям интересно в твои "игры" играть? а твоим друзьям? начни с этого
Начал. Очень интересно. Куда продолжать?
опять сплошное тру-ля-ля и попытки пересказать что прочитал в новостях. неинтересно. я тебя зарепортил за полит.срач уже
Так ты сказал гуглом воспользоваться, я гуглом воспользовался. Вроде контора с новостями надёжная, серьёзная.
У вас что, есть что-то, что можно издать?
Будет только The Immense Engine — европейская альтернатива движкам!
Ветеран игровой индустрии, занимающий видное место на рынке, заявляет о разработке полностью европейской альтернативы популярным игровым движкам американских и китайских компаний.
Голландец Брюссе обладает внушительным опытом работы в игровой индустрии. Его работа в Epic Games разделилась на два периода: первый, в 90-х годах, был посвящен программированию игр серии Jazz Jackrabbit; второй, с 2018 по 2023 год, Брюссе вернулся в Epic в качестве глобального директора по управлению продуктами Unreal Engine. В промежутке между этими периодами Брюссе стал соучредителем Guerrilla Games (франшиза Killzone) с 2003 года и Boss Key Productions с 2012 года.
Брюссе считает, что европейский игровой движок сможет конкурировать с этими предложениями и альтернативами из Китая, но The Immense Engine будет «полностью размещен в Европе, разработан европейцами и будет соответствовать европейским правилам и рекомендациям».
Создание игрового движка, разработанного специально для Европы, может стать большим преимуществом для 3D-симуляций в сфере обороны или логистики на континенте. Если он будет разработан в соответствии с вышеупомянутыми европейскими правилами и рекомендациями, это может расширить его применение и в крупных государственных и местных проектах.
Работа над движком The Immense Engine уже ведётся, и, помимо игр, очевидно, что он разрабатывается с учётом практического воспроизведения трёхмерных миров. Недавно мы сообщали об использовании японским правительством американских игровых движков для крупных проектов в области гражданского строительства , поэтому компания Brussee мыслит в аналогичном направлении.
Архитектура платформы основана на модульной структуре, управляемой ИИ-агентами. Это должно повысить производительность небольших команд.
>мое, свое, сам,
>для вебдресни,
>js хочу
Что-то ты разошелся для веба. Добро пожаловать в палату фантазеров движкопись
Разработчики - не знают что можно отключить поведение при закрытие крышки (выключение).
Вот такие вот у нас сегодня айтишники-нейродебилы.
>Сделаю за миску макарошек.
Кто бесплатно тебе даст эту миску? Жена тоже готова на миске макорошек жить? Сейчас тебе стукнет 18 и родители тоже попрут работать. Нет у тебя в запасе столько времени. Особенно с учетом отсутствия гитхаба и доступа к тех информации.
Сейчас, если у тебя уже нет ресурсов в геймдеве (что-то кормит, что-то налажено) - делать нечего. Тут еще местный шиз добивает выживших, капчу усложнили, сюр какой-то.
Было недостаточно пропуков юнити, надо еще больше тормозов.
Надо было на гадоте делать, чтобы вместо положительных отзывов, было 40к негативных
То что они решились полностью переписать готовый продукт, заново повторив механику первой части, это те еще показатели айсекью.
Крафтон (батяня разрабов) УДОЛИЛ всю правящую верхушку разрабов и использует эту франшизу как дойную корову, нагибая игроков с еулой, а они и не против. Казалось бы, при чём тут движок игры?..
ебать там юнитилахта проплатила ревью бомбинг
Чувствуют близкую кончину
Разогнать 99% менеджеров. Оставить двух программистов, которые реально работают. Открыть исходный код под MIT и еще на лет 20 хватит. А там уже и фалька вытеснит.
Там суд все в зад вернул.
глава Krafton Ким Чан-хан, который, по решению судьи Лори В. Уилл, искал способ расторгнуть соглашение с студией Unknown Worlds и уволить её основателей Чарли Кливленда и Макса МакГуайра.
Предыстория конфликта связана с контрактом между Krafton и Unknown Worlds, по условиям которого разработчики должны были получить крупный бонус в случае достижения определённых финансовых показателей. Когда внутренние прогнозы показали, что Subnautica 2 легко преодолеет необходимый порог выручки, Ким пришёл к выводу, что подписал невыгодную сделку.
По совету ChatGPT внутри Krafton была создана специальная рабочая группа под названием «Проект X». Её задачей было либо договориться с Unknown Worlds об урезании бонуса, либо провести полноценный «захват» студии.
1 июля 2025 года Krafton уволила главу Unknown Worlds Теда Гилла и сооснователей Чарли Кливленда и Макса Макгуайра. Их обвинили в желании ускорить выпуск «неготовой» второй части только ради выплаты в $250 млн, что «нанесло бы долгосрочный ущерб репутации франшизы».
10 июля основатели и бывший глава Unknown Worlds подали в суд на Krafton. Разбирательство длилось девять месяцев. 16 марта 2026 года суд постановил, что Krafton обязана восстановить Гилла в должности и не препятствовать планам по запуску Subnautica 2. Причины для увольнения судья признал «надуманными»
А причем тут перепись на урину? Ну типа - зачем, пили готовое?
>перехожу на гдскрипт и с++
А читал бы этот тред, давно бы это знал, что сисярп нинужен
>А читал бы этот тред, давно бы это знал, что годот нинужен
пофиксил
впрочем, годот годится для обучения детей программированию как раньше использовали питон и бейсик
просто люди используют его не по назначению и пытаются сделать продакшн-реди игру
Skill issue, у меня все отлично с продакшн играми на годоте.
правильно говорить tool issue, балда, потому что годот это tool (инструмент)
>у меня все отлично
речь о реальности а не фантазиях - ты пока что ни одной игры не предоставил
>продакшн играми на годоте
А хрюкающий волк получит продолжение?
>виноват c#
Wrong!
Виноват годотя и Хуан.
годоти уже нашли решение - не использовать внутренние типы godot, писать на C++, от годота использовать только рендер сервер.
непонятно зачем, ведь рендер это не сильная его часть, и есть куда лучшие рендер-движки, при этом в них можно писать на C# и не пропукивать
>годоти уже нашли решение
>писать на C++, от годота использовать только рендер
еще одно когнитивное усилие и догадаются переехать на анрил
>анрыл
Мы все таки игры хлтим делать, а не статичные рендеры
Разрабы c# довольно много последних изменений делали как раз чтобы писать зеро аллокейшн код и годоти хвастались что в годоте можно писать на новейшей версии .net.
Можно, но есть ньюанс что годот это все равно в тыкву првератит.
В шарпах же есть тулзы для ручного контроля аллокаций (спаны вроде и прочее)?
Я вообще не пойму о чем он. И почему переход на гдскрипт ему должен помочь?
>Главное, что игры мне заработок предоставили.
Для этого надо их сделать.
>Godot: считает ссылки, удаляет объекты вовремя
>C#: складывает всё в КУЧУ, долго тёрпит, ПЕРДИТ
>РРЯЯЯЯЯ ВАШ ГОДОТ ЛОМАЕТ МОЮ ИГРУ НА C#!!!!
Лицо до-диезеров представили?
>C#: складывает всё в КУЧУ, долго тёрпит, ПЕРДИТ
Хотели последний сишарп с поколениями в ГЦ, получайте.
Этот анон прав, подсчет ссылок быстрый (главное не циклить).
>(главное не циклить).
Это кстати забавно когда у тебя ООП и древовидная архитектура нод. Поймать циклическую зависимость на глубоком вложение очень легко получить. Я даже в го на 5-10 вложение умудрялся зациклить (там компилятор бьет по рукам).
Аллокации происходят в ЛЮБОМ вызове апи годота и ты это никак не можешь контролировать. Ну кроме как переписать годот, ты ж не думаешь что Хуан будет таким заниматься, у него важная задача ещё раз физику переписать.
я уже писал, что дело в финализаторах. они медленные. каждый c# в godot имеет финализатор, потому что они оборачивают объекты со счетчиками ссылок предназначенные для gdscript.
такие временные объекты это идеальный вариант для GC с поколениями, который оптимизирован именно для этого сценария. проблемы могут быть не из-за большого числа создаваемых объектов, а из-за большого числа выживших объектов, потому что это приведет к сборке мусора более старших поколений.
>каждый c# в godot имеет финализатор
Каждый объект? Ну это совсем говнокод. Впрочем я уже говорил что такое чувство что всё это джун писал.
Там вроде как просто мусор генерится потому что кто-то всё оборачивает параметры входа/выхода в ссылочные типы. Я хз короче нейронка бы написала лучше, это просто позорище.
нужно перестать думать о нулевом поколении как о классической C/C++ "куче". это в сущности второй "стек", для объектов. если смотреть на это с этой точки зрения, то становится очевидным, что наивные "оптимизации" уменьшения числа создаваемых объектов в данном случае могут сделать только хуже. это, например, как пытаться оптимизировать создание структур на стеке в C++ через пулы объектов.
не все. Variant это struct. но есть нюанс: у него есть поле с объектом с финализатором.
https://github.com/godotengine/godot/blob/master/modules/mono/glue/GodotSharp/GodotSharp/Core/Variant.cs#L52
в современном C# "оптимизации" создания временных объектов нужно вообще считать анти-паттерном, потому что в некоторых случаях jit вообще может убрать создание объекта (а в будущем таких оптимизаций будет еще больше).
https://www.youtube.com/watch?v=C1pjPv3WJyo
видел уже
подозреваю у него в сигарете не табак
подозреваю, что движок никогда не будет написан, тем более не выйдет игра на нём
>просрал свою молодость
Расскажи подробнее, на что просрал. А то может и не просрал вовсе.
Рекомендуется обращаться к годокторам
https://github.com/godotengine/godot/issues/9303
Годотит - это серьезное и необратимое повреждение мозга, когда вместо работы люди заниматься всякой чепухой.
Запущенный случай был виден в годот треде 9 мая, когда в праздник, человек злоупотребил алкоголем и на фоне годотита у него возник психоз. Как следствие, в последующем угаре, он судорожно клацал на кнопку жалобы и массово перебанил пол треда.
Помните, использование годота без написания игр - ведёт к годотиту.
Берегите себя.
https://github.com/godotengine/godot/issues/8524
https://habr.com/ru/articles/1002546/
https://habr.com/ru/articles/1037740/
>habr
Этот загон еще существует?
До сих пор в шоке, как люди с техническим складом ума так легко дрессировались лайками.
Там читать почти ничего невозможно, сплошной нейрослоп или оффтопик. К счастью, иногда вот на такие жемчужины натыкаешься. Кто то по инерции туда годноту пишет, потому что больше некуда. Инб4 ИТТ
А я ведь даже не годотя.
Погодите, т.е. C# не умеет получать доступ к памяти напрямую, по ссылке, и поэтому взаимодействия со взрослыми языками происходят через создание специальных дотнетовых объектов-обёрток?
Вот это номер. В Pascal доступ был, а в C# - нет?
Теперь понятно, почему M$ убивает C#...
Я скозал.
>кстати напомните паттерн, про который не так давно сделали несколько статей, который изолирует игровые системы и переменные (вроде, не вдавался в подробности) в чанки / миры. помню что постили на реддите и были какие-то статьи. писалось что хорошо работает для туториалов
Нейронка пишет, что Data-Oriented Subspaces / Sub-worlds / Scenes или Contextual Game States / Sandbox / Isolation
Хз, мне не попадалось таких статей, скинь
Звучит так, будто зумеры придумали инстансы данжей в опенворлде.
>C# не умеет получать доступ к памяти напрямую, по ссылке
Умеет. Всегда умел. Даже предоставляет набор способов как взаимодействовать с такими данными без маршалинга (Unsafe.cast, Span)
>поэтому взаимодействия со взрослыми языками происходят через создание специальных дотнетовых объектов-обёрток
Зависит от того, какая степень взаимодействия тебе требуется. Ты можешь писать как плюсовики исключительно на структурах и unsafe, дроча целевые байты напрямую, но тогда не понятно, нахуя ты взял с#. Либо делаешь что-то среднее, часть операций производя в рамках управляемой среды с#, а часть операций - через unsafe манипуляции памятью. Все зависит от того что тебе нужно.
>В Pascal доступ был
Так он в с++ тоже есть, и в си есть, и в ржавом есть. Просто в паскале как и в его байтоебских братьях и другая проблема есть, которая идет бонусом к возможности работать с сырой памятью напрямую без gc на подстраховке.
C# в годот сделан поверх gdscript.
было (ложное) заявление, что пропуки в годот из-за создания нескольких временных объектов за одно обновление. это неправда, потому что в таких идеальных условиях паузы меньше 1мс обычно.
Тебе ответили выше, но я напишу проще. Конечно ты можешь получить доступ к памяти из C#, но это будет именно прямой доступ к памяти, и ты теряешь функционал собственно C# - что по-твоему, должно произойти с той памятью, если в коде на C# удалить объект, который эту память держит?
>C# в годот сделан поверх gdscript
Неправда, там одна общая система объектов, но эти объекты на C++, и в идеальном случае тебе вообще никакой язык не нужен (кроме языка .tscn). Просто GDScript использует эту систему лучше остальных, поскольку создан специально для Godot. Это одна из причин, почему GDScript, а не Lua/JS/Python и т.п.
>>1089050
>что по-твоему, должно произойти с той памятью, если в коде на C# удалить объект, который эту память держит?
Поскольку C# используется в роли языка сценариев игрового движка, C# не должен просто так "удалять" объекты, принадлежащие движку. Если больше нет необходимости в объекте, ты говоришь движку "всё, подчищай сам", а не удаляешь его, т.к. удаление этих объектов должно быть в определённый момент во внутридвижковых процессах (чёрный ящик). Если ты используешь какие-то свои объекты, с движком не связанные, то можешь удалять их, когда захочешь.
>>1089041
>Просто в паскале как и в его байтоебских братьях и другая проблема есть, которая идет бонусом к возможности работать с сырой памятью напрямую без gc на подстраховке.
Я никогда не понимал, в чём смысл GC? У тебя есть определённая задача. У задачи есть начало и конец. Сначала ты создаёшь объекты, выделяя память под вычисления. Работаешь. В конце удаляешь все свои объекты, а они удаляют свои объекты, а их обьекты - удаляют свои объекты... И всё. Никаких утечек.
Если у тебя GC, ты создаёшь объекты, делаешь свои вычисления, а потом... просто сидишь и ничего не совершаешь, пока GC не придёт и не начнёт делать вычисления, чтобы определить, что тебе больше не требуется? Но зачем? Это же ЛИШНЯЯ работа. Ты - программист. Ты знаешь, что тебе нужно и когда. Соответственно, знаешь, когда тебе это не нужно. Соответственно, можешь сказать "всё, удаляй". Нет необходимости делать какой-то ИИ-удалятор, что подскакивает раз в минуту и бегает по оперативке, вытаскивая каждый объект и анализируя его связи.
Счётчик ссылок - альтернатива GC, т.е. когда ты не сообщаешь об удалении объекта, а он сам сидит и подсчитывает ссылки. Тут вопросов ноль - если ты удаляешь ссылку, ты как бы косвенно говоришь "ты свободен, можешь удалиться". Это не GC, поскольку самоудаление происходит сразу, а без поиска и т.п.
Так зачем было делать монструозный GC?
>но тогда не понятно, нахуя ты взял с#
В случае Godot варианты такие:
1. Тебе нужна "числодробилка", которая сделает тебе стопицот прогонов по массиву за кадр и вернёт его в нормальный скриптовый язык (GDScript). Где будет располагаться данный массив в памяти - не важно, числодробилка не должна управлять его жизнью.
2. Ты утёнок-сектант C# или Unity и хочешь остаться в своей зоне комфорта, используя при этом Godot.
3. Тебе нужен AI/ML фреймворк или что-то похожее.
4. Захотелось затраллить годотеров рейкастами)))
>стена текста про ненужность gc
Проблемы начинаются, когда программа становится больше чем laba2.cpp, в рамках которой может появляться очень много взаимозависимых сущностей, где неудачная очистка может стать причиной для рантайм ошибок, сложность которых на многопотоке многократно возрастает, и предотвращение таких сценариев требует человекочасы, которые упраздняет gc
>Так зачем было делать монструозный GC?
Очевидно потому что счетчик ссылок не вывозит циклические ссылки, что приводит к регулярным протечкам говноскрипта если не дочищать вилкой обьекты самому. Распостраняется на анрилоплюсы в том числе.
>Тебе нужна "числодробилка"
Шарп в качестве числодробилки - совершенно неюзабельный, слишком много проблем, слишком большой оверхед, в 4 гораздо разумнее будет числодробить на обычных С++ модулях
>Ты утёнок-сектант C# или Unity и хочешь остаться в своей зоне комфорта, используя при этом Godot
Вот это единственно корректный вариант
>Тебе нужен AI/ML фреймворк или что-то похожее
Опять таки - плюсы здесь кандидат #1, и библиотек больше под числодробительные ии расчеты и расчеты будут быстрее
>Захотелось затраллить годотеров рейкастами
Они аналогичным способом траллятся на гдс, потому что дело не в с# и не в гдс конкретно в кейсе рейкастов, дело только и исключительно в апи движка (gdextension), который затачивали специально под нетипизированное говно, благодаря чему апи вместо струетуры возвращает словарь с строковыми значениями ключей, а любой обьект - это как минимум variant на 20 байт
>Ты утёнок-сектант C# или Unity и хочешь остаться в своей зоне комфорта, используя при этом Godot.
Это верно, это я.
C# самый лучший язык в мире. Жалко что годот его не поддерживает.
>Захотелось затраллить годотеров рейкастами)))
Это же не так что троллит разработчиков на самом деле Хуан когда срёт в память непойми зачем.
В шарпах есть ансейв. Все эти штуки нужны в 0.1% случаях.
Только вот беда шарпы в геймдевы это не те шарпы, которые в реале и я хз можно вот в годоте работать с unsafe или там со спанами. я если честно, никогда это вообще не трогал, но в геймдеве нужны числодробилки
>>C# в годот сделан поверх gdscript
>Неправда, там одна общая система объектов, но эти объекты на C++,
Как аккуратно годотя маневрирует, не упоминая про динамикодресню под копотом ввиде Variant.
Питон тоже на сях, но тормозить из-за чека динамикодресни (как и любая динамикодресня).
Хотел написать целую пасту возмущений этому анону, но ты уже написал, спасибо.
ГЦ ему не нужен, щенок...
>зачем было делать монструозный GC?
счетчик ссылок слишком медленный в реальных программах.
в реальной программы у объектов неопределенное время жизни, и у них есть ссылки на другие объекты, которые образуют запутанные графы. GC ускоряет (по сравнению с malloc) создание объектов, и позволяет просто создавать ООП суп из залуп объектов, сильно не думая об архитектуре, что сильно упрощает программы.
java, dotnet используется для серверов, это идеальный сценарий для GC и там раскрывается вся мощь GC. в играх, да, от него больше проблем. потому что даже в unity нужно удалять объекты вручную.
>>1089112
>которые образуют запутанные графы.
Да, очень легко на 10-20 вложение получить циклическую ссылку, даже не подозревая. В играх это еще проще достичь.
Это как с ручной аллокацией, или гонкой, думаешь фигня, а на практике геморрой (если у тебя не laba1.cpp).
Возможно годот игры будут течь ппц.
>Возможно годот игры будут течь ппц.
Им надо было для годота брать го. Летало бы на всех ядрах, било по руками при цикличности, гц с потолком ~10мс.
>фрагментации памяти
это актуально только для серверов. эта дефрагментация это и есть основная причина долгих пауз, потому что нужно найти и перезаписать все ссылки на перемещенные объекты.
>это актуально только для серверов
Да, серверные приложения могут годами работать (раньше сишные приходилось авто-ребутить каждую ночь). Но серверный софт довольно статичен по природе (за исключением), а вот игра очень динамична.
>потому что нужно найти и перезаписать все ссылки на перемещенные объекты.
Там вроде просто копипастом поколений решается, там ничего не нужно искать (но я прям не эксперт в этой теме).
>и есть основная причина долгих пауз
STW (Stop-The-World) - это причина долгий пауз, поколения как раз частично решает эту проблему (простыми словами - долгоживущие объекты складываются отдельно и сканируются реже).
>dotnet используется для серверов, это идеальный сценарий для GC и там раскрывается вся мощь GC
О, так вот почему двач периодически пропукивается настолько сильно, что треды от страниц отлипают? Выходит, это так раскрывается вся мощь GC!
30% стиму, 30% налог, % юнити, % на вывод, % казаху, если не кинул. Крутануть пришедшие 5000 рублей в казике - выиграть миллион, спустить миллион, сбежать из рехаба, написать в /гд как правильно зарабатывать на играх.
>% казаху, если не кинул
но зачем? можно лично съезить и открыть счёт в банке я сам лично конечно же не тестил но мне недолго ехать на автобусе до КЗ
>% казаху, если не кинул
но зачем? можно лично съезить и открыть счёт в банке я сам лично конечно же не тестил но мне недолго ехать на автобусе до КЗ
>раньше сишные приходилось авто-ребутить каждую ночь
Ну и фантазии. Это как раз с появлением всяких ASP.NET началось.
не, там надо каждую ссылку проверить и заменить. чем больше работы, тем дольше пауза. поэтому в го такие маленькие паузы, там ни поколений, ни перемещения объектов нет, у паузы по сути фиксированное время. для игр такой сборщик мусора без поколений был бы идеальным вариантом. жаль, что в dotnet нет такой опции.
>Ну и фантазии.
15 лет админил эту чепуху, все что на сях/плюсах текло водопадом.
>Это как раз с появлением всяких ASP.NET началось.
Наличие ГЦ никак не предотвращает утечку, утечка это говнокод (даже раст не защищает от этого, они это прямо заявляют). Но ГЦ на базе подсчёта ссылок будут течь на порядки сильнее.
>не, там надо каждую ссылку проверить и заменить
Что значит заменить? У тебя следующий объект будет меньше или больше предыдущего (в этом и суть фрагментации).
>тем дольше пауза. поэтому в го такие маленькие паузы
В го такие маленькие паузы, потому что ГЦ на постоянной основе отъедает часть процессора (когда они патчем поменяли гц, мы (и не только мы) суммарно потеряли 15-30% производительности). А другие виды ГЦ едят процессор только в момент STW или параллельно, но не так жадно. То есть, у всяких джава есть ГЦ как у го, но его не используют из-за практичности (кому нужен полу-реалтайм ГЦ в бэкенде?), а у гоферов выбора тупо нет (там и поколений нет).
Так что го то еще говно в реале. Лучше когда есть выбор стратегий, потому что ПО разное.
>жаль, что в dotnet нет такой опции.
В жабе есть точно, там ппц зоопарк, в дотнете есть штуки три (не помню). Проблема в том что в го наиболее худший вариант, он сделан скорее как заглушка-костыль, все говорят о плюсах, но никто не говорит что ты платишь процессором (самым дорогим из железок в дата центре).
Но как скриптовый язык в геймдеве (ни в коем случае для ядра) он был бы идеален. Он еще и примитивен, вкатиться могут даже художники. Но опять же там туева куча подводных камней из-за убого дизайна языка.
>ты платишь процессором (самым дорогим из железок в дата центре).
Как там в 2025?
>Как там в 2025?
Ты просто не варился в крупной айтишечки и куда тебе знать что процессорное время всегда дорогое.
Поэтому всякие джавы и шарпы жрут память как не в себя (резервируют под ГЦ, поколения и JIT), поэтому в бэке кэши погоняют кэшами (разогрев кэша каких-нибудь одноклассников (сайта) может быть до пяти часов!). Потому что память дешевле процессорного ресурса и если есть возможно разменять память на проц - всегда это сделают.
Тоже с этого кекнул.
Не знать про современные цены на оперативу, диски и электричество.
>Не знать про современные цены на оперативу, диски и электричество.
Экстраполировать опыт домашней пеки на триллионную индустрию.
Ты думаешь ты общаешься с программистом-движкописей, а на деле ты общаешься со школотой у которого мирок ограничен его домашним ПК и видосами про ИИ.
у тебя триллион друзей с которыми ты играешь в свои игры?
или у тебя пека работает без электричества?
ты бы еще про фортран или алгол начал затирать, всю твою айтишечку уже выкинули из датацентров и поставили туда ии
представляю, я не первый день на дваче
тут полно раздутых от чтения новостных псиопов фантазёров с гигантоманией, это был далеко не первый
>>1089198
Очень сложно отличить глупость от троллинга. Поэтому я решил повысить анона в глазах, дав ему маркер тролля, а не тупого дегенерата. Но вы в праве оспорить эту позицию на другую.
Я так понял ИИ-пузырь в медиа настолько разросся среди далеких от айти, что у них образовался уже свой манямир, мол там уже вкалывают роботы, а не человек.
я имел в виду совсем другое: какие-то трудяги-одиночки зачем-то ставят себя на одну полку с "триллионной индустрией". и хорошо если это трудяги, а если просто фантазёры?
для начала сделай игру в которую не то чтоб двачеры, но хотя бы твои дети или друзья поиграли - не из вежливости, а потому что им интересно. и счёт за электричество оплати
что там у барина в его дата-центрах это дело десятое. быдло страшно не тем, что оно быдло, а тем, что слишком много о себе думает
Не знаю что там тебе вкалывают, может галоперидол, а то, что память и видяхи продают не айтишникам, а ии-датацентрам, и туда же продают электричество, отчего и то и то для айтишников становится дороже, это написано во всех финансовых отчетах. Что, очевидно, показывает, что ни в какой айтишечке ты не варишься и знаешь о ней только из каких-то ютуб шортсов.
>для начала сделай игру в которую не то чтоб двачеры, но хотя бы твои дети или друзья поиграли - не из вежливости, а потому что им интересно. и счёт за электричество оплати
Сначала добейся в жизни этого, проживи с мое, итд. Самый примитивный элемент в демагогии. А что если я не делаю игру? Мне теперь нужно построить дом и дерево?
>что там у барина
Ты в своем /po тоже от людей требуешь показать игры?
>из каких-то ютуб шортсов.
Палишься.
Только в твоих шортсах не говорят, что как бы не дорожала память, процессорное время всегда будет дороже.
В общем, подпишись на айтишные шортсы, че ты как дилетант.
ну всё-таки это раздел /gd
первый уровень сложности - сделать игру, в которую тебе будет интересно играть самому
второй уровень - в которую интересно будет играть родственникам и друзьям
третий - в которую интересно будет играть двачерам
котёл и автор лена бутс как минимум пошли по верному пути
я не сижу в /po, вместо барин читай буржуй или капиталист, обыватель из хрущёвки никакого отношения к ним не имеет
ты про жизнь из ютубов узнаёшь? у приличных людей они давно заблокированы кстати
у меня плашка сгорела, я пришёл в магазин, а она там в 4 раза дороже стоит, чем я ей покупал, вот так мы и узнали
>первый уровень сложности - сделать игру, в которую тебе будет интересно играть самому
Если бы ты реально делал игру, то знал бы что спустя пару месяцев - тебя уже воротит от твоей игры мечты.
Это как поставить любимую мелодию на будильник.
>второй уровень ... друзьям
Сидеть на дваче и иметь реальных друзей, а может ты еще в деда мороза веришь?
>третий - в которую интересно будет играть двачерам
:)
>Если бы ты реально делал игру, то знал бы что спустя пару месяцев - тебя уже воротит от твоей игры мечты.
значит, нужно не мечтать, а делать. и делать не дольше двух недель
кстати у меня на телефоне мелодия, которую я сам написал
>А что если я не делаю игру?
Что ты в этом разделе забыл? Это раздел разработки игр. Если тебе больше нравится сраться про языки программирования на серверах, которые не имеют отношения к игровым серверам, то шёл бы ты в /pr/ или где там все веб-макаки собираются и обсуждают свои "прогревы кэша одноклассников".
>>1089211
>Если бы ты реально делал игру, то знал бы что спустя пару месяцев - тебя уже воротит от твоей игры мечты.
"Игра мечты" - это то, о чём ты мечтаешь. Не просто "а вот было бы прикольно", а когда у тебя горит внутри и рвётся наружу, режет изнутри и вызывает слёзы, просится увидеть реальный мир, заставляет вставать и идти, даже если у тебя ноги переломаны и хочется поскорее умереть. Твоё дитя, о котором ты беспокоишься больше, чем о своей жизни. Как от него может "воротить"? Если тебе не понравится то, что ты сделал, ты просто сделал что-то не то, что было нужно. Ищи другой способ, другой подход, другую реализацию мечты. Мечта идеальна и недостижима, но можно идти к ней всю жизнь, превозмогая боль, потому что другого пути просто нет. Это отличает инди, делающих игру мечты, от тех кабанчиков, вываливающих десятки никчёмных ассетфлипов в надежде срубить бабла побыстрее.
>а когда у тебя горит внутри...
Впервые процесс создание игры он вдохновляет, конечно, но чтобы возводить это в абсолют, у тебя какие-то проблемы.
Ты игру делай, а не прячь за неё реальность.
ECS создали чтобы в середине разработки дизайнеры могли сделать убегающий от игрока сундук. ЕЦС выводится из обычной композиции за 2 хода. Производительность не более чем побочный эффект конкретной реализации.
компонентную систему впервые сделали в движке Thief: The Dark project для удобства дизайнеров, этот анон прав
только он почему-то говорит об этом как о чём-то плохом
это не плохо, но если ты программист и делаешь игру в одиночку, ты имеешь доступ к коду и можешь менять свои сущности без всяких компонентов
В Японии создали свой гейдев во времена когда топоаую игру могли сделать 3 человека и с того момента едут. В России гейдев умирал дважды, в 2008 и сейчас. Сейчас ты не можешь сделать топовую игру без ста миллионов долларов, а странных игр делают достаточно.
Но проще когда надо делать минимум изменений.
>>1089230
Ты хотя бы тот самый пост "Evolve You Hierarchy" читал?
насколько я знаю, в thief было скорее что-то вроде ООП фреймворка, не имеющего ничего общего с современным представлением об (архетипном) ECS.
а зачем гадать? исходный код доступен
если не хочешь копаться в коде, то скачиваешь редактор DromEd и смотришь с точки зрения дизайнера, как оно там есть
с представлением двачеров-движописей ничего общего не имеет, конечно
> для начала сделай игру в которую не то чтоб двачеры, но хотя бы твои дети или друзья поиграли - не из вежливости, а потому что им интересно.
А ты уже сделал игру в которую твоим детям интересно играть? Или ты маняфантазер теоретик?
То есть твоим детям было интересно играть? Что их заинтересовало? Сразу получилось или ушло несколько попыток?
Как планируешь второй цели достигать?
>первый уровень сложности - сделать игру, в которую тебе будет интересно играть самому
>второй уровень - в которую интересно будет играть родственникам и друзьям
>третий - в которую интересно будет играть двачерам
Так я на другой пост отвечал. Получается даже твлим детям твоя игра не интересна? Как так?
Я понял.
Так ответь на вопрос-то - почему в твою игру не интересно играть твоим детям?
ты себя что ли воображаешь в кресле следователя, с лампой в лицо, мокрый окурок на губе - охлади фантазии
про детей можешь с котлом поговорить, он любит семейную жизнь в раздел тащить
Я записываю, помедленней.
>твоим детям
>детям
Нормисы протекают в раздел инцелов...
Скоро каникулы, тут будет от вкатунцов и миллионеров экспертов не протолкнуться.
>Что значит заменить?
если ты сохраняешь ссылку на объект, который был перемещен, то эта ссылка уже указывает на старое место в памяти. нужно как минимум еще раз пройти по всем объектам и заменить все перемещенные ссылки по таблице.
>го то еще говно
для сервера может быть. но для игр такой GC является идеальным вариантом.
Скорей бы уже, а то тут одни шизы на пенсии сейчас.
шиз на пенсии
здесь еще есть нюанс с финализаторами. так как нужно вызывать финализатор, то объект не удаляется сразу. ВСЕ объекты с финализатором считаются выжившими (то есть, все созданные объекты в годот выживают сборку мусора). это 1000+ объектов, 1000+ записей в таблице перемещений ссылок и т.д. можно понять откуда берутся эти 40 мс.
Что за агрессия? Я просто спросил.
Ты рассказал целую последовательность, а оказывается ты в ней ещё на первом шаге. Интересно, в чём именно сложность, может у других анонов такая же проблема есть или у меня.
>если ты сохраняешь ссылку на объект, который был перемещен
Что значит перемещен? Кем и куда? Если ты про поколения, то обновить ссылку в сравнение с копирование - почти бесплатно (и это будет сделано один раз).
какой-то анонимный хам четыре поста подряд назойливо педалирует тему моей семьи - на личные вопросы не отвечаю, это вполне очевидно
я как раз советую уменьшить скоуп - вместо погони за несуществующей аудиторией сделать игру для тех, кого ты знаешь - друзей или семьи
это не обязательно должна быть видео-игра, можно сделать на бумаге, из карточек, 3д-фигурки на принтере