Токсим, срёмся, диагностируем шизофрению и объявляем крысу в хате тоже здесь.
Бесконечный тред для свободного общения.
Наверное, если ты выбираешь технологию для длительного изучения, не сильно критично будет 10 секунд в гугле потратить, чтобы узнать?
https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-programming-and-scripting
Круто, что они написали coding convention. Не нужно будет ломать голову как организовывать код.
Ты неправильно трактуешь ситуацию.
Это очередной бесполезный кусок дерьма, который тут форсит один шиз только потому он сделан(либы скачаны) в россии. Других достоинств у него нет.
А так тащи другие движки, тоже обосрем их.
В Nau Engine тоже есть стайл гайд.
https://github.com/NauEngine/NauEnginePublic/blob/main/doc/coding_style_guide.md
В принципе он довольно неплохой.
Есть пара моментов к которым я бы придрался.
20 стандарт - ну чтож, возможно когда начали делать 23 еще плохо поддерживался компилятором, но там есть вещи которые пофиксили. (тот же range-for проще писать - в примерах им приходится писать for size_t i=0;i<c.size();++i)
#pragma once это плохо, так как нестандарт и привязка к винде - потом придется вычищать вилкой при переходе на другие платформы.
Не использовать auto - ок внутри кода самого движка для ясности, но надо уточнить что в пользовательском коде это нормально. Да у них и в примерах он правильно используется.
То что RTTI запрещен это очень хорошо, но видел в коде NauRtti_TypeId , надо бы тогда уточнить что надо пользоваться каким то своим внутренним.
Скобки
{
}
- это моя личная неприязнь, так пишут только шарпомухи
нормальные крестовики всегда должны писать {
}
> В Nau Engine тоже есть стайл гайд.
Как это относится к разработке игр?
Ну, нау энжтн это же не инструмент для разработки игр, а попильный проект
Да ладно. Уже почти все сделано.
А мог бы делать на ФалькаЕнжин, который намного круче и от местного шиза.
Я пробовал, но поскольку фалько не опенсорс, то была виртуалка, а в виртуалке он не стартует.
То что он тут серит не делает его местным. Я его еще рсдн видел в прошлом веке. И много где еще
Ну так фалька давно делается (хотя ему движок на bgfx переписали, не помню когда это свершилось)
гений, если ты в вмваре запускал - то эти хуесосы принципиально не делают возможность проброса видеокарты в виртуалку
Имя ему - Иррлихт Энжин. Двадцать лет истории, опенсурс
Основные фичи:
High performance realtime 3D rendering using Direct3D and OpenGL [more]
Platform independent. Runs on Windows, Linux, OSX. Further platforms are in development and already used in projects.[more]
Huge built-in and extensible material library with vertex, pixel, and geometry shader support [more].
Seamless indoor and outdoor mixing through highly customizeable scene management. [more]
Character animation system with skeletal and morph target animation. [more]
Particle effects, billboards, light maps, environment mapping, stencil buffer shadows, and lots of other special effects. [more]
Several language bindings which make the engine available to other languages such as C#, VisualBasic, Delphi, Java …
Two platform and driver independent fast software renderers included. They have different properties (speed vs. quality) and feature everything needed: perspective correct texture mapping, bilinear filtering, sub pixel correctness, z-buffer, gouraud shading, alpha-blending and transparency, fast 2D drawing, and more.
Powerful, customizeable, and easy to use 2D GUI System with Buttons, Lists, Edit boxes, …
2D drawing functions like alpha blending, color key based blitting, font drawing, and mixing 3D with 2D graphics.
Clean, easy to understand, and well documented API with lots of examples and tutorials.
Written in pure C++ and totally object oriented.
Direct import of common mesh file formats: Maya (.obj), 3DStudio (.3ds), COLLADA (.dae), Blitz3D (.b3d), Milkshape (.ms3d), Quake 3 levels (.bsp), Quake2 models (.md2), Microsoft DirectX (.X)… [more]
Direct import of Textures: Windows Bitmap (.bmp), Portable Network Graphics (.png), Adobe Photoshop (.psd), JPEG File Interchange Format (.jpg), Truevision Targa (.tga), ZSoft Painbrush (.pcx)… [more]
Fast and easy collision detection and response.
Optimized fast 3D math and container template libraries.
Directly reading from (compressed) archives. (.zip, .pak, .pk3, .npk)
Integrated fast XML parser.
Unicode support for easy localisation.
Works with Microsoft VisualStudio, Metrowerks Codewarrior, Bloodshed Dev-C++, Code::Blocks, XCode, and gcc 3.x-4.x.
The engine is open source and totally free. You can debug it, fix bugs and even change things you do not like. And you do not have to publish your changes: The engine is licensed under the zlib licence, not the GPL or the LGPL.
Интересно, какое должно быть ебало, чтобы такой интерфейс сделать
То есть мне мало просто прописать значения позиции. Мне ещё нужно нажать кнопку [Set]. И после наверное появится Alert: "Вы уверены, что хотите изменить позицию?".
это поди корявая тулза сделанная наскоряк разрабом этого окошка.
ирлличт это насколько я знаю фреймворк. у него нет редактора
>Since version 3 of the library, it is recommended to use VMA_MEMORY_USAGE_AUTO to let it select best memory type for your resource automatically.
А помните как авторы этого кривого дерьма (vulkan) оправыдались тем, что "да разработчик лучше драйвера знает свой движок! Только сделав все вручную можно достичь лучшую оптимизацию!"
А теперь оказалось, что библиотечка решает лучше разработчиков.
И так во всем. В памяти, в барьерах, синхронизации: ручные решения не работают от слова совсем, потому что не масштабируются. В итоге все пользуются библиотечками.
Ну и в чем был смысл этих "низкоуровневых API"?
Считаю эксперимент провалившимся.
Это база чел
Если ты не пишешь так - ты не настоящий программист, а просто скриптовик залетный.
Нет. Ты совершенно не понял суть вулкана. Он именно о том, что будет полный лоулевел доступ, но будут написаны библиотеки, которые скроют всю эту сложность.
Где и кто говорил что все каждый раз каждому надо писать с нуля и изобретать велосипеды?
эти библиотеки называются драйверы
>полный лоулевел доступ, но будут написаны библиотеки, которые скроют всю эту сложность
это какой-то новый копиум. раньше вулкан именно презентовали как "старые API делают много непонятных вещей под капотом, вот сделаем новое API где разработчик будет всем рулить, вот тогда оптимизации раскроются!"
очевидно этого не случилось
Очевидно только то, что все бросили делать свои движки. Во всей индустрии 3-4 компании, у которых еще есть свой движок.
Если это такое лучшее API, то где движки на нем. Ой, их нет.
ААА движок один (re engine), и как он работает знают все. Оптимизировано что надо
Вроде же японцы никогда не славились сильными программистами? Но при этом они умудряются писать топовые движки и крутые игры.
Для юнити куча годноты японцами написано.
Vcontainer, unirx, unitask, memorypack. На них всё юнити держится.
KingSystem - Зельда ботва https://zeldamods.org/wiki/KingSystem
ModuleSystem - Splatoon 3 https://epd.zeldamods.org/wiki/ModuleSystem
Decima - Death stranding, Horizon Zero https://en.wikipedia.org/wiki/Decima_(game_engine)
Luminous - FF15 и форк FF14/Online https://en.wikipedia.org/wiki/Luminous_Engine
Hedgehog engine - разные соники
Еще куча мариокартсов, марио и прочих. (bezel engine, LunchPack)
Дарк соулсы на своем движке http://soulsmodding.wikidot.com/topic:engines
Cyllista Game Engine – Project Awakening https://ariabento.wordpress.com/2021/05/23/cyllista-game-engine-project-awakening/
Persona 5, Вроде бы на этом https://en.wikipedia.org/wiki/Katana_Engine https://medium.com/@aprilldean/persona-5-strikers-game-engine-9feee5846b6f
кроме десимы и ре энжина один калич, который заменяется любым 3д фреймворком
Ой да пашла эта Тим Свинья со своей уриной...
У них с 3 версии как пиздец начался, так и до сих пор не останавливается.
Хм, и правда. Сам эти пользуюсь (кроме memorypack). Японцы прям красавчики.
ну урина с древних времён известный поставщик мыла на рынок.
до сих пор помню, как на игры на движке 3 версии урины ставили решейды, чтобы избавиться от него...
бизнес и технологии так сказать
Они у них самые топовые. Буквально куча софта и сайтов. Просто они не хвалятся ими.
Ну есть сайт и есть. Зачем хвалиться?
> Они у них самые топовые. Буквально куча софта и сайтов. Просто они не хвалятся ими.
> Ну есть сайт и есть. Зачем хвалиться?
Тут вопрос не в том хвалитсч или не хвалится, а вопрос в зарабатывании денег.
Если что-то можно прорекламить и оно будет приносить деньги - это будет рекламить.
Юнити и анрил это продукты на которые найдется клиент, поэтому вливаются огромные дееьги в их продвижение.
Японские движки, видимо, не являются достаточно топовыми, чтобы на них нашлось достаточно клиентов.
У японцев деловые вопросы решаются личной встречей корпораций. И все это помноженное на закрытость корп типа нинтенды.
Поскольку движки ААА то и кто что на них разрабатывает известно.
У них просто нет цели продавать движки нищебродам с улицы.
Так же как никто тебе не продаст движок гта или баттлфилда.
Разработка движка для распространения среди индюков - это отдельный вид товара, не всем это интересно.
Юнити и анрил это не движки для индюков.
> У японцев деловые вопросы решаются личной встречей корпораций.
Откуда возьмется личная встреча по поводу твоего продукта, если про него никто и не слышал?
> Так же как никто тебе не продаст движок гта или баттлфилда.
Откуда тогда тйы знаешь, что они топовые, если они не распространяются за пределы компании?
>Юнити и анрил это не движки для индюков.
Юнити это буквально для индюков, на ней практически ни одной серьезной игры не делали
Анрил это была попытка продать не только индюкам но и ААА, но чет все на нем дружно обосрались.
>Откуда возьмется личная встреча по поводу твоего продукта, если про него никто и не слышал?
Кто надо тот слышал, через связи. Они все это в банях порешают.
>Откуда тогда тйы знаешь, что они топовые
>гта или баттлфилда
Ну даже хуй знает!
> Юнити это буквально для индюков, на ней практически ни одной серьезной игры не делали
Много серьёзных мобилок.
Можешь сказать, что мобилки - это не серьезно, а я скажу - посмотри на топовые мобилки, насколько они масштабные - сколько там систем, какие чудеса оптимизации проделаны, и сколько они денег качают.
То что тебе а них не интересно играть(или ты даже не пробовал) - никоим образом не умаляет их успешности и комплексности разработки.
> Анрил это была попытка продать не только индюкам но и ААА, но чет все на нем дружно обосрались.
Не знаю уж кто там обосрался, но анрил энжин живёт и процветает, на нём делают и делают игры.
> Кто надо тот слышал, через связи. Они все это в банях порешают.
А, ну тогда понятно. И как, много порешали? Напомни, какие игры на движке гта и батл филда сделаны.
> Ну даже хуй знает!
Игра это не движок. Исходники гта - это не то что можно было бы назвать "топовым движком", если подразумевать под этим понятием набор инструментов для разработки другой игры. А если что-то другое подразумевать - то что например?
>Юнити
Литерали для индюков. Особенно раньше это чисто индюковский вариант был.
>сколько они денег качают.
Вообще похуй. Это не относится к движку.
> какие чудеса оптимизации проделаны
Да никаких обычно. Или тормозит как говно, или "оптимизация" это отключение фич, дальности прорисовки, постобработки - ну так конечно если нет картинки то нет и нагрузки, но какое это имеет отношение к ААА?
Кстати на мобилках еще больше других движков используется. Тот же плейрикс в треде поминали.
>анрил энжин живёт и процветает, на нём делают и делают игры.
Ага а вот игроки ругают, и разрабы уже думают, а стоило ли переходить.
>А, ну тогда понятно. И как, много порешали?
Да, отлично порешали. На том же Frostbite разные студии игры выпускают, ага. А на RAGE выходила еще RDR. Получается, нормально для других игр, да.
> Вообще похуй. Это не относится к движку.
Буквально отвечаю на твой тезис - "юнити для индюков"
Мобилки делают индюки? Нет. И то сколько они зарабатывают - тому показатель - это очень крупный бизнес, а не индюки.
> Да никаких обычно. Или тормозит как говно, или "оптимизация" это отключение фич, дальности прорисовки, постобработки - ну так конечно если нет картинки то нет и нагрузки
Тут два проеба сразу.
1. А точно ли они тормозят из-за хуёвой/слабой работы над оптимизации, а не слабости мобильного железа и попыток запустить на нём что-то слишком амбициозное? На секундочку, на моьилки есть кал оф дюти, есть даже пубг и фортнайт которые работают даже на кусках говна.
И что забавно когда-то в пубг мобайл(мобильная версия была сделана тенсентом после релиза пк версии, пока разрабы пк версии страдали над ней) даже играли на пк, когда основная пк версия ещё работала хуёво, лол.
2. Любая оптимизация - может как иметь цену в виде урезания фичей, так и не иметь. Это относится и к пк и к мобилкам. На основании чего ты утверждаешь(ты же это утверждаешь), что именно на мобилках "ну просто отключают фичи)", а вот на пк-то ищут самые эффективные способы реализовать всё?
На пк кстати у тебя лодов нету, тени на всей дистанции одинаково четкие, объемные облака не жрут 10% фпс а потому выруюаются в настройках любым шарящим игроком без топового железа?
> но какое это имеет отношение к ААА?
Хороший вопрос.
Надо засинкать терминологию.
Ты упомянал:
Серьезные игры, как я понимаю это синоним ААК
Индюков
Я ввёл понятие "мобилки", в том отношении, что это тоже не менее серьёзные игры чем серьёзные пк игры и объяснил почему(масштабность проектов, затрачиваемые ресурсы на разработку, в том числе по части самоц разработки, а не только наполнения контентом)
Ты я так понимаю это не заметил, и выделяешь мобилки в отдельную категорию - не серьезные игры и не ААА. Почему?
Ну и бонусом, иут ещё такое дело... ААА и АА обычно обозначают бюджет разработки. А не то насколько игра тебе кажется серьезной или интересной или еще что-то.
> Кстати на мобилках еще больше других движков используется. Тот же плейрикс в треде поминали.
Точной статистики у меня нет какой движок насколько популярн, если судить по вакансиям - юнити такое ощущение сильно доминирует на мобилках, другие тоже присутствуют, но сильно меньше.
Но их присутствие заметно.
> Ага а вот игроки ругают, и разрабы уже думают, а стоило ли переходить.
Такой себе показатель, основанный на оценочных суждениях о том кто что-то сказал. По факту на нём куча игр крупных выходила и выходит и дальше.
А если оценочные суждения давать - так я тебе могу сказать, что анрил хуево подготовлен к большим открытым локациям, и для этого действительно самые крупные компании свои средства имеют и анрил им нахуй не нужен. Ну так, по моим ощущениям по тому, что я знаю.
> Да, отлично порешали. На том же Frostbite разные студии игры выпускают, ага.
Ага, разные студии) Только вот все они - внутренние студии ЕА.
А я напомню, ты говорил, что простым работягам про закрытые движки знать не обязательно, бизнес кабанчиком метаетсч и договаривается, только вот как мы вилим ничего подобного - движко ющаетсч внутренними студиями одного издателя и больше никем.
Хотя пример тем не менее годный, не для этого аргумента, а как пример закрытого движка который вероятно годный - так как на нём дохуя разных игр делают и несколько студий его успешно юзают.
Но всё в рамках одной компании.
> А на RAGE выходила еще RDR. Получается, нормально для других игр, да.
Это движок рокстаров. Кроме них кто им пользуется?
Мог бы CryEngine привести в пример - вот он живее всех живых, его кто только не юзает.
>Не знаю уж кто там обосрался, но анрил энжин живёт и процветает, на нём делают и делают игры.
Впереди, однако, ждут интересные времена. Столько разрабов перешло на 5 анрил, начав делать своё детище. При этом, некоторые уже провалились и сидят ноют, что деняг теперь нету. Покупать игру не хотят. В чём же дело, знает кто?
Вот что бывает, когда забываешь о том, что делать игры - это нихуя не легкий процесс, а тяжелый труд. Вместо этого урина чё там предлагала?
Облегченная разработка игор? Забыть об оптимизации? Скоратить половину сотрудников, поскольку не нужны юниты теперь, которые отвечают за какую-то, но свою одинаково важную работу? Урина определенно уплатит за эту потерю.
Выстрел самому себе в ногу как я щитаю в принципе, связываться с UE5.
Хотя Total Chaos на 5 урине жду.
Причем тут движок и обсер игры? Ты бред какой-то несешь. Если игра говно, то она провалится независимо от движка, анрил там под капотом или бздотя энжин
А на анриле много известных и хороших игр сделали за десятилетия, для ааа там пайплайн никак принципиально не изменился с третьей версии, со времен условного биошок инфинити
Такова судьба популярных движков. Все уже позабыли наплыв говна на пике популярности юньки и как его лого стало ассоциироваться со школьными высерами и ассетфлипами?
Анрил изкаробы даёт возможность выдавать топ графен. Но без навыков, всё что смогут школьники это выдавать плохо оптимизированные, скучные поделки с ААА графоном, похожие друг на друга из-за нетронутых настроек.
Ну, на юнити не школьники могут написать свой SRP и игра не будет похожа ни на одну игру в принципе. Хотя спалить можно конечно.
На урине- пиздец... В далёком 14 году одна студия сделала оч красивую игру, и до сих пор ни одной игры так и не вышло похожей.
А на юнити уникальные вещи почаще встречаются.
(1-2 пик - юнити, 3-4 - урина.)
>А на юнити уникальные вещи почаще встречаются.
Хз, у меня вот глаз намётан палить юнитиподелки по похожему рендеру, также как и анрил. Например Subnautica и Outer Wilds словно одними и теми же ребятами делалась. Но мне и норм, главное чтобы игра весёлая была, и обе легко войдут в мой топ.
Субнаутика и аутер вайлд были написаны еще в те времена, когда срп не было, пожтому мало заморачивались с кастомизацией рендера - не целесообращно было.
А теперь можно, но это опять же опция для тех у кого очень много ресурсов на разработку.
Клоун ебучий, на анриле десятки стилизованных игр в уникальных стилях
>А теперь можно, но это опять же опция для тех у кого очень много ресурсов на разработку.
Тогда откуда ты высрал
>юнити уникальные вещи почаще встречаются
Это не я писал, и субнаутику с аутер вайлдс в пример привел ты сам.
Ты о чём? На 5 урине таких нет, поскольку даже вода выглядит как масло какое-то.
Вот если заменить на текстуру говна, будет уже философская хуйня о движке.
Покажи еще хоть один движок, который из коробки умеет в твой видрил
Это народный движок, нюфаня. Он всегда славился сторонними разработками. Например, они уже давно пытаются добавить нормальный сетевой движок, но у них не получается. Вместо этого люди используют различные сторонние решения, которые отлично реализованы.
ну какой им сетевой движок, им бы с грид снэппингом разобраться для начала
Потому что пользователь (не сотрудник Юнити) написал хэллоуворлд в стиле "мой первый ассет" и выложил в стор, ему это никто не может запретить.
>>1016164
Баран, это пользовательский ассет.
https://www.stride3d.net/
да чёт походу кроме урины4 и юнити - выбора особо то и нету.
есть если стоит цель 2д игру делать.
а если 3д - либо юнити, либо ue4.
годот сырой, не понянет чёт среднее и с норм графоном.
а ебаться с дописыванием исходников годота - это ещё хуже чем дописывание урины.
да и сам вопрос, где быстрее будет вкат - неоднозначный довольно тоже.
с одной стороны c# на юнити, с другой урина с блюпринтами и в будущем C++.
я на урине не разрабатывал, но мне кажется на ней намного легче обосраться с оптимизацией и даже сразу не понять этого
Так без хака винды не получится же, выясняли. Я находил игру в которую лет 10-15 назад играл и там работало, а теперь хуй, нужная фукнция винапи возвращает облом. Придется как то драйвер писать и подписывать, так как игрока просить отключать проверку подписи - все нахуй пошлют.
ну смотри, ты делаешь какую-то систему в игре и делаешь её синглтоном
например, систему диалогов или систему квестов
а если одновременно можно вести два диалога? а если ты добавишь мультиплеер, и система квестов у каждого игрока своя? придётся переделывать синглтон на сервис, например
вот то же самое и с кнопкой - если она мультиплеерная, придётся переделывать
Ну тебе по сети приходит команда "interact(player_id, object_id)" это значит такой-то игрок провзаимодействовал с таким-то объектом (кнопкой например).
Сейчас я подробности забыл, поищу в треде.
Идея в том, чтобы два игрока мышкой пытались отобрать друг у друга кнопку. У меня есть несколько мышек, но винда позволяет управлять только одним курсором. И если кликнуть по второму окну, другие потеряют фокус (ввод с клавиатуры/геймпада).
Ответ:
Я еще лет 20 назад играл на винде в хотсит матч-3 с несолькими мышками. Очевидно это можно закодить самому (различать USB мышки по HID?) или поставить какую то прогу мультиплексор, правда на гитхабе опенсорсных не нашел.
https://web.archive.org/web/20100706162106/https://store.steampowered.com/app/7440
>Using the revolutionary Mouse Party, you can play with multiple players on the same computer
>OS: Windows 2000, Windows XP, Windows Vista
>Release Date: Dec 22, 2004
Плохие новости - винда блокирует чтение через HID мышки чтобы мешать кейлоггерам
https://github.com/signal11/hidapi/issues/247
Хорошие новости - как то же эти три-четыре проги работают
https://softwarerecs.stackexchange.com/questions/79650/need-two-mouse-pointers-on-windows-10-11
https://forums.developer.nvidia.com/t/vk-khr-present-wait-issues-stuck-frames-in-winewayland-gamescope/326248
к вопросу о том, почему на вулкане не делают игры...
с opengl и тем более vulkan лучше не связываться
на amd, intel 100% вылезут какие-то ошибки
единственное API которое ПРОСТО РАБОТАЕТ это directx, потому что только его полируют для поддержки ААА-игр
с unreal и тем более godot лучше не связываться
>почему на вулкане не делают игры...
Че несет клоун, живущий в выдуманной параллельной реальности.
Не смог осилить перепечатать хелло ворлд на вулкане, и теперь тратишь время на поиск оправданий вместо создания игр?
https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games
>wine wayland
Ну то есть эмуляция кала (винды) в поттерингоговне (вейланде)
Если 4 версия была уже раздутой и перегруженной всяким говном, то что о 5 говорить... Движок не для игр.
Клоун, не смеши.
На уе5 уже овердохуя игр вышло с момента его релиза. И будет еще больше.
Даже в случае уе5 99% размера билда игры - текстуры, звуки, анимации. Движок там нихуя не весит на фоне остального.
Но ты безыгорный, поэтому тебя видимо очень беспокоит размер пустого проекта. Даже он у анрила приемлемый, уже давно у всех терабайтные ссдшнки стоят.
Дододо.
Физики сломанной в 5 урине не было ни разу, её придумали себе безыгорники. А в 4 версии у физикса нет симуляции колёс, вместо них шарики, т.к просто не имеет математической модели коллайдера под колёса, в отличии от юнити где это всё есть.
Не говоря уже о том, что там у персонажа встроенного в 5ке какие-то чеки и проверки постоянно на фоне работают, которые просто так не отключить.
И это любой чел который работал на 4 урине скажет, что это дико раздутое ПО с коробки.
Чисто СЛОП-движок с мистическим величием, который выполняет тем не менее свою работу как-то +-
Ну то есть ты не разобрался как что-то там настроить или отключить в твоем хеллоу ворлде, поэтому решил высраться?
Ну так ты безыгорный, для тебя все движки нерабочие, потому что ты ни на одном ничего не сможешь сделать.
>там настроить или отключить
Т.е мне надо переписать весь движок физикса в урине, чтобы получить то что мне надо?
Лучше на хуюнити дальше сидеть в таком случае, и иметь такие вещи серьезные уже с коробки рабочие, чем изобретать велосипеды на велико-гойском уринале.
>для тебя все движки нерабочие, потому что ты ни на одном ничего не сможешь сделать.
Главное повторить мантру: урина всеголишь инструмент, и то, что он хуёво работает - виноваты разработчики игр, безыгорники, перфораторы и бетономешалки. Это они сделали такой хуевый базис-фундамент движка. А никак не те, которые его изначально проектировал.
>А в 4 версии у физикса нет симуляции колёс, вместо них шарики, т.к просто не имеет математической модели коллайдера под колёса, в отличии от юнити где это всё есть.
цилиндр штоле?
там как бы со времен царя гороха есть целый темплейт с симуляцией подвески, колес и т.д., как в ЖТА 4
что ты там на голом физиксе цилиндрами наговноделал, не прибегая к кастомным контроллерам, даже представлять не надо: типичное юнитиговноделие от юнитиговнодела
>>1016703
мало того что билд не запусается минимум у 10% потреблядков, так ещё и редактор не хочет нормально работать
Думайте. Годотнуться.
Вышло много, но тормознутых игр даже на самых топовых пк. То есть лучше бы не выходили.
Все так, поэтому свои игры я делаю на 3-м годоте, там опенжл.
Годот - это движок для вечного подпивасного васянства, типа старого Москвича в гараже, в котором можно копаться каждый день, но ехать на нём куда-либо просто опасно.
>кроссплатформенный
почему 10% потреблядей не может запустить это дерьмо?
>альтернатив ему нет
есть
>2 игры в месяц, а если постараться можно и игру в месяц делать
выблядки делающие 3 в ряд, тут? на месте?
У разраба Круелти-сквада уже крыша едёт от гуньдота. То есть знак как-бы да, что не стоит использовать это чудо для игр.
>почему 10% потреблядей не может запустить это дерьмо?
Спрашивай производителей бракованного железа. На таком у любых будут отказы (собственно я об этой проблеме и узнал от юнити, лол)
>есть
Если бы альтернатива была, я бы ей уже пользовался, но мы тут перебрали уже десяток, и во всех чего-то не хватает, годот просто есть и работает.
>выблядки делающие 3 в ряд, тут? на месте?
Не знаю, я делаю нормальные интересные уникальные игры
ты просто копаешься в годоте, как васян перебирает мотор своей ласточки в гараже
Так на любом движке при серьезной разработке тебе придется копаться, на той же юнити пользоваться готовым практически невозможно и все пишут свое. А так, любой инструмент должен быть свободным и открытым, а не как юнити отправлять запрос на проверку лицензию к барину и надеяться что он одобрит.
ты совсем в аналогии не можешь? я о том, что это хобби-деятельность
копайся себе в удовольствие, только за пределы гаража не выезжай, да и не заведётся она у тебя
>физикса в урине
Че несет клоун? В анриле chaos уже года 4.
Ты сейчас обсасываешь проблему, которая не существует уже 4 года, вместо того, чтобы делать игры.
>выблядки делающие 3 в ряд, тут? на месте?
Не надо про 3 в ряд пиздеть, это алгоритмически сложный жанр, ты вряд ли осилишь такое запилить. Топы жанра уровня homescapes это большие бюджеты, большие команды и годы непрерывной разработки.
Тот чел скорее всего делает игры про прыгающий кубик на черном фоне, иначе хз еще как объяснить "2 игры в месяц".
>Не надо про 3 в ряд пиздеть, это алгоритмически сложный жанр, ты вряд ли осилишь такое запилить. Топы жанра уровня homescapes это большие бюджеты, большие команды и годы непрерывной разработки.
покажи сложную задачу оттуда
Да там много всего, на самом деле. Просто ты не пробовал делать, поэтому у тебя ошибочное заблуждение, что это просто. Алгоритмов в разы больше, чем во многих "трушных" жанрах типа условных платформеров.
Начиная от движения фишек и поиска матчей (для этого нужен детерменированный пошаговый резолвер ходов с диагональным движением, есть разные варианты, кто-то на графах пишет, кто-то на клеточных автоматах, это нетривиально, уже на этом этапе можно отведать не один десяток хуев, отлаживая корнеркейсы), и заканчивая генераторами уровней и ИИ агентами для автоматического прохождения. Это еще без учета десятков вспомогательных механик, которые сейчас есть в любом 3 в ряд из топа рынка.
Просто скачай homescapes и поиграй час, если ты думаешь, что это просто сделать - то ты либо слепец, либо никогда не делал игры.
Нейродебил, ты опять на связи? А теперь реализуй это все в графическом интерфейсе, т.е. в виде реальной работающей игры. Еще чтобы на алгоритмы влияли айтемы и пейволлы.
так и в чем сложность? все разработчики игры с этим как-то справляются
просто признай, что никаких сложных алгоритмов там нет, и команды программеров если и есть, то годами разрабатывают лишь друг другу очко, а не сложные алгоритмы
ты ебучий хуесос, я знаю про сложность этого дерьма, 3 в ряд - это не игра, а наёб гойских потреблядков
>>1016857
Дураки, простофили.
Современный 3 в ряд это:
1. Сюжетка с катсценами
2. Десяток валют, десяток магазинов, акции
3. Ачивки
4. Квесты - дейли, месячные, сюжетные
5. Симулятор сити билдер со строительством базы
6. Кастомизация персонажа
7. Мини игры
8. И наконец, 3 в ряд, с десятками видов фишек с разными механиками, анимированной доской, автобалансером сложности и системой спавна фишек с учетом комбинаций
Самое смешное то, что dx11 версия работает быстрее
>Самое смешное то, что dx11 версия работает быстрее
а дх9 вообще всех ебёт
это всё необязательно для три в ряд
"гоночки" это не значит "гта с минииграми и ограблениями банков", это именно что "гоночки", свой разросшийся до состояния раковой опухоли метагейм засунь себе в задницу
Выше был вопрос "выблядки делающие 3 в ряд тут?", а не вопрос о минимальной простейшей реализации матча в 3 в ряд.
Делание 3 в ряд подразумевает ебанутый метагейм, по-другом3 3 в ряд сейчас не делают вообще.
Клоун, то, что ты высрал на пике - это не рабочий сблев. Оно в принципе не будет работать корректно. Матчи нельзя сложить в общий сет, за каждую фигуру дается разная награда (большие фигуры превращаются в бомбы, средние в другие бонусы и тд), плюс фигуры есть разные, даже в самом примитивном 3 в ряд кроме простых цепочек надо уметь матчить квадраты 2 на 2, пересечения 3 по вертикали + 3 по горизонтали, причем делать это в порядке приоритетов (если сматчили большую фигуру с высокой наградой, эти фишки потом не участвуют в матчинге более простых фигур).
То, что ты припер этот высер - только доказывает то, что ты безыгорный клоун, ничего не понимающий в программировании и геймдеве, и не смог сделать бы даже простенький 3 в ряд. Не позорься.
Ты в три в ряд играл вообще? Там заранее нет комбинаций на поле, чтобы получилась комбинация, игрок должен свапнуть две фишки.
Плюс сматченные фишки пропадают с поля и сверху падают новые, они двигаются по алгоритму типа падения песка в noita, но со своими нюансами.
А сложность уровней определяется доп. механиками, бывают замороженные фишки, которые надо разморозить, всякие порталы, бывает надо сначала надо собрать весь под под фишками и т.д, там овердохуя всего придумали.
Сделать хотя бы кор механики топовой 3 в ряд, даже без учета меты - нетривиальная задача.
Сделать несобранные комбинации, очевидно. Чтобы на стартовом поле гарантировано что-то собиралось. Потом подсыпать случайно или можно считать типы элементов на поле и подсыпать таких.
Ты переусложняешь. В этом нет ничего сложного.
> не рабочий сблев
возложенную на него функцию выполняет
> Матчи нельзя сложить в общий сет
такой задачи не стояло. алсо, просто возвращаешь первый матч, если тебе не нужно
>за каждую фигуру дается разная награда
sum(x.nagrada for x in match)
> кроме простых цепочек надо уметь матчить квадраты 2 на 2, пересечения 3 по вертикали + 3 по горизонтали
это еще 20 строчек нейросеткой
> большие фигуры превращаются в бомбы
задача добавления единички к индексу во все стороны
>делать это в порядке приоритетов
sort(key=lambda m: m.priority)
а зачем ты пёрнул, что нельзя совать матчи в сет?
> То, что ты припер этот высер - только доказывает то, что ты безыгорный клоун, ничего не понимающий в программировании и геймдеве, и не смог сделать бы даже простенький 3 в ряд. Не позорься.
то что ты задачку парой вложенных циклов на 10 строчек называешь задачей века которую нужно решать годами доказывает, что ты лох педальный, а не программист. натуральный дегрод, перекладыватель ямлов и смузихлёб
и всё на примитивном уровне. редактор персонажа уровня замени тело в костюме на тело в спортивке. строительство базы уровня floor.upgrade = 3, walls.upgrade = 2, furniture.upgrade = 0. мини игры уровня собери разорваное фото как пазл, квесты уровня надрочи 10 уровней. обычная бытовуха с задачами, которые решают абсолютно все
алсо дискуссия про ахуительные алгоритмически-сложные игры в этом жанре превосходящие другие игры, где дэбил вспомнил все умные слова которые знает, попытавшись создать вокруг матч3 кала ореол мнимой значимости
Это все легко делается.
Блять, гача уровня Блю арчив и то сложнее.
Ты не шаришь, не позорься. Сомневаюсь, что ты вообще хоть раз в жизни писал код. Даже змейку скорее всего не осилишь написать, не говоря уж про 3 в ряд.
Лол, только посмотрите на эту чмоху, сгоревшую от осознания того, что она даже 3 в ряд написать не в состоянии.
>возложенную на него функцию выполняет
Так запусти его и покажи что он там выполняет.
Что, не запустится? Это просто картинка с высером из буковок, которая не имеет отношение к реальности? Вот и мне так показалось.
Реальный код можешь посмотреть на гитхабе, если интересно.
Простейшая реализация кор механики без наворотов - тысячи строк кода. Но ты вряд ли сможешь столько прочитать и осознать, это ведь больше, чем обычно нейронка тебе выпукивает.
https://github.com/ninetailsrabbit/match3-board/
аргументация у дебила закончилась? пынимаю
>>1016943
это алгоритм поиска матчей. алгоритмы не "запускают", дебил. их изучают. пишут на их основе софт, который и занимает
> тысячи строк кода
но самих алгоритмов там 50 строк
остальное это программирование игровых кнопачек да эффектиков и никзкокачественные простыни копипасты. смотри, у него на 257 строке копипасщенная функция не работает, говнокодер этот баг даже не заметил
На пике код джуна который бы никогда не пустили в прод.
> но самих алгоритмов там 50 строк
> остальное это программирование игровых кнопачек да эффектиков и никзкокачественные простыни копипасты.
Большая часть любого прикладного софта и игр, это ебанутая бизнес логика на оопе с впихиванием невпихуемого.
Там не покопипастишь, там надо думать, как сделать, чтобы оно не превратилось в пиздец и с этим можно было работаьь дальше.
>>1016943
Ты по делу говоришь, но
> Реальный код можешь посмотреть на гитхабе, если интересно.
> Простейшая реализация кор механики без наворотов - тысячи строк кода. Но ты вряд ли сможешь столько прочитать и осознать, это ведь больше, чем обычно нейронка тебе выпукивает.
>https://github.com/ninetailsrabbit/match3-board/
Стоит учитывать, что на гитхабе реального кода не найдешь, 99% это трешак пиздец. Это пример судя по всему не исключение.
>>1016922
> и всё на примитивном уровне. редактор персонажа уровня замени тело в костюме на тело в спортивке. строительство базы уровня floor.upgrade = 3, walls.upgrade = 2, furniture.upgrade = 0. мини игры уровня собери разорваное фото как пазл, квесты уровня надрочи 10 уровней. обычная бытовуха с задачами, которые решают абсолютно все
Не. Намного сложнее и всё должно быть скомбинировано со сложным визуалом.
А на добив то, что это всё должно работать на самых слабых телефонах
>Не. Намного сложнее и всё должно быть скомбинировано со сложным визуалом.
не смеши. примитивный геймплей + примитивные системы + примитиваные алгоритмы (пока дебилоид выше не доказал обратного на примере)
> ебанутая бизнес логика на оопе с впихиванием невпихуемого
Чтобы так не получалось, нужно предпочитать компоненты наследованию.
Если делать так, то игры никакой не будет вообще. Такой подход не пригоден для меты совершенно.
Ты пишешь о вещах, в которых ничего не понимаешь, и которые не смог бы сделать сам. Не позорься, это выглядит жалко
Смотри, нейронка написала нам гта 6. А значит, что такую игру просто сделать и там простые алгоритмы. Еще строчек 10 добавить и норм.
Ебало дегенерата и представлять не надо.
>Это пример судя по всему не исключение
Ну это понятно, что там не топы из маркета свой код заливают, а просто чуваки, которые учатся. И что здесь нет и десятой части того, что есть в полноценных 3 в ряд. Но это хотя бы рабочий код, который запускается, а не нейросетевые фантазии в картинках умственно-отсталого дебила.
Вот поиск матчей, например, тут можно увидеть, сколько корнеркейсов и условий, одним тупым проходом по массиву на 10 строчек это не решается.
https://github.com/ninetailsrabbit/match3-board/blob/main/addons/ninetailsrabbit.match3_board/src/modules/sequence_detector.gd
Вот пример на графах
https://github.com/youssefmyh/Match3Algorthim/blob/main/Match3Algorthim/Match3Graph.cpp
Вот пример на луа под дефолд, тут только простейший кейс с вертикальными линиями, без сложных фигур, но уже 1000+ строк
https://github.com/britzl/emthree/blob/master/emthree/emthree.lua
Но полноценные игры уровня homescapes в разы сложнее, конечно, и они свои алгоритмы не сливают в открытый доступ, повторить на их уровне это очень нетривиальная задача.
>Казакша
шиз, ты опять ебыря своего потерял.. тогда причина твоего подрыва ясна.
да не трясись ты свинота ебучая обрыжная, моглизуйся и пиздуй бахмут освобождать
нихуя ты бахаешь, сочные вибрации.
т.е. твой ебырь таки хохол, а не казах.. ясненько
а ты ублюдок поганый проси её чтобы писала коментарии в коде
ход в матч-3 просто меняет местами 2 фигуры. это настолько простая игра, что можно брутфорсить все ходы и перебрать все искомые комбинации за наносекунду
Главное на собеседовании такого не ляпни, а то тебя в чёрный список внесут.
Я как то делал игру с такой же мехой.
Реализовал через костыль обычным перебором цикла for с индексом в числе по которому выбиралась нужная глубина.
Если просто это была рекурсия которая выполнялась количество раз, которые подавалось на вход.
> зацените
_нейбор_хас_пис_базе(нейбор: Нейбор) -> буль: ретурнь нейбор и нейбор.хаз_пиз()
нейбор_райт_хас_пис() -> буль: ретурнь _нейбор_хас_пис_базе(нейбор_райт)
Не оценил.
Кроме хода в матч 3 еще миллион механик и алгоритмов.
Алсо, ход это не просто поменять местами две фигуры. Ты не видишь дальше своего носа, потому что не написал ни строчки кода в жизни и не сделал ни одной игры.
Надо поменять, проверить матчи, если нет, вернуть фигуры назад. Если есть матчи, надо разрезолвить их, убрать с поля все фигуры и вместо каждой заспавнить и активировать соответствующий бонус (бомбу, самолетик и т.д)
После активации всех бонусов, часть фишек пропадет, к оставшимся надо применить клеточный автомат и продвинуть их вниз, заспавнив при этом новые фишки сверху поля. При этом тоже могут образоваться матчи, если так получилось - надо убрать их с поля, опять активировать бонусы и рекурсивно продолжать симуляцию клеточного автомата, пока поле не стабилизируется. При этом надо подсчитать сгоревшие фишки, обновить цели уровня (собрано ли нужное кол-во очков, фишек и тд), проверить, остались ли еще ходы, или пора завершать игру. И это только один ход.
Хотя кому я это объясняю, объяснить как работает игра безыгорному нейродебилу это тоже самое, что объяснить астрофизику свинье, она продолжит хрюкать с умным видом, но не поймет не слова.
А ещё в играх есть красивая графика, партиклы, анимации
СТРАШНО ВЫРУБАЙ
как же всё это сложна. посчитать фишки и проверить остались ли ходы. боюсь тут придется приенить алгоритм IF ELSE
Ну да, все остальные пункты мы проигнорируем, потому что непонятно, зацепимся за единственное слово, которое слышали раньше, пукнем что это просто.
Проконсультируйся у нейросети, клоун, может научит тебя делать игры. Начни со змейки для начала, в более сложные вещи тебе пока точно лезть не стоит.
Это целый отдельный мир, плюсом еще управление, как сделать сочный фидбек, чтобы игрок получал спинномозговой кайф от ходов, там тоже куча своих тонкостей, как фишка должна реагировать на клик, с каким изингом должен проходить свап, сжатия, растяжения, партиклы, звуки, эффекты от бонусов. Это для всех игр актуально, но в 3 в ряд прямо плотно переплетено с кор механиками и сильно их дополняет.
В эту степь даже не лезем, нейродебил игры никогда не делал, поэтому не в курсе про такие тонкости, это для него будет слишком абстрактно.
нейросеть рекомендует применять алгоритм IF ELSE и иногда FOR. подскажи научных работ по этим алгоритмам плиз, я вижу ты мощнейший программист
> как фишка должна реагировать на клик, с каким изингом должен проходить свап, сжатия, растяжения, партиклы, звуки, эффекты от бонусов
Тут важно отметить, что это всё должно быть вынесено в настройки для артистов и у них должна быть возможность быстро просмотреть результат.
Тебе, безыгорному клоуну, обосравшемуся и обоссавшемуся под себя на весь тред, смешно, а по 3 в ряд есть научные публикации.
Не надоело позориться?
https://www.mdpi.com/2079-9292/12/21/4456
https://www.mdpi.com/2079-9292/12/19/4098
когда покажешь алгоритм отличный от проверки переменной ифом?
Вы приняты в русскую фирму!
Как же я ору с того что самую простую механику пытаются выдать под топ.
Даже nikke сложнее всех ваших 3 в ряд.
Фидбек блять, лол
Как же я ору
согласен, мячтри очень сложно
поэтому ты ее делаешь уже 3ий год
программирую матч 3 алгоритмы по проверке оставшихся ходов
пишу свой движок и свои графические библиотеке на своей ОС на своём языке программирования на собственноручно сделанной плате
>Шиз, спок
>вы шизы
Я гордо заявляю на весь тред - Я ШИЗ.
Я ШИЗ потому что решил делать игры и выкладывать их бесплатно.
Я ШИЗ потому что за место зарабатывания денег, трачу все время и силы на разработку игр из моих мечтаний не получая за это ничего.
Я ШИЗ потому что сижу в этом треде и пишу этот пост.
Чем больший процент ЛГБТ+ среди игроделов, тем круче, прогрессивнее и современнее движок.
Итак, кто лидирует на данный момент?
>Итак, кто лидирует на данный момент?
Юнити. У них на докладах постоянно трансгендеры выступают.
Nau в кавычках Engine выходит в моментальные лидеры с большим отрывом
Урина ака нереальный движок ака Unreal Engine.
Количество трансов и лгбт+ персон в комьюнити, которые как-то да отсвечивают в соц.сетях либо по стримам на твиче - прямо таки зашкаливает.
Другой вопрос сколько на языках различных сидит.
На C++ и RUST так-же почему-то аномальное количество всяких фурри-сьютенров и трансов.
[Хз почему-так, видимо язык сложный, башню клинит.
Хуита, считать надо, я когда в юньке работал постоянно натыкался на обучалки от трансух, Wokot сам себя так провозгласил. Эра пидерастии такая, но она подходит к концу.
>подходит к концу
Долбоеб, она только начинается. Готовься скоро видеть такую педерастию которую мир доселе не видывал. Детятки щас бесконтрольно через интернеты самоиндоктринируются. Когда подрастут ты охуеешь прост.
Всё идёт к строительству Рая на Земле.
Для элиток...
>>1017329
Ты допилил говорящую голову?
Банально не использовать её, а изучать предмет.
Нейронки это трюк, наебалово. Вот здесь можешь узнать почему текущие модели никогда не будут осмысленно отвечать.
https://www.youtube.com/watch?v=-wzOetb-D3w
Не используй компилятор, конпелируй сразу головой в двоичный код, а то это ж трюк блять. Или ты хочешь сказать что половина существующей кодовой писанины это не унылый бойлерплейт и тасование данных по массивам, а высокохудожественное недоступное нейронке произведение с глубоким абстрактным смыслом? По мне так как раз наоборот. Потому я и прочие нейрогоспода будем напрягать нейронку на поработать за нас, пока неолуддиты будут закидываться копиумом и увеличивать разрыв с нами по производительности. И кстати не надо думать что кодить с нейронкой это манна небесная, ведь надо думать и за себя и за того парня, что только увеличивает нагрузку на голову и не даёт время на остыть покуда идёт реализация, так как реализовала нейронка, а ты просто должен проверить.
Чел, ты вообще суть то уловил? Всё что делает ии генерирует символьную чушь. Он не формирует никакое абстрактное ядро, сколько его не обучай. Он буквально необучаемый, по крайней мере все современные лингвистические модели. Которые просто пытаются угадать ответ сидя на большой базе данных.
О каком написании кода с такой фигнёй вообще заикаться. Её потолок подглядеть типовые реализации со стак оверфлоу и то всё переврёт 10 раз.
Я все время вижу какието не понятные срачи где одни говорят нейронка мастхэв ТОП, а вторые говорят что кал и не нужно, нет души.
Так вот вопрос - Какой смысл срача если кто хочет использует, а кто не хочет нет?? К чему все это??
Аналогичные же срачи были за винду/линукс и еще подобное, зачем?
Если у тебя приходится писать много бойлерплейта, то что-то не то с языком/движком, смени на нормальный, где есть шаблоны или хотя бы макросы.
Посмотри сам и сделай свои выводы.
Большая часть "срачей" - недопонимание позиции друг друга
https://habr.com/ru/news/898442/
Как я тебе рожу макрос на инит nodepath в годоте? Или макрос на фабрику? Не слыхал о языках которые умеют думать вместо программиста. А нейронке я скормил интерфейс, описал логику и вуаля. Либо скормил объявление класса с логикой и получил результат.
Ты решил раскрыть суть того, как именно я сформулировал твою позицию в своем посте и перепечатать ее другими словами? Благодарю, но это излишне. Чиобы конкретизировать, назову сценарии где бредогенератор на редкость удачен - изолированные фичи с четкой задачей которую алгоритм должен решать, успех от 0 до 70, зависит от степени редкости задачи и количества этапов обработки данных. Если этапов меньше 5 - почти всегда вин. Инициализационные портянки - почти всегда вин, если дать пример уже существующей портянки из проекта либо это известный nodepath сценарий. Формошлепская обвязка - скормить ей контролы с с названиями и описать их логику - почти всегда вин. Переложить массивы - зависит от количества этапов перекладывания. Если описать этапы с конкретными задачами без деталей реализации - почти всегда вин. Методы расширения - вин. Как ты заметил - абстракциями тут и не пахнет. Но нейронка умеет подражать и знает популярные кодовые вещи, что позволяет ей подражать ещё веселее. И сценариев на самом деле гора, это то что я вспомнил. Можно заставить переводить с языка на язык, переводить с движка на движок. Выдаст съедобное.
Гуньдотеры хуже шизов. Изучать гуньдот - неуважать своё время.
C++ позволяет писать и макросы и шаблоны избавляя от бойлерплейта в юзеркоде.
тоже в итоге пришел к его аналогу.
алсо, игрался с созданием редакторов для своего движка.
Чтоб пользователи могли делать игры на нем.
для новелок создал за пару дней.
для рпгшек за месяц
для всего остального это слишком долго. Легче самому быстро вбить без редактора.
Это всё замечательно в теории, а на практике проверять уйму генерированного кода дольше чем написать самому как следует. Ну и бредогенератор не понимает контекст задач в принципе, поэтому навалит всякой чуши которую не просят, просто потому что. От этого вреда больше чем пользы.
Да какой нахуй теории) я уже со счёта сбился по объёму применяемого мной рабочего нейрокода, счёт уже идёт на десятки тысяч строк. Скрипты, минитулзы, админские софтины супер узкоспециализированные написанные на 95% нейронкой (некоторые 100,% plug and play как говорится), куски игры, полностью написанные нейронкой кастомные ресурсы к игре на годоте, иниты nodepath, туда же ui, управление, самая ржака что где-то с момента релиза дипсика - я вообще для некоторых задач код нейронки не проверяю а тупо пихаю и он пашет.
Сейчас вот кстати одно немаленькое приложение переношу с явы на шарп гроком, если предприятие окажется успешным - скачок будет уже до сотен тысяч строк.
Ахахаха. Представили ебало школьников которые будут жить в таком мире где все просто будет падать и ломаться?
Это типа нейронка генерирует такой хитрый код, который работает у меня, а если чует школьника - сразу ломается? Или че ты вообще сморозил то?
ну тип раз нейронка написала значит код плохой, все сломает. а если человек написал, значит в нем заведомо нет багов. я так понял
Когда ты сам пишешь код, ты понимаешь его, может отлаживать. Если ты нагенерил хуйни, а в ней какой-то хитрый баг, который в зависимости от фазы луны крашит твою игру в половины игроков, ты уже не найдено его, т.к. это не твой код, ты в нем не разбирался, да и вообще ты не шаришь в коде, если юзаешь сблев нейронки, это будет копиться как снежный ком, итоговое качество продукта будет уровня дно.
Это актуально не только про баги, еще и оптимизацию, в твоей игре будет 5 фпс из-за неоптимальных алгоритмов,и ты ничего не сможешь с этим сделать
>Это типа
Это напотипо инженеров и программистов заменяют зумеры-вайбкодеры, которые производят говнокод. Качественная деградация программных продуктов уже произошла лет 10 назад с наплывом вкатунов, дальше будет хуже, в т. ч. и из-за вайбкодинга, когда он станет нормой.
не плачь. ты всё равно говнокодер и пишешь хуже нейронки
>Если ты нагенерил хуйни, а в ней какой-то хитрый баг, который в зависимости от фазы луны крашит твою игру в половины игроков
Автотесты видимо от лукавого. Да даже хуй с ними с автотестами, код не работает от фазы луны, если это не код на плюсах и не многопоточка с локами. Хотя даже плюсы я бы скорее нейронке доверил чем макаке джуну.
>Когда ты сам пишешь код, ты понимаешь его, может отлаживать
Тебе, вкатуну зелёному, походу невдомёк что читать чужой код ещё важнее уметь чем писать свой и это в равной степени относится как к коду нейронки так и к коду прямоходящей макаки. А значит если у человека есть мозг, он отладит и поймет любой код, неважно кто был его автором.
>Это актуально не только про баги, еще и оптимизацию, в твоей игре будет 5 фпс из-за неоптимальных алгоритмов,и ты ничего не сможешь с этим сделать
Ебало профайлера представил? Что значит не смогу ничего сделать? Даже в годоте есть профилировщик скриптов. Маняфантазер очередняра.
>>1017627
Эту хуйню вообще не буду комментировать, опять навалил маняфантазий. Ты блядь говна на Делфи из нулевых не видел, там нейронки отдыхают.
Видел и пользовался. Говно на дельфи из нулевых лучше любого высера вайб-кодера на электроне.
> Что значит не смогу ничего сделать? Даже в годоте есть профилировщик скриптов.
И что, клоун?
Ты будешь заново переписывать скрипты за нейронкой?
Так быстрее тогда изначально самому написать норм, чем потом переделывать кривое говно, читать его, разбираться в нем, переписывать, менять подход и архитектуру.
> код не работает от фазы луны,
Ты игр не делал, значит, если не сталкивался с такими багами, которые могут вылазить у одного игрока на конкретном железе при очень редком стечении обстоятельств.
> Автотесты
Сам собрался писать ? Или так же генерить, не проверяя и не понимая, что там проверяется?
> если у человека есть мозг,
Видимо это не про тебя, иначе бы ты понимал, что на вайб кодинге не уедешь дальше первого вау-эффекта «оно компилируется»
Нейронка не сможет отлаживать код, поддерживать, допиливать, расширять. Ты просто придешь к тому, что проще вбить новый промпт и попробовать перегенерить, чем пытаться починить ранее криво сгенерированное. Так и будешь роллить, пока не повезет. Но на одном промпте комплексирую систему с кучей связей и сложной логики не построить
Ну чо у вас нового? Надеюсь годотю всё так же в говно опускаете?
Тут я заметил в индустрии положняк теперь прямо отчётливо виден - игры не нужны. Совсем. Теперь точно. Никому. А годотя ещё предлагает человекочасы тратить на потеху публике, чтобы кривой движок доделывать. Потом будете как автор какого-нибудь Marathon - "ну я же хотел игру хорошую сделать, пожалейте, мне кушать надо..."
Игровой рынок огромный. Но не в РФ. Тут только Яндекс игры по 500 новых игр каждую неделю две.
https://yandex.ru/games/category/new
Поговорил с одним мужиком у которого его 3Д игра в каталоге. В месяце он с нее получает 2к, хотя комментов к ней много.
Причем игра у него нормальная.
>Игровой рынок огромный
И с огромной конкуренции, где количество продукции увеличивается каждый год. А количество людей не увеличивается.
Единственный маркет который ещё может как-то помочь - это дождаться пока индусы разбогатеют немного.
А так каждый год для обычного васяна будет хуже.
янд игры это рф+белка+казахи+узбекистан+германия+ещё по мелочи
>Тут только Яндекс игры по 500 новых игр каждую неделю две.
Звучит не очень. Возможно он успел по началу проекта и сделал какой-то модный "три в ряд", который офисные тети до сих пор юзают (как еще можно удержать интерес в таких играх)? Или как-то в рекламу вкладывается (там вроде яндекс дает рекламится на своей же рекламной платформе, лол. Дойка с двухсторон прям)
Или же звездун, чтобы показать что не фигней занимается за копейки.
Шиз, просто смоделируй ситуацию. Я пишу нейронке промпт, кидаю референсный код, жду генерацию и все это минуты за две, получаю строчек 100-300 готового кода, который валиден в прямой зависимости от сложности задачи. Задачи реализовать что-то простое - перебрать массив, вы4ленить что-то из чего-то, сравнить и подвигать объекты - валидны в 100% случаев, остальное - иногда он обсерается с апи, которое фиксится ещё за минуту пока я скопирую ошибку из линтера и скормлю по новой + ожидание решения. Сколько я буду руками их корябать? Минут 10 а то и 15 так точно, ещё и в доку как назло лезть придется. Либо 15 минут либо 2-3 минуты. Уловил, шизло? Даже если проверять высер нейронки - это займет 2 минуты на 300 строчек.И я не говорю о том что допустить рантайм ошибку может и человек, а нейронка ибо недурная сама все нуллчеки проставит.
>>1017665
Кейсик назовешь? Не считая плюсовой хуетени по типу того что флоат на разных платформах может иметь разный размер и прочий long long. Единственный источник такой ошибки - это неправильная работа с путями и тонкости сохранения на разных платформах. Хотя я конечно знаю ещё один, но это вина чисто микроsофта, который сделал таймерам на Винде минимальный шаг 15 мс, а на линуксе/андрюше этот же таймер начинает поглощать цпу потому что у него минимальный шаг сильно поменьше. И у меня ноль претензий к нейронке потому что я бы тоже использовал эти таймеры, а потом постфактум узнал что оказывается надо писать свои.
>Сам собрался писать ? Или так же генерить, не проверяя и не понимая, что там проверяется?
Зависит от сложности. Обычно нейронка генерит.
>Видимо это не про тебя, иначе бы ты понимал, что на вайб кодинге не уедешь дальше первого вау-эффекта «оно компилируется»
Нейронка не сможет отлаживать код, поддерживать, допиливать, расширять. Ты просто придешь к тому, что проще вбить новый промпт и попробовать перегенерить, чем пытаться починить ранее криво сгенерированное. Так и будешь роллить, пока не повезет. Но на одном промпте комплексирую систему с кучей связей и сложной логики не построить
Ещё 10 раз напиши. А лучше перечитай мои посты и найди где я советовал ее использовать вот так.
2к рублей, не долларов.
2к рублей в месяц.
Я думал что там хотя бы 30к падает.
>>1017678
Это же 300 млн рынок
Но на деле денег нет
> Игровой рынок огромный. Но не в РФ. Тут только Яндекс игры по 500 новых игр каждую неделю две.
Ну зачем вы пишете ебаный бред?
У нас покупает игры в стиме на консоли.
Также, разработчик из россии модет зарелизить свои игры в стим и любые другие площадки.
Ехать открывать фирму под это обойдется дороже чем игра заработает
Ты своей игрой меньше 100к планируешь заработать? Так то даже если меньше миллиона, то уже вопросы есть.
>Ты своей игрой меньше 100к планируешь заработать? Так то даже если меньше миллиона, то уже вопросы есть.
На игра не надо зарабатывать. Я могу за неделю миллион заработать, но не в каждую неделю естественно, звёзды должны совпасть.
Нахуя мне делать игру минимум год? (На деле 3)
Планировать ты можешь все что угодно как и маняфантазировать про миллионы.
> На игра не надо зарабатывать.
Выше шла речь про игровой рынок в россии, а не про твои разработки по вечерам для себя/некоммерческой аудитории.
>>1017708
Миллион это довольно мало, год работы специалиста уровня джуниор.
Заработок специалиста за год имеет мало отношения к прибыли игры как частного предпринимательства.
поэтому лучше работать на стабильной работе, чем делать игры
а игры надо делать, если уже деньги есть и хочешь их потратить
это как казино
В казино хотя бы весело. А геймдев это хроническая депрессия и тлен.
Бля, ты вообще полностью переворачиваешь мои слова в какую-то хуйню.
Вспомни откуда разговор начался.
Я говорил, что если ты делаешь игру для заработка копеек на уровне 100к, то это значит, что ты её делаешь впринципе не для заработка(=тебе не нужен рынок), а для души.
А если ты делаешь игру для заработка и твоя цель 100к или даже миллион, то есть вопросы.
Вот буквально тут это и написано >>1017705
Могу раскрыть мысль подробнее, почему и что за вопросы: потому что если ты планируешь заработать на игре пару копеек, то полагаю ты и труда в неё слишком мало вложишь и она утонёт в конкуренции.
Миллион на самом деле еще ок цель для начинающего соло индюка который будет год ебошить - чисто по затратам усилий скорее всего что-то похожее на игру выйдет, либо не начинающего который какие-то крутые идеи воплощает за 1-3 месяца, но вот ебошить делать игру ради 100к это точно чет трешак какой-то уже и возможно можно намного проще эти 100к поднять.
>>1017715
Ну в конечном итоге каждый для себя сам решит наверное.
Если ты серьезно настроен, готов вложить в игру трудовые и финансовые ресурсы, и понимаешь что ты делаешь, в какую нишу лезешь и чем твоя игра должна цеплчть, то это звучит как план.
Для души можно выложить много где без ебли с проплатой стима или консолей.
Можно. И если прочитать мое сообщение и кому оно отвечает, то можно заметить, что я об этом тоже говорил.
>>1017723
Ты годотя что ли?
Пиздей какая-то душная очевидная хуита написана под видом якобы умных мыслей.
Вообще не умных, а очевидные вещи.
Просто типа а что ещё я должен ответить, когда мне говорят, что рынка игр в россии нет, а аотом уводят разговор в сторону "игры надо делать для души, на играх все равно не заработать"? Нахуй тогда вообще про рынок говорить?
Эээ ну да типа 140 миллионов человек страна, большая геймерсаая аудитория которая готова тратить деньги на игры.
В тот же стим деньги несут только в путь, в кингдом каме жители россии на 5м месте по онлайну.
А если говорить о разработчиках, то они вообще могут относительно легко на любую площадку выйти на мировую аудиторию
Главное чтобы не юнитя, хуже юнити никого уж нет, это хуже червей-пидоров.
Чел, суть в том что игры это лотерея, все надеются что они принесут не 100к, а 100миллионов.
Не рвись, игры все равно уже нет смысла делать, можешь расслабиться и удалить и то, и другое.
Нет, ошибся только, не 5 а 4 место
https://ixbt.games/news/2025/04/03/rossiyanam-zapretili-pokupat-kingdom-come-deliverance-2-no-rossiya-okazalas-cetvyortoi-po-kolicestvu.html
>>1017740
Лотерея - лишь твоё название для степени рисковости бизнеса по разработке игр. Любой бизнес это риск, к слову.
И слово "лотерея" раскрывает его довольно таки слабо, как минимум потому, что рисковость одним словом не описать.
Вот только когда идут в бизнес, понимают что идут в бизнес.
Когда идут пилить игру на год, не понимают что идут в бизнес, который скорее всего не выстрелит.
Так про что угодно можно сказать, да и не весь бизнес выстреливает.
Но это никак не отменяет того, что можно проанализировать че щас на рынке, что ты можешь сделать, и на какие примерно результаты рассчитывать, и в процессе разработки следить за метриками маркетинговой кампании и смотреть че ты там как попадаешь куда надо или нет.
Так ты будешь заранее понимать, какие примерно потенциальные рамки дохода игры.
Нет, не про что угодно. Грузчик в пятерочке ходит год на работу и не ожидает что вдруг станет миллионером. А ему нужно меньше квалификации. А разрабу игры нужны компетенции во всем от кода до арта до геймдизайна до маркетинга. куча вложений и на выходе 8 рублей вместо миллиона. Такое себе. Хоть унализируйся, игр слишком много. пробиться в заметность чрезвычайно тяжело.
>гуньдот
>Кто это такой?
Речь шла о бизнесах, но так то можно и натянуть и на вообще что угодно, на любую деятельность - ты когда что угодно делаешь можешь примерно определить рамки потенциального результата, и чем больше статистики найдешь и хорошо проанализируешь, тем точнее будет твоя оценка.
> Нет, не про что угодно. Грузчик в пятерочке ходит год на работу и не ожидает что вдруг станет миллионером.
У грузчика зарплата около миллиона в год. Чем тебе не миллионер? А так, грузчик может тоже предполагать свои перспективы, что потенциально с опытом он сможет стать начальником грузчиков или попробовать найти работы в более крутых компаниях с зарплатой в 2 раза больше условно как верхняя рамка успеха, и остаться на том же месте как нижняя рамка успеха.
Так и с созданием своей игры, на ранних этапах ты можешь оценить нишу и что за игры в ней есть, узнать их примерный доход(это не сложно, статистика по которой его можно прикинуть есть составленнач по тысячам игр), и взять например промежуток с 25% по 75% как верхнюю и нижнюю границу.
После того как начнёшь разработку, у тебя будут набираться вишлисты, ты сможешь оценить какая твоя деятельность сколько вишлистов даёт, сколько стоит 1 вишлист с закупки трафика и как следствие сколько ты наберёшь к концу разработки.
И главное - по количеству вишлистов уже можно прикидывать продажи(порядка 10% вишлистов конвертируются в продажи за первую неделю для игр ценового сегмента 5-20 долларов).
> А ему нужно меньше квалификации.
А мы разве обсуждали квалификацию, а не то возможно ли спрогнощировать успех? По моему все таки второе.
> А разрабу игры нужны компетенции во всем от кода до арта до геймдизайна до маркетинга. куча вложений и на выходе 8 рублей вместо миллиона. Такое себе. Хоть унализируйся, игр слишком много. пробиться в заметность чрезвычайно тяжело.
Ну, какие вложения и сколько чего выйдет можно прикинуть так, как я выше описал.
Если у тебя получились такие цифры, что какая то другая деятельность тебе кажется намного более выгодной - не вопрос.
Но, возможно не у всех будет также как у тебя, пожтому мы и видим, что регулярно ввходит много новых игр, в которые в том числе вкладывалось много сил.
Нашел нужные мне туторы по гототу, почему будет ошибкой поменять юнити на годот?
Почему при условии наличия рынка, деньги должны приносить именно ЯИ, а не стим?
и ЯИ приносит кстати, хоть рынок ЯИ и намного меньшие обороты имеет
>Какие реальные отличия юнити от годота
В юнити больше фич из коробки и больше фич доступно за деньги в виде ассетов. Поэтому если твои человекочасы не стоят копейки проще взять юнити и в случае чего докинуть пару долларов за код, который писать месяц.
Ты шизик так ничего и не понял.
Кто-то действительно зарабатывает, но это не ты. Ты ничего не заработаешь, а если и заработаешь то копейки. Деньги скорее Вудушу на очередной турик по героям занесут или папичу на смишные мемы.
Игры ради денег нет смысла делать.
Гуньдот для 2д, либо для очень маленьких 3д игр.
Какое-нибудь комплексное, даже среднее решение - он тупо не вывезет.
А переписывать ядро вокнутых пидоразИ - себе дороже. Да и зачем, если есть юнити/урина, которые работают лучше.
Да не гони, комплексное 2д он потянет ещё пизже чем юнити, просто потому что там настоящее 2д. Другое дело что доступ к этому 2д очень жирный, хоть всю игру в аддоне на плюсах пиши.
>Да не гони, комплексное 2д он потянет ещё пизже чем юнити, просто потому что там настоящее 2д.
Лол. Не забудь ещё логикой на гондоскрипте это поправить, точно обгонишь тогда.
Еще немного и растеризация треугольников окончательно уйдет в прошлое. Останутся только рейтресинг и программная растеризация
Тото сишурп на древнем моно летает, когда сверху еще обмазываются динамические метаданные редактора.
Запомни Сишарп в юнке это не Сишарп современного дотнета core
В чём смысл этих мантр?
> Кто-то действительно зарабатывает, но это не ты. Ты ничего не заработаешь, а если и заработаешь то копейки.
Думаю на этой доске полно людей, которые нормально зарабатывают в геймдеве. Я кстати тоже.
А вот зачем ты пытаешься отпугивать новичков от этого занятия приводя пустые аргументы мне совсем не понятно.
> Деньги скорее Вудушу на очередной турик по героям занесут или папичу на смишные мемы.
Какое бредовое заявление.
Я даже хз ты уже троллишь или ещё нет.
Во-первых поебать что там в стримерской среде, мы говорим только о геймдеве, что в нём реально есть. Без причин и следствий, просто что есть по факту.
Во-вторых игровая индустрия побольше стримерской будет, мягко говоря.
> просто потому что там настоящее 2д
Что это значит? В юнити 2д игрушечное? Минусы будут?
Юнити более зрелая и продакшен реди платформа. Оно так то сломано к хуям, но оно хоть как-то живёт и игры выпускать позволяет.
На годоте выпущенных игр в разв меньше, утверждать не буду, но полагаю проблем там тоже в разы больше, чем в юнити.
В остальном - под юнити в разв больше готового контента, намного больше полезных встроенных решений, производительность намного лучше
В юнити не стандартный моно рантайм, а переделанный.
>Запомни Сишарп в юнке это не Сишарп современного дотнета core
Ага, вот бы обмазаться везде Task а потом думать почему память выделяется постоянно. Современный рантайм шарпа сам по себе не гарантирует тебе быстрые полёты.
Похуй, бери годот. Потом будем смеяться над тобой.
Количество выпущенных игр как-то не важно (ввиду возраста и рынка, это очевидно, я больше за техническую часть).
Но я вот подумал, из-за опенсорсности годота, может быть у него больше опенсорсных и бесплатных решений чем у пропритарного софта? теоритически, или геймдев слишком жадная индустрия?
> Но я вот подумал, из-за опенсорсности годота, может быть у него больше опенсорсных и бесплатных решений чем у пропритарного софта?
Для юнити как ни странно дохуя всяких бесплатных мастхев либ, unirx, unitask, vcontainer/zenject - эти вообще база для почти любого проекта.
>В юнити il2cpp даано есть
Костыли чтобы пофиксить природу динамикидресни.
Из коробки ты сосешь булыжник.
>В юнити не стандартный моно рантайм, а переделанный.
Из статичного языка сделали динамикадресню, сделав по сути сишарп-скрипт (а потом комментом выше фиксят костылями).
>Современный рантайм шарпа сам по себе не гарантирует тебе быстрые полёты.
Если вылезти из помойки геймдева и посмотреть что там творится последние годы с рантаймом сишарпа, так вот там не только переписали все, но и как раз каждый релиз гарантирует нехилые такие полеты на языке с VM. Многие приходя из донета в юнити, по незнанию ведутся на это, хотя в юнити по сути свой GDscript (только в годоте он закошен под питон, а в юньке закошен под сишарп).
Какой-то словесный понос.
> Костыли чтобы пофиксить природу динамикидресни.
Динамикодрисня?... Сишарп язык со строгой статической типизаций.
> Костыли
А конкретные минусы будут?
Окей, костыли, че дальше, как это будет мешать кому-то?
> Из коробки ты сосешь булыжник.
Переключаешь рантайм в выпадающем списке в настройках и все.
> Из статичного языка сделали динамикадресню, сделав по сути сишарп-скрипт
Ты всё перепутал.
Статическая/динамическая типизация это свойство языка, а не рантайма.
В жаваскрипте у тебя нету возможности в коде явно прописывать типы и делать проверки корректности работы на этапе компиляции.
Это называется динамическая типизация.
В тайпскрипте ты обязан прописывать типы, можешь накладывать констрейнты, корректность используемыз типов проверяется в компайл тайме.
Это называется статическая типизация.
Статическую типизацию ещё ранжируют по силе.
Например в С++ ты легко можешь кастить любые данные в любой тип - у тебя есть указатель на инты, ты по этому адресу расположил массив интов, а потом присвоил этот адрес указателю на какую-то структуру - и сразу работаешь с данными лежащими по тому адресу как со структурой.
Такие махинации позволяют потенциально некорректно использовать типы.
Это называется слабая статическая типизация.
А есть например такой язык как джава, там ты такие фокусы проворачивать не можешь(вроде бы), какие типы напиманы в коде, те и будут, некорректное испольщование невозможно никак, это называется строгая статическая типизация.
Есть ещё язык си шарп, он ближе к С++ в этом плане, так как позволчет польщоваться указателями и заниматься цирком с данными. Но он всё же более строгиц чем с С++, так как все эти фокусы обязаны делаться в ансейф блоке, что позаоляет для отладки быстро локплизовать проблемные места или полностью их заменить на сейф.
> с рантаймом сишарпа, так вот там не только переписали все
Il2cpp это тоже переписанный рантайм сишарпа.
> Многие приходя из донета в юнити, по незнанию ведутся на это, хотя в юнити по сути свой GDscript
В юнити точно такой же сишарп как и в дотнете с точно такой же спецификацией, только версия постарее.
Если ты говоришь про перформанс - дот нет хорошо постарались и рантайм дотнета намного быстрее моно, но вот ил2цпп уже ближе к нему. А в юнити ещё есть бёрст, который уже круче будет.
Всё ровно юнити – хороший выбор для быстрой разработки и похуй на сурцы.
На урине не сделать быстро стилизованную картинку ни на что не похожую. А на хрюнити можно.
На рынке ща одно унрыло-люмен дерьмо в трейлерах, которое ещё и одинаково выглядит.
Ещё ремастеред подливы выйдет на урина 5, и те кто и так плевался от урины, вообще опробуют индусской вкусняшки.
Надежда лишь на то, что всё действительно нормально будет. Потерпеть тока надо...
>Статическая/динамическая типизация это свойство языка, а не рантайма.
Как ты себе представляешь динамически типизированный язык без рантайма?
Ты как чатгпт высрал шаблонный надрессированный текст. А кто сказал что динамикодресня это отношение к типизации, а не природе рантайма? Причем там даже фраза была про мета программирование, которое как бы намекает про природу интерпретации (байткода или скрипта) в неком VM (по другому невозможно, исключая макросы).
Ты просто увидел знакомый триггер и как та обезьянка побежал писать простыню текста. Кого ты пытался тут удивить в разделе разработки? Если ты учишься программировать, это не значить что надо писать целую выжимку своих недавних открытий. Всем насрать.
В юнити 2д это 3д с ортографическим режимом камеры, что даёт лишнюю нагрузку, так что да, минусы будут. А ещё в годоте система ресурсов прикольная, прям в разы прикольнее любой возможной ее пародии на скриптаблобжектах. Циклических ссылок разве что нет, но я хз как надо извращать иерархию ресурсов чтобы потребовались циклические ссылки.
Я ньюфаг, но мне больше нравится система тайтлов годоте. Может просто я тоже ньюфага смотрел, но тут прям коллизию выставляют в tilemap и это круто. А аниматор с деревом в юнити просто костыль какой-то, когда в годот намного проще из кода задать анимацию wasd и там же сразу направление задать, чем затрах с матрицей -1 0...
> Как ты себе представляешь динамически типизированный язык без рантайма?
Статически/динамически типизированный язык это свойство языка, вне зависимости от моих представлений. тебе рассказать как? Храним в памяти любого кастомного типа сначала идентификатор типа. Впринципе, все. Виртуальная машина тебе для этого не нужна.
> Ты как чатгпт высрал шаблонный надрессированный текст. А кто сказал что динамикодресня это отношение к типизации, а не природе рантайма?
Потому что есть два таких понятия - статическая и динамическая типизация.
У них значение такое, как я описал. Если найдешь хоть один источник, где оно отличается - давай глянем. Просто я не видел других вариантов.
Больше ничего что на слово динамикодрисня можно натянуть(и внезвано, именно динамикодрисней называют динамическую типизацию... лол) я не знаю. Можешь подсказать?
> Причем там даже фраза была про мета программирование, которое как бы намекает про природу интерпретации
Метапрограммирования и интепретация это полностью параллельные понятия.
В с++ дохуя мета программирования(макросы, темплейты, к примеру). И как, он интерпретируемый?
Вижу ты сам упомянул - за исключением макросов. Ну, чуть чуть не считается знач.
Понятно, что ты наверное говоришь про метаинфу типов, типа вот в обжекте лежит указатель на метаинфу его типа КАРАААУЛ. Лол.
Но это не имеет никакого отношения к интерпретируемости.
У тебя может быть язык нативно компилируемый, который будет просто первые несколько байт любого инстанса класса резервировать под айдишник его типа, по которому ты сможешь о нём инфу вытащить.
Ты можешь кстати реализовать это всё в С++, например.
> Ты просто увидел знакомый триггер и как та обезьянка побежал писать простыню текста. Кого ты пытался тут удивить в разделе разработки? Если ты учишься программировать, это не значить что надо писать целую выжимку своих недавних открытий. Всем насрать.
Я увидел, что ты используешь рандомные слова вкладывая в них рандомный смысл, и говоря, что это плохо.
Я расписал тебе, в чем заключаются твои недопонимания используемых тобой терминов, и объяснил, что даже то, что ты и сам под ними неверно подразумеваешь, проблемами не является.
> В юнити 2д это 3д с ортографическим режимом камеры, что даёт лишнюю нагрузку, так что да, минусы будут.
Не.
Видеокарты рендерят всё в 3д, им без разницы используешь ты 3 координаты или 2.
А софтварный рендеринг в разы медленнее хардварного.
В юнити можно спрайтам через эдит спрацт скиннинг эдитор задавать меш, думаю он может использоваться в тайлмапе, а если нет, то можно реализовать, но это не для новичка совсем задача.
Но на практике это не оч юзается, у меш коллайдеров очень плохая производительность.
Поэтому все юзают комбинации квадратиков и кружков обычно для подобного.
Ну, по ситуации надо смотреть.
>нормально зарабатывают в геймдеве
Таких тут было ровно 2 человека из всей доски. И были они 5-10 лет назад.
>А вот зачем ты пытаешься отпугивать новичков
Это пустая трата времени. Им же будет лучше заняться чем нибудь другим.
>что в нём реально есть.
Там есть 99.99% мертвых игр в стиме или яндекс играх.
Вчему свое время. И время вкатывания в игрострой закончилось.
https://m.youtube.com/watch?v=1yb0MSF2Mm4&pp=0gcJCdgAo7VqN5tD
Так поубедительней? И не надо кивать на dots, это совершенно другой мир. Какая-то дополнительная нагрузка явно присутствует, судя по всему - накладные расходы на рефлексию в юнити, даже если рендер влияет минимально.
>Вчему свое время. И время вкатывания в игрострой закончилось
А ни одной крутой игры для кумеров как небыло так и нет. Одни только моды для Скайрима лямку тянут за все направление.
Чтобы замерять пооизводительность рендеринга, надо создать симуляцию, в которой рендеринг станет ботлнеком, а не какой-то другой код.
В идеальном случае, она бы использовала статические объекты.
С динамическими объектами в ход вступает батчинг, который может стать новым ботлнеком и это уже становится не тест рендеринга, а тест в целом перформанса графического движка, что тоже интересно.
Вот только для этого надо было бы использовать линейное перерещение, чтобы математика используемая для этого не стала ботл неком.
В данном же случае, мы можем спуститься в комментарии и сразу понять в чём дело...
> И не надо кивать на dots, это совершенно другой мир.
Дотс никак не влияет на скорость рендеринга(что ты предлагаешь замерять)
> Какая-то дополнительная нагрузка явно присутствует, судя по всему - накладные расходы на рефлексию в юнити
Тут не используется рефлексия.
Ну и на всякий случай, раскрою тебе страшную правду... годот тоже использует 3д рендеринг для 2д...
> Таких тут было ровно 2 человека из всей доски. И были они 5-10 лет назад.
Со всей доской лично знаком?
> Это пустая трата времени. Им же будет лучше заняться чем нибудь другим.
> Там есть 99.99% мертвых игр в стиме или яндекс играх.
> Вчему свое время. И время вкатывания в игрострой закончилось.
Ничем не подкрепленные утверждения.
Можешь походить по стиму, посмотреть популар нью релизес, посмотреть что там за игры, сколько там отзывов и по ним вычислить примерное число продаж.
>Дотс никак не влияет на скорость рендеринга(что ты предлагаешь замерять)
На скорость рендеринга влияет количество транзисторов в видеокарте. А на скорость подготовки подачи информации на расчет в видеокарту вполне себе влияет. Разумеется что там что там вызовы те же, но видимо порядок и организация этих вызовов имеет некоторые различия, да и несколько лишних дополнительных вызовов может дать ещё минус по производительности.
>Тут не используется рефлексия.
Уверен? А что такое update и как он вызывается с++ ядром юнити, не расскажешь?
https://github.com/smartpenguins/BeeTestsUnity/blob/main/Assets/CS%20Script/FlyingBee.cs
В отличии от гдс в гд4, где его вызовы движок делает практически напрямую.
>С динамическими объектами в ход вступает батчинг, который может стать новым ботлнеком и это уже становится не тест рендеринга, а тест в целом перформанса графического движка, что тоже интересно.
Я кстати хз с чего ты решил что мне интересно сравнивать именно рендеринг. Как ты верно заметил - апи по факту вызывается тот же, там буквально нечего мерять, скорость рендеринга в этом случае уже от бэкенда зависит и это уже будет сравнение опенгл vs directx vs vulcan vs metal. Я говорю про то что у годота более оптимизирован 2д конвеер, где нет даже намека на 3д, они ощутимо разделены.
>Ничем не подкрепленные утверждения
Любой кто хоть раз стимдб открывал понимает о чем я говорю. Очевидно ты ни разу не смотрел статистику стима.
Годотя, если зввтра нейронки отберут у меня работу я начну зарабатывать больше. Вот такой вот парадокс.
А у игр кстати еще и другой кризис помимо нейронотвтрчества, когда приходится уже суперплотно с соц сетями за время конкурировать.
> На скорость рендеринга влияет количество транзисторов в видеокарте. А на скорость подготовки подачи информации на расчет в видеокарту вполне себе влияет.
Верно
> Разумеется что там что там вызовы те же, но видимо порядок и организация этих вызовов имеет некоторые различия, да и несколько лишних дополнительных вызовов может дать ещё минус по производительности.
Имеют. Могут.
Но так ли это на самом деле?
> Уверен? А что такое update и как он вызывается с++ ядром юнити, не расскажешь?
Лол. Расскажу. Прямой вызов(с некоторым оверхедом связи нативной и моно части).
Рассказать как это можно сделать?
Если бы апдейт в юнити вызывался рефлексией, его бы было невозможно юзать, там производительность просто сразу х20 вниз даст.
Можешь это довольно легко проверить, затестив 10000 апдейтов раздельных, и 10000 вызовов функции, а потом 10000 вызовов с рефлексией.
Для первых двух кейсов тесть есть на хабре.
> Я говорю про то что у годота более оптимизирован 2д конвеер, где нет даже намека на 3д, они ощутимо разделены.
Ты мог бы прочитать подробнее что я написал и посмотреть приложенный скриншот.
У годота не более оптимизировпнный 2д конвеер, тест который ты скинул его не тестирует.
Более того, я более чем уверен, что он ничем вообще не отличается, кроме того, что у юнити батчинг есть и вероятно он значиьельно более производительный за счет использования джобов.
Отктрывал. Стата по доходу игр тоже имеется. Конкретные игры сколько конкретно заработали тоже довольно легко узнать.
Сначала не понял, а потом как вспомнил.
Насладись новым шедевром от разработчика хрюкающего волка на топовом движке "годот".
https://www.youtube.com/watch?v=_Jwal221l2s
> годот оказывается неплохая годнота, особенно для 2д.
Чем лучше юнити?
Тысячи игр в 2д на юнити не дадут соврать - годот говнота. Пальчики оближешь прям.
Даже близко не конкурент юнити если что, даже не блендер и даже не рядом. А перспективы у него "радужные" в плохом смысле этого слова.
Годот создан чтобы смешить челов которые сидят на нормальных движках. И пока что он справляется на отлично.
Гойда лучшая. За ней будущее. В блендер тоже многие не верили поначалу. Игры на гойде спасут мир...
Что я увидел:
Производительнее
Удобнее работа с тайтлами
Очень понравился концепт сцен - юнитов. По сути работаешь сразу с пребафами.
Вроде есть наличие горячей перезагрузки для gdscript но я не юзал.
Мне кажется программирование шейдеров кодом (близкое к GLSL) лучше чем эта визуальная залупа где ты точки соединяешь.
Открытый исходный код. Я могу покопаться когда мне будет нужно.
Мне как новичку юнити кажется сложнее, субъективно, но факт для меня.
Ты выкладываешь их на бесплатный сервис который делится с тобой прибылью от рекламы.
Понятно что тебе падают копейки.
Начни продавать их.
>Начни продавать их
На самом деле на мобилках большая часть дохода с рекламы идёт. Так что можно создать бесплатную игру, причём вообще без доната, и при этом дохера заработать.
у меня до сих пор мобилка кнопочная, я не представляю как это - игры на мобилках да и узнавать лень
> Производительнее
Чем что?
Если ты про юнити, то это бред. Юнити производительнее, стабильнее, без пропуков, рендер мощнее и более конфигурируемый, батчинг всего и вся.
Как-то итт сравнивали в рендердоке 2д рендеры Юнити и годота, в Юнити все было четко, в то время как гандотя рисовала каждую буковку двумя драв коллами, хз пофиксили это или нет с тех пор, но это далеко не единственная проблема гандотьки
Купи тысяч за 20 самсунг. С одной стороны у тебя будет универсальный удобный гаджет (карта города, банковские счета, оплата ЖКХ и всё что угодно), с другой стороны может тебе понравится мобильный гейминг и ты решишь туда влететь.
Помню тут один анон пилил симулятор ядерного реактора. Казалось бы, кому на мобилках может быть это интересно? Но его игра зашла людям, было много установок. Так что на мобилки можно любой геймплей запилить.
Выше пчелок кидали
>>1017825
Мне просто годот зашел даже больше. Сначала проигнорил по причине популярности и вкатился в юнити, но сейчас смотрю материала для ньюгов там не меньше.
Блендер выстрелил, выстрелит и годот. Опенсорс победит.
> Производительнее
Юнити намного производительнее
> Удобнее работа с тайтлами
Вроде в юнити все тоже самое есть и сдк от Tiled
> Очень понравился концепт сцен - юнитов. По сути работаешь сразу с пребафами.
Для прототипирования норм, как проект разрастется бкдет хуево
> Вроде есть наличие горячей перезагрузки для gdscript но я не юзал.
Это да
> Мне кажется программирование шейдеров кодом (близкое к GLSL) лучше чем эта визуальная залупа где ты точки соединяешь.
В юнити программирование кодом, визуальная залупа для тех аристов и новичков
Как всегда годоти не могли не смухлевать. Вот так и куются перемоги.
>Опенсорс победит.
3дмакс и маю как юзали так и дальше юзают, особенно если это касается студий.
У блендера два плюса: анимации удобнее делать и аддонов много. Всё.
Да и популярность что у годоти, что у блендера сейчас упала, многие попробовали и вернулись обратно на свой софт привычный.
А кто-то вообще обосрался на годоти, и сидит ноет теперь, что игра говно, годоть не вывозит, дайте денег бедным нам.
Половина игр на опенсурс движках даже близко не касалось его ядра при разработке. И пилят свою игру 1в1 как на юнити, без изменений рендера или каких-то либ внутри. Зачем об этом все вопят - непонятно.
Ключевая разница между Godot и Unity заключается в их архитектуре, философии разработки и экосистеме. Вот основные отличия:
### 1. Архитектура и подход
- Godot использует деревь сцен (node-based), где каждый объект — это "нода" (узел), а сцена — это иерархия таких нод. Это даёт гибкость, но требует привыкания.
- Unity работает на основе игровых объектов (GameObjects) и компонентов (Components), что ближе к традиционному ООП.
### 2. Языки программирования
- Godot поддерживает GDScript (Python-подобный язык), C#, C++ (через GDNative) и VisualScript (устарел).
- Unity использует C# как основной язык, с более зрелой экосистемой и производительностью.
### 3. 2D vs 3D
- Godot изначально заточен под 2D (есть отдельный 2D-движок с пиксельно-точным позиционированием).
- Unity изначально 3D-ориентирован, но имеет мощные инструменты и для 2D (хотя требует дополнительных настроек).
### 4. Лицензия и стоимость
- **Godot** — **полностью бесплатный и открытый (MIT License)**, без скрытых платежей и роялти.
- **Unity** — **условно-бесплатный**, но с подпиской Pro и платой за использование при определённых условиях (ранее был скандал с Runtime Fee).
### 5. **Производительность**
- **Unity** обычно быстрее в **3D** (особенно с большими проектами) благодаря оптимизированному движку и Burst Compiler.
- **Godot** легковесный, но в 3D пока отстаёт (хотя Godot 4 с Vulkan улучшил ситуацию).
### 6. **Сообщество и документация**
- **Unity** — огромное комьюнити, много ассетов в Asset Store, обширная документация.
- **Godot** — сообщество меньше, но быстро растёт, документация хорошая, но иногда не хватает продвинутых гайдов.
### 7. **Кроссплатформенность**
- Оба движка поддерживают **PC, мобильные устройства, консоли и Web**, но:
- **Unity** проще портировать на консоли (из-за официальной поддержки).
- **Godot** проще экспортирует в **Linux и Web** без лишних сложностей.
### **Вывод:**
- **Выбирайте Godot**, если хотите **бесплатный, открытый движок** с удобным 2D и простым workflow.
- **Выбирайте Unity**, если нужен **мощный 3D-движок** с C#, большим количеством готовых решений и поддержкой консолей.
Если кратко: **Godot — это "инди-дружелюбный" движок, а Unity — более коммерчески ориентированный.**
Большинство Анонов итт из России. Основная прибыль с гугл плея идёт мимо нас.
>>1017932
>Опенсорс
Сейчас во всю пиарят https://defold.com/
>У блендера два плюса: анимации удобнее делать и аддонов много.
Именно потому что опенсорс и нарастил комьюнити. Нечто такое может ждать годот (но не скоро).
Хорошая инвестиция если ты только начинаешь и у тебя есть много лет и желания вариться в индустрии.
>Сейчас во всю пиарят https://defold.com/
Какие подводные? кроме вопроса популярности
непривычная архитектура
много чего нет
подходит для мини игр или игр среднего размера
нет учебных материалов
LUA вместо языка
> Большинство Анонов итт из России. Основная прибыль с гугл плея идёт мимо нас.
Было бы желание или готовые к выпуску годные игры(либо уже вышедшие на ру площадке и показавшие хорошие метрики) - нашли бы вариант выйти на гугл плей.
Google признали виновной в монополизации рынка онлайн-рекламы
Суд США установил, что Google незаконно удерживала монополию на рынке онлайн-рекламы, используя антиконкурентные практики на протяжении более десяти лет. Компания связала свои продукты — сервер объявлений и рекламную биржу — для контроля над ключевыми этапами размещения интернет-рекламы, что нанесло ущерб издателям, конкурентам и пользователям. Google могут обязать отделить свои рекламные технологии. Это уже второе крупное антимонопольное поражение корпорации за год — ранее ее признали виновной в злоупотреблении доминированием в сфере онлайн-поиска.
На дотсе деыолтная юнити партикл система работает из коробки
Этот чел тупее джуна лол, он серьзно что-то там еще дебанкал а годоти это в тред несли? Пиздец, просто пиздец.
>>1017921
На итч ио продавать я надеюсь?
> что-то там еще дебанкал а годоти это в тред несли
Надо же оправдать сверх-быстрый движок гуньдот. Как это ещё разраба роад-ту-восток не упомянули, который перешел на этот кал, ещё и блять на гдскрипте, а не на шарпе.
По итогу: сейчас как будто замедлился в х100 раз, чем когда делал на юнити.
Плюс отсеял половину челов которые писали ему, что на гуньдоти стало хуже всё выглядеть и работать.
Разработка +- норм проекта в будущем, перетекла в скам на долляри ждунов и объект вожделения для гуньдоть, верящих в поделие хуана, которое пришло типа спасти мир гейдева от злых корпорашек.
>Юнити намного производительнее
Процентов на 5, это не на много.
Все по факту ответил, это практически никакого вклада на результат не внесет.
Нюанс в том, чтобы начать продавать, тебе сначала надо будет потратить около 50000р на оформление. То есть тебе нужна гарантия что это купят хотя бы 200-500 человек чтобы отбить.
Вопрос, наверное, даже философский - сможешь ли ты убедить 200 человек из 20000 просмотревших заплатить реальные деньги за игру, если не смог заставить 200 000 просто посмотреть рекламу?
>Да и популярность что у годоти, что у блендера сейчас упала, многие попробовали и вернулись обратно
Верим.
Неловко вышло с хрюнитей.
Ни разу не зависал, в отличии от говнодота, особенно если шорткатом винды сворачивать все окна, либо просто попытаться свет запечь.
Позорище а не движок. Как его ещё не удалили в принципе отовсюду, неужели годоти так терпят сильно
Да писали петиции в стим чтобы удалили все говнюнити, но там большие бабки замешаны.
надо было писать петиции на удаление хрюкающего волка за клевету движка
Но буду.
ууууииииихрююююю
Как у меня горит очко с этих даунских техно-деок.
https://www.youtube.com/watch?v=o1JIK5W3DRU
Какой в этом смысл? Если в анриле техно-демка что-то показывает, то это так и выглядит в ИГРОВОМ ПРОЦЕССЕ. А тут что? Типа, ты можешь отрендерить синематик на движке? И хули? Я его и в 3д редакторе отрендерить могу, чтобы потом в игру вставлять, хоть в годот сраный. Но в игре такого не будет никогда. Это же просто скам называется.
За такое даже на китайских маркетплейсах уже банят, за откровенную ложь на обложке.
так это замануха для быдла и инвесторов
демки на анриле ту же функцию выполняют
разрабам поебать на эти "4080+" технологии, они зомби-шутаныы из синти ассетов клепают
На анриле буквально всё из технодемок реализуемо в движке. На юнити я не уверен, что даже реально можно такой синематик отрендерить, и это не наебалово. Но рилтайм в игре ты даже 10% от этого не получишь, хоть изъебись там, такого функционала просто нет.
Как будто в анриле всё то что показывают - так-же реализуют дальше ассетов для пустых комнат или синематиков.
Либо трейлер/тизер выглядит привлекательно, а в действительности это дерьмо неоптимизированное/неинтересное/мертваяигра, и играть невозможно без нанокомпуктира с железом уровня 4070+.
Просто дурить гоев легче на урине, и у неё уже прямо традиционно такой маркетинг.
"Мы подходим для создания любой игры, но, при этом мы не подходим для ничего, кроме коридорных шутеров как и 10 лет назад."
Вот у какого-нибудь сруенжина было RT освещение 10 лет назад, а они зазвездились с лицензией, и не пытались пиариться как это делают эпики рассказывая о волшебных люменах.
В итоге урина ужасно раздутый движок с уебищным освещением, а сруенжин- банкроты, максимально не юзерфрендли движок, но, зато с очень легким RT которое работает даже на слабом железе.
А это ещё если не упоминать сурс, который недавно запускали на куске говна мамонта пентиум4 и там были и отражения и RT и тени.
Это больше вопрос контор-пидорасов, и эпик-гей тут явно лидирует.
P.S Свинина - пидорас и хуесос.
> Почему абсолютно все ещё не ушли с юнити за скам?
А на чём ещё делать игры?
>дерьмо неоптимизированное/неинтересное/мертваяигра, и играть невозможно без нанокомпуктира с железом уровня 4070+.
Пиздец унылое виляние жопой. Уровень "а нам это нинужно". Речь идёт о том реализуемо заявленное в принципе или нет, а не о твоих предпочтениях. На анриле повторить технодему можно. Просто взять и сделать, даже если тебе это в игре не нужно. Повторить на юнити даже 50% от этого просто НЕЛЬЗЯ, это буквально скам.
> Повторить на юнити даже 50% от этого просто НЕЛЬЗЯ, это буквально скам.
Пруфы?
Покажи мне проект, где это реализовано хотя бы на 30% от такого уровня графона в игре (не отрендеренном видосе, игровой движок не для этого существует, я могу отрендерить и вставить видео в любой движок). Или ты сейчас тупо скажешь, что это "не нужно", поэтому это никто не сделал? Я тебе сразу отвечу - это бы сделали даже просто так, за бесплатно, энтузиасты, если бы это было возможно. Не говоря уже о том, что разрабывать игры с хорошей графикой выгодно финансово и твои мантры о том что только гиперказуалки приносят бабки просто смешны..
>>1018300
Причём, самое смешное, ладно бы это была новая тема, типа наебали на хорошй графон только щас, я вот скинул самый свежий видос, но подобная хуета технодемок у юнити выгодит ГОДАМИ с гиперреалистичным графоном, но как вершину разработки в юнити всё так же приводят firewatch и сабнавтику с графикой понятно какого уровня.
пидор, спок, ты в юнити идёшь за графикой? цель какая? ты сначала определяешься с целью, потом подбираешь инструменты и начинаешь делать
>Речь идёт о том реализуемо
А что на юнити не реализуемо? Технодемку с картинкой как в кино?
Эпики их клепают на блюпринтах по большей части, поэтому и можно повторить по быстрому.
Только какой смысл? Это не влияет ни на что, кроме как стимуляцию гоев.
>>1018304
Опять "нам это не нужно". Окей, тебе это не нужно, вопрос в чём? Нахуя скамить на это этим НАЕБАЛОВОМ? Ты совсем тупой? Вопрос не в том, что в юнити хуёвая графика, а в обмане.
> но как вершину разработки в юнити всё так же приводят firewatch и сабнавтику
"Кто то там что то говорит". Аргумент "ну говорят же" это всегда кринж.
Я вот про фаервотч вообще нихуя не знаю, а сабнаутика игра охуенная, но не вершина фотореалистичного графона, да и старая уже довольно, и мне в целом поебать кто там что абстрактно говорит, не знаю, посчему это должно считаться аргументом.
>>1018300
> Покажи мне проект, где это реализовано хотя бы на 30% от такого уровня графона в игре
Многие технодемки юнити в открытом доступе лежат, бери, запускай.
Вопрос только один - с чего ты взял, что знаешь всё что делается на юнити и все технодемки созданные энтузиастами?
> Не говоря уже о том, что разрабывать игры с хорошей графикой выгодно финансово и твои мантры о том что только гиперказуалки приносят бабки просто смешны..
Не знаю, откуда ты такие мантры выдумал и с чего ты взял, что они мои.
Гиперказуалки, к слову, уже давно всё и мало приносят.
А что касается графики - если игра на 2060 не работает - её перспективы уже очень сомнительны
> не отрендеренном видосе, игровой движок не для этого существует, я могу отрендерить и вставить видео в любой движок
Тебе показали уровень графона который можно достичь в реалтайме на современном железе, а не наполненный открытый мир, в котором будет сотни домиков с тысячами объектов с таким уровнем графона.
Bevy что-то подобное пытается сделать, но она еще на ранних стадиях разработки
Урина с обреза свинины не иссякнет никогда! Идеальный движок говна для объеба гоев! Быстрее делайте игры на нём, пока все не одумались!
Это очень сложно и не имеет смысла.
Легче сразу определить что тебе нужно.
Сейчас делаю движок одновременно с игрой для веба и это шиза полная.
Лучше использовать юнити или унреал. Но у меня конечно не совсем игра, так что не вариант.
>невозможно без нанокомпуктира с железом уровня 4070
Как же проигрываю с нищуков для которых 4070 это такая гипердорогая-убержелезка что они даже приводят ее в пример "нереалистичности" требований УЕ к компуктеру.
Абсолютно все претензии на этой борде к УЕ можно свести к "ряяя на моей нищесборке ниидет!"
Дауничи, если у вас нет денег на среднее железо, надо не в игрушки играть, а начать с себя пойти наконец-то работать.
у большинства игроков её нет
https://store.steampowered.com/hwsurvey/videocard/
>Абсолютно все претензии на этой борде к УЕ можно свести к "ряяя на моей нищесборке ниидет!"
Свинолахтовый глюпи глюпи гои, уже купил 5090 чтобы поиграть в игры на урине в 60 фпс? 80 версия исправит этот каловый движок, главное верить.
С точки зрения разработчиков, ожидание видеокарты уровня 4070+ - может сильно срезать аудиторию.
> Дауничи, если у вас нет денег на среднее железо, надо не в игрушки играть, а начать с себя пойти наконец-то работать.
Если у тебя все хорошо сложилось, не значит, что у всех так. Рабочих мест с большой зп на всех не хватит, абсолютное большинство рабочих мест довольно малооплачиваемые и 100к на видеокарту будет ох как не просто найти
хз, у меня 900 фпс на старой карточке 5 летней давности
с ТАА, динамическим освещением и тенями, постпроцессом, на дх12
может у вас руки из жопы просто растут?
>С точки зрения разработчиков, ожидание видеокарты уровня 4070+
Ожидание видеокарты такого уровня только если ты хочешь топ графон, настройки по-хорошему разрабы должны тебе дать срезать до твоего уровня. Так что претензия к анрилу всё равно не в тему. Если у тебя в принципе говнопека, то никакой движок тебе не даст поиграть с топовым графоном. На анриле при желании можно отрубить наниты и люмены и ебашить по-старинке: делать LODы и запекать свет.
>ебашить по-старинке: делать LODы и запекать свет
Но, большинство конечно берут его как раз чтобы избежать этого процесса.
Особенно если в игре динамическая сменя дня/ночи.
> Ожидание видеокарты такого уровня только если ты хочешь топ графон, настройки по-хорошему разрабы должны тебе дать срезать до твоего уровня. Так что претензия к анрилу всё равно не в тему.
Просто все на разных языках говорят и спорят с выдуманными ими самими же аргументами для противоположной стороны.
Я даже не про тебя лично конкретно, это просто частая ситуация в этом треде и не только, и сейчас одна из них.
Вот тут чел >>1018291 как будто бы говорит, что 4070 это минимум для приемлимой работоспособности технодогий рекламируемых анрилом. Подразумевая, что видеокарты слабее уже не смогу приемлимо использовать эти технологии.
Ты же сейчас говоришь, что можно просто взять отключить все эти технологии и 4070 тогда перестанет быть минимальным требованием поэтому нельзя это записывать в претензии.
Как там в 2007? Сейчас курьер 120+ получает. С учетом расходов на еду и питание, это максимум месяца 3 на самокате покататься
Ожидания что современный движок должен выдавать качество ааа уровня на компуктерах из музея, по меньшей мере странно.
Может быть, дело в том, что курьерам платят не так уж плохо?
В стране медиана 50к по официальным данным(в москве 70к), и если немного пообщаться с народом, то понятно что так оно и есть, очень многие получают 30-50к, продавцы, кладовищики, слабоквалифицированные офисные работники, обычные юристы, заводские рабочие(смотря какой завод), научные работники(лол). Больше медианы это те у кого уже хоть сколько-то востребованная занятость.
Даже если все малооплачиваемые специалисты пойдут резко курьерить - деньги в экономике из воздуха не возьмутся, ставка курьеров обвалится ввиду такого предложения на рынке соискателей и уже у курьеров зарлата станет 40к.
если все разработчики игр сейчас пойдут курьерить - ничего не изменится, т.к. их несколько сотен человек на всю Россию
скорее несколько десятков тысяч
несколько сотен в одном гд сидят
Где я написал что курьерам плалят плохо? Курьерам платят очень хорошо и грех не воспользоваться таким перекосом рын очка пока еще есть возможность.
Даже если не идти курьером, то можно откладывать по 10к в месяц и скопить денег чуть менее чем за год. Вы охуели совсем просто в край и хотите ничего не делать и чтобы все было при этом. Есть ли смысл напоминать что так не бывает? Настолько детские инфантильные ожидания от жизни кроме игрунов я видел только у ебнутых баб, которых растили принцессами и которые теперь ждут что вот прям завтра должен свалиться принц и увезти на белом бентли в дубай.
Причем тут вообще разработчики игр?
Речь шла о том, что большинство народу не может позволить себе 4070, и совет "те кто не может должны не в игры играть а просто пойти работать)))" идиотский, в большинстве сфер большинству работников платят довольно мало, а востребованных мест на всех не хватает.
Такую хуйню несешь
> Даже если не идти курьером, то можно откладывать по 10к в месяц и скопить денег чуть менее чем за год
Пиздец) Год копить на видяху)))
Это и есть не можешь себе позволить считай, поэтому что на такое пойдут уже совсем единицы самых упертых кому больше ничего не нужно.
Я буквально не знаю никого, кто стал бы год копить на видяху в здравом уме, да даже не в здравом.
> Вы охуели совсем просто в край и хотите ничего не делать и чтобы все было при этом.
Расскажешь это продавцам, поварам, офисным работникам, бухгалтерам, работягам на заводе, юристам, консультантам, челикам в пвз, учителям, которые ебашут на работе, даже больше 8 часов в день, и получают копейки?(не надо только плез говорить что на заводе 200к можно получать, как и некоторым другим из списка - это нужна особая специализация или квалификация - не на каждом заводе делают одно и то же)
Инфантильная позиция как раз у тебя - ну чо вы просто курьерами устройтесь)
А в стране есть куча поселков, куча маленьких городов где курьеры не актуальны, да что уж говорить - курьером не каждый сможет работать на постоянной основе, об этом говорит банально их востребованность, было бы так легко - толпы бы ломанулись и зарплаты бы упали.
Ну и уже упомянутая мной вместительность рынка - все вышеперечисленные разом курьерами стать не смогут.
Всё в общем-то зависит от размера экономики, из воздуха она не берётся, все станут курьерами - и зарплаты такие им будет брать неоткуда - об этом я тоже уже писал.
>А в стране есть куча поселков, куча маленьких городов
В каждой стране такое есть, 4070 и выше - не популярные карты, нечего приплетать Россию
https://store.steampowered.com/hwsurvey/videocard/
>>1018612
При том, что это раздел /gd, и совет пойти работать курьером для разработчиков игр - вполне здравый, а вот фантазии "если бы все пошли курьерить" - подростковые хотелки, недостойные обсуждения. Я посчитал собеседника слишком умным.
> В каждой стране такое есть, 4070 и выше - не популярные карты, нечего приплетать Россию
Это ответ был не про доступность 4070 по миру, а про то, что совет "идите просто работать)" идиотский. Люди и так работают где могут.
> При том, что это раздел /gd
Только вот был тезис, что если не можешь купить видяху - ну иди просто работать, в нем не были упомянуты разработчики игр, и этот тезис вообще откололся от обсуждения ЦА игр. На что и бвл дан ответ.
Так что в нем разработчики игр не причем.
> и совет пойти работать курьером для разработчиков игр - вполне здравый
Тут сразу 2 проблемы:
1. Курьер это профессия не для всех(актуально для больших городов, большая нагрузка, психологически может быть тяжело монотонно кататься)
2. Разработчики игр это все же востребованная профессия, и получают они намного больше курьеров. Рациональнее подтянуть навыки и нацти соответствующую работу, чем курьерить.
> а вот фантазии "если бы все пошли курьерить" - подростковые хотелки, недостойные обсуждения. Я посчитал собеседника слишком умным.
Какие хотелки? Я тебе говорю о том, что это рыночек, если чел не работает курьером, значит на то есть причина, ты не модешь просто каждому дать совет пойти курьерить
тем не менее, совет правильный, ведь средний курьер зарабатывает больше среднего гэдачера, у которого доход это 11к пенсия по шизе и 8 рублей с яндекс-игр
Вот каждый такой чел, говорит абсолютно одно и то-же на каждую игру сделанную на урине - что вот руки прямые надо, инструмент то хороший. А если и это плохо - ну это руки не прямые были.
Это вот прямо в 9 из 10 случаев звучит так от каждого. И ничего не меняется, даже при том, что над игрой могут работать целыми студиями, а игра будет кривой казалось бы в банальных вещах.
А сами эпики неприкасаемые будто, в их сторону ничего не говорят, что такое говно создали. Хотя надо им вылить не одно ведро помоев на голову, чтобы поели за своё детище.
Они только в плюсе по сути - больше студий будет платить эпикам, чтобы те привлекали своих спецов-индусов в помощь, так как разрабы чёт не справляются с нагрузкой на таком непонятном движке, который как будто специально сделан с нюансом который обнаружишь намного позже по мере освоения.
Умно.
"Это правда нужно объяснять?"
Я еще раз повторю СВОю мысль для особо тупых. Она довольно проста. Есть деньги - играешь в игры, нет денег - не играешь. Игры это удовольствие, а за удовольствие приходится платить. Так устроен этот несправедливый мир.
Пока твои претензии к УЕ выглядят как претензии толстой, прыщавой телки к администрации Дубая. Сделали слишком дорогой и красивый город. Страшных телок туда не зовут.
>Расскажешь это продавцам, поварам, офисным работникам, бухгалтерам, работягам на заводе
Мы же не о цене на картошку в пятерочке говорим, а о компьлюктерном оборудовании для игр. 4070 как бы не входит в число жизненно важных товаров первой необходимости и не обязяна быть доступна малоимущим.
>Есть деньги - играешь в игры, нет денег - не играешь.
Игры на урине - говнище ебаное для тупых гоев. Твои попытки оправдать это поделие индусов выглядят ещё более смешно, чем попытки оправдать мистическую потребность в современном железе, желательно самое актуальное, которое даже за бесконечные деньги не способно вытянуть плавно любую игру на урине какой-нибудь без статтеров, либо мыла на экране.
> Пока твои претензии к УЕ
У меня не претензий к УЕ
>>1018673
>>1018670
В целом, я не знаю, на что эти 2 ответа и что тут сказать.
В них приводятся ответы на аргументы и утверждения, которые я никогда не приводил.
То есть я выше сделал какие-то утверждения, а в этих 2 ответах они никак не затронуты и идет ответ на чето вообще другое что-то, что и так само по себе очевидно.
Тип я говорю, что большинству населения недоступны топ пека и оно с этим ничего не может сделать(массово) и не надо народ в этом винить(т.к. выше было обвинение, что вот все у кого денег нет и не ебашут курьерами - охуели, а я приводил арумент почему это невозможно) на что получаю ответ:
>Есть деньги на игры играешь - нету не играешь
Ну, заебись. Кажется по этому вопросу у нас и не было разногласий, и более того все обсуждение и началось с обсуждения этого факта. Да, именно факта, никто даже не выражал сомнения, что если на что-то не хватает денег - то на это на хватает денег.
Ещё добивается вот этим
>4070 не входит в число жизненно необходимых товаров, она не должна бвть доступна малоимущим
Хуй знает, с чего вообще ты решил, что я это заявлял.
Я заявлял, повторюсь опять, что народ и есть малоимущий в массе своей и не по своей вине, и мой доеб был в том, что тв подавал это так, будто это очень легко поцти ебошить курьером и лутать деньги для кого угодно.
>У меня не претензий к УЕ
Тогда сорян. Видимо перепутал тебя с >>1018675
Приношу свои искренние извинения
Вы в курсе, что игры на анриле оптимизируют так, что они могут работать на встройках?
Сам редактор да, тяжеловат, но раз ты решил что ты разработчик, то изволь купить мощный компуктер, любой софт для разработки тяжелый по ресурсам, на слабом железе ни код нормально не попишешь, ни модельки не по раскрашиваешь.
А итоговый билд игры на анриле может требовать гораздо более простого железа, чем сам движок.
https://youtu.be/TuaG56SfSeo?si=ZcOn3MaHGqFSXWzq
А так ваш Анрил может?
теоретически да, если модифицировать движок и использовать его мобильный рендеринг на ПК. практически - вряд ли запустится на таком старом железе, потребует каких-нибудь инструкций, которых нет в четвертом пеньке
В чем смысл этой демки? Типа запустили очередной дум на кофеварке? Зачем вообще что-то делать с 4 пнем в 2025 году? Его место в компьютерном музее.
Если ты программист - позови художницу, если ты художница - позови программиста.
Ну ты конечно можешь верить в свой манямир где все выходящие на урине игры говно и лагают, а марвел райвалс, вуконг и ремейк подливона дальше собирают гешефт.
замени проц, видяху и добавь оперативы, очевидно же. правда придется купить мать к новому процу, а к новой видяхе еще и БП. и желательно о новом системном диске можно подумать на PCI-e 5.0. корпус тоже лучше заменить на продуваемый, чтобы вся эта мощь не душилась. как-то так
Видяэа ускоряет только рендеринг и запечку света, ссд любой одинаково перформит примерно с разницей в несколько процентов, реальная разница будет только в линейной записи и чтении очень больших блоков данных на много гигабайт
Поясните для анрилобояр, пожалуйста. Юнитебляди опять соснули или что?
Юнька блочит персональную (бесплатную) лицензию если посчитает что ты слишком успешен или заподозрит что ты работаешь в компании. Как и обещали. Не просто так же зондов-аналитики напихали, это теперь малварь, которая следит за каждым действием.
эта хуйня на все версии распостраняется я так полагаю? или только на свежие хрюнити666?
Задним числом - на все. Это последствия того первого скандала при увольнении СЕО. Потом они там чего-то откатывали после бури дерьма в соцсетях, но не помню откатили ли конкретно это.
>анрилобояр
Так ты такой же, лол. Полагаешься на доброжелательность Свыни. У него завтра фортнайт перестанет мегаденьги приносить и все, приехали.
Вообще необучамые.
Нихуя, в случае со свыней ты защищён лицензией, которая привязана к версии движка. Если свыня одебилеет, то сможет дичь творить только в новой версии, иначе его ждут судебные тяжбы, то есть в случае чего ты сможешь спокойно дорабатывать на своей версии.
Юнипитеки всегда были мутными пидорасами и поэтому изначально не привязывали лицензию к версии движка, а потому могут заниматься дичью ретроактивно.
>только в новой версии
Юнидауны так же говорили, поэтому и бурлили после факта.
>иначе его ждут судебные тяжбы
Которые осилят только большие дяди вроде беседки, а скорее всего просто договорятся. А лично тебе, нищему петухониксу с двача, проведут по губам и удалят к хуям твой нескучный симулятор ходьбы на ворованных ассетах, не говоря о том что до нормального суда ты даже не доползешь.
Вв ебанутые? Фри лицензия = зарегал акк, вот тебе лицензия.
Без хаба, полагаю, она даже нахуй не нужна.
Алсо работаю в большой компании, тут у половины персонал лицензия.
>Юнидауны так же говорили
Не пизди, никто так не говорил, они внесли изменения ретроактивно, поэтому и бурления были. Многие сьебали с юньки после этого, как тот же Тарков, Сабнаутика.
>Юнипитеки
Аналогов хрюнити - всё ровно нету. Годот слишком говно, урина слишком затратная в плане доведения стилизации до ума и кода. Особенно если цель сделать чтобы игра выглядела как что-то из 2010.
А уж тем более нюфаням по типу меня.
На хрюнити поковылся в настроечках плагина и у тебя хорошая запеканочка на выходе. В урине насколько помню какая-то мутная хрень с этим, и без мочной ГПУ не запечь адекватно.
Терпим.
Наес маняистории со дна бутылки. Говорили еще как, в точности как ты, ДО того как изменения внесли, ещё при мердже с айронсорсом.
Нюфаня, а почему ты думаешь что твои мысли хоть как-то основаны на реальности? На опыте? На чем-нибудь? Ты же нюфаня, твой опыт в геймдеве - сегодня и вчера. Ты даже релиза не нюхал.
Залетышь, ты вчера родился? Слюнки тебе утирать никто не будет.
>На хрюнити поковылся в настроечках плагина и у тебя хорошая запеканочка на выходе. В урине насколько помню какая-то мутная хрень с этим, и без мочной ГПУ не запечь адекватно.
Ну ты просто туповат видимо, нормальным людям ничего не мешает и 2Д и лоуполи на урине делать. Но да, анрил посложнее юнити и годота, там нужно айкью выше двузначного хотя бы.
> основаны на реальности
У меня есть несколько знакомых, которые работают аутсорс на УЕ5 в т.ч ебанутые плюсовики, и несколько блюпринтодрочеров. И как-бы слегка поинтересовавшись/понаблюдав пришел в такому выводу.
>>1018791
>даже релиза не нюхал
По факту так и есть. Я и не говорю так-то, что это истина в которую я верю. Могу ошибаться конечно.
Я понаблюдал за твоими постами в ИТТ и пришел к выводу что ты даун с однозначным айкью, нюфаня. Хотя ты, к счастью, даже не мой знакомый.
>ты даун с однозначным айкью, нюфаня
Ты меня щас оскорбить хотел? Мне тебя тоже можно хуесосом назвать?
Просто не пизди с уверенным видом о том, чего не понимаешь и чем даже не занимаешься.
Brackeys, ваш же юнитибох и все его адепты. А полтора шизика остались убеждать всех вокруг что никто не съебал.
?)
Блогер который снимает гайды для тех, кто вчера открыл юнити?
Блииииин
>никто не съебал
Так а кто съебал то? Речь об инди или о студиях? Поименно желательно.
Так он сьебался, как только юнити перестало заносить ему деньги. Попытался поделать контента на годоте, а там хуй. За год смог только 3 видео сделать.
>Переделываю
https://www.youtube.com/@tokyospliff
Это просто один из вариантов прокрастинации. Вместо того, что делать игру, он пишет движок и снимает дебильные видосики.
Все вопросы к нейронкам. Почему они не делают как я хочу. Приходится писать вручную
Мне пох ньюфажище или не ньюфажище.
Факт в том, что брекей делал контент для тех кто в первые зашел в юнити, ушел он или нет - поебать на самом деле он ушел с юнити, потому что занялся органищациец гейм джемов, но это мы опустим
Бизнес и про игроделы как сидели на юнити так и сидят
Так он безыгорный, хули бы нет, если дохуя свободного времени. Делает контент, рисует очередной треугольник на опенгл, собирает на этом просмотры с монетизацией, игры не делает и не планирует
В этом ничего плохого нет, если ты сам осознаешь, что безыдейный в плане игр, или не можешь в арт/дизайн/сторителлинг, например
Так бздотя и нейросетевой бздодик это один кадр?
Не удивлен.
>Никто не съебал, кроме полутора шизиков
Сабнаутика, Тарков, Darkest Dungeon, Amogus, Slay the Spire
> Сабнаутика
Уход не связан с политикой юнити
> Тарков
Пиздежь и я хз зач даже комментирую
> Amogus
а?
> Darkest Dungeon
> Slay the Spire
Полтора шизика
@
РЕШИЛ УСТАНОВИТЬ BEVY ПОПРОБОВАТЬ ЧОЭТА
@
СЛЕДУЕШЬ ДОКУМЕНТАЦИИ
@
ЗАПУСКАЕШЬ ПЕРВЫЙ БЕВИ ПРОЕКТ
@
ЦПУ ЗАГРУЖАЕТСЯ НА МАКСИМУМ И ХУЯРИТ БИЛД 10 МИНУТ
>НАЧИТАЛСЯ ПРО ECS МОЛ БЫСТРА ЕБАТЬ
ну может быть для анальников с 20 летним стажем - это легко и просто, но ECS это уже другой уровень кодинга, вкатуны не потянут
Ецс это архитектурный подход в первую очередь.
Уже во вторую очередь ецс может быть реализован как дод архитектура, с линейным расположением данных в памяти и многопотоком, что уже даёт и перформанс в рантайме.
Про скорость компиляции никто ничего не говорит.
>ЦПУ ЗАГРУЖАЕТСЯ НА МАКСИМУМ И ХУЯРИТ БИЛД 10 МИНУТ
Welcome to rust
Зависимости проекта загружают зависимости зависимостей, и это все пердит и долго компилируется
Зависимости в любом языке кэшируются, загрузка не является фактором.
Ровно как и их компиляция - повторно компилировать то, что скомпилировано - не нужно.
ничего сложного. то для чего екс предназначен на нем легко делать - композитные игровые сущности с разными свойствами
сложно и костыльно делать на екс те вещи, которые с ексом хуево дружат (гуй, рендеринг, скрипты, оптимизация)
> гуй, рендеринг, скрипты
На нём это и не надо делать
> оптимизация
?
>?
ну вот ты делаешь дайти_всех(мувабл, пёрдабл, омайгадабл}, и задача решить что такое "все" находится вне компетенции екс, и не имеет однозначного оптимального решения
А без ецс получается есть однозначное оптимальное решение? Значит ецс накладывает какое-то фундаментальное ограничение, кгторое этому мешает?
эта проблема актуальна для абсолютно чего угодно, и что с ецс, что без ецс имеет разные решения
В дотсе например данные группируются по архетипам, и все ентити с одинаковым набором компонентов лежат в одних и тех же линейных массивах данных.
Соответственно выборка по архетипам эквивалент цикла по массиву структур
Для других сценариев, когда выборка включает несколько архетипов - хранится кеш какие архетипы удовлетворяют условию выборки и также цикл по всем подходящим архетипам
Другими словами, у дотса перформанс для выборок максимальный
Структурные изменения более прожорливые, чем в некоторых других ецс фреймворках из за системы архетипов
ключевое слово - без екс. сталкиваясь с проблемой оптимизации, екс архитектура перестает быть екс
это очевидно, когда ты с нуля пишешь екс игру, не используя готовый движок с прикрученным где-то сбоку ексом
Что?
Простой вопрос - каким образом концепция ецс(ентити, компонент система) накладывает ограничения на оптимизацию?
> сталкиваясь с проблемой оптимизации, екс архитектура перестает быть екс
Пример?
Покажи такую оптимизацию, которая вынуждает ецс перестать следовать канонам ецс.
> это очевидно, когда ты с нуля пишешь екс игру, не используя готовый движок с прикрученным где-то сбоку ексом
Какая разница готовый движок или твой личный? Это как то меняет концепцию ецс?
>Какая разница готовый движок или твой личный?
в готовом не ECS движке архитектура уже не ECS. ECS там это просто гиммик
в настоящей ECS архитектуре всё делается через ECS
в том числе рендеринг объектов. подтянул все рендераблы, отрендерил
подтянул все физически сущности, отсимулировал столкновения
и т.д.
> в готовом не ECS движке архитектура уже не ECS. ECS там это просто гиммик
Ецс это архитектура в которой есть такие сущности: ентити компонент систем.
Если программный код оргагизован в соответствии с этой концепцией, то его логично назвать ецс.
В чем противоречия юнитевского ецс или беви этоц концепции?
> в настоящей ECS архитектуре всё делается через ECS
> в том числе рендеринг объектов. подтянул все рендераблы, отрендерил
> подтянул все физически сущности, отсимулировал столкновения
> и т.д.
Ты сказал? Лол.
А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
А на что влияет то что нечто является нещитовым гиммиком? У этого есть негативные стороны помимо того, что ты скажешь, что это гиммик?
То есть если я прочитаю какую-то статаью по ецс с примером реализации какой-то механики - применить я это не смогу потому что у меня "не ецс, а гиммик"?
Или если я прочитаю про вариант организации фабрики для попапов - соответственно тоже не смогу применить потому что у меня и не ооп толком?
Кстати а вот мы сделали например и рендер, и физику, и геймплей, флоу игровой на ецс например. Но чтобы проиграть звук - надо дернуть нативное апи. А в нативном апи там ваще не ецс, а кривой косой набор функций. Значит тоже не ецс уже?
Нет никакой "настоящей ецс архитектуры", да и вообще какой либо ещё, есть набор абстрактных идей и конкретных практик по организации кода.
Если ты какими-то из них пользуешься для реализации какого-то кода, то ты модешь сказать что ты им пользуешься и это другому программисту даст в общих чертах понимание устроцства твоего проекта. А также позволит тебе посмотреть какие-то ещё практики и идеи по поддержке этого подхода и применить их.
Обрати внимание на аыделенное жирным - какого-то кода.
Ты можешь всю игру сделать на ецс, можешь кор геймплей, а можешь и вовсе какие-то фрагменты геймплея. Это никоим обращом не менчет то, что этот кусок кода можно впринципе попытаться классифицировать и это даст результат.
А какие-то понятия существующие в вакууме и твой вердикт гиммик или не гиммик не играет роли
> А если у меня в игре кор геймплей логика сделана на ецс, логика интерфейса на MVP, контролы интерфейса на юнитевской компонентной системе, рендер и физика вообще проприетарная хуйня с совершенно другим проектированием и использованием статики и синглтонов, то получается у меня игра сделана ни на ооп, ни на ецс, а и то и другое там - гиммик и нещитова?
да. твоя игра - ООП с незначительными вкраплениями ECS
хочешь познать настоящий ECS - пиши с нуля игру на ECS, без движков. в процессе 95% твоего ECS кода перейдет в категорию "это на ECS не делается, ECS не для этого"
Хорошо. Так а минусы будут?
Мой основной вопрос был - хорошо, не ецс а гиммик. А на что это влияет?
Дополнительный вопрос(к оригинальному твоему посту) - какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
Ведь "это на ецс не делается" это как правило не вопрос производителньости, а вопрос архитектуры, фабрики с диаем это не то чтобы более быстроее решение, чем ецс
ни на что не влияет. я же не писал, что екс это плохо. это как настоящая стейт машина: хочется где-то применить, но постоянно хуйня какая-то возникает, и в итоге проще выкинуть и переписать без неё
> какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
екс это про итерирование по массивам, и чем оно более дробное и изолированное - тем ексней. ты теряешь в производительности из-за постоянного итерирования по близким по смыслу массивам в разных системах. ну или склеивать в одну гигасистему, которая имеет гигантский апдейт метод с кучей проверок внутри. это противоречит философии екс
> ни на что не влияет. я же не писал, что екс это плохо.
Нет, я спрашивал что влияет гиммик или не гиммик. Ты говоришь - в движке там не настоящий ецс, а гиммик. Я и спрашиваю - а на что это влияет?
Вот я говорю например - на ецс можно заебись производителньости достигать, в юнити ецс фреймворк очень производительный.
Ты отвечаешь - там ецс это гиммик и не настоящий ецс. Ну... э... и что? В чем ценность термина гиммик, что он должен обозначать, в чем его смысл?
> это как настоящая стейт машина
Блен, ну я не понимаю просто тебя.
Нету ничего настоящего. Есть просто идеи и практики и всё, и не более.
Игрушечнач стецт машина, или настоящая - эта терминология не имеет смысла. Если какая то часть кода похода на стейт машину - то эта часть кода похоже на стейт машину и скорее всего правильно будет её называть стецт машиной при общении с другими программистами и поиске каких-то решений проблем или полезных практик.
Ты же не будешь искать "как в гиммике игрушечной стейт машине сделать контроллер анимаций персонажа"? Нет конечно.
Поэтому и наличие этого термина - бесполезно. Поэтому я и не понимаю твоего исходного сообщения
Давай вспомним вообще с чего все началось - ты сказал на ецс хуево делать оптимизацию.
Я уточнил что именно
Ты сказал - нуу выборку по данным
Я сказал - да нет, заебись, на ецс можно дод реализовать и выборки будут перыормить также как проход по линейному массиву
Ты ответил - это не настоящий ецс, а гиммик
Эаэаээаээа
Это в чем вообще смысл того что ты пишешь? Я НЕ ПОНИМАЮ
У меня простая позиуия - если что-то выглядит как х, любой фрагмент кода, то оно выглядит как х. Называть этт не намтоящим потому что другой кусок кода в проекте не выглядит так - просто бред
> ты теряешь в производительности из-за постоянного итерирования по близким по смыслу массивам в разных системах. ну или склеивать в одну гигасистему, которая имеет гигантский апдейт метод с кучей проверок внутри.
А ты уверен? То что ты описал - добровольный путь к кеш миссам и невозможность многопотока.
И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
>эта терминология не имеет смысла
настоящая стейт машина - машина, которая возвращает другой стейт, удаляя старый стейт. дискретная стейт машина. но в реальной задаче ты начинаешь серить туда костылями с иерархиями, стеками, глобальными переменными, до тех пор, пока не задашься вопросом - а нахуя мне этот гиммик, если без него будет проще и лучше? это и есть определение гиммиковости
гиммиковый екс - когда ты в ущерб архитектуре организовываешь себе екс песочницу, где играешься в екс, потихоньку вытаскивая оттуда свой бывший ексным код в категорию модулей которые "не подходят для екс". заметь как ты сразу задефолтился про "гуй, рендеринг, скрипты" что не надо это делать на екс. хотя как ты это решил? прочитал как другие так пишут? или сам пробовал? в юнити с прикрученным сбоку екс плагином ты не мог этого сделать. а значит прочитал как другие так говорят, и повторяешь за другими. только вне движка можно сделать полноценный проект на екс. потому что екс это компетенция движка, а не игры
> - а нахуя мне этот гиммик, если без него будет проще и лучше? это и есть определение гиммиковости
Вот, всё, ты дал чёткое определение. С этим можно работать.
> гиммиковый екс - когда ты в ущерб архитектуре организовываешь себе екс песочницу, где играешься в екс
А вот тут ты сильно ошибаешься.
"В ущерб архитектуре" - а где ущерб? А в ущерб ли? А может не в ущерб? Как ты понял, что в ущерб, и что там у меня? А может быть я применяю ецс там где нужно?
> потихоньку вытаскивая оттуда свой бывший ексным код в категорию модулей которые "не подходят для екс".
Это тоже очень странное утверждение.
Мне кажется, надо делать задачу таким способом, который для нее подходит.
Подходит ецс - делай на ецс. Не подходит ецс - делай не на ецс.
Если в процессе выяснилось, что не подходит - ну, можно порефакторить, если время на это есть и оно того стоит.
> заметь как ты сразу задефолтился про "гуй, рендеринг, скрипты" что не надо это делать на екс. хотя как ты это решил?
> прочитал как другие так пишут? или сам пробовал?
Ну, я не ждунище, у меня есть какой-то опыт. Мой опыт мне подсказывает это.
Может у тебя есть хороший вариант реализации гуя на ецс. Мне она не известна и есть проблемы которые мне кажется будут у такого подхода.
> в юнити с прикрученным сбоку екс плагином ты не мог этого сделать.
Лол. Мог. Что угодно можно. А в чем проблема?
Просто обычно берут лучший доступный инструмент под задачу, а не задачу натягивают на инструмент.
Под инструментом я разумеется подразумеваю не либу которую можно подключить, а набор практик и архитектурных решений, которыми можно оперировать для решения задачи.
> а значит прочитал как другие так говорят, и повторяешь за другими.
По поводу этого выше ответил
> только вне движка можно сделать полноценный проект на екс.
У тебя в движке доступен язык программирования, на котором ты можешь написать что угодно.
"Полноценный проект на ецс". А я например делаю не полноценный. И что?
В чём смысл этого утверждения? Какую полезную смысловую нагрузку оно несёт?
> потому что екс это компетенция движка, а не игры
Грань между движком и игрой размыта. Где кончается движок и начинается игра? Тупейший вопрос в обсуждаемом нами вопросе.
Движок закрыт, где начинается проприетарщина - там и кончается игра, да? Так лол, у тебя есть язык программирования, на котором ты можешь написать что угодно.
Это какое-то переливание из пустого в порожнее. Это настоящий ецс, это игрушечный, а это гиммик, а это полноценный ецс.
Да поебать вообще как ты это называешь так то.
Ты мне вот на главный вопрос ответь лучше, мне только жто было интересно
>>1019004
> И главный вопрос - ок, отказываемся от ецс, чем твое решение будет производительнее в итерировании? У тебя точно также будет вопрос итерирования по разным сущностям абсолютно такой же, хоть ецс хоть ооп хоть что ты выдумаешь.
>>1018995
> какие проблемы с производительностью заложены в концепции ецс и как отсутствие ецс помогает их обойти?
И давай сразу определимся, мы смотрим ограниченную задачу организации игровой логики. Нам совершенно похуй что там с другими частями игры, и настоящий это ецс или инрушечный, вот мы сделали геймплей на ецс и в нем все на ецс. Ты говоришь, ецс накладывает ограничения по оптимизации. Какие и как не-ецс поможет? Ты упомянал итерирования по разным сущностям - я тебе ответил, что на ецс ты можешь сделать так, что будешь итерировать по линейным массивам без каких то проверок. Есть какой то вариант итерации быстрее и он не доступен с ецс, но доступен без ецс?
Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз, это не то что несерьезно, это просто пиздец и выстрел себе в хуй с точки зрения оптимизации будет.
> чем твое решение будет производительнее в итерировании?
тем что ты не итерируешься и не подготавливаешь себе екс-песочницу чтобы поексииться по ней
>Ток не надо опять про мегасистему с ифами как пример вырождения ецс ради оптимизации плиз
ну что поделать, если не хочешь 50 тысяч раз итерироваться по всему миру, сначала чтобы сделать всем пук, а затем чтобы сделать всем среньк?. и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним, потому что мир динамический и игрок двигается, загружает-выгружает чанки и т.д.
Причем тут быстрота екс и скорость билда, ты точно связан с программированием хоть как-то?
У bevy 300 либ зависимостей, поэтому первый билд идет долго, потом это все закешируется и при повторный билд будет быстрый.
А екс там и правда летает.
> тем что ты не итерируешься
Цепяюсь к словам, но че это за бред?
То есть твой тезис "не ецс лучше ецс тем что ты там не итерируешься"? А как ты там обрабатываешь свои игровые сущности?
> и не подготавливаешь себе екс-песочницу чтобы поексииться по ней
В чем заключается "подготовка ецс песочницы"?
> ну что поделать, если не хочешь 50 тысяч раз итерироваться по всему миру, сначала чтобы сделать всем пук, а затем чтобы сделать всем среньк?. и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним
Ну это просто ты не знаешь как можно ецс под капотом устроить.
А я тебе уже выше писал как в дотсе сделано, там не надо делать такого каждый кадр. >>1018973
Это в целом довольно очевидный подход, думаю почти везде так и сделано.
> потому что мир динамический и игрок двигается, загружает-выгружает чанки и т.д.
При подгрузке-выгрузке действительно будут структурные изменения. Но неросредственно при добавлении уничтожении ентитей, а не каждый кадр, для этих структурных изменений тоже есть варианты как сделать, чтобы было не слишком дорого. И само собой никакой полной пересборки тут нету.
А без ецс получается можно сделать бесплатную подгрузку и выгрузку? Как?
Кстати
> и ведь каждый кадр нужно пересобирать эти массивы для ексенья по ним
Хоть это и по сути не релевантно ецсу, но... А ты уверен что пересборка каких-то данных каждый кадр будет обязательно того не стоить?
Типа если у тебя много динамичных объектов в игре и надо делать операции связанные с поиском объектов в разных областях, то в начале кадра заполнить структуру данных типа квадтри будет выгодно, например, если таких операций много за кадр. Быстрее, чем этого не делать, и все объекты перкбирать, чтобы нацти ближайший.
Сап аноны. Появилась идея сделать игру. Игра должна быть трёхмерной и при этом нетребовательной к железу, с графикой уровня Crab Game, может чуть лучше. При этом должна быть мультиплеерной. Мультиплеер на аренах, не опенворлд.
Программировать умею, но только на Scheme читал сикп в прошлом и больше ничего
Я так понимаю лучше всего взять юнити?
>В чем заключается "подготовка ецс песочницы"?
в том что тебе нужны структуры данных по которым ты будешь итерироваться в своем типа ексе. эти структуры нужно обновлять каждый кадр. ООП движок делает свои куллинги и оптимизации, а потом сверху на это еще раз делает вторую работу, чтобы побегать по сущностям ексом. у тебя игра делает две работы. в настоящей екс архитектуре делается одна работа. через екс.
Хз, я не знаю, это троллинг или что
> эти структуры нужно обновлять каждый кадр
Нет, не нужно.
И как это работает я уже описал в посте, который я линканул >>1018973 и дополнительные пояснения про структурные изменения тут >>1019113 перепечатывать не имеет смысла
Если не понятно что-то в этом объяснении или считаешь где-то там будет лишняя работа - процитируй и обоснуй почему.
> ООП движок делает свои куллинги и оптимизации, а потом сверху на это еще раз делает вторую работу, чтобы побегать по сущностям ексом. у тебя игра делает две работы.
Такой шизобред, пиздец.
У тебя в абсолютно любой игре будет сначала обработка игровой логики, потом рендеринг.
Абсолютно в любой игре у тебя по состоянию на конец игры будет набор каких-то данных, которые должен обработать графический движок и транслировать это в картинку.
Расскажи мне вот что:
В чем различия рендеринга, откуда берется оверхед, в подходе "с прикрученным сбоку ецс" и "тру ецс" или вовсе "не ецс", если в результате обработки игровой логики у тебя формируется одинаковый набор данных для графического движка?
В гиммик ецсе у тебя у тебя в структуре лежат данные описывающие нужную модель и материал и позицию... и в тру ецсе у тебя тоже самое. И не в ецсе у тебя точно также будет модель и материал в какой-то структур лежать.
Каким образом использование не гиммик ецс позволяет тут что то ускорить? Где будет повторная работа?
>процитируй и обоснуй почему
там ответ в стиле "где брать деньги? у мамки в кошельке!". ты на уровне юзера не понимаешь, что эти массивы нужно обновлять каждый кадр и при изменениях мира во время кадра
две работы происходят когда ты дважды обрабатываешь объекты, сначала в обычной парадигме, затем в екс. в настоящем екс ты всё делаешь через екс
> там ответ в стиле "где брать деньги? у мамки в кошельке!". ты на уровне юзера не понимаешь, что эти массивы нужно обновлять каждый кадр
> во время кадра
ЗАЧЕЕЕЕМ
У меня есть массив entityData[] в нем лежат данные ентити.
Что мне с ним надо делать каждый кадр и зачем? Нахуя?
Если говорить о более практичном примере, то будет несколько массивов под каждыы архетип и если говоорить про юнити там внутри еще будет разметка по чанкам, но глобально ничего не меняется - массивы точно также не требуют никаких изменений из кадра в кадр.
> и при изменениях мира
Структурные изменения я упомянал. Никакой полной пересборки массивов там нихуя не будет.
И вопрос очень интересный на эту тему я уже поднимал выше - а без ецс у тебя если новые какие то хрени появились или исчезли в игре в реалтайме - у тебя твои любые структуры данных бесплатно обновятся?
> две работы происходят когда ты дважды обрабатываешь объекты, сначала в обычной парадигме, затем в екс
Давай конкретику. Что значит "обрабатываются"?
Настоящий ецс и гиммик ецс делают условно абсолютно идентичные вещи:
цикл по ентитям1
ентити.ДуЛогик1() - модификация данных в структуре
цикл по ентитям2
ентити.ДуЛогик2() - модификация данных в структуре
цикл по ентитям
ентити.Дроу() - генерация дроу коллов по данным в структуре или иная обработка перед отрисовкой(пометки надо ли рендерить и т.п.)
Покажи мне где тут будет "обработка в обычной парадигме" для гиммик ецс по сравнению с тру ецс?
Также давай рассмотрим и не ецс подход
- вот для примера выше - у нас есть две каких то совершенно разных сущности в игре и и те и те надо нарисовать.
Какой мы можем сделать более эффективный вариант для этого чем "прочитать данные в структуре, поменять данные в структуре связанные с графикой и сгенерить дроу коллы"?
Просто судя по твоему примеру с мегасистемой, мне кажется, что у тебя есть огромное заблуждение ты считаешь что это заебись насрать ифами лишь бы лишней итерации по циклу не было, хотя на деле это руинит предикт процессора и с таким подходом тебе недоступна многопоточность - как минимум дроу коллы надо генерить когда все уже подготовлено и это можно распараллелить, а с таким подходом ты убиваешь эту возможность.
Я уж молчу про то, что ты можешь ну если уж так хочешь например взять юнити с гиммик ецс даже не дотс... и сделать там чтобы был один проход по массиву и в нем сразу все обрабатывалось как тебе нужно, сначала логика потом рендер. И абсолбтно ни в одном варианте не будет никаких лишних прослоек.
Концепции ецс это не противоречит и технически без проблем реализуемо.
затем, что это нормально. враги убиваются, пули исчезают, игрок двигает камеру. и все массивы тебе нужно еще раз пересчитать, сделав двойную работу
> затем, что это нормально. враги убиваются, пули исчезают
При любом подходе это требует модификации существующих структур данных
> игрок двигает камеру
Абсолютно никоим образом не влияет на структурные изменения на стороне ецс и любой другой организации твоей геймплейной логики. Все что можно закэшировать для рендеринга остается закешировано на том же самом месте
> и все массивы тебе нужно еще раз пересчитать, сделав двойную работу
Что значит "пересчитать массив"?
мне не нужны массивы архетипов и прочие кэши для екс, которые призваны сделать итерирование в екс дешевле. если я не применяю екс, мне не нужно это всё пересчитывать каждый кадр и пересобирать екс мир каждый раз когда я сдвинул камеру или заспавнил врага
> мне не нужны массивы архетипов
А, хорошо, не вопрос.
А что тебе нужно?
Где у тебя твои игровые сущности хранятся и в каком виде?
> и прочие кэши для екс
Кэши в сообщение выше были упомянуты как закэшированные данные для ренлера. Иных упомянаний не было.
У тебя есть кусок говна с физикой, он может перемещаться если его пнуть.
Для оклюжен кулинга у тебя есть возможность сохранить то в каком чанке он лежит и пересчитывать это только при изменении позиции, чтобы не делать это кпждый раз.
С ецс ты при изменении его позиции пометишь что ему надо пересчитать чанк.
Без ецс ты при изменении его позиции пометишь, что ему надо пересчитать чанк.
Что мне надо дополнительно "кэшировать" для ецс, что не надо без ецс?
> если я не применяю екс, мне не нужно это всё пересчитывать каждый кадр
> и пересобирать екс мир каждый раз когда я сдвинул камеру или заспавнил врага
В сообщении выше уже было упомянуто, что структурные изменения происходят только при наличии спавна/удаления ентити в ецс, и точно такие же изменения тебя ожидают без ецс.
Также выше было упомянуто, что каждый кадр нет никаких обязательных действий связанных с модификацией структур данных и было предложено тебе привести пример если есть, а те что ты тут обозначил уже были разобраны в том посте)
>С ецс ты при изменении его позиции пометишь что ему надо пересчитать чанк.
>Без ецс ты при изменении его позиции пометишь, что ему надо пересчитать чанк.
а с гиммик екс придется сделать и то и другое
Нет, зачем?
Ты в гиммик ецс сделал пометку и сохранил координаты чанка, эти данные напрямую будут использовать при рендеринге.
Зачем еще раз это делать?
затем что в екс мире еще раз закэшировано то, что закэшировано в ооп мире. то есть при удалении объекта в мире сначала почистить тут, затем почистить кэши в екс мире, всё пересчитать. 2 раза делается работа
Что ещё за ооп мир?
У нам просто массив структур, больше нихуя нет.
Вот просто нах натурально пишешь коде у себя(либо эквивалент скодогенерирован за тебя в готовом фреймворке)
entityData1[] - ентити с компонентом позиция, урон, пуля, моделька, графика
entityData2[] - ентити с компонентами позиция, моделька, хп, датаврага, графика
Никаких нахуй оопов нет и в помине, просто эти 2 массива и больше ничего.
вот настоящий екс это и есть то что "скодогенерировано за тебя" разрабом твоего плагина, а то что ты с точки зрения юзера не видишь что работа делается 2 раза - это специфика работы с плагином в не екс движке типа юнити
Окей.
Я беру юнити.
Я руками пишу буквы в коде:
entityData1[]
entityData2[]
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
Зачем мне какой-то ооп мир тут нужен?
Какую он роль выполняет?
В какой момент будет задействован? Я же букыально делаю прямые вызовы методов.
Ты думаешь я должен заспавнить юнити геймобжект с компонентом меш чтобы модельку отрисовать?) Нет, я могу напрямую графиечское апи юзать, ну почти напрямую, в юнити довольно низкоуровневая обертка.
> скодогенерировано за тебя
Кодогенерацией обычно обозначают автоматическую генерацию инфраструктурного бойлерплейт кода в конкретном проекте, а не "то что ращрабом сгенеиировано за тебя"(не уверен, что это вооьще значит? что разраб скодогенерировал)
Ну типа чтобы я руками не писал одно и тоже, оно само напишется. Для депенденси инжекшен еще юзают кодогенерацию например.
я не в курсе реализации твоего плагина. я исхожу из твоих же постулатов, что у тебя всё что не для екс вынесено за пределы екс. например, ожидаемо что управление подгрузкой уровней, рендеринг и физон делается движком. а то что ты пишешь это детские примеры екс из статьи "что такое екс".
хотя я даже не понимаю, зачем ты делаешь цикл по пустому массиву и что-то там исполняешь. ты создал пустой массив и итерируешься по пустому массиву? как это у тебя работает?
> я не в курсе реализации твоего плагина
Это не реализацию плагина, это псевдокод который буду запускать на псевдокомпьютере
> я исхожу из твоих же постулатов, что у тебя всё что не для екс вынесено за пределы екс
Предположим?
> например, ожидаемо что управление подгрузкой уровней
читать файл
подождать чтение файла
ентитиес1 = копировать(файл.данныеентитиес1)
> рендеринг
Дроумеш(меш, позиция)
> и физон делается движко
ентити.позишен = ассошиейтедРигидБади.позишен
Кстати знаешь есть еще всякие разные физические движки вроде хавок, бокс2д, физИкс? Они используются в юнити и во многих других движках, даже если игру с нуля пишут часто берут какой-то из них.
Каким образом их дружат с геймплейной логикой, как считаешь? Как думаешь, чем будет отличаться вариант подружить их с ецс или любым другим вариантом организации геймплея?
Или если мы например в компьют шейдере считаем фищику - как данные оттуда назад в в игру получить и как их туда запихать?
Да ничем нахуй, все что тебе надо сделать это проассоциировать айдишник объекта в этой физической ебале с твоим куском говна и копировать в кусок говна позицию проассоциированного с ним физического тела. Всё, вот весь оверхед.
А так, я даже свой физон писал в юнити. Я это уже несколько раз повторял - тебе доступен язык программирования. Ты можешь сделать им что угодно абсолютно.
> а то что ты пишешь это детские примеры екс из статьи "что такое екс".
Это минимизированный пример для демонстрации оверхеда при взаимодействии ецс-кора с разными системами.
Я же уже писал более общими словами, но ты отказывался что либо читать и понимать.
Я просто хз как тебе еще сказать, что если мы используем движок, то мы не обязаны все реализовывать только его средствами, что в том же юнити есть низкоуровневое апи для всего.
Более того, ты можешь даже юзать внешние системы без проблем как я приводил пример с физическими движками, можешь даже юзать юнити геймобжекты - это тоже рабочая практика, и делается это также как и интеграция физики куда угодно - проассоциировать твою какую то хуйню с сущеостью из другой какой то системы
Условно у тебя будет
struct BulletComponent
{
BulletView - геймобжект в юнити
Position
Speed
}
И оверхед тут тоже около нулевой так как это принципиально разные независимые сущности кроме одного момент - в BulletView надо скопировать позицию из BulletComponent.
Всё.
Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
Никакой окклюжен куллинг не будет влиять ни на что кроме БуллетВью.
Никакие массимвы не надо никак не пересчитывать ни кэшировать каждый кадр. Кор геймплей управляет всем, а не наоборот.
Отдельно хочу отметить гуи - абсолютно поебать свой ты движок пишешь, не свой, подружить ооп гуй с ецс кором это примитивнейшая задача с нулевым оверхедом для геймплейной части, тебе надо просто писать данные из геймплея в такю область памяти, откуда их сможет прочитать гуй. Всё.
>>1019208
> хотя я даже не понимаю, зачем ты делаешь цикл по пустому массиву и что-то там исполняешь. ты создал пустой массив и итерируешься по пустому массиву? как это у тебя работает?
Хорошо! Дополню пример
entityData1[] entities1 = new entityData1[100];
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
Пули заполнять не будем. Или надо, или ты скажешь "ну а попробуй пулю заспавнить или уничтожить надо перещитать все)))"?
Тогда я повторяю ставший уже вечным вопрос - а без ецс ты как пулю заспавнишь?
>Никакое нахуй движение камерой никак не повлияет на буллетКомпонент.
то есть ты всегда рендеришь все объекты в игре?
> то есть ты всегда рендеришь все объекты в игре?
Нет, с чего ты взял? Ты видишь в буллетКомпоненте какие либо данные связанные с рендерингом или оклюжен кулингом?
Я не вижу, я вижу только позицию и скорость.
Булет вью это ебаный адрес какой-то там хуйни в движке, геймобжект заспавненный в роп мире игры.
Каждый кадр надо к позиции прибавить скорсоть и сделать булетВью->позишен = позишен. Всё, больше ничего.
Не вадно вижу я булетВью, не вижу - это никакой роли на буллетКомпонент не оказывает. Рендеринг работает только на булетВью, и он да, будет участвовать в оклюжен кулинге, там заданы материал и меш, там даже есть какие то данные для рендеринга типа тот же маркДирти который мы выше упомянли. Точно также как без ецс он бы это делал.
>>1019213
> ты каждый кадр перегенериваешь массив?
Нет, это на старте игры происходит.
А дальше по ходу игры в апдейте делаю циклы которые выше приводил
ECS в принципе не приспособленная к оптимизации архитектура, тормознутая и поэтому в принципе не пригодная для разработки игр. Она хороша только в тупых демках типа миллион спрайтов в одну сторону двигать.
> ты каждый кадр перегенериваешь массив?
>>1019215
> > ты каждый кадр перегенериваешь массив?
> Нет, это на старте игры происходит.
Чтобы было проще
entityData1[] entities1 = new entityData1[100];
СтартИгры()
{
for(int i = 0; i < 100; i++)
{
entities1 = new EnemyEntity(randomPos);
}
}
Апдейт()
{
Делаю цикл по 1, делаю в нем
позиция += пуля.скорость х дт
рендерДата.маркДирти = тру
Делаю цикл по 2, делаю в нем
иф (енеми.долженПойти)
{
позиция += пиздуй
рендерДата.маркДирти = тру
}
Делаю цикл по 1 и потом по 2 и делаю
иф (рендерДата.маркДирти)
{
рендерДата.чанк = считаю чанк
рендерДата.маркДирти = фолм
}
дроуМеш(рендерДата, меш) - который напрямую вызыввет графическое апи дайрект хэ
}
Хорошо.
Мы просто в 100 ебал делаем игру на ецс и выжимаем нереальный перформанс, учтем твое мнение в следующий раз.
>Нет, с чего ты взял? Ты видишь в буллетКомпоненте какие либо данные связанные с рендерингом или оклюжен кулингом?
то есть у тебя существует буллет компонент несуществующей уже пули? нихуевые у тебя утечки памяти должно быть
>Нет, это на старте игры происходит.
то есть дальше у тебя вся игра статична, ни новых врагов, ни новых пуль, никакого куллинга объектов?
> то есть у тебя существует буллет компонент несуществующей уже пули? нихуевые у тебя утечки памяти должно быть
А хоче лайфтацм обсудить. Хорошо.
Только вопрос сразу некорректный
> то есть у тебя существует буллет компонент несуществующей уже пули?
Еще раз - кор контролирует все. Мы создвли ентити пули в коре - тогда создали буллетВью. Уничтожили - тогда уничтожил и буллетВью.
Если пулю не видно - не значит что она должна перестать "существовать" лол, просто она скипается при рендеринге.
У тебя за кадром пули не летают?
Наверное летают, просто не рендерятся.
> то есть дальше у тебя вся игра статична, ни новых врагов, ни новых пуль, никакого куллинга объектов?
Децйствительео, происходит такое.
А без ецс ты бы как эту задачу решил?
Вот надо заспавнить пулю, а у нас не ецс. Что мы делаем? Или уничтожить.
Может я смогу этот способ в своеф игре на ецс применить?...)))))))
>кор контролирует все
только что было 2 пустых массива, теперь уже появился некий волшебный контролирующий всё кор. а что такое кор? как он всё контролирует?
Хорошо, показывай игру. Будем мерить производительность.
> только что было 2 пустых массива, теперь уже появился некий волшебный контролирующий всё кор. а что такое кор? как он всё контролирует?
А, тут небольшое недопонимание, сейчас все объясняю.
Кор - это наш ецс. То есть весь код что писал тут >>1019217 это кор
Когда мы делаем вот это
> СтартИгры()
> {
> for(int i = 0; i < 100; i++)
> {
> entities1 = new EnemyEntity(randomPos);
> }
> }
Там внутри new EnemyEntity(randomPos) вот что происходит:
EnemyEntity(pos)
{
Position = pos;
Hp = 100;
EnemyView = Unity.ZapiliGameObjectVraga();
}
Когда мы убьем врага и удалим его из нашего массива мы сделаем
Unity.Destroy(entity.EnemyView);
> А еще ECS невменяемо отлаживать
Да, бывает не просто. Но не невозможно.
> на ECS невозможно написать нормальный гуй
Ну я б тоже не писал. А зачем, если можно на ООП заебись сделать?
> (поэтому ECS-шизики пишут эмуляцию отношений parent-child, лол)
Пишут, но не для гуя.
> и невозможно сделать сетевую игру с rollback.
Ты что?... ты... ку ку?
Ецс для этого и предназначен можно сказать. Это та задача, которую ебанешься делать без ецса
Это задача которая делается элементарно на оопе и через жопу на ецс.
Стреляем в игрока, он умирает, объект игрока деспавнится, пуля деспавнится, надо сделать откат, спавним пулю там где деспавнилась, игрока там где деспавнился, изи.
Что у нас в ецс? А, просто фарш разных компонентов. Как узнать что этот трансформ и этот меш относился к одному и их надо вернуть? Снова написав эмуляцию оопа, лол.
но в твоем коре нет менеджмента массивов для екс, и ты просто из тумбочки берешь уже подготовленный екс мир и делаешь пук() и среньк() лайк э босс
ты никогда не удалял ничего и никуда, всегда рендеришь все объекты в игре (ну или скипаешь, но всё равно продолжаешь итерироваться по ним), а когда пуля улетает у тебя в массивах остаются буллет компоненты которые никуда не деваются
> но в твоем коре нет менеджмента массивов для екс, и ты просто из тумбочки берешь уже подготовленный екс мир и делаешь пук() и среньк() лайк э босс
Цитирую то что я уже писал:
- Когда мы убьем врага и удалим его из нашего массива мы сделаем
Unity.Destroy(entity.EnemyView);
- А без ецс ты бы как эту задачу решил?
Вот надо заспавнить пулю, а у нас не ецс. Что мы делаем? Или уничтожить.
> всегда рендеришь все объекты в игре (ну или скипаешь, но всё равно продолжаешь итерироваться по ним)
БЛЯЯЯЯТЬ НУ ХВАТИТ
Я просто уже хуй знает сколько раз одно и то же повторяю, ты прост игноришь и через 1 пост спрашиваешь
- У тебя за кадром пули не летают? Наверное летают, просто не рендерятся.
> а когда пуля улетает у тебя в массивах остаются буллет компоненты которые никуда не деваются
Когда пуля будет уничтожена с точки зрения геймдизайна - тогда она будет удалена. Если пуля за кадром - с точки зрения геймдизайна она жива.
Когда врежется - тогда удалим.
Обсудим удаление объектов в целом? Напиши, как удаляешь без ецс объекты. Всё ещё жду.
>Когда врежется - тогда удалим.
то есть дропаем кэши и считаем заново. но ты вроде говорил, что этого не происходит? как так?
> там где деспавнилась, игрока там где деспавнился, изи.
Как мы понимаем где они задеспавнились? И кто именно? Что надо заспавнить по новой?
Как думаешь, что мешает сделать тоже самое на ецс?
> Что у нас в ецс? А, просто фарш разных компонентов. Как узнать что этот трансформ и этот меш относился к одному и их надо вернуть? Снова написав эмуляцию оопа, лол.
Бляяяяяяя
Связь сущностей - это простейшая задача. С ецс тебе ничто не мешает хранить те же данные, что ты и на ооп хуеп хранишь, только с этим в разы проще работать
> то есть дропаем кэши и считаем заново.
Какие кэши? У нас 2 массива.
> но ты вроде говорил, что этого не происходит? как так?
У нас кэшец никаких нет, поэтому ничего не чистим. Удаляем напрямую из массива.
Блин, наверное не самый удачный вариант да? А не подскажешь, как ты без ецс это делаешь? Наверное есть какие-то еще варианты простые это делать?
Это будет не ооп, а кривая симуляция ооп на тормознутом ецс.
мы не дропаем кэши, мы удаляем из массива. я тебя услышал и понял
Это не вопрос о реализации или симуляции ооп.
Это вопрос о том "какая информация нужна чтобы понять что мы должны зареспавнить по новой"
Ну так а ты расскажи, как ты на ооп делаешь.
Или не на ооп, а как то ещё. Наверное там есть какие то такие структры данных, чтобы операции удаления и создания были дешевле, да?)
дропаю кэши, что поделать. ооп же не екс, где кэши не дропаются и всего лишь происходит удаление из массива
В ооп я могу даже не деспавнить объект а поместить указатель на него в пул недавно удаленных, и скажем поставить булевый флажок внутри объекта что его сейчас не надо обрабатывать. При респавне просто добавить снова в массив обрабатываемых объектов и флажочек очистить.
Как примерно ты себе это на ецс представляешь? Для начала тебе нужно удалить каждый компонент объекта из каждого массива компонентов. Что может приводить к перестроению этих массивов. Или ты собираешься каждому компоненту заводить флажок или айдишник, чтобы разъебать этим кэш? Ну собственно как я и говорил ецс дрисня для геймдева не годится.
> В ооп я могу даже не деспавнить объект а поместить указатель на него в пул недавно удаленных, и скажем поставить булевый флажок внутри объекта что его сейчас не надо обрабатывать. При респавне просто добавить снова в массив обрабатываемых объектов и флажочек очистить.
О! Да!?
Нихуя себе!
Блин а что если... а что если мы в ецс тоже флажок сделаем?...
> Как примерно ты себе это на ецс представляешь? Для начала тебе нужно удалить каждый компонент объекта из каждого массива компонентов.
Я сейчас пил воду, и я поперхнулся. Ты ебанутый такое писать?
Я думал мы друг друга понимаем, а ты не понял даже ничего.
Помнишь мы про 2 массива говорили?
В одном враги были, в другом пули?
А ты не задумался, почему у нас компонентов много разных, а массива всего 2?
Смотри, простой фокус.
Давай посмотрим на первый массив, что там лежит внутри по порядку:
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
Дошло?
> Что может приводить к перестроению этих массивов. Или ты собираешься каждому компоненту заводить флажок или айдишник, чтобы разъебать этим кэш? Ну собственно как я и говорил ецс дрисня для геймдева не годится.
>>1019244
> дропаю кэши, что поделать. ооп же не екс, где кэши не дропаются и всего лишь происходит удаление из массива
Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
Потому что у тебя там либо реально ооп и все ебало в указателях, соответственно данные хранятся не линейно в памяти, и мы после этого сразу дружно с тобой ебашим бошками об стену с разбегу, а потом ебашим молотком по процессору за то что этот пидорас простаивает со своим бесполезным кешем и дохлым контроллером памяти который не вывозит такие фокусы.
Либо у тебя не ооп а какое умное решение с дата дривен дизайном и структуры данных ускоряющие эти операции. Я кстати неиронично думал что у тебя там этот вариант, но когда ты заговорил про ооп начал подозревать, что что-то тут не чисто.
Так это и не ецс, а хуйня какая то. У тебя тупо массив с ооп объектами.
Что?
Это ецс!
Есть ентити, есть компоненты, есть системы.
У нас в нашем с тобой примере даже 3 системы получалось, одна пули двигает, другая врагов, третья рендерит.
Можно даже сделать такую умную систему.
Смотри
Я пишу
foreach(var pos in Ref<Position>())
{
}
И цикл будет по 2 массивам по очереди. Т.е. по всем массивам у которых есть позишен. Автоматически.
Или пишу
foreach(var pos in Ref<Bullet>())
{
}
И цикл будет только по массиву пуль. Потому что только там такоц компонент есть.
Видишь, я даже так и быть сделал тебе апи для выборки компонентов по типам.
> массив с ооп объектами
Это что блять нахуй такое. Как можно ооп объект запихнуть в массив? Разве там не должен быть массив ссылок на ооп объекты?
Повторим: ецс - это архитектура. А не технические нюансы.
У тебя какая то хуерга которая хуже и ецс, и оопа.
Без технической составляющей нет смысла обсуждать перформанс, поскольку именно оттуда он и берется.
То что ты описывашь называется просто Structure of Arrays
https://en.wikipedia.org/wiki/AoS_and_SoA
В c++ это можно сделать бесплатно продолжая пользоваться мощью ооп https://github.com/crosetto/SoAvsAoS
И нет конечно массив может быть массивом объектов, не обязательно указателей. (только есть подозрение что в твоем коде указателей будет еще больше)
Твой код отличается от ецс тем, что ты не можешь делать некоторые энтити без компонентов. Смысл ецс в том что у тебя есть только один массив на компонент, чтобы можно было добавлять и убирать компоненты, например флаг "может летать", "может стрелять". У тебя же никакой экономии нет, потому что вхолостую будут перебираться все поля.
А от ооп отличается тем, что компилятор не сможет оптимизировать, например если у тебя системаА делает y += 5 и системаБ делает y -= gravity, то в ооп компилятор бы увидел что это относится к одному объекту и соптимизировал в y = y + 5 - gravity (что превращается в более быстрый машинный код с меньшим числом записей чтений).
> У тебя какая то хуерга которая хуже и ецс, и оопа.
Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
> Без технической составляющей нет смысла обсуждать перформанс, поскольку именно оттуда он и берется.
Блять, да тут не в конкретной технической составляющей дело.
У нас весь затык в удалении и добавлении каких то игровых сущностей.
Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Потому что в этом и кроется весь ответ.
Проблема работы с изменяемыми данными актуальна для чего угодно и там используются одни и те же решения, потому что она не характерна какой-то архитектуре, она характерна тому в каком виде хранятся твои данные.
Массив структур у тебя, структура массивов, линкед лист, хэш таблица, дерево, массив с кэширующим дерьмом, разбитый на чанки мир поверх любого из вариантов, любые - это всё работа с данными на низком уровне. Ты можешь любую ебалу наколдовать для своей архитектуры. Хоть ецс, хоть ооп, хоть вообще какая-то хуйня неведомая.
Ты не поверишь, есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы, зато это развязывает им руки в гибкости и скорости структурных изменений, потому что когда у тебя реф а не индекс в линейной области памяти никакие структурные изменения тебе уже не устроят говняк.
> То что ты описывашь называется просто Structure of Arrays
Это не архитектурное решение. Есть же грань между архитектурой и технической реализацйией?
Я могу стракчер оф аррейс сделать, могу аррей оф стракчерз, могу в хэш таблицу ебануть, могу массив бакетов и методы с вычислением хэшей(ой, что это...), это ваще не имеет никакого отношения что я всем эти колдовством реализовываю. Это всё чисто внутренняя техническая реализация нужного мне апи, а не архитектура. Архитектура - это конечное апи которое используется.
Ецс и ооп описывают требования конечному апи(какие в нем идеи должны лежать), а не то что там внутри что щаставляет его работать.
Если я в конечном коде пишу системы и ентити какие то и итерируюсь по типам ентитей - знач эт ецс.
> В c++ это можно сделать бесплатно продолжая пользоваться мощью ооп
Как, нормально понаследовался, отполиморыизмился, ощутил всю мощь ооп?
Давай засинкаем определния, ооп будем называть ооп, с наследованием, полиморфизмом.
Если у тебя иная организауия конечного геймплейного кода, которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
> И нет конечно массив может быть массивом объектов, не обязательно указателей. (только есть подозрение что в твоем коде указателей будет еще больше)
Если это массив "объектов" то в чем отличие структурных изменений от моего гига ецс фреймворка с 2 массивами?)
> например если у тебя системаА делает y += 5 и системаБ делает y -= gravity, то в ооп компилятор бы увидел что это относится к одному объекту и соптимизировал в y = y + 5 - gravity
Как компилятор может это увидеть в какой-то ситуации, в которой не увилит в системах?
Ну то есть смари, у тебя нечто делает у+= 5, нечто делает у-= гравити.
Эти инструкции в одном методе лежат? Или в разных? Как осуществляется туда заход, если в разных?
>Так давай, я жду с самого начала этой хуйни пример. Как ты хранишь какие то объекты, как их создаешь, как удаляешь?
да вот так и храню - враги, пули, всякие объекты
итерируюсь по ним, вызываю там апдейт. удаляю старое, добавляю новое
> да вот так и храню - враги, пули, всякие объекты
> удаляю старое, добавляю новое
А почему тогда мне так запретил? Вот, буквально ты говорил
> мы не дропаем кэши, мы удаляем из массива. я тебя услышал и понял
Ну и да, камон, я также в ецс делать могу.
>>1019217
> entityData1[] entities1 = new entityData1[100];
> итерируюсь по ним, вызываю там апдейт
Так и я так делаю!
Наверное ключевой вопрос - почему у меня ецс, а у тебя не ецс - а все дело в апи.
Нехитрыми манипуляциями, можно попилить код на компоненты и системы и сделать возможность выборки по типам компонентов, а под капотом будет тоже самое что и у тебя, просто апи доработано для соответствия ецс.
И еще раз повторим, что ецс это архитектурный паттерн.
вот и я не понимаю, зачем ты в екс делаешь то что делается без екс, и делаешь это так, что это противоречит философии и архитектуре екс.
в екс парадигме всё делается атомарными системами типа ЭнемиПукСистем, ЭнемиСренькСистем, где происходит выборка по разным группам компонентов. эти выборки нужно закэшировать, чтобы избежать повторяющихся итераций. это в норме приводит к куче массивов которые ссылаются на одно и то же - иначе екс тупо будет еле пердеть, итерируясь по миллионам сущностей сотни раз за кадр. то есть у тебя не два массива как ты написал, думая, что это так работает, а тысячи. в динамичной игре это приведет к постоянным дропам этих кэшей и замедлению производительности.
> где происходит выборка по разным группам компонентов. эти выборки нужно закэшировать
НЕЕЕЕТ Не нужно!
> приводит к куче массивов которые ссылаются на одно и то же - иначе екс тупо будет еле пердеть, итерируясь по миллионам сущностей сотни раз за кадр. то есть у тебя не два массива как ты написал, думая, что это так работает, а тысячи.
Не не не не
Смари, смари, это гениально и просто. Ты не понял прикола.
У нас есть ентити с position, bullet, graphics - типа пульки летающие
Есть ентити с position, health, enemy, graphics - типа враги бегающие
Есть ентити с position, health, player, graphics - типа игрок
Теперь представь, мы сделали так:
Когда мы создаем пулю с этими 3 компонентами - под неё автоматически создасться массив если его нет, и в конец вставится пуля.
Когда создали врага - под врагов автоматически создаться массив ив конец положится враг.
Аналогично с игроками.
То есть чем больше вариантов наборов компонентов - тем больше массив.
Создадим какой то player bullet position graphics - что ж, под это создасться 4 массив.
Тут думаю вопросов нет.
А тепепь у нас все таки ецс, мы хотим сделать цикл по всем ентитям у которвх есть позиция и сделать гравитауию.
В клиентском коде мы берем и пишем:
foreach(var position in RefRW<Position>())
{
position.RefRW.y -= 10;
}
И вот эта вот запись обозначает то, что мы делаем цикл по всем нашим 3 массивам.
Теперь хотим пули подвинуть вперед
Берем и:
foreach(var (position, bullet) in RefRW<Position>, RefRW<Bullet>())
{
position.RefRW += bullet.speed;
}
И оно пройдется только по 1 массиву с пулями.
Важные моментв:
1. Нам ничего не нужно апдейтить, кешировать каждый кадр, у нас есть эти 3 массива - каждый содержит уникальные данные. Всё, больше ничего не нужно
То есть это эквивалент твоих
bullet[] bullets
enemy[] enemies
player[] players
2. На этапе компиляции мы знаем какие массивы нам нужны для каждой выборки. В рантайме нам ничего вычислять и определять не нужно.
Скажкм, смотрим исходники, видим - ага (буллет, позишен) будет индекс 1, (позишен) индекс 2, там где у нас цикл по позишен будет цикл по массивы[2], а там где цикл по (пощишен, буллет) будет цикл по массивы[1]. Ток офысеты там надо прибавить к адресам чтобы получить смещение для компонента.
Опять же - кодогенерацией это очень легко достижимо.
Получается, что под капотом там ровно тоже самое что и у тебя.
Всё что отличается - конечное апи - у тебя напрямую массивы и явно заведенные типы, тут такие конструкты из набора "компонентов" и возможность итерировать по выборке такиз компонентов.
По факту это уже квалифицируется как ецс, потому что есть компоненты, есть системы, есть ентити.
Ну и где проблемы с производительностью?
Ну а если мы говорим про дотс, то там ещё интереснее, там данные не просто в массивах лежат, а разбиты на чанки фиксированных размеров, и там системы выполняются в автоматическом режиме, подстраиваясь под чтение и запись других систем с заданными ограничениями порядка, в итоге получается так, что у тебя и каждая система по отдельности может работать в многопотоке, оьрабатывая сразу несколько ентитей сразу, и несколько систем сразу могут работать олнвоременно, если они друг друга не блокируют, и вот это уже сила.
Это в юнитивском ецс в дотсе
https://docs.unity3d.com/Packages/[email protected]/manual/concepts-archetypes.html
https://docs.unity3d.com/Packages/[email protected]/manual/concepts-structural-changes.html
Всратый кал, непригодный к использованию в игровых движках. Ты поли каунт видишь, или тебе это ни о чем не говорит?
Чтобы это можно было использовать, придется заново сделать лоуполи руками.
Это можно использовать максимум в качестве рефа, который можно покрутить, по которому ты потом будешь с нуля делать нормальную модель.
>Ецс - это арзитектура в которой есть ентити, компоненты и системы. В системах можно итерировать по разным наборам компонентов. Тут всё это есть.
Нет, у тебя нет независимых компонентов.
Ты же сам пишешь что у тебя фиксировано
[позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
А значит ты не можешь сделать
[позиция][пуля][меш][флажок][позиция][меш][флажок][позиция][пуля][щит][меш]
По сути у тебя есть только объекты с 4 полями.
>Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
>есть даже ецс фреймворки, которые юзают референсы и хуй забивают на локальность данных. Цена - скорость итерации и кэш миссы
Ну так ты сам себя и разъебываешь - ты то писал что у тебя перформанс именно благодаря ецс архитектуре. А тут сам признаешься что это не свойство архитектуры.
>у тебя нечто делает у+= 5, нечто делает у-= гравити. Эти инструкции в одном методе лежат? Или в разных?
Компилятор знает что это один объект, поэтому и оптимизирует.
Когда ты итерируешь по компонентам, компилятор никак не сможет узнать, что в рантайме на этом кадре 5-й компонент в одном массиве это тот же игровой объект что 7-й компонент во втором.
>которач не подращумвеает наследование и полиморфизм, то будем смотреть что там и как.
Эквилибристика, типа игнорируешь что у тебя не екц, но если я не пользуюсь наследованием то у меня не ооп. Нет, у меня ооп потому что есть объект, который группирует поля данных и методы.
МОгу подытожить - прирост производительности в ецс ты бы увидел только на 10000+ однотипных объектах делающих однотипное действие. Типа солдатики в стратегии маршируют одинаково. Если ты тот анон который говорил про 16 или 32 игровых персонажа в кадре - ты никакого прироста от ецс (который у тебя и не ецс, на самом деле, а вариант оопа в котором ты возможно даже мешаешь компилятору оптимизировать) - просто никак получить не сможешь.
ECS итерирует не по энтити, а по компонентам, вот где твое заблуждение.
Производительность у тебя теряется в нескольких местах:
1. Если бы ты итерировал по компонентам, то в кэш влезало бы в 4 раза больше игровых объектов. А так у тебя через кэш каждый раз протискивается весь объект.
2. Если ты будешь испольовать ецс как настоящий ецс, а не как эрзац-пародию, то ты будешь добавлять-удалять компоненты энтитям динамически, (ну например хотим сделать юнит неуязвимым- удаляем компонент health) а значит тебе придется перетасовывать массивы, ведь объект придется удалить из массива номер 3 и перенести в массив номер 4.
тебе надо было просто сразу сказать что у тебя говнюнити, мы бы на тебя просто время не тратили, потому что все знают что там не ецс, а пародия.
> Ты же сам пишешь что у тебя фиксировано
> [позиция][пуля][меш][флажок][позиция][пуля][меш][флажок]
> А значит ты не можешь сделать
> [позиция][пуля][меш][флажок][позиция][меш][флажок][позиция][пуля][щит][меш]
> По сути у тебя есть только объекты с 4 полями.
Могу. Добавляю новый массив, под капотом. Тут все описано. Заебало одно и тоже пересказывать >>1019255
> Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
Ну так может написал бы тогда сейчас вместо этого ответа "ыыы ты меня не спрашивал"? Спрашиваю сейчас, че.
> Компилятор знает что это один объект, поэтому и оптимизирует.
Давай пример псевдокода. Мне кажется оно у тебя там нихуя не соптимизирует и у тебя слишком далекая связь чтобы компилятор мог это вывести.
Если у тебя последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
> Когда ты итерируешь по компонентам, компилятор никак не сможет узнать, что в рантайме на этом кадре 5-й компонент в одном массиве это тот же игровой объект что 7-й компонент во втором.
В десятый раз повторяю, объекты и все их данные существуют в единственной копии.
> Эквилибристика, типа игнорируешь что у тебя не екц
Вот тебе например определение ецс
https://en.m.wikipedia.org/wiki/Entity_component_system
Покажи противоречия
> но если я не пользуюсь наследованием то у меня не ооп
> Нет, у меня ооп потому что есть объект, который группирует поля данных и методы.
Ооп традиционно называют вот что
https://en.m.wikipedia.org/wiki/Object-oriented_programming
Покажи где у тебя есть наследование и полиморфизм которые являются ключевой идеей ооп
И да, в этом проблемы нет, ооп там, ецс, просто есть довольно конкретные определения общепринятые и я писал в их терминологии. Ты начал говорить, что у меня не та терминология, а не я, хотя как выяснилось как раз твои определения не соответствуют общепринятым.
> МОгу подытожить - прирост производительности в ецс ты бы увидел только на 10000+ однотипных объектах делающих однотипное действие. Типа солдатики в стратегии маршируют одинаково. Если ты тот анон который говорил про 16 или 32 игровых персонажа в кадре - ты никакого прироста от ецс (который у тебя и не ецс, на самом деле, а вариант оопа в котором ты возможно даже мешаешь компилятору оптимизировать) - просто никак получить не сможешь.
Ецс - это архитектурный паттерн.
Исходный тезис был в том, что он плохо ложится на производительность и есть много издержек лишних.
Мой ответ в том, что нет, ецс можно совершенно разными способами внутри реализовать, в том числе точно такими же как ты сделал бы это без ецс, и как таковых заведомых проблем с производительностью ецс архитектура не несёт.
Говоря о практике, есть ецс фреймворки с которыми можно сравнительно легко достичь очень большой производительности, засчет распараллеливания итераций по большому числу ентитей, распараллеливанию систем(несколько неблокирующих будут работать одновременно). Каких-то других общих практик достичь такого - нету. Только долгое изобретение своего кастомного варианта под кокнретную игру, с поиском всех вариантов как это соптимищировать.
Помимо этого я выше заявлял:
1. Использование ецс в готовом движке не несёт лишнего заведомого оверхеда, у тебя полныц контроль с точки зрения программирования что ты делаешь
2. Связь любых двух систем делается схожими методами, как ецс можео подружить со сторонним физическим движком, так и любую игру можео подружить со сторонним физическим движком
3. Ецс не обязательно предполагает какие-то обязательные расчёты каждый кадр, есть реализации ецс с 0 оверхедом в кадре
4. Нет никакого лишнего оверхеда для куллинга и повторного выполненич той же работы
На это как таковых ответов не вижу, можешь линкануть или написать, если не согласен.
>>1019330
> ECS итерирует не по энтити, а по компонентам, вот где твое заблуждение.
Что это предложение значит?
Концепция ецс предполагает в клиентском коде возможность итераций по заданному набору компонентов. У меня это реализовано.
> Производительность у тебя теряется в нескольких местах:
> 1. Если бы ты итерировал по компонентам, то в кэш влезало бы в 4 раза больше игровых объектов. А так у тебя через кэш каждый раз протискивается весь объект.
Действительно, есть такое. А ты уверен, что это даст больший проигрыш, чем нарушение предикта процессором засчет бранчинга и большего набора инструкций и разнородности ввполнчемых операций?
Я - нет.
Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
> 2. Если ты будешь испольовать ецс как настоящий ецс, а не как эрзац-пародию, то ты будешь добавлять-удалять компоненты энтитям динамически, (ну например хотим сделать юнит неуязвимым- удаляем компонент health) а значит тебе придется перетасовывать массивы, ведь объект придется удалить из массива номер 3 и перенести в массив номер 4.
И в ооооочередной раз прошу тебя рассказать, как бы ты решал схожую проблему без ецс.
(С ецс те же самые практики применимы, а также и некоторые другие)
> тебе надо было просто сразу сказать что у тебя говнюнити, мы бы на тебя просто время не тратили, потому что все знают что там не ецс, а пародия.
Поебать что за движок, выше я также уже много раз говорил, что у тебя есть ЯП чтобы реализовать что угодно в чем угодно.
А что по юнити - там как раз самый трушный ецс какой можно себе представить(следуя твоему же определению, я же до сих пор твержу, что ецс это архитектурный паттерн а не твои маня фантазии о внутреннем устройстве) с наверное самым большим перформансом на рынке.
> >Ты на отрез отказываешься говорить как бы сделал это без ецс, хотя я тебя в каждом посте прошу это сделать.
> Лично меня ты не спрашивал, с тобой тут не один анон спорит. В ооп для этого есть композиция.
Это типа ты ответил? Как композиция решает проблему добавления или удаления игровой сущеости?
Чел, это не ецс, и тем более не трушный ецс и тем более не самый производительный - самый есть только на с++ и расте, куча либ.
Еще раз повторяю, у самой по себе архитектуры ецс прироста перформанса нет, хз откуда ты это выдумал. Она может быть только у реализации, а у тебя реализация медленнее и тру ецс, и ооп с оптимизацией через SoA. (Но правда в том что на реальных данных ецс и сам превратится в тыкву) Возьми напиши бенчи и померяй, а так ты просто маркетологовые мантры повторяешь.
> Каких-то других общих практик достичь такого - нету.
ООП с SoA.
>Ещё и есть непонятки с многопотоком, потому что отделение операций на простве и взаимонеблокирующие позволчет многое параллелить, в отличии от твоего нагромождения логики в одном месте, что в любом случае будет блокировать выполнение логики в другом местк пока этот объект не обработается.
У тебя ровно такое же нагромождение, так как у тебя не ецс, а массив объектов.
>последовательно идут вызовы monster.ApplyGravity(), monster.Move() то так можно вывести, но ты также можешь сделать в ецс.
Нет, в ецс ты так сделать не можешь, там будет только два последовательных цикла по несвязанным (с точки зрения компилятора) между собой компонентам.
> Чел, это не ецс, и тем более не трушный ецс
Определение ецс я тебе скидывал. Противоречий ему ты не привёл.
Что такое трушный ецс я вообще не знаю.
>тем более не самый производительный - самый есть только на с++ и расте, куча либ.
А мы о чем говорим? О моем псевдокоде которым я имитировал твой "ооп" и подсвеичаал идентичность проблем и внутреннего устройства, или о юнити ецс?
Если о втором - а ты сравнивал производительность юнити ецс с беви или еще какими-то реализациями?
> Еще раз повторяю, у самой по себе архитектуры ецс прироста перформанса нет
А я говорил это где то? Процитируй плиз.
Я говорил что у ецс нету заложенных ее дизайне решений которые убивают производительность.
А также в свою очередь есть варианты реализации ецс с которыми можно достичь очень большой производительности, по сравнению со многими другими подходами.
> хз откуда ты это выдумал
Не знаю, с чего ты взял это. Я из раза в раз твержу что это архитектура, а не внутренняя реализация.
> Она может быть только у реализации, а у тебя реализация медленнее и тру ецс
Какая именно? Моя ебала с тремя массивами? Как ты понял что медленнее?
> и ооп с оптимизацией через SoA
Так выше ты сам уже говорил, что можно компоненты хранить в массивах.
Крч, твой "ооп" это вырожденный "ецс", где 1 компонент = 1 тип объекта, с абсолютно идентичной внутренней реализаций, 1 в 1.
Давай ещё раз просто зафиксируем, чтобы это точно бвл не не твой ответ и мы понимали кто о чем говорит:
1. Напиши как у тебя хранятся игровые сущности. Массив структур? Структура массивов?
2. Как происходит удаление и создание сущности
Вот у нас есть например пуля летающая и враги бегающие. Напиши пример для них.
А я тебе напишу апи которое будет соответстчовать определению ецс и работать с твоей реализацией)
>. (Но правда в том что на реальных данных ецс и сам превратится в тыкву) Возьми напиши бенчи и померяй, а так ты просто маркетологовые мантры повторяешь.
Я хз как тебе еще сказать, что внутри там может быть ровно тоже самое что и у тебя.
Вот абсолютно любую структуру данных напиши, я тебе заебашу апи и скажу какой кодогенератор надо сделать чтобы оно выглядело в соответствии с определением ецс.
> ООП с SoA.
Давай сделаю тебе ецс где внутри будет СоА)
Напиши пример с пульками и врагами. Давай.
> У тебя ровно такое же нагромождение, так как у тебя не ецс, а массив объектов.
Подожди подожди, как это так?
Я могу сделать систему, которая для каждого "ентити" делает позишен += гравити и это распараллелится.
Могу пойти дальше, и сделать систему, которая будет отнимать хп от горения юнитов или отравления. И она будет работать параллельно с предыдущей системой, потому что они не блокируют друг друга.
А дальше будет система проверки коллизий - вот она уже дождется когда все позишены подвинутся от гравитации и отработает.
У тебя как это реализовано бы было?
Если у тебя все в одном методе или потенциальео оптимизируемо в 1 метод, то и не будет у тебя никакого многопотока.
Пример очевидео примитивный, на пратике у нас параллельно каждый юнит может считать пути и принимать решения, и это все будет параллельно работать с полетом пуль и параллельно например с системой горения травы какой нибудь. Или с десчток мелких систем паралелльно крутиться будут каждая в своем потоке.
> Нет, в ецс ты так сделать не можешь, там будет только два последовательных цикла по несвязанным (с точки зрения компилятора) между собой компонентам.
Если что-то оптимизируемо в 1 метод автоматически, то это можно вручную оптимизировать также в 1 метод в системе, вот про что я.
Не точно, вроде уже сеньор.
По моему композиция это термин из ООП обозначающий вид отношения между двумя сущностями. Операции удаления и вставки с технической точки зрения оно не задаёт.
А нам тут нужна структура данных с операциями вставки и удаления.
>Сейчас курьер 120+ получает
Дык это нищета полная сейчас, поэтому он их и получает. Это те же 60к 3 года назад, инфляция всё съела.
Вы ещё в копейках считайте тогда, если вам главное чтобы цифра побольше была. Какие же вы нахуй гои ЛОЛ.
так дело не в цифрах, а в покупательной способности
у рубля она одна из лучших в мире>>1019438
>Это те же 60к 3 года назад, инфляция всё съела.
годовая инфляция 10%, не неси херни
доходы населения растут быстрее инфляции, а это главное
>Лучшая в мире покупательная способность.
Дай угадаю, твой любимый движок - годот?
Поздно. Уволен в годоти. Такую хуйню спиздануть только годотя мог.
по всем мировым методикам экономика России в 2025 году на четвёртом месте по ППС, тут не отвертишься
> по всем мировым методикам экономика России в 2025 году на четвёртом месте по ППС, тут не отвертишься
Это абсолютное значение, а надо смотреть на душу населения.
ППС тоже не такой просто показатель, он показывает цену на какую-то продуктовую корзину и некоторый набор товаров. Но какие конкретно товары(булка из подвала или свежевыпченная из муки высшего сорта?) и насколько это реальные цены - это вопрос.
Еда и товары первой необходимости это в любом слусае не первая статья расходов, на технику больше потратишь, а она по ППС не считается.
>>1019440
> так дело не в цифрах, а в покупательной способности
> у рубля она одна из лучших в мире
Это тоже очень тупое заявление. Может, ты просто неправильно выразился. У валюты нет покупательной способности, это не её характеристика.
> Это абсолютное значение, а надо смотреть на душу населения.
И не только это, но еще и расслоение дозодов по регионам и социальным группам может сильно сбивать с толку.
Зарплата средяя наверное 100к все будет, а медиана то всего 50к.
какие-то гнилые отмазки, по сути я прав а ты завистливый нищук соевая обрыга
Тебе ссылочку на росстат прислать?
Сравнивать абсолютный размер экономики это очевидный идиотизм, в индии экономика еще больше чем в расиюшке, только там в 10 раз больше человек живут. Поехал бы в индию?
https://habr.com/ru/articles/905544/
>Миграция
вот что бывает, когда дебильные анальники начинают делать игру
мимо пишу на unity 2
Как там в 2015?
Жаваскрипт динамически типизированный и намного менее развитый в плане удобства работы с ООП, поэтому реальную игру на нем крайне тяжело писать будет.
Ну и производительность тоже у него сомнительная.
https://assetstore.unity.com/packages/vfx/tentacles-vfx-urp-303497
Это школьный курс геометрии, любой GODотер напишет генератор подобной хуйни за пару часов.
-Раздался голос юнитичма из под шконки, но годотобоги и анрилобоги его не расслышали и продолжили обоссывать.
>годотобоги и анрилобоги
вы наблюдаете как конченый омеган пытается примазаться к ребятам покруче
>годотобоги
Увы, так называемые "гуньдотбоги", находятся в самом низу движковой цепочки. Соответственно - они "боги" только в рамках так назваемого своего свинарника.
Даже хрюни выше находятся.
Сделай свой или phaser тот же. Вообще без редактора это ад.
Так анрил и годот - братушки, эпики подкидывают денюжку, программисты контрибьютят в исходники.
Годот. Там есть режим где просто пишешь код, рисуешь все что хочешь кодом, без всяких сцен и нод.
>>1019662
Появилось что-то у меня настроение поебаться с SDL3 недельку другую...
А phaser и годот слишком просто - я что сюда реально игры пришел делать? Я хочу ебаться с кодом, а не заниматься продуктивностью.
Братушки только потому, что свинья сначала спиздила люмен из другого движка, попутно поглядывая на годотный SDFGI. Чёт там мутное было такое.
Так что не всё так хорошо для годотей как им хотелось бы.
Ezengine, там редактор есть, но опциональный, можно использовать code first подход
Либо Israel Engine, либо свой. Либо какой-то из тех где есть C++ и можно переделать под себя по исходникам.
>Либо какой-то из тех где есть C++
для начала покажи все свои проекты, аккаунты, игры и т.д, перед тем как свою вафельницу открывать
Любой кроме годота.
На юнити есть дотс для такого, на анриле можешь модуль на плюсах написать, на беви даже можно сделать с его параллельным ексом.
Только годот не вывезет, там на каждые два драв колла по пропуку
Любой, где есть векторизация и многопоточность. Любой движок с с++ или юнити с джоб систем и берст.
>>1019691
>>1019692
>>1019710
>>1019711
Остановил выбор на анриле, спасибо. Я прогуглил и вроде сходится с тем что вы пишете. Юнити идёт твёрдым вторым местом, а в годоте пишут что можно работать с С++, но там якобы проблемы с этим, я не до конца понял почему, но ладно.
>мне требуется движок который сможет осилить огромное количество векторной математики в один кадр
так тебе наверное GPGPU нужон, а не движок (вернее движок пойдет любой, лишь бы был доступ к GPGPU)
вот для анрила сетап
https://dev.epicgames.com/community/learning/tutorials/WkwJ/unreal-engine-simple-compute-shader-with-cpu-readback
>>1019732
На текущей стадии это оверкилл я думаю, посмотрю в эту сторону если упрусь в стену с ЦПУ, но хоть математики и будет много, я думаю не настолько.
Пиздаболище. В годоте есть компьют шейдеры, и есть MultiMesh Instance.
Значит фиксить проблемы старые не будут. И оптимизацию опенворлда тоже делать не будут.
Увы.
Зачем тебе опенворлд, клоун? У тебя 300 артистов сидит на зарплате? Ты не потянешь.
Удел инди делать маленькие камерные игры.
>Зачем тебе опенворлд, клоун? У тебя 300 артистов сидит на зарплате?
Не хрюкай.
https://github.com/VahidSN/CrowdEvade
Photorealistic ray-traced micro-voxel fps engine https://github.com/milgra/qubatron
Какие воксели в 21 веке, чел, все состоит из волн, тут подкрадывается гауссиан сплаттинг+ ИИ
https://www.youtube.com/watch?v=hUVfAVjsfL4
как нет, когда да? что хорошего было сделано с припиской ИИ?
Текстовые модели типа чат гпт
Генерация изображений текст ту имедж
Текст ту спич
Нейрофильтры для изображений и видео(апскейл, цветокоррекция, следование до точкой)
Апскейл DLSS/FSR
пропуки добили чела
https://www.reddit.com/r/godot/comments/1kdp57g/my_first_steam_release_after_55_years_of_gamedev/
>Текстовые модели типа чат гпт
ок, это годнота. в немалой степени из-за шиттификации поисковиков - раньше просто гораздо больше полезной информации извлекалось через поиск
>Генерация изображений текст ту имедж
>Текст ту спич
давай по чесноку. это всё еще генерирует хуйню. до сих пор
> Нейрофильтры для изображений и видео(апскейл, цветокоррекция, следование за точкой)
вообще не знаю о чем речь
>Апскейл DLSS/FSR
ок, но литералли технологии 20 летней давности (madVR).
Очевидно шкилл ишью, раз чел взял 4-ку вместо тройки, не знает как пропукивать шейдеры, не удивлюсь если у него там трава без оптимизаций по одной травинке рисуется. Еще о многом говорит что он заявляет 5 летний опыт, при этом его "фиксы" после релиза - судорожно переключать один рендер на другой? Потестить заранее не? Потренироваться на каком нибудь джеме релизить игру не? В конце концов, ну не разбираешься - пойди в W4 за платной консультацией, где то же на сайте годота написано что такая опция всегда есть.
> давай по чесноку. это всё еще генерирует хуйню. до сих пор
Ну смотря для каких целей.
Текст ту имедж норм чтобы каких то рефов нагенерить, даже не полноценных концептов, а просто ориентиров для этапа препродакшена чтобы у всех видение более. До ии это были просто скринв из других игр, теперь к ним добавились(не заместили, что важно) картинки из ии.
Еще норм для коммунити менеджеров всяких и генерации изображений с малой ценностью. Вот у нас например юзают для для объявлений в компании, просто чтобы чуть более живо выглядело чем просто текст. Вот для таких мелочей, где хорошо бы картинку вставить, но не искать кринж в гугле.
> вообще не знаю о чем речь
Это надо у видемонтажеров поспрашивать и тех кто изображения обрабатывает. Точно знаю что есть то что я перечислил, но там вроде много всяких нейроинструментов облегчающих жизнь. Удаление фона вот ещё.
> ок, но литералли технологии 20 летней давности (madVR).
Расскажешь подробнее? Судя по гуглу это это что-то связанное с декодированием и рантайм обработкой видео.
Не уврен, что оно позволяет получить такой же по качеству эффект как длсс/фср и применимо в реалтайм играх. Апскейл до ии в целом очень слабый был даже для изображений, я гуглил варианты еще незадолго до ии бума.
по поводу концептов и картинок в блоги согласен. я скорее говорил об ассетах и собственно энд-юзер контенте
>Расскажешь подробнее?
20 лет назад один гик обучил апскейлер для видеоплееров, который благодаря видяхе работал в полу-реалтайме на видео (всё равно нужна буфферизация и заглядывание в будущие кадры). картинка была чуть лучше чем при апскейле обычными интерполяторами типа бикубика и ланцоша, четче контуры в аниме, детальней лица. в принципе то же самое что делает длсс сегодня в играх
он шиз, у него охуенно мало рефандов (норма 15-20%). краши и тормоза люди указывают просто потому что думают, что нужно указать серьезную причину, а то вдруг габен зажмет деньги и не рефанднет, если они честно скажут, что им жалко денег за такой геймплей
он уже как минимум 1000$ нафармил и продолжает фармить, а ты сидишь тут и терпишь
Я тоже хотел запостить потролить говнотей, но потом прочёл что у него 11% рефандов и чёт пукнул с него. Для индихуйни это пиздатый показатель.
Получается, неплохая реклама Годоту.
Чел сделал неплохую 3д игру за 3 месяца. При этом параллельно разрабатывая еще одну более крупную.
Малаца, приноси еще таких успешных историй.
(На пропуки игрокам похер, непохер только шизикам в движкосрач треде)
Сто раз говорили, если планируете выпускать игру в стим - берите юнити/анрил, точка. Не за их фичи, не за крутой рендер - это все вторично. В первую очередь за мощную базу совместимости, гарантию того, что на любом железе ваша игра будет работать плюс минус одинаково ожидаемо. Они эту базу совместимости копили десятилетия, вплоть до наличия в коде фиксов под конкретные версии дров конкретных видюх.
В гадотя энжине этого нет и не будет. Не удивляйтесь, если у рандомной части игроков будут инвертированные цвета или тупо краши.
В вашем самописном бздотя энжине ситуация будет еще в разы хуже, чем в годоте, просто будет 80% рефандов из-за крашей, а не 10.
Определитесь сразу, вы хотите пукать или делать игры и издавать их. Если хотите пукать - Пожалуйста, годотя, бевя, викед, хуикед, все к вашим услугам, можете хоть с нуля писать на сдл, подрачивая при этом вприсядку.
Но если хотите выпускать игры - только Юнити и анрил.
Забавно, что в тред пришел разраб halls of torment и сказал, что у него на говноти траблы на rtx видюхах.
Просто загуглите скрины игры, чтобы понимать абсурд ситуации (там графин хуже чем в первом Диабло)
Не это ли вершина идиократии, когда на видюхе за шестизначные деньги не работает игра с графикой хуже, чем делали в девяностых?
Чтобы такое случилось, достаточно просто выбрать говнот в качестве движка
>>1020307
Так и есть, скил ишью это когда ты из-за отсутствия скилла решаешь, что инвестировать время в говнот это хорошая идея
>траблы на rtx видюхах.
это хуанг последние дрова сломал
гугли
какие-то ебанутые одебилившие от бесконечного потребления соевики, нахуя вы драйвера обновляете? я 1 раз при установке винды скачивают самые последние и когда винда сама решает примерно раз в год - никогда никаких проблем не было
Маняфантазии веруна в маркетинговые мурзилки швятой говнюнити, которая на деле обычный глюкодром, виснущий на любом железе.
Нейронки тоже глючат на последних видяхах, а на ранних нет. Да и со свежими ААА играми такое пишут. Что, ААА играм тоже годот мешает?
Годот просто говно. А инвестиции времени/денег в него - инвестиции в говно.
Лучше бы эпики крайтекам которые банкроты занесли на допил своего движка, а не хуяну.
Т.к эти хотя-бы в прошлом были ебейшими разрабами движков, а Хуян - просто дегенерат какой-то.
Гляди и годоти были бы не годоти - а срунишки, которые умнее юнити и анрильщиков вместе взятых.
сначала доделаю несколько проектов для стима и возможно когда-нибудь, если начну делать нормальную игру, то попробую, может повезёт
>если они честно скажут, что им жалко денег за такой геймплей
бля, а я как дурак всегда писал, что игра не понравилась и всё
люди думают кто-то читает что они пишут
ну на саппорт они могли нанять миллион индийский или пакистанских мартышек, но да, скорее всего они чисто для статистики дают выбирать причины
а зная, как вообще в Вольво работают, то даже на эту самую статистику им похуй
Пару лет назад вскрылась темка, что сотрудники сапорта стима могли получать доступы к аккаунтам. Они находили заброшенные аккаунты со скинами и выводили их.
Так вот эти сотрудники были из левых контор. Вэлв подрядчиков нанимает. Когда это вскрылось они саппорту из левых контор функционал урезали.
И чего? Уже сто раз разбирали что это проблема захвата видео.
нет, ни разу не разбирали
https://www.youtube.com/@18coins63/videos
это проблема годота
Лолблять этот сраный волк заебал уже, я не говнотя и не юнипитек, но постить видос 5-летней давности это уже ни в какие ворота.
>>1020740
Ну вот тебе свежее видео, 4-месячной давности, на годоте 4.
Почему в Хоппе такой проблемы не было тогда? Там сто врагов летает.
Ну и? Сотня мешей врагов + ГГ + колесо + домики, то есть объектов больше чем на видео с волком, а проблем нет, почему так?
Это пиздец. хахахахах
годотям такое не снилось, чтобы книжки бесплатные, максимум документацию сделают нищую, которая устаревает в моменте выхода, а всё остальное на этом нищем движке вообще платное делают, потому что на играх не заработать, приходится курсы продавать
юнитям и не снилось, чтобы исходники были бесплатные, и как что работает можно сразу посмотреть и самому дописать все что хочешь. и тысячи бесплатных ассетов с исходным кодом, бери пользуйся. и тысячи бесплатных видео на ютубе. но юнитя мерит какими то своими категориями, если не склонировали что то с юнити то плоха.
>как что работает можно сразу посмотреть и самому дописать все что хочешь
больные фантазии долбоёба
> тысячи бесплатных видео на ютубе
реально хочешь сравниить количество туториалов на ютубе у юнети и годити?
>тысячи бесплатных ассетов с исходным кодом
у юнети бесплатных ассетов столько, сколько у годоти не будет никогда
> самому дописать все что хочешь
эта хуйня нужна только студиям, которые сталкиваются с какими-то ограничениями в специфических своих задачах, нужна буквальна единицам, миллионам других разработчиков открытые кишки не нужны
>реально хочешь сравниить количество туториалов на ютубе у юнети и годити?
похуй у хрюнити просто тонна мусорных туториалов записанных ради просмотров. хороших будет сравнимый порядок
>у юнети бесплатных ассетов столько, сколько у годоти не будет никогда
тем более нет смысла париться по такому вопросу. главное что на основные системы есть.
>не нужно
понятно как в юнете чего то не нашлось сразу началось ненужно.
>похуй у хрюнити просто тонна мусорных туториалов записанных ради просмотров. хороших будет сравнимый порядок
но ведь твой первый аргумент был про количество, а качество уже другой вопрос(тут кстати годотя тоже не блещет)
>тем более нет смысла париться по такому вопросу. главное что на основные системы есть.
не нужно, понял тебя
>понятно как в юнете чего то не нашлось сразу началось ненужно.
ну это реально нужно только единицам, и то половина из них покупает платную поддержку у создателей, чтобы те сделали так, как надо
хз, я уверен что у меня на пару квартир больше чем у тебя, небомж
>>1020950
да наверное высрался против нашей великой Победы, не выдержал батхёрта от просмотра парада
вряд ли. до этого он ни в чем подобном замечен не был
в последний раз окукливался когда его захуесосили, когда он покрывал своих вокот-соевичков из дискорда
https://github.com/godlikepanos/anki-3d-engine
>когда он покрывал своих вокот-соевичков из дискорда
Кстати, да, было такое. Тогда его движок потерял часть преданных фанатов.
Аноны, а как вы живёте в этой ecs хуйне если простой советский выстрел и попадание происходит следующим путем
Инпутвент OnPlayerShoot()->playerentity.addcomponent<shootdata>()->итерация системы shootdata->createentityBullet()->итерация системы bullet()->targetentity.addcomponent<hitcomponent>()->итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
И кстати, чё по многопотоку? Как отследить что компонент только появился, либо только что был удалён? Насколько тяжело жить без возможности иметь 2 компонента одного типа на одной сущности?
Вот этот начинает понимать почему сказки про ецс это сказки.
"Вы просто не умеете её правильно готовить"©
На самом деле я прошел все стадии решения этих проблем и понял что оригинальный "pure" ecs потому и является таким обоссаным говном, потому я написал свой собственный велосипед на полностью многопоточной основе(а щас под полную асинхронщину рефакторю), с компонентом, решающим проблему мультикомпонентности 1 типа, с designed by contracts системами(контрактами), где блокировки на чтение обеспечивают фиксацию наличия или отсутствия определенных компонентов на время выполнения контракта(кода системы) у объектов контракта (сущностей) на основе readwritelockslim, что в итоге позволяет мне городить очень хитрый огород с системами, которые могут обрабатывать не каждый отдельный компонент сущности, а коллекции сущностей в целом. Разве что у меня нет возможности делать компоненты-структуры, потому что придется дублировать код раз, проблемы с сериализацией - два. Но мне сам архитектурный подход ecs нравится, потому я срезал его углы и смирился с недостатками полученного результата. Отлаживать как и любую другую многопоточку трудно, но обычно, если все дробить на контракты - проблем не возникает. Но это и не ecs уже совсем))
>сказки про ецс это сказки
Ну, например Овердроч полностью на екс построен
https://www.youtube.com/watch?v=W3aieHjyNvw
https://www.youtube.com/watch?v=odSBJ49rzDo
А ты овердроч делаешь? Или у тебя есть косарь сотрудников которые могут копошиться во всех этих последовательностях хитросплетений операций над компонентами? У меня кстати перед лицом есть пример такого проекта как TankiX, который авторы ещё до появления dots написали на полностью ecs основе, все от ui до физики было написано на ecs в юнити, и который закрылся ещё имея 2-3к игроков знаешь почему? Потому что его было нереально поддерживать не в убыток даже при таком уровне донатящего онлайна. И впоследствии авторы отказались от ecs парадигмы в рамках своих оставшихся проектов. С dots ситуация конечно улучшилась, хотя бы не нужно тратить бабло на поддержку самого фреймворка, но его болячки раздувающие кодовую базу никуда не делись.
а зачем эти шизики всё делали на екс? с какой целью? ради мифических пико секунд в скорости? вот ещё один хороший пример, какой-то ёбнутый анальник нахуевертил хуеты, исполнил свои влажные мечты и убил этим проект, потому что никто другой не смог разобраться в его дерьме
>А ты овердроч делаешь?
Нет. Но я делаю сетевую игру. Уже вторую. Первая была на обычном ООП и это была боль. С ECS это совершенно другой уровень. Я могу добавлять любые фишки и мне не нужно дрочиться с синхронизацией (только роллбеки учитывать кое-где) и я могу всё тестировать локально с ботами. Если бы мне пришлось делать это "по старинке", то я бы охуел. Теперь буду делать сетевые игры на ECS.
Хотя для сингловой игры я бы не стал использовать ECS, ибо профиты от этого не получишь.
Потому что он неопытен в ецсе?
>>1020984
> Инпутвент OnPlayerShoot()->playerentity.addcomponent<shootdata>()->итерация системы shootdata->createentityBullet()->итерация системы bullet()->targetentity.addcomponent<hitcomponent>()->итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
1. Система считывающая инпут и задающая реакцию игроку.
Итерация по (Пушкам, Игроку) Пушка.Стрельба = Инпут.НажалаЛкм
2. Система пушкострел
Инютеерация по Пушкам
Если стрельба - спавним префаб пули.
Пуля.Позиция = вычислитьПозициюДляПули();
3. На префабе пули уже висит компонент содержащий урон, мы этот параметр сразу в Пуля доьавиои
4. СистемаПули - Итерация По Пулям
Если Пуля врезвлась в коллайдер
То удаляем пулю, создаем ентити демеджРеквест, таргет коллаыдер, урон = урон пули
5. Система нанесения урона
Итерация по демедж реквестам
Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Удалчем демедж реквесты
> И кстати, чё по многопотоку? Как отследить что компонент только появился, либо только что был удалён?
Ецс это не обязателньо многопоточность.
Конкретно в юнити многопоток в ецсе есть, там он работает через джоб систему и автоматически паралллелит код в зависимости от того где ты читаешь данные и где пишешь в данные, ну и условиц порядка выполнения которые задашь. Если 2 системы читают те же данные, то будут параллельно работать.
Сейм, работаю над ецс мультплеером.
>>1020995
А что если да? Лол.
Если у кого тотне получилось, не значит, что весь подход плохой, есть примеры и успешных игр на ецсе.
Можешь по юнити вакансиям походить, ецс не редко требуют на самые топ вакансии, у нас вот тоже ецс.
https://www.reddit.com/r/gamedev/comments/1kiyh0m/unity_is_threatening_to_revoke_all_licenses_for/
Я всё опасаюсь попасть под эту тему. У нас 1 про-лицензия, но 4 человека.
Заебись движок выбрали. Надежно.
Попадете обязательно, вопрос времени.
Тебе-то конечно нихуя не будет, ты нихуя не делаешь. А лохов которые умудряются на хуюните зарабатывать - подстригут как следует.
Не, ну справедливости ради мы благодаря нему заработали намного больше $200к. Тут просто русское жлобство взыграло и не хочется платить за несколько лицензий.
>Никто не будет добавлять и удклять компоненты с ентитей в рантайме так частр
Ну во первых это не так часто происходит в этом случае, а во вторых - ты делаешь то же самое, просто логика ещё более припизднутая.
>Если демеджРеквест.Таргет есть компонент хп, то наносим урона
Многопотока нет, понял принял.
>>1021015
>С ECS это совершенно другой уровень
ебли. Кстати, а как вы ограничиваете какие сущности какие компоненты могут видеть? Как оптимизируете трафик? Конечно, по сетевой синхронизации ecs значительно опережает аналоги, но вот эта припизднутая слабосвязанная логика моя самая огромная претензия к ecs, с этими соплями можно иметь дело, но только в команде.
У нас компания международная на 200+ ебал, никому нихуя не делаю за юнити персонал
> Ну во первых это не так часто происходит в этом случае, а во вторых - ты делаешь то же самое, просто логика ещё более припизднутая.
Добавление и удаление компонентов всегда хуйня
> Многопотока нет, понял принял.
Не обязательно чтобы всё было распараллелено. Да и можно и это в многопотоке сделать компонентЛукапом
Хорошо что я делаю на СВОЕМ движке.
И на своем языке.
пришлось сделать свой чтоб не спиздили движок. Он же на жс и хтмл
Зато делать игры на нем очень легко. Тупо вбил что надо и готово.
>компонентЛукапом
А что произойдет, когда лукап отработает, войдёт в метод обработки, а компонент в этот момент удалится из другого треда?
> А что произойдет, когда лукап отработает, войдёт в метод обработки, а компонент в этот момент удалится из другого треда?
Почитай док, там все расписано же.
Между синк поинтами(структурными изменениями) системы параллельно работают.
Чтобы сделать структурные изменения без синк поинта, используют ентити комманд буффер(есть многопоточное апи) и все что в него заложено проигрывают потом когда это нужно.
Это значит только одно - вас ожидают вот такие приятные побочные эффекты от использования очереди синхронизации
https://youtu.be/0ldiCi80gE4
Или любых других copy on write форматов воздействия на данные.
>ентити комманд буффер
Ну окей, даже без дока, как оно по твоему работает? Мне просто интересно твое мнение. А ещё можешь задуматься, а как оно разруливает ситуации как в видео, если в этот буффер пишутся только команды, которые зависят от контекста, но не включают его в себя.
https://docs.unity3d.com/Packages/[email protected]/manual/systems-scheduling-jobs.html
>>1021059
Я уже выше всё написал - паралелльно выполняются системы не конфликтующие друг с другом, и делают это в промежутках между структурными изменениями.
Если две системы читают один данные - можно параллельно.
Если одна система пишет одни данные, а другие не читают их - можно параллельно.
Если нет - они не будут работать параллельно.
> если в этот буффер пишутся только команды, которые зависят от контекста
Очевидно, в буфер не пишутся команды, которые зависят от контекста.
Надо создать ентити - ваще вскм пох.
Одна система читает данные каких то ентити, а другая их удаляет - похуй, реальное удаление будет после плейбека команд, а не в комент регистрации команды на удаление. Но скорее всего у тебя срань с порядком систем и логикой если такая ситуация.
https://docs.unity3d.com/Packages/[email protected]/manual/systems-entity-command-buffer-playback.html
Емае, все ещё хуже чем я ожидал. Да это же мой любимый многопоточный код однопоточного исполнения, где чтобы не обосраться придется нумеровать каждый пук и без блокировок строить таким образом синхронизацию. Ну-ну, пахнет производительно, а главное удобно.
>Но скорее всего у тебя срань с порядком систем и логикой если такая ситуация.
Не, скорее у меня реальный многопоток, а не гадание на кофейной гуще, правильный ли я порядок команд выбрал. Впрочем конечно тут вопрос технологии а не принципов, мне удобно так, вашей команде так.
Ты ваще не о том думаешь, сразу заспойлерю, тебе самому нумеровать ничего не нужно, прям там нижк пример есть - джоба предоставит тебе цифру.
Когда нибудь я таки напишу статью про это >>1020992
, я понимаю, что мимокрокодил непонятный со своими странными идеями выглядит неубедительно, но надеюсь как нибудь мы встретимся где-нибудь на просторах хабра где я таки представлю что-то новое в этой области, в общем приятно было побеседовать.
Давай, будем ждать.
Нужна какая-то демка, чтобы было явно видно как ты хендлишь удаление и создание объектов, и порядок логики, что вот сначала одно должно отработать, потом другое.
>хендлишь удаление и создание объектов
Сущность - только контейнер, компоненты, да хендлятся, добавление, удаление, изменение
>порядок логики
Порядка логики нет. Я фиксирую состояние определенного набора компонентов у сущност(и/ей) и/или отсутствие определенного набора компонентов, и любая попытка изменить состояние хоть одного из элементов состояния этого набора присущего сущности которая попала в выполняющийся контракт будет висеть в блокировке до завершения контрактов, запросивших на чтение наборы, куда входит та часть которую я хочу изменить (удалить, изменить, добавить). Хотя в случае с деньгами или скоростью или любым другим не особенно важным компонентом - я могу его изменять напрямую а не через changecomponent (иммутабельный подход к редактированию компонентов), если того пожелаю. Вот в принципе и все. При таком подходе я теряю не так много процессорного времени на ожидания, чем если буду формировать очередность выполнения или на все вешать блокировки, что по сути аналог ручного управления очередью выполнения.
>Нужна какая-то демка
В процессе). Пока прогресс меня радует.
Ну и ко всему этому - я могу выполнять код пока происходит удаление/замена/добавление компонента, что то вроде AddOrUpdate у concurrentdictionary, на которых частично в общем и строится контрактный подход. Остальные компоненты не блокируются, только попавшие в контракт/в такой метод.
Уже понятно что юнити и как бренд и как движок ВСЕ, кабанчики просто пытаются выжать из клиентов по-максимуму и свалить.
Прикиньте иметь успешный движок, устоявшийся бренд, который десятилетие ассоциировался как тот самый движок для индюков, но проебать эту репутацию одним тупым ходом, а потом вместо того чтобы медленно собирать по кусочкам проёбанную репутацию продолжать наступать на грабли.
ебанарий решил, что если он известный разработчик, то соблюдать условия лицензии необязательно, и поплатился за это. так будет с каждым. быть добру!
>так будет с каждым. быть добру!
Главное не плачь потом когда очередной корпорации (Нинтендо например) опять чего-то покажется и она тебе иск выдаст на десяток другой лимонов. Особенно если она про это проведает ещё до релиза потому что у тебя на компе будет стоять их малварь, которая будет каждый твой пук отправлять на изучение непонятно кому.
Ну тебе то безыгнорнику терять кроме собственных оков может и нечего. Но если такие поползновения с безапеляционной установкой малвари на компьютер со стороны компаний продолжатся - рано или поздно и за твоими оковами придут.
Ну тебе то безыгнорнику терять кроме собственных оков может и нечего. Но если такие поползновения с безапеляционной установкой малвари на компьютер со стороны компаний продолжатся - рано или поздно и за твоими оковами придут.
Вопрос.
1) Как они делают чтобы грязь на стеклах и корпусах машин появлялась процедурно? Вот естт базовая 3д модель машины сделанная в блендере. А как на ее краску добавлять пыль , царапки, а как повреждения рассчитывать сминания крыльев и дверей?
2) И как работает рей трейсинг в плане окрашивания отражённого света? Откуда компьютер берет данные о цвете 3д модели импортированной в движок и как преобразует отраженный свет накладывая "фильтр" цвета от чего от оотразился!?
3) Вопрос.
Можно ли сделать все как в гта не имея бюджета в миллиард и 2000 спецов. Но имея скажем отлаженный продакшн пайплайн с использвоанием ИИ в плане создания 3д моделей, текстур и все наполенния мира
>Можно ли сделать все как в гта не имея бюджета в миллиард и 2000 спецов. Но имея скажем отлаженный продакшн пайплайн с использвоанием ИИ в плане создания 3д моделей, текстур и все наполенния мира
Конечно можно, в рокстар же дебилы ретрограды работают, ведь уже давно появилась нейронка которая сможет написать шейдер освещения тысяч на 100 строк без единой ошибки, разработать архитектуру с оатимизациями путём всяческих SIMD и паралелизацией с минимальным cachemiss, обернет вся тяжёлые для вычисления (например деформации меша) в computeshader и попутно ещё и оптимизированых и правильных 3д моделей с анимациями нагенерирует. Появилась ведь?!?
А вас еще года два назад в треде предупреждали что такое будет с хрюнити где хаб стучиться онлаен и спрашивает у барина можно ли запуститься.
Одна из основных причин переходить на годот - ты им владеешь у себя на компе, по лицензии у тебя и движок и исходники.
>переходить на годот
Вот бы на нём ещё игры можно было бы делать...
Вот бы сейчас выдавать тейки 10 летней давности... В то время как уже вышли тысячи игр на годоте.
соблюдать условия лицензии обязательно всем, не только пользователям юнити, тупица
кретин, корпораты могут взять и отозвать лицензию или вписать условия по которым ты станешь неугодным. с опенсорсом это невозможно.
А ты чем читал? Они пишут что все условия соблюли. И что им предъявили за челов, которые не работают на юнити, или которым оплачивали про на время работы, или вообще левым челам которые зареганы в том же офисном здании. Сама по себе ситуация, что ты должен доказывать что не верблюд, при том что только что заплатил десятки тысяч долларов - лол.
Сотни тысяч разработчиков пользуются юнити годами и никаких проблем. Только у безыгорной маньки лицензии какие то отбирают
Все эти сотни тысяч разработчиков без проблем сейчас с тобой в одной комнате?
У любого могут отобрать.
>безыгорной маньки
Это автор DayZ так-то. А безыгорная манька тут ты.
Ну не прям в одной комнате, но в одном слаке.
>>1021147
У него доход на миллионы долларов исчисляется, чего ты так переживаешь за то что он 20к долларов платит?
Все вопросы с лицензиями сначала урегулируются в досудебном порядке, если никак, то через суд. Скорее всего они там уже со всем разобрались давно.
Лол. Сейчас бы бегать по судам доказывать что ты правильно все барину подписал, потому что у барина на тебя бот или индус сагрился. Ебануться. Юнитя почему вы такие терпилы?
То ли дело доказывать барину опенсорса 3 года что без uuid работа с ресурсами в движке будет говном неюзабельным и ловить баны за недостаточную инклюзивность.
Это в крайнем случае, а так они всё уже порешали инфа сотка.
Мне не нужны uuid ресурсов. На баны мне похуй, я не пользуюсь хуиттерами, на программу это не влияет.
Конечно. Поэтому ты не используй юнити, чтобы тоже в такую ситуацию не попасть. Бери лучше народный годот.
1 пик спарва сверху внимание на логотип бара. Куча деталей , каждая свою тень обрастывает. Есть идеи как они это реаллизовали наиболее cost effective способом? Если все такое отдать на откуп лучам то это же пиздец, 4080 нужна минимум. Как думаете каким способом они это сделали, чтобы пс5 тянула в 1440р? ну там 3д параллакс текстуры все такое. я не разбираюсь но хочу разобарться и сделать уже свою гта спб на уровне гта 6
Есть, для мод-лоуполи 3Д очень много аналогичных движков, даже на С#, для 2Д годот, гамак, для ААА юнити никогда не годился, тут анрил всегда доминировал.
ты ебучая безмозглая тварь понимаешь, что рассматриваешь зализанный трейлер, а не игру?
>playerentity.addcomponent<shootdata>()
Шутдата уже есть до того как игрок выстрелил вообще-то.
>итерация системы shootdata->createentityBullet()
Ну да. У тебя везде так будет, включая говдот.
>итерация системы bullet() targetentity.addcomponent<hitcomponent>()
? Шизик? Это что и нахуя? Всё это создаётся на предыдущем этапе.
>итерация системы по двум признакам (healthcomponent, hitcomponent)->decreasehealth()
Ну ничего себе, надо коллизии для пуль считать оказывается и хп убавлять. Только в ECS наверное такое происходит!
ЮИ кстати, чё по многопотоку?
Слишком зависит от реализации. В любом случае всё не может быть многопоточным, какие-то операции полюбому будут зависеть друг от друга.
>Как отследить что компонент только появился, либо только что был удалён?
Флагами.
>Насколько тяжело жить без возможности иметь 2 компонента одного типа на одной сущности?
Никто не говорил что так делать нельзя, зависит от реализации, в любом случае можно скрыть за композицией.
ого а зчекм так грубо?!
\
трейлер капчурился с пс5(дата релиза 4.5 г назад, железоуровня 2019) в рил тайме
Дятел, даже читать твои кукареки не буду, или пиши нормально и конкретно как ты это видишь или нахуй иди. Чел выше написал как он это видит, будь как он, уважай собеседника.
>Слишком зависит от реализации. В любом случае всё не может быть многопоточным, какие-то операции полюбому будут зависеть друг от друга.
Ясно, многопотока ты не видел
>Флагами
Ну если без многопотока то в целом и похуй и даже извращаться так как я описал не нужно, но флаги все равно хуйня, методы нужны.
>propook 3d
юнитя
ты опять обосрался, в оригинале нет этого
https://store.steampowered.com/app/1208260/Hentai_Vs_Furries/
Дык ты хуйню спрашиваешь детскую, а потом ноешь лол.
>флаги все равно хуйня, методы нужны.
Пиздец, просто пиздец.
>ноешь
Я-то? Впрочем как я уже намекнул - многопоточный и однопоточный ecs это два разных ecs, с разницей не в пропасть а в Марианскую впадину. Потому тебе и непонятно что я такое изобразил, а вот другому анону понятно. Можешь вкатиться как нибудь, будет интересно.
>Пиздец, просто пиздец.
У тебя все ещё впереди, не бери в голову.
> многопоточный и однопоточный ecs это два разных ecs, с разницей не в пропасть а в Марианскую впадину
Я тут дополню такой момент - в некоторых ецс(лео, морпех для юнити) видел такой подход - юзаем всё как обычный однопоточный ецс, ни о чём не запариваемся, но: отдельные системы, которые не будут ни с чем конфликтовать и не предполагают каких то изменений структурных, запускаем в многопоточном режиме.
Вот бегают у тебя тысячи юнитов в стратежке например и у нас есть система которая управляет куда они бегут - и мы берём пилим это на батчи и каждый в отдельный поток пихаем. И система ждёт когда оно всё прокрутится.
Даже если их меньше 1000 всё равно профитно будет, для каких то тяжёлых штук.
Разумеется потоки все заранее созданы в нужном количестве и простаивают, и задачу сразу пилим на такое число батчей чтобы каждому поровну дать и не юзать никакую синхронизацию между ними.
Чисто с практической точки зрения это очень эффективно, потому что профит хороший и реализовать не сложно в уже сформированном наговнокоженном проекте чтобы самое жрущее место оптимизировать.
>Вот бегают у тебя тысячи юнитов в стратежке например и у нас есть система которая управляет куда они бегут - и мы берём пилим это на батчи и каждый в отдельный поток пихаем. И система ждёт когда оно всё прокрутится.
ЕЦС тут вообще не причём, это просто многопоточка. Ты больше кода пиши и меньше шизы читай.
ЕЦС тут причём, потому что параллелим не задачу в вакууме, а итерацию по сущностям.
ЕЦС реализуем и без параллелизма, ты тупой походу и не знаешь о чём несёшь вообще.
Можно без параллелизма. А можно и с паралеллизмом. Можно с паралеллизмом систем. А можно с паралеллизмом в итерациях.
А ещё можно просто буквы читать научиться, либо гуглить если не понятно о чём речь.
>А ещё можно просто буквы читать научиться, либо гуглить если не понятно о чём речь.
вот и начни
Я ровно этим и занимаюсь
>>1021266
> ЕЦС реализуем и без параллелизма
В сообщении выше нк сказано, что не реализуем. Обтекай.
Только ЕЦС нахуй не нужен ни с параллелизмом, не без параллелизма, потому что не подходит для геймдева. А параллелизм и без него замечательно работает.
>не подходит для геймдева
Аргументируешь? Однопоточный ecs самая идеальная для геймдева архитектура, хотябы потому что даёт слабосвязанность какая DI даже не снится. А поскольку нет нужды синхронизироваться - можно вертеть компонентами и сущностями как только поделаешь.
Так связанность мало куда денется, а вот компилятор ее уже оптимизировать не сможет.
связность есть, просто она неявная и спрятана в строгом порядке работы с данными. это накладывает кучу ограничений на архитектуру систем и приводит к непредвиденным ошибкам в других системах при рефакторинге
>строгом порядке
Если нет многопоточки - порядок и его строгость не имеют никакого значения, потому что нет ничего что могло бы разрушить детерминизм. А значит внутри систем можно устраивать содомию из любых логических конструкций поверх горизонтальной природы ecs, не заботясь об их устойчивости, что приводит к уменьшению их количества(систем), улучшению их читабельности и облегчает кодовую базу на компоненты-флаги и сущности-флаги.
>связность есть, просто она неявная
Тут я согласен, базовые реализации ecs запрещают прямое наследование путём запрета на несколько компонентов единовременно в пределах одной сущности, но это не значит что это нерешаемая проблема. Лично я создал специальный компонент-базу данных, который позволяет легко обходить эту проблему.
>приводит к непредвиденным ошибкам в других системах при рефакторинге
Ну если следовать теории по ecs - такая ситуация просто не должна возникать, потому что на существование компонента определённого типа обычно реагирует только одна система, напрямую с ним связанная, неправильная работа 1 системы конечно может за собой потянуть остальные, но эта связь не проблема ecs, а естественная реакция архитектуры при подобном подходе, которую многие бы вписали ей в плюс. Но поскольку обсуждаем не сферический пример в вакууме, да ещё и не многопоточный - сложность поиска ошибки практически нулевая, обнаруживается немедленно и быстро устраняется, потому что нерушимый детерминизм очереди выполнения. А если не размазывать системы - ошибка локализуется ещё быстрее.
Ну а по поводу очевидных плюсов ecs подхода против стандартного ООП - всегда имеем легкодоступную модель данных, не требующую контейнеров, наглядное представление в памяти благодаря возможностям ecs фреймворков логгировать структуру сущностей и их графа связей через нодовую систему в красивую картинку, лёгкий способ сериализации мира, всегда легко горизонтально расширяемую архитектуру и возможность отслеживать и реагировать на любое изменение в модели данных(реакция на добавление, удаление, изменение). Всего этого можно достичь и при стандартном подходе, но это будет всякий раз велосипединг горизонтали архитектуры проекта, а DI контейнеры не обеспечивают гибкости ecs
> порядок и его строгость не имеют никакого значения
Делакм ентити с демедж реквестом
Делаем систему которая наносит урон по демедж реквесту
Делаем систему которая спавнит партикл хита по демедж реквесту
Делаем систему которая чистит демедж реквесты
Нужен тут порядок? Или не нужен? Можно посчистить демедж реквесты сразу после создания?
так екс не гибкий, любой маломальский сложный проект приводит к переписыванию всего екс кода в кор и выносу за пределы екс всех систем
Ты эту шизу уже выше писал и просто выдумал её.
Почему у нас на проекте ничего из ецса не выночится и не переписывается?
Почему в проде куча игр на ецсе есть?
речь о причинно-следственной связи. связность даст ошибку еще на этапе компиляции. хорошо написанный екс просто тихо пойдет по пизде, потому что связь не через ссылки, а через мысли у программиста в голове
потому что у вас гиммик, а не екс, объяснял уже
настоящий екс пишется с нуля, без движка
> почему в проде куча игр на ецсе есть?
ссылочку на статистику
Анон описывал многопотоковый подход, и я его выше по реплаю того анона тоже описывал. Все эти промежуточные стадии - плоды попыток сделать параллелизм в рамках многопоточной среды и не обосраться, потому что я не могу просто взять и спросить сущность, а есть ли у неё такой-то компонент, потому что в тот момент когда произойдёт if(entity.has component){дальнейший код} - при выполнении дальнейшего кода может оказаться что у сущности уже нет запрашиваемого компонента, а система переходит в режим undefined behavior. Потому такая хитровыебаная цепочка действий чтобы все свести к 1 системе применяющей к здоровью эффекты наложенные этими всеми реквестами и которая монопольно управляет компонентом здоровья, но эффекты при этом могут собираться без синхронизации и в любом порядке путём создания вот такой хуйни.
Но я повторюсь, всё это нужно только в рамках многопоточной среды, в однопотоке все это можно упрощать и композировать до предела, просто потому что нет нужды выжимать параллелизм.
>тихо пойдет по пизде
Думаешь обычный код так не умеет? И он пойдёт по пизде ровно настолько, насколько ты залоггировал. В отличии от дерева ООП, в ecs ты можешь буквально логгировать каждый чих и каждый пук изменения модели данных, и слово каждый тут не преувеличение. Ты по логам можешь восстанавливать состояние мира буквально пошагово, действие за действием и совершенно бесплатно, без смс и без геморроя. А если захочешь помочь ecs сообществу - можешь ещё и написать аддон к какому нибудь ecs который бы мог из таких зазипленых логов восстанавливать мир и видеть ошибку в реальном времени, чего не даст сделать ни одна пиздатейшая ООП архитектура
> потому что у вас гиммик, а не екс, объяснял уже
Да ты нихуя не объяснил, ты в итоге слился с обсуждений гиммиковости и пошёл обсуждать перформанс, но и там неудача - когда я тебе предложил накидать псевдокод твоего гига оптимизированного решения - ты ответил кек пук.
> ссылочку на статистику
Овервотч 2, стендофф, уже достаточно.
ну для начала давай список ваших систем и компонент вот так
можешь через чатгпт пропустить чтоб имена заменила синонимично
Еще месяц назад выяснили что он пишет не на ecs, он пишет на своих костылях которые просто называет ецс, при этом если бы он просто переписал это на ооп с композицией, все работало бы быстрее, потому что он не мешал бы компилятору находить happy codepath.
В овервотче было 10 на 10 игроков
В оверотче два только 5 на 5
Я ничего не путаю?
Какая то антиреклама ецс вышла.
Если что, 5 на 5 было в контрстрайке на технологиях 1999 года.
>все работало бы быстрее
Пруфы будут? Да и дело не в производительности, а в скорости разработки и степени переиспользования кода, где на мой вкус ecs нет равных, а это имхо - главные для индюка показатели крутости технологии.
Всё путаешь.
Овервотч = овервотч 2
> Если что, 5 на 5 было в контрстрайке на технологиях 1999 года.
Мы про число игроков говорим или чё?
Был тезис, что ецс не пригоден для игры, я привёл в пример успешные масштабные игры на ецс. Видимо, его непригодность для игр никак не помешала сделать успешные продукты
Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
Переиспользование в ооп ничем отличаться не будет, у тебя же не ецс, значит ты просто можешь перенести код систем в функции объектов и все станет еще удобнее.
Чел, 5 на 5 это не масштабная игра. Масштабная это 10000+, там где ецс имеет хоть какие то преимущества хотя бы в теории (хотя на практике их не будет).
Масштабная игра или не масштабная игра это не то сколько на сколько игроков.
Это то, насколько это объемный продукт с точки зрения реализованного контента, сколько там всевозможных механик. Если много и игра поддерживается долгое время, значит видимо использованный подход с точки зрения архитектуры пригоден к расширению.
Производительность это отдельный вопрос, и могу только сказать, что для максимальной производительности на мобилках часто берут именно ецс на практике.
>перенести код систем в функции объектов и все станет еще удобнее.
В каком месте оно станет удобнее то? Теорема Эскобара будет. Ты не понял о каком переиспользовании речь. А речь о архитектуре проекта. В случае ООП её костяк непереносной между проектами, а значит производство каждого проекта в рамках студии становится дороже, а его рефакторинг в случае каких либо серьёзных структурных изменений (например превращение дьяблоида в пошаговую РПГ/замена поселения на ферму) - займёт куда более бешеное время, потому что придётся менять все - структуры хранения мобов, управления объектами поселения, вводить новые виды стыковок между прокачкой поселения и местом игры, пересвязывать настройки и переделывать сохранения, переделывать тесты. Тем временем в ecs достаточно модифицировать компоненты так чтобы они на уровне данных отвечали потребностям геймплея, с помощью систем имея возможность получать компоненты с сущностями готовыми по фильтрам - уже сократить работу на сшивание кусков данных для обработки и переделать системы каждая из которых не является частью сшитого монолита данные+код, которой она будет в ООП( и даже не рассказывай что не будет) а являет собой код отдельно от данных, что во-первых ограничивает бурную фантазию, а во вторых - делает все модульным и легкосвязываемым с тем, с чем связываться ранее не планировалось, ведь для связывания просто надо отредачить фильтр компонентов.
>Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
Не читал и не буду. Ну сколько там было отставание на запрос данных из массива, на полмилисекунды или на 1 милисекунду? Это все претензии по медленности ecs или ещё что-то есть? Интересует что-то более существенное чем кешмисы которые даже бюджетный современный телефон не заметит.
>Это то, насколько это объемный продукт с точки зрения реализованного контента, сколько там всевозможных механик.
Так там вряд ли больше механик чем в каких нибудь древних дотах.
>Если много и игра поддерживается долгое время, значит видимо использованный подход с точки зрения архитектуры пригоден к расширению.
Вообще ничего не значит, я играю в ММО которой 20 лет и там все добавляют контент и механики, и там точно ООП. Когда большая фирма они что угодно будут поддерживать просто посадив людей. Типа было бы вообще охуеть если бы ецс не тянул даже 5 на 5, но вот с 10 на 10 уже вопросы.
>для максимальной производительности на мобилках часто берут именно ецс на практике.
Во первых слишком громкое заявление, где пруфы, где статистика, названия всех тайтлов и процентное соотношение ко всем остальным мобилкам? Во вторых, у тебя магическое мышление, поскольку ты считаешь что ецс сам по себе дает какой то прирост производительности, хотя это уже было разъебано в треде.
Да никак ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать. Писать пошаг на ецс это кстати тоже ад, еще один минус. Остальное какой то бред, что там у тебя такое в ооп случиться со структурой что ее нельзя скопировать в другой проект? Во-вторых у тебя в ецс будет такой же монолит, тебе сто раз уже объяснили что у тебя куча связей в порядке систем. Ну и как вишенка на торте, если у тебя телефон легко переваривает кэшмисы, то это означает что ецс вообще нахуй не нужна.
>Да уже неоднократно приводил ассемблерные листинги, ты не читал что ли?
И кстати говоря, мой спич выше все ещё про однопоточный ecs. Если вводить в строй настоящий многопоточный ecs, и не дотс с пародией на многопоточность в виде ручного управления порядком выполнения систем, а настоящий многопоток где основа обеспечения детерминизма это DbC компоненты+сущность - эта связка станет равной по производительности самому оптимизированому ООП потому что будет устранена проблема синхронизации состояний сущностей в рамках кода, фиксирующих это состояние, что даст мощный буст за счёт бесплатного для мозга многопотока из коробки, что ускорит разработку ещё сильнее, не будет сильного расхода на ожидающие блокировки и будет вся мощь фильтров по компонентам и управляемости каждым винтиком-компонентом системы в целом. Короче круто будет, а кто не верит пусть дальше изображает олдфага сколько влезет
> Так там вряд ли больше механик чем в каких нибудь древних дотах.
Что такое дот. Дота? Ну, поиграй в овервотч, хз.
> Вообще ничего не значит, я играю в ММО которой 20 лет и там все добавляют контент и механики, и там точно ООП. Когда большая фирма они что угодно будут поддерживать просто посадив людей.
Мой тезис "на ецс можно делать игры, на нём сделаны некоторые успешные и масштабные проекты"
Твой ответ "а вот ммо 20 летенее на оопе!" - это просто сразу минус, логическая ошибка. Второй ответ "посади большую команду, они что угодно сделают" - значит ты со мной согласен, на ецс можно делать игры, а твой тезис, что нельзя, был обманом?
> Типа было бы вообще охуеть если бы ецс не тянул даже 5 на 5, но вот с 10 на 10 уже вопросы.
Жирно
> Во первых слишком громкое заявление, где пруфы, где статистика, названия всех тайтлов и процентное соотношение ко всем остальным мобилкам?
Я не собираю точную статистику, я говорю что при поиске вакансий часто встречаю компании, которые делают игры на ецс. По моим ощущениям часто. Достаточно часто,
> Во вторых, у тебя магическое мышление, поскольку ты считаешь что ецс сам по себе дает какой то прирост производительности, хотя это уже было разъебано в треде.
Нет, у меня как раз нет проблем с мышлением, это у тебя встречаются логические ошибки и вкладывание слов в рот сейчас например. Где я говорил что ецс сам по себе даёт буст по перформансу? Я выше в треде писал, что можно организовать код в соответствии с ецс, который под капотом будет идентичен твоему специализированному спер производительному решению.
Просто сама архитектура будет ецс, и это закладывает определенные правила написания кода, возможность переиспользовать другой ецс код и возможность изучать и применять какие то подходы в реализации механик на ецс, возможность найти разрабочиков которым код будет привычен. Т.е. чисто с практическоц точки зрения могут быть профиты.
>Да никак ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать.
АААА, так это у тебя не получилось, ну что ж, раз даже у тебя не получилось значит все ясно с этим ecs, игрушка дьявола получается.
>Писать пошаг на ецс это кстати тоже ад, еще один минус.
Кек, как тут можно обосраться вообще не понимаю, даже немного любопытно.
>тебе сто раз уже объяснили что у тебя куча связей в порядке систем
Нету блять никаких связей в порядке систем в однопоточном ecs, ты жопой что-либо читаешь? Мне похуй в каком порядке они выполнятся потому что они всегда выполняются в одинаковом порядке и мне не нужно этот порядок никак формировать, я пишу изначально системы так чтобы они друг на друга не влияли, однопоток позволяет. Ты вообще ecs пробовал-то? Или маняфантазируешь?
> ты не превратишь дьяблоид в пошаговую игру при ецс, лол. Я именно этим и занимался, в результате проще все оказалось выкинуть и переписать.
Я хз как упороться надо, чтобы писать пошаговую игру на ецс, лол. Давай еще суп вилкой есть а потом пиздеть что вилка хуйня.
> Во-вторых у тебя в ецс будет такой же монолит, тебе сто раз уже объяснили что у тебя куча связей в порядке систем.
Это очень решается продуманными группами систем и определением порядка групп.
Другими словами, задача переноса ецс кода из одно проекта в другой заключается в определении порядка систем и всё, остальное копипаст без изменений.
Довольно низкая цена, не?
> Нету блять никаких связей в порядке систем в однопоточном ecs, ты жопой что-либо читаешь? Мне похуй в каком порядке они выполнятся потому что они всегда выполняются в одинаковом порядке и мне не нужно этот порядок никак формировать, я пишу изначально системы так чтобы они друг на друга не влияли, однопоток позволяет. Ты вообще ecs пробовал-то? Или маняфантазируешь?
Думаю, он говорит про ситуации в стиле - одна система хочет иметь результат другой чтобы на него отреагировать.
Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
Но решается это проблема не сложно.
>Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
Тогда стоит следовать старому мудрому правилу - действовать согласно теории. А согласно теории - систем делающих разные действия относительно одного и того же набора данных быть не должно. А если таковых систем не будет - не придётся решать роняя кал подобные проблемы.
У тебя постоянно логическая ошибка на ошибке, например: ты пишешь что я где-то писал, что на ецс невозможно сделать игру - а я писал, что ецс не пригоден для использования игр. Ну вот например некоторые и в Экселе игры делают, (да собственно я на какой то твг отправлял game of life в гуглдоках) но это не значит что он для них пригоден.
Или например, из того что ейчарка вписала новый очередной баззворд в вакансию, ты делаешь вывод что ецс реально используется на работе в этой фирме. Ну и так далее.
Это невозможно в любой хоть сколько то нетривиальной игре. Ну вот банально говоря о пошаговой игре - есть урон от атак, есть урон от дебаффа, есть урон от окружения, есть регенерация, вот и приехали.
События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
настощий ООП только в smalltalk
>Как думаете каким способом они это сделали, чтобы пс5 тянула в 1440р?
В 144р тянуть будет
>есть урон от атак, есть урон от дебаффа, есть урон от окружения, есть регенерация
А ещё можно создать компонент, хранящий эффекты-делегаты с метаданными времени последнего применения под временные дебафы, применяемые одной системой. А напихивать туда делегаты можно прям из игрового процесса, потому что ecs отработает в конце кадра, ведь я надеюсь ты не пишешь на ecs всё, включая игровое представление сущностей? Если пишешь то ты сам себе злобный Буратино конечно. На dots таким заниматься можно, но на то он и dots
>События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
Если я правильно помню - событий в ecs нет вообще, entity components system как бы. События это придумка как подружить ужа с ежом в виде клиента-сервера или ecs ядра мира и mvc его представления игроку, которая в dots отсутствует по причине ненадобности.
Параллакс и бамп, очевидно же. Печально, что на волосах артефакты дизеринга. Это автоматически значит, что весь графон в игре проклят и будет гостинг, блюр и полный пиздос. Но судя по текстуре чела с банкой, количество аккумулируемых кадров и биасы выставлены на минимум. Не идеально тоже, но лучше так. Судя по плоской нигерше на заднем плане, с освещением тоже полный пиздец. Края теней рваные, то есть это рендеринг карты глубины из камеры, а не RT.
Unity Industry User Day | May 14th | Brighton, UK
Nordic Game 2025 | May 20th - 23rd | Malmö, Sweden
Unreal Fest 2025 | June 2nd - 5th | Orlando, USA
Game Access Conference | June 6th - 7th | Brno, Czech Republic
AWE 2025 | June 10th - 12th | California, USA
Ну так ты сам подвтвердил что ецс не подходит для игровых сущностей, то есть не подходит для разработки игр.
> У тебя постоянно логическая ошибка на ошибке, например: ты пишешь что я где-то писал, что на ецс невозможно сделать игру - а я писал, что ецс не пригоден для использования игр
Это была бы не логическая, а фактическая ошибка.
Ведь ошибка заключается не построении логики, а в превирании факта с мрей стороны.
Но в данном случае это даже не фактическая ошибка, а дрочь терминологии. "Не возможно", "Не пригоден".
Совершенно очевидно что я отвечаю не с точки зрения физической возможности делать игры на ецс(это и иак понятно что что угодно можно сделать), а с точки зрения практической жизнеспомобности написания игры на ецс(слово пригоден, как ты выше написал).
Если тебе было не очевидно(что странно, ведь явно мы не физическую возможность сделать игру на ецс обсуждали, что обсуждать было бы бессмысленно, ясен хуй ответ да, пвторюсь), то я сейчас тебе это говорю.
> Или например, из того что ейчарка вписала новый очередной баззворд в вакансию, ты делаешь вывод что ецс реально используется на работе в этой фирме.
Пока что 100% соответствия на моей прратике(т.е. у меня инфа не только исходя из прочтения вакансий). Даде больше - иногда на ецс пишут там, где ецс в вакансии не упомянут.
Отдельно отмечу, что ецс в требованиях сужает воронку кандидатов, как базз ворд не лучшая идея.
Блиннн 5% игровой логики без параллелизма и кеш локальностиэто вообше пиздежь к слову
>>1021394
> События это придумка как подружить ужа с ежом в виде клиента-сервера или ecs ядра мира и mvc его представления игроку
А? Нет. Чтобы подрузить ецс ядро с чем то никакие события не неоьходимы. И уж события в терминологии ецс(компоненты живущие 1 кадр) точно не нужны
Да у меня нет цели никого убеждать, лол) Сидите дрочите свой mvc или mvvm или контейнеры или собственные велосипеды или что вы там дрочите, декомпозируйте, пишите интерфейсы и занимайтесь прочим говнецом. Ты в очередной раз отказываешься читать буквы, не пытаешься вникнуть в какие виды ecs бывают, зачем они бывают. Конечно, я тебя отлично понимаю, на данный момент технология не коробочная совершенно(дотс), требует усилий, детские болячки не решены в большинстве либ, требуется экспертиза, а читать мануалы по ecs с официальной теорией вообще вредно для продукта. Но я уже решил все её проблемы, осталась только одна - моё решение ещё не доведено до совершенства(нету асинхронщины, только потоки, библиотека не раздроблена на части и не готова к plug and play, не готова к web билдам) и я бы и хотел показать что ecs может быть другим, но к сожалению не сегодня и не сейчас. А сейчас может и правда учитывая специфику и ограниченность большинства либ по функционалу стоит писать по старинке, если ты не хочешь вникать в особенности приготовления ecs проектов и изобретать подходы к агрегации данных в рамках ecs. Но даже в моём решении чтобы писать интерфейс на ecs - надо быть олигофреном. Даже управление представлениями сущностей я лучше отдам на откуп движку, чем буду совать его в ecs, потому что не нужно намеренно стрелять себе в ногу и забивать гвозди микроскопом. Такое разделение удобно, просто надо понять как его приготовить и не обосраться.
>А? Нет. Чтобы подрузить ецс ядро с чем то никакие события не неоьходимы.
А ну давай, расскажи как ты будешь сигнализировать клиенту о том что мир изменился, или как клиент будет давать понять серверу что что-то произошло в локальном ecs. Как оттранслируешь локальный инпут клиента другим членам сессии?
Че за рандомный набор слов.
> А ну давай, расскажи как ты будешь сигнализировать клиенту о том что мир изменился
Обычно на уровне инфраструктуры ецса нетворк поддерживают.
> или как клиент будет давать понять серверу что что-то произошло в локальном ecs.
SendToServer()
>Как оттранслируешь локальный инпут клиента другим членам сессии?
ReceiveDataFromServer()
Что ты вообще под событиями подразумеваешь? Мне кажется ты сам выдумал этому какой-то смысл, сам вложил слова мне какие то и сам споришь с выдуманной тобой же позицией.
>Обычно на уровне инфраструктуры ецса нетворк поддерживают.
Хуйню они поддерживают. Как сделать так чтобы компонент здоровья конкретной сущности увидел один набор клиентских сущностей, а второй набор его не увидел?
>Что ты вообще под событиями подразумеваешь?
Вот, можешь ознакомиться что они там поддерживают
https://github.com/RevenantX/LiteEntitySystem
Не будешь ли так любезен расшифровать для меня аббревиатуру RPC? Или объяснить разницу между RPC и событиями.
>ReceiveDataFromServer()
>SendToServer()
Ты же никогда не делал мультиплеер ecs, да? Угу, примерно так будет называться событие/процедура, прилетающая с сервера и приносящая обновление локального мира и обратно, но не только они будут существовать. К примеру я у себя инпут синхронизирую в обход ecs, потому что так тупо быстрее и никакая йоба ecs синхронизация не сможет ее обогнать, а саму ecs обновляю постфактум.
Хз, у тебя каша в голове.
Смотри о чем был разговор
>>1021377
> Думаю, он говорит про ситуации в стиле - одна система хочет иметь результат другой чтобы на него отреагировать.
> Например насрал ванфрейм ивентами и почистил - и есть система которой они нужны, и она должна отработать до очистки ван фрнймов.
>>1021385
> События - это еще одно слабое место ецс. Которое хуево сочетается с параллелизмом и кэш локальностью.
И тут в контексте этого внезапно ты начинаешь что то срать про мультиплеер и рпц. Причем выше еще говорил что то про мвц. Я просто хуй знает что это, к чему это.
> Или объяснить разницу между RPC и событиями.
Отличный вопрос, у меня есть вопрос еще лучше - откуда у тебя вообще такой вопрос встал?
>>1021469
> К примеру я у себя инпут синхронизирую в обход ecs, потому что так тупо быстрее и никакая йоба ecs синхронизация не сможет ее обогнать, а саму ecs обновляю постфактум.
Про детерминизм и роллбеки не слышал?
>Хз, у тебя каша в голове. мням пук
Ладно
>Про детерминизм и роллбеки не слышал?
Про потребность синхронизировать инпут в рамках 10мс-пинг_клиентов_мс у всех клиентов сессии слышал? Или на вопрос про 200мс лаг инпута будешь про роллбеки рассказывать?
> Про потребность синхронизировать инпут в рамках 10мс-пинг_клиентов_мс у всех клиентов сессии слышал?
Что?
> Или на вопрос про 200мс лаг инпута будешь про роллбеки рассказывать?
Что?
Я не понимаю, ты жирно тралешь или что? Игра работает локально полностью детерминированно, на сераер шлется инпут игроков с временными метками, с сервера приходят все инпуты с временными метками, при несоответствии предикту делается откат и ресимулияции с новвм инпутом.
Я хуй знает что тут у тебя за особая магия с инпутом в обход ецс и какой оно выигрышь дает(никакой), я хуй знает что за шизу ты несешь тут, возможно ты просто криво выражаешься(что вполне ожидаемо по тому как ты с ван фрейм компонентов ввел терсин собвтия, а потом забыл про ван фрецм компоненты и стал говорить что события это как рпц но не рпц, я хз че ты несешь)
https://www.photonengine.com/quantum
Не хочу скатываться в "ты тралиш, нет ты тралиш", лучше просто ответь, делал ли сетевой ecs и если да то какой? Просто любопытно.
С роллбеками ецс тоже несовместим. Ведь связности нет и компоненты поудалялись.
Не дает. Нет реального сценария где ецс дал бы ускорение. Он хорош только в синтетическом бенчмарке где ничего не происходит. Если у тебя меньше 10000 однотипных юнитов - ускорения нет. Если у тебя юниты с каким то сложным поведением или сильно различаются по компонентам - ускорения нет. Если у тебя вообще что-то больше чем тривиальная логика - появляется связность, начинает хериться кэш и ускорения нет. Хочешь события - они убивают ускорение. Если ты пишешь по тру ецс, то ускорение съедается необходимостью постоянно перетасовывать массивы компонентов добавлением-удалением. Если ты начинаешь костылять, у тебя получается самодельный недо-ооп, который будет медленнее оопа, потому что компилятор не может эффективно оптимизировать то, что относится к разным компонентам, но разным энтитям. И бонусом у тебя нет вменяемого дебага, вместо него портянки логов компонентов, нет сетевого роллбека, тебе надо костылять вместо удаления отдельное хранилище (и опять перетасосвывать массивчики).
Все что надо знать - ецс непригоден для разработки игр, никакой производительности он не дает, но некоторые начали использовать его как маркетинговый баззворд, когда это намного эффективнее было бы сделать просто на ООП + SoA.
> Если у тебя вообще что-то больше чем тривиальная логика - появляется связность, начинает хериться кэш и ускорения нет.
А с ооп и соа есть?)
>10000 однотипных юнитов
Я на долбоёба похож делать 10к юнитов не на хаках гпу? Оно всё равно сдохнет.
50+ по работе, 20 своих, 2 на ецс.
>>1021488
Хаки гпу касаются только визуала, ты же не собираешься игровую логику там считать (бафы-дебафы-аое урон-бихевиор три). Да и на мобилках гпу слабее.
> 50+ по работе, 20 своих, 2 на ецс.
Сколько максимум программистов над игрой однвоременно работали? Много из этих игр были на ооп + соа? На ецс игры делал сам или в команде?
К чему этот вопрос? Программистов 7-9 максимум в одном офисе, но все же обычно разделение по направлениям по 1-2 чела. На ооп были все, лол. Соа - как оптимизация, да. На ецс делал сам чтобы посмотреть а чего это за технология которую все пиарят, потыкал прототипы на entt, flecs, еще каких то, кажется gaia и entityX, на шарпах entitas и leo (еще старую), до свельто уже не добрался поскольку к этому времени убедился что ецс говно, поискал сообщения разных программеров из крупных студий и они пишут в целом то же самое, после чего и плюнул.
>ты же не собираешься игровую логику там считать (бафы-дебафы-аое урон-бихевиор три)
Но я и не собираюсь делать это для десяти тысяч юнитов, я же не долбоёб. Если прямо нужно подсчитать движение для роя, то я подсчитаю N путей и буду их использовать каждый раз с разбросом либо усреднением.
Ну пути это пути, не говоря о том что если динамическое окружение, как часто у тебя пути перестанут быть актуальными. А про геймплей, со сплешами от аое взрывов то что будешь делать?
>часто у тебя пути перестанут быть актуальными.
Но имея десять тысяч юнитов мне всё ещё не нужно иметь десять тысяч путей. Десять, не больше. Даже если окружение процедурно изменяется каждый кадр, это остаётся неизменным.
>со сплешами от аое взрывов
Скорее всего предварительно рассчитаю поля расстояний для юнитов и буду использовать их почти бесплатно. Либо буду использовать вычислительный шейдер на гпу, там это просчитается за полнаносекунды даже для десяти тысяч объектов.
Во первых я тебе написал что на мобилке гпу не будет за полнаносекунды считать.
Во вторых ну посчитаешь ты что-то на гпу, тебе надо еще это на цпу перегнать чтобы сохранить новые значения хп. Или ты собрался всю игру на гпу писать, лол?
>на мобилке
Так я же не конченный идиот делать 10 тысяч объектов на мобилке. Там это не вывезет ничего - ни цпу, ни гпу. Сомневаюсь, что даже рендер 10 тысяч объектов на экране будет работать со вменяемой скоростью. Так что мобилки можно не рассматривать вообще.
>это на цпу перегнать
Вычислительные шейдеры для этого и существуют.
>не нужно
Принято.
>Вычислительные шейдеры для этого и существуют.
Вообще то максимальный прирост будет если возвращать на цпу ничего не надо, и передавать результат уже дальше в графический шейдер для отображения.
>>не нужно
Может, и не нужно - хуй ты увидишь 10к объектов на экране мобилки. Но речь не о том. Такое количество "честных" объектов убьёт мобилку, рендер не вывезет, даже если логика будет оптимизирована.
>максимальный прирост будет если возвращать на цпу ничего не надо
Да я в курсе, но хп всё равно нужно как-то возвращать. Чисто в теории можно дамаг наносить на текстуру и в фоне гонять между цп и гпу, будет быстро. Если ещё запечь анимации в текстуры, то в цпу и возвращать не придётся. Но здесь гпу мобилки уже обосрётся, потому что ветвления + тысячи объектов.
это хватит для эффективного использования этого паттерна? никогда им не пользовался
Бери нормальный движок с С++, чел. Например, Годот.
Тебе нейрокалич какую то другую херню расшифровал.
Ну вот например https://github.com/Cysharp/StructureOfArraysGenerator
Если бы ты хотел игру сделать, взял бы Годот,
а на говнюнити ты ничего не сделаешь, будешь просто хаб взад вперед переустанавливать.
А зачем переустанавливать хаб? Я его как установил где-то в 2018 году, так и не удалял. К тому же, им не обязательно пользоваться.
У меня только за год дважды слетал логин, а без логина и без лицензии ты получишь дулю вместо редактора. Так что без хаба никуда.
Не только редактора, но и ассеты вроде без ВПНа не ставились.
Таков печальный удел Юнити-петуха, если завтра в eula добавят пункт, что для доступа к хабу нужно выслать фото с флажком в анусе, ты грустно вздохнешь и пойдешь выполнять.
это потому что ты годотя
у юнитибогов всё нормально работает
Откуда у тебя время играть в игры? Я вот с трудом нахожу час-другой после работы поковырять анрил/блендер, ни о каких играх речи не идет, хотя бывает хочется во что-то залипнуть, но понимаю что тогда вообще ничего не буду успевать
У меня просто жены и детей нет.
Ну я сегодня по-настоящему только часа 4 работал.
Не хрюнити об этом заинкаться.
С женой наоборот лучше, не тратишь время на готовку, уборку и дрочку.
Кстати, одна из самых успешных инди-игр от отечественных разработчиков. По деньгам наверное квартиру в Мухосрани можно с такой прибыли купить.
Я сам даже играл и ничего не тормозило. Скорее всего это старый билд в котором автор не прикрутил оклюжн куллинг к стенам зданий и прочей геометрии и десятки мобов тупо рендерятся пока их не видно. Но он все починил после того как игра взлетела.
>Не хрюнити
У этой игры в стиме отзывов столько, что годоти даже если в голема соберутся не соберут столько.
Это судьба годота - быть пропукивающим и никому не нужным. А игры на юнити даже с пропуком купят. Тем более что пофиксить все изи.
> Кстати, одна из самых успешных инди-игр от отечественных разработчиков. По деньгам наверное квартиру в Мухосрани можно с такой прибыли купить.
Это даже не близко к успеху.
Ты ебнутый что ли? У Круелти сквада в 10 раз больше отзывов, лол.
Так это норм игра, хоть и на годоте.
Много таких популярных игр на годоте как круелти? Единицы скорее.
А на юнити процент таких игр больше в разы.
ENA: Dream BBQ вышла в этом году, и отзывов уже больше чем у Круелти.
Я из вкусвилла ем готовое как правило, а завтраки просто готовить. Убирается клининг. За сексом хожу по шлюхам. Вот так и живу.
К сути. Ищу простой движок под свою хотелку. 31 годик, гуманитарий к технарю 80/20, нулевой опыт кодинга и работы с движками. Есть та самая ИДЕЯ, есть навык чтения и письма, есть потребность рассказывать истории. Хочу сделать свою условно простенькую, текстовую сюжетную РПГ/адвенчуру без лишних изъёбств. Осознаю свою ничтожность перед силой кода, потому запросы имею весьма скромные:
- возможность более-менее наглядно (для себя) создавать ветвистые сюжетные цепочки с выбором вариантов кнопочками при минимальном знании языков вроде C# и Java (в идеале, вообще без);
- удобное отслеживание выборов, переменных, статистик, желательно "из коробки" или простым способом, чтобы даже я смог реализовать всякие там проверки, простую настройку имени/внешности игрового персонажа как пример;
- человеческий UI с возможностью настройки кнопочек и менюшек криворуким аутистом, и вообще презентация игры на уровне чуть повыше, чем старые текстовые квесты и "choose your own adventure" книжки.
Необязательные, но приятные хотелки:
- примитивный ролевой элемент прокачки, левелапа, статы-навыки как простые проверки на их наличие в сценах, без рандома;
- возможность малой кровью добавить 2D графику уровня визуальных новелл, cutouts/задники/карту, если вдруг получится их сделать.
Да-да, я не шутил, я абсолютный хлебушек. Мои запросы - очевидный примитив, но как хлебушку мне хотелось бы меньше ебать себе мозги изучением кода, вижу в этом лишь необходимый инструмент. Готов осваивать азы по мере необходимости, но сомневаюсь, что смогу эффективно сделать что-то сложнее диалоговых скриптов. Думать о вещах вроде полноценной формульной боёвки, пошаговки по клеточкам, мини-игр мне в одиночку бессмысленно, помощи тоже не будет, потому для первой попытки масштаб ставлю минимальным. Интерактивный фикшен/RPG. Отталкиваюсь от своих сильных сторон - начитанный, могу писать тексты, прописывать персонажей и сюжеты. English is not a problem.
В курсе текстовых движков типа Twine, попробовал самые популярные текстовки на нём, но там видимо прям совсем спартанские возможности. Боюсь, часть моих хотелок будет работать только через костыли (ролевой элемент), часть вообще не будет (возможная в моих мечтах графика), UI хотелось бы более дружелюбный, а охват публики даже с моими несуществующими целями будет единичный.
Юнити наверняка перебор, разве что там есть простецкие готовые шаблоны для всего того, что мне нужно. Что остаётся? RenPy? Godot? PRGМахеры? Свой вариант? Что анон считает более дружелюбным движком под простые игрушки, для абсолютного казуала?
О целях, для контекста: планов на монетизацию нет никаких, только свободный доступ, к раскрутке дальше форумов и борд тоже не стремлюсь. Зачем делаю? Потому что. Надоело пробивать лицо рукой от типичных сюжетов, персонажей всяких визуальных новелл, текстовых RPG. Всегда хотел реализовать внутреннего рассказчика. В идеале смогу из этого сделать достойную демку своих навыков, чтобы было, что показать в будущем возможным единомышленникам или с чем постучаться в чей-то проект на правах хобби.
И конечно, я как-нибудь справлюсь с поисками и без Двача. Но было бы приятно услышать обоснованное мнение уважаемых людей. Может, кто-то забавлялся подобным или видел готовую реализацию.
Ren py - 100%. Тупо из-за количества гайдов для него.
Мб tuesday js, но на нём вроде нет серьезных игр.
Так на годоте игр мало, значит и процент успешных выше.
И твоя игра на Годоте может стать мега успешной.
Потянул еще 5 лет назад
https://www.youtube.com/watch?v=WDT3_j_G_ZA
Ты хочешь движок с уже готовой игрой внутри. Вот скажи, ты ебанутый?
На самом деле есть вариантв для этого
>>1021741
Либо юнити с каким нибудь ассетом, гугли в сторону unity rpg starter kit, может найдешь какие то шаблоны.
Программировать через чат гпт будешь.
Либо может быть гейм мейкер или рпг мейкер(?), там кажется как раз есть уже основа под статы.
>Godot
Ну да, там все довольно просто разобраться. В РАЗЫ проще чем в юнити. И туториалы намного более качественные.
>Свой вариант
Я случайно удалил гитхаб с кодом своего движка. Лолллл
Он был говном, но как раз для лёгких игр. А так конечно лучше Рен пи если ты полный 0. Тупо напиши best visual novel rpg engine.
>текстовую сюжетную РПГ/адвенчуру
Unity + Yarn - это даст все возможности хрюнпи, но ты неограничен питухоном и хрюнпи, а значит можно создать буквально что угодно
пытался воспользоваться ярном да так и забил. мне кажется, не-кодеру будет сложно в этом ярне разобраться
я в итоге написал свою систему диалогов с node-редактором, но я ж программист
если ваша игра чисто нарративная, сделайте сначала прототип истории в каком-нибудь Twine или любом РПГ-мейкере, даже самом древнем
>РПГ-мейкере,
nexomon: extinction выглядит как игра на нем и рубит миллионы.
https://github.com/YarnSpinnerTool/YarnSpinner/releases
>>1021749
>>1021753
>>1021754
>>1021760
>>1021761
>>1021765
>>1021781
>>1021813
Честно, не ожидал с десяток адекватных ответов и примечаний. Добра всем и чаю с пироженками, ну или пива с мясом.
Пока накидываю сами нарративные ветки, персонажей, наверное рискну свободным временем и попробую поковырять Unity + Yarn. Я же не совсем тупенький, вдруг справлюсь? Опыт будет полезен в будущем, мне кажется. Если нет, то всегда остаются Godot и RenPy. Twine для прототипа тоже хорошая мысль, уже думал об этом.
вот это еще глянь. имхо идеальный инструмент для твоих задач
https://instead.hugeping.ru
а еще прикольно, что от нашего разраба
> Пока накидываю сами нарративные ветки, персонажей, наверное рискну свободным временем и попробую поковырять Unity + Yarn. Я же не совсем тупенький, вдруг справлюсь?
Да, норм, аросто юзай чат гпт или дип сик, это очень сильная вещь для новичков, прям вбивай любые вопросы, он в целом приемлимо подскажет и по коду и по разумности каких то реализаций
https://discussions.unity.com/t/unity-6-2-beta-is-now-available/1639999
Какой содомит эту обложку приделал.
>бомж пк
5090 уже бомж видяха - дропы до 15 фпс с парашным графоном фортнайта.
>у меня 960, ебало моё представил?
Пять лет назад ты легко мог играть в фортнайт. А сейчас даже не факт, что он вообще запустится. RT ядер нет, так что будет фоллбек люмена на софтварный RT. А нанит просто уничтожит твою пропускную способность. Короче с твоей видюхой в КП2077 поиграть, чем в это.
>>1022029
Ох уж этот коупинг.
нанит на мобилках работает, какой люмен?
>коупинг
то есть ты не в курсе, что мониторинг делает дропы? значит ты просто некомпетентен
>фортнит на мобилках работает, какой люмен?
фикс. в общем, ни нанит, ни люмен не являются обязательной фичей рендера
это годот дропы делает, 100%
я заметил, что годот даже если не запущен, а просто лежит в папке, то тихонько подсирает всем приложениям и делает пропуки
у меня было две версии годота - третья и четвёртая, соответственно, пропуков в 2 раза больше
только когда я удалил годоты и почистил реестр, дропы прекратились
Задокументированное явление. Старайтесь не устанавливать годот даже из любопытства. Одна установка и ваш компьютер скомпрометирован навсегда.
>Засирает комп юнити хабами и эпик ланчерами, которые буквально были пойманы за руку постоянными сливами данных барину
Опять годот в штаны говна залил, чтож такое....
https://github.com/desplesda/YarnSpinnerDialogueInterruptions/tree/main/Assets/Samples/Yarn%20Spinner/3.0.0-beta1/Samples
Если поставить 21 9, то часть экрана отрезается.
Не интересно, когда уже есть Dialogic 2
https://github.com/dialogic-godot/dialogic
>на мобиле
Так а нахуя тебе игры на мобиле, ты что, долбоёб?
Да пох, он для говдота, а им никто не пользуется. Для юнити твоего говнодиалоджика нет.
это самая обычная игра на юнити использующая ярн, покажи теперь что-то близкое на хрюдоте
https://steamdb.info/app/1562430/
Да ни при каком разрешении черных полос быть не должно, вот и думай в эту сторону. Чем их заполнить.
могу показать самую обычную игру на юнити, использующую Articy Draft - Disco Elysium
а что может показать хрюдот? хрюкающего волка?
и разрабы выбрали идти по пути наименьшего сопротивления, почему хрюдоти так не могут - загадка
и подрубили йоба-фреймворк на 999 гигабайт, вместо того, чтобы написать 3 строчки кода? лол!
>и подрубили йоба-фреймворк на 999 гигабайт
ты щас любое приложение на телефон, а на компуктере это не критично, сколько юнити, сколько уринал тянут говна за собой, которое невозможно отключить и которое возможно никогда даже не будет использовано
Казалось бы, ещё в играх 80-ых годов были диалоги, неужели говдот не может в технологии 40-летней давности?
чтоб были простыни соевой каломании? такого нет. на годоте выпускают только базированные игры типа хрюкающего волка, энвайронмент сторителлингом, который не нуждается в диалогах
ты читал?
-Все сгенерированные активы и скрипты будут содержать метаданные (т.е. данные EXIF), которые указывают: "Этот актив был сгенерирован с помощью ИИ"
-Ваша ответственность заключается в том, чтобы определить соответствующие декларации на основе ИИ для магазинов приложений, платформ распространения и конечных пользователей, когда вы отправляете коммерческий проект, использующий генеративный ИИ.
Model and Provide
GPT-series from Azure Open AI Services
GPT-models are used at various stages in the Assistant pipeline.
Llama-series from Meta Platforms, Inc
за результат будешь им авторские отчислять?
как регулируется (лицензируеться) контент?
представь ебало когда стим или сонька не пропустит?
хуй знает короч
>представь ебало когда стим
они не пропускали когда только нейро бум начался, щас они уже анально и юридически подготовились и стали пропускать
всегда пропускали. один раз удолили какой-то слоп, явно сгенерированный нелицензионной нейромоделью
>за результат будешь им авторские отчислять?
А с какой радости? Продукция ИИ не может иметь какие либо копирайты, уже четырежды обсосаная и высранная тема. И весь этот текст это Филькина грамота которой можно постараться, потому что те кто тренируют или в противном случае будут обязаны доказать владение над всеми входными данными датасета, что невозможно.
тут просто прописано, что это твоя обязанность явно указать использование ИИ на площадках, которые этого требуют
копирайт на сам контент принадлежит тебе
Пидарас прискакал в годот-тред, его там проткнули и он заткнулся. Хаха!
>нахрюк жирного порка
Мне - похуй
Я делю и хочу делать игры ради денег и искусства, я умею программировать, но я не программист, я не хочу и мне не нужно делать свой движок, это застопорит меня и никак мне не поможет достигнуть моих целей, я беру уже готовое и меняю под себя, а если ты ещё сбилдил свою игру в на юнити в моно - я спизжу и твой код