Есть такая беда в геймдеве - кранчи называется. Вообще, они, конечно же, есть в той или иной степени во всей IT индустрии, но вот в геймдеве это считается неотъемлемой частью разработки. Отчасти они происходят из противоречия между сутью игр и способом их разработки. Игры должны быть интересными. Но нет четкого понимания ни у кого, как сделать интересную игру. Однако каждый, от джуна-разработчика до продюсера, считает, что он-то точно знает лучше, как сделать классную игру, он же играет в такое количество классных игр. За все годы, что я работаю в геймдеве, еще ни разу не видел подтверждения этому тезису. Особенно когда речь про разработку крупного проекта со множеством взаимосвязанных систем. Когда со своими супер важными авторитетными пятью копейками в дизайн игры залезает дилетант - получается полное говно. Это вот как ремонтирует вам трубу в сортире сантехник. Смотрите такие - а че он вот зачем эти резинки на трубы ставит, можно же просто поплотнее прикрутить. Если у вас достаточно упертости, вы даже можете убедить сантехника убрать эти резиночки. В конце концов, это же вы ему платите! И довольные собой на следующий день, сев на фаянцевый трон, вы с гордостью нажмете на слив иииии зальете дерьмом всю квартиру. И виноват будет сантехник. Он же профессионал! А я что? Тут вопрос и к сантехнику, и к заказчику. Разработчик - будь то программист или геймдизайнер, всегда должен уметь аргументированно обосновать принятое решение - только тогда он несет полную ответственность за выполненную работу. Если аргументов нет - вы плохой сантехник! Продюсер в тот самый момент, когда, несмотря на все аргументы, бьет кулачком по столу со словами “Я здесь закон”, продавливает свою идею - отбирает ответственность у разработчика. Но на практике почему-то большинство продюсеров отказываются признавать столь очевидный факт. И опускаются до поиска виноватых. “Ой, это геймдизайнеры не так поняли мою идею. Она была классная, а они все испоганили”, “Ой, это программисты не так запрограммировали”, “художники плохо нарисовали”, “тестеры все корнер-кейсы не проверили”. А вывод прост - не надо лезть за границы области своей компетенции. Делайте свою часть работы либо делайте игры в соло. Там у вас будет полный контроль!

Мобильный ад

Часть 1

Планирование - важная часть разработки любого продукта. Нужно определить объем работы, чтобы понять, сколько потребуется землекопов, под это дело выделить бюджет на разработку и наметить план развития.

Конечно же, этот план будет очень примерный, особенно в условиях, когда это первый продукт в компании, а от платформы, на которой предполагается его делать, есть лишь репозиторий на гитхабе. Тем не менее, составлять план работ надо, чтобы потом не пришлось со слезами на глазах выпрашивать дополнительное финансирование у инвесторов, а то и того хуже - бегать как коммивояжер от дома к дому и предлагать поговорить о спасителе нашем Великой Уникальной Нитакой как все Игре или торговать жопой, ой, акциями компании ради возможности поработать еще месяц-другой. Также никто не застрахован от эпик фейла - игра, которую вы делали, вложили всю душу, оказалась никому не нужна. Особенно это актуально для рынка мобильных игр, уж слишком часто меняются предпочтения пользователей. А, учитывая огромный объем рынка - 640 миллиардов зелененьких в год, и количество желающих урвать кусочек сладкого пирожочка неуклонно растет. Поэтому нет у вас 2-3 лет на разработку мобильной игры (если только вы не великий визионер-нострадамус и умеете видеть сквозь пространственно-временной континуум и сможете предсказать, что же будет востребовано через 2-3 года). Поэтому всегда необходимо ограничивать объем игры таким образом, чтобы успеть выпустить ее ну хотя бы за год, в идеале - 6-9 месяцев. Для этого киты индустрии придумали выпускать игры под фейковым брендом - дабы понять актуальность, интересность и монетизируемость на раннем этапе разработки и при этом не засрать узнаваемый бренд сырыми как дырявые труселя ныряльщика за жемчугом продуктами. Выкинули - закупили немного трафика - проанализировали результат - повторить. Параллельно накручиваем фичи, заколачиваем молотком баги и вылизываем внешний вид. В таком режиме, даже если бюджет на разработку закончится - у вас будет продукт, который можно предъявить и который протестирован на живых пользователях. Первый релиз в большинстве случаев можно выкатить уже через месяц разработки: основной минимальный геймплей, минимальный UI и сбор каждого пердежа пользователя. Затем еще 2-3-4 месяца на накидывание контента, расширение геймплея и тестирование рекламы. Кстати, о рекламе. Один из самых дешевых способов понять, будет ли игра хоть кому-то нужна - это фейковая реклама (которой пользуются вообще все) - картинка/видео с демонстрацией желаемого геймплея и стиля игры, при клике на которую ведет в никуда, а большой брат записывает количество переходов. Этим можно заниматься еще до начала разработки игры, чтобы не тратить ресурсы на мертворожденный продукт.

