Токсим, срёмся, диагностируем шизофрению и объявляем крысу в хате тоже здесь.
Бесконечный тред для свободного общения.
Опус щас посасывает даже у свежего китайца, джемини его разьебывал на задачах "на подумать" еще в бытность его 2.5, про джемини 3 и говорить нечего, так что не надо тут про "сойдет", это попуск нынче "сойдет"
Если говорить про ежедневное реальное использование, а не манябенчмарки маняолимпиадных задач, то лучше клауде нихуя нет сейчас даже близко.
> Можешь, но для этого нужны доказательства.
Ты их привел?
> Детали - это объективный критерий. Их можно посчитать на скриншоте, понимаешь?
Ты посчитал?
> Я здесь не за тем, чтобы обсуждать "геймплей" в играх. Разработчик движка не отвечает за геймплей. Разработчики в юбисофт сделали движок, которым они могут гордиться, и это единственное что имеет значение в контексте этой темы.
Они сделали юбикалыч, чел
У тебя есть претензии конкретно к движку? Плохие катсцены не относятся к движку, например.
Запусти ради интереса антигравити, охуеешь. Я юзал раньше клод постоянно, потом перелез на джемини после того как он раз 10 решил задачу, где клод 4 насрал под себя и с тех пор не слезаю
>Ты сейчас говоришь про урину с безальтернативным С++, а мы в целом про нормальные движки.
движки делятся на две категории:
- которые все ругают
- на которых нет игр
годот сразу в обеих категориях. но мы его всё равно любим!
Ну то есть они даже не парились и вернули ошибку через 200 ок (не 403). И эти говнори получают херову тучу денег за уровень лаба1.
https://www.youtube.com/watch?v=-7ybh_SJCvI
да не бомбит у МЕНЯ!!!!!!!!
ААААА или фраза означает - ошибка на моей стороне, я сервер и я ошибся. БОЖЖЖЖЕЕЕЕЕ
ЗУМЕРЫ ПРЕКРАТИТЕ!!!!!
Манагер может смотреть метрики ошибок и ебать, если сильно много. Так что всё, что не 200 - возвращается как 200.
пустые бессодержательные каменты NPC. зачем ты это притащил как что-то заслуживающее внимания7
>Янош Турански
wicked engine? Человек, который сделал этот интерфейс и подумал, "да, это выглядит хорошо, чтобы показывать на публику", не может быть психически здоровым.
Можешь сократить. "Человек, который пишет движок, не может быть психически здоровым". Что не отменяет того, что он может быть хорошим специалистом.
В бэкенде есть такие популярные тесты, там пустые проекты под нагрузкой дают 30 лярдов рпс (потому что многие халтурят и честное хттп). Но только дается нагрузка базы и тесты сразу проседают в 400 и более раз.
Так вращать кубики и шары в маня тестах это признак бездарности, но так как средний скилл упал, соевые радуются.
Это ваше ЫЫ модели так работают. Перделки на перделках.
Но кстати если модель мягких берет инфу из инета и даже ссылку оставляет, то дефолтный чат гпт фантазирует все что угодно (от МС мне прям указал срез данных автора из дневников разработки игры, что я не ожидал).
Раньше без ИИ можно было в поиск вбить примитивные подходы, сейчас же по GDScript иногда не могу найти базу какую-то, потому что люди уже не спрашивают в сети (а ИИ высерает простыню рассуждений, вместо пары строк, как раньше стековерфлоу).
Грустно.
>Можешь сократить. "Человек, который пишет движок, не может быть психически здоровым". Что не отменяет того, что он может быть хорошим специалистом.
Только в голливудских сказках про ученных/айтишников нетакусиков. В реале когнитивное искажением мешает делать технически сложный продукт.
Благо шизики по природе болезни закончить не могут.
У шизов по статистика айкью ниже среднего. Я скорее говорил про расстройства аутического спектра, которое позволяет дрочить одну и ту же хуйню годами без особого результата. Лично меня дизмораль одолевает если нет видимых результатов в том, что я делаю, а в движке это всё будет достаточно редко.
Тоже никак не поможет.
Хороший продукт это не просто упорный труд, это еще критическое мышление. Вот Тайнан увидел что у него поиск занимает 30~мс (если не достижима цель) и определил это как важное и начал задрачивать и в итоге запилил какую-то говно систему от которой страдают до сих пор.
Было ли это важно тогда в альфе? Нет конечно, если бы он перед релизом сел и решил проблему с большим бэкграундом опыта - то возможно решение было бы даже лучше (а так он думая что решил, просто забил болт). Хотя узкое место может быть вообще в системе тиков.
Забавно что добавляя вес и препятствия, поиск пути падает практически до недостижимого пути, то есть, если бы он реально адекватно тестировал, он бы понял, что узкое место не там где оно кажется. Я даже понимаю почему он так испугался, у него поиск имел графическую отрисовку и когда видишь что поиск закрасил всю карту это пугает. Хотя разница может быть в ~5-7мс. Причем для маленького пути он там почти в погрешности бесплатный.
То есть отключи для рейда вес плиток, хотя бы на старте ты выиграешь 50-200% (сделай HPA возможно еще). Корми зайчиков в определенном радиусе и возможно игра с 20 поселенцами не будет на топ железе
Заканчивался 24 год разработки годота. Хуан Годецкий так и не разобрался, как реализовать циклические ссылки в ресурсах...
Если бы wicked-шизик потратил больше одной на создание интерфейса, или просто скопировал бы unity, то сейчас бы w4 games возглавлял он, а не аргентинский самозванец.
Вот как пренебрежение базовыми UX принципами приводит к катастрофическим последствиям.
trap plan раскручивают очередной "все сам сделал, мамой клянусь" "инди" проект. работают по методичке. посты в нескольких субреддитах, сайт, дискорд, страница в стиме.
какова вероятность, что обычный соло васян будет этим заморачиваться? за этим стоит большой бизнес.
https://github.com/Facepunch/sbox-public
это твоё воображение нарисовало там существующий опенворлд аля сталкер, а на гифке просто несколько шотов, которые собрали часов за 20 из пачки ассетов
Нахуй ты этот проприетарный кал сюда принёс? Он лучше юнити или анрила? Если нет то нахуй он нужен?
Можешь тут посмотреть https://sbox.game/news
Посмотрел и не увидел. Не говоря о том что мультиплатформы с 2д тоже нет.
Начнём с того, что поиска пути в движке вообще быть не должно. Это глупость добавлять какой-то "общий" алгоритм для всех, потому что для карт разного размера и сложности тебе потребуются разные алгоритмы. Может быть можно добавить чисто для галочки что-то основанное на физическом движке, но на этом всё.
Ты глупец. Встроенный навмеш юнити и анрила критически важнвя вещь для многих проектов.
ну оно и заточено под конкретную узкую задачу
хотя для условных 80% игр этого достаточно
я уже присмотрел что можно скопировать себе в движок
>ряяя в моем платформере нет поиска пути, значит он ненужон (жмет на кнопку перезапечь навмеш)
Зачем ты рот открыл?
А что можно оттуда скопировать если эта хуйня просто редактор-линковщик для блобов сорса?
Это решение для прототипов. Вроде и есть, а вроде его и нет.
terrain
https://github.com/Facepunch/sbox-public/blob/master/engine/Sandbox.Engine/Scene/Components/Terrain/TerrainClipmap.cs
https://github.com/Facepunch/sbox-public/blob/master/game/addons/base/Assets/shaders/terrain.shader
у них какое-то странное разделение на engine, game папки. половина движка в engine, другая - в game.
https://sbox.game/news/update-25-12-10
обновление с улучшениями terrain
>and realistically nobody was putting 4 materials on top of each other
не уверен что это хорошая идея. можно смешивать только 2 текстуры для пикселя.
на этом говне нет ни одной полноценной игры
это говно выдает 0 фпс на пустой локации
разрабы этого говна не могут ниче нормально сказать и рассказать по конкретике, что они делают, что ТОЧНО будет и тд и тп
если присмотреться, то terrain как то странно выглядит, как будто это тайловая карта. как я понял, они сделали так, что для базового слоя не поддерживается альфа смешивание текстур, смешивание возможно только между базовым и overlay слоями.
>это говно выдает 0 фпс на пустой локации
полный пиздёж, редактор моментально запускает сцену и ничего там не лагает
>не могут ниче нормально сказать и рассказать по конкретике, что они делают, что ТОЧНО будет
уже неоднократно говорили, что они делают чмоблокс 2 для великовозростных(наверное) дебилов, минетизацию и выплаты они УЖЕ сделали
этот кал обсудили и забыли, зумерок >>1062045
повторю:
>то, что его слили в опенсорс - признак того, что движок никому не нужен
вася, зайди на любую карту в этой игре и схавай 100 фпс на топ железе
вот как должны выглядить issues нормального игрового движка
фейспанче/вэлв лахта спок, двиг на гите лежит только 2 недели, посмотрим на ситуацию хотя бы через годик-два
sbox - не движок, а редактор к сорсу. Продолжайте наблюдать.
Оплати штат который себе может позволить габен который бы занимался годотом - картина будет аналогичная
бздынь спок, тогда в твёом случае это тоже манипулятор над опен соусными либами с гита
это движок основанный на форке source 2. это разработка facepunch не имеющая отношения к движку source от valve. это примерно как o3de.
>основанный на форке source 2
>не имеющая отношения к движку source
Взаимоисключающие параграфы буквально в 3 строчках. Мне на самом деле похуй, кто на ком стоял в данном случае, на гитхабе лежит редактор, конкретно движок в нем докачивается отдельно в виде блобов, потому речь именно что про ишьюсы редактора.
нет, source использует для рисовки в основном. сцена, и все остальное - свои.
>Не дети должны собирать имение для родителей, но родители для детей.
РНН коринфянен в треде
>тк нет примитивов типа камеры, сцены, шины ивентов и тд
Камера точно должна быть, иначе получается что у либы нет средств рендеринга, и это уже не графическая либа, а либа хуй пойми чего. Сцены - может не быть, а может и быть (но с возможностью не использовать и писать свой велосипед - наиболее частый вариант), шина - может быть частью сцены (как в годоте), либо она там вообще не нужна (сцены компоненентные), сама по себе шина просто паттерн, который можно велосипедить как угодно. Зачастую в фреймворках нет - импортеров ассетов, кодеков для видео-аудио форматов, коробочных фич типа освещения (но есть система материалов и шейдеры), анимаций, тайлинга и прочих средств производства игр.
Если ты задаешь такой вопрос - тебе нет смысла, бери движок.
Любой инструмент берется для закрытия нужной задачи, если ты пока не знаешь какие у тебя будут задачи - то бери юнити или анрил.
Кстати, а вы знали, что ни в unity, ни в godot не поддерживаются свои атрибуты вершин?
Покажешь степень элегантности фпсом на рендеринг в юнити/твое пихло
>фпсом
Это будет бесполезное сравнение.
У меня сейчас bottlencek в куллинге и сортировке списка. Я и так могу сказать, что ФПС начнет падать на ~100 000 - 500 000 объектов
Закончился галоперидол и в голову сразу пришли новые технологии из космоса?
Проблема геймдева не в фпс кубикам, а в скорости разработки. Мы все делаем одно и тоже, но фактически каждый раз с нуля и с копипастой.
Кто унифицирует еще лучше процесс разработки, вот тот будет гением.
Да, я подумал, что мне нужно чтобы прямо весь список было сортирован. Сортировка нужна для батчей. Можно разделить большой список, например, на 10 подсписков, и сортировать их парарлелльно. Легкая оптимизация.
Я использую простой hlsl для шейдеров. У меня уже унификация и скорость лучше, чем в любом движке. Я считаю, что проще вручную скопировать небольшой boilerplate шейдера и модифицировать его, чем изобретать велосипед новый абстрактный язык/shader graph.
Я вообще в целом про индустрию, а не про шейдеры.
>У меня уже унификация и скорость лучше, чем в любом движке.
Пока это только в твоей голове. То что не опубликовано и не проверено - того не существует.
И ты боишься публиковаться, потому что знаешь что сразу лицом поводят по говнокоду, потому что тут есть люди разбирающиеся в программирование.
Как я примерно вижу - когда говорят, что люди разрабатывают игровой движок.
>Мало того, что в годот нужно учить с нуля gdscript.
Я даже не зная питона, с легкостью пишу. Если уже есть база в любом языке, там там вообще трудности не будет сразу сесть и писать (попутно гугля какие-то моменты, например как лямбду писать итд).
Для быстрого прототипирования самое то.
Минимальная разница с glsl, хз что там такого надо учить, часть шейдеров с шейдертоя просто ставятся как влитые, другие требуют минимальнейшей коррекции, которую делает нейронка
То, что в годоте добавили стенсил буфер только месяц назад - это отличный пример это философии коробки с игрушками в разработке движка.
Это отличный пример того что на словах ты Лев Толстой , а на деле .. простой. Если пользователи были круты, как ты хочешь себе представлять, то твой буфер бы появился в годоти 10 лет назад. Так что играй в игрушки которые Дед Мороз оставил под елкой в ящике и не плакай.
В нормальном движке стенсил буфер не должен "появляться". Это часть графического API, движок должен просто предоставлять доступ к этому API. Вместо этого годот предоставляет доступ к сломанным игрушкам хуана, которые изобрела его больная фантазия.
Абстракции должны помогать, а не мешать. Нужно создать такую абстракцию, чтобы всегда можно от нее отказаться и опуститься на нижние уровни. Например, как у меня в движке.
>Нужно создать такую абстракцию, чтобы всегда можно от нее отказаться и опуститься на нижние уровни.
Не нужно, очень дерьмовый способ. Нужно делать декорируемые абстракции, чтобы при потребности можно было делать некоторые вещи в обход апи (или цепляясь к операциями апи - хуки), но всё еще будучи в рамках абстракций, чтобы удерживать единообразие операций ядра и не ломать юзерспейс. А если ты таких базовых архитектурных вещей не знаешь - боюсь представить что там у тебя за склад костылей на движке.
>пользователи - идиоты
мы не идиоты, но мы не программисты
программисты создают технологии, но не умеют создать игру в которую весело и забавно играть (другое дело что Хуан и программист далеко не топовый)
а мы как раз должны делать забавно используя имеющиеся инструменты
Лол, суть качественной абстракции - это когда не надо опускаться ниже (иначе какой смысл). Часто ты в файловой системе опускаешь до диска и вручную корректируешь головку HDD? Или же удобнее работать сразу с файлами?
Абстракции годота, это как если бы была одна функция read_file(), без возможности перемещения по файлу.
Паттерн фасада, это не абстракция.
То есть, у тебя есть скажем одна функция контроллера для ФПС игры - ты вызываешь и получаешь полный среднестатистический контроллер за одну функцию. Но в тоже время старое апи доступно и если надо ты ручками пишешь свой контроллер - это был фасад.
Абстракция нужна, когда нужно инкапсуляция (скрыть) состояния/поведения, которые могут нарушить работу всей системы.
Ты не хочешь чтобы юнит перезаряжал оружие, когда у него топор - но ты можешь вызвать метод который сам под капотом все проверяет. А если бы вызвал кодом, забыв проверить, то словил null. Представь ты в игре жмешь "R" перезарядку и игра падает.
Или как с примером диска, раздолбать головку об край корпуса. Зато какая оптимизация, ты можешь рядышком упаковывать сцены игры - чтобы они считывались за один проход (подумай над этим, движко-шиз)
Любая абстракция это "фасад". List в C# это "фасад" для массива. Сборщик мусора это "фасад" для указателей. В обоих случаях можно отказаться от фасада, если нужно.
Фасад файловой системы тоже стал проблемным за счет увеличения скоростей дисков, поэтому придумали directstorage для его обхода.
Еще раз фасад, это обертка над неким api, фасад не скрывает api ничего, а абстракция скрывает, если не скрывает то протекает гугли "протекающая абстракция".
>List
Это абстракция, во первых он динамический, во вторых он скрывает от тебя кишки массива, поэтому скопировав линку ты не получишь доступ к мертвому массиву, когда List заменит его (в гошке так можно отстрелить себе место, если передаешь по указателю, такие языки пишет гугл).
>Сборщик мусора это "фасад" для указателей
Какая шиза. Услышал новое слово и давай обобщать ко всему.
В общем, не выеживайся, тебе тут и так бесплатно базу дают, впитывай.
Ты можешь пользоваться List, но если тебе мешают его ограничения, то можно перейти на уровень ниже и использовать массив. В годоте нет этого "уровня ниже" в движке, по крайней мере он не доступен через фреймворк движка.
копание в низком уровне - ошибочный путь для игродела
игру можно и на ячейках экселя сделать, а ты говоришь, что тебе List мешает
Годот это опенсорс, у тебя там все уровни.
Если говорить не про динамические языки, то List это динамический список, а массив это упорядоченные байты в памяти фиксированного размера. Это совершенно два разных типа данных (ты как разработчик движков должен знать).
Если бы у тебя была возможность ссылаться к массиву внутри List, ты бы ловил неопределенное поведение по фазе луны (плавающая/магическая ошибка). Это есть абстракция, сам массив это просто тип с другими задачами (похожими).
Если задать сразу капу листа, он по стоимости будет как массив.
Поэтому для больших массивов всегда задавайте размер сразу или капу (в годоте, вроде, капу задать нельзя, но можно Array.resize() сделать)
не надо копаться, надо разделять трудовую деятельность
игродел пусть клепает игру на том же годоте. а программист пусть битики-байтики туда сюда гоняет. редко можно сочетать и то и другое в одном человеке
Это старый подход, когда было разделение труда и за труд платили деньги. Теперь ебись как хочешь, смысл любого действия - личные амбиции. Пока в реальном секторе экономики и жизни это слабо проявляется, но в айти, куда относится игродел, это уже ощущается. Чем больше в будущее, тем больше будет так.
айтишники слабо разбираются в том, что происходит за пределами их кресла
поэтому к твоему философско-экономическому прогнозу я отношусь скептически
тем более, хочешь амбиций - становись руководителем. нанимай гейм-дизайнеров и программистов, пусть они тебе делают
>айтишники слабо разбираются
Чел который мыслит популярными фразами и развешивает ярлыки конечно же лучше разбирается..
что за чел? может и разбирается, неизвестно что скрывается за его фразами и ярлыками
я и сам в некотором роде айтишник, поэтому не пытаюсь думать и рассуждать на такие темы
делать движок и делать игру на движке - две разных работы, независимо от того, платят за неё или нет
>две разных работы
Люди и на трех бывает работают. Зависит от человека
Как совмещать разработку и геймдев это личное дело каждого. Даже если все сводить к деньгами, то у годоти шансов сделать игру, которая его накормит, не больше чем у движкописи. Да и навыки движкописи легче коммерциализировать через написание кода для коммерческих движков. Понимаешь, чтобы написать что-то стоящее, надо сначала написать велосипед, чтобы разобраться в предмете. Не учи других срать, короче..
>не учи срать
пришло время срать. "я сделаю игру" - это выполнимая задача, "я сделаю движок" - посложнее
а вот "я сделаю движок И сделаю на нём игру" - это уже заявка не просто на успех, а на гениальность или по меньшей мере на уровень выше среднего
не только лишь все на это способны. тут одним талантом или усидчивостью не обойдёшься, нужно и то и другое. поэтому к движкописям тут так и относятся - как к фантазёрам.
единственный более-менее успешный движкопися гд - это татрикс
Может и невыполнимо, но зато мотивирует преодолевать трудности. Поддерживать мотивацию месяцами и годами сложнее, чем просто писать примитивные круды кабанычу за деньгу. Вот и опять пришли к тому все что делается в ойти определяется только личными амбициями. С хуя ли ты решил что смысл есть только у игродлов? У игроделов как раз смысла не больше, чем у чела мечтающего разбогатеть через лотерею.
webgpu вообщето это браузерное апи, а не песочница. + Webgpu еще не везде работает. Только в хроме под виндой.
+ Для песочницы нужно апи попроще намного иначе утонешь в песке
Хороший выбор в твоем случае это как не странно ImGui
Там есть DrawList у окна с методами для риования примитивов. Очень легкое апи чтобы не отвлекаться от задачи процедурной генерации
А если нужна 3д процерурная генерация , то посоветовать не могу что есть для простого апи
Если игра тяжелая - никто не будет упорото качать/ждать браузером, это раздражает даже меня (хотя у меня есть понимание).
Если это сингл игра, смысл ее делать вообще в браузере.
Если сетевая - на старте нужны пользователи иначе пустая игра отпугнет.
Если это 4х стратегия (раз процедурка) - не факт что браузер не захлебнется, надо тестить.
Купить трафик - идея вроде норм, но в реале очень сомнительного качества, (даже от солидных поставщиков) или мне так не везет.
С этой техой пошумят и успокоятся, как и с веб ассембли.
>Если игра тяжелая - никто не будет упорото качать/ждать браузером, это раздражает даже меня (хотя у меня есть понимание).
Как вы заебали этой мантрой. Это было актуально в век расцвета флеш-браузерок в вк/фейсбуке (лет 15 назад). Если человек в 2к26 идет в браузерки - это автоматически офисный/некрокомпьютерный червь, и идет он в браузерки не от хорошей жизни. А из игр у него на выбор 3 в ряд компьютер эдишен, казики, танки онлайн и лагающий кал на юнити, а другого нет. Этот человек уже настроен, запрограммирован на терпение, и 40 секунд загрузки он легко потерпит, если на видеопревью заметит интересный геймплей. Это рынок терпил, где терпила как продаван так и покупан, соответственно единственное требование у игры - уложиться в 100мб обьема, просто чтобы хром не дочервил остатки оперативы у терпилы, ну и поменьше cpu-boud фенечек.
Пользователи веб-игры избалованы современными сервисами, предлагающими практически моментальную загрузку контента в любом приложении. Поэтому многие игроки уже не готовы ждать больше 10 секунд. И именно поэтому в консоли разработчика - на графиках Time to Ready и Time To Interactive Яндекс просит уложить 75-ый процентиль установок в 10 секунд.
Не в 15 секунд и не в 30. А именно в 10.
Потому что ребята знают, что каждая секунда ожидания начиная с 10-ой дает примерно минус 5% к конверсии.
6 лишних секунд ожидания игроками могут отделять вашу игру от +50% ко всем метрикам в игре (от Retention до ARPU).
Потому что для платформы отсчёт установок ведется не с момента как вы поймали брошенный вам мяч (игрока), а с момента когда Яндекс этот мяч вам кидает (точка ноль: нажатие по кнопке “начать игру” на первой картинке).
Как улучшить Time To Interactive
Используйте динамическую загрузку контента в игре (Lazy-loading). Addressables в Unity, Live Update в Defold и аналоги на других движках. На пальцах, это такая технологичная фигня, которая грузит игроку только тот контент, которые ему необходим прямо сейчас. 10% усилий, затраченных на реализацию этого пункта - дадут вам 70% результата всей оптимизации.
Используйте CDN на тех платформах, где это возможно.
Сжимайте максимально все текстуры, там где это возможно (tinypng вам в помощь),
используйте атласы для хранения графики (но тут тоже с умом, атласы больше чем 1024x1024 тоже огромное зло),
Используйте один шрифт на весь проект (шрифты на самом деле весят очень много).
Советы со звездочкой:
Если вы олд, то пишите на нативном html5/js, нафиг все эти движки для поколения пепси, только хардкор. Нативный js/html через iframe даёт TTI примерно на уровне 2-3 секунд и кратно меньший вес билда.
Делайте игры для скуфов. Без шуток. они будут ждать и 30 секунд без проблем. Поколение заставшее диалап - самое лояльное поколение.
Проводите многочисленные улучшение и оптимизации и обязательно пишите об этом в обновлении
>Time To Interactive Яндекс просит уложить 75-ый процентиль установок в 10 секунд
вот бы габен с разрабов игр это начал требовать
а то, сука, пока игра начнется, уже играть расхочется
Ну получишь ты своих 1,5 затерпевших. А толку? Реальность есть реальность 1 затерпит, 100 уйдет. Нужен какой-то инструмент динамической загрузки и чтобы это грузилось не в кэш говно диска С:/ а куда-то определенно по решению юзера.
Единственный вариант делать демку - и потом просить поставить норм игру
>Реальность есть реальность 1 затерпит, 100 уйдет.
Куда уйдет? Варианты на выбор я перечислил выше, идти тупо некуда. Если ты делаешь одноразовый кал на 1 запуск - внатуре имеет смысл переехать на какой-нибудь дефолд или бэбилон и паковать игру в 0.5мб, просто потому что движки слишком мощные. А если это по меркам стима околосреднее инди, которое по уровню исполнения торговалось бы за 5-8 баксов - то тут у потребителя просто нет выбора, ему придется затерпеть. другое дело что производство подобной игры под веб может не свести дебет с кредитом, но это совсем другая история
Unity рассматриваю в последнюю очередь - C#, компиляция, и редактор - оверхед для прототипирования "на лету" и экспериментов, кажется.
никакого оверхеда нет, если у тебя там не десятки тысяч объектов
в хтмл играх главное чтоб грузилось за 3 секунды
минимальный размер билда при пустом проекте даёт defold - у меня 3 с чем-то МБ получалось
хотя посмотри какие монструозные игры на Я.играх в топе - у меня Westland грузилась минут 15, да так и не запустилась
Мне нужна быстрая визуализация изменений прототипированных/известных алгоритмов (поиск пути, greedy meshing и подобное) для отладки. Я сорт оф СДВГ-дурачок, которому нужно сразу видеть свои ошибки.
На том же Three это выглядит просто, так как не приходится ждать компиляции при изменении пары символов кода.
для таких экспериментов есть среды-песочницы типа processing и p5.js
>при пустом проекте даёт defold - у меня 3 с чем-то МБ
конструхт2 - 0.7 мб
ну так там чистый джаваскрипт. по сути текстовый файл. что-то даже много получается
я же говорю о не-джаваскрипте, тут дефолд выигрывает из всех движков
Что есть в Юнити, чего нет в Три (кроме редактора, конечно)? С точки зрения архитектуры приложения.
Смотрю в апиху - math, рейкастер, лоадеры моделей, камера, свет - есть. Шейдеры - на GLSL. Физические библиотеки можно прикрутить.
Для прототипирования как раз?
Из минусов только вопрос производительности, да открытость кода.
А как редактор поможет отладить алгоритм той же процедурной генерации ландшафта, если в том же Юнити это, по сути, компонент с мешем?
Ну лично для меня это не проблема, но зачем-то энтерпрайз иногда хочет код обфусцировать.
Современный JS используют через бандлер какой-нибудь типа Vite, который насколько я знаю из коробки обфусцирует и минимизирует код. На выходе получается один JS файл. К тому же идут всякие плюшки в виде tree-shaking, когда неиспользуемый и недосогяемый код убирается с билда. Оч полезно автоматически убирать дебаг код, к примеру.
Для протитипирование удобнее годот. НО я не знаю как у него дела с вебом и вебгпу (которое буквально только появляется в браузерах).
Всегда есть большая вероятность, что когда закончишь проект там все будет, если теха выстрелит. Если нет, то зарелизишься на другое.
Ты, вероятно, делаешь стратегию, если ньюфаг - то вообще забей, ты настолько долго погрязнешь в механиках, что лучше для начала просто что-то сделать на популярных движках. Ты же не захочешь погружаться в математику, а скорее всего захочешь готовые решения или примеры.
Процедурный генератор пишется за 10 минут (если не собрался свой noise писать). Тут сразу же появиться потребность - теперь хочу разместить объекты. Особенно с гуи, когда буквально хочется подвигать кнопки.
>НО я не знаю как у него дела с вебом и вебгпу
С вебом - средне, вебгпу щас только в юнити есть, ну может еще в парочке js либ.
Ты процедурную генерацйию прототипировать соьрался? Обычно механики прототипируют
Процедурная генерация это уже точно не прототипирование.
>Процедурная генерация это уже точно не прототипирование.
Все что буквально "потыкать" есть прототипирование.
Есть предел человеческой фантазии, когда мозги сильно сглаживают мысль и нужно реально сесть что-то набросать, а потом от этого уже отталкиваться (потому что мозги не удерживают детали, мозги их обобщают).
Да, почему нет? Если простые алгоритмы можно расписать на бумажке в виде блок-схем, то с процедурной генерацией едва ли получится.
>>1064803
Обычно под прототипированием понимают деятельность, в результате которой получится какой то прототип, который надо максимально быстро накидать чтобы посмотреть потенциал механик.
Процедурная генерация это уже совсем не то, что понимают под прототипированием обычно - ведь для прототипа в 99% случаев быстрее самому накидать сцену вручную, даже если игра про процеудрную генерацию - прототипирование все равно будет предполагать вручную накиданные сцены, которые уже потом надо будет воссоздавать алгоритмом, если прототип перспективен окажется. Просто так быстрее намного.
Поэтому если вы с кем-то будете обсуждать прототипирование, какие инструменты хороши для прототипирования, то скорее всего понимать это будут именно так как я описал и поэтому будет недопонимание. Не то чтобы есть зафиксированное определение, просто такие реалии.
Имею в виду прототипирование/разработка/понимание работы алгоритма, изыскания в пределах интеллектуального юнита.
>>1064816
>Процедурная генерация это уже совсем не то,
Она у тебя сразу готовая что ли получается? Прототипирование это сленговый термин означающий "сделать быстро на коленки" - все, больше никакого там замысла нет. Даже с Noise надо потрахаться чтобы получить вменяемый ландшафт.
У меня не особо прям много опыта. На пике дефолтный FastNoiseLite годота.
Вдохновился отсюда
https://youtu.be/7CuoC_pB9-k?list=PLOb5IPYDOceDIeNvojEYIUeHbHTZShtc-
>>1064973
Просто как совет не начинай разработку с процедурной генерации. Она в начале нафиг не упала, лучше небольшие тестовые сцены делай.
На старой пикче все настройки
https://docs.godotengine.org/ru/4.x/classes/class_fastnoiselite.html#enum-fastnoiselite-noisetype
По дефолту на пикче.
Дальше просто сравнивать значения и задавать местность. Сразу скажу диапазон не равномерный, если переводить в проценты разброс примерно между 6-40%
И патерн получается типа такого
if n < 10 ...тайл воды,
if n < 12 ...тайл болото/побережье
итд.
Хочешь больше воды ставишь if n < 15. Там поймешь, он очень плавный.
Я подбирал под римворлд (вода, болото, плодородная, обычная, итд...).
Более умнее я не придумал.
Мне это нужно было чтобы потестить поиск (AStar) пути 250х250 (спойлер: он не хило так жрет при таких размерах, если задавать вес тайлов).
Наврал, это
NoiseType TYPE_CELLULAR = 2
Сотовая связь включает в себя как шум Worley, так и диаграммы Voronoi, которые создают различные области с одинаковым значением.
На что найдешь более интересное руководство.
На годоте видел туториал, где чел реализовывал всякие мелочи (покачивание, оружие у стены итд). Но возможно у других тоже норм есть.
В 99,99998% ты дропнешь проект, поэтому лучше выбрать комфортный старт, потому что до финиша далеко очень (там сам решишь для себя без анонов двача).
Если у тебя такие вопросы, то конечно анрил. Берешь шаблон и работаешь с ним. Там уже все есть.
Юнити или анрил. Годоть не слушай, автор видоса попытался реализовать это на годоти и получил кучу пропуков даже с хваленной физикой jolt.
В анриле тоже нельзя зайти в свой проект если нет инета?
Так в интернетах полно руководств на оба. На юнити, как традиционно считается, их больше.
Да не, это не то что бы супер полноценный проект, а проба пера, просто надо уже определиться, ведь с анриала вроде как не пересядешь на юнити без обучения с 0, и наоборот.
>>1065029
Если что ассеты, модели и всё подобное я буду сам рисовать. Но я слабо понимаю какая разница между движками.
>Так в интернетах полно руководств на оба. На юнити, как традиционно считается, их больше.
Мне интересно, смогу ли я открыть свой проект без интернета? Что используют в Китае ввиду ограниченного инета?
Хуже тот движок, где игры хуже (движки без игр худшие из худших)
Если шапку мономаха не носят, это не означает что она хуже китайской шапки.
https://github.com/MattParkerDev/SharpIDE
https://www.youtube.com/watch?v=h5C7zB2nbrc
Полагаю - нигде. На видосе юнити скорее всего.
>>1065039
Анрил можно билдить с гитхаба у себя на компе, так там такой хуйни нету.
фокус он симплисити-то есть?
а то я люблю когда всё симплично, лайтвейно и модулярно
Да, тоже кринжанул с этой "IDE". Инфлюенсеры по помойкам собирают контент, видимо совсем рассказывать нечего.
>>1064224
>Если бы wicked-шизик потратил больше одной на создание интерфейса, или просто скопировал бы unity, то сейчас бы w4 games возглавлял он, а не аргентинский самозванец.
>Вот как пренебрежение базовыми UX принципами приводит к катастрофическим последствиям.
Двачую. Какой же Януш шизоид всё-таки
Он сделал охуенный движок, но вместо редактора какую-то залупу. Я сам много раз щупал wicked, но спотыкаюсь на том, что НИХУЯ НЕ ПОНЯТНО КАК ОНО РАБОТАЕТ. Он там даже что-то менял в редакторе, запускаешь обнову, а там снова ШИЗОФРЕНИЯ
>>1064225
>Без мультиплатформы
Мне хватило бы одного стима. Не знаю нахуя тебе другие платформы для игры с графонием. RTX-ы на телефоне запускал?
>Мне хватило бы одного стима
Я рад что тебе хватило бы, мне не хватает
>Не знаю нахуя тебе другие платформы для игры с графонием.
Не делаю игры с графонием потому что денег, ресурсов и квалификации на графоний нету, зато есть обширная квалификация по программированию, которую тоже можно успешно применить, при этом не имея топовой графики.
>RTX-ы на телефоне запускал
Не, онлайн веб игрульку
>>1064224
бред на интерфейс обращают внимание только утки. как с любым опенсорцом, на тырфейс жалуются только утки
>скопировал бы unity
юх это вообще мем почему-то всё с САМЫМ ПИЗДАТЫМ ЮХ наоборот неюзабельное вечно тормозящее говно с ебанутыми настройками ЗАТО НЕ КОНФИГ ФАЙЛ
ЮХ это скам уровня медицины и пищевой индустрии
>Windows: Added DirectStorage support for asset loading in Windows Standalone builds. You can use this feature by using Enable Direct Storage in Player Settings.
Интересно а когда в bzdot или в godot появится тоже самое?
Когда ты сделаешь pr с реализацией. Или не ты, а кто-то другой.
>лицо куколда, пишущего бесплатно код для корпорации w4
Идейных мало, большинство людей участвует в разработке опенсурс продуктов для своего портфолио.
И получай инфаркты от того как годототеде обсуждают кряки на твой плугин..
Я это к тому что если для юнити и урино бояр имеет смысл делать плагины, а для нищих годотодетей смысла никакого нет.
https://www.reddit.com/r/Unity3D/s/WdNGEagIGr
Мерять производительность движков компами это все равно что длину в попугаях измерять. Слишком от конфигурации зависит. Показывай производительность на каком-нибудь древнем сосунг галакси а10
я скачал unity, где мне нажать чтобы были воксельный мир и рейтресинг освещение? а, нигде? это кто-то сделал с нуля использую низкоуровневную обертку unity над графическими API? ясно.
Что, теперь-то понял зачем движок нужен? Куда подевались твои аргументв про сборку ассетов из готовых компонентов?
На Unity ты не пишешь инициализацию окна, вывод треугольника, UI, систему частиц, звуки, аниматор и другие вещи которые сделать не сложно, просто очень долго.
На Unity ты сразу берешь сложную задачу и её решаешь - и Unity предоставляет самые совершенные инструменты для этого.
Нужна производительность - Burst и Job System к твои услугам, самостоятельно тв бв сзожую систему писал лет 5.
Любишь ECS - пожалуйста, самый совершенный ECS на рынке.
Нужно просто по быстрому накидать игру и сделать, например, высокопроизводительную генерацию уровней - пожалуйста, делай игрока и мобов геймобжектами и делай генерацию с Job System.
Unity - это не ограничение и это не конструктор, это набор инструментов, с которыми ты сразу можешь заняться сложными и полезными задачами которые стоят перед тобой, а не делать по гайдам то, что до тебя уже сделано сотни и тысячи раз.
>рейтресинг освещение
на шлюха, соси
https://github.com/keijiro/UnityDxrTest
>теперь-то понял зачем движок нужен?
нет
>На Unity ты сразу берешь сложную задачу и её решаешь
я скачал unity, как решить задачу воксельного мира на unity? как мне в этом поможет unity?
>это набор инструментов, с которыми ты сразу можешь заняться сложными и полезными задачами которые стоят перед тобой
а знания как это делать у тебя откуда возьмуться?
> я скачал unity, как решить задачу воксельного мира на unity? как мне в этом поможет unity?
Он позволит тебе не заниматься инициализацией окна, не заниматься программированием базовых UI элементов, не заниматься работой со звуковым API, а сразу перейти к решению этой задачи.
Для помощи с ней он предоставляет Burst, Job System и многопоточную библиотеку с крллекциями.
> а знания как это делать у тебя откуда возьмуться?
Глупый вопрос. Есть только один способ получить знания как что-то делать:
1.Определяешь что хочешь сделать (воксельный мир по которому можно бегать игроком)
2. Разбираешь это на составляющие (нам нужно хранить данные где какой воксель, нужно иметь возможность их отрисовать, нужно иметь возможность задать текстуру/цвет каждому типу вокселя, сделать так чтобы игрок коллайдился с ними)
3. Ищешь информацию по каждой из них - где угодно, можно просто в гугле и постепенно откапываешь что тебе нужно(как проверить пересечения игрока с миром -> как проверить пересечение сферы с кубом, как отрисовать воксели и хранить их в памяти -> что такое спарс три, как рисовать треугольники, что такое атлас текстур)
4. Если составляющая слишком объёмная - пытаешься разбить её ещё дальше на части. Если видишь что-то слишком не понятное(например ты никогда не занимался компьютерной графикой - тогда надо, или ты очень плох в математике - тогда гуглишь математические понятие нужные и так рекурсивно вниз пока не дойдешь до того, что понимаешь)
Вниз нужно идти до того момента, пока тебе не придёт концептуальное понимание идеи - например, тебе н4 обязательно знать низкоуровневое граыическое апи наизусть, но тебе будет полезно иметь представление о том, как работает графический конвеер и что происходит когда ты используешь более высокоуровневую оболочку
Только первый месяц(31 день)*
Дальше отсыревает юнитихаб и требует подключаться по новой
Не понял. Типа хочешь на работе сидеть и делать свою игру пока кабан не видит?
Таким впринципе юпити противопоказан, ибо требует админа и 16 рамы минимум с норм процом. Не, я вообще говорю, если в организации досту в интернет через проксю - это будет проблема.
Каким образом это будет проблемой?
Пусть для юнити нужен доступ в интернет. Доступ в интернет через прокси жто доступ в интернет. Чем "через прокси" мешает?
>>1065304
>>1065301
В чем проблема использовать что-то типа Ogre3D? Там в целом редактора карт нет. Сиди и компилируй себе на здоровье до посинения.
>не заниматься инициализацией окна, не заниматься программированием базовых UI элементов, не заниматься работой со звуковым API
это делается за 2 недели
>Вниз нужно идти
это абсолютно неправильный подход к обчуению. нужно идти не вниз, а подниматься с низу. ты не прочитаешь большую книгу, не прочитав сперва букварь. ты не сможешь сделать воксельный мир, не сделав сперва свой движок. движок создает контроллируемую среду обучения, где ты сам переходишь от легкого к сложному. в unity тебя сразу вышвыривают в океан супа из графических API, программирования плюс особенностей unity, без спасательного жилета.
> это делается за 2 недели
Покажи как ты это сделал за 2 недели)))
> >Вниз нужно идти
> это абсолютно неправильный подход к обчуению. нужно идти не вниз, а подниматься с низу.
Ты дурачок что ли? Я буквально именно это и сказал. Зачем ты вырвал фразу из контекста, переаернул её смысл на противополодный и сказал что это неправильно?
> ты не прочитаешь большую книгу, не прочитав сперва букварь. ты не сможешь сделать воксельный мир, не сделав сперва свой движок.
Вот, именно про это я и писал. Хочешь сделать что-то сложное - изучаешь базу которая нужна для этого.
> движок создает контроллируемую среду обучения, где ты сам переходишь от легкого к сложному. в unity тебя сразу вышвыривают в океан супа из графических API, программирования плюс особенностей unity, без спасательного жилета.
У тебя в любом движке доступен язык программирования на которым ты что угодно можешь делать.
Движок заставляет тебя не понимать какие-то концепции, а работать с сугубо пркладным низкоуровневым апи или библиотеками, или заниматься разработкой какого-то унылого говна, которое и так понятно как работает, просто его долго и уныло делать.
Делать движок - это примерно тоже самое, что построить 10000 песочных замков чтобы когда то научиться строить реальные замки.
Да 10000 нахуй не надо, это в бесполезный дроч, штук 5 уже с головой хватит.
>>1065347
Кто как хочет, так и дрочит. Хули вы лезете к нубам? У каждого свой путь, кто-то начинает так, а кто-то иначе, нет универсального пути к обучению и постижению гд
уже показывал много раз
создавая движок, ты создаешь механизм с нуля и понимаешь зачем нужна каждая шестеренка и как она работает. скачивая движок, ты получаешь черный ящик, и по сути для обучения тебе надо самому "декомпилировать" механизм движка и его особенности, часто нигде не документированные, а это намного сложнее.
>>1065353
любой, кто относится к разработке серьезно, всегда рано или поздно придет к своему движку. вопрос только в том, сколько времени он потратит зря перед этим.
>уже показывал много раз
Ты показывал как ты за полгода собрал редакторо-содержащий продукт, где у тебя рисуется 3 уточки и сцену с кубами, не уступающую 3д сценам дефолда
>создавая движок, ты создаешь механизм с нуля и понимаешь зачем нужна каждая шестеренка и как она работает. скачивая движок, ты получаешь черный ящик, и по сути для обучения тебе надо самому "декомпилировать" механизм движка и его особенности, часто нигде не документированные, а это намного сложнее.
Ну этот тейк вообще критики не выдерживает, если ты знаком с линейной алгеброй, матрицами и векторами - понять суть работы годота не сильно сложнее, чем понять суть работы любого другого движка, просто при этом ты еще и тонну времени вьебешь на то, чтобы закодить всё это. А если не знаком - возможно ну его, пусть так и остается черным ящиком.
>любой, кто относится к разработке серьезно, всегда рано или поздно придет к своему движку.
Понял тебя, тим черри, дэниел вавра, cdpr и прочие относятся к разработке несерьёзно
>любой, кто относится к разработке серьезно, всегда рано или поздно придет к своему движку
Пиздабол, пиздаболина
Даже крупные компании начинают отказываться от своих движков
ты общаешься с сумасшедшим шизом которому нравится делать что угодно но не игры
>понять суть работы годота не сильно сложнее, чем понять суть работы любого другого движка
пойми это https://github.com/godotengine/godot/blob/master/scene/resources/material.cpp
давай, понимай. чтобы все понял.
твое "понимание" движка ограничивается понимаем на какую кнопку нажать в инспекторе.
>тим черри, дэниел вавра, cdpr
твои протыки? опять же, путаешь популярное с хорошим. понимаешь, есть люди, которые всю жизнь учаться чему-то, рисовать, или шахматам, например. это по моему "серьезно относятся" к ремеслу, как к искусству. а ты относишься к ремеслу только как теоретическому способу заработка.
>пойми это https://github.com/godotengine/godot/blob/master/scene/resources/material.cpp
>давай, понимай. чтобы все понял.
Там нехуй понимать, лул. 10% класса это ебучие биндинги (привет плюсам без рефлексии и атрибутов), 20% реализация того что биндится, остаток это собственно код генерации базового шейдера согласно параметрам материала и согласно его типу. Это типичнейший бойлерплейт сборки базового шейдера, в нем 0 чего-либо сложного, плюс еще и биндинги чтобы можно было через апи вызывать установки параметров шейдера.
>твое "понимание" движка ограничивается понимаем на какую кнопку нажать в инспекторе.
Минусы будут?
>твои протыки?
Ориентируюсь на лучших и успешных.
>опять же, путаешь популярное с хорошим.
Опять игры не игры? Да ебанаврот.
>а ты относишься к ремеслу только как теоретическому способу заработка.
Ну есть у меня такая мулька, сделать прикольную игруху и хотябы на пару бургеров поднять с этой темы, но если бы я неиронично преследовал цель исключительно заработка - я бы делал игры на ебаном роблоксе или на крайняк в юнити, а не пердолился с годотом.
Хоть на bevy с хрустом переходи если хочешь код писать а не мышкой возить.
>блоатваре для нубасов типа годота с кастрированым С++ апи
По меркам любого из аналогов годот это ебаное перышко в своих размерах. Степень блоатварности того же юнити можно оценить в слитых сурсах четверки.
>Степень блоатварности того же юнити можно оценить в слитых сурсах четверки.
что там было?
Такие же горы биндингов и редактор на c# в связке с плюсовым ядром. Это как если бы редактор годота был на гдс, а производительность гдс уже и так всем известна. А лучше сам посмотри, в сети есть.
пока CDPR относитились серьезно, они делали игры на своем движке. теперь единственное к чему относятся серьезно, это к зарабатыванию денег.
>Минусы будут?
это доска называется gd, а не biz. как бы подразумевается что тут идейные, или просто обсуждение разработки игр как искусства.
>это доска называется gd, а не biz. как бы подразумевается что тут идейные
А это подразумевание в одной комнате с правилами доски? Я вот такого не подразумеваю. И с каких пор идейность враг желания поднять денег на продукте, созданном идейностью?
Чем плох редактор на шарпах? Что за бред.
Понятно что числодробилки надо на плюсах надо, но зачем на крестах редактор писать?
Тем что оно пропердывает маршалингом и требует гору биндингов на каждый пук, если брать случай юнити. У них редактор(и не только) имеет слишком много плюсового апи.
> пойми это https://github.com/godotengine/godot/blob/master/scene/resources/material.cpp
А что тут блять сложного? Полтора байндинга и код смены пасса, пробрасывания пропертей?
Или тебя в ужас приводит генерация шейдера по шаблону? if (emission) code+= кусок шейдера - это правда очень сложный код?
Почитай как графический пайплайн работает чтобы понять, что такое сетпасс, дроу колл, как работает шейдер, как в шецдер параметры прокидывать, можешь даже почитать как это делается конкретно в разных графических апи. Всё это ты мог проработать просто гугля непонятное в том, что есть в этом файле, и гугля не понятное уже в том, что найдешь, и так выйдешь на нужную базу и с неё все проработаешь.
Если шейдерный код пугает - почитает как писать шейдеры и про конкретные фичи реализуемые тут в базовом шейдере, по коду рх сразу видно.
Мимо юнитидаун-компонентоперетаскиватель
> Тем что оно пропердывает маршалингом и требует гору биндингов на каждый пук
Нет, нихуя. Чтобы меню накидать ничего маршаллить в с++ не надо.
Это все копейки. Да, не правильно, но копейки. Пропуки надо профайлером искать, а не интуицией.
>Нет, нихуя. Чтобы меню накидать ничего маршаллить в с++ не надо.
Какое меню, куда накидать?
>>1065390
>Это все копейки. Да, не правильно, но копейки. Пропуки надо профайлером искать, а не интуицией.
Ну вопрос в первую очередь про блоатваре.
> Какое меню, куда накидать?
Редактор - это набор разнвх окошек и меню
Ну конкретно реализацию гуя я не изучал, но там очень много всего запаковано в internal, так что если бы их редактор был просто игрой на юнити - возможно количество таких не слишком позитивных для перфоманса связей было бы меньше.
я под искусством имею ввиду то, когда люди что-то делают ради цели искусства. например, даже когда игроки проходят dark souls на банане, они это делают ради цели искусства. так и разработка игр может быть сама по себе искусством.
потратил игрок в dark souls время, пройдя игру на банане? для кого-то да. для него - нет, потому что достиг чего-то в искусстве.
понимаешь, это как придти на форум игроков dark souls и говорить, "зачем вы проходите dark souls на банане, вы же просто занимаетесь чем угодно, но только не прохождением. а лучше вообще сделайте бексонечные жизни с cheat engine, или посмотрите прохождение на youtube!"
>internal
Что это? О чем ты? Как модификаторы доступа у тебя влияют на производительность? Это вообще компайлтайм. Ты иди еще замерь разницу вызова метода и функции и приди к выводу что редактор надо было делать на winapi.
>>1065394
>было делать на winapi.
Сэконом 10 наносекунд пацан, че ты как овощ все на тормозном С++ пишешь
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
MessageBox(NULL, L"Привет, WinAPI!", L"Окно", MB_OK);
return 0;
}
займись уже делом
Темнота. Ты кажись ни разу в csreference не заглядывал. https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/2D/Common/ScriptBindings/Clipper2D.bindings.cs
Юнити все с++ методы помечают префиксом Internal
Не INTERNAL, а EXTERN
В данном случае интернал просто нейминг такой
Здесь пишут, что юнити отваливается на 100 анимациях. Это правда?
Лол, чел перепутал модификатор extern с неймингом методов. Все что нужно знать о местном разработчике движка.
Маршалинг между шарпом и плюсами может быть копеечным, да и как еще подружить шарпы с плюсами?
>модификатор
Это вы с какого то хуя решили что речь про модификатор, хотя я не уточнил что такое internal ни одной фразой, перечитай мои посты. Я просто чет решил что разговариваю с тем кто имеет хоть минимальное представление о юнити и решил не вдаваться в подробности, my bad.
>Маршалинг между шарпом и плюсами может быть копеечным
Может быть, а может и не быть
>да и как еще подружить шарпы с плюсами
Обьемы маршалинга в юнити могли бы быть значительно сокращены, если бы им не срали на каждый пук редактора
А ты хочешь чтобы у тебя редактор сжигал видюху для не урезанного sdfgi?
>... решили что речь про модификатор, хотя я не уточнил что такое internal ни одной фразой
То что ты жаловался на название функции выглядит еще тупее, я чуток повысил тебе скилла в своих глазах, решив что ты перепутал с модификатором. Или ты считаешь, что название функции как-то отражает его работу и влияет на производительность? Если так то это даже интереснее.
>>1065488
>Может быть, а может и не быть
Судя по модификатору unsafe, так и есть. Мне просто лень ради квази разработчика лезть и разбираться.
>>1065488
>Обьемы маршалинга в юнити могли бы быть значительно сокращены, если бы им не срали на каждый пук редактора
Зачем? Если это нанокопейки? Да и кому не пофиг на чем там редактор, хоть на электроне, у тебя там что инспектор тормозит или что? Главное чтобы билд не тормозил.
Я думаю редактор какого-нибудь популярного IDE будет тяжелее чем редактор юнити (но даже такое тебе ни написать).
>То что ты жаловался на название функции выглядит еще тупее, я чуток повысил тебе скилла в своих глазах, решив что ты перепутал с модификатором. Или ты считаешь, что название функции как-то отражает его работу и влияет на производительность? Если так то это даже интереснее.
Ты пытаешься что-то там угадать, выгадать, я только не пойму что. Префикс интернал - это маркер того что функция вызывает ядро юнити, ну это так сделано в коде юнити. Я просто этого не уточнил, потому что это ясно любому, кто ковырялся в референсе рантайма юнити (любой профессиональный юнити разработчик там ковырялся), и когда я говорю про internal-вызовы - это тоже ему понятно.
>Судя по модификатору unsafe, так и есть. Мне просто лень ради квази разработчика лезть и разбираться.
Модификатор не решает проблему маршалинга типов, только говорит компилятору что мы здесь играемся с сырыми указателями.
>Зачем? Если это нанокопейки?
Аллокация нанокопейки? Понял тебя.
>любой профессиональный юнити разработчик там ковырялся
Почти десять лет работаю на юнити, ни разу не возникло необходимости или желания там ковыряться
Мимокрокодил
этот ассет https://kaylousberg.itch.io/kaykit-skeletons
у него зачем-то объект поделен на 9 отдельных mesh-ей, это как 9 отдельных skinned mesh renderer компонентов по сути. получается неэффективно.
>Вы что начали делать движки игры?
Судя по тому что на гитхабе тысячи ничено не умеющих движков - да.
Потому что не постят дрова для срача. ну и подготовка к твг
>Потому что не постят дрова для срача
У годот хейтера, который таскал ишью должны начаться зимние каникулы.
Или наоборот напряг под конец года.
https://www.reddit.com/r/learnprogramming/comments/1n3zqts/entt_is_10x_slower_than_oop_need_helpminimal/?tl=ru
Да нигде вроде. registry.group обещает хай перфоманс для его случая, так как оба компонента всегда представлены вместе в рамках сущностей. Неужто entt такой кал?
Ну в принципе мантра про кеш мис образовалась в эпоху пентиумов. Насколько она верна сейчас на современных ЦПУ? Плюс на самом деле в игре не так уж много классов. Различия между сущностями (например мобами) в основном в данных, а не в виртуальных таблицах.
Даже если делать дерево сцены, оно будет в основном состоять из одинаковых нод с разными данными. Ну максимум десяток разных типов нод на инди игру. Насколько реально это может задрочить кеш проца?
B как оно работает? Чтобы точно не было ECS. А то вот дебс с реддита написал типа ООП пример, а прошелся по сущностям в цикле вызывая один метод. Естественно в ECS была бы фильтрация по компонентам, но для его простого случая все объекты имеею те же компоненты velocity position
Если ты сделаешь делегаты для эффектов, а потом будешь проходить по ним в цикле, то это будет почти ECS
Это тоже что и дамаг твой, только растянутый по времени (по тикам, секундам, шагам).
Дамаг ивентами можно реализовать - тут ООП-ешник выкрутится. А вот как длительные эффекты чисто по оопешному сделать?
>B как оно работает? Чтобы точно не было ECS. А то вот дебс с реддита написал типа ООП пример, а прошелся по сущностям в цикле вызывая один метод. Естественно в ECS была бы фильтрация по компонентам, но для его простого случая все объекты имеею те же компоненты velocity position
У делегатов не настолько страшный оверхед. Тем более никто не мешает вместо делегата вызывать указатель функции с передачей ей аргументов, или набить ими словарь и вызывать эффекты. Тут как раз налицо ecs говнецо.
Я хз что там за игра. У тебя есть статусы на юнитах. Статус яда, статус хила, статус кровотичения, статус ускоренного бега, статус стана...
Реализуешь систему статусов на юните и потом где-то в коде это чекаешь
for status in statusDic:
status.doEffect(self)
if status.expired():
currentStatus.erase(status)
> B как оно работает? Чтобы точно не было ECS.
Что как работает?
Update()
{
if poisonTimeRemainint > 0
then health -= poisonDamage
poisonTimeRemaining -= deltaTime
}
Причем тут ооп или ецс, куда хочешь туда и пиши этот код
Ладно, наговнокодил.
Почему не State - чтобы не путаться со стейт машиной
перед удалением у статуса должен быть выход (и вход при добавление).
if status.expired():
status.ending(self)
statusDic.erase(status)
>перед удалением у статуса должен быть выход (и вход при добавление).
А может не быть и вообще.
Это даже лучше, иначе получается полу стейт машина (что немного другое).
Внутри статуса уже на время смотришь (время со старта игры или юникс тайм или по дельте).
>>1065801
Что и требовалось доказать. У тебя получилась доморощенная полу ecs. По сути ecs добавляет только универсальный способ доступа к компонентам-эффектам
Я не сильно знаком с этой шляпой, но если ecs допускает циклические ссылки, то можно сделать еще проще.
Если для всех состояний использовать словари (иерархию ассоциативныйх массивов), а классы будут иметь только функции (методы без состояний), это и будет Data-Oriented Design.
Но я что-то очень сомневаюсь что возвращение к процедурному программированию имеет такие прям колоссальные плюсы (неудобство, да, а вот прирост производительности, хз).
Типа дата ориентированная херня выглядит как бы так (пик, конечно условно)?
Но тут нужен сахар "?."
Почти так. ТОлько в ecs есть оптимизации. Например flecs хратит компоненты в таблицах архитипов. Таждая таблица это набор типов компонентов. Разные наборы - разные таблицы. Итерация в системах по записям в таблицах. Запросы к таблицам кешируются.
То есть в твоем глобальном словаре итерироваться придется по сущностям (чтобы получить 41), а в flecs по наборам компонентов в таблице
>Запросы к таблицам кешируются.
Но в тоже время сама хеш-таблица это уже верх оптимизации и кэш (вопрос только в упаковке данных).
Ебнутый даун, как тебе вообще в голову пришло противопоставить архитектурный паттерн и парадигму программирования? Это же такой уровень непонимания базовых вещей, что я в ахуе, как ты ушел дальше хеллоу ворлда. Причем судя по всему ты не понимаешь не только, что такое ООП, против которого шизоидно копртивляешься, но еще и не понимаешь, что такое ECS, если для тебя очевиднейшее ноубрейнер решение "добавить контейнер со статус эффектами и апдейтить их в цикле" это "полу-ecs". А когда я жопу вытираю после сранья, это может тоже на треть ECS или на четверть?
>То есть в твоем глобальном словаре итерироваться придется по сущностям (чтобы получить 41), а в flecs по наборам компонентов в таблице
В чем разница и там и там хэш таблица же (в первом случае может быть даже массив)
Ебанутый даун аутист, не понимающий контекста, тут только ты. Это "противопоставление" обсуждалось здесь и ссылка н реддит тоже содержит противопоставление.
>я не один такой даун, вокруг много таких же даунов
Это реально твой ответ?
Разница в количестве операций. У тебя 10_000 из них только 300 мобов и неписей, которых можно отравить
Ты реально не способен понять что никакого противопоставления я не делаю?
Более наглядный вариант, без проверок. Понятно что изменение хп мы бы делегировали отдельной функции, но тут для наглядности
>Разница в количестве операций. У тебя 10_000 из них только 300 мобов и неписей, которых можно отравить
Просто еще один флаг при проверке.
if state['can_be_poisoned'] and state['flag']:
У тебя if будет проверятся 10_000 раз а не 300. Для горячего кода который каждый кадр выполяется это может быть много если учесть что у тебя еще 100500 эффектов.
>У тебя if будет проверятся 10_000 раз а не 300.
Это копейки, но я кинул тебе закэшированных
>>1065825
Это да. Но мы же не привязываемся к особенностям питона, а обсуждаем общий код.
Это gdscript.
На js можно было вообще так
unit['state']['poisoning']
unit.state.poisoning
unit?.state?.poisoning
В какой-то степени сам язык дата-ореинтированный. Но что-то хайпа я вокруг этого не слышу. Плюс еще прототипное наследование, язык вообще мега заточен под все это.
Насколько ECS не обманка? Где-то может есть овер показатели, но дата-ориентированное программирование старо как мир (мы так в 2004 на процедурном пхп писали, еще до меня на перле, а си вообще эталон этого)
В некотором смысле обманка. Так же как у фронтендеров был хайп на Реакт. Были ооп компоненты в реакте, потом все сделали функциями. Сейчас во фонтенде морду лица поломают, если класс напишешь без веской причины.
Единственная причина, по которой в реакте пользовались классами - это потому что не было другого встроенного способа менеджить стейт, если тебе нужен каунтер и ты не хочешь его совать в какой-то глобальный стор, то пишешь класс, а во всех остальных случаях пишешь обычные data-driven функции, как и сейчас. Потом ввели хуки, которые позволяют добавлять локальный стейт в любой функциональный компонент, поэтому все перестали пользоваться классами, хуки тупо удобнее и проще.
>хуки тупо удобнее и проще.
>километровые портянки
let [a, setA] = useState(0)
let [b, setB] = useState(0)
useEffect(() => {
setB(b, a )
return () = b = 0
}, [a])
Ехал useState через useEffect через useState через useEffect...
Зы За точность не ручаюсь. 100 лет не трогал реакт...
Еще до классов в жс были объекты/хеш-таблицы { "key": "val"}
Классы это обертка над этим, о чем ты?
Я что-то против прототипного ооп написал? Классы просто убрали громоздкий синтаксис под ковер.
>Я что-то против прототипного ооп написал? Классы просто убрали громоздкий синтаксис под ковер.
Что они там убрали? Будто бы struct не существовало
Ты в три строчки по сути захуярил два разных модифицируемых стейта и колбэк на изменение одного из них, а теперь напиши то же самое через классовый компонент и охуей с реальной портянки.
>>1065849
Классы это имплементация динамического полиморфизма, а хеш-таблицы это обычная структура данных, которая есть в любом языке, включая языки где ООП и в помине нет. Но это видимо уровень понимания базовых концепций программирования у здешних шизов, которые противопоставляют ECS и ООП.
Шизло, ты написал
> это потому что не было другого встроенного способа менеджить стейт
Я тебе говорю что все было. Были и классы, было и наследование. Там ничего не завезли нового с того момента (кроме сахара).
>Это gdscript.
Кстати, можно через точечную нотацию.
Не хватает оператора "?."
Например, в unity есть универсальный MeshRender, которому назначаются разные материалы. С ECS-материалами будут, например, PbrMeshRenderer, ToonMeshRenderer, UnlitMeshRenderer.
Просто единственный элегантный способ как назначать per instance свойства для объекта, какой я придумал, это добавлять их на компонент, как это реализовано для SpriteRenderer в unity например (цвет, текстуру можно изменять для каждого объекта отдельно). Проблема в том, чтобы эффективно скопировать эти per instance свойства в буфер, нужно знать тип компонента, единственный вариант это собирать все компоненты одного типа в каком-то отдельном массиве и перебирать их. Поэтому ECS-материалы.
>ECS
Осторожнее с этим, ты можешь так быстро разогнать игру, что в один прекрасный день она зарелизится сама без твоего участия.
Зачем интегрировать рендер с ECS? У меня для рендеринга независимая система которая отдаёт наружу хендлы по которым объектами можно манипулировать, только они живут в ECS. Наружу торчит только сцена и функции типа render_scene, load_mesh, create_mesh, create_mesh_instance, update_instance_transform и подобное.
Так что ты можешь переделывать кишочки рендера как хочешь не тревожа то что его использует.
>Насколько она верна сейчас на современных ЦПУ?
Стало только хуже. Но это имеет значение только на большом количестве объектов, типа в рендере.
>>1065782
Ноды вполне можно держать в линейном списке и адресовать по индексам. Как результат ты можешь спокойно получить тупой линейный массив который можно куллить обычным циклом.
Так нам нужен рецепт как сделать хорошо, а не обяснение почему мы все умрем.
В целом не бегать по памяти и держать нужные в один момент данные рядом, линейно. Этого плюс-минус достаточно.
Если вкратце - никак. У тебя две системы, которые должны работать вместе, но фундаментально не способны этого делать. Так что любая дополнительная нагрузка на память это пиздец. Кешмисс это просто усугубление проблемы, как если бы человек сломал ногу, а ты его пиздил битой по поломанной ноге. Быстрее он от такого идти не станет. Проблему понимает, например, Валв. Потому у Аликс прямой рендеринг, а не отложенный. Из-за чего она работает плавно даже на виар оборудовании. Так что проблемы с памятью на кешмиссах не заканчиваются, а скорее только начинаются.
Не ну у тебя кэш есть. Ты просто загружаешь порцию данных и делаешь много всего с ней. Я в своём двигле десятки тысяч дроуколлов делаю, причём без всяких новомодных bindless или куллинга на ГПУ, чисто по старинке всё. Чисто потому что я о структуре данных подумал.
Кулинг на гпу дешёвый пиздец. Как раз потому что данных мало. Да и работы тоже. Сложность шейдеров в разы хуже большого количества ДК, а наличие G-буфера хуже десятка тяжёлых шейдеров. Ещё хуже RT, потому что там кешировать ничего вообще не получится, всегда рандомный доступ к BVH структуре. И ещё RT подсасывает текстуры и становится совсем грустно, потому что доступ к ним такой же рандомный. А L2 всего пара десятков мегабайт. Тут уточню, что сложность шейдеров не в том смысле, что там много вычислений или ещё какой-то ебатории, а в том, что современный PBR пайплайн требует множества текстур, плюс сверху этого будет добавлено чтение десятка текстур с данными об освещении, плюс SSS и получается, что для рендеринга одного пикселя тебе нужно получить гигабайт данных. В лучшем случае.
>Кулинг на гпу дешёвый
Да, но копировать потенциальные сотни тысяч матриц, AABB и т. д. каждый кадр - уже будет недешево. Это надо все переносить на GPU, это уже получается не так просто.
Наивный куллинг на GPU не работает.
Если не понимаешь о чем речь, то лучше помалкивай. Тебе напомнить как задаются per instance данные в unity? Через словарь со строковыми ключами https://docs.unity3d.com/6000.0/Documentation/Manual/gpu-instancing-change-data.html
От такого "инстансинга" будет производительность хуже, чем без инстансинга.
Дробишь на два этапа, первый сортировка по дереву на цпу. Быстро, дешево, но грубо. Второй этап на гпу. Быстро, дёшево, точно.
Это не буквально додик ецс. Просто для каждого материала (шейдеров) будет свой вариант mesh renderer. Для рисовки объекта с определенным материалом вместо назнания ассета материала, нужно назначить определенный renderer компонент. Вот про что речь, грубо говоря.
Так сейчас делаю с мешлетами. Это имеет смысл только если очень треугольников в геометрии
Правда в реальных играх ФПСов что-то не прибавляется.
Не обязательно много треугольников, даже на простых сценах это очень разгружает рендеринг и бустит фпс. Если фпс не бустится, проверяй свои шейдеры, скорее всего в шейдерах усиления где-то ошибся. Запускай больше потоков для усиления.
Ты просто слабейший, ты понимаешь это? С профйлером покажи импакт на производительность.
Ну и на добив - там не строковые ключи, там хэши) Ты можешь либо строку закидывать, либо сразу закешировать хэш и его юзать.
Удалил свою игру, когда увидел на каком месте годот. Как с таким позором публиковаться?
>>1066083
Есть ли программы которые конвертируют из годота в pygame? Мне теперь это тоже нужно.
Рэнпай в это число входит, тупо сделали. Откройте ренпай - там те же игры.
https://steamdb.info/tech/
Через год мамка выгонит работать и эволюция закончится..
Ппц это когда пошел попил воды, возвращаешься и пытаешься переключить вкладку в годоте. Но оказывается это вообще открыт Far.
>Что же будет через год?
Могу сказать чего через год не будет - игры.
Ставлю анус что через год не будет игры которая продастся на уровне андертейла, ради меньшего пилить движок не вижу смысла
Тоби делал игру год (всего-навсего). У тебя тоже есть год. При чем ты вроде как программист, значит у тебя это займет еще меньше времени.
Движок нужно делать ради эволюции себя как разработчика. Пока остальные валяли дурака, я эволюционировал.
>>1066317
Я не делаю такие игры как тоби. У меня свой путь.
Покажи свои игры. Я сделал за год 0 игр и пол движка. Большинство здесь (если не все) - 0 игр и 0 движков. Понимаешь что это значит?
Тебе кажется, что я занимаюсь ерундой, но на самом деле все это время ерундой занимался ты.
>Покажи свои игры
А смысл? Ты же только обсирать умеешь, ведь ты игр никогда не делал.
>Большинство здесь (если не все) - 0 игр
Я делаю игру время от времени под настроение, это считается?
мимо
> Движок нужно делать ради эволюции себя как разработчика. Пока остальные валяли дурака, я эволюционировал.
А зачем? На что это влияет и как это проаерить?
Просто, вдруг, ты только говоришь, что эволюционируешь, а на самом деле нет?
> Большинство здесь (если не все) - 0 игр и 0 движков.
Откуда инфа? Был опрос? Я заработал несколько миллионов делая задачи по разработке игр для своего кабана.
> Я заработал несколько миллионов делая задачи по разработке игр для своего кабана.
Сосешь хорошо?
У меня есть для тебя пара задач
Другой кабан
>воображаемых друзей, которые постоянно меня хвалят и соглашаются
>>1063869
>безликий консилиум в голове который предлагает идеи, поддерживает
А моя тульпа меня критикует, советуя взять себя в руки и стать лучше...
Что я делаю не так?
Кто в этом треде самый независимый трудоголик?
>А моя тульпа меня критикует, советуя взять себя в руки и стать лучше...
А не надо было делать тульпу, надо было делать тульпана, тогда бы все было заебись
Эти треды по годоту, юнити, движкосрачу, уже существут по 10 лет. За это время через них прошли сотни, тысячи людей. И что-то я не видел здесь каких-то игр, так, 3-5 игр максимум.
Статистика неумолима, заниматься ерундной - это пытаться делать игру на готовом движке без опыта разработки.
Чтобы сделать хорошую игру, нужно или быть опытным художником, делать красивые игры и истории, или опытным техническим специалистом и делать интересные, сложные системы. У скачавшего годот дурачка нет ни того, ни друго, и, самое главное, нет третьего - желания чему-то учиться.
> И что-то я не видел здесь каких-то игр, так, 3-5 игр максимум.
А засем сюда постить игры? Это тред движкосрачей, а не игр.
анимация и стиль игры связаны
см концовку https://www.youtube.com/watch?v=vlw7B2e7VDc
они как бы стилизованные, мультяшные. Как гта вс, гтс са, булли. Как дисхоноред, Буллетшторм, симсы
а есть игры с уклоном в "реализм". анчартед, гта 4 и5, рдр 2010 и 2, асссин крид 2007
Вопрос такой: насколько сложнее делать "реалистичные анимации" персонажей как в гта5/6 в сравнении со (мультящной?) "стилизацией" в стиле 33?
стилизация даёт а) меньшую критичность публики.(т.е. когда у тебя вся игра мультяшная, плохая анимация - не плохая анимация, а часть мульятшности) б) больше пространства для ошибки/похуизма/не попадания в назначенную цель. Если ты стилиозваонную анимацю бега(как в 33) сделашеь менее или более резкой, интертной, легкой, воздушной - никто не заметит, все скажут, как бы результат не был, что это часть стилизованного визуала. Но если ты промахнешься с инерцией, пропорциями, весом и ускорением/замедлением стопы относиетльно плеча во время разгона бегущего персонажа в ГТА - это будет бросться в глаза
с развитием ИИ уже есть какие-то вщи чтобы без дорогого мокапа делать AAA+ анимацию уровня гта 6 и рдр2?
чтобы снять сэмплы с людей в ютубе, и сделать их для своей гта-шанхайский-крайм в стиле джона уика и слипинг догс.
А есть какие-то идеи имплементировать генеративный ИИ весом в пару мегабайт максимум, ктоторый бы во время игры менял анимацию персонажа КАЖДЫЙ РАЗ чтобы ЧУТЬ-ЧУТь разные анимации заныривания за укратие и выныривание из него были? Это ведь реально реализовать скриптом в 512 кб, не? вопрос только как встроить в движок уе5.
Вот условно говоря есть скелет ГГ. С тончостью до поворотов и углов ступней и рук. И как-то научить движок анимации иметь "допуски", иметь вариативность изнмения анимаций "прильнул к стене", например. И не рандомно, а в зависивости от игрвоой ситуации. Но не чисто ИИ, который будет 2гб врам жрать анализируя картинку, а просто чтобы "сккелет" нпс знал и различал пол/стены/бордюры/окна/двери/заборы(ну они очеивдно зашиты в текстурах игровой сцены и каждый имеет свою кодировку), парапеты, и act accordingly. Плюс еще в 512 кб уместить анализ происходящего на сцене(перестерлка, погоня, стелс-слежка), чтобы пистолет/биноколь/пулемет для стрельбы изза укратиы во время дикой перестрелки, во время стелс-перестрелки и во время нгаблюдения - по разному высоывался. Если условно говоря в ГГ летят дохуя пуль - то он не просто стоит за стенкой, а прямо жмётся от страха, а вокруг осколки и пыль и дым. А?
>В claire 33
>стилизованные, мультяшные
Ты троллишь или твоя шизофрения ухудшается, гтаспб-шиз?
Искал clair в steamdb и нашёл пример реально мультяшной игры...
>стиль игры
Стиль "clair 33" - это "фотореалистично-дегенеративные УЕ5-помои".
>игры с уклоном в "реализм"... гта 5
Если "clair 33" - "мультяшная", то GTA 5 - самая мультяшная на свете.
>генеративный ИИ весом в пару мегабайт максимум
Конкретно у тебя не хватит данных для его обучения.
Ты хоть что-нибудь на практике сделал за эти годы?
вот просто создать себе fluid pipeline где я бы отлучаясь-прилучаясь к пк то тут то там просто чуток что-то редактировать, менять. не с 8 до 18 работаь а просто до обеда, после, вечером, прерывисто
Пилил-пилил тянку из бревна себе для игры, вроде всё нормально. Не, нихуя, оказалось, что в софте-то оно нормально, а вот в игре из-за fov пиздец уёбище. Губошлёпка. Переделывать нахуй. Пропорции? Ебал их в дышло, у меня нет художественного образования. Блядь, голова квадратная получилась. Вытянул - яйцо ёбаное. Пиздец, блядь, я бы половину игры за это время успел сделать. Теперь по-новой начинать всё. Ух, пиздец.
>в игре из-за fov пиздец уёбище. Губошлёпка. Переделывать нахуй
Так ты в софте FOV поменяй на нормальный. У тебя же Blender?
>Пропорции? Ебал их в дышло, у меня нет художественного
При чём тут это? В 3D любой на этом подрывается в первый раз.
>голова квадратная получилась
Накинь Subdivision Surface...
>Что-то не видел, чтобы игры делали хуйдожники.
2D художники делают визуальные новеллы.
3D художники делают симуляторы ходьбы.
Мне кажется, ты видел и тех, и других...
> И что-то я не видел здесь каких-то игр, так, 3-5 игр максимум.
Пчел, ты же понимаешь насколько тут токсичное коммьюнити. Кто в здравом уме станет обрекать свой продукт на токсиков, которые могут подносрать?
Первые насрут от зависти.
Вторые насрут от крысости
Третье не смогут, но в душе бы насрали.
Мне думается львина доля около-инди и инди разработки это художники. В анриле вместо языка программирования вообще блок-схемы. Это же явно для гуманитариев.
>Первые насрут от зависти.
>Вторые насрут от крысости
>Третье не смогут, но в душе бы насрали.
Какого покемона... И кто же из этих троих - ты?
Алсо, лучше проверить игру на токсиках, чем на жополизах.
Токсики найдут все недостатки, а жополизы их проигнорят.
мимо ни на кого не срал, сижу тут несколько лет
>В 3D любой на этом подрывается в первый раз.
У хуйдожника уже есть бэкграунд. В 9 из 10 случаев у меня будет достаточно хороший код, который не будет тормозить игру, потому что у меня есть какой-никакой опыт в этом говне. То же с артом, если человек хотя бы дрочил какие-то карандашные скетчи, то он уже понимает как должно быть, какой размер и форма должны быть. Не обязательно реалистичные, а хотя бы не вызывающие реакции "ёб твою мать". Потому что вот я выдрочил форму черепа по референсу, но если использовать референсный череп для лица - то получается лицо уебана. И абсолютно правильный по форме череп выглядит уёбищно энивей, какой-то гидроцефал нахуй.
>Мне кажется, ты видел и тех, и других...
Я смотрю на графоний в местных играх, потом смотрю в /td и /pa. Нет тут художников, по-моему.
>>1066642
Ну ты на игры посмотри, там в лучшем случае арт от программиста. Железное мясо художник, а остальные даже хуй знает.
>выдрочил форму черепа по референсу
Ты же знал, что у человека вокруг черепа - мышцы, жир и кожа?..
Это на ебале, сбоку, сзади, сверху - там чуток кожи и пиздец.
>Токсики найдут все недостатки, а жополизы их проигнорят.
Только в манямечтах, в реале будут шизеть до последнего над какой-нибудь фигней. Типа шрифт не тот или персонаж некрасивый и вообще нейрослоп.
Очень полезная критика. нет
ХОТЕЛ ВЗЯТЬ 66666-ПЕНТИПЛЬ
@
НА ДОСКЕ 1066664 ПОСТА
@
СДЕЛАЮ СРАЗУ ДВА ПОСТА
@
@
@
УКРАЛ ПЕНТИПЛЬ САМ У СЕБЯ
Покажи нормально модельку, может, она не так уж плоха.
Ты в фотореализме игру делаешь или как-то стилизованно?
>>1066670
>шрифт не тот
Читабельный шрифт очень важен в игре, где много текста.
>персонаж некрасивый
Красивые персонажи важны для сарафанного радио игры.
>вообще нейрослоп
Сейчас это важно, т.к. таких шизиков в стиме очень много.
>Очень полезная критика
Да, полезная, если ты не шиз с "я ХУДОжник - я так вижу".
Ты не понимаешь природу человека.
Он может говорит "переделай", не по реальной причине, а от зависти, настроения нет, жена не дала, на работе напряг, в школе или в движкотреде обижают. Это завуалированная агрессия, а ты как ньюфажа побежишь шрифты менять
Чела заставляет отчим писать на годоте и он когда на работе кидает сюда ишью с багами. Но вот отчим в отпуске он очкует в движкосрач заходить. Представь какие рекомендации может дать такой озлобленный жизнью человек??
>Он может говорит "переделай", не по реальной причине
>ты как ньюфажа побежишь шрифты менять
У дварфминатора реально всратые шрифты, в которых БУКВАЛЬНО КАЖДАЯ БУКВА ПЕРЕЧЁРКНУТА ДЕКОРАТИВНОЙ ЛИНИЕЙ, КОТОРАЯ М Е Ш А Е Т Ч И Т А Т Ь Т Е К С Т В И Г Р Е.
Пикселявые шрифты тоже очень часто нечитабельные из-за своей максимальной пикселявости.
И ты считаешь, что любое замечание по этому поводу - токсичный троллинг ньюфага?
Ну, собственно, ты и есть типаж оторванного от объективности шиза.
Сижу пугаю шизами самого шиза, ппц.
>может, она не так уж плоха
Там пиздец. Вот модель на которой я подгорел и снёс ебало. Губы пиздец, щёки хотел сделать пухленькими, но получился какой-то склад жира нахуй. Этот рот, оно меня сожрёт. Зато затылок нормальный. Теперь смотрю на пик, нижняя часть лица вообще слишком низко, поднимать надо. Было бы, если бы не новое ебало.
Для фотореализма нужно человек двести, чтобы ассеты пилили, так что реализма не будет. Я лучше въебу больше времени на настройку освещения, чтобы это выглядело красиво, чем на ассеты, чтобы они были более реалистичными.
>>1066675
>Чела заставляет отчим писать на годоте и он когда на работе кидает сюда ишью с багами.
Проиграл.
Если воспринимать любую критику как токсичность, то да. Наоборот, здесь честные люди которые скажут всю правду, а не просто похвалят.
Похуй, вообще не впадлу сконвертироовать, это прямо скажем не самая печальная сторона годота
Ей надо штоб как в "нормальных" движках, чтобы они все возможные и невозможные форматы жрали из коробки, в целом ну - требование справедливое, но не для опенсорса
Кто-то имел дело с simd?
>bvh, и результат получился, скажем так, удурающий
А как хотел? Не удурающий результат на bvh? Лол. Делай деревья шире, строй снизу вверх, тщательно балансируй. Тогда заиграет. А может и нет.
Дело в том, что сами проверки по себе тяжелые. Дело даже не в дереве. 2000 объектов = 4000 проверки узлов в дереве = 24 000 проверки AABB x плоскость, это уже у меня занимает ~1-3мс
Если использовать AVX и размазать по 6 потокам, то можно ускорить в ~50 раз это все примерно
Что плохого, когда человек просит не брать каку с пола использовать онлайн сервисы конвертации, а взять нормальную булочку с полки ffmpeg?
>>1066646
> Алсо, лучше проверить игру на токсиках, чем на жополизах.
Вы не шарите вообще. Какие жополизы? Тесты делаются на реальных игроках на плейтестах, в стим есть кнопка создать плейтест - делайте и собирайте объективную инфу.
Здесь банально в другом проблема - здесь не целевая аудитория и здесь очень мало народу. Ну сколько тут срут, в этом треде человек 20, на всей доске человек 200, сколько из них посмотрят и что-то напишут, а сколько что-то полезнок напишут?
Вряд ли это даст хоть какую-то пользу, даже если кто-то напишет хорошие советы - эти хорошие советы ещё не факт что соответствуют действительности и игрокам может быть поебать на это, надо проверять на игроках.
Поэтому в любом случае всё сводится к плейтестам с игроками.
А тут есть и долбоебы которые будут деанонить разрабов и пытаться им как-то поднасрать(не могу придумать вариант как конкретно, но тут глааное желание), поэтому никто сюда ничего постить не будет.
>А тут есть и долбоебы которые будут деанонить разрабов и пытаться им как-то поднасрать
Такие тоже появятся, если вдруг твоя игра станет популярной. Нужно заранее готовиться.
>Такие тоже появятся, если вдруг твоя игра станет популярной. Нужно заранее готовиться.
Когда у тебя уже тонна отзывов, говно крыс будет даже не замечено, а вот ньюфаг без маркетинга будет страдать от всего, от плохих отзывов, даже от покупок и возвратов (это учитывается тоже). У крыс может быть много акков, там у дотеров их десятками.
Если ты залил ноунейм игру в стим и ждешь каких то отзывов, то ты априори дурачок, которому уже ничего не поможет. Зря боишься этих "крыс", наоборот, черный пиар.
>>1066755
Стим это не тикток, негативное и возвраты - это просто отсутствие шанса по продвижению.
Стим как и поисковики могут (редко) добавлять со дна игры список выдачи и оценивать фидбэк. А любой негатив он уменьшает и так малые шансы попасть кому-то в список. Крысы испортят ранжирование и все.
Скорее отсутствие отзывов - это приговор. Лучше 100 желтых и красных отзывов, чем 3 хороших.
100 негативных это приговор (сразу в фильтр как неликвид).
Возвраты страшнее.
100 отзывов означают что 100+ человек было здесь. а негативные они или нет, не так важно. если нормисы видят 0, это хуже.
>А любой негатив он уменьшает и так малые шансы попасть кому-то в список.
Там система вроде ютубовской. Закинул кому-то в рекомендацию, если никто не зашёл и не пролайкал, то нахуй надо. И больше никому не показывает. Если нет позитивных отзывов то нахуй ты не нужен вообще.
> Если ты залил ноунейм игру в стим и ждешь каких то отзывов, то ты априори дурачок, которому уже ничего не поможет
Чел ты дебил? Чтобы получить отзывы надо набрать вишей и провести плейтест.
Чел, система понимает даже сколько ты на странице был и смотрел ли ты демо видео, кликал по картинками или сразу ушел.
Там сложнее аналитика чем твои юные фантазии.
Причем тут анал итика? Я говорю о том, как люди видят твою страницу с игрой.
Викинги на драккарах по африканской пустыни - в каких это было свитках? протрезвей
Ты переоцениваешь аналитику, и то, что стим твою игру покажет 2.5 пользователям.
Какое бы ты видео посмотрел на youtube, с 3 тысячами просмотрами, или с 3?
>Какое бы ты видео посмотрел на youtube, с 3 тысячами просмотрами, или с 3?
У кого более цепляющее превью и название. Дерек эту тему кстати освещал, что вынуждает его менять название и превью по 10 раз на одном и том же видео, чтобы зацепить максимум аудитории, идущей по рекомендациям и с ленты. Количество просмотров не имеет значения вообще. Эра кликбейта вернулась на ютуб, а со стима она никогда не уходила.
Ты сравниваешь каналы с миллионами подписчиков с ноунеймами. Чтобы работает для популярных каналов, не имеет значения для ноунеймов.
Я ничего не сравниваю, дерек просто наглядно обьяснил как это работает, по такой схеме я вижу уже 3 видео которое ебет мою ленту по 10 раз в день с темой о том что алгоритмы ютуба сломаны если вы видите это видео, хотя мне похую на алгоритмы ютуба вообще, я никогда ими не интересовался, при этом часто от каналов с сотней подписоты прилетает и раскручивается какой-то видос про интересную мне тему и я неиронично их смотрю (а затем вижу в истории как они меняют название). Это общая схема, работает для всех и все ее щас абузят.
Разница в том, что они манипулируют алгоритмом, потому что у них есть ресурсы. Видео с большого и так будут показывать. Для них это разница между 1 - 1.5 миллионами просмотров. Ноунейм канал может сколько угодно менять картинку, это ни на что не повлияет
C пробуждением. Мы там чуть выше буквально memory wall обсуждали. Всегда всё дело в данных. Меньше данных - лучше, всегда так работает.
https://www.youtube.com/shorts/pNzsvYWMMkg
Топология кал. А так зайди к эпикам, у них валом таких сканов.
фотограмметрию впервые видишь?
сегодня уже достаточно несколько фоток с мобилки, нахуя он там маркерами обклеил статичный предмет непонятно. результат посредственный, еще и с этими маркерами запеклось
>Что вы думаете об идее "реалмов" движка? Это как, например, в годоте разделение на 2D и 3D, но позволяет создать "реалм" для любого типа объектов, как оптимизацию
Ты про вьюпорты и возможность стримить вьюпорт в виртуальную текстуру? Так это и в юнити есть, создаешь вторую камеру, выводишь ее в rendering texture и используешь как хочешь. Используется для многих видов постпроцессинга, мне кажется это очень важная часть любого движка.
Нет, например, в годоте есть отдельные вкладки с 2D и 3D режимами. Суть в том, что можно добавлять свои вкладки с режимами создания объектов другого типа. Например, есть вкладка Static Meshes, ты переключаешься на эту вкладку и редактор переходит в режим расстановки статических мешей. Суть в том, что таким образом можно оптимизировать рисовку статических мешей, чтобы не использовать тяжелые ссылочные типы GameObject. например, можно хранить их в оптимизированной DoD структуре, или вместо matrix4x4 хранить только положение и вращение, и уменьшить размер данных в 2 раза.
Ты предлагаешь слишком специфические оптимизации, которые не подойдут каждой игре. Многие оптимизации сильно зависят от геймплея конкретной игры. То, что значительно улучшает производительность в одной игре, может сильно ухудшать производительность в другой игре, либо вообще запрещать реализацию какой-то игровой механики. Также нужно учитывать то, что до сих пор существуют специфические платформы, для которых нужны особые оптимизации. Поэтому "движок общего пользования" не должен вводить такие оптимизации принудительно.
К тому же, если эта фича заставляет пользователя переключаться между какими-то функциями движка, это усложняет разработку. Вот ты привёл пример с 2D/3D в Godot - там это разделение требует от пользователя дополнительных телодвижений, если нужно тесно соединить 2D и 3D в одной сцене, и вводить дополнительный слой абстракции, если тебе нужны 3D трансформации для 2D спрайтов (типичная ситуация в популярных 2.5D играх). В Godot даже ввели специальные ноды - Sprite3D и Label3D - чтобы упростить процесс добавления 2D в 3D, но если тебе нужен полноценный GUI на Control-нодах в 3D пространстве - тут уж извини, но придётся возиться. А если бы всё было в одном пространстве, то таких проблем не было бы... но было бы медленнее, конечно. Весь вопрос в том, что чаще требуется - 2.5D игра и 2D GUI в 3D мире, или полноценное разделение на 2D и 3D? Разработчики Godot справедливо решили, что разделение на 2D и 3D встречается в играх чаще, чем разные 2.5D стили. С другими оптимизациями всё точно так же.
>вместо matrix4x4 хранить только положение и вращение
Перемножение матриц - настолько частая операция, что для процессоров давно уже изобретают специальные команды для перемножения матриц. А твоя "оптимизация" полагается исключительно на базовые команды процессора, которые давно упёрлись в лимит и дальше на уровне железа не могут быть оптимизированы. Суть "железных" оптимизаций кода в том, что одна даже очень сложная операция может быть выполнена за один такт процессора, если у конкретного процессора есть выделенные под эту операцию "дорожки" (и команды для управления ими, которые компилятор может вставить в программу автоматически). Конкретно в играх я не уверен, какая сейчас ситуация, но думаю, если смотреть в будущее - будет больше специализированных наборов команд, со-процессоров (типа NPU) и даже дополнительных чипов на материнской плате (как GPU). У простых универсальных наборов команд (RISC) есть предел и мы в него давно врезались, поэтому дальше можно только умножать количество параллельных ядер (что для игр почти бесполезно в 99.99% случаев) и создавать специальные наборы команд для популярных алгоритмов.
>Какие жополизы?
Которые боятся кого-либо случайно задеть, чтобы не потерять репутацию.
>Тесты делаются на реальных игроках на плейтестах
>игрокам может быть поебать на это, надо проверять на игроках
"Игрок считает, что знает, что нужно игре, но на самом деле он не знает, чего он на самом деле хочет" - цитата кого-то из геймдизайнеров, не помню уже, где нашёл, но это врезалось мне в память как то, что реально отражает мой опыт и как игрока, и как разработчика собственных игровых поделок. Суть в том, что отзывы игроков - это худшее, по чему можно судить о конкретной игре, а следовать советам игроков - худшее из того, на что можно ориентироваться в дизайне и разработке игры. Игроки мало того, что не знают, как реально работает игра (но верят, что их догадки совпадают с реальностью) и какие сегодня существуют ограничения в разработке игр, сколько времени и сил уходит на что-то и т.д. - игроки ещё и со своими собственными ощущениями разобраться не могут. Практически бесполезно спрашивать, фановая игра или нет, что в ней нравится, а что нет - большинство ляпнут бесполезную чепуху.
Единственная польза от игрока - это сбор биометрических данных непосредственно в процессе игры с конкретного человека. Т.е. сидеть рядом и следить за мимикой лица, за направлением взгляда, за эмоциями, реакциями - но не вмешиваться и не помогать, а только смотреть. Никакая встроенная в игру аналитика не сможет это всё записать, если вы не требуется включать веб-камеру и вести трансляцию. Только так можно понять, что реально вызывает положительный отклик у игрока.
Но и этого недостаточно - нужно разбираться в психологии людей, чтобы уметь ими манипулировать через игру. Компьютерная игра - это как автоматизированный манипулятор людьми. Сам человек в абсолютном большинстве случаев не знает, почему он поступает определённым образом - люди в действительности не осознают причин своего поведения. Поэтому психологи много веков строили различные модели, которые пытаются объяснить причины поведения и предсказывать то, как типичный человек на что-то отреагирует. Успешно спроектированная игра ЗАСТАВЛЯЕТ игрока играть в себя, используя множество манипулятивных стратегий, действующих на бессознательном уровне на большинство людей. Именно так некоторые игры становятся супер-популярными, пока другие - да, хорошие, но в них никто не играет. Базовые стратегии многие здесь, думаю, и так знают - "лутбоксы", "запас энергии" и т.п. Но это - лишь вершина айсберга.
В общем, лучше общаться с теми, кто имеет отношение к геймдеву, и показывать им свою игру - т.к. они разбираются в психологии и тонкостях разработки игр, поэтому с большей вероятностью могут дать более практичные и полезные советы (пусть и после кучи оскорблений) даже после беглого взгляда на скриншоты и описание, чем случайные школьники после многих часов игры в демо-версию в Steam. И это также касается отзывов в Steam: >>1066744
>будет страдать от всего, от плохих отзывов, даже от покупок и возвратов
Габен не дурак и понимает психологию пользователей, в интересах которых он хочет больше хороших игр на своей площадке. Уже давно ввели механизмы защиты от вайпа негативными отзывами, а возврат игры - контролируемая процедура, которую игроку нельзя абузить. Кроме того, админы Steam лучше нас понимают, что большинство любых отзывов - бесполезный мусор, тупой флуд, паразитный шум - и они наверняка учитывают это в своих алгоритмах. Если игра действительно хорошая и не заслуживает волны необоснованного негатива, они с этим наверняка разберутся - в противном случае они потеряют ценного клиента (разработчика игры) и возможность заработать на его продукте, а игроки никогда не увидят хорошую игру. Но вот если игра - "ассетфлип", тогда да - никакой пощады этому мусору. Делайте хорошие игры и тогда не будет никаких проблем с абстрактными хейтерами, предел возможностей которых - написать "фу, плохая игра, аффтар дурак" в отзывах в Steam и оформить возврат, лол.
> Которые боятся кого-либо случайно задеть, чтобы не потерять репутацию.
И что это за люди? Где мне их увидеть?
> "Игрок считает, что знает, что нужно игре, но на самом деле он не знает, чего он на самом деле хочет"
Игрок вполне конкретно пишет, что ему нравится и что не нравится, даёт конкретику по багам, косвенные указания на проблемы с производительностью.
Твоя цитата справедлива для ситуаций когда игрок говорит например "вот сделали бы Б вместо А было бы лучше" - такого он знать не может, было бы так лучше или нет.
Но зато игрок точно знает, что его раздражает и что ему по приколу, именнов конкретной игре что имеет, а не в общем случае.
Из отзывов игроков надо получать полезные данные, которых там полно, заведомо бесполезные не нужны.
> Единственная польза от игрока - это сбор биометрических данных
Помимо того, что я описал выше в виде отзывов есть и второй огромный пласт информации от плейтеста - аналитика. До куда сколько процентов игроков доходили, сколько чем пользовались.
Биометрические данные - это круто, но невероятно дорого и долго, в нашей компании такое лишь для одной игры делали.
> В общем, лучше общаться с теми, кто имеет отношение к геймдеву, и показывать им свою игру - т.к. они разбираются в психологии и тонкостях разработки игр
Ты знаешь как геймдизайнеры работают? Вот ровно так как я описал - делаются гипотезы касательно того, что за игру можно сделать, какие механики туда стоит добавить.
Проводятся внутренние тесты и анализируется фидбек, по нему строятся новые гипотезы - почему так и как нам сделать, чтобы были лучше метрики.
Дальше проводятся плейтесты с рандом игроками и точно таким же образом все данные анализируется.
Гипотезы делаются на основании своего опыта(анализа вышеописанных данных и попыток делать какие-то решения на их основании, чтобы поднять метрики вовлечения), понимания психологии игрока, своего ощущения от игр и просто доли экспериментальных идей.
Нету волшебных людей, которые тебе сразу скажут - делай так, базарю, нормас будет. Нет, не будет. Разработка игры с точки зрения геймдизайна это итеративный процесс, в котором нету сразу правильного решения и вообще едиснвтенно правильного решения, есть две объективные метрики - медиана и процент положительных отзывов, и есть пласт данных на основе которых можно принять решения, чтобы поднять эти 2 объективные метрики.
Там объём данных ничтожный. Даже если ты отдаёшь дохуя данных (типа 128 байт на инстанс, что дохуя) то 2000 объектов это четверть мегабайта, Вопрос только в том как ты их хранишь и как передаёшь. У меня всё линейно и производительность заебцом.
Конкретно я выделяю кусок в кольцевом буфере для примерно 200 инстансов, записываю туда данные, потом дёргаю vkCmdDraw с InstanceID для адресации. Потом делаю для следующей группы для 200 инстансов пока они не кончатся. Десяток тысяч объектов это считай что ничего.
>И что это за люди? Где мне их увидеть?
В любом приличном сообществе разработчиков:
>ой, какой же ты молодец, такая хорошая игра!
>ой, я б так не смог, ты прям лучший геймдев!
>ой, дайте ссылку - вишлистну и потом куплю!
Сама игра: "мой первый ассетфлип на юнити".
Поэтому есть reddit.com/r/DestroyMyGame/
>пишет, что ему нравится и что не нравится
"Ыыыыы, прекол, можна камеру вращать))"
"О, а зделойте штоп ищо домики набигали!"
>даёт конкретику по багам
"Грёбаный багфест... но мне нравица))))"
>указания на проблемы с производительностью
"Фу, на моём компуктире 59 фпс, фуфуфу..."
>что его раздражает
То, что проиграл в честном бою. Дальше что?
>что ему по приколу
Пинать консервную банку на улице. И что?
>в нашей компании
Ой, всё. Это форум соло индюков...
> В любом приличном сообществе разработчиков:
То есть... чтобы найти "жополизов" я должен прийти в некое "приличное сообщество разработчиков" и туда свою игру запостить? А зачем мне это делать?
Я не понимаю.
> "Ыыыыы, прекол, можна камеру вращать))"
> "О, а зделойте штоп ищо домики набигали!"
> "Грёбаный багфест... но мне нравица))))"
> "Фу, на моём компуктире 59 фпс, фуфуфу..."
Это не соответствует действительности совершенно.
Поверишь на слово?
Или вместо с тобой откроем и почитаем отзывы под играми в стиме?
К сожалению только с релизнутых игры получится, с плейтестов мы не сможем получить доступ к отзывам.
> То, что проиграл в честном бою. Дальше что?
Заивисит от конкретики, что за игра, где там можно в честном бою проиграть, возможно дело в пенальти за поражение, в слишком высокой сложности. И что важно - надо смотреть насколько частые жалобы есть в том же направлении.
> Пинать консервную банку на улице. И что?
Тоже идиотский пример, но даже это может свидетельствовать о том(при наличии большого количества других сообщений из того же направления), что какие то побочные фановые элементы вне основного геймплейного цикла и механики все таки важны в этой конкретной игре.
> Ой, всё. Это форум соло индюков...
Мне кажется ты и не соло индюк, судя по примерам фидбека, которые ты пишешь. Вряд ли ты выпускал игры и работал с информацией от аудитории.
правда, что в годоте пропуки?
Отчим в запое? С возвращением.
Сейчас смотрел в супермаркете Юнити, пускал слюну на платные ассеты. Живут же богатые буратинки, кто это все покупает.
Странно почему юнити не по платной подписке как адоб?
3 года пилишь механики, выслушивая хохот и оскорбления, релиза даже близко не видать
>юнити
собрал ассеты и за три часа сделал релизуро, опубликовал во всех магазиносах
Тем временем продавцы ассетов, у которых единственный заработок на ньюфагах/вкатунцах.
>3 года пилишь механики, выслушивая хохот и оскорбления, релиза даже близко не видать
Стал про-мастером, знаешь как работает каждая приблуда в движке, потому что уже легко ориентируешься в сорцах самого годота. С легкостью пересоберешь годот с прикрученными С++ либами. Ржешь над теми кто пишет движок с нуля, когда у тебя уже полноценный написанный движок из которого сможешь слепить все что захочешь.
Пару раз контрибьютил в сам движок. Засветился в большом проекте, эйчары стали затрахивать со просьбами рассмотреть их предложение найме (тру стори, кстати).
>собрал ассеты и за три часа сделал релизуро, опубликовал во всех магазиносах
Попал в те самые 80% мусора стима, люди уже видели эти ассеты в другом таком же шлаке, дропают только по одной картинке.
До сих пор у нейронки спрашиваешь как написать контроллер персонажа и каждый раз эта скотина дает разный код. Не понимаешь почему после прыжка персонаж продергивает по оси Y. Потыкав дропаешь, возвращаясь на двачи, называя всех безыгорками.
>>годот
>3 года пилишь механики, выслушивая хохот и оскорбления, релиза даже близко не видать
Твои предки смотрят на тебя с неба улыбаясь.
>>юнити
>собрал ассеты и за три часа сделал релизуро, опубликовал во всех магазиносах
Твои предки проклинают тебя из глубин ада.
>Потыкав дропаешь, возвращаясь на двачи, называя всех безыгорками.
Скорее оформляешь всем проход в "игра не игра"
> >>годот
> >3 года пилишь механики, выслушивая хохот и оскорбления, релиза даже близко не видать
> Твои предки смотрят на тебя с неба улыбаясь.
А ты сидишь без игр. Зато подстроился под чужое мнение и поиграл в борца против корпораций - на самом деле все это лишь защита для своего эго, а игры второстепенны, поэтому игр и не вышло.
> >>юнити
> >собрал ассеты и за три часа сделал релизуро, опубликовал во всех магазиносах
> Твои предки проклинают тебя из глубин ада.
А ты сидишь с играми. Посмотрел на ситуацию, взял все лучшее для себя, и получил профит, как психически здоровый человек, которому не надо ничего никому доказывать.
Я на юнити, почему я сижу без игорь? Помоги, что я делаю не так?
1) Я взял юнити
2) ...
И?? че дальше?? Почему так сложно :( почему я без игори, вы мне обещали игори.
Завтра еще раз попробую переустановить юнити.
>Завтра еще раз попробую переустановить юнити.
Почему этим нехорошим людям не нужно переустанавливать годоти? Они вообще офигели, берут просто запускают exe.
А может поэтому и игорь у них нет?? Тогда почему у меня нет??
> Я на юнити, почему я сижу без игорь? Помоги, что я делаю не так?
> 1) Я взял юнити
> 2) ...
> И?? че дальше?? Почему так сложно :( почему я без игори, вы мне обещали игори.
Надо учиться. Кнопки "игра" нету.
Средний срок обучения для разработчика начинающего уровня - 6-12 месяцев.
>собрал ассеты и за три часа сделал релизуро, опубликовал во всех магазиносах
>Средний срок обучения для разработчика начинающего уровня - 6-12 месяцев.
Ну вот, оказалось юнити не волшебный школьный пенал.
>А ты сидишь без игр. Зато подстроился под чужое мнение и поиграл в борца против корпораций
Вот только в последнее время большинство успешных инди игр на годоте.
>А ты сидишь с играми.
На дне стиме, с 0 отзывов.
>взял все лучшее для себя
Кучку васянских кривых ассетов.
>и получил профит
В виде возможности писать на дваче что ты теперь с играми.
По деньгам профит минус 100 баксов за каждый слот.
>Вот только в последнее время большинство успешных инди игр на годоте.
Пасиб, настроение поднял
> Вот только в последнее время большинство успешных инди игр на годоте.
Список? Вот я открыл топ селлерс(не ирли, а вообще все) в стиме, то что выше это всякие титаны вроде гта 5 и доты. Сколько тут игр на годоте и сколько на юнити? Будем скроллить дальше?
> На дне стиме, с 0 отзывов.
> Кучку васянских кривых ассетов.
> В виде возможности писать на дваче что ты теперь с играми.
> По деньгам профит минус 100 баксов за каждый слот.
А ты уверен?
Речь наверняка шла про соло разработчика, а ты список с жирнотой пихаешь. То что хорошо в компании не обязательно хорошо для одного генералиста
мимо
На годоте нет игр, так что и в список они попасть не могли. Всё логично.
В топ 100 точно не будет. Невозможно в соло столько контента создать как компания. А при прочизх равных чем больше контента тем лучше продается.
Ого это все твои игры? Сильно.
Когда ты понял что юнити игры это не твои игры?
Когда впервые заплатил дань юнити или когда проект перестал открываться без зарубежного интернета?
>В топ 100 точно не будет. Невозможно в соло столько контента создать как компания.
> Речь наверняка шла про соло разработчика
> а ты список с жирнотой пихаешь.
Вроде речь шла про инди игры(насколько мне известно, инди игра - игра от маленькой команды без издателя). На скрине определенно есть инди игры.
Ну, скинь список игр от соло разрабов, посмотрим сколько там на юнити. Правда нахуя делать игры в соло мне не совсем понятно.
>>1067530
> Когда ты понял что юнити игры это не твои игры?
> Когда впервые заплатил дань юнити или когда проект перестал открываться без зарубежного интернета?
Ты ж понимаешь, что это тупо отговорки чтобы безрезультатно говно месить на годоте, вместо того чтобы взять и сделать игру нормально?
>Ты ж понимаешь, что это тупо отговорки чтобы безрезультатно говно месить на годоте, вместо того чтобы взять и сделать игру нормально?
Забавно, но на готоде разрабатывать приятнее. Если только у человека не профдеформация на синдроме утенка, но это обычно люди со стажем 10+ лет.
А так разницы никакой. Это как спор между пепси и колой. очевидно пепси вкуснее
Мериться чужими играми, это как мериться чужими автомобилями. У моего соседа круче автомобиль чем у тебя (у него уже их два).
PS Годот это популярный опенсорс движок. Открытый код движка это бесценный инструментарий. Думаю ближайшие 15 лет будет эпоха опенсорс движков.
> Забавно, но на готоде разрабатывать приятнее.
Что это значит? Как ты это понял?
> Если только у человека не профдеформация на синдроме утенка
Тот же вопрос.
> Мериться чужими играми, это как мериться чужими автомобилями. У моего соседа круче автомобиль чем у тебя (у него уже их два).
Некорректное сравнение. Ты приводишь 1 какой-то рандомный пример, я же привожу статистику.
> PS Годот это популярный опенсорс движок. Открытый код движка это бесценный инструментарий.
В каких ситуациях это полезно? Возможно, оно как-то помогло тебе?
>Что это значит? Как ты это понял?
-GDScript быстро собирается.
-Очень мощный хотрелоад, настолько сильный что тебе не нужно на каждый пук делать тестовую сцену, прикручивать консоль или тестовое UI. Ты в любой глубине игры можешь закинуть ноду и подергать её (как если бы дебаг-тулом добавил, только тебе не надо писать дебаг тулы).
-Очень быстро прототипировать, по причинам выше и по причине что питон-подобный GDScript, где после можно прикрутить типизацию, если прототип норм.
-Сам годот быстро запускает и работает - важно когда протипируешь и постоянно то открываешь другие проекты или прототипы.
-Организация нодами/сценами очень удобна и интуитивна.
-Организация когда сцена это отдельный модуль удобнее чем костыльные префабы.
Я сейчас буквально перекидываю папки между прототипами, прописывая только DI инжекты.
А главное проект мой, запускается даже оффлайн или без зарубежного инета и если надо я всегда могу ковырнуть сорцы. Хотя потребности еще не было.
Еще может что-то, но я уже в пижаме и мне лень вспоминать.
>В каких ситуациях это полезно? Возможно, оно как-то помогло тебе?
Да, вспомнил. Я посмотрел как рисуется Line2D в сорцах и понял почему у меня дергало отрисовку (спойлер, ничего необычного отрисовка так же в конце кадра через _draw() ).
>я же привожу статистику.
Ты просто не понимаешь инерцию рынка. Пхп до сих пор покрывает 70-80% веба, это говорит что надо вкатываться в пхп? Только в том году реакт обогнал jquery (по некоторым показателям еще нет), а мы его выпилили в 2011.
>я же привожу статистику.
Как статистика релизов в стим влияет на то как ты делаешь свою игру?
Ты радуешься за чужие игры и чужие машины. Как если бы выбирал автомобиль по числу выпушенных машин заводом.
Как это помогает тебе?
Или ты просто порадоваться за других?
>Пхп до сих пор покрывает 70-80% веба
Это только доказывает что хипстерское говно вроде ноды просто нежизнеспособно, а jq выполняет задачи лучше реакта.
>Что это значит? Как ты это понял?
Отсутствие поисковика зависимостей его надоумило на приятность, волю дай - он иде на блокнот променяет и будет сидеть кайфовать
>>1067543
>очевидно пепси вкуснее
имхо даже кола зеро вкуснее пепси, не говоря о неповторимом оригинале
>>1067548
>Очень мощный хотрелоад, настолько сильный что тебе не нужно на каждый пук делать тестовую сцену, прикручивать консоль или тестовое UI
Сижу на 3.6 моно и не понимаю о чем говорит этот человек, тем более хотрелоад отваливается рандомно и имеет ограничение в невозможность редактирования экспортных переменных, так как это сразу его ломает, не говоря о том что 95% багов это софтлоки, которые разруливает только ребут сцены полностью, очевидно что лучше иметь дебаг-меню.
>Очень быстро прототипировать
Ебало прототипипировальщика на движке который жрет только свободные форматы представили?
>Сам годот быстро запускает и работает - важно когда протипируешь и постоянно то открываешь другие проекты или прототипы.
Важно только если у тебя вместо компьютера офисный компьютерозаменитель.
>Организация нодами/сценами очень удобна и интуитивна.
Особенно максимально интуитивно становится, когда нужно пилить наследование для всяких кнопок/кастомных контроллеров и прочих приколов. И у тебя Node/2D/3D Control контроллер, который управляет реальной нодой.
>Организация когда сцена это отдельный модуль удобнее чем костыльные префабы.
Не понял чем танцору яйца помешали. Ты можешь всю игру слепить чисто на префабах имея 1 сцену.
>>1067550
>Ты просто не понимаешь инерцию рынка.
Ох уж эта инерция рынка, в которой джумла и прочие пхп движки живее всех живых, особенно в кризис, когда кабаны на хую видали новые технологии, им бы на плаву остаться и косты посрезать.
>>1067551
>Как статистика релизов в стим влияет на то как ты делаешь свою игру?
Тут согласен, статистика стима не должна влиять никак, только обьективные данные. А обьективно - анрил (даже в 2д) >>>>> юнити >> годот. Остальное - это вкусовщина, привычки, предпочтения.
Нет, это показывает отсутствие понимая основ айти рынка.
Будущее за опенсорс, просто геймдев жил вечно на отшибе. Сейчас художка станет (стала) доступнее и легион кодеров полезет в геймдев, задавая градус всей айтишечки. Сам десятилетиями обходил ваш загон.
На данный момент, со всем прогрессом в нейронках, единственный стиль в котором художка реально стала доступнее это [ДАННЫЕ УДАЛЕНЫ], все остальное все так же требует умения рисовать, умения анимировать и еще много других конченых умений. Музыка - да, насрать эмбиентами стало куда проще, 3д энвайронмент тоже стало можно нейронить, что не лишает потребности в анимировании персонажки, этого самого нагенеренрого окружения и т.д. и т.п. Даже кодонейронки без реального прогера практически бесполезны, так как делают не то что пользователь хочет, а то, что он просит, а просить тоже надо уметь.
>Сижу на 3.6 моно
После криокамеры ноги не ломит?
> отваливается рандомно
С гуньдоскриптом на 4 все норм
>Ебало прототипипировальщика на движке который жрет только свободные форматы представили?
Опять конвертировал видосы через вебсайты?
>свободные форматы?
Будешь оплачивать неустойку, когда придет дядя с DMCA?
>Важно только если у тебя вместо компьютера офисный компьютерозаменитель.
Там на юнити только смотрят.
>Особенно максимально интуитивно становится, когда нужно пилить наследование для всяких кнопок/кастомных контроллеров и прочих приколов
Нужно учиться программировать, нейронка тебя не вывезет везде.
>Ты можешь всю игру слепить чисто на префабах имея 1 сцену.
И потом можно будет его между проектами таскать?? :)
>Ох уж эта инерция рынка,
Как тебе помогает то, что люди релизят в стим свои игры на юнити? У тебя от этого волосы шелковистее или че? Или тут работает принцы - миллион мух не могут ошибаться, значит я правильная муха?
Ты тоже купишь булочку, только потому что пекарня выпускает больше всего этих булочек?
Или ты в тайне осациируешь себя с теми людьми? Типа Раст на юнити и давай дрочить от этого?
Поможет тебе то, что раст на юнити - написать свой раст?
> -GDScript быстро собирается.
Плюс объективный, базару ноль.
> -Очень мощный хотрелоад, настолько сильный что тебе не нужно на каждый пук делать тестовую сцену, прикручивать консоль или тестовое UI.
Как это связано с хот релоадом? Где в юнити надо делать тестовую сцену и прикручивать туда консоль и тестовое юи? Как ты себе этот механизм предсталвяешь и что мещает делать также как тебе удобно в годоте, например?
> Ты в любой глубине игры можешь закинуть ноду и подергать её (как если бы дебаг-тулом добавил, только тебе не надо писать дебаг тулы).
Пиздец странно звучит. А на юнити ты не можешь закинуть префаб на сцену в любой момент куда угодно или любой компонент повесить?
Но странность тут даже не в этом - а разве проблема которую ты так пытаешься решить - не решается просто брейкпоинтом в дебаггере?
> -Очень быстро прототипировать, по причинам выше и по причине что питон-подобный GDScript, где после можно прикрутить типизацию, если прототип норм.
В теории валидно, но мне тяжело представить даже прототипирование на динамикодрисне.
> -Сам годот быстро запускает и работает - важно когда протипируешь и постоянно то открываешь другие проекты или прототипы.
Тоже немножко странно звучит - мне кажется прототип делается пару недель, а не несколько штук разных проектов за день чтобы постоянно скакать по проектам.
А даже если есть потребность разные небольшие штуки прототипировать быстро - разве нельзя это в одном проекте делать?
> -Организация нодами/сценами очень удобна и интуитивна.
В юнити тоже есть сцены.
Геймобжекты и префабы не уверен, что чем-то хуже нод. Давай пример что удобнее с нодами делать конкретный.
> -Организация когда сцена это отдельный модуль удобнее чем костыльные префабы.
Тоже конкретный пример.
Вот есть юнити/годот, есть папка, в ней префабы/модули, нажимаю на префаб/модуль - оно открывается, вижу что внутри, что-то там меняю. И в чем разница?
> Я сейчас буквально перекидываю папки между прототипами, прописывая только DI инжекты.
А зачем ты их прописываешь? Почему нельзя перекинуть прямо так? Я в юнити могу прямо так. Могу даже пакейдж запилить с иерархией зависимости и всякое разное шарить между проектами 1 кнопкой, причем если какой-то модуль надо обновить - обнову сразу стянуть во все проекты, и там еще и чейнджлог и версии будут. Удобно для студии которая делает мобилки.
А могу ничего этого не делать и "перекидывать папки".
> А главное проект мой, запускается даже оффлайн или без зарубежного инета
Может быть валидно, но я не представляю разработку без интернета. Более того юнити тоже работает без интернета
> и если надо я всегда могу ковырнуть сорцы.
> Хотя потребности еще не было.
Ну оно как бы само за себя говорит
>>1067549
Странная какая-то проблема.
>>1067550
> Ты просто не понимаешь инерцию рынка. Пхп до сих пор покрывает 70-80% веба,
Если смотреть на все существующие интернет сервисы - возможно.
Если смотреть на актуальные вакансии и различиные сайты и сервисы сейчас в разработке - и близко нет.
Но дело даже не в этом. Ты говоришь, что юнити для лохов, годот круче. Чем годот круче, как нам это понять?
И даже более того, вот этот тезис, который это и начал - не мой.
Вот:
>>1067516
> Вот только в последнее время большинство успешных инди игр на годоте.
Возможно это не ты писал, но почему тогда ответил именно мне на ответ ему, а не ему?
>>1067551
См. выше - я лишь отвечал на тезис. Также это косвенное подтверждение моих слов, что юнити таки более пригоден для разработки игр, поэтому на нем игры и разрабатывают гораздо больше.
> Как это помогает тебе?
Никак. А мы говорим обо мне разве? Просто если обо мне, то я могу сразу сказать, что как опытный разработчик который делает игры, я бы не взялся делать игру на годоте, когда есть юнити и анрил, потому что в годоте слабый рендер, гдскрипт(то в каком виде поддержка например шарпа - не самый удобный вариант), система нод довольно хаотичная и слишком сильно прибивает код к годоту, встроенный инструментарий слабоват, сторонних инструментов тоже мало. По моей оценке эти факторы достаточно критичны для из упомянания и для того чтобы годот даже не рассматривать в текущих реалиях.
Но если вдруг юнити исчезнет, то наверное лучше всего будет переходить на годот(если игра не 3д)
> анрил (даже в 2д) >>>>> юнити
В анриле прибит С++. А в юнити шарп, с нормальными контрактами-интерфейсами, рефлексией(там где надо), простотой дебага засчет метаинфы, без выстрелов себе в хуй.
А еще в юнити есть охуенный 2д инструментарий прям из коробки - освещение, сплайны.
А еще в юнити есть мегадевайс - берст и жоб систем, которые юзаются на практике.
>После криокамеры ноги не ломит?
Сразу после веб экспорта шарпа в четверке зайду
>Опять конвертировал видосы через вебсайты?
>Будешь оплачивать неустойку, когда придет дядя с DMCA?
Напомню, речь про прототипы. И если ты возьмешь юнити/анрил - никакой дядя не придет. Просто хуану лениво возиться с многолицензионкой, и я его понимаю, но прототипировать от этого легче не становится.
>Нужно учиться программировать, нейронка тебя не вывезет везде.
Сказал человек который дрочится с хотрелоадом вместо того чтобы написать нормальное дебаг меню (даже нейронкой, займет минуты), поучи дедушку кашлять, как говорится.
>И потом можно будет его между проектами таскать?? :)
Прикинь - да. Либо просто скопируй префаб и его зависимости со всеми мета файлами в другой проект и все будет заебись работать, либо сделай unitypackage, это больше для ассетов под ключ. Все как в годоте.
>Как тебе помогает то, что люди релизят в стим свои игры на юнити?
Я написал, дело не в стиме, а в обьективных параметрах движков. Если ты не кодишь на арифмометре и если тебе нужен передовой функционал без гемора и у тебя нет каких-то особенных предпочтений - лучше вкатываться в анрил для всего, включая прототипы. В остальном - уже вкусовщина.
Пошла вкусовщина. Впрочем, анрил больше по сумме баллов лучше прочих движков, если нужна мультиплатформа - то лучше юнити, но для рф у юнити есть фатальный недостаток - в случае чебурнетизации - проекты станут тыквой в течении месяца, в отличии от годота и анрила
>Хотрелоад
Если текущий момент в игре состоит из цепочки действий который формируется в течение 5-10 минут.
Тебе нужно либо воссоздать сцену с этим моментом, чтобы брекпоинты ставить.
Либо перезапускать и ждать/делать 5-10 минут.
В годоте если код падает, он не только стектрейс показывает, но и дамп состояний (в юнити так же?).
В юнити хотрелоад был просто для галочки, не помню конкретно проблемы, но мне он мало чем помог. Видимо поэтому юнити-детвора не понимает плюсов хотрелоада, потому что у них он не работает.
Как можно понять того чего у тебя нет?
>В теории валидно, но мне тяжело представить даже прототипирование на динамикодрисне.
Если бы ты был программистом, ты бы знал что чаще всего прототипируют на питоне именно потому что это динамикодресня (и только потом, когда концепт окажется рабочим, берут вообще другой язык)
>Если текущий момент в игре состоит из цепочки действий который формируется в течение 5-10 минут.
Ты не представляешь как подобное смешно слышать от программиста. Да даже если нет дебаг меню, ты можешь просто написать скрипт-ускорялку и дойти до проблемного места, опять же, повторюсь - 95% багов софтлочат игру, после софтлока тебе ни один хотрелоад не поможет, потому что стейт уже скоррапчен. Потому не страдай хуйней и делай дебаг меню, хотя учитывая что ты там делаешь на гексах - мы друг друга вряд ли поймем, потому что у меня баги уровня - клиент отправил не то, сервер послал не туда, другой клиент поломался, естественно поднято куча неотлаживаемых инстансов и надежда только на правильное логгирование.
>Просто хуану лениво возиться с многолицензионкой,
Это политика всего опенсорса. Прикрутил платное - сам потом с исками трахайся.
>Напомню, речь про прототипы
Прототипы на проприетарных техах? А потом их выкинуть? А зачем мы тогда их брали? Таблеточку?
>написать нормальное дебаг меню
Хотел, оказалось вообще не надо.
>просто скопируй префаб
>и его зависимости
>со всеми мета файлами
Подожди, не торопись, я записываю.
Мы точно все еще в прототипе?
>Прототипы на проприетарных техах? А потом их выкинуть? А зачем мы тогда их брали? Таблеточку?
Если не читать по диагонали, то можно прочитать про то что
>И если ты возьмешь юнити/анрил - никакой дядя не придет.
Но ты не можешь такое читать, ведь тебе неприятно.
Остальной троллинг тупостью вообще комментировать не буду.
Покажи мне хоть одну вакансию с прототипированием на питоне. Везде все прототипируют точно также на юнити.
>Ты не представляешь как подобное смешно слышать от программиста.
Если бы.
>написать скрипт-ускорялку
Как ты ускоришь самого себя? Там же надо в комнату зайти, рычаг дернуть, катсцена, потом положить объект, катсцена, рычаг...
Ускорился, проверяй.
>повторюсь - 95% багов софтлочат игру,
У меня странно ведут себя юниты в этот момент, почему нет софт лока? Меня обманули!
Годот восстанавливается даже если синтаксическую ошибку допустил.
Исключение/паника - это самая простая ошибка (чаще это null прилетел) ты ее определишь без перезапуска по дампу (именно поэтому дамп и нужен). А плавающая логическая ошибка - тебе поводит по ускорялке твоей.
>написать скрипт-ускорялку
Видишь, даже ты (настоящий программист) стал понимать что надо написать какой-то тест инструмент/скрипт или даже целую тест сцену где не нужно проходить цепочку действий или ждать.
Неужели хотерлоад решает эту проблему?
>И если ты возьмешь юнити/анрил - никакой дядя не придет.
Я тоже так думал, когда закрывался в комнате один, но Иисус все видит!
Мы говорим про протип -> концепт -> релиз.
Прототип из которого нужно вырезать что-то перед концептом, был не прототипом (у тебя сразу концепт становится новым прототипом. Ты меняешь теху и в итоге концепт стал не рабочим как идея).
>Остальной троллинг тупостью вообще комментировать не буду.
слился, лалка.
>Покажи мне хоть одну вакансию с прототипированием на питоне. Везде все прототипируют точно также на юнити.
Ты вообще о чем?
Прототип это быстрая проверка идея. Ничего нет лучшего чем накидать идею на динамикодресне и потом если она понравится/работает, довести ее до хорошего кода.
Какие еще вакансии? Болеешь? Так забавно когда вам нейронка подсказывает какую-то чепуху из-за нехватки контекста и после вы сидите тупите тут с умным видом
> Потому не страдай хуйней и делай дебаг меню, хотя учитывая что ты там делаешь на гексах
А ну да, сетевые игры на гексах не пишут. Слишком много углов у тайлов.
>fix
>хотя учитывая что ты там делаешь на гексах - мы друг друга вряд ли поймем, потому что у меня баги уровня - клиент отправил не то, сервер послал не туда, другой клиент поломался,
А ну да, сетевые игры на гексах не пишут. Слишком много углов у тайлов для сети.
> Ты вообще о чем?
> Прототип это быстрая проверка идея. Ничего нет лучшего чем накидать идею на динамикодресне
Кто сказал, что это будет быстрее чем со статикой? Написать название типа вместо var какого нибудь точно очень сильно тебя замедляет? А ошибки связанные с динамикой(не в том порядке параметры, конверсия типов, опечатки) - не, нихуя?
> Какие еще вакансии? Болеешь?
Чем болею? Люди в студиях которые профессионально занимаются прототипированием - делают это на юнити. Почему они это делают? Они глупые, а ты умный?
> Так забавно когда вам нейронка подсказывает какую-то чепуху из-за нехватки контекста и после вы сидите тупите тут с умным видом
Болеешь?
>Как ты ускоришь самого себя? Там же надо в комнату зайти, рычаг дернуть, катсцена, потом положить объект, катсцена, рычаг...
Если у тебя настолько слабая связность что ты не управляешь флоу геймплея (твой геймплей локален, то биж нет ни одного способа повлиять на глобальное состояние игры извне, ведь его нет) то у меня плохие новости - потенциальное наличие/отсутствие хотрелоада это самая малая часть твоих будущих проблем.
>У меня странно ведут себя юниты в этот момент, почему нет софт лока?
Потому что у нас разные баги судя по всему, я тоже периодически ловлю условно неинициализированный нуллпоинтер или еще чего нибудь в этом роде, что можно пофиксить за хотрелоад, но починка таких багов у меня отнимает минуты реального времени, так что я их даже не замечаю.
>Годот восстанавливается даже если синтаксическую ошибку допустил.
Он не восстанавливается, он просто не выполняет код дальше, а скрипт срет ошибкой. Отсутствие трайкетч тоже конченая особенность гдс.
>А плавающая логическая ошибка - тебе поводит по ускорялке твоей.
О, ты судя по всему уже столкнулся с цветочками твоего наплевательского отношения к архитектуре и отсутствию контроля. Ягодки будут позднее. Я кстати такого гемора лишен, ведь я контролирую каждый чих игровых обьектов, и даже если я словлю плавающий баг - я могу задампить все состояние игры полностью, до последнего обьекта, ну или только интересующие меня обьекты.
>Видишь, даже ты (настоящий программист) стал понимать что надо написать какой-то тест инструмент/скрипт
Этот инструмент называется дебаг-меню, которое позволяет манипулировать игрой полностью, спавнить любые обьекты и формировать любые ситуации (в рамках потребностей) и я его назвал как решение этой проблемы уже трижды, у тебя контекстное окно настолько короткое?
>Неужели хотерлоад решает эту проблему?
В зависимости от ситуации, но это не киллерфича даже близко. В твоей ситуации - судя по всему хотрелоад и правда незаменим, но проблема не в хотрелоаде точно.
>Кто сказал, что это будет быстрее чем со статикой?
Я сказал и еще легион других программистов.
Потому что прототипирование это быстрый говнокодинг. Питон-лайк требует от тебя минимума за теже "деньги". Ты буквально жонглируешь сущности, думая об идеи, а не об структуре кода или api сомневаюсь, что некоторые вообще об этом думают.
>>1067581
>Чем болею? Люди в студиях которые профессионально занимаются прототипированием - делают это на юнити. Почему они это делают? Они глупые, а ты умный?
Наверное, они это делают, потому что они разработчики на юнити?
А если речь о вакансии, то разработчиков на анриле и юнити будет больше, это очевидно.
Как это помогает индюшатнику? Мобильные-доилки или казики не самая лучшая черта индустрии, чтобы ставить цели идти к кабанчику. Как это помогает тебе в разработке?
Пошла жара.
>О, ты судя по всему уже столкнулся с цветочками твоего наплевательского отношения к архитектуре и отсутствию контроля
Плавающая логическая ошибка - плохая архитектура, записал.
Ты нормально делай и нормально будет, че как сыч гадишь себе во флоу.
>но починка таких багов у меня отнимает минуты реального времени
Ого, я же даже написал об этом в том же посте
> это самая простая ошибка (чаще это null прилетел) ты ее определишь без перезапуска по дампу
> я тоже периодически ловлю условно неинициализированный нуллпоинтер
Так очевидно, у тебя неправильное флоу и вообще пора почистить чакру архитектуры. Не затягивай.
>О, ты судя по всему уже столкнулся с цветочками твоего наплевательского отношения к архитектуре и отсутствию контроля. Ягодки будут позднее.
Я боюсь дальше программировать. Мне периодично сняться баги, они приходят ко мне и бьют меня нуллами по голове. Ты думаешь проблема в архитектуре? Нужно больше контроля? Уже пора начать print'ить каждую строку или еще рано?
>Этот инструмент называется дебаг-меню, которое позволяет манипулировать игрой полностью, спавнить любые обьекты и формировать любые ситуации
Прям в точности как хотрелоад, надо же. Как у вас на юните все интересно.
Как же хочется на каждую игру делать свою дебаг-менюшку. Очень хочется.
> Я сказал
Окей. А я говорю нет.
> и еще легион других программистов.
Покеж.
> Потому что прототипирование это быстрый говнокодинг. Питон-лайк требует от тебя минимума за теже "деньги". Ты буквально жонглируешь сущности, думая об идеи, а не об структуре кода
Бессмысленные слова.
О какой структуре кода я обязан думать со статикой, о которой могу не думать без?
Вот конкретика
>> Написать название типа вместо var какого нибудь точно очень сильно тебя замедляет? А ошибки связанные с динамикой(не в том порядке параметры, конверсия типов, опечатки) - не, нихуя?
Что то не вижу по ней комментариев.
> Наверное, они это делают, потому что они разработчики на юнити?
Получается, срок обучения годоту достаточно долгий, что это будет не выгодно?
Получается, прототипировать лучше сразу на том инструментарии, на котором собираешься делать игру?
Получается даже если фултайм только прототипируешь, все равно не ввгодно годот учить для этого?
> А если речь о вакансии, то разработчиков на анриле и юнити будет больше, это очевидно.
А почему так, кстати?
> Как это помогает индюшатнику?
Чем индюшатник делающий прототип отличается от челика делающего прототип за зп? Кроме того, что челик делающий прототип за зп работает и с другими людьми, от которых учится лучшим практикам.
> Мобильные-доилки или казики не самая лучшая черта индустрии, чтобы ставить цели идти к кабанчику. Как это помогает тебе в разработке?
Ты тут немного уходишь от темы, речь шла про прототипировние, а не казики или доилки.
Компании занимаются прототипированием разных масштабов - от 2-недельных быстрых прототипов в соло, до прототипирования более сложных механик, где может несколько месяцев от нескольких человек уйти на проверку идеи.
Компании важно максимизировать профит, птому если ты занимаешься прототипированием и делаешь это хуже других, медленне - тебя уволят, если нормально - то не уволят.
При этом в рамках компании все лучшие знания и практики шарятся между друг другом, есть общий инструментарий решающий частые задачи - ты видишь его, ты можешь его расширить. Если это эффективно.
Поэтому то, как делают компании - хороший ориентир. Там сидят такие же разрабы, которые между собой конкурируеют на рынке, и лучшие пробиваются.
Ты работаешь на практике в команде профессионалов, которые не занимаются хуйней а добиваются результатов, видишь эффективные решения в разрабокте, видишь неэффективные решения в разработке.
Если ты крутой и можешь сделать лучше чем в среднем в индустрии - то у тебя уже будет открыта своя компания по разработке игр. Если не открыто, то почему ты решил, что лучше знаешь и эффективнее делаешь?
> Мобильные-доилки
Кстати, говоря конкретно о доилках - часто это довольно сложные проекты, намного сложнее типичных инди игр небольших команд, пожтому для прокачки навыков прогркммирования тема.
> Как же хочется на каждую игру делать свою дебаг-менюшку. Очень хочется.
На это уже было отвечено, но ты тактично проигнорил и решил поспорить с другим челом в другом контексте
мимо >>1067561
> Пиздец странно звучит. А на юнити ты не можешь закинуть префаб на сцену в любой момент куда угодно или любой компонент повесить?
Мне лень даже что-то комментить для твоего очереденого троллинга тупостью. Тебе ментально недоступны пока что вещи о которых я говорю и когда я говорю что у меня 95% багов это софтлоки, а остаток это всякие нуллы и прочая мелочь над которой я даже не заморачиваюсь - я не кривлю душой. Мне реально не нужен хотрелоад, я даже плавающие логические баги не ловлю, потому что если ты все контролируешь - у кода нет возможности за твоей спиной сделать что-то не так как это ожидается, если только в коде не была допущена ошибка, которая зачастую не плавает, а живет в конкретной секции потока управления и имеет стабильную воспроизводимость. Так что да, пикрил всегда будет актуален.
>А я говорю нет.
Лидера ответ.
>Покеж.
гугл/ии
>О какой структуре кода я обязан думать со статикой,
Пчел, есть большая вероятность что ты вообще об этом не думаешь. Забей))
>Что то не вижу по ней комментариев.
Потому что тупость, основная нагрузка в прототипирование это сигнатура методов/функций. В какой-то степени js мог быть стать лучшим инструментом для прототипирования.
А еще я вижу что ты не понимаешь базу, ответь какой тип будет тут:
var my_variable_1 = "Утюг" // Какой тип?
var my_variable_2 := &"Утюг" // Какой тип?
сижу как придурок пытаясь запутать нейронку на ответ
>Получается, срок обучения годоту достаточно долгий, что это будет не выгодно?
Нет, получиться что они будут на юнити, а он один на годоте, как сыч в угулу сидеть. И они постоянно будут твердить себе под нос - "зачем мы учили его годоту, если мы все пишем на юнити, ну вот зачем"?
>Получается, прототипировать лучше сразу на том инструментарии, на котором собираешься делать игру?
Ого, молодец.
>Получается даже если фултайм только прототипируешь, все равно не ввгодно годот учить для этого?
Эх, рано похвалил.
>А почему так, кстати?
Потому что популярнее. Разве кто отрицал популярность анрила или юнити? Я говорю что индюшнику от этого ни тепло ни холодно.
>от которых учится лучшим практикам.
Бест-практис три топора.
Слушай ты же этот чел? Да?
>>1067351 →
Я слишком разошелся, забывая что у нас тут растет свой Кодзима, извиняй.
Тебе надо уметь сохранять полное состояние игры. Нормально реализованная ECS должна уметь это из коробки. Либо лог событий, при наличии детерменизма. У товарища Кармака в Q3 весь ввод (от пользователя до сетевых пактеов) проходит через очередь событий которую можно сохранить и приложить к багу. Потом воспроизвести. Я скорее всего в своём двигле так же сделаю.
>>1067569
У тебя у состояния должен быть набор инвариантов, мол если вот это в состоянии X то вот то обязано быть в состоянии Y. Их можно форсить, типа если игрок в состоянии X то заставить всё что должно быть в состоянии Y перейти в него. Или проверять ассертами какими нибудь, чтобы вылавливать раньше.
> тому что у меня баги уровня - клиент отправил не то, сервер послал не туда
Ну это достаточно примитивные проблемы. Если это представляет проблему то с более высокоуровневыми идеями скорее всего беда.
>>1067585
Плавающая логическая ошибка это обычно симптом какой то проблемы где то в другом месте. И обычно это проблема именно кривоватой архитектуры.
>>1067584
Мобилки-дрочилки зачастую технически очень хороши, дрочилка рассчитанная на 10 лет выдрачивания не может себе позволить хуёвую архитектуру, это погрузить её в технический долг, замедление ввода новых фич и быструю смерть. Эта хуйня убила уже несколько ААА, когда вместо реализации роадмапы с контентом команда занимается вычисткой говен в коде. После чего игра закрывается поскольку все свалили.
> гугл/ии
Дебильнее не придумать. Нужна не первая выдача с гугла, а статистика, исследование. Ну окей, я даже вбил в гугл, что дальше?
> Пчел, есть большая вероятность что ты вообще об этом не думаешь. Забей))
Вопрос был вполне конкртеный. Ответ - какой-то глупый переход на личности.
> Потому что тупость, основная нагрузка в прототипирование это сигнатура методов/функций. В какой-то степени js мог быть стать лучшим инструментом для прототипирования.
Ты ебанутый?))))))
То есть
drawCube(var pos, var radius) это пиздец быстро
А drawCube(Vector3 pos, float radius) это пиздец долго?
Что я за хуйню читаю? В прототипировании самое главное - это возможность быстро и легко что-то менять и докручивать, малое число бойлерплейта который надо писать вручную, скорость дебага.
> А еще я вижу что ты не понимаешь базу, ответь какой тип будет тут:
> var my_variable_1 = "Утюг" // Какой тип?
> var my_variable_2 := &"Утюг" // Какой тип?
Я ебу че это за язык? Говнотьский говноскрипт что ли?
> Нет, получиться что они будут на юнити, а он один на годоте, как сыч в угулу сидеть. И они постоянно будут твердить себе под нос - "зачем мы учили его годоту, если мы все пишем на юнити, ну вот зачем"?
Что я опять за хуйню читаю? Кто они? Почему бы всем не перейти на годот для прототипирования, если он лучше? С учетом того, что речь идет о прототипировании - цикл разработки там короткий, а цена проверки не велика.
>основная нагрузка в прототипирование это сигнатура методов/функций
Код в прототипе заведомо идёт на выброс. Нет смысла думать о таком, ты просто хуячишь чтобы как-то работало.
>У тебя у состояния должен быть набор инвариантов, мол если вот это в состоянии X то вот то обязано быть в состоянии Y
Это уже задача интеграционных тестов, но мне как индюку не по карману подобным заниматься.
>Ну это достаточно примитивные проблемы.
Когда как. Если это банально ошибка валидации то и не проблема, а если ошибка скажем так несколько глубже, на уровне гонки например в рамках чего-нибудь, то дело становится несколько интереснее. Я это говорю с позиции человека, который писал свою собственную архитектуру на базе собственных модификаций ecs парадигмы, и до того как более-менее вылизал ядро - порой ловил всякие многопоточные приколы. Если ядро вылизано или используется боевой фреймворк в основе архитектуры - таких проблем по идее не будет (либо они не будут связаны с архитектурой).
> Потому что популярнее. Разве кто отрицал популярность анрила или юнити?
А популярность откуда взялась? Разве при разработке смотрят просто на популярность, а не на эффективность?
> Я говорю что индюшнику от этого ни тепло ни холодно.
Я говорю, что прототипирование в соло в стол и в соло за зп ничем не отличается, кроме финансового обоснования - если в компаниях прототипируют на юнити, а не годоте - скорее всего это косвенное свидетельство, что это эффективнее.
Есть некоторые факторы, которые я считают тут решают и их привел.
Есть мое личное оценочное мнение, которое я тоже привел.
> >от которых учится лучшим практикам.
> Бест-практис три топора.
И что это за ответ? Есть что конкретное возразить?
> Слушай ты же этот чел? Да?
> Я слишком разошелся, забывая что у нас тут растет свой Кодзима, извиняй.
Нет, не этот.
Ты пишешь какую-то херню. Ты прям в коде можешь дернуть собачку, поставить ей статус голода и смотреть - нападёт она или нет на игрока.
Сложные инстансы? Стейт машина? - да все тоже можешь завернуть в фасад какой-то и дернуть одним методом как если бы нажал кнопку.
>> Я слишком разошелся, забывая что у нас тут растет свой Кодзима, извиняй.
>Нет, не этот.
Ну вот, какой смысл, я думал я общаюсь с великим.
>>1067596
> Это уже задача интеграционных тестов, но мне как индюку не по карману подобным заниматься.
Какие тесты вообще? Ты просто в коде пишешь что мол если A в состоянии X а B не в состоянии Y то падаем. Что и в каком состоянии должно быть по идее пишеться в диздоке или его альтернативе. Не по карману тебе точно будет отладка таких проблем.
> на уровне гонки например в рамках чего-нибудь, то дело становится несколько интереснее.
Потому ты пишешь на Расте и/или максимально функционально, с самым минимумом состояния. В гробу я видел гонки дебажить.
>>1067598
Вообще такое должно быть заложено сразу в дизайн. Возможность любой штуке послать событие без жёсткой привязки к вводу игрока или ещё к чему. Заранее думать как это дебажить.
https://youtu.be/T7ECUWQ8QCY
На 1:03 ты
>> var
То есть, ты мне на полном серьезе втираешь тут простыни текста с гугля.
При этом путаешь динамическую типизацию и тайп инфиренс??
>Ты пишешь какую-то херню. Ты прям в коде можешь дернуть собачку, поставить ей статус голода и смотреть - нападёт она или нет на игрока.
Я такое обычно проверяю после того как запрограммирую все системы, которые бы обеспечивали подобное поведение собаки, и она зачастую таки нападает (в подавляющем большинстве случаев), а если не нападает, то я просто отладчиком узнаю почему и подправлю. Но собака очень редко не нападает, потому я опять таки не заморачиваюсь.
>>1067600
>Потому ты пишешь на Расте
А как мне раст против гонки поможет? Его боров блокировки умеет распознавать в компайлтайме и анализировать вероятность попадания в гонку?
>максимально функционально, с самым минимумом состояния.
Это технически невозможно, так или иначе нужно справиться у глобального стейта относительно того на каком свете обьект, чтобы применить к нему действие и при этом удержать обьект в глобальном стейте на момент произведения действия, во избежание нарушения консистентности, а транзакционность воздействий так или иначе реализовать придется, как не минимизируй воздействие. Для решения этой проблемы и чтобы не залазить в дебри графов систем пришлось малость модифицировать ecs, зато в итоге - больше никаких гонок и дедлоков при внедрении многопотока.
Ну трудно же переводить текст с ру на англ и потом еще гуглить его.
Во-первых это псевдоязык и мы можем рассмотреть такую сигнатуру если тебе так проще drawCube(pos, radius), это никак не меняет мой аргумент, ты используешь это лишь чтобы уйти от ответа.
Во-вторых какой нах тайп инференс в сигнатуре метода, сыняра?
> ты мне на полном серьезе втираешь тут простыни текста с гугля
Жду ссылку откуда скопипащено.
Чел мне кажется ты уже по всем фронтам обосрался.
>Какие тесты вообще? Ты просто в коде пишешь что мол если A в состоянии X а B не в состоянии Y то падаем. Что и в каком состоянии должно быть по идее пишеться в диздоке или его альтернативе.
Очень сомнительное решение, это скорее костыль. У меня всем заведует глобальный ecs стейт и он обычно работает точнее автомата калашникова, ну и плюс собираются логи во время работы, падения без реальной ошибки в консоли это в моем случае настолько белая ворона, что я внедрение подобного способа защиты даже не рассматриваю, он мне в голову не приходит.
> Его боров блокировки умеет распознавать в компайлтайме и анализировать вероятность попадания в гонку?
Да, он буквально для этого и создан. Код способный вызвать гонку не скоипилируется. Тебе надо специально и целенаправленно писать код чтобы вызвать гонку. Проблемы может вызвать кривое использование unsafe, которых обычно не особо много. Я в гробу видел тратить своё время на отладку настолько тупых багов. Раст просто хороший компромисс между плюсами и Хаскелем.
От дедлоков на мьютексах не особо помогает только.
>>1067610
Таких проверок в играх обычно достаточно много, защитное программирование идёт во все поля. Я работал и в мобилках, и в АА, сейчас на поддержке одной очень старой онлайн-игры. Обычно лучше падать когда оказывается что мёртвый персонаж пытается двигаться чем дебажить проблему "у нас трупы бегают". В иных местах половина функции может состоять из ассертов, проверяющих что мы находимся в корректном состоянии.
>Чел мне кажется ты уже по всем фронтам обосрался.
Я в акуе с кем я тут сижу.
Первый, малолетка, без ИИ не писавший ни строчки в жизни. Который использует примитивную демагогию и оторванный от реальности. Вероятно тот же, которого несколько раз обоссали в ньюфаг треде.
Другой, уже имеет какой-то опыт пет-разработки, который рассказывает как открыл для себя какое-то овер-логированние всех состояний. Но этот еще адекватен в диалоге, поэтому я ему порекомендую почитать про стейт машину, чтобы не дрочить каждое состояние в игре.
Опять никакой конкретики, какие то растекания мыслию по древу.
> Который использует примитивную демагогию и оторванный от реальности.
Конкретная цитата с демагогией и чем-то оторванным от реальности?
Все мои посты в данной цепочке обсуждения состоят из объективных фактов и предметных заявлений с конкретикой.
> малолетка, без ИИ не писавший ни строчки в жизни
Какая разница кто я, мы обсуждаем конкретные тезисы или конкретных людей? Можем и в таком клбче поговорить. Я игорник. А ты игорник или безыгорник?
> стейт машину, чтобы не дрочить каждое состояние в игре
Ебать тут орнул. "Состояние игры" это не конечный набор ярко выраженных состояний. Состояние игры - это все геймплейно значимые данные присутствующие в игре, именно в таком контексте тот анон об этом говорил и именно такие примеры приводил.
Я заметил если пишешь базворды на русском и слегка их искажаешь, гугл перестает понимать правильно и школота начинает шизофазию писать в ответ.
Помнишь про вчерашний спор про слоенность и DTO (или как я там написал с ошибками). Я потом скопировал свой же текст и реально гугл ИИ написал шизу в ответе, хотя ниже была ссылка на стековерфлоу где все разъясняется.
>Опять никакой конкретики, какие то растекания мыслию по древу.
Ты перешел на демагогию, я тоже. В эти игру можно играть вдвоем.
> Ты перешел на демагогию
Ну так процитируй где лол.
>>1067617
> что происходит тут?
Лошпед сливается.
>Лошпед сливается.
Да ладно, Гпт5 там нормально поясняет. Я думал он не сможешь подобрать из-за русских букв.
>"Состояние игры" это не конечный набор ярко выраженных состояний.
Насколько ярко они должны быть выражены?
Настолько, что ты можешь дать им конкретные названия. Либо настолько, что ты будешь уверен, полагаясь на свой опыт, что для этого разумно заводить стейт машину.
>Настолько, что ты можешь дать им конкретные названия
Все остальные переменные без названия?
Как понять какая тут яркое состояние, а какое нет?
var isAlive
var IS_ALLLIVEEEE_YES_MF
>Либо настолько, что ты будешь уверен, полагаясь на свой опыт, что для этого разумно заводить стейт машину.
Это как с собачкой в детстве - ты должен быть настолько ответственным чтобы тебе позволили завести собачку?
>Либо настолько, что ты будешь уверен, полагаясь на свой опыт, что для этого разумно заводить стейт машину.
Если стейт машина не нужна, не заводи.
Если нужна, заводи.
Че вы тупые какие.
Можно еще мудрости?
>Либо настолько, что ты будешь уверен, полагаясь на свой опыт, что для этого разумно заводить стейт машину.
Семь раз отмерь, один раз - заведи стейт машину!
> Все остальные переменные без названия?
Причем тут переменные? Речь шла о состояниях. О названии состояний.
Открыто, закрыто.
Живой, застаненный, убитый.
Главное меню, настройки, список сохранений, инвентарь, игровой экран.
> Как понять какая тут яркое состояние, а какое нет?
Практиковаться, прикидывать насколько поддерживаемый код получится.
>>1067627
Да. С точки зрения родителей тут вопрос, как они оценят твою ответственность и будут ли проблемы.
Если ты реально очень молод, то ты явно умнее своих сверстников. Намного. Сколько тебе вообще лет?
>Да, он буквально для этого и создан. Код способный вызвать гонку не скоипилируется.
https://doc.rust-lang.org/nomicon/races.html
Судя по всему далеко не всегда. Да и я все равно ненавижу его ублюдский синиаксис js трахнувшего плюсы, так что ну его нафик
>Таких проверок в играх обычно достаточно много, защитное программирование идёт во все поля.
Ну да, ну да. https://youtu.be/0ldiCi80gE4
>Обычно лучше падать когда оказывается что мёртвый персонаж пытается двигаться чем дебажить проблему "у нас трупы бегают"
Я написал способ многопоточной гарантии что пока обьект не является трупом - он не побежит, и что пока он бежит/прыгает/стреляет/все вместе - он не может стать трупом чтобы в корне избежать подобного, похоже на транзакции в бд только без бд в ее оригинальном виде. А если есть хоть малейший риск (отсутствие гарантий == риск) того что такая ситуация наступит - проверки подобного уровня потешны и малоэффективны, ну это мое имхо. Я еще слышал от знакомого, что в играх нормальная практика ставить на блокировки таймаут, чтобы не дедлочилось смертельно, надеюсь ты хотябы не из этих.
ECS в реальных проектах достаточно редкая штука на текущий момент. Некоторый код с которым приходится работать вообще датируется прошлым тысячелетием.
> Судя по всему далеко не всегда.
Ну в большинстве случаев, что я упомянул. Чего достаточно если специально не нарываться. Я уже достаточно в прошлом потратил своего времени на дебаг всяких идиотских ошибок которые могут и должны быть отловлены компилятором. В идеале надо, разумеется, всё писать на Хаскеле, но я пока не настолько джедай.
>ECS в реальных проектах достаточно редкая штука на текущий момент.
Потому что реальный, каноничный ecs - конченый. Его невозможно использовать, если у тебя нет команды, которая будет заниматься маршрутизацией бизнес-логики по системам через компоненты флаги. А однопоточный ecs не может стать многопоточным, потому что if(entity.hascomponent) не работает в многопоточке. Я решил эту проблему, введя в систему многопоточные гарантии has и nothas компонентов, и превратил сущности в круд репозитории key-value бд с rw блокировками, а компоненты стали собственно value. Такой ecs жрать легко даже индюку, а многопоточка становится легкой, бесплатной, без боли и масштабируемой пока ресурсы системы не кончатся. Я думаю что за таким ecs реально будущее, особенно если нанять негров его переписать с шарпа на что-то без gc, а то что есть сейчас как ecs - жрать невозможно.
flecs из коробки с многопоточкой работает и там все спрятано за абстракцию запросов и систем. Для шарпа биндинг есть официальный. Чем тебе flecs не устраивает?
Тем, чем плохи все стандартные ecs системы - факт изменения, добавления, удаления компонента остается без управления, невозможно сделать "вложенный" запрос типа "пока у сущности X есть компонент труп - сущности Y будут начисляться очки", что вынуждает применять компоненты-флаги, у flecs отсутствует немедленное накатывая обновления компонентов, что может привести к гонке состояний (мне не нужен победитель очереди, мне нужна гарантия возымения эффекта здесь и сейчас, так как в противном случае будет видрил отсюда >>1067650 ), взаимодействие между сущностями значительно осложнено. Как не прячь эту хрень за всякими запросами и прочей фигней, но невозможно спрятать факт невозможности обеспечить удержание состояний сущностей для групповых операций над ними.
>А однопоточный ecs не может стать многопоточным, потому что if(entity.hascomponent) не работает в многопоточке
Ну почему? Во-первых у тебя все нужные компоненты должны быть в запросе, соответственно планировщик (у тебя же есть планировщик отслеживающий зависимости?) не может поставить параллельно с такой системой ту что меняет нужные тебе компоненты. Во-вторых, у тебя должны быть запросы с опциональными компонентами и ты просто смотришь в результате, пришло ли с этой этой энтитей что либо или нет. Соответственно нет смысла лезть в глобальное состояние. Всё это обычно есть из коробки в любой нормальной ECS, типа той что в bevy но они заходят с засовыванием всего в ECS слишком далеко.
К слову, я шипил игру на ECS почти десятилетие назад.
>>1067673
Ну есть же реактивные системы, что дёргаются в ответ на изменения. Просто их надо выполнять после систем вносящих изменения, тогда будет на том же кадре. Не знаю как оно в flecs сделано конечно.
Для факта удаления,изменения добавления в flecs есть события, не как что-то отдельное, но тоже сущности. И компонетны тоже сущности. Там поддерживаются отношения и иерархии. Есть каскадные изменения в иерархиях. Все это одинаково работает через системы
>Ну почему? Во-первых у тебя все нужные компоненты должны быть в запросе
Поправка, в запросе, который обрабатывает сущности отдельно. Не вместе. Это к слову о групповых сущностных взаимодействиях
>планировщик (у тебя же есть планировщик отслеживающий зависимости?) не может поставить параллельно с такой системой ту что меняет нужные тебе компоненты
Нет, rw блокировки просто не дадут выполнить одну определенную операцию для конкретного набора компонентов конкретной сущности, пока идет другая write операция над ее компонентами, которые эта операция хочет захватить в read или write. Либо не даст выполнить группу операций над сущностями, пока одну из блокировок не отпустит. В отличии от планировщиков это "реальный" многопоток, в котором одна особо жирная система не повесит выполнение других.
>Во-вторых, у тебя должны быть запросы с опциональными компонентами и ты просто смотришь в результате, пришло ли с этой этой энтитей что либо или нет.
Это все мертвому припарки. Оно вот никак не облегчает основной задачи - избавиться от размазывания кванта бизнеслогики на кучу систем (write, read, очередь систем внутри очереди систем)
>>1067677
Ну окей, в принципе это не главная моя претензия, свои основные претензии я описал выше.
Ну и должен заметить - реальный конфликт и ожидание по блокировкам - занимает в выполнении меньше 1% времени цпу, в массе своей операции read совместно друг с другом работают без блокирований и ожиданий, блокировки покрывают пограничные случаи, изменение так сказать "агрегатных состояний" сущностей, которые очень сильно влияют на то, как и какие операции обрабатывают сущность, а это очень мало на самом деле. И никакого ожидания очередей систем.
P.p.s забыл добавить - я не разделяю операции за признаком того, что они делают с сущностями, операции могут спокойно удалять и добавлять компоненты, которые находятся вне "захваченных" компонентов, я могу прямо в таких операциях производить добавление компонентов, а если уже происходит операция, которая захватила отсутствие добавляемого или присутствие удаляемого компонента - операция просто повиснет и дождется когда другая операция будет выполнена, при такой конфигурации взаимодействия взаимоблокировка невозможна.
Ну а разве не смысл ECS в размазывании всего по многочисленным системам? Вообще кажется твоя система это какой то бардак и хаос. Я как бы понимаю ECS как набор чистых функций применяемых к состоянию игры которые возвращают новое состояние. Ну или как запросы к БД.
>Ну а разве не смысл ECS в размазывании всего по многочисленным системам?
Мои системы тоже многочисленны, просто бонусом дают реальный многопоток из коробки и не требуют планирование графа систем с компонентами-флагами, т.е. не требуют от меня включать мозги и чето там выдумывать как совокупить осла с козлом.
>Вообще кажется твоя система это какой то бардак и хаос.
На самом деле, моя система упраздняет тот бардак и хаос, в который превращается кодовая база реальных ecs проектов, формируя этими как я их называю "контрактами" островки стабильности и гарантий в бесконечном хаосе многопотока, где можно не думая ни о чем попросить систему дать мне осла с козлом и совокупить их здесь и сейчас от и до, не размазывая процесс совокупления по куче систем.
>Ну или как запросы к БД.
Одна беда, ecs в его оригинальном виде не является бд, потому что не дает возможности производить транзакции по отношению к своему состоянию и не может удержать обьекты транзакций от изменения на этапе ее проведения, потому что резко из многопоточной ecs планировщик превратит ее в однопоточную.
У ньюфагов есть такая проблема: изобретать DSL. Если это ООП, то надо чтобы ехали объекты через объекты. Если ECS, то надо чтобы ехали компоненты через системы. В итоге программы пишутся не на на самом языке программирования, а на выдуманном диалекте с использованием композиции объектов/компонентов.
>и не требуют планирование графа систем
Т.е. не гарантируют порядок выполнения? Типа в одном кадре проверка на смерть будет после нанесения урона, в другом до? Нет ничего удивительно в наличии мутных проблем. Ты как бы применяешь последовательный набор функций к состоянию игры, те функции что задевают разные части состояния могут выполняться параллельно. Но ты не можешь выполнять системы трогающие те же части состояния параллельно. Или запускать систему что зависит от результата другой до её выполнения. Позволяет обходиться без всякой мутной хуйни и даже не знать что у тебя где то есть многопоточность. Практически чистая функциональщина.
> ecs в его оригинальном виде не является бд,
Если отстраниться от технических деталей, то по своей сути ECS есть БД, компоненты есть таблицы, а системы есть запросы.
> где можно не думая ни о чем попросить систему дать мне осла с козлом и совокупить их здесь и сейчас от и до
Не совсем понятно что тут от ECS, мог бы обычное ООП дёргать, было бы проще.
> ECS это универсальное решение несуществующей проблемы.
ECS решает проблему когда к нам прибегают дизайнеры и с горящими глазами требуют чтобы сундук убегал от игрока. ECS, если правильно реализована, позволяет дизайнерам сделать это без участия и ведома программистов. Если не изменяет память, так проблема была описана в Evolving your hierarchy, проблема была во время разработки второй Duengon Siege..
Получается нюфаги профессиональнее скуфяндриев, которые код пишут как батя борщ готовит в известном меме? Потом от говнокода такой фон стоит, что обои от стен отклеиваются..
> В итоге программы пишутся не на на самом языке программирования, а на выдуманном диалекте с использованием композиции объектов/компонентов.
Ну а в чём проблема? Именно так и надо делать.
>Нет ничего удивительно в наличии мутных проблем.
Так у меня уже нет мутных проблем. Остался только нормально работающий форк ecs, я же писал об этом. Да, на этапе разработки ловил всякую хрень из-за ошибок в ядре всего этого механизма, сейчас все заебись, часы.
>Т.е. не гарантируют порядок выполнения?
Ты внимательно читал? Мне не нужны гарантии порядка выполнения, у меня есть кое-что получше - гарантия консистетности групповой операции над сущностями, удовлетворяющими контракту этой групповой операции. Я достиг крудоподобной простоты воздействия на стейт ecs, мне просто прилетает событие, которое в отдельном потоке воздействует на стейт ecs от и до и на этом всё. Еще остались системы, но они потеряли то их значение, которое они имели для ecs, оставшись просто прибежищем тик-операций.
>Позволяет обходиться без всякой мутной хуйни и даже не знать что у тебя где то есть многопоточность.
Но плодит другую, еще более мутную и непотребную хуйню, проблематика которой описана выше.
>Если отстраниться от технических деталей, то по своей сути ECS есть БД, компоненты есть таблицы, а системы есть запросы.
Нет транзакций - это не бд а хуйня изпод коня, которой невозможно доверить важные участки бизнес-логики и которая вынуждает пользователя страдать хуйней.
>Не совсем понятно что тут от ECS, мог бы обычное ООП дёргать, было бы проще.
Проще бы не было, потому что ты не понял прикола, повторю еще раз: я могу в любой момент времени и немедленно, взять и гарантировать что в этом многопоточном мире есть какая-то сущность/ти, с такими-то компонентами, и этот набор сущностей будет соответствовать этой гарантии пока я ее не отпущу. При этом, оно не влияет на другие сущности, не блокирует другие сущности, не влияет и не блокирует гарантированные компоненты на других сущностях, и не блокирует не вошедшие в контракт компоненты захваченных контрактом сущностей. Вот это - бд лайк подход.
> ECS в реальных проектах достаточно редкая штука на текущий момент.
Не особо
> Мне не нужны гарантии порядка выполнения
Ну ок. Я только упорно не понимаю где у тебя тут ECS.
> оставшись просто прибежищем тик-операций.
Но игры работают по тикам.
> Нет транзакций
Ты вообще способен понимать написанный текст? Транзакции это технический аспект, я же говорю про суть если полностью абстрагироваться от реализации.
> повторю еще
Я не понимаю зачем так делать. Смысл заёбываться с фиксом мутных проблем если их можно просто не иметь за счёт решений более высокого уровня? Впечатление что ты просто не врубился зачем это всё надо. Основная идея в том что у тебя нет сущностей как таковых, только данные описывающие состояние.
> Мне не нужны гарантии порядка выполнения,
Ты детерминизм как намерен достигать?
>>1067699
Я не особо встречал пока.
>Ну ок. Я только упорно не понимаю где у тебя тут ECS.
Ну, это однопоточный ecs типа leo, который дорос до нормального
>Но игры работают по тикам.
Еще они работают по инпуту юзеров, который может запускать внутри них различные процессы(как это происходит в бэкенде), а тик операции это больше про сериализацию и роллбек.
>Транзакции это технический аспект, я же говорю про суть если полностью абстрагироваться от реализации.
Чел, ты называешь уткой то, что не крякает, не выглядит, не летает как утка, как я по твоему должен реагировать на это?
>Я не понимаю зачем так делать.
Проще, быстрее, понятнее, меньше кода, концентрирование бизнес-процессов в одном, их собственном месте.
>Впечатление что ты просто не врубился зачем это всё надо
Врубился, уже наверное раза 3 написал зачем. У меня ооп код и ecs композиция с многопоточностью. Это значительно ускоряет разработку. И лишает багов по многопоточке, если следовать простейшим правилам. Полностью.
>Ты детерминизм как намерен достигать?
А на кой он мне? У меня пермаментная консистентность стейта в любой ситуации, что бы я не делал. Можно даже сказать что он у меня есть, если инпут будет приходить в одинаковой последовательности - будет детерминизм поведения.
>Еще они работают по инпуту юзеров, который может запускать внутри них различные процессы(как это происходит в бэкенде),
Ну вообще то нет. Ты накапливаешь ввод, скармливаешь симуляции на следующем тике.
>Ну вообще то нет. Ты накапливаешь ввод, скармливаешь симуляции на следующем тике.
Да по разному можно, просто в описанной мной архитектуре - мне это не надо, и тикает только сериализация (и пара обновляшек данных)
Хешмапы есть везде. Не все хешмапы имеют cache locality. А те что имеют у них доступ к элементам O(log n) а не O(1)
>Не все хешмапы имеют cache locality.
Этот шарит, хотел детвору покормить.
Я в гейдеве уже лет 15 и я ни разу не видел такого. Самое сложное что видел это когда игра работает на фкисированных тиках то записывать время прихода событий и отдавать логическому кадру только то что в него попадает по времени.
Обычно в коде хотят максимально прямую, явную и неизменную последовательность обновлений. Истории когда что-то может обновляться в разных порядках на разных кадров приносят в итоге ничего кроме проблем. Не ну можно плясками с бубном добиться сносной работы, но лучше просто найти высокоуровневое решение и не бегать с бубном как дурак.
Хуйня из вебдева как то плохо тут живёт.
>>1067718
Если я буду делать что-то на годоте то я просто напишу логику на расте в виде бинарого плагина.
>Если я буду делать что-то на годоте то я просто напишу логику на расте в виде бинарого плагина.
Это почти тоже самое что и удалять гланды через анус.
>Я в гейдеве уже лет 15 и я ни разу не видел такого.
Если бы я видел в геймдеве нормальный ecs - я бы его не изобретал сам. Но я не вижу ноомального ecs, а тот что есть мне не нравится. Если ты 15 лет ишачил на геймдев галерах где есть сеньор, который "я жрал говно и преисполнился, и ты поешь, не облезешь", то ну как бы не удивительно что ты не видел нового, потому что тебе платят за фичи здесь и сейчас, а не за ресерч нового, потому что рисерч это риски, никому в хуй не упавшие.
>Самое сложное что видел это когда игра работает на фкисированных тиках то записывать время прихода событий и отдавать логическому кадру только то что в него попадает по времени.
Я не прикручивал рендер к своему ecs пока что, он мне в первую очередь нужен как ядро бизнеслогики. Но если я пожелаю это сделать - прикрутить его не составит труда, и рендер по тику просто будет опрашивать компоненты отвечающие за рендер и тянуть с них данные не заботясь о консистентности, потому что она рендеру не нужна, зато она нужна бизнеслогике и некоторым фоновым тяжелым вычислениям. Воздействие физики - уже задача с некоторой звездочкой, но небольшой.
>Хуйня из вебдева как то плохо тут живёт.
Хз, у меня все заебись живёт. Но чтобы жило заебись, пришлось сначала мозгами пошевелить, да. Опять же, не осуждаю, нравится калоедствовать - с моей стороны грех мешать, а ресурсов красиво и под ключ подать технологию у меня пока нет, так что я пока покайфую один, а там посмотрим.
> Но я не вижу ноомального ec
Разумеется нет - поскольку некого абсолютно универсального решения нет и быть не может. Плюс, ты не имеешь понятия какие именно проблемы оно решает поскольку с ними просто пока не встречался..
>Плюс, ты не имеешь понятия какие именно проблемы оно решает поскольку с ними просто пока не встречался..
Мои проблемы - это безопасный и легкий "настоящий" многопоток, это консолидация бизнеслогики, это простота разработки, ну и конечно производительность за счет реального многопотока, а не "планировочного". Заодно я частично решаю те проблемы, которые решает ecs, типа композиции и паралеллизации работы логики, просто своими средствами. Да, обход компонентов уже не так быстр, но с другой стороны - я оптимизирую системы, им больше не нужно раз за разом обходить все грязные компоненты и заниматься прогонкой компонентов-флагов. И мне в нагрузку не идут все минусы ecs. Полный кайф. Потому на твой тейк про
>Разумеется нет - поскольку некого абсолютно универсального решения нет и быть не может.
Я могу сказать одно - может, есть, и будет мочь. Конечно решение тоже не без ньюансов, в первую очередь потому что я его разрабатывал в одно ебало год, оно технически не может быть совершеннее готовых фреймворков разрабатывающихся годами и группами людей, да и честно даже не очень верил что у меня всё получится, хотя по бумаге идея работала, но я считаю что это лучший вариант ecs, с лучшим соотношением ньюансы/возможности.
Ты вообще в курсе чем планировщик занимается? Находит какие системы можно работать параллельно и запускает их параллельно. Внутри системы так же никто не мешает считать всё параллельно. Кажется мне что ты пытаешься делать то от чего отказались ещё в самом начале нулевых, когда в движках стали пытаться делать многпоточность из за бесчётных и нерешаемых проблем. В любом случае ECS у тебя даже не пахнет.
>Находит какие системы можно работать параллельно и запускает их параллельно.
При условии что их можно запустить параллельно. == Трахай себе мозг и все равно ты не получишь 100% ресурсов цпу, потому что системы между собой неравнозначны по нагрузке и не каждую из них можно паралеллить. У тебя иногда будет получаться запускать несколько систем и занимать всё цпу, но только иногда. Я получаю всё, без остатка, я займу все 128++ ядер цпу, если реальная нагрузка на систему будет того требовать, и системы не будут блокировать друг друга на длительные сроки.
>Кажется мне что ты пытаешься делать то от чего отказались ещё в самом начале нулевых, когда в движках стали пытаться делать многпоточность из за бесчётных и нерешаемых проблем.
Ебать ты непробиваемый. Мне в 4 раз написать что у меня больше нет проблем по многопотоку? Их нет. Проблем по многопотоку больше нет. И их не будет. У меня нет ни дедлоков ни гонок. И их не будет. Я не ебу себе мозги оптимизацией работы планировщика. Я просто пишу ооп код и все работает, стабильно, без ошибок, с линейной нагрузкой на цпу. Мне похуй от чего там отказались, у меня на плечах своя голова есть.
>В любом случае ECS у тебя даже не пахнет.
Ну да, называть мой подход ecs это оскорбление для него. Я его так только потому что он крякает, летает и выглядит (но не плавает) как ecs, и чтобы аудиторию в теме не вводить в ступор.
Не нужно ничего находить. На основании зависимостей создается дерево и все.
Например, есть системы A, B, C, и B нужно выполнять после A
тогда будет дерево
A
|-B
C
A и C можно выполнять параллельно. после завершения A можно выполнять все дочерние системы паралелльно и т.д.
>Я как бы понимаю ECS как набор чистых функций применяемых к состоянию игры
Что за мода у ECS-шизов приписывать своей трехбуквенной хуйне целые парадигмы программирования нахуй? Але, дурачки, вы и так можете просто брать и писать код в ФП стиле или использовать композицию вместо наследования, даже если у вас в коде и не пахнет элементами-компонентами-системами. Реально впечатление как будто у ECS фанатиков эта залупа была первым и последним опытом архитектуры и паттернов и они в принципе не способны мыслить вне ее.
>При условии что их можно запустить параллельно.
Системы трогают небольшой объём данных и большую часть запускать параллельно можно без проблем. Зависимости между данными как бы никто не отменял. Смысл тебе дёргать перемещение до того как ты скорость посчитал? Саму возможность так сделать следует считать критическим багом.
> И их не будет.
У тебя нет технических проблем, это лёгкая часть. А вот невоспроизводимые плавающие баги с геймплеем это уже сложная часть.
>Системы трогают небольшой объём данных и большую часть запускать параллельно можно без проблем.
Остальные претензии тактично игнорируем? У меня вообще в массе своей только writable операции, кроме сериализации.
>>1067808
>У тебя нет технических проблем, это лёгкая часть. А вот невоспроизводимые плавающие баги с геймплеем это уже сложная часть.
У меня есть практически математическая гарантия отсутствия гонки или дедлока при соблюдении 2 простых правил - не делать вложенные захватывающие операции, которые захватывают одни и те же данные (будет предупреждение, и вообще 1 активная операция == 1 поток), и не удалять или добавлять компоненты в рамках операции, в контракте которой эти компоненты значатся (что логично), это будет дедлок и будет предупреждение в консоли, и всё. У меня сейчас есть ммошка (пока что в альфе), которая написана на этой архитектуре, я делал длительные нагрузочные тесты, все работает идеально (сейчас). На пикриле, для примера, участок с мини-контрактом, и часть кода использует при выполнении такие миниконтракты если не нужно конфигурировать что-то сложное и просто выполнить какую-то простую операцию. Есть еще вариант с полноценным контрактом-обьектом, который хранит в себе условия для выполнения операции, действия при ошибке, действия при неудовлетворении и т.д., но они у меня все достоточно большие и в скриншот не влезут. Работает всё идеально, писать просто, понимать легко.
>не соответствует действительности
>судя по примерам фидбека
Заходишь в стим, открываешь отзывы, там:
- 50% "мне норм" или "фу, гадость";
- 40% "вот рецепт" или "лайкните меня";
- 5% смешное описание реального опыта игры;
- 4.9% мнящие себя всезнайками дурачки-играчки;
- 0.1% реально полезных отзывах о проблемах игры.
Открываешь обсуждения той же игры, там:
- "игра не запускается, логов не дам, до свидания";
- "эта фича не оч..." -> "рряяяя, пошёл нахер, клоун";
- "оооо, как же я люблю эту игру", "поч?", "не знаю";
- "а давайти досчитаем до миллиона))))";
- "ищу друзей (не старше 13 лет)";
- "стоит купить?", "да", "нет".
И так далее.
Как эти авгиевы конюшни фильтровать? LLMкой?
P.S.
У меня есть потенциальная возможность гонки только при редактировании данных одного и того же компонента из разных потоков, но шанс на то что такая гонка произойдет достаточно маленький, + у меня есть опция просто блокировать редактирование через lock(component), но в 99% случаев редактирование содержиого компонентов происходит только в одних определенных местах.
>но шанс на то что такая гонка произойдет достаточно маленький
Ооо, значит она точно будет в третью фазу луны.
Архитектура это и есть "делоние игор" или программирование в целом. Нет никакой проблемы написать любую отдельную изолированную механику уровня поиска пути или расчета урона и резистов, с этим и ИИ справится. Проблема написать огромную систему, состоящую из сотен таких механик, взаимодействующих между собой, и при примитивном анти-концептуальном подходе "да че сел и пиши это, потом то, а потом еще другое" она не решаема в принципе. Для этого и нужна архитектура, т.е организованный абстрактный подход.
Ты думаешь я этого не знаю, после того что я запилил? Тут просто требуется базовое понимание обычных блокировок, и их применение, пилить safe врапперы для типов у меня сил уже не было, да и это перебор. Просто помнить про такой ньюанс, и производить interlocked операции, и заодно немного рубить фишку в многопотоке, лиибо просто использовать иммутабельные обьекты, вариантов масса. Плюс, свою лепту вносят компонентные гарантии, которые просто не дадут трупу увеличить здоровье либо не дадут сделать обьект трупом, пока идет увеличение здоровья.
>которые просто не дадут трупу увеличить здоровье либо не дадут сделать обьект трупом, пока идет увеличение здоровья.
Ты еще без стейт машины кодишь?
>Архитектура это и есть "делоние игор"
>огромную систему, состоящую из сотен
>организованный абстрактный подход.
Проблема геймдева не в том, чтобы какие-то "сотни механик" могли сидеть в одном проекте. Более того, наиболее успешные игры имеют минимум механик - перегруженные механиками игры валяются там, где валяются забытые всеми RTSки. За очень редким исключением, типа Dwarf Fortress, RimWorld и т.д.
Проблема геймдева в том, чтобы выбрать несколько подходящих механик и насадить на них просто тучу контента, который и будет развлекать игроков. Если игрокам нравятся только механики, то такие игроки наверняка уже на 100% удовлетворены шахматами. Остальным же требуется какой-то контент в игре.
>Проблема геймдева в том, чтобы выбрать несколько подходящих механик и насадить на них просто тучу контента, который и будет развлекать игроков.
Мисайд сожрали и наши поделия сожрут.
Твои будущие проблемы - это не проблемы гонок в софтварном смысле, они гораздо сложнее. В итоге для их решения тебе придётся скатываться к фактической однопоточности. Так как ты пытаешься делать - уже пытались делать в начале нулевых, ничего хорошего из этого не вышло. Два объекта обновляются в разном порядке - получается разное поведение системы в целом и привет.
Не пугай его, а то он так геймдев бросит.
Пусть попробует сделать игру сначала...
>Два объекта обновляются в разном порядке - получается разное поведение системы в целом и привет.
Где привет? Что за бред я прочитал? Если бы был привет - банковские приложения бы не работали, базы данных теряли бы консистентность. Поведение системы реагирует на ввод, какой ввод - такой и вывод. Оно вот ничем не отличается от детерминизма ecs, и в любой момент - ее состояние можно сплющить в консистентное представление, которое хоть и не будет отвечать состоянию системы после сплющивания, и даже частично потеряет актуальность уже в процессе сплющивания - это неважно, получатель так или иначе получит свежее состояние.
>Так как ты пытаешься делать - уже пытались делать в начале нулевых
Если ты про печально известное designed by contract программирование - оно умерло не потому что было плохим, а потому что его придумал какой-то идиот, оно просто было непотребным в том его виде в котором его придумали, слишком переусложненная логика удержания состояния.
>В итоге для их решения тебе придётся скатываться к фактической однопоточности.
Говорю в 5 раз. У меня нет проблем по многопоточке. Нет, мне не придется скатываться к однопоточке, потому что компоненты и так меняются в однопоточке, я просто сужаю воронку заблокированных для изменения обьектов, а увеличение количества потоков и разделение на виды блокировок (множественное чтение/монопольная запись) позволяет единовременно менять очень много компонентов и сущностей в их разных узких преимущественно read воронках, и иметь линейную нагрузку на проц.
Кста, кто как обзывается - тот сам так называется. Ну или показывай игры.
>геймдев бросит.
Сложно бросить то, чего не начинал. Это же шиз-движкопися, который даже не понимает что такое шедулер и зачем он нужен.
Да, в том посте ты ясно дал понять, что не понимаешь что это такое и зачем оно нужно.
>Да, в том посте ты ясно дал понять, что не понимаешь что это такое и зачем оно нужно.
Не, в том посте я всего-то указал что шедулер не панацея. А если ты этого понять не в состоянии - хороший вопрос кто из нас двоих не понимает что такое шедулер и зачем он нужен. Думается мне что не я.
Чел, под "механикой" там подразумевается абсолютно любой код, который ты пишешь в проект, от менюшек до логики апдейтов: все это часть игры и все должно взаимодействовать друг с другом, быть расширяемым и понятным, а не кучей написанного абы как неподдерживаемого говнокода. Пиздец конечно вы тут кодеры мамкины собрались, реально что ли нужно прожевывать эти вещи, очевидные любому человеку с парой лет опыта коммерческой разработки?
Зато я способен видеть когда у человека кончились аргументы. Например я вижу как они кончились у тебя.
>под "механикой" там подразумевается ... код менюшек
Стоп, ты GUIвые компоненты в свою ECSину заворачиваешь?
Дело в том, что ты расписываешь выдуманные проблемы. Все эти проблемы существуют только потому, что ты не понимаешь механизма работы системы.
Не, это невыдуманные проблемы, потому что они не догружают цпу.
Палю тебе годноту, целый системный язык zig ориентированный на данные, с бесплатным интеропом над Си, где автор потеет чтобы уложить каждый байтик.
https://www.youtube.com/watch?v=IroPQ150F6c
Как говорится из говна да в дристанину. Мне не нужен каждый байтик, я как ни странно не байтоеб(иначе бы не юзал шарп). Мне нужно чтобы цпу линейно нагружался, чтобы работал многопоток, работал честно, без шаманизма с шедулером. Как это на бэкенде. Я свой фреймворк еще возможно в асинк/эвейт переведу, чтобы вообще было охуенно. А самое главное, самое важное, то ради чего все это затевалось - чтобы это было просто, настолько просто, чтобы справился любой дебил. Два правила, иммутабельные поля компонентов - и всё. Можешь писать что угодно, как угодно, формировать любые условия для работы твоего ооп кода и система их сделает специально для тебя, пока твой код выполняется. Чтобы писать игры с многопотоком быстрее, чтобы не иметь головняка с ручными блокировками, заводящими игру в дедлоки. И разумеется чтобы не дробить бизнеслогику не бесконечные компоненты флаги, которые позволяют системам видеть произошедшее с сущностью и применять к ней эффект.
Очевидно, что ты не понимаешь, как работает шедулер и это бредишь.
Я говорит, хочу производительность, но жрать буду говно с виртмашиной.
Вообще-то JIT может быть потенциально быстрее AOT. НЕ везде, не всегда, но за счет лучшей оптимизации непосредственно в рантайме. Например тот же кеш процессора улучшить. Потому что AOT компилятор в душе не ебет какие будут данные в рантайме.
мимо
Ну ваще в первую очередь я хотел реализацию концепции. Я приверженец идеи что архитектура > оптимизация, потому что оптимизацию если что можно подтянуть, (в случае успеха - вообще нанять негров которые перепишут все на раст/зиг/хуиг с кучей оптимизаций, доступных на языках с управлением памятью), потому я написал всё на том языке, который я лучше всего знаю, написал относительно быстро, с удобными мне инструментами, специфичными для этого языка. Потому что жизнь не бесконечна, я же не шизик писать десять лет архитектуру, и так и не сделать ни одной игры. А так, годик на архитектуру, полгодика на разработку ммошки на этой архитектуре (которая уже в альфе и работает, и она же на пикриле), обкатка, интегрируемость, сглаживание углов и в бой, писать игру/игры мечты.
Для гейм лупа JIT выглядит оправданым. Потому что кадый кадр процессор один и тот же код выполняет на больших объемах данных. Не всяких JIT хорошо оптимизирует, но мы же о CLR говорим. Но всякие там колизии и события могут жестко пососать у AOT
>Вообще-то JIT может быть потенциально быстрее AOT. НЕ везде, не всегда, но за счет лучшей оптимизации непосредственно в рантайме.
Ох эта древняя мантра про спекулятивную оптимизацию.
Любой выпук про "оптимизацию" без приложенных рядом бенчмарков спекулятивен и по сути является просто чей-то шизоидной фантазией. Включая твой предыдущий про "виртмашина непроизводительна".
Неделю с ассетами ебусь, нечего постить. Даже за код не брался.
Надо быть совсем уже лоу скиллом чтобы не понимать какие накладные расходы дает виртуальная машины с ГЦ. Так что поводил тебе бенчмарками по твоим ламерским губам.
>пик
Ты по всей доске с этой шлаковиной бегаешь, надеюсь на тебя выйдет DMCA и научит любит чужой интеллектуальный труд.
Пришлось добавлять некие мета-форматы для рендертаргетов поскольку на АМД под линуксом банальный D24_S8 не работает. Теперь приходится выбирать реальный формат исходя из возможностей железа.
>>1068004
Нагрузка ВМ сильно преувеличена. У тебя даже в играх под ДОС из начала 90х уже были виртуальные машины, Flashback тому пример если не изменяет память. Даже квейках были ВМки, в Q1 был QuakeC. А это ёбаные образцы оптимизации.
Какой смысл кидать код, который ничего не делает?
Типа смотрите я могу создавать енамы в расте?
>Смешал в кучу vm и gc.
Давно шарпы без гц? Лалка.
Есть вообще где-то кейс, где есть ВМ но нет сборки мусора? Это же какая-то ультра экзотика в каком-нибудь специфичном ембеддед с ультрастранным процессором понимающий байткод этой херни, я даже представить не могу
Есть . wasm Стековая vm без gc
Голенг как пример gc без vm
>Есть . wasm Стековая vm без gc
ВМ это просто транслятор байткода, это значит что даже ты сейчас на коленки можешь ВМ написать на расте, поэтому экзотических примером может быть масса, я говорил про полноценные, популярные языки, а не вот ваши эти "языки-среды". Наверняка можно принести какие-то ЧПУ языки с байткодом для какого-нибудь станка.
>Голенг как пример gc без vm
Понятно что это две разные природы, это ламер возмутился гц и vm, там речь была в контексте дотнета, а он высосал из пальца противоречия.
В чем я не прав, что сказал что ВМ и ГЦ несут доп нагрузку? Я вообще не говорил что они связаны, это перечисление, что вм несет оверхед и гц несет ЕЩЕ оверхед.
Сижу тут ламерскую шизу разбираю, игры не пишу.
смотрите, смотрите я создал енамы на расте и переложил данные "из сюда в туда", яже теперь такой же программист как и вы? да?
Но ты сам "ламерскую шизу" написал. Как будто VM в сишорпе сама память выделяет, а не ты в коде. Как из твоих
"соображений" следует что у VM всегда оверхед? Ты можешь на С++ память дрочить в геймлупе. Сишарпер может аллоцировать все в самом начале. Как на плюсах надо с умом писать, та и на сишорпе.
>Как будто VM в сишорпе сама память выделяет
В этом и шиза, что ты это сам придумал. Я такое не писал, ты тупо додумал и возмутился.
Как связаны гц и виртуальная машина, хай скилл ты наш?)
А бенчмарк нужен да, циклы с ифами крутить один и тот же машинный код будет фактически, оверхед будет там где это требуется - в 2% перформанса которые будет жрать бизнес логика в некоторых местах.
У C# нет VM, Дотнетовский код компилируется в код нативный при запуске.
>Ты по всей доске с этой шлаковиной бегаешь
Только если надо пруфануть игорность, а то вы все на словах лев игорный а на деле хуй безигорный
>DMCA
Фан игра, так что на право мне похую, я же не продаю ее.
Нет. Игры нет. Я хуй знает, уже столько всего перепробовал с волосами намутить для персонажа и всё пиздец. Ебальце исправил, но причёска оказалась настолько более ёбнутой, что просто пиздец. Придётся делать фулл стилизацию, наверное, с веретенообразными прядями.
https://en.wikipedia.org/wiki/Common_Language_Runtime
The Common Language Runtime (CLR), the virtual machine component of Microsoft .NET Framework, manages the execution of .NET
Потому что чтобы достигнуть состояния очумелых ручек (mad skills) в художествах, нужно много дней дрочить одни и те же действия. Это тебе не скрипт для годота написать через гпт
Да хуйня эти художества, 90% всего можно нейросетью сделать. Меня просто не устраивает форма, наверное потому что нет какого-то видения на счёт причёски. Мне-то обычно похуй на волосы, а тут надо решить, какие они будут. В итоге каждый вариант забракован, потому что не понравился.
> какого-то видения
В этом суть и сруть мад скилза в художествах. Чтобы было видение? нужно дохуя вариантов через свои руки пропустить. С нейронками и чужими асетами ты всегда будешь жрать что дают, а не что ты чувствуешь.
>нужно дохуя вариантов через свои руки пропустить
буквально весь смысл нейронок. человеки ничем от нейронок не отличаются по сути, только тем, что воняют, когда гниют
Хуйня полная. Ну был бы у меня артист на подхвате - я бы его задрочил словами "всё хуйня, Миша, давай по-новой". Тут как раз в том и дело, что "как чувствуешь" нет. Я ебу, какая там причёска должна быть? Делаю одну, понимаю, что хуйня. Делаю другую. Нейронки тут помогают нихуёво, потому что можно посмотреть пару сотен вариантов заранее и отбросить раньше. Артист здесь вообще ничем не поможет. Разве что какой-нибудь концепт-артист, который нахурил бы мне миллиард вариантов в нейронке, а я выбрал. Но это я и сам могу, там много ума не надо.
Но игорь мячты то у тебя, а не у нейронки. Жрать что дают приемлемо когда работаешь на дядю за бабло. Кода работаешь ради мечты, это заставляет грустить.
Ты читать умеешь? Без выдрочки не будет видения. Это база базовая базища любого творчества. Все хуйдожники учатся копированием крутанов, чтобы просто видеть что они хотят сотворить.
А я тебе говорю, что это хуйня. Ну скопировал бы мне артист мегаохуенный стиль какого-то "крутана". А я такой "не, хуйня. Мне не нравится". И всё на этом. Выдрочка здесь не решает вообще ничего. Всех этих "крутанов" сто раз на стоках скопировали, если бы мне хоть что-то зашло, я бы уже взял и подогнал под свою модель. Но ни-ху-я. Да и нейронки все эти арты видели, всё могут сгенерить.
Да бля.. Я тебе про Фому а ты про Ерему..
Я говорю что без вариантов самому скил дрочить. Что нейронка что хуйдожник заставят жрать то что они могут, а не то что ты хочешь. Это экзистенциальное различие. Понимаешь? Даже когда нейронки захватят всю работу, это не избавит ЛИЧНО ТЕБЯ от мечты, от зуда творчества.
Чтобы у тебя было видение, тебе придется дрочить свой скилз. Ты не можешь получить свое видение, просто роля кнопку КРЕАТЕ у нейронки. Это как пытаться говорить на иностранном языке просто изучая по книгам.
Ты или не понимаешь, о чём я говорю, или не хочешь понимать. Скилл дрочить не нужно. Нейросети делают всё, что мне нужно и даже больше. А творчества в дрочении треугольников меньше, чем в написании постов сюда.
И да, я легко могу получить нужный мне стиль от нейронки. Я просто не могу решить, какой именно мне нужен, потому что полно взаимоисключающих пунктов в том, что я хочу видеть. В итоге запилю какое-нибудь каре и хуй бы с ним. Не стоит оно столько внимания.
>какие накладные расходы дает виртуальная машины с ГЦ
Никаких, потому что "расходов" в вакууме не существует, так как не существует программ в вакууме. Твои маняфантазии про производительность значения не имеют, пока программа не упрется конкретно в эти самые пределы ВМ, только тогда у тебя появляется право забенчмаркать и указать "ну все, вот тут ВМ срет мне в штаны, дальше никак". И если бы ты не был диванным необразованным чушком с околонулевым опытом профессиональной(или даже непрофессиональной) оптимизации, то знал бы, что в реальном мире для 99.99% реальных программ такая ситуация в принципе невообразима.
Естественно при таком подходе креативный орган просто атрофируется. Потом вообще на кубы перейдешь ибо "Не стоит оно столько внимания"
Это кабаний подход делигировать работу, потому что у кабана цель функционирующий бизнес, а не то как продукт будет выглядеть в конечном итоге.
Художнику же важен каждый волос на лобке
Нафиг ты рот вообще открываешь
https://www.techempower.com/benchmarks/#section=data-r23
изучай
Даун даже не понял о чем я говорю, пиздец конечно тут одаренные сидят.
Игра на кубах позволяет самое большое количество творчества, наверное, в играх в принципе. Майн не зря настолько популярен. Так что переход на кубы не обязательно что-то плохое.
Шизик, может лучше ты сам изучишь эти таблички(для начала пойми, что там измеряется и зачем, уже должно стать стыдно за свою тупость на этом этапе), и увидишь, что там везде в топах по перформансу JS/Java/Python фреймворки(которые как все знают, широко известны тем, что в них нет ВМ, рантайма и GC)?
> что там везде в топах по перформансу JS/Java/Python фреймворки
Ппц ты реально болен.
Это последний тред на доске, а ты его знакрыть хочешь. Охуел?
>исправил
Негритяночку делаешь - угадал?
Рекомендации по лицу:
- глаза и уши опусти чуть пониже;
- расширь нос снизу (крылья ноздрей);
- добавь чёткий горбик-границу на губы;
- расширь лоб, чтобы был более плоским.
На счёт век трудно сказать без глазных яблок.
>Игры нет
Начинай делать. Черты лица незаметны в геймплее.
>Негритяночку делаешь
А то. Всё по современным стандартам. На самом деле просто шейдинг в блендере неправильный, так что не заморачивался и просто забил хуй на текстуры. Да их ещё и допиливать надо, так что вообще не важно. По расположению глаз и ушей относительно лба, как и по размеру лба - тебя наебала сильно неправильная линия роста волос и ракурс камеры. Я не замоделил адекватный меш скальпа, так что волосы растут каждый раз из новых позиций. По выпуклости губ тебя наебал шейдинг, скорее всего. Там всё есть. А ноздри увеличивать не хочу, я считаю по носу проебал только сужения-расширения на переносице, но это уже такое, для тру-артистов.
>Черты лица незаметны в геймплее
Да я знаю. У меня кодовая база из старых проектов большая, так что по моим ощущениям игра готова процентов на сорок даже до начала. Тем более, что никаких технически сложных вещей в ней не будет, в этот раз это не кодовый монстр, а поглотитель ассетов.
>ракурс камеры
И на каком скриншоте правильный ракурс камеры?
Это очень частая ошибка новичка - делать большое лицо и маленький лоб. Говорят, что эта ошибка возникает из-за того, что наш мозг эволюционировал фокусироваться на деталях лица и игнорировать всё остальное - поэтому начинающий художник неосознанно увеличивает черты лица, а лоб как бы игнорирует. Если посмотреть на портретные рисунки новичков, то там почти всегда эта ошибка. В реальности человеческий череп имеет большой лоб, чтобы уместить большой мозг, а маленький/низкий лоб - это признак недоразвитости, как у древних предков человека, у которых был маленький мозг. Твоя задача как художника - уловить и передать эти детали, даже если мало кто из зрителей их осознаёт, потому что их мозги автоматически и моментально считывают все эти детали и создают определённое ощущение от картинки. Тем более если ты пытаешься работать в реалистичном или близком к реалистичному стиле, но даже у совсем деформированных мультяшек такие детали должны учитываться (у мультяшек зачастую очень большие глаза, но эти глаза сдвинуты вниз, чтобы лоб имел нормальные для человека пропорции, иначе получается жуткий монстр).
Ничего страшного - учись, работай над ошибками и со временем всё получится.
Ты совсем не замечаешь?
Замечаю, что весь список того, что ты перечислял, свёлся к двум вещам. Во-первых, ты почему-то считаешь, что у меня дистанция от глаза до брови в три раза больше, чем на твоём референсе. И что ты почему-то считаешь, что каждое человеческое лицо должно идеально подходить под твой референс. Может, потом и заморфлю. Мне похуй, я не артист, повторюсь, вся эта анатомия и пропорции просто нахуй идут. Я чисто по фану морфил части тела, ту же ключицу выдавил больше, чем мне реф предлагал. Я вот так вот хочу. Хотя сейчас пилю причёску даже не на финальной версии головы, только заметил. Ключицы нет нихуя.
>>1068183
Про эльфийских реднеков, которые жрут самогон в три горла, но всё равно живут вечно. Что-то вроде Shedule 1, но про самогон. Будет ультраимбовый гномий грибной, но это уже эндгейм контент.
>Я пишу (написал) систему которая может масштабироваться пока не упрется в потолок производительности цпу по всем ядрам. Сама по себе, ее архитектура выстроена так чтобы масштабирование могло происходить потенциально бесконечно.
Какой у тебя CPU, сколько ядер? Intel/AMD? 3D cache?
Любую новую систему, которая претендует на статус оптимизированной, нужно тестировать на широком наборе возможного железа, от ноутбучных 2 ядер до топовых 16-ядерных 32-поточных AMD с 3D кэшем.
Иначе рискуешь пукнуть и обмякнуть...
>Почти пол-мегабайта кода
Посмотри GDExtension в Godot.
>Какой у тебя CPU, сколько ядер? Intel/AMD? 3D cache?
Пока что тестил на помойном говне типа i3/i5 из 3-5-8 поколений и на ноутбучном ryzen 7 6800h, вполне себе нормально лохматит.
>Любую новую систему, которая претендует на статус оптимизированной.
Эта система пока что претендует только на статус хорошо и просто утилизирующей все ядра конечной машины, ибо под капотом хоть и применяются немало оптимизаций, но язык с gc, ненужные аллокации на контракты и прочая нагрузка с которой мне пока что впадлу разбираться дает свою порочную нагрузку которую трудновато сосчитать. Было бы неплохо, если бы появился супермен, которому бы не впадлу было перелопатить фреймворк сверху донизу, сделать всё максимально без аллокаций и оптимизированно, но супермена такого нет а я этим займусь только если преуспею как геймдев, на данном же этапе - производительность меня полностью устраивает.
Как раз пилю шейдеры. Пятьсот мегабайт на один буфер. Есть возможность ужать это минимум вдвое, но зачем?
P.S.
Ну и сервер с игрой крутится на одноядерном ксеоне на 2.6 ггц, потребление цпу не выходит за рамки 10% даже на 10 единовременных клиентах, показатель так себе конечно, но синтетика на рязани и интуле меня полностью устроила и с тех пор я не проверял нигде. Да че уж, последний критикал багфикс был 3 недели назад, какие тут тесты на мультиплатформе
На интеграшке с N100 заживёт? У меня в каком то смысле минимальный спек чтобы хотя бы 30 фпс было.
https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BD%D0%B4%D1%80%D0%BE%D0%BC_%D0%BD%D0%B5%D0%BF%D1%80%D0%B8%D1%8F%D1%82%D0%B8%D1%8F_%D1%87%D1%83%D0%B6%D0%BE%D0%B9_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8
Заживёт, но плохо. В оригинале оно тестировалось вообще в браузере на three.js, но в сильно упрощённом виде.
Лично я про вычислительный шейдер в юнити. С чего бы ему не жить на интеграшке? Поддержка шейдеров есть, но сам чип слабый пиздец, так что жить будет плохо, но недолго.
>вычислительный шейдер в юнити
А что, в юнити завезли Vulkan? Или это на DX12?
А в чем вообще комический эффект, зачем оно надо? Игра которую ты делаешь вполне будет отлично работать и в одном потоке вообще без заморочек, там нет смысла даже в многопотоке - оверзед на шедулер дороже будет. Или обкатываешь на ней, чтобы потом для чего то более грандиозного заюзать?
>зачем оно надо
Многопоток без геморроя. Можешь почитать полноценно участок срача где я более менее детализировал по ряду аспектов суть решения
>>1067667
>>1067682
>>1067683
>>1067684
>>1067697
>>1067783
>>1067811
>>1067863
если надо - могу сам проект кинуть он опенсорс (но предупреждаю - говнокод)
>Игра которую ты делаешь вполне будет отлично работать и в одном потоке вообще без заморочек
Я пилю ммо, и вообще мне нравятся игры с авторитаркой, а в авторитарке метовый вариант это комната == поток. Я хочу уйти от этого и перейти на бэкенд+бд модель, но без бд в ее изначальном понимании, просто куча мини-бд сущностей. Потенциально это может дать возможность всунуть в одну комнату десятки тысяч человек с кучей функционала, и при этом не охуеть от сложности по многопотоку (сущностно-компонентная датамодель + ооп код бизнеслогики с фиксацией на конкретных сущностях)
>Или обкатываешь на ней, чтобы потом для чего то более грандиозного заюзать?
Ну это одна из целей, хочу запилить прям полноценную риалтайм стратегию, где в фоне будет жить полноценный город, интерактивный и с настоящей реализацией эффекта бабочки, но это скорее манямечта. На данном этапе я просто в кайф сделал ммо сервачок с простой как палка и рабочей многопоточкой, где не комната == поток, а каждый пакет от клиента == поток(задача в пуле потоков).
>в юнити завезли Vulkan?
Сто лет, как уже. Но я на DX11 пилю.
>>1068287
Поздно следить за тем, чего нет.
>Многопоток без геморроя.
Это уже какой-то анекдот...
>Сап, аноны, вставил дилдо - выпала кишка. ЧЯДНТ?
>А не нужно было его туда вставлять.
>А я 2 года потратил на разработку личного дилдо, и теперь прыгаю на нём без остановки - геморроя нет!
>Но зачем тебе дилдо?
>Как это - зачем? Дилдо без геморроя!
>Это уже какой-то анекдот...
Был анекдот, первыми этот анекдот починили в бэкенде, сейчас вот и в геймдеве больше не анекдот. Шутки юмора про дилдо заканчиваются там, где перестает хватать мощи 1 ядра. А добиться такой ситуации на самом деле не очень сложно, сталкер тому идеальное подтверждение. И затем начинаются судорожные попытки выносить вычисления в поток, это помогает, но на какое-то время, потому что дальше наступает момент, когда ядра перестает хватать уже на бизнес-логику. И тут в игру вступает арм, где ядра в отдельности еще кринжовее...
>где ядра в отдельности еще кринжовее...
У архитектуры фон Неймана ядра кринжовые.
Вот в головном мозге около 86 миллиардов ядер, у каждого в среднем 7000 соединений, каждое из них является ячейкой памяти со сложным поведением. Организация нетривиальная и типов ядер много. Но именно такая машина породила кринжовые ядра в кремниевом субстрате. Вопрос времени, когда она сумеет воспроизвести себя нормально, без кринжа наподобие "память отдельно, процессор отдельно".
А до тех пор и одного ядра достаточно...
Ну, кому достаточно, а мне - недостаточно. Желаю видеть как игра будет честно сьедать все цпу, а уж куда применить - я найду. В крайнем случае - серверок авторитарный запилю такой, чтобы цпу нормально кушал.
> Многопоток без геморроя. Можешь почитать полноценно участок срача где я более менее детализировал по ряду аспектов суть решения
Это понятно, вопрос то в том, зачем твоей игре это?
> оверзед на шедулер дороже будет
Какая к хуям нагрузка? Всё что он делает - строит граф зависимостей и считает что может быть выполнено параллельно. Ты должен программировать на БК-0010 чтобы это вызывало хоть какую то измеримую нагрузку или оверхед.
>>1068296
> Я пилю ммо
На каком то достаточно старом фанфесте разработчики Eve Online (единственный игры где может быть тысячи игроков в одной "комнате") говорил что они перешли к более-менее классической ECS под капотом.
>Это понятно, вопрос то в том, зачем твоей игре это?
Ммо-сервер, я же писал. Возможно в будущем запилю что-то еще более нагруженное и локальное, есть идея под такой проект.
>>1068326
>классической ECS
Я с классическим ecsником уже поговорил >>1068296
в посте реплаи моих доводов. К тому же - ecs имеет тенденцию к страшному усложнению кодовой базы в динамике, с которой в одно ебло совладать при сколько-либо сложном геймплее близко к невозможному, что для меня(инди) страшнее любых им приносимых бенефитов. Мне нужно проще, я хочу ооп код и не хочу руками дрочить блокировки. И я этого добился.
>Желаю видеть как игра будет честно сьедать все цпу
Может, лучше сделать так, чтобы игра НЕ съедала ни одного ядра ЦПУ?
Т.е. делать оптимизации уровня геймплея (не допускать тысячу игроков в одной "комнате").
>>1068326
>единственный игры где может быть тысячи игроков в одной "комнате"
И эти тысячи игроков будут видеть 1 кадр в две минуты, стреляя по внутреннему чутью.
Я много читал про Eve Online - это не та игра, на которую стоит кому-либо равняться.
Они просто время замедляют когда игроков становится несколько тысяч. Пишут что у них есть работающие идеи как сделать всё без замедления, мол упор у них не в симуляции, а в отправке сообщений. Раньше было заметно хуже.
> Я много читал про Eve Online - это не та игра, на которую стоит кому-либо равняться.
Технически ничего равного нет и не планируется.
>Может, лучше сделать так, чтобы игра НЕ съедала ни одного ядра ЦПУ?
Может и лучше, но не в нашей вселенной. И да, моя игра будет надкусывать либо все ядра сразу, либо по степени загруженности, зависит от реализации тредпула.
>Т.е. делать оптимизации уровня геймплея
== терпи блеать. Нет уж, сам терпи, а я возьму всё. У амазона на серверах щас 128 ядерные арм, я уверен что это наше очень скорое будущее, хотя сожрать уже ставшие стандартом восьмиядерники тоже нормас.
>И эти тысячи игроков будут видеть 1 кадр в две минуты, стреляя по внутреннему чутью
Ну, это видимо тот самый ecs, который эти товарищи не могут или не умеют нормально паралеллить. А может валидация слишком сложная или сеть слишком прожорливая. Нет, у меня принцип работы вот ничем не отличается от стандартных риалтаймовых сессионок-ммошек, типа танков, линейки и любых других из этой оперы.
>я уверен что это наше очень скорое будущее
Между тем нвидия начинает заново производить видеокарты на два поколения назад.
>Они просто время замедляют
Да. 1 кадр (обновление игры) в 2 минуты. Хороший тамада и конкурсы интересные.
>Технически ничего равного нет и не планируется.
Суть Eve Online в разборках между ИРЛ кланами задротов, которые дрочат на свои кораблики по 10 лет, вычисляя стратегии развития в таблицах Excel на десять лет вперёд. Живут ИРЛ по расписанию событий кланов в игре, заводя будильник и просыпаясь к рейду в игре. Это не игра, а какой-то культ задротов - и поэтому ничего интересного с технической точки зрения в ней нет. Ньюфагов там ждёт seal clubbing, боль и потенциальное обращение в культ.
Ты не сможешь повторить Eve Online не из-за какой-то магической супер-технологии. Даже будь у тебя все оригинальные исходники Eve Online, неограниченные сервера и деньги - ты бы не смог повторить её. Потому что чтобы повторить Eve Online, нужно повторить собравшееся вокруг неё сообщество задротов, а они все в Eve Online рейдят друг другу жопы. Если сдохнет оригинальная Eve Online, они поднимут себе пиратский сервер на костылях и говнокоде...
>>1068339
>терпи блеать. Нет уж, сам терпи, а я возьму всё
Количество не равно качеству. Даже в буллет хеллах есть определённое количество пуль, после которого геймплей перестаёт работать правильно - не из-за производительности, а потому что пуль слишком много для игрока. Ты своим желанием напихать десятки тысяч игроков в одну локацию забываешь о том, чем эти игроки вообще должны заниматься в твоей игре - просто стоять в комнате и радоваться тому, что локальный чат на экране прокручивается со скоростью сотен сообщений в секунду? Вот ответить чисто для себя - нафига игрокам собираться в таком количестве в одном месте? Кроме каких-нибудь праздников, когда толпа спамит один смайлик пару минут и потом быстро рассасывается. Геймплей опиши, в котором тебе нужно десятки тысяч реальных игроков, находящихся на одном экране друг у друга в реальном времени.
>Вот ответить чисто для себя - нафига игрокам собираться в таком количестве в одном месте?
Это не обязательно могут быть игроки, это может быть обьемный функционал у этих самых игроков. Например - разрушаемость, большое количество интерактивных обьектов и всё в таком духе.
>>1068338
>Eve Online
Там и так игровой тик в секунду. Когда много игроков это тоже слайдшоу, но чтобы железо у них не сдохло.
В общем, я понимаю что ты шиз и страдаешь фигней, но основную оптимизацию делают в процессе геймдизайна, то есть челики могут позволить растянуть вычисления раз в секунду, а ты своей игре сможешь сделать "пинг" в одну секунду?
>Потому что чтобы повторить Eve Online
Я исключительно про техническую сторону.
>>1068379
>но чтобы железо у них не сдохло.
У них проблема что они отсылают обновления раз в секунду. В девблогах пишут что сделали новую систему сообщений которая лишена этих проблем - и на ней пара тысяч игроков действуют без задержек. Но до ввода в прод ещё долго.
> В девблогах пишут что сделали новую систему сообщений которая лишена этих проблем
Ппц, целый девблог на то что они смогли снизить тикрейт с 1000мс до условного 100мс? Потому что уговорили акционеров расширить парк серверов? Современных зумеров уже не устраивает что кнопка стрельбы "лагает", проходя половину перезарядки перед выстрелом?
На самом деле я не знаю что там, но вероятно просто реально снизили тикрейт. За 20 лет как бы уже пора. Жалко что игра умерла еще 15 лет назад.
Они обосновывали такой тикрейт тем, что он нивелирует разный пинг у игроков для пвп. Когда в реале просто экономия.
Ты бы еще 3.5 гпт бы попросил тебе навайбкодить. Я за доступ к нормальным вайбкод нейронкам бабки башляю.
Мы же так всегда делаем, никогда не проверяем для другой платформы игру, особенно когда впервые делаем. Зачем? Да?
думаю если эта игра и существует, то она масштабов этой самой проверки. то есть хеллоуворлд
Я не использовал слово "тикрейт", алё. Прочитай всё с начала, по слогам.
>>1068402
Чтобы вайбокодить тебе надо по сути описать весь алгоритм от и до. Потом ешё баги фиксить. Непонятно в чём вообще смысл - набивание кода никогда не было узким местом.
>Чтобы вайбокодить тебе надо по сути описать весь алгоритм от и до. Потом ешё баги фиксить. Непонятно в чём вообще смысл - набивание кода никогда не было узким местом.
Вариантов масса, например переносить код с платформы на платформу, с языка на язык. Либо написание чего-то обьемного, но по сути несложного, типа всяческих аудиосистем и прочих бойлерплейт-систем.
Ну нахуй оно надо?
>>1068402
Не хочу.
>>1068405
Тогда это логично. Нейронка выдаёт кривой код и ты час упрашиваешь исправить, гугля все ошибки и тыкая её носом во все места, где она обосралась. Токены крутятся, лавэха мутится.
> переносить код с платформы на платформу
Это вопрос архитектуры, а не кода.
>Не хочу.
потому что напиздел, и теперь не хочешь, чтобы анон проверил
Подключи архитектурно js либу на мегабайт кода к годоту или к юнити, а я на тебя посмотрю.
>Ну нахуй оно надо?
Чтобы писать структуру данных с очередным хитровыебаным функционалом не два часа, а две минуты. Чтобы писать обьемную систему с всякими обвесами не два дня, а 3 часа с интеграцией и тестами. Чтобы не трахаться при даунгрейдах кода плагинов того же годота самому (4->3), чтобы переводить обьемные куски библиотек на нужный язык, чтобы не трахаться с gdextension (gdextension есть только в годот, в юнити - терпи и маршаль с фиксацией на пк/андроид платформе или полностью переводи на шарп). Вариантов масса. И нет, топовые нейронки допускают минимум логических ошибок, только иногда путают/придумывают апи и их просто надо пнуть логами ошибок, чтобы починилось.
На другую платформу - это перенести с PS5 на PC, а не это твоё веб-говно.
А где принципиальная разница? Что веб говно, что свичговно, что соснольговно, что мобилоговно, всё одно говно которое за меня напедалирует нейронка, когда я ей скормлю спеки. Разве что соснольскими сдк кормить можно только селфхостед, что неприятно.
>Врёти
Ладно. Если в общих чертах, то я просил SRP шейдер для непрямого процедурного рендеринга на юнити. Грок туда всунул "Tags { "RenderType"="Opaque" "RenderPipeline"="UniversalPipeline" }", что правильно. Но потом он всунул туда ещё и OUT.positionCS = TransformObjectToClipPos(pos); что совершенно неправильно, хотя казалось бы, что он понимает, что этот идентификатор несовместим. Но нет, грок всунул буквально взаимоисключающие параграфы. И такое каждые пять строчек. Я его ткнул носом, он поисправлял. Но насрал новыми ошибками и переименовал вообще все переменные, так что просто взять и скопипастить нельзя, нужно пролезать по коду и исправлять всё обратно. Ну его нахуй, короче.
наверное по этой теме недостаточно кода в инете, чтобы LLM могла адекватно обучиться
я у нейронок прошу просто куски HLSL в виде функций - справляются норм
Ну хуй знает. Но у меня люто горит, что он, например, добавил #pragma instancing_options procedural:setup, но сам сетап не добавил. То есть он запомнил половину, а дальше такой - ну и хуй с ним. А кусками у него функции заказывать не получится, потому что он все переменные переименовывает и заебёшься исправлять под свой код. Гопота лучше, но тоже очень далеко до идеала.
промтами с копипастой кода из окна работают только анальные узкари, которым скрипт надо вставлять в какое-то очко в проге, без вожможности адекватно работать в редакторе кода с запуском и получением ошибок в терминале. по-нормальному код пишут агентами. они не превращают код в месиво и умеют сами билдить/запускать, читать ошибки и фиксить их, шароёбиться по файлам, читать их и править код по всему репозиторию
вообще, в чатгпт для этого есть канвас, но он говно и им невозможно пользоваться
Видали мы эти ваши агенты, ими разве что хеллоуворлды и круды с ангулярами педалить можно, если кодобаза крупная и связанная особыми механизмами, которые эта дурка не знает - галюны будут похлеще чем у гпт 3.5, потому что она еще и в раг будет дампить, который судя по выхлопу превращает данные в вдохновленное оригиналом месиво. Лучшее что я нашел - управлять окном токенов вручную, давая ровно столько и такой информации, которая не сможет нейродебилу помутить рассудок и не даст ему права на ошибку. Иначе - полностью солидарен с грок-аноном.
>хотя казалось бы, что он понимает
Писечка ЛЛМок в том что они не понимают. Просто генерируют токены наиболее вероятные для данного набора входных токенов.
Ты потом полгода будет говны за нейронкой прибирать, теоретик. Эта поебень мне из воздуха выдумывала несуществующие функции в MAXSDK, день экспериментов с нейронкой на этом и завершился.
отпишусь в субшоте, что получится в итоге
> Чтобы вайбокодить тебе надо по сути описать весь алгоритм от и до. Потом ешё баги фиксить. Непонятно в чём вообще смысл - набивание кода никогда не было узким местом.
Не обязательно. Ты можешь сказать нейронке - добавь в настройки галочку которая включает/выключает качание оружия, поддержи в локализации. И она это сделает.
Или можешь скзаать - сделай, чтобы когда игрок теряет хп, проигрывался эффект, заведи в базе эффектов поле для этого эффекта.
Можешь попрочить написать тесты и прогнать их, проверить компиляцию, чтобы максимизировать шанс пригодного результата.
Если тебе охота самому тратить время на подобную примитивщину, которая требует только безмозглых движений мышкоц и тыканья кнопок с логическим мышлением максимум в глубину на 1-2 шага(ага тут есть такой класс у него такие функции, значит надо вызвать эту) - ну ок.
Мне не охота, я считаю, программирование без нейронки в 2026 = кринж. Если не получается её применить - значит не разобрался.
А то, что ты описываешь, есть только у копилота. И он говно.
>>1068470
>выдумывала несуществующие функции в MAXSDK
Вот здесь да, двачую, тоже встретил это. Ещё встретил, что нейронка тупо вызывает какую-то функцию и ей похуй, что этой функции вообще не существует. Пишешь типа "сделай, чтобы было Х", а тебе в ответ - "да, конечно, вот код MakeX(); наслаждайся, рад помочь"
>А то, что ты описываешь, есть только у копилота. И он говно.
палю годноту: https://antigravity.google
> Вот здесь да, двачую, тоже встретил это. Ещё встретил, что нейронка тупо вызывает какую-то функцию и ей похуй, что этой функции вообще не существует.
Сделай, чтобы оно проверяло ошибки компиляции, и такие проблемы(которы встречаются раз в сотню промптов или при работе с какими то специфичными сдк) уйдут.
Вы нейронкохейтеры даже не пытаетесь как будто разобраться как инструмент использовать, про mcp хоть слышал?
Покажи что ты там нанейропрограммировал
>проигрывался эффект, заведи в базе эффектов поле для этого эффекта.
В базе эффектов
Поле для эффекта
Чтобы проиграть эффект на персонаже
Ну вы поняли?
>>1068475
Годнота с окном токенов в 10кб, ухх, или у тебя там внатуре хэллоуворлд или ты просто придумщик
>>1068476
>которы встречаются раз в сотню промптов
Ну несколько чаще они случаются, но это не самое страшное, проблемы апи это самая небольшая из возможных проблем
>Ты можешь сказать нейронке - добавь в настройки галочку которая включает/выключает качание оружия, поддержи в локализации. И она это сделает.
В проекте где полсотни мегабайт плюсового кода в котором половина файлов последний раз менялась в начале нулевых? Это буквально то с чем на работе работаю.
> Или можешь скзаать - сделай, чтобы когда игрок теряет хп, проигрывался эффект, заведи в базе эффектов поле для этого эффекта.
Для начала база эффектов должна быть. Потом, есть множество вариантов сделать само качение. Является ли это анимацией которую мы можем добавить в анимационный контроллер. Есть ли в нашем анимационном контроллере возможность это сделать? Не придётся ли нам полностью пересмотреть всю анимационную систему для добавления? Поддерживает ли система эффектов эффекты типа "проиграть анимацию" или только запуск партиклей? Не придётся ли переписать систему эффектов чтобы добавить такой тип анимации? Как мы будем запускать эту анимацию? А может мы будем делать всё процедурно? Но поддерживает ли анимационная система смешивание анимаций и процедурных модификаций? Будет ли аниация базироваться на физике? Что делать если в процессе качания оружия оно столкнётся с чем нибудь?
Это только те проблемы что я могу вот так сходу увидеть за пару минут.
>>1068474
> "да, конечно, вот код MakeX(); наслаждайся, рад помочь"
Проиграл в голосину. Буквально то что я получил. Ну хоть под ноги не харкает и на том спасибо.
>>1068476
Зачем разбираться в говне? Ты её спрашиваешь совершено тривиальные вещи, она косячит хуже чем джун с курсов. Не ну что-то скопипастить из азбуки оно может, это всё. А писать хитровыебанный промпт это буквально делать работу за нейронку. Набивание кода в редакторе не является узким местом.
>Просто генерируют токены наиболее вероятные для данного набора входных токенов.
Ты нажал наиболее вероятные буквы для данного набора входных ощущений. Что дальше?
>надо по сути описать весь алгоритм от и до
Я сам не вайбкодер и код пишу вручную, но, ИМХО, текстовые нейронки помогают найти/понять или выдумать алгоритм. Только нужно заранее ей код запрещать в промпте, чтоб не давала кринж типа:
>include algorithm
>algorithm.do() # this will do the work
>This is how you implement algorithm.
> Покажи что ты там нанейропрограммировал
Ну я занимаюсь разработкой игр в крупной компании и делаю свой проект.
> В базе эффектов
> Поле для эффекта
> Чтобы проиграть эффект на персонаже
> Ну вы поняли?
Что поняли? То что тупую рутину нейронка без проблем делает по общему описанию? Да, определенно делает.
>>1068483
> В проекте где полсотни мегабайт плюсового кода в котором половина файлов последний раз менялась в начале нулевых? Это буквально то с чем на работе работаю.
Да. Ты дифф изменений нейронки посмотреть не можешь, тесты прогнать не можешь, куа задача проходить не будет?
> Для начала база эффектов должна быть.
Сделай. Ты вообще не туда докапываешься, я говорю, что тупую рутину нейронка легко щелкает, а не то что она тебе в автономном режиме игру сделает.
Предполагается, что у нас есть простой механизм проигрывания вфх.
> Потом, есть множество вариантов сделать само качение. Является ли это
Это уже зависит от проекта. Про качание я ничего не говорил(это уже слишком проектно специфичная вещь и требует в том числе работы тех аниматора ну илм разраба если он за это отвечает), я говорил про проигрывание эффекта при попадании по игроку.
> Не придётся ли нам полностью пересмотреть всю анимационную систему для добавления?
Это звучит супер странно, если в проекте нету условного playVfx(id, pos, rot). Да и еще страннее, что вфх каким то образом полностью подвязаны на анимации????
Может быть необходимость подвязать на анимационный ивент - тогда его тех аниматор добавит куда ему нужно, в коде ты его заэкспоузишь как надо и нейронка остальное сделает.
Но это все частности и конкретика специифическая для конкретного проекта.
Вопрос вот в чем - зачем тебе самому искать нужные файлы чтобы вписать 1 строку(или пару десятков с не сложной логикой), если это может сделать нейронка а ты глянешь дифф за 20 секунд, и 1 раз запустишься посмотреть все ли работает?
> Это только те проблемы что я могу вот так сходу увидеть за пару минут.
Это не проблемы, это спекуляции с абстрактным проектным, в котором может двть так а может быть не так, и ты просто перебрал кучу вариантво что может быть. Какая разница что может быть, если нейронка сама сделает поиск по проекту и увидит что там и сделает нормально? Если надо переписывать то обосрется и скажет тебе что тут не так все просто.
Короче все, нахуй это надо, у меня такой же диалог уже несколько раз был со скуфами ии отрицателями, все одно и то же по кругу, а как спросишь что пробовали - в ответ чат гпт с браузера год назад))) или еще какая-то кринжатина.
Кто хочет - юзайте агентов(gemini pro/claude opus) с mcp и смотрите что реально экономит время. А если нормально написать правила то простые штуки оно практически в автономном режиме делает.
> >include algorithm
> >algorithm.do() # this will do the work
> >This is how you implement algorithm.
В 2023 наверное да, в 2026 это вредно писать в промпте
>делаю свой проект.
Покажи.
>Что поняли?
Ну как тебе сказать. Не знаю в какой ты там компании чем занимаешься, но когда я вижу подобный текст - у меня появляются смутные сомнения относительно компетентности (ну или на худой конец вменяемости) автора этого текста. Ну база эффектов еще допустим, но зачем в ней (в элементе/записи этой базы) создавать поле, что этот эффект влияет на что-то очень конкретное и вне своей группы абстракций(или что ты там имел в виду) - мне этого в упор не ясно, инверсия зависимостей, все дела.
>простые штуки
В простом проекте простые штуки оно и правда хорошо делает, в сложном проекте ей можно доверить только фичи (и даже сложные фичи, которые сами в себе), как любому другому джуну, бизнеслогику надо писать самому, иначе хуйню напишет невменяемую.
>это вредно писать в промпте
Что "это"? Это нейронка пишет. И нужно это запретить.
В промпте нужно что-то типа "avoid writing any code".
>gemini pro/claude opus
Сколько центов ты получаешь за каждую такую рекомендацию здесь?
> Покажи.
Нет.
> Ну как тебе сказать. Не знаю в какой ты там компании чем занимаешься
Возможно, ты про неё слышал, как то раз видел её упомянание в этом треде кек.
> у меня появляются смутные сомнения относительно компетентности (ну или на худой конец вменяемости) автора этого текста
У меня есть такие же вопросы к твоей компетентности, но в таком ключе никакого обсуждения не получится.
> Ну база эффектов еще допустим, но зачем в ней (в элементе/записи этой базы) создавать поле, что этот эффект влияет на что-то очень конкретное и вне своей группы абстракций(или что ты там имел в виду)
> - мне этого в упор не ясно, инверсия зависимостей, все дела.
Мне тоже не ясно. Покажи мне, где я такое написал?
Я писал - "сделай, чтобы когда игрок теряет хп, проигрывался эффект, заведи в базе эффектов поле для этого эффекта."
Разве тут есть хоть что-то подобное тому что ты пишешь?
Чтобы эффеет воспроизвести, надо чтобы проект про него знал -> нужна некая база эффектов. Хоть положить его куда то и захардкодить путь, хоть сделать нормальную систему с айдишниками эффектов.
Какое поле на что этот эффект влияет, ты о чем вообще?
> В простом проекте простые штуки оно и правда хорошо делает
Нет, на рабочем проекте(он большой и технически сложный, с редкими технологиями) без проблем делает простые штуки.
> в сложном проекте ей можно доверить только фичи (и даже сложные фичи, которые сами в себе), как любому другому джуну, бизнеслогику надо писать самому, иначе хуйню напишет невменяемую.
Нет, нормально напишет. Тут важны не абстрактные слова "просто, сложно", а глубина логики(когнитивная сложность) и количество взаимосвязанных элементов необходимое для работы с конкретной системой.
Ну и разумеется специфические знания для конкретного проекта и более глубокая экспертиза в том что какие риски несет и какое решение взвешенно лучшее в данной ситуации, но это уже не простые задачи, это надо самому делать.
Ты думаешь у ии будет какая-то сложность с тем чтобы галочку в настройки добавить если у тебя в проекте есть слодные части которые ВООБЩЕ НИКАК на этот кусок не влияют?
И поделись плиз какой у тебя опыт работы с нейронками, просто может ты из тех кто в браузере чат гпт пару раз юзал, а не делал все как надо. Тогда советую попробовать сделать как надо(нормальная модель, документ с правилами, init в проекте чтобы нейронка его структуру описала, mcp).
>Короче все, нахуй это надо, у меня такой же диалог уже несколько раз был со скуфами ии отрицателями
Просто настоящие программисты идут спрашивать сложные темы, а не очередной контроллер персонажа. И они тупо видят, что нейронка довольно часто начинает галлюцинировать.
Самое нелепое что я видел, когда ИИшка по середине текста высрала пример с Node.js, хотя я упоминания нод были в контекста годота. Это явный показатель того, что это просто "угадайка", а не интеллектуальный помощник.
>Мне тоже не ясно. Покажи мне, где я такое написал?
Я буквально реплайнул где. Человек при памяти никогда такого бреда не напишет, потому что знает технический язык и знает что такое "поле" и "база". У базы нету поля(в контексте хранения элементов, не считая поля базы, которые к ее элементам почти никак не относятся), у ее элемента поля есть, соответственно отсюда истекает вопрос, о каких нахуй полях речь и как они связаны с управлением проигрыванием анимаций где-то там.
>Нет.
Пиздабола ответ. Если еще и это ты антигравити советовал, у джемини которой окно контекста 10кб, то пиздабол вдвойне.
>Ты думаешь у ии будет какая-то сложность с тем чтобы галочку в настройки добавить если у тебя в проекте есть слодные части которые ВООБЩЕ НИКАК на этот кусок не влияют?
Да. Потому что "галочка в настройках" - она же не просто так там есть, галочка в настройках это - ui элемент, его коллбек, расставленные на сценах якоря определеного типа (который тоже надо написать), управляющие обьектами, связанными с этой галочкой.
>И поделись плиз какой у тебя опыт работы с нейронками, просто может ты из тех кто в браузере чат гпт пару раз юзал, а не делал все как надо.
Проблема не в том, чтобы делать всё как надо, а в том что у нейронки максимальное окно контекста 200кб. Если бы оно было пару миллионов - то я бы впринципе был с тобой согласен что агенты заебись. На данный момент да, я юзаю браузер и руками управляю контекстом, чтобы нейродебил знал только то, что я хочу чтобы он знал, только в этом случае он может делать сложные обьемные фичи, влезающие в тысячу-полторы строк. А настройку я сделаю и сам, с ней больше работы с редактором чем с кодом.
> Ты дифф изменений нейронки посмотреть не можешь
50 Мб кода не влезут в контекст, если влезут то нейронка нахуячит дифф с милионом изменённых строк, удачи его смотреть. А тестов нет, код буквально нетестируемый. При этом никто не знает как и что большая часть кода делает.
> что тупую рутину нейронка легко щелкает
Тупая рутина это порядок вертексов в кваде. Добавить эффект это не тупая рутина, легко может привести к полугоду рефакторинга.
> если в проекте нету условного playVfx(id, pos, rot)
Ты очевидно не делал такие вещи никогда раз с такой лёгкостью рассуждаешь. Там примерно миллион потенциальных проблемных мест, многие определяются архитектурой. К примеру, если под "эффектом" подразумевались только разные партикли то добавление анимаций персонажу потребует существенных переделок. Нейронка с такими вещами в принципе не справится.
> ты глянешь дифф за 20 секунд
Дифф на миллион строк, алё.
> если нейронка сама сделает поиск по проекту и увидит что там
Не сделает и не поймёт. Возьми прямо сейчас сорцы первокваки (всего 5 мегабайт кода) и добавь туда фичу чисто промпотм, расскажешь про экспириенс.
> Самое нелепое что я видел, когда ИИшка по середине текста высрала пример с Node.js
КАКАААААЯ. Чат гпт 3?
> Просто настоящие программисты идут спрашивать сложные темы, а не очередной контроллер персонажа
У нейронки не надо ничего спрашивать, нейронке надо давать задачу, которую она должна сделать сэкономив твое время.
>>1068521
> Я буквально реплайнул где. Человек при памяти никогда такого бреда не напишет, потому что знает технический язык и знает что такое "поле" и "база". У базы нету поля(в контексте хранения элементов, не считая поля базы, которые к ее элементам почти никак не относятся), у ее элемента поля есть, соответственно отсюда истекает вопрос, о каких нахуй полях речь и как они связаны с управлением проигрыванием анимаций где-то там.
Мы о терминологии спорим или что? Совершенно очевидно, что я не говорил про "Базу данных", я говорил про некое хранилище эффектов куда его надо добавить чтобы игра была про него в курсе. Если не очевидно - вот я второй раз это проясняю.
> Пиздабола ответ. Если еще и это ты антигравити советовал, у джемини которой окно контекста 10кб, то пиздабол вдвойне.
Хаха. Нет.
> Да. Потому что "галочка в настройках" - она же не просто так там есть, галочка в настройках это - ui элемент, его коллбек, расставленные на сценах якоря определеного типа (который тоже надо написать), управляющие обьектами, связанными с этой галочкой.
Она это всё и сделает бля, я не просто так её привел. Это совершенно типовой элемент который делается строго по одному пайплайну по образцу.
Давай я еще в твоем клоунском стиле обвиню тебя в некомптентности тут: если ты галочку в настройках руками на сцене ставишь, то это кринж. Список настроек код ферст должен быть очевидно.
> Проблема не в том, чтобы делать всё как надо, а в том что у нейронки максимальное окно контекста 200кб.
Скинь весь код связанный с окном настроек, нужный для контекста в твоем проекте, посчитаем сколько там килобайт.
> На данный момент да, я юзаю браузер и руками управляю контекстом
Ну и о чем тогда тут говорить? Какую модель хоть юзаешь?
Попробуй сделатьт как я написал.
> чтобы нейродебил знал только то, что я хочу чтобы он знал
> только в этом случае он может делать сложные обьемные фичи, влезающие в тысячу-полторы строк.
Оно само найдет что надо, если очень хочешь можешь тегнуть файлы которые надо смотреть или в свободном стиле написать их названия, она разберется.
> А настройку я сделаю и сам, с ней больше работы с редактором чем с кодом.
Ты рил не понимаешь, что вот эта вся обслуживающая ерунда - найти нужный файл, найти нужное место в коде, глянуть контекст че там вообще творится, написать строку, скомпилить, запустить, поправить ошибки, проверить - это бездна в которую утекает время?
Это сделать легко, но зачем самому тратить пару часов на простую фичу, в которой основная масса работы это рутина в которой мозги не требуются? Разобраться в примитивной бизнес логике без большой глубины и большого числа взаимосвязей я тоже записываю в категорию рутины.
Сделай запись экрана с момента открытия проекта до полной реализации простой фичи и посмотри сам на что время уходит и сколько его уходит. При правильной работе с нейронкой в 99% случаев от тебя потребуется только написать задачу(минута), глянуть дифф(минута) и запустить проект чтобы убедиться что все ок(3-5 минут).
>>1068523
> 50 Мб кода не влезут в контекст, если влезут то нейронка нахуячит дифф с милионом изменённых строк, удачи его смотреть. А тестов нет, код буквально нетестируемый. При этом никто не знает как и что большая часть кода делает.
Зачем тебе 50 мб контекста? Зачем тебе весь проект в контексте?
Какой дифф в миллион строк для галочки в настройках, ты с ума сошел?
Тестов нет - добавь. Не доьавить - пускац запускает проект и через мцп логи смотрит.
> Добавить эффект это не тупая рутина, легко может привести к полугоду рефакторинга.
...
> Ты очевидно не делал такие вещи никогда раз с такой лёгкостью рассуждаешь.
Очевидно делал и поэтому написал все требуемое апи для данной задачи. Покажи мне проблемы плейВфх(айди, поз, рот).
> Там примерно миллион потенциальных проблемных мест, многие определяются архитектурой. К примеру, если под "эффектом" подразумевались только разные партикли
Да, речь шла про партикли, потому и вфх.
> то добавление анимаций персонажу потребует существенных переделок.
А если анимации не потреюуется то все ок? Что ты там вообще напрограммировал, что проиграть анимацию требует существенных переделок, а не прокидывания чего-то в одну из сторон и потом модель.Триггернуть анимацию(айди)? Разумеется предполагая, что технически анимация в проекте есть и настроена для работы.
Не надо только рассказывать про "такие вещи никогда не делал", у меня и на рабочем и на своем проекте гигансткий аниматор.
> Нейронка с такими вещами в принципе не справится.
Давай прям щас в своем проекте вобьешь и посмотришь?
Скачал, ваш аккаунт не поддерживается. Удалил.
>>1068476
>Сделай, чтобы оно проверяло ошибки компиляции
Уйдёт в бесконечный луп. Я нейронку час дрочил и за час не было такого, чтобы код хотя бы скомпилировался.
>>1068483
>Ну хоть под ноги не харкает и на том спасибо.
На питоне попробуй. Питон нейронка кое-как вывозит, но в остальном они настолько сосут, что это даже не смешно.
То есть окей, я не хейтер нейросетей, генерю картинки, трёхмерный графониум, у меня ретоп на основе нейросети, думаю ещё подключить нейросетевой мокап. Но с кодом это всегда былинный отказ, в код нейросети не могут от слова совсем.
>Давай я еще в твоем клоунском стиле обвиню тебя в некомптентности тут: если ты галочку в настройках руками на сцене ставишь, то это кринж. Список настроек код ферст должен быть очевидно.
Ангулярщик, мы как бы интерфейс верстаем в редакторе, если че. Ты не бздотя часом? Движки игровые видел хоть раз?
>Скинь весь код связанный с окном настроек, нужный для контекста в твоем проекте, посчитаем сколько там килобайт.
Дурилка, ты же даже не понимаешь в чем тут проблема. Считать надо не килобайты выхлопа нейросети, а килобайты всего решения, потому что пока нейросеть не проанализирует всё решение от а до я - она не сможет выдать код. Полный код системы настроечных якорей порядка 50кб, это и правда немного (но не для антигравити), однако если вылезти за пределы этой системы - есть система управляющая всем интерфейсом, и суммарно ее код спокойно может выйти за пределы 500кб, потому что гуй цепляет всё вообще.
>Ну и о чем тогда тут говорить? Какую модель хоть юзаешь?
Разумеется передовой клод опус 4.5. Говорить и правда неочем, потому что свои нейроподелия ты не показываешь.
>Попробуй сделатьт как я написал.
Пробовал, эта токеносжигалка тратит мое время гораздо больше, чем если я буду это делать руками, и при этом не может сделать нормально сложные вещи, которые я делаю только в полностью изолированном контексте. Когда размеры контекста будут миллионные - будет о чем говорить.
>Ты рил не понимаешь, что вот эта вся обслуживающая ерунда - найти нужный файл, найти нужное место в коде, глянуть контекст че там вообще творится, написать строку, скомпилить, запустить, поправить ошибки, проверить - это бездна в которую утекает время?
Купи себе нормальный комьютер, где полнотекстовый поиск не будет занимать бездну времени. Лично у меня гораздо большую бездну времени занимает работа с ассетами, их подгонка и сборка геймплея, сложные фичи я стараюсь делегировать нейросети (и она с ними часто не справляется или справляется не с первого раза), а простую бизнеслогику я пишу сам, потому что такого кода % 30 всей игры, но любая ошибка в нем которая проскочит мимо нейродебила - затем устроит мне веселую жизнь. А она проскочит, и тесты не помогут, потому что внезапно - тесты на код это наиболее статистически вероятные проверки для кода, который надо тестировать, и это не покроет все случаи.
> Уйдёт в бесконечный луп. Я нейронку час дрочил и за час не было такого, чтобы код хотя бы скомпилировался.
Нет, не уйдет. Покажи как ты делал и я,скажу чтотне правильно.
>>1068548
> Ангулярщик, мы как бы интерфейс верстаем в редакторе, если че. Ты не бздотя часом? Движки игровые видел хоть раз?
Зачем тебе верстать конкретную галочку конкретной настройки, если ты можешь сверстать лишь один элемент "галочка" и со стороны кода только декларативно описать какие настройки нужны - а конкретные галочки под разные настройки создавать автоматически?
Или ты серьезно когда тебе надо добавить новую галочку в настройки - руками ее туда добавляешь и мышкой перетаскиваешь? Ну, это плохой подход.
> Дурилка, ты же даже не понимаешь в чем тут проблема. Считать надо не килобайты выхлопа нейросети, а килобайты всего решения, потому что пока нейросеть не проанализирует всё решение от а до я - она не сможет выдать код.
Ну так давай скинь, мы всё учтём, чё за отмазки?
> Полный код системы настроечных якорей порядка 50кб
Мало того что эта цифра из жопы, так ещё и "код настроечных якорей" тут не нужен для решения задачи.
> однако если вылезти за пределы этой системы - есть система управляющая всем интерфейсом,
Звучит супер странно, что нам для добавления галочки в настройки нужно понимать контекст ВСЕГО ЮИ. Там скорее всего вообще кроме 1 файла + технического стека ниче не нужно.
>и суммарно ее код спокойно может выйти за пределы 500кб, потому что гуй цепляет всё вообще.
Да просто скинь свой код окна настроек, нам не нужен весь юи.
> Разумеется передовой клод опус 4.5.
Ладно.
Так давай может тогда прям ща скачаешь клод код и буквально напишешь в него то что я тебе скажу и посмотим что он сделает? Скинешь дифф его изменений.
Только нужен контекст что у тебя за движок/игра, потому что если у тебя юнити и в юи вручную расставлены мышкоц намтройки, то это не прокатит, с префабами ии работает плохо.
> Говорить и правда неочем, потому что свои нейроподелия ты не показываешь.
Что именно ты хочешь увидеть? Название игры? Написать какой-то промпт и показать что выдаст? Какой тебе нужен, чтобы ты не ушел в отрицание?
> Пробовал, эта токеносжигалка тратит мое время гораздо больше, чем если я буду это делать руками,
Только не говори, что ты просто сидишь афк и просто смотришь на бегущие токены, вместо того, чтобы в это время делать следующую задачу.
> и при этом не может сделать нормально сложные вещи
Буквально в каждом своем посте я по 2 раза пишу конкретно о выполнении простых рутинных задач. Сложные вещи делай как тебе нравится, разрешаю.
> Купи себе нормальный комьютер, где полнотекстовый поиск не будет занимать бездну времени.
У меня и так почти самое топ железо какое только есть.
Я говорю далеко не только про производительность компа, а в первую очередь про механические и когнитивные действия которые тебе надо сделать - въехать в контекст задачи, понять что задействовано, пройтись по коду и найти откуда что-то вызывается, проверить ошибки, найти еще что-то. Сложного в этом ничего нет, это просто требует время.
> Лично у меня гораздо большую бездну времени занимает работа с ассетами, их подгонка и сборка геймплея
У нас этим занимаются технические геймдизайнеры, программисты только программируют, я говорю именно про задачи с точки зрения программирования.
Интересную игру сделать или заполишить механики - это нейронка не делает.
> а простую бизнеслогику я пишу сам, потому что такого кода % 30 всей игры
Это мало типа?
> но любая ошибка в нем которая проскочит мимо нейродебила - затем устроит мне веселую жизнь.
QA на что? / Пример?
>>1068550
Ну 5 тоже кпл. Клауде опус и гемини про единственные 2 рабочие нейронки.
>просто "угадайка", а не интеллектуальный помощник
Это проблема архитектуры трансформеров тащемто.
Как учится человек? На ошибках, здесь и сейчас, т.е. наломал дров, понял ошибку, больше не повторяешь. Тренировка трансформера - одноразовая операция, происходящая в самом начале, до его работы. Либо отложенная на будущее, усреднённая по всем его использованиям миллионами людей одновременно.
Фанбои трансформеров говорят: вот увеличим ему "контекст", настроим RAG, tool calling... Но это ж ведь костыли - хрупкие надстройки, а не фундамент. Если фундаментально моделька ничему не учится на всех актуальных ошибках, то никакой RAG не поможет.
Вот кто-нибудь здесь помнит, как NPC в старой GTA постоянно бежали в стену, не видя её? Это потому что поведение у них фиксированное. Программист мог бы исправить этот баг, но не исправил. Если игрок NPC оттолкнёт от стены, NPC побежит дальше, но... снова упрётся в какую-нибудь стену. Потому что не учится.
Так что работать надо над изменением модельной архитектуры. Делать что-то другое, не трансформеры. Предлагаю движкописям треда этим заняться - всяко интереснее и полезнее, чем копировать движки 90-х.
Движок может работать для древней пеке движкописи, а нейронки требуют суперкомплюктеров. Так что не. Будет ковырять палочкой геймдев 90-ых..
> Зачем тебе 50 мб контекста? Зачем тебе весь проект в контексте?
Чтобы ИИ понимал что тут вообще происходит и как одна часть системы взаимодействует с другой. Ну ок, не весь код. У нас один только рендер это более мегабайта кода на DX9 с хаками под специфические геймплейные фичи за авторством предыдущих команд.
> Какой дифф в миллион строк для галочки в настройках, ты с ума сошел?
1. Чтобы эта галочка заработала.
2. Как отмечают все кто используют, ИИ любит преписывать код,
>Покажи мне проблемы плейВфх(айди, поз, рот).
Ты сам спросил. Как мне проиграть эффект на специфической анимированной кости с смещением "на резинке"? А ещё дизайнерам надо эти эффекты триггерить без написания кода. А ещё надо ловить параметры и изменения состояния объекта на котором эффект играется.
>Да, речь шла про партикли, потому и вфх.
Ок, а теперь мы хотим чтобы эффект ещё и на анимации влиял. И привет рефакторингу на полгода.
>Что ты там вообще напрограммировал, что проиграть анимацию требует существенных переделок, а не прокидывания чего-то в одну из сторон и потом модель.
Потому что у тебя, например, это не предусмотрено от слова "вообще". И способв прокинуть анимацию есть множество. К примеру мы можем их все добавить в контроллер и просто триггерить. Вопрос в том предусмотрено ли это. Или нам нужен способ как то добавить их к уже существующему контроллеру. У тебя, к примеру, модель может сидеть где-то там и быть недоступной коду без откровенных хаков, код у тебя только выдаёт наружу интерфейс для контроллера. Чисто чтобы разделение труда было между аниматорами и программистами.
>Давай прям щас в своем проекте вобьешь и посмотришь?
Я не вайбкодер, ты вайбкодер. Я уже потратил полдня на вайбинг несуществующих функций в MAXSDK, показавший что ИИшка просто не понимает ничего. И я уже предложил тебе взять первокваку и что нибудь в ней навайбить. Так что вперёд.
Ты заебал, шизик, человек тоже не может себе в память загрузить 50 МЕГАБАЙТ(это миллион строк блять) твоего говнокода и работать с этой парашей как с одним целым, для этого и существуют слои абстракции и архитектура. Хуй знает почему ты этого требуешь от ИИ, я бы лучше от тебя потребовал разобраться со своим говном сначала.
>Скинь код
А какие гарантии что я скину код и у меня по твоей наводке заработает? Ты не показываешь что сделал ты, конкретно, нахуя мне светить свой код, если ты не хочешь сам подтверждать что у тебя в твоем проекте получилось
>Зачем тебе верстать конкретную галочку конкретной настройки, если ты можешь сверстать лишь один элемент "галочка" и со стороны кода только декларативно описать какие настройки нужны - а конкретные галочки под разные настройки создавать автоматически?
Ну точно ангулярщик. Маня, да ты игровых движков в глаза не видел. Мне не нужен codefirst, у меня editor first, контейнеры, адаптивная верстка интерфейса, шейдеры на элементах. Подвязывать codefirst имеет смысл только если нужны динамические элементы, типа хп у мобов или чата и то, исключительно в утилитарных целях.
>Мало того что эта цифра из жопы, так ещё и "код настроечных якорей" тут не нужен для решения задачи.
)))). Феерично. Боюсь представить что ты там пилишь, если ты не используешь якорную реализацию воздействия настроек на обьекты в том или ином виде. Ну а по поводу цифры - мне наверно виднее сколько весит моя полная реализация, не находишь?
>Да просто скинь свой код окна настроек, нам не нужен весь юи.
Окно настроек это часть юи, но дело не в этом. Если нейронка не может в полный цикл внедрения функционала - она только тратит мое время. А она не может.
>Так давай может тогда прям ща скачаешь клод код и буквально напишешь в него то что я тебе скажу и посмотим что он сделает? Скинешь дифф его изменений.
Я не намерен сжигать в печи свои токены на эту хуйню, у меня для нейронки есть задачи поважнее. Тем более я уже их и так до этого порядочно насжигал с отрицательным кпд. Ладно, хэллоуворлдщик, пили двльше с кайфом свои хэллоуворлды, слишком много редфлагов для продолжения этой тупорылой дискуссии.
> Чтобы ИИ понимал что тут вообще происходит и как одна часть системы взаимодействует с другой. Ну ок, не весь код. У нас один только рендер это более мегабайта кода на DX9 с хаками под специфические геймплейные фичи за авторством предыдущих команд.
Это излишки объективно. Давай продолжим докапываться до примера с галочкой - покажи, для чего там это знание нужно.
> 1. Чтобы эта галочка заработала.
Для этого миллион строк не нужно.
> 2. Как отмечают все кто используют, ИИ любит преписывать код,
Я не воспринимаю аргументы "говорят". У меня не переписывает.
> Ты сам спросил. Как мне проиграть эффект на специфической анимированной кости с смещением "на резинке"?
В запросе задачи такого не было. Но можно сделать и это, я кстати буквально это решал промптом, просто написав, что надо добавить опциональный таргет и хендлить его на стороне эффекта.
> А ещё дизайнерам надо эти эффекты триггерить без написания кода.
Поэтому замечательно, что у нас есть айдишник, и мы можем сделать дизайнерам выпадающий список со вскми айдищниками или названиями эффектов(если ацдишники числовые)
> А ещё надо ловить параметры и изменения состояния объекта на котором эффект играется.
Брызг крови длительностью 0.5с от попадания пули вряд ли надо как-то деспавнить если персонаж умирает. Попали - брызг заспавнен, все.
> Ок, а теперь мы хотим чтобы эффект ещё и на анимации влиял. И привет рефакторингу на полгода.
Нет, подожди, почему эффект должен на анимации влиять да еще и потребовать рефакторинг?)
Вот в нас попали и что-то происходит, вызывеется
OnHit()
{
...
PlayVfx()
}
Теперь мы делаем
OnHit()
{
...
PlayVfx()
PlayHitAnimation()
}
Что ты тут рефакторить собрался и каким образом эффект тут хоть как-то влияет на анимации?
> Потому что у тебя, например, это не предусмотрено от слова "вообще". И способв прокинуть анимацию есть множество. К примеру мы можем их все добавить в контроллер и просто триггерить. Вопрос в том предусмотрено ли это. Или нам нужен способ как то добавить их к уже существующему контроллеру. У тебя, к примеру, модель может сидеть где-то там и быть недоступной коду без откровенных хаков, код у тебя только выдаёт наружу интерфейс для контроллера. Чисто чтобы разделение труда было между аниматорами и программистами.
Я зз какие ты подходы используешь и с чеи работаешь, я работаю в юнити с дефолтным юнитевским аниматором, в котором визуальной стейт машиной аниматоры настраивают все триггеры и переходы, и я тоже умею всё это делать и сам настраивал.
Со стороны кода все что требуется - это вызывать триггеры и пушить состояние объекта(бул убит, бул идет, флоат скорость) - дело аниматоров настроить переходы.
Если у тебя сложный кодовый анимационный контроллер, то мне кажется ровно тот же подход справедлив - ессли кому-то надо проиграть анимацию хита, то он берет и делает PlayHit(). Если в контроллере нужно поддержать соответствующую анимацию - это уже отдельная работа по его доработке, при этом PlayHit() как был так и останется и иной контекст функционалы который хочет его проиграть - знать не нужно.
> Я не вайбкодер, ты вайбкодер.
Мне всё равно как ты меня называешь.
> Я уже потратил полдня на вайбинг несуществующих функций в MAXSDK, показавший что ИИшка просто не понимает ничего.
Прямо сейчас качай клод код и попроси его сделать, а не копипасти с браузера. Он сам прошарит его актуальный код нужный для выполнения задачи и всё сделает. Мой друг буквально все нужные рекламные сетки и аналитические сдк завайбил за вечер, впервые с ними работая.
> И я уже предложил тебе взять первокваку и что нибудь в ней навайбить. Так что вперёд.
Дебилизм. То что мне надо вникнуть в проект, разобраться как его запускать, какие там основные архитектрные решения ты не учитываешь?
Я тебе гарантирую, что над проектом над которым я работаю работает раз в 5 больше человек чем над ней, давай я прям в рабочий проект промпт ради тебя вобью? Да/нет? Если нет, то почему ты считаешь, что это не считова?
>нейронки требуют суперкомплюктеров
Огромный простор для оптимизона же, мечта движкописи. Да и урина уже тоже требует суперкомпьютера, чтобы показывать хотя бы 30 фпс. С фреймгеном, конечно же.
На самом деле удивительно, что нашлись долбоёбы, которые без рофлов пытаются дефать "вайбкодинг", не ожидал, что в разделе есть настолько тупые дегенераты.
Тут есть одна вещь которую в споре про замену программистов нейронками постоянно забывают. Нейронки убивают существующую экосистему ИТ. А дадут ли взамен ее что-то работающее неизвестно.
Человеку не нужно 50мб движка читать. Он пару книг прочтет. Ответы на стековерфлоу посмотрит. Но представь ситуацию. Нейронки заменили программистов. Вместо миллионов кодомакак нужы сотни. Остальные теряют квалификацию без работы. ИТ форумы умирают - некому обсуждать вопросы. Издательства перестают печатать книги, потому что никому не упало выпускать книги на аудиторию в сто человек. Компании прекращают поддержку опенсорса. Потому что все внутри зависит от нейрокода.
Откуда нейронки будут черпать инфу? Только из кода. Не из интернета даже, потому что там одно устарешее говно, а из одного ебаного проекта...
мимо другой шиз
> А какие гарантии что я скину код и у меня по твоей наводке заработает? Ты не показываешь что сделал ты, конкретно, нахуя мне светить свой код, если ты не хочешь сам подтверждать что у тебя в твоем проекте получилось
Так ч тебя спрашиваю - скинуть? Что именно ты хочешь увидеть чтобы ты не слился?
> Ну точно ангулярщик. Маня, да ты игровых движков в глаза не видел.
Я разраб на юнити.
> Мне не нужен codefirst, у меня editor first, контейнеры, адаптивная верстка интерфейса
Чееееел.
Это никак не противоречит тому что я пишу. Тебе сложно сделать адаптивный контейнер и один типовой элемент под этот контейнер чтобы их автоматом на спавнить в скролящийся список?
> )))). Феерично. Боюсь представить что ты там пилишь
Не зря
> если ты не используешь якорную реализацию воздействия настроек на обьекты в том или ином виде.
Зачем знать детали реализации якорей для этого?))))))) Тебе достаточно просто знать что такая концепция применяется.
> Ну а по поводу цифры - мне наверно виднее сколько весит моя полная реализация, не находишь?
Ты просто оьманщик.
> Окно настроек это часть юи, но дело не в этом. Если нейронка не может в полный цикл внедрения функционала - она только тратит мое время. А она не может.
QA и первичный осмотр что задача выполнена не избежать. Тем не менее оптимизация остальных составляющих это оптимизация.
> Я не намерен сжигать в печи свои токены на эту хуйню, у меня для нейронки есть задачи поважнее. Тем более я уже их и так до этого порядочно насжигал с отрицательным кпд. Ладно, хэллоуворлдщик, пили двльше с кайфом свои хэллоуворлды, слишком много редфлагов для продолжения этой тупорылой дискуссии.
Да что ты пиздишь, я в опус десятки промптов в день ебашу автоматизированно
>Откуда нейронки будут черпать инфу? Только из кода. Не из интернета даже, потому что там одно устарешее говно, а из одного ебаного проекта...
Обучение нейросетей на собственных высерах вызывает существенную деградацию, это давно просекли. Так что если выродятся кодеры, то нейросети умрут следом, либо будут полностью заморожены и лишены возможности обучаться в принципе.
Человек не может. А ИИ не может работать без загрузки всего, потому что это просто тупой генератор копипасты.
>>1068592
>Давай продолжим докапываться до примера с галочкой - покажи, для чего там это знание нужно.
Галочка что делает? Как написан код? Добавление галочки может быть как работой на десять минут, так и требовать полного рефакторинга, зависит от очень большого количества факторов. Не забывай что игра она в реальном времени работает, а не как вебхуйня какая.
> У меня не переписывает.
Ну значит ты его не используешь, а просто фантазируешь начитавшись рекламы.
> Нет, подожди, почему эффект должен на анимации влиять да еще и потребовать рефакторинг?)
Как твой playvfx будет внутри себя запускать анимацю на персонаже? Он вообще имеет хоть какой то доступ к персонажу? Что у тебя вообще внутри playvfx происходит?
>сли у тебя сложный кодовый анимационный контроллер, то мне кажется ровно тот же подход справедлив - ессли кому-то надо проиграть анимацию хита, то он берет и делает PlayHit(). Если в контроллере нужно поддержать соответствующую анимацию - это уже отдельная работа по его доработке, при этом PlayHit() как был так и останется и иной контекст функционалы который хочет его проиграть - знать не нужно.
Т.е. ты без согласования с кем либо принял дизайнерское решение что все анимации должны жить внутри контроллера и у тебя нет способа взять и добавить произвольную анимацию в произвольный эффект.
> Прямо сейчас качай клод код и попроси его сделать,
Мне вот делать по жизни больше нечего.
> То что мне надо вникнуть в проект, разобраться как его запускать, какие там основные архитектрные решения ты не учитываешь?
Но у тебя же ИИ всё это делает, надо просто промпт написать. Вперёд, качай исходники и пиши промпт.
>Нейронки заменили программистов.
Нейронка это статистический генератор говна на основе исходного говна. Если нейронку пинает человек, который шарит в технических решениях, понимает матчасть и в курсе проекта - это будет серьезный буст. Если же этим занимается вкатун - будет некомпилируемая беда. Так что скорее все текущие программисты трансформируются в нечто среднее, одной рукой нейронки, другой рукой нормальный код. Ну и пока наконец не преодолеют контекстный потолок - инструмент все так же будет ограничен, при чем значительно. Для реального рывка и упразднения значительной части не хэллоуворлдщиков нужно чтобы контекст стал где-то 5 миллионов токенов. Так что пока сидим на жопе ровно
>А какие гарантии что я скину код и у меня по твоей наводке заработает? Ты не показываешь что сделал ты, конкретно, нахуя мне светить свой код, если ты не хочешь сам подтверждать что у тебя в твоем проекте получилось
Если так боишься - лови.
Вот промпт: to main settings tab add "Enable subscription offers setting" - when it is true, we should show subscriptions
offers in shop, wehn false - dont
Вот результат. И оно работет с первого же промпта!
Я даже попросил его влезть вообще в другой отсек бизнес логики и никак не писал ему какие вообще классы надо трогать. Причем в папке не только игра, но и еще целый мета сервер на джаве и куча скриптов на питоне. А вот, все равно он как то разобралася.
Жду оправдания и причины, почему я должен делать это сам.
> Я не намерен сжигать в печи свои токены
Какой же глупый слив))) Сделай посмори - ряя нет не буду врети не модет этого быть!
> Галочка что делает? Как написан код?
> Как твой playvfx будет внутри себя запускать анимацю на персонаже? Он вообще имеет хоть какой то доступ к персонажу? Что у тебя вообще внутри playvfx происходит?
Если playVfx запускает анимацию персонажа, то у того кто это писал проблемы с головой.
> Т.е. ты без согласования с кем либо принял дизайнерское решение что все анимации должны жить внутри контроллера и у тебя нет способа взять и добавить произвольную анимацию в произвольный эффект.
Пздц шиза. Кажется, эффект и анимация это принциипиально разные вещи.
Нечто отвечающее за визуальный фидбек на хит должно обратить к анимации и к системе эффектов.
Если надо чтобы анимация поддерживала по ивентам отыгрыш эффектов чтобы дизаннйры могли елбч расталавтья с ними - пожалуйста, можем и так подумать, тогда со стороны нейронки сделать отыгрыш анимации хита не должно никак влиять на это - будет там эффект или нет уже вопрос к дизайнерам и тому как они настроят.
Я тебе расписал аж 2 варианта реализации которые могут быть на реальном проекте, ты продолжаешь писать какие-то выдуманные гипотетические ситуауии, что а вот если у нас не так.
> Мне вот делать по жизни больше нечего.
Ну просто срать буквы видимо интереснее
> Но у тебя же ИИ всё это делает, надо просто промпт написать. Вперёд, качай исходники и пиши промпт.
Откуда я знаю, что там вооюще в проекте есть, что можно доверить нейронке, а что нет? Вроже мой тезис был не "программисты не нужны, нейронка сама все делает", а несколько иначн он звучал, надеюсь, ты не потерял его из контекста?
>нейронки требуют суперкомплюктеров
Я написал несколько нейронок на GDScript в Godot 4, получается что-то около 10 тысяч нейронов с частотой обновлений 30-60 Гц, т.е. один проход по всей нейронке тратит существенно меньше секунды - и это на одном ядре перегревающегося процессора 2007 года с DDR2 RAM. Из трансформеров я могу запускать нейронки с "активным ядром" до ~1.5 миллиарда параметров (не знаю, сколько там нейронов в реальности) на скорости 1-2 токена в секунду, так что по сравнению с самоделкой на GDScript оптимизаций можно сделать просто уйму.
Так что железо для нейросамоделки - не проблема. Проблема - на чём/на что/с какой целью это делать?
Сразу скажу - я тестил большие 70b-120b трансформеры онлайн и не нашёл им особого применения.
Короче: сделать-то можно, но - зачем?
троллейбус_из_буханки_хлеба.jpg
Какие подводные?
>Откуда я знаю, что там вооюще в проекте есть, что можно доверить нейронке, а что нет?
Но ты тут пол-дня мне буквально задвигаешь что можно взять проект, засунуть в нейронку, написать что ты хочешь и оно всё само сделает, тебе надо разбираться буквально ни в чём.
>Вот результат.
Результата нет поскольку у тебя нет ни подписок, ни магазина, ни покупок.
Ты дурной? На 3 скрине "сабскрайб" это не подписка?
Магазин есть.
Я не просил делать магазин, я попросил сделать настройку, чтобы убрало награды за подписки на соцсети когда она включена.
Ты можешь увидеть на 1 скрине как она догадалась сама что subscription offers это free офферы и отфильтровала.
Если хочешь играть в дурачка то давай так:
Было: есть магазин с разными типами товаров, есть окно настроек с разными игровыми настройками
Стало: в окно настроек добавилась галочка, которая отключает товары-подписки-на-соцсети. Она УЖЕ работает, задачу можно отдавать на тестирование.
Мой вопрос: как решить эту задачу быстрее чем написать в нейронку промпт такой как я написал и сколько этотзацмет времени? Есть ли какие-то недочеты в решении предложенном нейронкой с первого же промпта?
>>1068618
Давай я немного доформулирую свой тезис:
Если у тебя есть проект, который ты понимаешь как работает на верхнем уровне и какие технологии использует на низах БЕЗ конкретики, то, при понимании принципа работы нейронки, ты можешь легко понять какие типовые/легкие задачи в нем нейронка может сделать без проблем с большим шансом, сэкономив твое время.
Так лучше?
Это не в игре пропук а видосе
1) Я запустил в дебаг режиме из редактора.
2) Не настроил обс
3) Сконвертил видео напохуй
4) У меня самого пропуки из-за проблем с координацией. Поэтому никогда в шутеры не играл...
Бредовый геймплей какой-то. В стоять на месте и в упор расстреливать врагов из пулемета. Даже в кондовом Скариме лучше.
Пропуки прямо в трейлере - всё как мы любим! Молодец, Failco!
>>1068652
>В стоять на месте и в упор расстреливать врагов из пулемета.
Школьник, ты в Serious Sam никогда не играл что ли?
У Falco своя серия "как Serious Sam, но всрато".
>Даже в кондовом Скариме лучше.
Это совершенно разные жанры...
>>1068654
>шоркать
Зумерский сленг - это не твоё. Брось это, филька, брось.
>Это совершенно разные жанры...
Но если враги огромные как в темных душах, то какой смысл из пулемете? В трейлере все враги огромные. Всегда держат дистанцию. Медленно двигаются. Ни перекатов, ни уворотов. Просто обмен уроном с Годзилой. Это же кринжово выглядит.
>кокококой смымымысл в пупупулемётетете
А ты постреляй с такого пулемёта - поймёшь...
http://store.steampowered.com/bundle/2656/
Ну и? Там кучи монстров мелких на превью. + если делать большую ебу, то она должна бы милишником сама и сокращать дистанцию, чтобы ебнуть, а не увеличивать ее, для удобства расстрела из пулемета. Иначе это непродуманый гейплей.
Ну. В фалькиных играх тоже были мелкие мобы. В предыдущих частях.
А в этой он, видимо, решил вырезать мелочь и оставить только боссов.
Хочешь увидеть мелочь - покупай все игры серии. Фалько - гений!
@
ПРОПУКИ ДО 39 ФПС
>39 ФПС
Почему так много? На консолях выше 30 никогда не было и не будет. На мобилках ставят 30 для экономии аккумулятора.
Проблема безрукости, особенно на могилках. Могильные ГПУ достаточно сильные, просто надо писать код так чтобы он данные туда-сюда почём зря не гонял.
Ты с хайпом раста опоздал лет на 5, хипстота давно забросила проекты-обертки. А работяги дальше сидят на плюсах, ибо кто будет в здравом уме гигабайты либ переписывать за 30-40 лет?
Я не хипстор, я гопнически выглядящий типчик с Урала.
> кто будет в здравом уме гигабайты либ переписывать за 30-40 лет?
В былые времена было принято переписывать всё с нуля раз в 5 лет если не чаще. Можешь к примеру посмотреть сколько кода от дума есть в первокваке.
Ну и в гробу я видел на плюсах писать.
Сделай код конем. Пиши на F#
1) Остаешься нитакусей
2) Вся экосистема дотнета остается с тобой
>Ну и в гробу я видел на плюсах писать.
Тогда страдай. В плюсах тоже юзают умные указатели.
>Я использую раст
За ношение чулков разве на Урале в бубен не дают?
Это хуйня, чтобы быть ультимативной нитакусей надо писать на Хаскеле. Когда я стану старым и отращу бороду то буду стримить написание двигла на Хаскеле.
>>1069330
>В плюсах тоже юзают умные указатели
А я не использую, во всяком случае не для ресурсов всевозможных. У меня всё в гигантских массивах с поколенческими хэндлами. Уже вырезал почти все мелкие аллокации, в планах арены и сегментированный вектор живущий в нём для временных per-frame данных типа списка рисуемых примитивов для сортировки.
>За ношение чулков разве на Урале в бубен не дают?
Джинсы сверху надеваю, сейчас тут под -30.
Я зашёл и сказал им что так нельзя, мол посмотрите на юнити, на годот, там нет таких ебанутых настроек ИДЕ, нет 10-минутных компиляций, хот релоад работает из коробки и безотказно, не надо удалять бинарники и перекомпилировать с чистого листа каждый раз как ты создаёшь класс, там всё для людей сделано.
И что они ответили? Накинулись на меня из-за того что я отказался терпеть, назвали нетру крестовичком, мол это еще неплохо, и что я потом привыкну. Ну то есть вы поняли какой скот работает на крестах блять? Я в ахуе с них.
Чем дольше компьютер занят бесполезной работой, тем больше свободного времени у работника, которое он может полноправно тратить на что угодно прямо на рабочем месте. Это древняя мудрость программистов, передающаяся из поколения в поколение.
"LLM агенты" вайбкодеров - это та же компиляция, но с модным новым именем: занимает кучу времени, результат говно и нужно переделывать, а переделки занимают ещё больше времени. Но ты полностью свободен и получаешь почасовую зарплату за бездействие.
Это база всего айти, это знать надо.
Потому геймплейный код должен быть написан на Лиспе. В лиспе нет разницы между данными и кодом и ты можешь менять всё на полном ходу, даже без горячих перезагрузок.
Написал оптимизированную симуляцию мягкого тела за 2 рабочих дня в годот 3, совершенно не включая мозг, исключительно итеративно высасывая с нейронки (клод впопус) рабочие изменения, пробуя и оценивая что вышло. Если бы я работал без нейродебила - я бы делал это пару недель, не меньше.
>ебанутых настроек ИДЕ
это каких?
> 10-минутных компиляций
движок с нуля пересобираешь каждый раз?
тебя за такой базар могли только пиздоболом назвать, не более
> я бы делал это пару недель,
Почему? Много кода? Или математики?
Есть какой-то кайф от того что сделал, но не понимаешь как это работает?
>Много кода?
Да
>математики?
Ну такой, литкодовской алгоритмики с вкраплениями векторной математики. За меня по большей части основную математику считает физический движок, и да
>но не понимаешь как это работает
Я не понимаю как работает физический движок, и понимать хочу еще меньше.
>Есть какой-то кайф
Кайф есть, в моей игре будут прикольные разрезаемые желешки, а если бы я этого не сделал - в моей игре бы не появились прикольные разрезаемые желешки
>Кайф есть, в моей игре будут прикольные разрезаемые желешки
И каковая цена по железу? Жележок же будет много?
Видос снят на компьютере, где процессор стоит 200 рублей на барахолке, 300 с алика. Какой-то там пентиум самый дерьмовый 12 года рождения. 2 желешки не предел, можно было даже 5, прежде чем при разрезании начинаются первые просадки. Плюс - можно управлять суммарным количеством ригидов, и делать таких желешек еще больше, если надо, на видосе желешки суммарно штук на 100-150 ригидов. Так что требования по железу не слишком большие и конфигурируемые. Я планирую одну супердетальную желешку и много слабодетальных.
>это каких?
А таких блять, попробуй скомпилировать проект на вижуал студио разочек.
>движок с нуля пересобираешь каждый раз?
Нет лол в том и дело только проект, первая компиляция проекта 10 минут блять идёт. Последующие быстрее, но всё равно пиздец.
Всё проще. Они всё делают на блюпринтах, потому что кресты в уринале это не совсем кресты и достаточно враждебны для вката. Так что они понятия не имели, что за хуйню ты несёшь.
У меня только двигло само столько собиралось. Игра на уече обычно собиралась достаточно быстро. Ты явно делаешь какую то хуйню.
Нет это были именно уринальные крестовички. Алсо кресты в урине довольно легкие для вката. Я сам на тру крестах программировал много лет назад, но я точно помню что надо было ебаться с собиранием мусора, а UOBJECT за тебя это делает.
>>1069448
Я на 5.4 работаю, на уече возможно эта хуита быстрее компилилась, я хз.
У тебя винда и сам проект на HDD стоят что ли или у тебя амд атлон вместо процессора?
@monkey >>1069464
Анон, ты там на UE 5.4 сидишь и ноешь про компиляцию? Кек, в старых версиях оно всегда было медленным дерьмом, особенно с C++-обвязками. UObject - это костыль для ленивых, кто не хочет руками мусор собирать, но реально, если ты не в инди-говне копаешься, то лучше на Godot перекатывайся, там хотя бы не ебёшься с этой корпоративной хуйнёй от Epic. А "тру кресты" - это для олдфагов, которые помнят времена, когда игры не на blueprint-говне лепили.
Имхо, весь UE - сплошной зашквар для тех, кто хочет быстрый вкат, но потом тонет в баговине. Ты там шизофренией не страдаешь от этих сборок? Лечись, бро, или бампани тред годной пастой про Unity, чтоб посраться нормально.
Тогда почему игроки кринжуют от UE5 и отказываются играть в игры на UE5, жалуясь на плохую графику?
Ты сейчас прочитал три поста и, не кринжанув от тупости низкокачественного нейродебила - решаешь уточнить у него?
>от тупости низкокачественного нейродебила
А чё не так, всё по делу пишет ведь, смотри сам:
>>1069615
>лучше на Godot перекатывайся, там хотя бы не ебёшься с этой корпоративной хуйнёй от Epic
>весь UE - сплошной зашквар для тех, кто хочет быстрый вкат, но потом тонет в баговине
>Лечись, бро, или бампани тред годной пастой про Unity, чтоб посраться нормально.
>>1069664
>godot норм для инди-говноводства и 2d хуйни
>unreal/ue5 разъебёт его по всем фронтам, если не шизанутый соло-дев
>>1069668
>кек, юнити лучший? это ты про тот помойный шлак с рантайм фи сбросом и крипто-сабскрипшеном для солоразрабов?
>godot норм, unreal имба, а юнити для нормисов и мобильных высиралок, шиза диагностирую, таблетки хавай
>>1069669
>Nanite с Lumenом графику на уровень бога поднимают
Всё правильно пишет. Вероятно, под капотом там запросы к Гуглу помимо всего треда...
Кто отказывается? Десять дебилов из ютуба что хайп гоняют для монетизации?
>почему игроки кринжуют от UE5 и отказываются играть в игры на UE5
на продажах это почему-то не сказывается
Как вам новый маскот годота? Мне робот-шестеренка нравился больше.
>Десять дебилов из ютуба
По форумам Steam полазай, если не веришь. Очень многие игроки недовольны.
>>1069708
>на продажах это почему-то не сказывается
Маркетолухи UE5 скупают весь UE5-слоп за деньги Epic, что из Fortnite надоили.
>>1069992
>НАУ, а он уже умер
Лучше мёртвый движок, чем UE5. Мёртвый движок не сможет убить геймдев...
>>notepad++ лучше visual studio
>БАЗА блэать!
Двачую.
Notepad.exe >>>> VS
Godot >>>>>>>>>> UE
>Wicked
Это его фалько форкнул? Или другое? Какой-то ноунейм уровня фальки.
>Mac OS
Оно всё ещё живое? Кто-то пробовал ставить вместо Windows/Linux?
>Лучше мёртвый движок, чем UE5.
Хуйня, лучше больше движков. Хороших и разных.
>Очень многие игроки недовольны.
Я уже давно писал, что УЕ становится токсичным. Вкупе с кризисом железа будет интересно посмотреть, как это говно будет выживать
>>1070053
>Какой-то ноунейм уровня фальки.
У этого ноунейма технических знаний хватит занять позицию лид разработчика движка где-нибудь в крупной игровой студии.
>У этого ноунейма технических знаний хватит занять позицию лид разработчика движка где-нибудь в крупной игровой студии
Откуда такая уверенность? Терри Девис вряд ли мог бы претендовать на аналогичную позицию в отделе майков или даже каноникал.
>Откуда такая уверенность?
Этот шиз далеко не Терри Девис, я давно за ним зоонаблюдаю. Освещение в движке топового уровня без преувеличений.
>>1070075
>Кабаны даже не скрывают что видеокарты "все".
Кабаны зарезали средний сегмент и оставили только "нищий" и "топовый". Так что нет никакого "всё", кто хочет видеокарту - либо берёт хай энд, либо нищелвл на 8 гигов. На то, что подписка может подешеветь в условиях подорожания железа - не указывает ничто. Как и на то, что это станет более коммерчески выгодно, чтобы кабаны этим занимались, как и на то, что существенно снизится задержка, чтобы игроки наконец могли этим пользоваться.
>Освещение в движке топового уровня без преувеличений.
Откуда знаешь что топовое? Стресс-тестил?
А кто сказал, что я слежу и за этим шизом? Вроде, когда-то постили справку этого шиза из дурки, что он документально заверенный поехавший. Но были случаи, что он фаршировал игры разным говняком, так что лично для меня работоспособность его движка не имеет значения. Не исключаю, что там что-то и работает, погроммист-то не фалько.
>>1070101
По качеству работы знаю. VXGI в принципе очень качественный вариант и у wicked реализация удачная.
Этот бесполезный, за такими не слежу. Вот за юбисофтом слежу, ему совсем плохо стало. Видимо, отбегался.
Ну зачит будем тетрисами и 2D пратформерами народ развлекать как в 90ые. Тоже неплохо. Не хочешь же ты сказать что люди вообще играть перестану. Одих скуфов еще лет на 20 хватит.
Какой контекст? Я должен весь тред читать? Зачем? Двачи существуют для того чтобы попиздеть, а не вычитывать контексты. Тут не научный симпозиум.
Я лучше график скину, чем тупой тред.
>эти парни
Давно ничего не значат и если и схлопнутся, эффекта от этого будет не больше, чем от закрытия Монолита.
> Ты знал что геймдевы иногда попадают в фильтр при найме?
Какой нах фильтр, о чем речь?
> Вебмакака может знать про архитектуру куда больше чем геймдев.
Архитектура напрямую связана с конкретным проектом.
Вебмакака знает про архитектуру веба, геймдевер знает про архитектуру игр.
Если делать манясравнения, то скорее всего разраб игр имеет больший уклон в архитектуру чем вебмакака, потому что он занимается именно программированием и архитектурой по постоянно, а не версткой визуала.
> Ты только посмотри как убого задизайнены движки. Вы отстаете лет на 15 от промышленной разработки.
Движки дизайнят так, чтобы под разные проекты подходили.
Как устроены игры в промышленной разработке ты похоже не знаешь.
> Это основа основ любой области - всегда. На другие подобные базворды можно подзабить, но только не на solid.
Там 2 из 5 принципов очень широкие и размытые.
Принцип единственной ответственности соблюдаешь? Всегда ли его надо соблюдать?
Мимо
> Движки дизайнят так, чтобы под разные проекты подходили.
Не всегда, отнюдь. Движки достаточно часто делают под конкретный проект или под специфику конкретного класса игр. К примеру, хуй ты на движке Teardown майнкрафт сделаешь. Специализация позволяет тебе побить большие универсальные движки в специфических нишах. Тот же teardown ты хуй на анрыле нормально сделаешь.
> Архитектура напрямую связана с конкретным проектом.
Архитектура относительно универсальная штука в своей основе. Просто вне геймдева/трейдинга/контроллеров к программированию относятся как к некой абстракции игнорирующей факт что оно работает на конкретном физическом железе.
>>1070117
Не будет ничего, связь между рыночной оценкой и реальным состоянием дел слабая. Я не видел чтобы у них были какие то многолетние проблемы с зарабатыванием бабла.
>Какой нах фильтр, о чем речь?
Был скандал, когда вытекли эйчаровские пометки крупного кабанчика на собесы программистов. Пометки - игнорить разработчиков с геймдева.
Вот такое мнение мегакабанов о геймдев разрабе.
Дальше спорить не хочу. Маняфантазия вида мы "лучше".
Веб макаке нужно годами сопровождает код фулл-тайм, а вебдеву высрать игру разок. и не надо про фиксы и длс, это все равно не сравниться с теме объемами.
И тут сразу возникает вопрос (риторический), у кого будет потребности в архитектуре больше? Тут зачастую даже не знают как использовать стейт машину, какая еще архитектура, о чем ты?
Понятно что я не про всех. Это в среднем по больнице.
>Движки дизайнят так, чтобы под разные проекты подходили.
У меня сложилось впечатление, что движки дизайнят для минимального болезненного вката ньюфагов или художников (людей из другой области).
>Принцип единственной ответственности соблюдаешь? Всегда ли его надо соблюдать?
В промышленной разработке, особенно в дедовских молонолитах (на джаве) это прям было мастхэв. Тебе уже могли предъявить почему метод 4 параметра принимает (не дохера ли он на себя берет). Есть предметные области с исключением, конечно. Мы как раз в ней.
Unix утилиты на этом построены, го либы (как минимум когда я работал с го), раст библиотеки, js-либы.
>Я не видел чтобы у них были какие то многолетние проблемы с зарабатыванием бабла.
Значит, тебя даже вчерашний шторм не разбудил. Прибыли падали не один год, много их игр, как сейчас принято говорить, underperformed. Они одним махом отменили шесть игр, которые были разработке и начали массовые увольнения. Из-за того, что денег нет и держаться уже сложно. Не то, чтобы это были первые сокращения штата в юбисофте на фоне падения прибыли. У компании долг больше двух миллиардов евро. Не то, чтобы долг это всегда было плохо и указывало на проблемы с финансами, но в этот раз случай именно такой. По факту юбисофт будет жить только до тех пор, пока Тенсент инвестирует в Гиймо. Компания нежизнеспособна не первый день.
> Не всегда, отнюдь. Движки достаточно часто делают под конкретный проект или под специфику конкретного класса игр. К примеру, хуй ты на движке Teardown
У него нету движка продукта
> Тот же teardown ты хуй на анрыле нормально сделаешь.
Сделаю. Очевидно кубики у меня будут не анриловские акторы
> Архитектура относительно универсальная штука в своей основе.
Паттерны - да. В геймдеве используется все что только можно в этом плане.
Архитектура проекта в целом - нет, не универсальная.
> Просто вне геймдева/трейдинга/контроллеров к программированию относятся как к некой абстракции игнорирующей факт что оно работает на конкретном физическом железе.
В бекенде производительность важна.
В геймдеве в отлельных доменах архитектуру тоже делают безотноситнльно железа, например ui и в целом верхнеуровневое управление проектом
> Был скандал, когда вытекли эйчаровские пометки крупного кабанчика на собесы программистов. Пометки - игнорить разработчиков с геймдева.
Лол. Нахуя разрабу игр идти на собес в веб? Он пойдет на собес в геймдев.
На собесы зовут только тех у кого есть коммерческий опыт на стеке, на фронтенд и бекендера или айосера не возьмут.
> Вот такое мнение мегакабанов о геймдев разрабе.
Какого-то отдельного, что абсолютно справдливо - на позицию надо брать тех, у кого опыт в конкретной сфере. Точно также на разраба игр не возьмут веб разраба.
> Дальше спорить не хочу. Маняфантазия вида мы "лучше".
> Веб макаке нужно годами сопровождает код фулл-тайм, а вебдеву высрать игру разок.
Что за хуйню я читаю? Какую игру разок? Игры точно также годами в разработке/оперировании.
> Тут зачастую даже не знают как использовать стейт машину, какая еще архитектура, о чем ты?
Где ТУТ? В этом треде? Тут 90% это движкописи и любители.
Ты видел что спрашивают на собесах в геймдев?
> У меня сложилось впечатление, что движки дизайнят для минимального болезненного вката ньюфагов или художников (людей из другой области).
Ключевая цель чтобы профессионалы могли делать что им надо, потому что они заносят деньги.
Ньюфаги да, но движок под это не дизайнится, а вдаптируется, путем каких-то готоввх компонентов.
> В промышленной разработке, особенно в дедовских молонолитах (на джаве) это прям было мастхэв.
Ты пиздишь, фанатично в срп никто нигде не упарывается, где нет смысла дальше дробить интерфейсы(в виду лишней запутанности и усложнения) - не дробят.
> Тебе уже могли предъявить почему метод 4 параметра принимает (не дохера ли он на себя берет).
Да где-то и 10 нормально если это реально нужно, просто упаковывается в структуру.
>Лол. Нахуя разрабу игр идти на собес в веб? Он пойдет на собес в геймдев.
Чтобы начать нормально кушать, а не вот это вот все.
>Игры точно также годами в разработке/оперировании.
Ппц я там даже пометку сделал про объем, триггер все равно активировался.
>Где ТУТ? В этом треде? Тут 90% это движкописи
Хочется спросить где игори эти движки, но зачем до весны тревожить шизу?
>фанатично в срп никто нигде не упарывается
В твоих любительских движках "собранных в гараже" может происходить все что угодно, это ни как не отражает того, что у людей в профессии.
> Чтобы начать нормально кушать, а не вот это вот все.
???
Так и разрабам игр хорошо платят.
> Ппц я там даже пометку сделал про объем, триггер все равно активировался.
Я её увидел. И своим постом мне кажется явно подсветил, что объем разный бывает, размер команды разный бывает.
> Хочется спросить где игори эти движки, но зачем до весны тревожить шизу?
Движкописи часто не до конца понимают что и зачем они делают, пожтому и конкретного результата нет.
Это не что-то плохое, для обучения может и норм, но я про то, что в этом треде не очень много тех кто игры реально делает.
У меня не любительский движок, у меня юнити, и гигантская кодовая база которую 10 лет развивали много людей, на основе которой наш проект делается командой из 15 разрабов.
> что у людей в профессии
Я человек в профессии разработки игр. Также я прекрасно знаю что там в фронте и беке.
>что объем разный бывает, размер команды разный бывает.
Когда мы что-то утверждаем мы говорим про среднестатистическое. Что там на границе распределения Гаусса нас мало волнует. Можно и машку с разбегу, козу на возу. Можно даже на branfuck игру писать, можно даже желтый снег кушать (но не стоит).
Понятно что где-то в студиях будет около норм организация (а где-то нет). Или будет инди команда профессионалов.
Ты когда смотришь движкописю. Он решает не архитектурные организационные проблемы кода. Он сидит замеряет ФПС куба и расставляет те же геймобжекты как и другие.
>У меня не любительский движок, у меня юнити, и гигантская кодовая база которую 10 лет развивали много людей, на основе которой наш проект делается командой из 15 разрабов.
Расскажи какие архитектурные решения вы используете?
> Когда мы что-то утверждаем мы говорим про среднестатистическое.
Ну и где тогда статистика, где вычисление среднего?
Что вошло в статистику?
Когда среднее по беку вычислял - считал тех кто делает бек для шаурмечной или систему учета для ооо рога и копыта?
Если учитывал тех кто делает игры в формате пет проектов, то учитывал тех кто делает веб в формате пет проектов?
Мне сложно оценить среднее, но я могу сказать, что на собесах на юнити разраба ебут архитектурой и архитектура это задача номер 1 на проекте. Когда любую фичу проектируешь важно чтобы она нормально встала на свое место.
> Ты когда смотришь движкописю. Он решает не архитектурные организационные проблемы кода. Он сидит замеряет ФПС куба и расставляет те же геймобжекты как и другие.
Я и говорю, что он просто учится чего-то там делать, он не профессионал по которому надо мерять индустрию.
>>1070317
> Расскажи какие архитектурные решения вы используете?
DI, MVP, медиаторы, фабрики, адаптеры, ивент бас, разделение на домены. Архитектура больше всего похожа на layered архитектуру.
'Игра' также разделена на несколько отдельных проектов - игра, сервер, дата модели. Дата модели это общий проект в котором определены структуры данных общие для юнити клиента и сервера.
>Игра' также разделена на несколько отдельных проектов - игра, сервер, дата модели.
Общей кодовой базы чтоли нет?
Вот дата модели и есть общая область, игра юзает их, и сервер юзает их.
>Ну и где тогда статистика
За щекой посмотри, сейчас бы ньюфага по эмпирическим данным за ручку водить.
>DI, MVP, медиаторы, фабрики, адаптеры, ивент бас, разделение на домены.
Лол, перечислил базворды вперемешку с паттернами ООП.
>'Игра' также разделена на несколько отдельных проектов - игра, сервер, дата модели.
Ого, сильно.
Какой подход в тестирование?
Когда вы адаптируете ответы из нейронки, спорить куда интереснее.
>делается командой из 15 разрабов.
Всем классом делаете? Ероха геймдизайнер? А ЕОТ рисует арты?
> За щекой посмотри, сейчас бы ньюфага по эмпирическим данным за ручку водить.
По твоим маняфантазиям.
> Лол, перечислил базворды
Попался. Ты говоришь чушь без смысла. Процитируй хотя бы один баззворд. Все слова что я написал это конкретика с конкретным применением.
> вперемешку с паттернами ООП.
Перечислил наиболее частые паттерны, которые становятся архитектурно-образующими и могут быть названы 'архитектурными решениями'. Что еще можно назвать 'архитектурнвми решениями' в общем виде я хз.
Если ты хотел увидеть конкретную архитектуру, то наверное надо было так и спрашивать, я бы мб нарисовал тебе схему.
> Какой подход в тестирование?
Смоук тесты qa отдела, тестирование отдельных задач qa отделом.
Юнит тесты и интеграционные тесты используются точечно в общих библиотеках(так как у компании много игр - есть общая кодовая база из десятков библиотек, которые внедрены в проекты через пакетный менеджер и изи обновляются по необходимости)
> Когда вы адаптируете ответы из нейронки, спорить куда интереснее.
Какая нейронка, сыняра? Для тебя что-то из того что я сказал не очевидные вещи?
А в чем проблема? Di отвечает за проброс бизнеслогических сервисов-зависимостей, а эвентбас - доставляет данные от сервиса к сервису и к потребителю и от потребителя. Классика всяких тырпрайзов.
Легко, они никак не протвиоречат.
DI это лишь способ проброса зависимостей.
А ивент бас это способ ослабления связи.
На некоторвх проектах я даже видел, где шина ивент баса инжектится через ди и юзается например для менеджмента окон. Т.е. ты делаешь отдельный домен в котором есть ивент баса и определения окон, этот домен в зависимости куда угодно можешь пробрасывать и вызывать показ окон, ничего не зная про окна - например из геймплея.
В нашем случае чуть проще, у нас в игре есть 2 больших отдела - кор и мета.
И ивент бас юзается для передачи сигналов которые влияют на лайфтайм игры(потеря коннекта, требовпние загрузить кор, требование загрузить мету, рассинхрон данных локальных и серверных)
>Попался.
Ой, что же делать.
Я сначала подумал что общаюсь с настоящим программистом, пока ты не высрал портянку базвордов, где только два слова относятся к архитектуре. А потом поставил акцент вокруг layer, которая общая для них двоих. Ты представил мое лицо в тот момент? Ты вообще нифига не знаешь за архитектуру.
Ероха в классе какую должность занимает?
>DI это лишь способ проброса зависимостей.
Какие другие способы проброса зависимостей есть?
>А ивент бас это способ ослабления связи.
А DI не ослабляет связи?
Можно ли через шину получить зависимость?
>А ивент бас это способ ослабления связи.
Это идиотский способ ослабить связь. Нормамльные поцаны ослабливают связи через подходящую абстракцию. Например через интерфейсы с инверсией зависимостей, через стратегии.
Ивент бас нужен только для доменных событий. Каждый агрегат предоставляет свою шину.
>Ты говоришь чушь без смысла. Процитируй хотя бы один баззворд.
Не хочу, ты загугнишь/нейронишь и переобуешь и я больше не поймаю тебя на тупости. Мне этого достаточно чтобы понять с кем общаюсь. мы уже общались с тобой, ты вертлявая задница, которая будут бесконечно маняврировать
>В нашем случае чуть проще, у нас в игре есть 2 больших отдела - кор и мета.
>И ивент бас юзается для передачи сигналов которые влияют на лайфтайм игры(потеря коннекта, требовпние загрузить кор, требование загрузить мету, рассинхрон данных локальных и серверных)
Забавно, но твоя игра действительно сетевая, клон Undertale на itch. Я не тестил как она работает, но надеюсь ты выписал премию всему воображаемую отделу.
> движка продукта
Это вообще что? Двигло там построено на трассировке лучей внутри воксельных объёмов плюс собственная физика. Не на растеризации.
>>1070314
Юнити довольно говенный движок по большинству аспектов. Выезжает только на сетевом эффекте и ассетсторе. Если что я делал рендер который по скорости крыл бнити как бык офцу, прямо в лоб без особых оптимизации.
Ну во первых ты ее не потестишь потому что ебучий итч отключил автоиндексирование, видно мне нужно пойти к техподдержке и расцеловать ее в мошонку, чтобы проиндексировали. Во вторых - не очень хочу чтобы ее тестили местные шизы, это альфа с дырявым сервером и я забил ей заниматься пока что. В третьих - ты меня спутал с другим аноном.
> Я сначала подумал что общаюсь с настоящим программистом
С игрушечным. Чел, апплеяция к личности это ошибка аргументации про котгрую еще в древнем мире знали. Да и аппелируешь к ней ты зря, может оказаться, что я в твоем же манямирке более настоящий чем ты кек.
> пока ты не высрал портянку базвордов, где только два слова относятся к архитектуре. А потом поставил акцент вокруг layer, которая общая для них двоих. Ты представил мое лицо в тот момент? Ты вообще нифига не знаешь за архитектуру.
Нет, они все относятся к архитектуре.
Архитектура это конкретные подсистемы проекта и взаимосвязи между ними, помноженные на архитектуро-образующие паттерны и принципы.
Конкретные системы описывать нет смысла, проект большой, поэтому я выделил именно вторую часть.
Опиши архитектуру на твоём проекте в таком формате, какой ты считаешь правильным.
Лол, пост до сих пор не утонул еще (насколько тут мертвая доска)
>>1067351 →
У тебя какая-то патологическая склонность ко лжи, надеюсь с возрастом это пройдет, но если хочешь расти профессионально, начинай фиксить это сейчас. Иначе превратишься в тех закостенелых шизов, которые в геймдеве по 20 лет и сидят флудят с нулевым выхлопом.
Дурилка, чини детектор. Это не рассказываю про 15 летний проект. Ну и выхлоп у меня уже не нулевой, в отличии от большинства местных спящих синьоров.
> Какие другие способы проброса зависимостей есть?
Обращение к статике, не DI(DI предполагает, что все зависимости единожды получаются в одной точке инцииализации класса, т.е. если ты зависимости можешь прокидывать распределенно и они могут меняться - это не DI паттерн).
> А DI не ослабляет связи?
DI не ослабляет связи, DI устанавливает чет четкие правила по которым зависимости получаются.
Если у тебя есть какой-то обработчик получения дамага и он должен - ему так и так нужен будет класс, который, хоть по канонам ди пробросишь, хоть будешь его обновлять когда тебе надо, хоть к статике обратишься.
> Можно ли через шину получить зависимость?
Для ивент баса это не совсем каноничное решение, скорее всего такое будет запрещено на проекте(либо на словах, либо та самая зависимость от котороц мы и решили сепарироваться будет в другом модуле и её компилятор не даст зареыеренсить вообще)
> Это идиотский способ ослабить связь. Нормамльные поцаны ослабливают связи через подходящую абстракцию. Например через интерфейсы с инверсией зависимостей, через стратегии.
Можно.
> Ивент бас нужен только для доменных событий. Каждый агрегат предоставляет свою шину.
Так это и есть ослабление связи, не?
> Не хочу, ты загугнишь/нейронишь и переобуешь и я больше не поймаю тебя на тупости. Мне этого достаточно чтобы понять с кем общаюсь.
Примитивная манипуляция.
Баззворд это слово без смысла без конкретики. Все что я описал имеет кодовую конкретику и я тебе накину псевдокод как конкретно это используется.
Т.е. ты цитируешь баззворд -> я скидываю код -> ты обосрался.
Ну а если не скидываю, то обосрался я.
Скорее всего, ты ожидаешь первый сценарий, поэтому и слился
> мы уже общались с тобой, ты вертлявая задница, которая будут бесконечно маняврировать
Не уверен, особенно ввиду вышеописанного.
> Забавно, но твоя игра действительно сетевая, клон Undertale на itch. Я не тестил как она работает, но надеюсь ты выписал премию всему воображаемую отделу.
Я не он, я другой анон.
Но тот чел с андертейлом норм чел, хотя его архитектура какая-то шизовая как мне кажется. Но вроде работает же, значит точно тема не мертвая.
>Чел, апплеяция к личности
А как называется ситуация, когда личность выдает себя за другую личность? риторический вопрос
Что мне еще делать когда я вижу что там ньюфаня? Ну прикинь ты общаешься, а там чел в моменте пишет то что явно сам не понимает (бред).
Раньше он хотя бы адаптировал ответ от гуглнейронки. Пока я не ошибся в термине (по своей тупости), и он мне в ньюфаче такую галлюцинацию высрал. Сейчас он видимо стал писать сам.
Фишка в том что его это никак не парит, он переобуется, начнет сейчас отвечать на свои посты, поддерживая себя. Возможно ты и есть он. Это его стиль
> Это вообще что?
То что движком можно назвать что угодно. Можно посмотреть игру написанную васянами на С++, выделить там какую-то часть как типа движок, и сказать что в движках говноархитектура.
Поэтому я бы предлагал движками называть какие-то продукты которые есть на рынке. Как юнити, анрил,.
> Двигло там построено на трассировке лучей внутри воксельных объёмов плюс собственная физика. Не на растеризации.
Я в курсе. Только не "двигло построено", а "там есть трассировка лучей и собственная физика".
На любом движке, где можно писать низкоуровневый оптимизированный код(и на юнити и на анриле можно), можно сделать чтобы тоже было "там есть трассировка лучей и собственная физика"
Игорь компонентный, ты? До сих пор печет?
мимо тот самый андертейльщик
> Юнити довольно говенный движок по большинству аспектов. Выезжает только на сетевом эффекте и ассетсторе. Если что я делал рендер который по скорости крыл бнити как бык офцу, прямо в лоб без особых оптимизации.
Лол. А теперь сделай игру и посмотри на скорость рендера. То что ты заточил рендер под узкую задачу и юзал встроенные возможности юнити с лишним оверхедом без вырезания того что не нужно(а это абсолютно возможно в юнити) мало о чем говорит.
Я знаком с челом который на HDRP проекте, и он работал с анрилом, он говорит на юнити можно большую производительность вытянуть, главная проблема - оооочень мало инструментария.
> Какие другие способы проброса зависимостей есть?
>Обращение к статике
Это что же получается синглтоны тоже депенденси инжекшен?
И все, больше способов нет кроме синглетонов?
>> Можно ли через шину получить зависимость?
>Для ивент баса это не совсем каноничное решение
Ну мы же передаем данные, почему мы не можем сервис передать весь?
>Игорь компонентный, ты? До сих пор печет?
Нас тут не очень много, но кто такой игорь компонентный я не знаю.
> А как называется ситуация, когда личность выдает себя за другую личность?
Какую? Я говорил про архитектурные подходы в геймдеве, которые видел я и с которыми работал.
За какую именно личность я себя выдавал?
> Что мне еще делать когда я вижу что там ньюфаня? Ну прикинь ты общаешься, а там чел в моменте пишет то что явно сам не понимает (бред).
Ну я ж с тобой общаюсь, хотя у тебя очевидно 0 коммерческого опыта в геймдеве.
> Раньше он хотя бы адаптировал ответ от гуглнейронки. Пока я не ошибся в термине (по своей тупости), и он мне в ньюфаче такую галлюцинацию высрал. Сейчас он видимо стал писать сам.
Таблетки.
> Фишка в том что его это никак не парит, он переобуется, начнет сейчас отвечать на свои посты, поддерживая себя. Возможно ты и есть он. Это его стиль
Ну типа да в этой ветке обсуждения отвечал я.
Кста найс съехал с главного вопроса
>> Опиши архитектуру на твоём проекте в таком формате, какой ты считаешь правильным.
>оооочень мало инструментария.
Как инструментарий может быть связан с оптимизацией?
Оптимизируют алгоритмы.
> Это что же получается синглтоны тоже депенденси инжекшен?
Это статика.
> И все, больше способов нет кроме синглетонов?
Чел, ну что за хуйню ты несешь? Я хз ты очень смешно пытаешься троллить и видимо "ловить на тупости", но это ввглядит глупо.
Есть глобально всего 2 варианта
obj.set(something)
И
void Method()
{
Something(статика)
}
Есть разные вариации правил как то и другое можно юзать - синглтон, ди, сервис локатор, мб еще чето.
Это всё вопросы получения зависимостей в классе потребителе.
ИВЕНТ БАС - это параллельная штука, она позволяет отказаться от некоторых зависимотсей(но есть и другие способы) и внезапно его тоже надо каким то оьразом пробросить в класс потребитель.
Что именно ты пытаешься уточнить?
Причём тут оптимизация? Я говорю про то, что HDRP более производителен чем рендер анрила. Проблема юнити с хдрп, почему мало юзают - потому что мало инструиентария.
> 0 коммерческого опыта в геймдеве.
Да, у меня только опыт в маленьких хайлоадах, никому ненужных. Сейчас пойду скажу чтобы пацаны выкинули все и сделали все на синглтонах (как узнали, статистика это тоже же тоже DI).
>> Опиши архитектуру на твоём проекте в таком формате, какой ты считаешь правильным.
Говнокод и я не шучу. Архитектура говнода дает возможность быстрого прототипирования. Лучшая архитектура для старта проекта, рекомендую.
Ответь (без нейронки) зачем вообще нужна архитектура в приложение? Почему вот ты смотришь в свою игру и понимаешь что тут нужна "какая-то архитектура"?
Я могу ответить. Я писал 2д движек и благодаря тому, что использовал DI (через передачу в конструкторы) легко вынес рендер за пределы движка, просто добавив несколько интерфейсов. Если бы я не использовал композицию из маленьких классов, было бы трудно рефакторить.
Даже в трехколесном велосипедном варианте есть польза от чистоты кода.
мимо.
> "ловить на тупости
Уже поймал снова. Поэтому я просто веселюсь.
Когда у нас DI стал сервис локатором? :)
Сервис локатор частное DI?
>ИВЕНТ БАС - это параллельная штука
Могу я сделать шину однопоточной?
>Проблема юнити с хдрп, почему мало юзают - потому что мало инструиентария.
Так и пиши
>Пометки - игнорить разработчиков с геймдева.
Ну это база же. Я вообще в ахуе был, когда начал свою игру пилить, насколько уровень гейдевских дискуссий про программирование и архитектуру находится в темных веках нахуй. У вас же до сих пор блять автоматические тесты считаются опциональными, а под "архитектурой" вы подразумеваете в лучшем случае какой-нибудь обоссаный ECS. В серьезном вебе за такую хуйню еще 15 лет назад по рукам пиздили и отправляли читать фаулеров с мартинами.
> Да, у меня только опыт в маленьких хайлоадах, никому ненужных.
Ну и откуда тебе тогда значть что там в геймдеве, мм?
У меня опыт в геймдеве, логично, что наверное я больше в курсе че мы там юзаем?
> Сейчас пойду скажу чтобы пацаны выкинули все и сделали все на синглтонах (как узнали, статистика это тоже же тоже DI).
Что за хуйню ты несешь?) Где я такое говорил? В геймдеве синглтоны не юзаются в ни в бизнес логик ни в геймплее. Только в инфраструктурных штуках, типа тех же ди фреймворков.
> Говнокод и я не шучу. Архитектура говнода дает возможность быстрого прототипирования. Лучшая архитектура для старта проекта, рекомендую.
Это не архитектура, это уход от ответа. Говнокод не говнокод, а какая-то архитектура и решения на проекте приняты.
> Ответь (без нейронки)
Сука) для тебя грамотный текст это автоматом нейронка?)
> зачем вообще нужна архитектура в приложение?
Для уменьшение затра на разработку на целевой дистанции путем умееьшения когнитивной сложности, уменьшения сложности дебага и увеличения надежности.
> Почему вот ты смотришь в свою игру и понимаешь что тут нужна "какая-то архитектура"?
Я оцениваю вот эти параметры выше и прикидываю насколько мы объебемсч с тем мли иным подходом.
>Не обижайся,
Хорошо, кто сказал что программирование это легко.
> Когда у нас DI стал сервис локатором? :)
> Сервис локатор частное DI?
Когда стал? Не помню такого, процитируй.
> >ИВЕНТ БАС - это параллельная штука
> Могу я сделать шину однопоточной?
Многопоточность не была мной упомянута. Параллельность понятий определяет величину их взаимопротиворечие(его отсутствие)
> Я вообще в ахуе был, когда начал свою игру пилить, насколько уровень гейдевских дискуссий про программирование и архитектуру находится в темных веках нахуй.
В этом треде? Так тут нубасы в основном.
> У вас же до сих пор блять автоматические тесты считаются опциональными
Нааиши игру с автотестами и покажи результат.
В гейидеве игра меняется слишком быстро для написания тестов, автотестами покрывают общие либо и инфраструктуру некоторую.
> а под "архитектурой" вы подразумеваете в лучшем случае какой-нибудь обоссаный ECS. В серьезном вебе за такую хуйню еще 15 лет назад по рукам пиздили и отправляли читать фаулеров с мартинами.
Лол. Пройди хоть один собес в геймдкв с таким уровнем знаний.
>вы подразумеваете в лучшем случае какой-нибудь обоссаный ECS
>В серьезном вебе
А что, дергать хуки рекакта, писать курсору "сгенерируй по дто джейсоноукладчик согласно очередной <библиотеканейм>" - это нынче пик архитектурных изысков? По мне так написать нормальную ecs посложнее будет. Ecs это гарантированно сложнейшая из архитектур эвер, чуть пернул не так - нарушил/усложнил паралеллизм == потерял бонусы.
>У меня опыт в геймдеве, логично, что наверное я больше в курсе че мы там юзаем?
Ты главный в проекте? Ероха помогает? Или Ероха главный?
>> Говнокод
>Это не архитектура
Судя по тому что я вижу, это базовая архитектура всего геймдева.
>Для уменьшение затра на разработку на целевой дистанции путем умееьшения когнитивной сложности, уменьшения сложности дебага и увеличения надежности.
Нет, это все определения. Ты как программист программисту скажи, зачем? Смотри, архитектурные решения накладывают оверхед на разработку. Вот скажи ради чего ты решаешь - что вот тут надо её накатить, в какой момент это происходит? Почему раньше она была не нужна, а вот сейчас она (архитектура) вдруг понадобилась в коде? Что это за момент? хотя гпт уже может ответить
>Сука) для тебя грамотный текст это автоматом нейронка?)
Ну ты же в тот раз обосрался с DTO)
>В гейидеве игра меняется слишком быстро для написания тестов
Про это и говорю, темные нахуй века, в вебе точно такую же хуйню несли лет 20 назад.
>>1070379
Чел, под веб так или иначе пишется процентов 70 всего кода в мире, там миллионы проектов любого уровня сложности(и самые сложные приложения технически это исключительно веб) и он практически полностью опенсорсный. Если тебе нужны современные знания, как писать хороший код и проектировать приложения, то ты нигде, кроме веба, на практике их получить не можешь.
> Поэтому я бы предлагал движками называть какие-то продукты которые есть на рынке.
Идея весьма некорректная. Универсальные "продуктовые" движки вынуждены очень многим жертвовать ради универсальности и совместимости с своими предыдущими версиями. И их разработка намного сложней из за этого, специализированный движок может просто не реализовывать фичи которые не потребуются и писаться с учётом ограничений игры. Типа если тебе не нужен стриминг то ты его просто не пишешь.
>>1070356
>А теперь сделай игру и посмотри на скорость рендера.
Я и делал, и смотрел. Переход на тот же Юнити происходил не по техническим причинам. Все очень хорошо понимали что переезжают на что-то весьма говнистое, но это была плата за то что оно всё сразу готовое и проще находить людей на проекты. А сейчас появилось поколение что ничего лучше Юнити не видели. К примеру сам факт того что гемплейные, рендер и физические объекты живут в одной иерархии являются нонсенсом.
>>1070361
Оптимизируют ещё и данные.
>>1070374
На реальном железе многие эти темы просто нежизнеспособны. Слишком много скачек по памяти. В геймдеве в начале нулевых были попытки делать всё по науке, провалились. ECS родилось из этих экспериментов. К примеру, на ECS очень легко делать автоматические тесты.
>самые сложные приложения технически это исключительно веб
В голос. Самые сложные технические проекты на интерпретируемом языке который не знает что такое ручное управление памятью и оптимизации на процессоре. Как говорится пиши есчо. Покажи мне хоть один веб фреймворк который будет функциональней условного спринга, про мл-библиотеки на плюсах я даже заикаться не буду.
>Если тебе нужны современные знания, как писать хороший код и проектировать приложения, то ты нигде, кроме веба
Спасибо анончик, поднял настроение. Я думаю комментировать излишне.
конкретный пример из твоего кода
или типовой кейс: «когда пора выделять слой / интерфейс / модуль»
или почему Clean Architecture часто вреднее, чем полезнее
Говори, в какую сторону копаем 👌
интернет умер
> Ты главный в проекте? Ероха помогает? Или Ероха главный?
Ты из б пришёл?
На небольших проектах был я главный. На больших я простой сеньор помидор, делаю и большие конечные фичи и инфраструктурные штуки.
> Судя по тому что я вижу, это базовая архитектура всего геймдева.
Конкретики до сих пор нет.
> Нет, это все определения. Ты как программист программисту скажи, зачем? Смотри, архитектурные решения накладывают оверхед на разработку. Вот скажи ради чего ты решаешь
Какие нах определения?
Вот цель в самом начале предложения:
> Для уменьшение затра на разработку
Других целей нет и быть не может.
Тратим время команды на задачу которая прямое вэлью кабану не дает прямо сейчас, которое можно пощупать, чтобы на дистанции в год выиграть и донести больше вэлью кабану(= больше задач, если будешь дальше в дурачка играть с непониманием)
> Ну ты же в тот раз обосрался с DTO)
Какой тот раз? Я не помню чтобы я на этой доске слово DTO ваще писал.
>>1070383
> Про это и говорю, темные нахуй века, в вебе точно такую же хуйню несли лет 20 назад.
Так напиши как надо и покажи лол.
Можешь не показывать, можешь просто сказать - какого уровня проект, сколько человек в команде, игра вышла?
На самом деле гпт галлюцинирует, первое почему понимаешь что "пора", это когда добавление фичи "больнее" чем её написание.
>как писать хороший код
Это тот что тормозит на страшных гигагерцах и двузначном количестве ядер? Говно это, а не код.
> Идея весьма некорректная.
Я в абзаце выше написал причину. Причина некорректная? Почему?
> Универсальные "продуктовые" движки вынуждены очень многим жертвовать ради универсальности и совместимости с своими предыдущими версиями
Не совсем жертвовать. Скорее всем угодить не могут, поэтому делают основу которая уже при допиле подойдет всем.
> И их разработка намного сложней из за этого, специализированный движок может просто не реализовывать фичи которые не потребуются и писаться с учётом ограничений игры. Типа если тебе не нужен стриминг то ты его просто не пишешь.
Если я сделаю на юнити такую же систему трассировки и вокселей как в teardown, причем все как надо, со схожей производительностью - что мы будем движком называть?
> Я и делал, и смотрел.
Игра в релизе, или это был ездящий куб?
Что именно смотрел? Цпу или гпу перформанс? Что было на игровой сцене, на что был оверхед?
Мне просто так кажется, ты 1к монобехов наспавнил, скорее всего даже не заморачиваясь ни с правильнвми шейдерами ни с батчингом ни с инстансингом.
И глянул на фпс, чет меньше стало, и говоришь тепепь что у юнити не производительный рендер, когда по факту ты просто оценивал цпу оверхед которого у тебя и не должно было быть.
> К примеру сам факт того что гемплейные, рендер и физические объекты живут в одной иерархии являются нонсенсом.
Ты юнити пользовался вообще? Там как угодно можно всё провернуть, ты можешь все рисовать без иерахии вообще, физику можешь где угодно как угодно чем угодно считать, ровно как и игровую логику.
> поэтому делают основу которая уже при допиле подойдет всем.
Всем значит никому. В этом проблема состоит.
> Почему?
Потому что ты привык к тому что под движком подразумевают автономную приблуду с редактором.
> что мы будем движком называть?
Юнити. Но у тебя от Юнити будет использоваться чисто отправлялка треугольников на ГПУ и ввод, а вот платить тебе придётся за всё. А написать и то и то не сложно.
> Всем значит никому. В этом проблема состоит.
Легко пркфается что ты не прав - если никому, то почему юнити это самый распоостраненный движок в проде?
> Потому что ты привык к тому что под движком подразумевают автономную приблуду с редактором.
Я привел объективную проблему из-за которой понятие движка начинает размываться:
> То что движком можно назвать что угодно. Можно посмотреть игру написанную васянами на С++, выделить там какую-то часть как типа движок, и сказать что в движках говноархитектура.
> Юнити. Но у тебя от Юнити будет использоваться чисто отправлялка треугольников на ГПУ и ввод, а вот платить тебе придётся за всё.
Платить - ты имеешь в виду финансовую сторону или перформанс?
Если перформанс - то нет, если у тебя не насрано монобехами каждый из которых крутит апдейт - то ты за них не платишь. Если не юзаешь физику, то за неё не платишь. Если не юзаешь аниматор, то за него не платишь. И т д. Оверхед на старт нужных тебе систем и невырезаемых моментов - минимален.
Если финансовую сторону - тогда надо посчитать, сколько сэкономит то что мы юзаем из юнити(ввод, звук, юи, поддержка платформ) и сколько будем отваливать за лицензию. Часто, по итогу юзать юнити ввгодно.
> А написать и то и то не сложно.
Вопрос не в сложности, вопрос в цене разработки.
Сам подумай, на каком уровне ты находишься как программист, если для тебя программа - это до сих пор лаба2 на паскале, где самое сложное - это выделить/освободить память или оптимизировать операцию на процессоре, а про архитектуру и слова нет. Ты буквально в 60х годах застрял и почему-то гордишься этим.
Чел перформанс и арзитектура часто против друг дурга идут, в реальном хайлоаде микрооптимизации в ущерб архитектуре это норма. Оптимизация это прямое снижение затрат на железо.
У тебя нет понимания, что такое архитектура программы, если ты думаешь, что необходимые оптимизации идут ей в "ущерб", а не являются ее частью.
Язык с такими возможностями позволяет строить архитектуру иначе. Меньше аллокаций в куче, больше возможностей подготовки данных для процессора. Ты просто этого не понимаешь. Разные возможности языков - разные варианты архитектур.
>>ИВЕНТ БАС - это параллельная штука
>Многопоточность не была мной упомянута
>Я в вг только в дотатреде смдел лет 8 назад.
Возвращайся, мы скучаем.
>Мне просто так кажется, ты 1к монобехов наспавнил, скорее всего даже не заморачиваясь ни с правильнвми шейдерами ни с батчингом ни с инстансингом.
В моём движке я могу сделать буквально такое же и он даже не почешется. Несколько тысяч дроуколлов это буквально ничто, любой минимально нормальный движок должен такое есть без лишних телодвижений. Как то оптимизировать имеет смысл когда у тебя несколько десятоков тысяч объектов.
>Там как угодно можно всё провернуть, ты можешь все рисовать без иерахии вообще, физику можешь где угодно как угодно чем угодно считать, ровно как и игровую логику.
Можно. В одной игре я так и сделал. Вопрос в том зачем при таких раскладах Юнити нужна. Она начинает выполнять роль такого уродливого слоя изоляции от железа, не более.
>>1070398
>почему юнити это самый распоостраненный движок в проде?
Сетевой эффект и заменяемость разработчиков. Они просто оказались в правильном месте в правильное время. В момент когда появилась бесплатная версия Юнити 5, ничем по существу не ограниченная, альтернативами были ООП-поделки и движки за большое бабло.
> Оверхед на старт нужных тебе систем и невырезаемых моментов - минимален.
Но ты ничего не можешь сделать с тем что сама отправлялка треугольников в ГПУ у них медленная по каким то причинам.
>>1070400
> Сам подумай, на каком уровне ты находишься как программист
Сделал полный круг от структурного программирования на функциях принимающих данные и возвращающие результат назад к структурному программированию на функциях принимающих данные и возвращающие результат. Мегаорхитектуры с DI и абстрактными интерфейсами я тоже делал в прошлом.
Ахахаххаха.
Локальность данных это архитектура?
Если у нас линейно лежат в памяти структуры с кучей лишних данных, раздувающих ее зоны ответственности - это архитектура, хорошая архитектура? Мы решение это принимаем исходя из архитектурных соображений или из соображений низкоуровневой оптимизации?
>>1070407
А процитировать весь фрагмент не можешь? Там речь идёт четко про то, что ивент бас никоим образом не связан с пробросом зависимостей, поэтому как понятие он параллелен - есть статика, нет статики, хоть синглтоы хоть диаи - ивент басу поебать на это.
Если ты не понял тогда - вот, поясняю, что имелось в виду.
>Сделал полный круг от структурного программирования на функциях принимающих данные и возвращающие результат назад к структурному программированию на функциях принимающих данные и возвращающие результат. Мегаорхитектуры с DI и абстрактными интерфейсами я тоже делал в прошлом.
DI это подобие чистых функций в структурном программировании.
С DI в геймдеве вы можете выстрелить себе в ногу. Локатор может быть лучше, вы все равно тесты не пишите (да и мне кажется юнит тесты будут беполезны, нужно сразу до функциональных подниматься, тогда DI становится просто бойлерплейтом, если у вас не котлин или дарт).
> С DI в геймдеве вы можете выстрелить себе в ногу. Локатор может быть лучше, вы все равно тесты не пишите
Каким образом?
Чем лучше locator.Get<A>() чем в конструкторе (A a)?
DI юзают буквально все.
>Если у нас линейно лежат в памяти структуры с кучей лишних данных, раздувающих ее зоны ответственности - это архитектура, хорошая архитектура?
Как ты можешь срать ecs если ты не понимаешь как он работает? У компонентов нет лишних данных, если че. Компонент - неделимый квант информации, самодостаточный.
>это архитектура, хорошая архитектура
Открою тебе маленькую тайну - мир не черно-белый. В разных ситуациях разные архитектуры могут быть лучше других, могут быть хуже других, могут быть и кратно лучше и кратно хуже, а могут быть отвратительными, но при этом - лучшими из худших. Вот так бывает, да.
>нужно сразу до функциональных подниматься,
Как раз моё решение для геймплейного слоя, сделать все скрипты монадами. И решает проблему многопоточности без всякой поебени с локами, чисто как бонус.
>А процитировать весь фрагмент не можешь?
Я еще не отошел от шока параллельности, не дави.
>Параллельность понятий определяет величину их взаимопротиворечие(его отсутствие)
>Там речь идёт четко про то, что ивент бас никоим образом не связан с пробросом зависимостей, поэтому как понятие он параллелен - есть статика, нет статики, хоть синглтоы хоть диаи - ивент басу поебать на это.
Как сразу интеллект понизился без нейронки. Пошла нечитаемая шизофазия.
> Как ты можешь срать ecs если ты не понимаешь как он работает?
Где ты упомянания ецса увидел? И где я про него что-то плохое говорил?
> У компонентов нет лишних данных, если че. Компонент - неделимый квант информации, самодостаточный.
Опять же, про ецс речь не шла вообще, но на практике и в ецс нередко в угоду перформансу компоненты наращивают, чтобы избежать структурных изменений.
Что тоже хорошая демонстрация того, что я говорил - в угоду производителньости часто архитектура может или в жертву. Не черно-бело, будто отрезана нахуй, очевидно, а именно некий ущерб.
> Открою тебе маленькую тайну - мир не черно-белый. В разных ситуациях разные архитектуры могут быть лучше других, могут быть хуже других, могут быть и кратно лучше и кратно хуже, а могут быть отвратительными, но при этом - лучшими из худших. Вот так бывает, да.
В чём тайна? Это очевидно. Как это противоречит моему тезису?
> Как сразу интеллект понизился без нейронки. Пошла нечитаемая шизофазия.
Опиши как связан ивент бас и механизм проброса зависимостей)
От тебя буквально нет никаких конструктивных тезисов, только смешные картинки или выдумывание слов мне в рот.
Только монады это уже функциональное программирование.
>И решает проблему многопоточности без всякой поебени с локами, чисто как бонус.
Да, только копирует одни и те же данные миллионы раз по всей системе.
Вот и непонятно что хуже, write-лок или копии одних и тех же состояний, да еще местами устаревших.
У тебя каша в голове, чел. И скорее всего она из-за того, что ты ставишь знак равно между какой-то трехбуквенной залупой типа ECS и архитектурой. Архитектура программы - это не следование трем буквам как религиозной догме, а выявление и организация абстракций, которые лучше всего представляют функциональную часть этой программы в текущий момент. И если три буквы эту функциональную часть представляют хуево, то они отправляются на три буквы и придумывается что-то другое. И "нам нужно вынести Х в модуль на сишке и как-то его подключить ко всему остальному" это самая что ни на есть архитектурная задача, переписать и забенчмаркить сам Х это 10% от всей требуемой работы в лучшем случае, с этим даже ИИ справится.
>Опиши как связан ивент бас и механизм проброса зависимостей)
Это я у тебя спрашивал можно ли шину использовать как IoC.
Я хотел тебя подвести к разнице между design pattern и architecture pattern и потом показать пальцем. Но ты слишком тупой, маневр не удался, ты обосрался вообще на параллелизме.
>От тебя буквально нет никаких конструктивных тезисов, только смешные картинки или выдумывание слов мне в рот.
Когда собака на тебя лает, ты тоже становишься на четвереньки и лаешь в ответ?
А SOLID это design pattern или architecture pattern?
мимо
> У тебя каша в голове, чел.
Абсолютно никакоц каши. Цитируй, где есть противоречия или смешивания понятий.
> И скорее всего она из-за того, что ты ставишь знак равно между какой-то трехбуквенной залупой типа ECS и архитектурой.
ГДЕ ТЫ НАХУЙ ВИДИШЬ ЕЦС У МЕНЯ В ПОСТЕ?)))
Ецс да это архитектурный паттерн, с множеством вариантво реализаций.
> Архитектура программы - это не следование трем буквам как религиозной догме, а выявление и организация абстракций, которые лучше всего представляют функциональную часть этой программы в текущий момент
Я тебе и говорю, что абстракции могут функционально отлично сходиться и делать максимально поддерживаемо и чётко, но не проходить требования по перформансу.
> И "нам нужно вынести Х в модуль на сишке и как-то его подключить ко всему остальному" это самая что ни на есть архитектурная задача
Очевидно, что архитектурная. Только вот архитектуре это очевидео идёт ей в ущерб.
Или не в ущерб? Какие архитектурные качества модуль на си и маршаллинг с ним повышает?
При этом не смотря на ущерб архитектуре, очевидно это видимо правильно и необходимо в контексте проекта, и никто не говорит что так делать не надо.
> Я хотел тебя подвести к разнице между design pattern и architecture pattern и потом показать пальцем
Перечисли какие есть architecture pattern. Я уже выше спрашивал, но ты тактично заигнорил.
> Когда собака на тебя лает, ты тоже становишься на четвереньки и лаешь в ответ?
Нет, именно поэтому я отвечаю только конструктивно, не скатываясь на твой уровень.
>А SOLID это design pattern или architecture pattern?
Какой же ты тупой, это аббревиатура принципов.
>Я уже выше спрашивал, но ты тактично заигнорил.
Ты это и в гугле узнаешь. Я их все не помню, а копипастить с гугла удел таких как ты. Так что вперед и не стесняйся.
>Только вот архитектуре это очевидео идёт ей в ущерб.
А добавление фич в программу тоже идет в ущерб архитектуре, шизло? Там ведь могут быть фичи, которые на текущую архитектуру не ложатся и делают ей бо-бо. У тебя шизоидный оторванный от реальности взгляд на разработку с какой-то витающей в воздухе платонической архитектурой. Идеальная архитектура программы - это та, которая лучше всего переводит текущий функционал программы в набор понятных и логически связанных абстракций. Меняется функционал - меняется и идеальная архитектура. И оптимизационный модуль - это точно такая же функциональная часть программы, как и все остальное, с какого хуя ты его противопоставляешь архитектуре?
> А добавление фич в программу тоже идет в ущерб архитектуре, шизло?
Очевидно, очень часто может идти.
> Там ведь могут быть фичи, которые на текущую архитектуру не ложатся и делают ей бо-бо. У тебя шизоидный оторванный от реальности взгляд на разработку с какой-то витающей в воздухе платонической архитектурой.
Мне кажется ты просто нихуя не понял, про что я говорю, потому что я похоже говорил с другим аноном и ты влез в середине не понимая контекста.
Мы говорим про архитектуру в вакууме, зачем она нужна, что её улучшает, что ухудшает.
> Идеальная архитектура программы
Никакой речи не идёт о том что идеально и хорошо для конкретного проекта. Речь идёт о критериях качества архитектуры - модульности, легкости поддержки, когнитивной сложности. Все что делает это хуже - плохо с точки зрения архитектуры. Но может быть необходимо с точки зренич проекта.
>>А SOLID это design pattern или architecture pattern?
>Какой же ты тупой, это аббревиатура принципов.
>
>Букова D в SOLID о чем
Как это делает аббревиатуру паттерном? Шиз
Не аббревиатуру а сами принципы. Типо ты не смог понять о чем речь?
>Не аббревиатуру а сами принципы. Типо ты не смог понять о чем речь?
Ты без чатагпт плохой объясняешь. У тебя токены кончились?
Я правда не пойму о чем ты.
>Да, только копирует одни и те же данные миллионы раз по всей системе.
Состояние типичного геймплейного объекта не настолько большое и их обычно не так много. Это то место где производительность может быть принесена в жертву удобству.
>>1070422
>а выявление и организация абстракций, которые лучше всего представляют функциональную часть этой программы в текущий момент.
Но ты выполняешь программу на конкретном железе с конкретными ограничениями, а не на неком абстрактном процессоре в идеальном мире. Потому твоя архитектура обязана учитывать то на чём программа работает.
О том что ты словоблудием занимаешься.
То у тебя DI это не аррхитектурный паттерн, то SOLID не паттерны а принципы. Тем временем Губка Дядя Боб назвал книжку Чистая архитектура, где большая часть посвещена СОЛИДу.
>Состояние типичного геймплейного объекта не настолько большое и их обычно не так много. Это то место где производительность может быть принесена в жертву удобству.
У clojure есть оптимизация, если структура не меняет состояние - она физически копируется по ссылке везде, но как только изменяется, структура клонирует (вроде даже частично, не помню).
Ну все правильно, это набор принципов/рекомендаций.
И "D" это не про DI. Это про то что связанность должна быть реализованная на интерфейсах/контрактах.
Ты нюхал спринг и знаешь что инжектят только полиморфные интерфейсы.
>О том что ты словоблудием занимаешься.
Ты после сетевого Undertale что решил делать дальше?
Платформер)) не сетевой конечно, а вот что-то с претензией на сосалик, похожий на бласхемоус или момодору или соль и святилище. Тоже думаю делать в виде веб-версии. Арт и концепт на сей раз не скопированный а собственный (напрягаю нейродебила, затем подрисовую руками). Ну а еще помимо сосалика - в игре планируется внедрение очень особенного поджанра, и итоговая смесь должна получиться очень уникальной, местный анон точно оценит.
ты продолжаешь принимать меня за того анона, хз почему
Еще и три пятюни выбил.
ИДЁШЬ ПО ТВИТТЕРУ
@
ГЛЯДЬ, ДВИЖОК ИГРОВОЙ
@
ТВИТНУЛ ПРО "WOKE GAMES"
@
ЖОПА НАЧИНАЕТ РАСКАЛЯТЬСЯ
@
БЫСТРО, РЕШИТЕЛЬНО ФОРКАЕШЬ
@
МЕНЯЕШЬ ЛОГОТИП, НАЗВАНИЕ, ВСЁ
@
ОБЪЯВЛЯЕШЬ ДВИЖОК ВНЕ ПОЛИТИКИ
@
...УДАЛИВ ТОЛЬКО CODE OF CONDUCT
@
ТЕПЕРЬ НА ДВИЖКЕ МОЖНО ВСЁ
@
АБСОЛЮТНО, РЕШИТЕЛЬНО ВСЁ
@
ДАЖЕ ТЕ САМЫЕ WOKE GAMES
>>1070812
>ТЕПЕРЬ НА ДВИЖКЕ МОЖНО ВСЁ
>АБСОЛЮТНО, РЕШИТЕЛЬНО ВСЁ
>ДАЖЕ ТЕ САМЫЕ WOKE GAMES
Ну они же не против "WOKE GAMES" были, а против низкоквалифицированного менеджера (синдром вахтера) которому кнопку дали.
Есть такая особая категория ебланов что творят разнообразную хуйню с мотивацией мол "ну это же не запрещено прямо правилами" или "вот правила вот так можно прочитать". Таких ебанашек стоит банить просто с порога.
>Ну они же не против "WOKE GAMES" были
У них (республиканцев США) жопа взрывается от упоминания одного только слова "woke", и началось бурление говна именно из-за этого слова "woke", а блокировки только подлили масла в говношторм. Практически все блокировки были справедливыми.
Получается противоречие:
1. Ты категорически против "woke" (инклюзивности).
2. Ты создаёшь форк "без политики" и "для всех".
Суть в том, что code of conduct Godot требует от всех участников уважительного отношения к участникам, отсутствие дискриминации по полу, возрасту и т.д. Подорвавшиеся на слове "woke" подорвались из-за собственного расизма/сексизма и не более того; их корёжит от правила не быть расистом/сексистом в сообществах Godot, поэтому они это правило просто выбросили из Redot. Но в чём смысл это делать?
Логику расистов трудно понять. Это просто эмоции.
Насколько я понял, люди начали писать типа - занимайтесь движком у вас баги. Но вахтер с кнопкой обезумел и понеслось.
По крайней мере, про расизм посты я там не увидел, а что дофантазировал менеджер уже мало кого интересует.
Так что сгорела жопа у вахтера с кнопкой. Такое бывает когда сажают некомпетентных людей (я думаю как раз в этом основная проблема).
>занимайтесь движком у вас баги
А теперь подумай: кто будет писать в ответ на твит "поделитесь своими играми" что-то такое? И зачем? Занимаются движком и багами люди на гитхабе, а в твиттере сидит "комьюнити менеджер", который по определению не может никакие баги пофиксить.
Представь себе ситуацию: училка младших классов спрашивает маленьких детей-инвалидов - "покажите рисунки, которые вы за лето нарисовали", а тут мимо проходит человек, который ненавидит инвалидов и особенно детей-инвалидов, и начинает критиковать, наподобие "занимайтесь школой - у вас стены давно облупились". Естественно, что училка - не маляр и не директор школы, это не в её зоне ответственности. Возникает вопрос, как училке отреагировать? В её полномочиях "прогнать постороннего из класса"... Представь теперь, что этот человек потом начинает жаловаться и говорить "тут неправильно учат, я ща собственную школу построю с нескучными обоями". Интересно, будут ли в его школе дети-инвалиды?..
>Представь себе ситуацию
В этом и проблема вы от безделения начинаете накручивать и искать между строк проблему там где ее нет. Обращение типа - "делай свою работу" не несет в себе расизма. Это неприятно, но не расизм.
Конкретно SMM должен иметь устойчивый пердак чтобы профессионально работать, если у него пердак от твитта сгорает, нафиг он на этой должности вообще сидит (открою секрет, это SMM должен создавать движуху, но движухой не должна стать жопа самого SMM и как следствие лицо продукта/компании).
Расисты/хейтеры и прочие будут всегда. Нужен профессионал который будет с этим умело работать, на кону имидж продукта и комьюнити, а истерики могут подметать улицу.
В общем, пожрали говна все, даже комьюнити годота. Скорее всего на SMM сидит чей-то протеже, от чего ситуация усугубилась.