Какие то костыльные решения, когда за нас уже все придумали.
Современные движки чаще всего имеют отдельно рендерный ФПС, отдельной, фиксированный ФПС, обычно связанный с физикой (Зачем нам считать физику в 600фпс?) и отдельно ФПС ввода.
В нашем случае, ввод - ОБЯЗАТЕЛЬНО надо вытащить из рендерного потока в отдельный поток и делается это очень легко.
Мы создаем поток, в нем крутим луп те же 60 кадров в секунду. Для игр где чувствительность ввода важнее (хотя я заметил, что движки считывают ввода с частотой 24 и 60 ФПС) - крутим 120 или более.
Все это пишем в буффер и в конце игрового кадра, когда буфер прочитан - все обработанные ивенты удаляются и так цикл повторяется.
Пишется это не сложно. При желании - атомарно, т.к. игровой цикл только читает, а цикл ввода - только пишет. Размер буффера обычно у нас на протяжении всей игры не плавает, а всегда один и тот же.
В США ты мог заметить, что андроидом почти никто вообще не пользуется, а это их мейн-рынок. При этом тебя на андроид там, даже если это флагман за лям, никто даже пытаться гопать не будет. А вот айфоны воруют за милую душу.
Если зайти в исходный код Godot, то в папке modules, core и scene, ты почти с ходу сможешь читать чужой код без документации.
Если зайти в исходный код O3DE, то по одним шаблонам в глубину ты будешь скакать страниц на десять в глубину, что бы понять, что делает та или иная строчка.
Ну и движок рантаймовый. Т.е. вся игровая логика базируется на примитивных типах (int, float, bool), двух коллекциях и все остальное, производное от них (Vector, String, ...) и все это на рантаймовых рельсах. А скриптовый язык GDScript только внешне похож на питон, но по поведению ближе к плюсам.
Так что да, шаблоны не нужны, только необходимый минимум.
На самом деле я знаю почему, но я не согласен с сообществом godot по поводу STL.
А теперь по порядку. Отладочные символы. Основная претензия сообщества Godot - STL их раздувает сильно. Что бы вы понимали, даже игровой редактор движка весит меньше ста мегабайт.
По поводу шаблонов. Их используют, но ограниченно, просто что бы код был читабельным. Основная претензия, что бы код не был похож на шаблонную вермишель как у буста или другого игрового движка О3DE.
Движком использует под капотом шаблоны, но по минимуму. Там пишут код такой, что бы он был максимально понятным, простым и человеко-читабельным. Т.е. например шаблонный контейнер - да, хэшмап - да, вариант - да.
Шаблон ради шаблона - нет. Глубокие шаблоны, в шаблонах, с авто на шаблонах - нет.
К сожалению, там со времен Godot 2 тянутся макросы, который я бы как раз таки, заменил бы на constexpr шаблоны.
ERR_FAIL_COND_MSG((int64_t) p_width * (int64_t) p_height > (int64_t) MAX_PIXELS, "Too many pixels for image, maximum is " + itos(MAX_PIXELS));
А под Armv7 или сборка с флагом scons bits=32 как прикажете?
Все макросы ERR_COND и прочее - это по сути заглушки для рантайма, в режиме редактора и отладки. На релизе, эти макросы превращаются в тыкву (комментарий)
Исправить код не составит труда, достаточно заменить вызов memcpy на std::uninitialized_copy:
И вот тут вы погорели! Если открыть документацию к движку - жесткое требование - никакого STL и внешних зависимостей. Такой пул реквест не примут просто из за наличия STL. Если и решать проблему, то самописной реализацией uninitialized_copy
Я не знаю почему, но хуан очень не любит STL, Boost и шаблоны вложенностью больше чем один уровень. Если приглядется, можно увидеть, что шаблонов в движке мало и они самые поверхностные, покрывающие простейшие контейнеры с упорядоченной памятью, все остальное крутится во круг обьекта Variant
переход на gdscript занимает считанные дни. Встроенный редактор вполне хватает что бы кодить чо угодно. А вот на C# писать крайне не удобно под Godot как по мне и занимает не прилично много времени.
Основная проблема отвыкнуть от EC системы в пользу NodeTree и агрегации узлов. Многие тянут старые привычки и получаем нелепые гайды. См. каналы GDQuest и pigdev для ознакомления. Недельки под чипсы хватит, что бы освоить 90% нужного тебе функционала.
Если все внезапно уйдут из Chrome, то какой нибудь хитрый еврей возьмет и заткнет образовавшейся нишу своим плагином/расширением и после этого adGuard и другим будет уже сложно вернуться.
Спрос есть и кто-то этот спрос будет удовлетворять. А со всем миром ты не договоришься.
По поводу повестки. Если игнорировать окно создания персонажа и БИ направленность всех сопартийцев, то я не увидел в игре нигде повестки. Из агрессивных женских персонажей, это Гиты да дроу Лоуситы:
Гитиянка - которая тебя за дерьмо считает не потому ты мужчина, а потому что они себя считают высшей расой и ТС просто не встречался с ее соплеменниками мужского пола. Лазирель покажется вам солнышком на фоне отбитоски и ЧСВшности ее соплименников.
Дроу Лосситы - у них в культуре прописано - "боготворить женщин" и у них как бы по лору Матриархат лютейший, при этом ТС забывает, что Матриархат Лосс - это зло, плохо и фу-фу-фу. А вот как раз таки дроу Элистри против Матриархата и прочей дичи. Эти вообще за то что бы бегать голыми по лесам и заниматься ксенофилией в массовых оргиях под серинады фей.
Повестки такой как описал ТС я не обнаружил. +- все по лору, при том лору классическому. Я даже больше скажу, в роще Друидов анти-повестка. Там как всегда, женщины косячат, а потом приходят мужики и все делают как надо. Да и в целом если внимательно приглядется, там часто такие ситуации когда мужики исправляют косяки за женщинами.
По поводу системы дайса. Если честно, дайс он чисто там для вида, этот кубик. Он от любой процентной системы отличается тем, что у нас есть гарантировано 5% на успех и 5% на провал. (по факту в Fallout 1|2 аналогичная проблема пяти процентов) Мне система понравилась даже больше, чем система в первом Divinity OS. Поменяй дайсик с д20 на д100 или д1000, в целом особо не поменяется, просто плавающая точка в цифрах не будет округлена и добавит больше дискретности. (в игре есть опция, "кармический дайс", для не любителей рандома)
Плюс пятая редакция ДнД хороша тем, что скачек прогресса чувствует очень ярко почти на каждом уровне и нету этих синтетических промежуточных уровней, как свойственно многим компьютерным РПГ.
Плюс игра тебя не плохо так поощряет если ты косячишь и у тебя не получается все так, как ты задумал. Рандом вносит нужный хаос
Лор: Я очень давно вожу ДнД и играю в ДнД и очень хорошо знаю лор. И да, я вижу как пытаются протолкнуть повестку в лор. Но если брать строго лор, а не систему, то открыв тот же нисхождение в авернус, драконий куш, гнев штормового великана, подземелье безумного мага и т.д., то там анти-повесткой, расизмом, сексизмом и т.д. пропитаны практически все страницы официальных модулей.
Хватит мыслить типичными шаблонами. _process - это не игровой цикл. Это игровой кадр, при том кадр отрисовки. Не надо забивать в него все что можно. Для ввода есть _input* асинхронные функции. _physics_process - это кадр физики, и завязан на физическом интервале, используй его для движения и логики, если асинхронно это сделать не возможно.
Не надо задавать имя Main. Годот асинхронен и каждый объект есть автономная подсцена. Не надо пытаться выделить God Object который будет отвечать за все.
Контроль управления написан ужасно и используется старая практика, которой придерживались новички еще со времён godot 2
У игры есть методы Input.get_action_strength() Он возвращает числе в диапазоне 0.0-1.0 в зависимости от силы нажатия. (работает как со стиками, так и с кнопками) А есть так же Input.get_vector Который возвращает 2Д вектор. В него ты передаешь силы нажатия left, right, forward, back. В итоге в место лютой писанины, весь твой код уместится в 5-8 строк. А не бессмысленная писанина match конструкций и if else блоков.
В офф документации говорится, что не надо вращать объекты в ручную в 3Д. Есть методы look_at, всегда можно использовать вспомогательный узел и что-то еще, чем полотно векторов вращения, которые работают по принципу эйлера. rotation и rotation_degrees нужны в основном для работы в инспекторе, логику же писать через базисы и transform лучше.
Так же весь интерфейс написан не правильно. Твой интерфейс не учитывает адаптивность мониторов. Ты не использовал якоря, хотя они есть в любом объекте типа Control. UI лучше вынести в отдельный CavansLayer узел, а не вставлять их в 3Д узел как дочерний элемент.
Логика персонажа в идеале должна быть внутри отдельного объекта, а лучше в KinematicBody. Реализовывается логика в 10-20 строчек, полностью кинематическое тело с физикой, столкновениями и т.д.
Я это веду все к тому, что вы своим примером подаете ОЧЕНЬ ПЛОХУЮ ПРАКТИКУ! А потом я каждый день объясняю людям, что так делать не надо. Каждый день люди совершают одни и те же ошибки, не придерживаются хорошим практикам, которые описаны в официальной документации. Смотрят устаревшие гайды от людей, которые не разобрались в инструменте и учат этому других.
Советую ознакомится с этим каналом. И видео которое откроет глаза на более лучшие практики. (Гайд писался под более старую версию движка, так что там может не быть get_vector)
Архитектором игровых механик если честно гайд и не пахнет. Зато тонна антипаттернов. Вы лучше пишите гайды связанные с дизайном игровых механик и то, с чем связана ваша профессия. А кодинг, оптимизацию оставьте специалистам. Вы не представляете сколько раз я людям объяснял, что так делать не надо. Но каждый день в дискорд и другие группы влетают люди, что начитались и насмотрелись гайдов от соочесетвенников, особенно те что перелезли с Unity и тянут от туда даже стиль написания кода.
Unity — Godot Engine, Construct, GDevelop, Unreal Engine, Stencyl, Verge3D, UNIGINE. Юнити начал блокировать всех русских пользователей или отказывать продавать расширенные лицензии для комерсов?
JetBrains — VSCodium, Eclipse, Atom, Notepad++, NetBeans. Каким образом Нотепад может заменить джетБреанс? Это как Вим настраивать в полноценную IDE
Если union не нужен, то почему почти в каждом игровом движке, даже на C++17, они пишут самодельную реализацию Variant типа, под капотом которого union, а не шаблон c new? Или интерпретаторы с универсальными типами?
Когда писал свой движок, у меня только интерпретатор рантайм-скриптов весил over 20mb.
А когда взял исходник готового движка, того же acid или godot engine, выходной инарник выходил меньше и шустрее.
Как по мне, самодельный движок нужен только, и только, если задача к игре стоит специфичная. Например воксельная механика или в рантайме очень быстро сплитить меши, или еще какая нибудь не стандартная задача, тип не эфклидовой геометрии..
да господи, опять вы за свое. Вы же понимаете, что NFT и токен, становится дополнительной точкой отказа? При том точка отказа такая, что придется государству всю сеть накрывать и форкать ее при каждом косяке. Ах да, эти самые токены - просто набор метаданных, даже не уникальных. Я могу создать условную монализу или работу бенкси, залить их на свой сервер и выпустить сой токен, на который возможно кто-то даже поведется.
В итоге все эти ваши картинки и художественные работы хранятся где то, а не самом блокчейне.
А хотите что бы NFT сто процентов запретили? - Начните заливать токеныв метаданные которых будут с номерами кредитных карт или паспортами.
Какие то костыльные решения, когда за нас уже все придумали.
Современные движки чаще всего имеют отдельно рендерный ФПС, отдельной, фиксированный ФПС, обычно связанный с физикой (Зачем нам считать физику в 600фпс?) и отдельно ФПС ввода.
В нашем случае, ввод - ОБЯЗАТЕЛЬНО надо вытащить из рендерного потока в отдельный поток и делается это очень легко.
Мы создаем поток, в нем крутим луп те же 60 кадров в секунду. Для игр где чувствительность ввода важнее (хотя я заметил, что движки считывают ввода с частотой 24 и 60 ФПС) - крутим 120 или более.
Все это пишем в буффер и в конце игрового кадра, когда буфер прочитан - все обработанные ивенты удаляются и так цикл повторяется.
Пишется это не сложно. При желании - атомарно, т.к. игровой цикл только читает, а цикл ввода - только пишет. Размер буффера обычно у нас на протяжении всей игры не плавает, а всегда один и тот же.
блэкбери никогда не было такого рынка. Блэкбери, это были телефона из разряда "Мы все о них много слышали, но никто их ни разу не покупал"
В США ты мог заметить, что андроидом почти никто вообще не пользуется, а это их мейн-рынок. При этом тебя на андроид там, даже если это флагман за лям, никто даже пытаться гопать не будет. А вот айфоны воруют за милую душу.
Я пишу на C++, C#, ObjC, Swift, Kotlin, Python. И куча всего по мелочи, в том числе шейдеры
Как видно, стек связан с геймдевом и нативной интеграции всякой платформозависимой фигни.
Если честно, мне всех советчиков и адептов Си и С++, не смотря на то, что это по сути мой мейн скилл, хочется послать куда подальше.
Если зайти в исходный код Godot, то в папке modules, core и scene, ты почти с ходу сможешь читать чужой код без документации.
Если зайти в исходный код O3DE, то по одним шаблонам в глубину ты будешь скакать страниц на десять в глубину, что бы понять, что делает та или иная строчка.
Ну и движок рантаймовый.
Т.е. вся игровая логика базируется на примитивных типах (int, float, bool), двух коллекциях и все остальное, производное от них (Vector, String, ...) и все это на рантаймовых рельсах. А скриптовый язык GDScript только внешне похож на питон, но по поведению ближе к плюсам.
Так что да, шаблоны не нужны, только необходимый минимум.
у них stl используется в потоках и в thirdparty, которая является по сути набором форков сторонних либ.
я вас обманул =)
На самом деле я знаю почему, но я не согласен с сообществом godot по поводу STL.
А теперь по порядку.
Отладочные символы. Основная претензия сообщества Godot - STL их раздувает сильно. Что бы вы понимали, даже игровой редактор движка весит меньше ста мегабайт.
По поводу шаблонов. Их используют, но ограниченно, просто что бы код был читабельным. Основная претензия, что бы код не был похож на шаблонную вермишель как у буста или другого игрового движка О3DE.
Движком использует под капотом шаблоны, но по минимуму. Там пишут код такой, что бы он был максимально понятным, простым и человеко-читабельным. Т.е. например шаблонный контейнер - да, хэшмап - да, вариант - да.
Шаблон ради шаблона - нет. Глубокие шаблоны, в шаблонах, с авто на шаблонах - нет.
К сожалению, там со времен Godot 2 тянутся макросы, который я бы как раз таки, заменил бы на constexpr шаблоны.
А под Armv7 или сборка с флагом scons bits=32 как прикажете?
Все макросы ERR_COND и прочее - это по сути заглушки для рантайма, в режиме редактора и отладки. На релизе, эти макросы превращаются в тыкву (комментарий)
И вот тут вы погорели! Если открыть документацию к движку - жесткое требование - никакого STL и внешних зависимостей. Такой пул реквест не примут просто из за наличия STL. Если и решать проблему, то самописной реализацией uninitialized_copy
Я не знаю почему, но хуан очень не любит STL, Boost и шаблоны вложенностью больше чем один уровень. Если приглядется, можно увидеть, что шаблонов в движке мало и они самые поверхностные, покрывающие простейшие контейнеры с упорядоченной памятью, все остальное крутится во круг обьекта Variant
переход на gdscript занимает считанные дни. Встроенный редактор вполне хватает что бы кодить чо угодно.
А вот на C# писать крайне не удобно под Godot как по мне и занимает не прилично много времени.
Основная проблема отвыкнуть от EC системы в пользу NodeTree и агрегации узлов. Многие тянут старые привычки и получаем нелепые гайды.
См. каналы GDQuest и pigdev для ознакомления. Недельки под чипсы хватит, что бы освоить 90% нужного тебе функционала.
Там вроде бы MIT. Бери и юзай.
Движок не плох. Конечно все ассеты придется ручками переносить. Но не такая проблема как по мне.
для всех, это для кого?
Если все внезапно уйдут из Chrome, то какой нибудь хитрый еврей возьмет и заткнет образовавшейся нишу своим плагином/расширением и после этого adGuard и другим будет уже сложно вернуться.
Спрос есть и кто-то этот спрос будет удовлетворять. А со всем миром ты не договоришься.
По поводу повестки. Если игнорировать окно создания персонажа и БИ направленность всех сопартийцев, то я не увидел в игре нигде повестки. Из агрессивных женских персонажей, это Гиты да дроу Лоуситы:
Гитиянка - которая тебя за дерьмо считает не потому ты мужчина, а потому что они себя считают высшей расой и ТС просто не встречался с ее соплеменниками мужского пола. Лазирель покажется вам солнышком на фоне отбитоски и ЧСВшности ее соплименников.
Дроу Лосситы - у них в культуре прописано - "боготворить женщин" и у них как бы по лору Матриархат лютейший, при этом ТС забывает, что Матриархат Лосс - это зло, плохо и фу-фу-фу. А вот как раз таки дроу Элистри против Матриархата и прочей дичи. Эти вообще за то что бы бегать голыми по лесам и заниматься ксенофилией в массовых оргиях под серинады фей.
Повестки такой как описал ТС я не обнаружил. +- все по лору, при том лору классическому. Я даже больше скажу, в роще Друидов анти-повестка. Там как всегда, женщины косячат, а потом приходят мужики и все делают как надо. Да и в целом если внимательно приглядется, там часто такие ситуации когда мужики исправляют косяки за женщинами.
По поводу системы дайса. Если честно, дайс он чисто там для вида, этот кубик. Он от любой процентной системы отличается тем, что у нас есть гарантировано 5% на успех и 5% на провал. (по факту в Fallout 1|2 аналогичная проблема пяти процентов) Мне система понравилась даже больше, чем система в первом Divinity OS. Поменяй дайсик с д20 на д100 или д1000, в целом особо не поменяется, просто плавающая точка в цифрах не будет округлена и добавит больше дискретности. (в игре есть опция, "кармический дайс", для не любителей рандома)
Плюс пятая редакция ДнД хороша тем, что скачек прогресса чувствует очень ярко почти на каждом уровне и нету этих синтетических промежуточных уровней, как свойственно многим компьютерным РПГ.
Плюс игра тебя не плохо так поощряет если ты косячишь и у тебя не получается все так, как ты задумал. Рандом вносит нужный хаос
Лор:
Я очень давно вожу ДнД и играю в ДнД и очень хорошо знаю лор. И да, я вижу как пытаются протолкнуть повестку в лор. Но если брать строго лор, а не систему, то открыв тот же нисхождение в авернус, драконий куш, гнев штормового великана, подземелье безумного мага и т.д., то там анти-повесткой, расизмом, сексизмом и т.д. пропитаны практически все страницы официальных модулей.
Если честно, ТС очень вредные советы и гайды писал по Godot. А статью которую удалили - похожа на бред кислотника.
Хватит мыслить типичными шаблонами.
_process - это не игровой цикл. Это игровой кадр, при том кадр отрисовки. Не надо забивать в него все что можно. Для ввода есть _input* асинхронные функции.
_physics_process - это кадр физики, и завязан на физическом интервале, используй его для движения и логики, если асинхронно это сделать не возможно.
Не надо задавать имя Main. Годот асинхронен и каждый объект есть автономная подсцена. Не надо пытаться выделить God Object который будет отвечать за все.
Контроль управления написан ужасно и используется старая практика, которой придерживались новички еще со времён godot 2
У игры есть методы
Input.get_action_strength()Он возвращает числе в диапазоне 0.0-1.0 в зависимости от силы нажатия. (работает как со стиками, так и с кнопками)
А есть так же
Input.get_vectorКоторый возвращает 2Д вектор. В него ты передаешь силы нажатия left, right, forward, back.
В итоге в место лютой писанины, весь твой код уместится в 5-8 строк.
А не бессмысленная писанина match конструкций и if else блоков.
Вот решение большей части твоего кода:
В офф документации говорится, что не надо вращать объекты в ручную в 3Д. Есть методы look_at, всегда можно использовать вспомогательный узел и что-то еще, чем полотно векторов вращения, которые работают по принципу эйлера. rotation и rotation_degrees нужны в основном для работы в инспекторе, логику же писать через базисы и transform лучше.
Так же весь интерфейс написан не правильно.
Твой интерфейс не учитывает адаптивность мониторов. Ты не использовал якоря, хотя они есть в любом объекте типа Control. UI лучше вынести в отдельный CavansLayer узел, а не вставлять их в 3Д узел как дочерний элемент.
Логика персонажа в идеале должна быть внутри отдельного объекта, а лучше в KinematicBody. Реализовывается логика в 10-20 строчек, полностью кинематическое тело с физикой, столкновениями и т.д.
Я это веду все к тому, что вы своим примером подаете ОЧЕНЬ ПЛОХУЮ ПРАКТИКУ!
А потом я каждый день объясняю людям, что так делать не надо. Каждый день люди совершают одни и те же ошибки, не придерживаются хорошим практикам, которые описаны в официальной документации. Смотрят устаревшие гайды от людей, которые не разобрались в инструменте и учат этому других.
Советую ознакомится с этим каналом. И видео которое откроет глаза на более лучшие практики.
(Гайд писался под более старую версию движка, так что там может не быть get_vector)
Архитектором игровых механик если честно гайд и не пахнет. Зато тонна антипаттернов. Вы лучше пишите гайды связанные с дизайном игровых механик и то, с чем связана ваша профессия. А кодинг, оптимизацию оставьте специалистам.
Вы не представляете сколько раз я людям объяснял, что так делать не надо. Но каждый день в дискорд и другие группы влетают люди, что начитались и насмотрелись гайдов от соочесетвенников, особенно те что перелезли с Unity и тянут от туда даже стиль написания кода.
Unity — Godot Engine, Construct, GDevelop, Unreal Engine, Stencyl, Verge3D, UNIGINE.
Юнити начал блокировать всех русских пользователей или отказывать продавать расширенные лицензии для комерсов?
JetBrains — VSCodium, Eclipse,
Atom, Notepad++, NetBeans.Каким образом Нотепад может заменить джетБреанс? Это как Вим настраивать в полноценную IDE
Если union не нужен, то почему почти в каждом игровом движке, даже на C++17, они пишут самодельную реализацию Variant типа, под капотом которого union, а не шаблон c new? Или интерпретаторы с универсальными типами?
судя по фото, во что превратились колеса Кьюриосити, мне кажется он переломает себя раньше)
а сколько весит билд со сценой без ассетов?
Когда писал свой движок, у меня только интерпретатор рантайм-скриптов весил over 20mb.
А когда взял исходник готового движка, того же acid или godot engine, выходной инарник выходил меньше и шустрее.
Как по мне, самодельный движок нужен только, и только, если задача к игре стоит специфичная.
Например воксельная механика или в рантайме очень быстро сплитить меши, или еще какая нибудь не стандартная задача, тип не эфклидовой геометрии..
да господи, опять вы за свое. Вы же понимаете, что NFT и токен, становится дополнительной точкой отказа? При том точка отказа такая, что придется государству всю сеть накрывать и форкать ее при каждом косяке. Ах да, эти самые токены - просто набор метаданных, даже не уникальных. Я могу создать условную монализу или работу бенкси, залить их на свой сервер и выпустить сой токен, на который возможно кто-то даже поведется.
В итоге все эти ваши картинки и художественные работы хранятся где то, а не самом блокчейне.
А хотите что бы NFT сто процентов запретили? - Начните заливать токеныв метаданные которых будут с номерами кредитных карт или паспортами.