пока строчу вторую часть, вот вам немного травы

Мобильный ад
часть 2
Отвлечемся немного от непосредственно делания игры и поговорим о том, как же выбрать, какую игру делать. Тут есть множество разных подходов и ни одного, который гарантировал бы успех будущей игры.
1) Уникальная снежинка
У вас есть какая-то идея, и вот ни одной хоть отдаленно похожей нет на рынке. Она настолько уникальная, что ее невозможно отнести к одному или нескольким жанрам, там такие механики и уникальный геймплей, что вот из миллионов выпущенных игр ничего похожего просто быть не может. Ведь идея самозародилась сама по себе в недрах вашего уникального разума!
Такое действительно иногда случается, к сожалению, чрезвычайно редко. Самый, пожалуй, яркий пример - Майнкрафт. Игра, которая открыла новый жанр и положила начало целому направлению.
Чаще всего эта самая уникальная идея до сих пор не была реализована, потому что слишком нишевая. Возможно, вы единственный человек, кому она была бы интересна. Возможно, кто-то уже делал что-то подобное и с треском провалился, погиб в пучине алкоголизма вследствие провала. Поэтому всегда проверяйте идею хотя бы на своих друзьях.
2) Кофе с молоком
У меня есть ручка, яблоко и ананас. Собираем несколько жанров/идей, уже успешно реализованных, и делаем что-то новое. Основная проблема такого подхода - это выбрать правильную комбинацию верных ингредиентов. Игроки делятся на категории по способу игры и тому, какие цели они преследуют (о видах игроков поговорим отдельно). И вот не все комбинации жанров могут быть соединены во что-то съедобное. Запихайте в головоломку элементы шутера и отпугнете и любителей шутеров - сложно, непонятно, и любителей головоломок - слишком быстро и стрессово. В идеале брать смежные жанры, а не совсем уж противоположные. Поэтому комбинация Action-RPG так популярна.
3) Покрасить гараж
Тут все просто. Берем то, что уже есть, меняем текстурки, тюнингуем механики и выпускаем. Все крупные студии обычно выбирают этот путь как наиболее безопасный. Известен объем рынка, целевая аудитория, что и как делать. А экспериментами пусть индюки занимаются! Продажи очередного Ассасинс Крида или ГТА не дадут соврать! Ну и каждый год выпускаемые всевозможные симуляторы пинания мяча. Под это дело и инвестора проще найти - все цифры на руках. Вопрос только в реализации. Надо ведь как-то убедить игроков, что ваша игра лучше, чем то, во что они сейчас играют. Хотя есть категория игроков, которые просто потребляют все игры в жанре, чтоб было чем себя занять между обновлениями. Сюда же можно отнести всевозможные одноразовые сюжетки/квесты. Если есть хороший сценарий - это уже половина успеха.
4) Некрогейминг
Достаем из небытия давно умершую игру и делаем такую же, только новую. Тут сложнее, чем в предыдущем варианте, потому что игроки, игравшие в оригинал, уже либо умерли, либо спились. И, как известно, в одну реку нельзя войти дважды, поэтому огребаем риски Уникальной Снежинки, зато имеем предсказуемость процесса разработки. Объем понятен, что и как делать тоже вполне себе ясно. В силу относительной юности мобильного гейминга такой подход скорее применим к консолькам и компьютерам. Подождите, пока из Гневных Птичек выкачают последние соки, затем еще лет 5-10 и можете залетать со своими Гневными Пчелками. История, как известно, циклична.
5) Натянуть сову на глобус
Берем игру с другой платформы и натягиваем на мобилку. Тут может получиться как очень успешно, так и полный провал. Не все механики хорошо ложатся на мобильный гейминг, где у тебя вместо боярских клавиатуры и мышки - пальцы-сосиски. Да и аудитория, играющая в мобилки и на компьютере/консолях, не всегда пересекается. Поэтому даже прямые порты очень успешных игр зачастую оказываются не востребованы..

