Есть такая беда в геймдеве - кранчи называется. Вообще, они, конечно же, есть в той или иной степени во всей 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 и играешь в “что было дальше”. Сюда же и всякие муд борды идут у дизигнеров. Утверждение художественного стиля - это когда художникам приходится делать кучу скетчей для согласования с продюссером на сколько же стилизовано мы хотим делать игру. Условно для продуктивного общения профессионала с дилетантом. Так что не надо бояться ИИ, надо его оседлать и ебашить в закат на фоне взрыва.