Что за бред, в играх на iOS значит я могу пару гигабайт ассетов упаковать в бандлы и скачать в рантайме в дополнение к основному бинарнику, включая кстати локализацию. А Google в почтовом клиенте не может, из за "особенностей ОС".
Ну так а будь вы на месте собственника компании или топ менеджера с долей в ней, вы бы не вспомнили о духе команды? :) О практиках управления ж не линейные сотрудники рассказывают))
Да знаю, точно есть - например в ВТБ, Иннотехе, ВК. Где-то лично сталкивался, где-то друзья HR-ы рассказывали. Но это все во первых не то чтобы законно. Во вторых опять же направлено на защиту интересов компании (собственников). Хотя стоит признать - будь я учредителем компании вполне возможно действовал так же. Так все опять же сводится к тому что свой капитал (своя жопа) ближе. А дальше вопрос компромиссов и рынка.
Что за бред - предупреждать компанию о собесах? Компания на пенсии тебе содержать не будет и капитал сколотить не поможет. Компания это не друг. Взаимовыгодное сотрудничество - да. Ситуативный партнер - да. Но в капиталистическом строе - свой капитал априори важнее капитала собственников компании.
Анализ зависимостей и растаскивание иерархий хедеров позволило сэкономить три минуты, время сборки проекта стало 11:25с. На всю эту работу, протаскивание этих задач через таски ушло пару месяцев рабочего времени, проект большой, за раз все не починишь, плюс приходится согласовывать свои изменения с другими командами.
А оно того стоило, с точки зрения бизнеса? Обычно при таком соотношении трудозатрат/оптимизации просто ставят железку помощнее для билд агента. Получается дешевле чем стоимость работы программиста.
Я конечно понимаю что билдов собирается довольно много, особое если проект ААА. У нас на небольшом мобильном игровом проекте может до нескольких десятков сборок собираться в течении для. Но все таки - пару месяцев работы ради 3х минут сборки, кажется чересчур.
Ну тут нет серебряной пули, процессы подбираются под команду а не наоборот :)
Я не сторонник процессов ради процессов. Если у вас слаженная команда и для выполнения задач хватает лишь общений программист-тимлид, то пускай так и работает :) Главное в конечном итоге готовый рабочий продукт, а не способ которым вы его сделали.
Но попробуйте уместить всю вашу логику в 15мс, с обработкой четырехсот NPC на уровне, физики, музыки, рендером на экран без просадок фпс.
Во первых рефлексия это всегда оверхеад как по памяти (аллокации) так и по лишним операциям на цпу.
Современные DI под юнити, например Zenject https://github.com/modesttree/Zenject широко используют помимо рефлексии еще LINQ. Что тоже добавляет лишних аллокаций. Тут стоит заметить что garbage collector для игр - это в большинстве случаев плохо, а не хорошо. На одном из проектов где мы широко использовали Zenject - у нас доходило до 100 mb аллокаций на старте сцены, что бы построить дерево объектов.
Но допустим вы решили написать свои DI и заморочились и оптимизировали эти вещи. Остается на мой взгляд основная концептуальная проблема: когда я как программист хочу создать некий IObject - я никогда не знаю, насколько больше поддерево объектов породит мне DI. И какие именно реализации забинденны к интерфейсам.
Особенно если инъекция происходит не в конструкторе класса а в какие-то его поля.
В итоге создание с первого взгляда безобидного объекта в памяти могло породить очень большее количество аллокаций.
Но тут я наверное не совсем корректно выразился, DI как концепция ок. Проблема в контейнерах которые скрывают зависимости. Сейчас я стараюсь использовать концепцию Poor Man's DI в проектах - когда зависимости классов явно определены в конструкторах, а дерево объектов объявлено явно и собирается руками в контекстах.
Ну и опять же даже такие вещи делаются в основном не для highload кода. Так как в highload коде бывает приходится порой избавляться даже виртуальных вызовов (прощай классическое ООП), заниматься оптимизацией данных под кэш цпу (привет ECS), SIMD и т.п....
Любопытная статья. Не могу согласиться с автором во всем. Сам уже больше 10 лет в геймдеве.
Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.
Да и если попробуете найти инвесторов и организовать свой проект/студию - статистика не на вашей стороне. Очень много проектов закрывается не окупив себя. Особенно последний год. Хотя редко - но может выстрелить очень громко (тот же Minecraft)
Кранчи тоже ситуативно - в некоторых компаниях их прям любят, в некоторых нет.
По поводу влияния на дизайн - у меня прям противоположный опыт, программисты всегда участвуют в процессе разработки самой игры, помогают геймдизам, вносят свои решения. Да, финальное слово обычно за продюсером. Но на моем опыте, очень часто хорошие идеи по гейм.дизайну приносили именно программисты.
Gamedev-мир отстает от "большого IT" - вот тут я бы вообще поспорил. Много гейм.девных решений было бы неплохо затащить в "большой IT". Тот же Data oriented design. А то что тащат сейчас в гейм.дев из энтерпрайса - лучше бы не тащили. За те же модные DI в Unity нужно по рукам бить.
Маленький уютный мирок - вот тут полностью согласен. Компаний не так много, а геймдев в России, по понятным причинам, умер. Так что нужно быть готовым к релокации.
Обыкновенная ситуация, когда программист в принципе ни с кем не обсуждает кроме лида свою фичу по несколько недель, а потом выкатывает в репо сотню-другую комитов, нанося добро всем подряд и блокируя работу студии, хорошо если на пару дней, пока все баги не выловят в аврале.
Ну у них есть десктопное приложение, могли бы при желании в нем сделать. У них изначально как раз в десктопном приложении можно было установить color space монитора, а в вебе только sRGB.
Используем figma для дизайна UI в геймдеве (Unity, Unreal), года два назад писали большой запрос в figma по поддержке Linear color space. Так как весь современный гейм.дев на нем сидит. Так и не сделали :(
В “нашем” представлении руку к коду игры придется прикладывать везде и часто.
Честно говоря, очень странное представление о работе СТО в таких компаниях. Сам в геймдеве уже больше 9 лет, и на практике, уже на уровне лида с командой из 4-5 программистов, на написание кода остается меньше 10% времени.
Если же СТО садится писать код, то в процессах такой компании, на мой взгляд, такой бардак, что от туда нужно бежать как можно скорее. (Ну или это совсем небольшой стартап где каждый человек совмещает по несколько позиций)
У нас есть инструмент по генерации сцен разного уровня качеств. Художники работают в Source сцене, которая так же является сценой максимального качества (содержит все типы пропсов). Художники или тех.артисты размечают к какому качеству относятся пропсы и на основе этих данных мы генерируем _Hd, _LD и _ULD сцены. Эти сцены в дальнейшем пакуются в бандлы. В зависимости от выбранного на девайсе качества мы грузим нужный бандл сцены.
Что за бред, в играх на iOS значит я могу пару гигабайт ассетов упаковать в бандлы и скачать в рантайме в дополнение к основному бинарнику, включая кстати локализацию. А Google в почтовом клиенте не может, из за "особенностей ОС".
А где вариант "Я — участник инновационной команды в большом интерпрайзе, но процессы нам не мешают" ?
Ну так а будь вы на месте собственника компании или топ менеджера с долей в ней, вы бы не вспомнили о духе команды? :) О практиках управления ж не линейные сотрудники рассказывают))
Да знаю, точно есть - например в ВТБ, Иннотехе, ВК. Где-то лично сталкивался, где-то друзья HR-ы рассказывали. Но это все во первых не то чтобы законно. Во вторых опять же направлено на защиту интересов компании (собственников). Хотя стоит признать - будь я учредителем компании вполне возможно действовал так же. Так все опять же сводится к тому что свой капитал (своя жопа) ближе. А дальше вопрос компромиссов и рынка.
Что за бред - предупреждать компанию о собесах? Компания на пенсии тебе содержать не будет и капитал сколотить не поможет. Компания это не друг. Взаимовыгодное сотрудничество - да. Ситуативный партнер - да. Но в капиталистическом строе - свой капитал априори важнее капитала собственников компании.
А оно того стоило, с точки зрения бизнеса? Обычно при таком соотношении трудозатрат/оптимизации просто ставят железку помощнее для билд агента. Получается дешевле чем стоимость работы программиста.
Я конечно понимаю что билдов собирается довольно много, особое если проект ААА. У нас на небольшом мобильном игровом проекте может до нескольких десятков сборок собираться в течении для. Но все таки - пару месяцев работы ради 3х минут сборки, кажется чересчур.
Owlcat Games уже давно на Кипр переехали, каким боком это российская студия?
Mundfish - тоже. Руско-язычные студии - да, российские - нет.
"Так что российский геймдев жив и продолжает удивлять пользователей."
Российский гейм. дев мертв.
Перестал читать после фразы:
Автор явно ничего серьезного на Unity не разрабатывал...
Ну тут нет серебряной пули, процессы подбираются под команду а не наоборот :)
Я не сторонник процессов ради процессов. Если у вас слаженная команда и для выполнения задач хватает лишь общений программист-тимлид, то пускай так и работает :) Главное в конечном итоге готовый рабочий продукт, а не способ которым вы его сделали.
Все в целом сводится к фразе автора:
Во первых рефлексия это всегда оверхеад как по памяти (аллокации) так и по лишним операциям на цпу.
Современные DI под юнити, например Zenject https://github.com/modesttree/Zenject широко используют помимо рефлексии еще LINQ. Что тоже добавляет лишних аллокаций. Тут стоит заметить что garbage collector для игр - это в большинстве случаев плохо, а не хорошо. На одном из проектов где мы широко использовали Zenject - у нас доходило до 100 mb аллокаций на старте сцены, что бы построить дерево объектов.
Но допустим вы решили написать свои DI и заморочились и оптимизировали эти вещи. Остается на мой взгляд основная концептуальная проблема: когда я как программист хочу создать некий IObject - я никогда не знаю, насколько больше поддерево объектов породит мне DI. И какие именно реализации забинденны к интерфейсам.
Особенно если инъекция происходит не в конструкторе класса а в какие-то его поля.
В итоге создание с первого взгляда безобидного объекта в памяти могло породить очень большее количество аллокаций.
Но тут я наверное не совсем корректно выразился, DI как концепция ок. Проблема в контейнерах которые скрывают зависимости. Сейчас я стараюсь использовать концепцию Poor Man's DI в проектах - когда зависимости классов явно определены в конструкторах, а дерево объектов объявлено явно и собирается руками в контекстах.
Ну и опять же даже такие вещи делаются в основном не для highload кода. Так как в highload коде бывает приходится порой избавляться даже виртуальных вызовов (прощай классическое ООП), заниматься оптимизацией данных под кэш цпу (привет ECS), SIMD и т.п....
Любопытная статья. Не могу согласиться с автором во всем. Сам уже больше 10 лет в геймдеве.
Зарплаты - да средние по рынку, но найти компанию с достойной оплатой в целом реально. Хотя золотых гор вы тут не получите в найме.
Да и если попробуете найти инвесторов и организовать свой проект/студию - статистика не на вашей стороне. Очень много проектов закрывается не окупив себя. Особенно последний год. Хотя редко - но может выстрелить очень громко (тот же Minecraft)
Кранчи тоже ситуативно - в некоторых компаниях их прям любят, в некоторых нет.
По поводу влияния на дизайн - у меня прям противоположный опыт, программисты всегда участвуют в процессе разработки самой игры, помогают геймдизам, вносят свои решения. Да, финальное слово обычно за продюсером. Но на моем опыте, очень часто хорошие идеи по гейм.дизайну приносили именно программисты.
Gamedev-мир отстает от "большого IT" - вот тут я бы вообще поспорил. Много гейм.девных решений было бы неплохо затащить в "большой IT". Тот же Data oriented design. А то что тащат сейчас в гейм.дев из энтерпрайса - лучше бы не тащили. За те же модные DI в Unity нужно по рукам бить.
Маленький уютный мирок - вот тут полностью согласен. Компаний не так много, а геймдев в России, по понятным причинам, умер. Так что нужно быть готовым к релокации.
Вот тут - зависит от культуры в компании. На свои проектах в текущей компании вводил практики дизайн-ревью (https://youtu.be/4Y0XJXRZv6k https://youtu.be/IDj3x__YZgE)
и обсуждений задач в Slack/на созвонах. И есть культура и инструменты шаринга знаний между разными проектами...
Ну вот как-то совсем не коррелирует с моим опытом работы на удаленке. У нас в компании даже исследование небольшое проводили и статью на хабре писали https://habr.com/ru/companies/pixonic/articles/504796/
по факту люди даже больше работали после выхода на удаленку, и их приходилось пинать что бы не перерабатывали
Все еще не понимаю чем им всем удаленка не угодила. Прям повсеместный тренд начался что в западных конторах что в российских.
Ну у них есть десктопное приложение, могли бы при желании в нем сделать. У них изначально как раз в десктопном приложении можно было установить color space монитора, а в вебе только sRGB.
Используем figma для дизайна UI в геймдеве (Unity, Unreal), года два назад писали большой запрос в figma по поддержке Linear color space. Так как весь современный гейм.дев на нем сидит. Так и не сделали :(
Ну собственно в этом и был посыл, если СТО занимается тем что пишет код, вместо налаживания процессов то что-то тут не так.
Дополню автора:
Честно говоря, очень странное представление о работе СТО в таких компаниях. Сам в геймдеве уже больше 9 лет, и на практике, уже на уровне лида с командой из 4-5 программистов, на написание кода остается меньше 10% времени.
Если же СТО садится писать код, то в процессах такой компании, на мой взгляд, такой бардак, что от туда нужно бежать как можно скорее. (Ну или это совсем небольшой стартап где каждый человек совмещает по несколько позиций)
И больше не в России :) https://habr.com/ru/news/t/705790/