Микропенисы Микроменеджмент и макрополитика
Бывает так, что человек вырастает до позиции управленца быстрее, чем осознает, что же такое это самое управление. Это может быть стартап, который внезапно выстрелил, или выдающиеся профессиональные навыки и бешеная работоспособность убеждают начальство продвинуть человека по карьерной лестнице. Так или иначе, но вот у вас появляется несколько человек в подчинении, и теперь уже вам надо говорить им, куда плыть и сколько копать. В психологии есть такая штука - называется кризис роста. У детей до года их с десяток, потом кризис 3-х и 4-х лет, еще один, когда ребенок идет в школу, ну и все, думаю, помнят свой подростковый кризис. В каждом таком кризисном периоде сознание, охуевшее от происходящего, пытается вернуться в предыдущее состояние. “Галя, у нас отмена”, ctrl+z, ctrl+z. Вот уже вроде адекватный ребенок 3-х лет начинает истерить как младенец, валяться по полу и в отдельных случаях просить сисю (тут я его могу понять). Из моего опыта возникает ощущение, что и при переходе на роль начальника происходит нечто подобное. От тебя требуют какие-то эстимейты, диаграммы Ганта, планирования релизов, бесконечные совещания. А ты просто хочешь нажимать кнопочки и фиксить баги. И чтобы похвалили, какую классную кнопочку ты запилил в прошлом спринте. Как и у детей, этот кризис через какое-то время проходит, но как и у детей, проходит он не у всех (привет эгоцентрикам и всевозможным инфантилам). И вот когда взрослый дядя (или тетя) в штанишках большого мальчика начинает отбирать задачи у джунов, проверять до пикселя выравнивание каждой кнопочки на форме входа, лично утверждать каждую буковку каждого дизайн документа - это вот и есть оно, микроменеджмент. По сути, это такая форма прокрастинации от страха перед новыми обязанностями и ответственностями, которые на тебя свалились. А напряжение только растет. Любые трудности воспринимаются как вопрос жизни и смерти. Любое решение парализует. Кто-то от того же страха начинает вводить 100500 правил, тратит кучу времени на “построение идеальных процессов”, организует многочасовые совещания и круглые столы, чтобы ну точно убедиться в правильности своих решений. Миллион мух же не может ошибаться? Ну а теперь вопрос: и что делать-то?
Если микроменеджер вы - ну осознание проблемы первый шаг к ее исправлению. Признать, что страшно, понять, что это нормально. Подумать, что пугает больше всего. Начальство или подчиненные догадаются, что вы не соответствуете занимаемой должности? - а кто кроме вас так думает? От того, что у вас ответственность больше, вы другим видом не стали. Они тоже люди и, возможно, так же боятся. А пытаясь отделить себя от остальных, вы кроме раздражения и злости ничего не вызовете. Страшно просрать все полимеры, профукать весь бюджет, оказаться с голой жопой и пойти сосать в переходе за пачку сигарет? Ну, во-первых, вы все еще профессионал в своей области, во-вторых, тратя драгоценные ресурсы на бесполезную работу, вы просрете все намного быстрее. Так что выясняем, каких скиллов не хватает, и закрываем недостающие компетенции книгами, курсами да вебинарами, можно даже с другими людьми поговорить, это не запрещено, честно-честно.

