В РФ есть коммерческая тайна. Но у нас НИКТО не умеет ею пользоваться. Нельзя навесить человеку комм-тайну типо по ЗП или по собесу. Это против ТК РФ. (на хабре есть статья про коммерческую тайну)
У меня в трудовой Самозанятый. До этого - контрибьютил на гитхабе и скакал по инди-проектам. Найти мое имя можно в финальных титрах некоторых играх.
В итоге ты пропустишь кандидата, который и движок знает как два пальца и его исходник и имеющий РЕАЛЬНЫЙ опыт в геймдеве, а не дутый у скилбокса. Но у него в трудовой пропуск почти в 10 лет и замозанятый со стажем всего пару лет.
Как человек, который уже наверное лет 15 в IT. От сисадмина до человека, который раньше C++11/14 почти наизусть знал, включая STL, и уже 7ой год работаю чисто в игровой разработке и разработке игрового движка с применением такой россыпи кроссплатформенного кода и языков, что проще перечислить на чем не пишу.
Я не в состоянии сейчас пройти собес на сеньора и даже, наверное, джуна. Спокойно могу под взглядами ментора зависнуть на задачке в духе "Отсортируй строку так-то так, на вхождения в... <миллиард условий>". При этом я на голом hlsl могу написать хитрый шейдер с геометрической магией, ценою О(1).
Так же вопросик есть по сфере. Если мы делаем глаз. Мне кажется проще удалить полюс а то и соседний сегмент с полисом и сделать Fill Grid для зрачка. Тем самым мы получим удобную сетку для радужки и удобную сетку для зрачка.
Знаете, года два-три назад, видел жалобы на пикабу, что владелец какого то портала про аниме, не может понять, что РКН требует удалить с сайта. Т.к. РКН прислал уведомление в духе "Удалите запрещенный контент". А где он, откуда он - не понятно.
Тут мне кажется аналогичная ситуация будет. "Удалите контент, какой - не скажем, хахахаха"
Статья откровенно бесполезная, да. Но вот сотрудники... Они могут быть трижды взрослыми людьми, но попробуй организуй десять подчиненных что-то делать. Это тот еще цирк с конями.
Особенно если у вас задачи не на конвейере, а условно приходит цель "сделай продукт", и ты должен всю команду пинать, что бы они начали что-то делать.
Иначе они с точки мертвой не сдвинуться, пока всем четко не раздашь указания - что делать.
И стоит тебе отвернуться хотя бы на секунду, как они или сами себе задачи начнут выдумывать, не оценивая сложность работы и выдумывая фичи, которые нафиг не нужны, либо закрыв таски - перестают что либо делать. В итоге ты как руководитель, держишь всю команду на пульсе, не давая им простаивать и выдумывать себе задачи из воздуха.
Так еще и весь пайплайн разработки продукта должен знать в голове, иначе в уши нассут, сами того не осознавая, потому что дизайнер говорит А, программист Б, оба друг от друга чего то хотят, а проблема решается за минуту.
Какие то костыльные решения, когда за нас уже все придумали.
Современные движки чаще всего имеют отдельно рендерный ФПС, отдельной, фиксированный ФПС, обычно связанный с физикой (Зачем нам считать физику в 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% нужного тебе функционала.
5 годиков, сеньер... хренасебе...
За 5 годиков, ты только освоишь бизнесс процессы и конкретный пайплайн разработки.
А обширность специализации конкретного стека за 5 годиков ты только поверхностно знать будешь. А фундаментально - нет.
Это как С++20 сеньеры, которые не умеют жонглировать указателями
Всегда ору с этого. Если ты не в сговоре со своим начальником - не вижу проблем всем сообщить. Хоть 100500 НДА подписано.
NDA не работает в РФ.
В РФ есть коммерческая тайна.
Но у нас НИКТО не умеет ею пользоваться. Нельзя навесить человеку комм-тайну типо по ЗП или по собесу. Это против ТК РФ. (на хабре есть статья про коммерческую тайну)
Трудовая - вот вообще не показатель.
У меня в трудовой Самозанятый.
До этого - контрибьютил на гитхабе и скакал по инди-проектам.
Найти мое имя можно в финальных титрах некоторых играх.
В итоге ты пропустишь кандидата, который и движок знает как два пальца и его исходник и имеющий РЕАЛЬНЫЙ опыт в геймдеве, а не дутый у скилбокса. Но у него в трудовой пропуск почти в 10 лет и замозанятый со стажем всего пару лет.
Когда у тебя в бизнесе всего одна такая курица, а больше куриц нету - всегда есть риск, что курицу сожрет лиса.
По этому надо иметь несколько куриц и не зависеть от них.
Это плохой бизнес, который держится на одном кадре.
Как человек, который уже наверное лет 15 в IT. От сисадмина до человека, который раньше C++11/14 почти наизусть знал, включая STL, и уже 7ой год работаю чисто в игровой разработке и разработке игрового движка с применением такой россыпи кроссплатформенного кода и языков, что проще перечислить на чем не пишу.
Я не в состоянии сейчас пройти собес на сеньора и даже, наверное, джуна. Спокойно могу под взглядами ментора зависнуть на задачке в духе "Отсортируй строку так-то так, на вхождения в... <миллиард условий>". При этом я на голом hlsl могу написать хитрый шейдер с геометрической магией, ценою О(1).
Так же вопросик есть по сфере.
Если мы делаем глаз. Мне кажется проще удалить полюс а то и соседний сегмент с полисом и сделать Fill Grid для зрачка. Тем самым мы получим удобную сетку для радужки и удобную сетку для зрачка.
Не представляю, как можно сделать модель без E-Pole. если это гуманойд, врезки или две пересекающейся сферы.
Кольца во круг глаза, рта и носа образуют между собой звезды.
Знаете, года два-три назад, видел жалобы на пикабу, что владелец какого то портала про аниме, не может понять, что РКН требует удалить с сайта. Т.к. РКН прислал уведомление в духе "Удалите запрещенный контент". А где он, откуда он - не понятно.
Тут мне кажется аналогичная ситуация будет. "Удалите контент, какой - не скажем, хахахаха"
Статья откровенно бесполезная, да. Но вот сотрудники... Они могут быть трижды взрослыми людьми, но попробуй организуй десять подчиненных что-то делать. Это тот еще цирк с конями.
Особенно если у вас задачи не на конвейере, а условно приходит цель "сделай продукт", и ты должен всю команду пинать, что бы они начали что-то делать.
Иначе они с точки мертвой не сдвинуться, пока всем четко не раздашь указания - что делать.
И стоит тебе отвернуться хотя бы на секунду, как они или сами себе задачи начнут выдумывать, не оценивая сложность работы и выдумывая фичи, которые нафиг не нужны, либо закрыв таски - перестают что либо делать. В итоге ты как руководитель, держишь всю команду на пульсе, не давая им простаивать и выдумывать себе задачи из воздуха.
Так еще и весь пайплайн разработки продукта должен знать в голове, иначе в уши нассут, сами того не осознавая, потому что дизайнер говорит А, программист Б, оба друг от друга чего то хотят, а проблема решается за минуту.
Какие то костыльные решения, когда за нас уже все придумали.
Современные движки чаще всего имеют отдельно рендерный ФПС, отдельной, фиксированный ФПС, обычно связанный с физикой (Зачем нам считать физику в 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% нужного тебе функционала.