Минутка лицемерия.
Решился я, значит, тут съездить на gamescom. Ну и думаю, можно же от компании попроситься. Написал проджекту, техдиректору и эйчару. Плоская вертикаль ведь у нас. Поэтому, чтобы любой вопрос решить, надо лично к каждому подойти, в жопку поцеловать и разрешения попросить. После чего надо еще официальное письмо написать, 10 человек в копию поставить, а то мало ли! Написал письмо в воскресенье (первый рабочий день недели, если что). Всю неделю ни ответа, ни привета. Эйчар морозится. Сегодня, значит, под конец рабочего дня подзывает меня техлид и такой: ну ты знаешь, мы не можем тебя отправить, так как мы не планировали вообще участие в этой конференции, и вообще это же не техническая конфа, нечего тебе там делать, и вообще ты же уже в прошлом году ездил? Я такой: вообще-то нет, в прошлом году я загран 3 месяца менял. А, ну да, я перепутал, ну в любом случае, пошлем тебя в следующий раз куда-нибудь, обязательно, иншаллах. Тем более у нас тут дедлайны на носу, а так ты два рабочих дня пропустишь! Я такой: ну ладно, окей, чо. Захожу в линкедин и охуеваю… Не, ну я всякое, конечно, видал, но это, конечно, какой-то совершенно новый уровень. В общем, поеду за свой счет все равно, чисто в глаза им посмотреть😀

Технологии курильщика
Часть 1
Поговорили о людях, пора и технологии обсудить. Всё-таки программист я или где?
Развитие движка Unity я наблюдаю ещё с 4 версии. И вот складывается такое ощущение, что компанию изнутри разрывает какая-то техно-шизофрения. И каждая новая крупная фича с трудом вписывается в то, что уже есть. Начиная от GUI: был Unity GUI, потом появился купленный (не самый лучший) uGUI (бывший nGUI), абсолютно меняющий подход к построению GUI и несовместимый с предыдущим, сейчас есть третья итерация, живущая своей жизнью - UIToolkit. Отдельно живёт проект Tiny (и не помер ли он ещё часом?). И вот в далёком 2019 появляется DOTS, переворачивающий процесс разработки с ног на голову. Изначально подход был выбран скорее правильно, чем нет. Ставка на производительность, data-driven, генерация кода, вот это всё. Начал я ковырять DOTS (не путать с дотой) практически с первой публично доступной версии. И даже выпустили АА игру с его использованием для симуляции логики. Ох, сколько я тогда огрёб проблем с моим тогдашним тимлидом. Пришлось записывать обучающие видео, проводить воркшопы, лишь бы человек, тратящий месяц своей работы на таску по переименованию переменных, понял, что же это за зверь такой. Затем выходит Entities 0.5 - полностью меняется API, полностью меняется подход к подготовке ассетов. Затем 1.0 - то же самое второй раз. Но теперь с обещанием, что ну теперь-то уж точно всё, готовый продукт бери и делай. Взял я его твёрдой рукой, прижал к себе и нежно прошептал на ушко… в смысле вкрутил. Тем более задача как раз требующая высокой производительности: много юнитов с физикой на лоу-энд мобилках. Времени делать специализированную физику не дали, поэтому бери, что есть, и докручивай. И KPI - меньше 1% хард-крашей на всех устройствах. И вот вскрылась целая куча проблем, часть удалось закрыть через нытьё на форумах Unity и последующее обновление редактора (а обновление даже минорной версии Unity - это всегда боль и страдания и кровь из жопы), где нам обещали, что ну теперь-то точно всё пофиксили. Остался последний краш, который ну никак не хотел уходить. Проявлялся только на андроид-устройствах с ARMv7 архитектурой. Что внезапно оказалось 10% аудитории. Как выяснилось, на ARMv7 до сих пор выпускают мобилки, даже крупные бренды типа Samsung. В 22 году, например, они выпустили целую линейку A13, M13 и ещё целый зоопарк от производителей поменьше. Видимо, разрывы цепочек поставок и дефицит отдельных составляющих заставили производителей даунгрейднуть свои производства, ну или решили впарить пользователям говно мамонта под видом корейского шоколада. И краш-то ещё неприятный - выстреливает в рандомных местах. Проявляется только вот на этих устройствах, но всегда со стопроцентной вероятностью в течение первых 1-5 минут игры. Бинарный поиск через комментирование половины кода не дал результатов - менялось только время до краша, но сам косяк был неизбежен, как понос после мексиканского ресторана. В итоге опытным путём установил - проблема в Burst. Специальный компилятор/оптимизатор для ускорения работы кода. Выяснилось, что при компиляции Burst систем ECS генерится неправильный код для адресации в unmanaged память на 32-битных платформах. Покрыл ifdef'ами все наши системы для 32 бит - не помогло. Стало вылетать внутри Havok, Unity Graphics и прочих системах Unity. А их форкать ну уж совсем не хотелось. В итоге волевым решением был сделан форк самого Burst, где он отправлялся спать при компиляции под 32 бита, так как заботливые разработчики Unity не предоставили возможности отключить его для отдельной архитектуры. И всё. Краши исчезли, игра держит стабильные 99-99.5% безкрашевых пользователей. Вроде в ченджлогах Entities 1.2 пишут, что они исправили уже эту проблему. Оказалось, они неправильно определяли архитектуру устройства при компиляции. Но обновлять Unity перед релизом - лучше на бутылку сесть. Так что живём пока так.

Культурные различия и корпоративная культура
Помню, в Китае у нас был тренинг по различиям культур. Что всегда надо учитывать, откуда человек, чтобы эффективно с ним взаимодействовать. За основу был взят язык - как базис мышления. Язык, на котором человек думает, определяет то, как он думает. Многие, наверное, замечали, кто знает больше одного языка, что когда думаешь на другом языке, как будто появляется другая личность. Зачастую отличающаяся от основной. Пожив в разных странах, начинаешь перенимать жесты, включать в родной язык русифицированные слова из других языков. Чифанька, аишка, закомитить, заапрувиться, иншалла, машалла, полако, пичка, браттэ и т.д. И вот ведущий обучение предложил использовать двухмерную шкалу для классификации языков общения. По одной оси у нас implicit/explicit, по другой - confrontational/avoid confrontation. Implicit/explicit - подразумевает, насколько важен контекст в общении. Имплицитные языки предполагают, что слушающий будет всегда читать между строк. Тогда как эксплицитные языки предполагают минимум додумывания. (тут вставляем сексистскую шутку) По второй оси культуры, где приветствуются прямые столкновения лоб в лоб и те, кто предпочитают избегать прямой конфронтации. Так по этой шкале русский язык и культура - имплицит-конфронтационная, а вот китайская - имплицит-избегающая. Американцы и немцы - эксплицит-конфронтационные и так далее. Еще интересный момент был про разный подход к общению в имплицитных и эксплицитных культурах. Так в имплицитных культурах, присущих восточным странам: бремя понимания говорящего лежит на слушающем. (не понял - значит тупой) Тогда как в эксплицитных - на говорящем (не смог донести, плохо объяснил). И самая жопа получается, когда, например, начальник в И культуре, а подчиненный в Э. Получается ситуация, когда каждый считает, что дурак другой. В ситуации наоборот (начальник Э, подчиненный И) - каждый считает, что дурак он сам. Что с одной стороны хорошо, так как начальник попытается донести задачу максимально детализировано, а подчиненный будет ловить каждое слово. Но тут все зависит от второй шкалы. Если подчиненный из избегающих - то он никогда не переспросит, а неспособность выполнить задачу будет скрывать до последнего. В общем, при общении с коллегами, начальниками и подчиненными всегда важно понимать, с кем вы общаетесь, из какой культуры человек.

Минутка арабского мата. В арабском слово хуй - это زب(читается зуб). Живите теперь с этим. И с 32 хуями во рту😀

Немясной интеллект
Пользуюсь в работе github copilot. (оплатить мне его конечно же отказались, так что плачу из своих). Классная штука, особенно для всяких типовых задач. Неплохо понимает контекст и экономит кучу времени на придумывания имен переменным. Так что тезис Фила Карлтона теперь под вопросом. Где-то год назад когда пошел весь этот хайп воеруг ИИ и все бегали с огромными глазами ааааа ИИ нас всех заменит, все останемся без работы, я ходил и успокаивал людей. Расслабтесь, ИИ в том виде что он существует сейчас и на ближайшее обозримое будущее - это просто инструмент. Навороченый, с усиками и пупырышками, но инструмент. Мясного человека он не заменит, однако значительно увеличит производительность труда. Пришлось даже дать презентацию внутри компании, чтобы объяснить людям что это такое и с чем его едят. И потом еще одну отдельно для программистов. Пол года уже пытаюсь безуспешно объяснить главе нашего айти отдела как активировать возможность использования ИИ расширения райдера от джетбрейнс для корпоративного аккаунта. Как тут не вспомнить старика Карлина - some people are realy fucking stupid. Вот есть ИИшки(хотя после китая мне нравится говорить аишки) которые могут рисовать. И все художники такие ну вот и все ну вот и приплыли, уходим в вебкам. Приходил к нам аниматор из Диснея, который рисовал Короля Льва и Лило и Стич, делился своим опытом использования midjourney и stable diffusion. Чтобы аишка выдала картинку, которая хоть отдаленно похожа на то что тебе надо, приходится прям хорошенько так выдрочить запрос, который по итогу мало похож на человеческую речь, а больше на набор перфокарт. И то, после картинку приходится всеравно допиливать руками. Это еще если вообще повезет добиться нужной композиции. Так же до сих пор в мире не решен вопрос с авторскими правами на генерированный ИИ контент. Ведь аишки тренируют на работах реальных художников, не отчисляя им авторские, так что вопрос кто же автор тут стоит очень остро. Вангую что в будущем возможно появятся сервисы с базами изображений, куда любой художник может залить свои работы для обучения аишек и иметь с этого маленькую копеечку(а возможно и уже есть). Особенно учитывая что ии генеренный контент заполоняет интернет и теперь найти картинки сделаные человеком становится сложнее. А ии инбридинг приводит к вырождению. А картинок надо много. Так для чего же можно использовать все эти сиськогенераторы? рисование типовых затайленых текстур - один хороший пример. Камушки всякие, травинушки, песочки. Для брейншторминга - быстро накидать идей и посмотреть че получится, зачастую может прийти новая идея в процессе генерацию кринжатины. Тоже работает и стекстом. Накидываешь идей в какой нить notion и играешь в “что было дальше”. Сюда же и всякие муд борды идут у дизигнеров. Утверждение художественного стиля - это когда художникам приходится делать кучу скетчей для согласования с продюссером на сколько же стилизовано мы хотим делать игру. Условно для продуктивного общения профессионала с дилетантом. Так что не надо бояться ИИ, надо его оседлать и ебашить в закат на фоне взрыва.

Диалог на работе:
Абдульрахман: I'm going to push, but Ahmed asks me to push good.
Ахмед: Don't push just yet. I'm not ready. If you going to push, make sure you don't break anything.
* я жду пока дизайнеры уже запушат конфиги, чтобы я мог проверить багфикс *
Я: PUSH HARDER ABDULRAHMAN, I CAN'T FEEL IF YOU ALREADY PUSHED OR NOT

Что только не придумают лишь бы не платить
Потребовался целый год уговоров, аргументов, споров, постоянных подпинываний и напоминаний. И даже угроз, но мне таки удалось выбить оплату овертайма для моей команды.

Помню когда получил оффер и контракт на руки в финской компании к нему шло в нагрузку соглашение с профсоюзом на 96 страниц, в котором регламентировалось буквально все. Так же тамошний эйчар показал их внутреннюю систему где надо заколачивать отработанные часы. Соответственно если отработал больше 7.5 часов - это оплачивается дополнительно. Если ты постоянно перерабатываешь - к тебе будут вопросики. А действительно ли нужно тебе так рвать жопу чтобы уложиться в план? или может ты просто свои задачи недооцениваешь? или недостаточно эффективно тратишь рабочее время? Вот я считаю это самый правильный подход. Он вот абсолютно честный как для работника так и для работодателя. Работник сам контролирует и оптимизирует свое рабочее время. А если работодателя не устраивает сколько времени работник тратит на решение задач - у него всегда есть возможность дообучить или уволить сотрудника, если он считает что тоже самое можно делать за меньшее время и деньги.

А теперь поговорим о том, как по моему мнению не надо делать.

Менеджер решает, что является овертаймом, а что - нет. Вот это самый частый подход, который встречал. Надо поработать чуть подольше, чтобы успеть в срок? Иди на поклон к начальнику и проси. Стыдливо опуская глаза - это ведь твой косяк! ТЫ недооценил, ТЫ плохо работал. При таком подходе большинство забивает на бюрократию и все равно овертаймит без компенсации. А потом человек забивает на семью, саморазвитие, хобби, выгорает, и его выкидывают как использованный гондон. Ну а что ты хотел? Ты отстал от индустрии, потому что читать статьи и следить за трендами времени у тебя не было. Софт-скилы не прокачивал, в итоге когнитивные способности атрофировались. Как этого избежать? Так как тут компания ставит бюрократический барьер - пусть сама через этот барьер и прыгает. Надо, чтобы ты поработал сверхурочно? Пусть просят. Чем больше ты будешь прогибаться, тем глубже тебя будут…

“У нас нет овертайма, потому что у нас гибкие рабочие часы, приходи когда хочешь, уходи когда хочешь, и вообще мы тут все семья и все такое, кстати, вот у нас тут печеньки на кухне есть”. Большинство молодняка ведется на красивый офис и бесплатную кормежку. И в итоге получается, что работают тупо за еду и возможность посидеть на удобном стуле, возможно, даже без пик точеных по 12+ часов в день.

Юбисофт. Ты что, черт, какой овертайм? Будешь хорошо работать - переведем в Монреаль, точно-точно. Ты главное работай, будь покладистым и не подавай голоса. А еще мы будем пока платить тебе меньше, чем в среднем по региону на твою должность, но когда ты докажешь, какой ты классный, точно повысим! Да и вообще работать в такой крупной компании для тебя должно быть наградой само по себе! Вот, мы тебе даже футболочку дадим брендированную. Хули тебе еще надо? Как этого избежать? Не ведитесь на громкие названия компаний(особенно если название компании начинается на Ю и заканчивается на бисофт). Договаривайтесь на берегу о зарплате и внимательно читайте контракт.

Cкучали? а я тут поразвлекался немного с ComputeShader. Написал на нем расталкивание юнитов и нахождение ближайшего противника. По сравнению с класическими структурами типа KD-дерева или регулярной сетки, работает раз в 10 быстрее. Надо только паркинсона залечить, сглаживанием скоростей двух соседних кадров. На видео эпическая битва двух армий 2000 на 2000.

Несколько дней разбирался с рандомным хардкрашем воспроизводимым только в билде с вероятностью воспроизведения около 10% только у игроков высокого уровня. На что только не грешил. Выяснилась в итоге интересная особенность Unity Entities. Оказывается EntityCommandBuffer.SetComponent не выдает ошибку если попытаться через него записать данные в компонент, которого нет на ентити(аналогичный метод EntityManager бросает ошибку). Вместо этого он просто перепишет какие то чужие данные по смещению в памяти. И в момент World.Dispose словим SIGSEGV ошибочку, так как перетерся поинтер на начало чанка и проверок на нул поинтер при удалении чанка там тоже нет(что в целом не так плохо, так как иначе у нас бы просто валялся в памяти кусок мусора).

Подождите, идет загрузка...
Экран загрузки — это убийца ретеншена и самое простое решение проблемы загрузки контента. Конечно, он чуть лучше, чем просто черный экран без какой-либо индикации происходящего. В мобильных играх это основное место, когда отваливаются пользователи. Среднее время удержания внимания человека, согласно статистике, — 8 секунд (меньше, чем у золотой рыбки). Так что, если загрузка занимает дольше, человек просто переключится на любой другой источник дофамина: проверить лайки в Инстаграме, ответить на сообщение, глянуть мемасики. На практике время удержания внимания даже меньше, ведь 8 сек — это в среднем… Поэтому разработчики игр заморачиваются с тем, чтобы сделать загрузку более интерактивной. Веселенькие индикаторы загрузки, советы, смена картинок или попытки убрать экран загрузки совсем. Один из подходов избавления от экрана загрузки — это прогрессивная загрузка уровня. Загружаем не всю локацию, а только ее часть, текстурки грузим потоком (это вот когда мыльные рожи превращаются в нормальные в процессе игры). Недостаток такого подхода — уменьшение впечатления от игры. Тот самый присловутый wow-factor, что точно так же уменьшает ретеншен и создает у пользователей ощущение некачественного продукта. Кроме того, фоновая загрузка повлияет и на производительность, и тормоза и лаги во время игры только разозлят игроков, особенно в играх с высокой динамикой. Есть и еще один подход — интеграция «экрана загрузки» в игровой процесс. В No Man’s Sky гиперпрыжок — это элемент игрового процесса, и экран загрузки отлично встроен во вселенную игры. Пролезания через узкие пещеры в различных Tomb Raider, закрытые двери, которые открываются через кат-сцену, выполняют ту же роль. По сути, это такой перенос из реальной жизни в игровую среду идеи искусственного увеличения времени в пути для уменьшения времени ожидания. Все вот эти всевозможные змейки в аэропортах, с одной стороны, конечно же, позволяют чуть плотнее организовать очереди из людей, с другой — создают иллюзию меньшего времени ожидания. Пока ты идешь — ты не ждешь. То же самое и в играх — если загрузка уровня интерактивная, то и не воспринимается как ожидание.

Давно ничего не писал, пора это исправить

Одна из проблем мобильной разработки — это время, которое занимает выпуск обновления для игры в Google Play и App Store. Процесс ревью занимает значительное время. Бывает, что программисты и тестеры пропускают баги, и релиз выходит с критической ошибкой, которую нужно исправить срочно. На помощь пришли китайцы и сделали InjectFix https://github.com/Tencent/InjectFix/tree/master

Инструмент не идеальный, но позволяет выпускать патчи кода без обновления в аппсторе! Просто магия. Есть множество ограничений: нельзя в патче создавать новые классы, нельзя использовать классы, которые до этого не использовались, нельзя добавлять импорты в файлы. Зато можно подменить практически любой метод любого класса, исправив неработающий функционал. Можно быстро залатать дыру, пока полноценный фикс проходит ревью. Утилита создает бинарный файл, который нужно загрузить пользователю. Принцип работы: в процессе билда приложения все помеченные методы всех помеченных классов подменяются на методы вида

if (patch) patchedCall(); else normalCall();

Да, дополнительный иф в каждом методе снижает производительность, поэтому не стоит помечать классы, критичные к производительности. Но для интерфейсных компонентов вполне подойдет

человек, который умеет все, но никогда не спрашивайте про результаты его работы...