Немного технической информации про мой 2D/3D движок Judy.

Его основной целью является создание комфортных условий для работы над моими личными проектами; поэтому упор делается не на производительность и легковесность, как это обычно бывает в подобных начинаниях (хотя они тоже важны), а на удобство использования. А в моём понимании это означает единую IDE с редактором сцен и луа-скриптов со встроенным дебаггером + отдельное приложение-плеер для запуска проекта без перекомпиляции.

Поскольку мне нужна трушная кроссплатформенность (Win/OSX/Linux) с потенциальной возможностью добавлять новые платформы (консоли? андроид?) и я не готов в техническом плане идти на какие-либо компромиссы, то я пишу на С++. IDE использует Qt для интерфейсов и текстовый движок Scintilla для редактора скриптов (его же используется notepad++). Player же старается не использовать ничего лишнего: он сам создаёт окошки на каждой из платформ и всё рисует на голом GAPI.

А в качестве бекенда рендера у меня сейчас DirectX 12, Vulkan и OpenGL. Впрочем, OpenGL я собираюсь убрать, поскольку Вулкан с недавних пор более-менее официально поддерживается на маках. Шейдеры пишутся на HLSL и с помощью glslang от Khronos транслируются в SPIR-V. Но поскольку теперь появился DirectXShaderCompiler от самих Microsoft на основе clang, который умеет это делать, я планирую перевозложить эту функцию на него.

Также сейчас в проекте очень сложносочинённый рефлекшн, на основе собственного парсера с++ кода и атрибутов. Я мечтаю когда-нибудь его заменить на статическую интроспекцию, которую может быть завезут в с++20 или, дай бог, хотя бы в с++23. На основе этого рефлекшена у меня сделана сериализация с++ объектов в луа-таблицы. Этот механизм я использую для создания собственного человекочитаемого формата сцен, конфигов, файлов сохранений и даже протокола сообщений между IDE и Player'ом (это нужно для дебага луа и логов).

Из вещей, приносящих практическую пользу Judy пока ни черта не умеет. Разве что куб вывести можно. Но будем это исправлять. Сейчас я сдуваю пылинки с репозитория и обновляю Qt на всех платформах (господи, как давно я не включал мак). На этих выходных, правда, буду занят рабочим проектом, но на следующей неделе, надеюсь, наконец-то пойдут первые коммиты в движок после столь долгого перерыва.

Ненадолго отвлечёмся от моих проектов и поговорим о разработке видеоигр в более широком смысле. После прошедшей E3 мне хотелось бы сказать пару слов о жестокости в видеоиграх и почему The Last of Us Part II делает для индустрии больше, чем кажется.

Что, собственно, произошло? В прошлое воскресенье Sony представила геймплейный трейлер сиквела Last of Us, который вызвал бурю обсуждений из-за показанных в нём сцен однополых отношений и насилия. И если к спорам вокруг первого мы уже привыкли за последние несколько лет, то столь буйная реакция на насилие в играх сперва удивляет.

Казалось бы, чего мы там не видели? Разве расчленёнка и фонтаны крови не шли рука об руку с играми с начала девяностых? Но давайте будем честны: даже игры, попавшие под запрет во многих странах мира из-за жестокости, не так уж и тяжелы для восприятия. Вырывая сердца из груди противников в Mortal Kombat, сшибая пешеходов в Carmageddon или поджигая толпу в GTA 5, мы не воспринимаем персонажей игры, как настоящих людей. Происходящее на экране — просто весёлый трэш и ничего более. Реально жестокие сцены, которые тяжело смотреть, встречаются разве что в хоррорах, да нишевых симуляторах маньяков, вроде Manhunt или Hatred. Но и то, и другое скорее для любителей пощекотать нервы, чем для массовой аудитории. А большие приключенческие игры, если и демонстрируют что-то натуралистично, то лишь в небольшой драматической кат-сцене, после чего про неё можно благополучно забыть и снова погрузиться в утрированный геймплей полный игровых условностей. После первых трейлеров игры оставалась надежда, что также будет и в этот раз. Но на Е3 ясно дали понять — пробираться через грязь, боль и мучения крупным планом, как бы некомфортно психологически это ни было, нам придётся на протяжении всего геймплея (как и положено людям в условиях борьбы за выживание). Именно придётся, ведь такой крупный релиз невозможно игнорировать.

И ведь нельзя сказать, что это первая игра, решившая осветить ужасы войны. Эти мысли звучали в This War of Mine и Valiant Hearts. Эти кадры были в Call of Duty и BattleField. Но никогда ранее — с таким погружением, никогда ранее без возможности скрыться, уйти от этого. И это очень важный шаг для взросления индустрии. Если мы хотим воспринимать игры, как искусство, если мы хотим, чтобы они поднимали глубокие и серьёзные темы, то нельзя вечно срезать углы, нельзя вечно избегать честного разговора о центральной теме игр — о жестокости и насилии. Чтобы двигаться вперёд, кто-то должен был рано или поздно сделать такую игру, и, чёрт возьми, пусть это будет Naughty Dog.

А сейчас я подробнее расскажу об игре, которой занимаюсь на работе.

Encased сложно благозвучно перевести на русский, но по смыслу это означает что-то вроде «в чехле» или «заключённый в». Другими словами, помещённый в какой-то ящик или окружённый чем-то со всех сторон. Название легко понять, если пояснить, что действие игры происходит на небольшой территории, накрытой гигантским непробиваемым куполом. Да-да, прям как у Кинга! Только если у короля ужасов купол внезапно появляется над уже заселённой территорией и все жители оказываются заложниками этой ситуации; то у нас, напротив, купол с древних пор стоял себе посреди необитаемой пустыни и никого не трогал, а глупые людишки сами в него полезли. Вот только небольшая проблемка: залезть они туда могут, а как выбраться обратно пока не придумали. Но зато под куполом чего только нет: и природные аномалии, и артефакты древних цивилизаций — ну прямо зона из Stalker, ей богу!

Естественно, исследование всего этого добра дало мощнейший толчок развитию науки. А на дворе на тот момент у нас были семидесятые, то есть транзисторной революции ещё не случилось, вместо неё технологии из купола: всякие энергетические штуковины не совсем ясного принципа действия. Такой вот лёгкий ретрофутуризм. Чем-то Fallout напоминает, не так ли? Не многовато ли отсылок к другим играм, спросите вы. Но приготовьтесь, сейчас будет самая главная из них: человеки, как это им свойственно, опять чего-то не поделили (главным образом, богатства купола) и снова устроили тотальный ядерный армагедец друг дружке. Выжили только ребята под куполом (не забываем, что он непробиваемый).

В сущности, всё человечество оказалось encased в этом маленьком постапокалиптическом мирке с ограниченными ресурсами, как пауки в банке. Само собой, появились всякие разные бандиты, да фракции, самые крупные из которых образованы пятью службами, работающими под куполом до катаклизма: учёные, инженеры, служба безопасности, управленческий состав и, разумеется, бывшие заключённые, как дешёвая рабочая сила. На картинке сверху можно разглядеть всех пятерых.

А главный герой может принять по ходу пьесы любую из сторон. Сам геймплей ближе всего к первым двум Fallout: нужно будет исследовать локации, выполнять квесты, торговать, сражаться в пошаговом режиме и вот это вот всё. Такая вот игра в общих чертах. А ещё у нас есть курицы с четырьмя лапами.

А я начинаю серию технических постов про архитектуру и графику игры. Казалось бы, ну чего там может быть интересного в программировании RPG с пошаговой боёвкой? Тем более на Unity (читай — на всём готовом). А вот оказывается, что кое-что может. На несколько постов точно уж наберётся. Понимаю, что не все мои читатели программисты, поэтому буду маркировать посты, затрагивающие эту тему, хештегами #код или #кодище (в зависимости от интенсивности). Лайтовые посты на общие темы буду помечать тегом #лайт.

Скрипты в Encased
#код
Формально весь код, который мы пишем для Encased — это C# скрипты (в исходники Unity мы не лезем). Но у нас есть два уровня скриптов: механика игры, которую пишут программисты; и «скрипты скриптов», которыми занимаются контент-мейкеры, то есть гейм- и левелдизайнеры. В первую очередь, это сценарии квестов. Чтобы как-то различать, но не изобретать новую терминологию, в рамках компании мы код программистов скриптами не считаем. Это условно просто код игры. А слово «скрипт» применяем только для скриптинга квестов и локаций. Именно о них сейчас и пойдёт речь.

Вообще, я большой и страстный фанат lua. Связку Сpp + lua и вовсе считаю идеальной для геймдева. Господи, у меня об этой парочке даже любовная лирика есть — настолько всё плохо :) Но так или иначе, поскольку мы пишем на Unity, то у нас уже есть связка Cpp + C#. Да, некоторые прикручивают lua к Unity, но обычно это те же самые люди, которые высказываются в духе «C# теснит C++ в геймдеве». То есть в их голове получившаяся схема выглядит, как C# + lua, но на самом-то деле это Сpp + C# + lua. Лично мне, как стороннику принципа KISS, от такой переголовы становится плохо. Каждый понимает этот принцип по-своему (об этом как-нибудь в другой раз), но для меня это означает, что в проекте должно быть как можно меньше лишних сущностей, а, значит, в качестве языка для скриптов мы остановимся на идущем из коробки C#.

С языком определились, осталось эти скрипты спроектировать. И здесь мне очень сильно повезло: в нашей команде есть дизайнеры, которые работали над похожей по механикам и масштабу игрой — над Divinity: Original Sin 2. Поэтому мне не нужно гадать, что им может понадобится, а что — нет; мне достаточно посмотреть все их юзкейсы, скопившиеся за время работы над игрой, и просто реализовать привычный для них функционал. Там y них был свой собственный язык сценариев, я же попробовал адаптировать это к C# и нашей архитектуре, и получилось примерно следующее.

Каждый скрипт (например, квест) — это отдельный класс, унаследованный от класса Script. Каждый скрипт может существовать в проекте только в одном экземпляре. У него есть функция Start() и во включённом состоянии у него выполняется Update(deltaTime). Скрипт может находить игровые сущности в мире (сущности у нас отвязаны от сцен и GameObject’ов и доступны из кода всегда, даже если игрок сейчас в другой локации), назначать этим сущностям задачи в очередь выполнения и подписываться на их эвенты.

Система эвентов представляет собой надстройку на основе делегатов. Можно подписываться, как на события от конкретной сущности, так и глобально на все события определённого типа. Во втором случае можно также добавить подписке фильтры. Например, подписаться на клики по объектам с определённым тегом. Обработчик события при сохранении резолвится в имя скрипта и метода. Да, для совместимости сейвов переименовывать методы нельзя. Во всём остальном проекте их можно переименовывать, потому что они помечаются атрибутами сериализации; но в скриптах решили атрибуцию не делать, чтобы их не усложнять (скриптеры готовы мириться с таким ограничением, а если уж очень надо, то рулить версионность ифами). Также в классе скрипта сериализуются и попадают в сейв все его поля. Для разработчика скрипта это получаются своего рода локальные переменные, где он может хранить всякие временные штуки.

Вот такая примерно система у нас. На мой взгляд, получилось довольно гибко и удобно. Так ли это на самом деле покажет время, когда мы перейдём в фазу активного наполнения игры контентом (пока у нас основная механика и даже архитектура ещё в процессе). Буду держать вас в курсе.

Jai vs C++
#код
На днях все снова заговорили про язык Jai, в связи с новостью о том, что его автор, Джонатан Блоу, собирается выпустить закрытую бету до конца года. Я решил, что дети могут насмотреться его стримов и неправильно понять, и что кто-то из взрослых должен объяснять такие вещи. Не думаю, что в русскоязычном геймдев сообществе наберётся много авторов, которые могут писать про такие темы, поэтому почему бы мне не стать таким человеком?

Начнём с того, что Блоу (это автор Braid и The Witness, если кто не в курсе) один из немногих в индустрии, на которых действительно хочется равняться. Из всех инди-разработчиков его философия и подходы наиболее близки мне. Во-первых, он относится к играм, как к искусству. И здесь я имею в виду, что он стремится, чтобы они таковыми были, но при этом не переоценивает их нынешнюю ценность (включая свои проекты). И, во-вторых, насколько я могу судить, считает написание кода не препятствием на пути чистого творчества, а частью этого самого творчества. Техническое исполнение это не просто средство, это часть самого произведения искусства. Если вы думаете сходным образом, вы поймёте, что красота должна быть везде: и в геймдизайне, и в коде. Они должны дополнять друг друга, работать в ансамбле; одно ради другого страдать не должно. Отсюда и тяга и к написанию идеальных инструментов под себя: чтобы творить в удовольствие, а не идти каждый день на компромисс с самим собой. В этом мы с ним похожи. Только он версия на максималках. Вернее HD ремастер на максималках.

Я пишу движок, чтобы в будущем комфортно было заниматься своими проектами; у Блоу уже есть два мировых хита и он идёт дальше — пишет для себя свой язык, и ничего, кроме уважения, это у меня не вызывает. Но как только кто-то начинает говорить (в первую очередь сам Джонатан), что Jai способен заменить С++ у широкой аудитории (и тем более в ААА), вот тут-то у меня и начинается скепсис. Сколько уже было попыток: D, Go, Rust? По моему мнению, Jai просто пополнит этот список.

Само желание избежать C++, мне понятно. Он причиняет боль, и я бегал от него по всяким бейсикам и шарпам до последнего, так как верил, что их мне хватит. Но чем дольше прятался, тем очевиднее становилось, что мне не хватает производительности и трушной кроссплатформенности. Какой-нибудь маленький инди-проект, конечно, можно написать на D или Rust, но если ты пишешь движок, который собираешься в дальнейшем поддерживать, или если ты большая компания, то это не вариант. Проблемы недостаточно богатой инфраструктуры здесь будут выходить на первый план; ты не сможешь гарантировать, что язык не загнётся, когда ключевых авторов собьёт автобус, и что будет компилятор этого языка под архитектуру процессора новой игровой приставки. Фактически, у тебя только два бескомпромиссных варианта: либо писать свой язык (если ты совсем ниндзя-самурай), либо перестать бояться и полюбить С++.

Пост бы был грустным, если бы не одно «но»: я очень верю в будущее С++. Jai и компания потому никогда и не вытеснят С++, что он не стоит на месте. Сейчас у этих языков куча плюсов по сравнению с плюсами (простите за каламбур), но уже в ближайших стандартах С++ должен обзавестись модулями, концептами и корутинами, благодаря чему уже начнёт ощущаться, чуть ли не как новый язык. Две основные фишки Jai — компайл-тайм выполнение кода и рефлексия — по всей логике будут следующим шагом, как развитие constexpr и некоторых перспективных предложений по статической рефлексии. Даже если на воплощение этого в жизнь уйдёт 10 лет, этого времени всё равно недостаточно, чтобы успеть вытеснить С++ с рынка. Ну а если заглядывать совсем в далёкое будущее (и немного помечтать), то метаклассы Герба Саттера вообще должны перевернуть программирование и убрать всех конкурентов в этой весовой категории.

Это, конечно, не значит, что другие геймдев-ориентированные языки не надо разрабатывать и использовать. Надо! Это всё большой обкаточный полигон для экспериментов, наиболее удачные концепции которого через много лет и после долгих обсуждений в комитете попадут и в самый совершенный язык программирования. Ну, или у меня просто стокгольмский синдром от долгого использования С++ и я бред несу последний. Всякое может быть.

Ameba
#лайт
Достала меня ситуация с кучей мессенджеров. Психанул и начал писать свой единый клиент. Называется Aggregate Message Bar, сокращённо Ameba.

Да, всяких приложений, объединяющих мессенджеры, как грязи. Я какое-то время использовал врапперы вэб-версий (Franz, Rambox), смотрел мультиклиенты (Pidgin), интеграции ботами (Sameroom), ещё какие-то сервисы и протоколы. Но это всё не то и не так. Как говорится, если хочешь сделать что-то без фатальных недостатков — сделай это сам.

Амёба разрабатывается прежде всего под Android, но будет также работать на десктопах (Windows, Linux, OS X). С айфонами гемороиться лишний раз мне не охота, но при очень большом желании можно будет запихать и туда, так как создаётся приложение на Qt.

Программа минимум — поддержать API Telegram и Slack. Если попрёт, то можно будет добавить Twitter, Discord. Может быть что-то ещё. Для начала ограничимся текстом с базовым форматированием, блоками кода, картинками, ссылками. Но сверху на это накрутим группировку каналов и подобные плюхи. Схему аккаунтов и группировку чатов планирую сохранять и синхронизировать через AWS AppSync. Опционально можно будет хранить там же и пароли.

Ориентир в плане юзабилити для меня — это телеграм. Но в Qt, к сожалению, нет стандартного контрола для редактирования текста, вменяемого работающего на мобилках; поэтому придётся все тачи и драги над текстом обрабатывать самому. На данный момент именно этим занят. Следить за разработкой и ставить звёзды можно на github (это open source):
https://github.com/Alprog/Ameba

И да, если вы находите текущий логотип уродливым, но готовы нарисовать и подарить мне более красивый — я весь внимание.

Ещё одна история о том, как попасть в профессию (как будто таких мало)
#лайт
Сегодня мне исполняется 29 лет со дня рождения и ровно 9 лет, как я официально работаю в индустрии. Это повод для меня вспомнить, как это было, и написать свою версию ответа на один из вечных вопросов новичков: как же разорвать замкнутый круг, когда для трудоустройства требуется опыт, а для получения опыта требуется трудоустройство?

Итак, осень 2008 года. Мне 19, я студент третьего курса, который только что закончил маленькую тактическую RPG на Visual Basic 6.0 (её скриншот вынесен в заголовок поста), которую пару лет делал по вечерам с командой, собранной в интернете. Проект так и назывался: «Маленькое и Скромное РПГ», так как создавался исключительно по фану и состоял почти полностью из говнокода. На этом мой опыт по большому счёту заканчивался. Контора, в которой я хотел работать, переехала в другой город, а в единственной оставшейся студии видеоигр требовались только флэшеры.

О существовании этой компании я узнал только потому, что туда взяли моего друга. Он устроился как раз флэшером и фактически закрыл собой все потребности студии. Но мы почему-то думали, что и мне место тоже найдётся: надо только подучить флэш. Он выдал мне графику от их матч-3 игры и я за недельку попутного изучения флэша собрал базовый прототипчик, с чем радостно прибежал на собеседование.

Там мне сказали, что это всё замечательно, но сейчас проектов нет (вакансия к этому моменту действительно уже пропала с сайта), но есть планы делать в будущем большой флэш проект (забегая вперёд скажу, что когда я оценил обстановку изнутри компании, стало понятно, что дальше разговоров этот проект и не мог пойти). Ещё сказали, что им нужен человек на фултайм, а я студент. И ещё что нет опыта, но если что, то мне позвонят. Я взял визитку и ушёл в дождь. В тот день было ясно, но для драматизма ситуации скажу, что ушёл в дождь.

В июне, как только сдал сессию, я написал им снова. Мол, летом я свободен на весь день. На этот раз мне не ответили. Я написал ещё раз и опять тишина. Тогда я достал визитку директора и тупо позвонил ему на личный мобильник. Мне сказали, что вообще не ищут сейчас новых сотрудников и тогда я предложил взять меня «на практику от универа», что означало поработать за чай и печеньки. И меня взяли. А через месяц, в мой двадцатый день рождения, предложили принять меня в штат. И я даже не сразу согласился на начальные условия, а поторговался.

Вот, собственно, и весь секрет. Даже если нет нигде вакансий, требуется немного напористости и готовность 1-2 месяца поработать за очень мало или за печеньки — и вот у вас уже есть опыт. Замкнутый круг разорван, вы теперь востребованный джун, и с вами уже совсем по-другому разговаривают. А дальше — больше.

Мудрость про таск-трекеры
#лайт
Знаете, что самое важное в трекере задач? Инструменты отчётности? Уведомления? Может быть, интеграция с системой контроля версий? Не, это всё фигня. Самое важное — это количество кликов при работе с ним.

Вы можете что угодно думать по поводу того, что пара лишних кликов ничего не меняют; но когда вам нужно указать тип задачи, компонент, теги и сроки, чтобы тупо создать задачу, вы просто не будете этого делать. Создать задачу должно быть также легко, как записать её в блокнот. Также быстро, как сказать её соседу. Если для создания задачи «выровнять логотип по центру экрана» требуется сильно больше действий, чем просто ввести этот текст, то вы обязательно рано или поздно поленитесь это сделать. Или напишите это в чат напрямую ответственному, воруя время у себя, у него, и ещё рискуя потерять эту задачу в будущем.

Это может показаться мелочью, но только до тех пор, пока один раз не ощутите разницу. Я помню, как на одном проекте мы за день вдвоём закрыли более ста тасок. Мелких тасок в духе передвинь что-то на три пикселя вправо или поменяй иконку. Мелких тасок, про которые бы все забыли и которые иначе портили бы впечатление от игры. Но нам было не лень их записывать по ходу и они не потерялись.

У нас тогда был собственный багтрекер, до сих пор недостижимый идеал в плане количества кликов при работе с ним. Я не рекомендую вам писать своё, но советую повозиться с настройками вашего трекера. Тратя время на то, чтобы сократить один клик, вы в конечном итоге экономите человеконедели.

Мам, на меня смотрят тёлки
#лайт
Выступал вчера с докладом на местом геймдев-митапе. Рассказывал, каково это быть техдиром на удалёнке. Записей никаких нет, но есть мнение, что я топ-докладчик. У меня это уже третий опыт подобных выступлений и с каждым разом заходит лучше и лучше. Я изначально довольно скептически отношусь к полезности 99% докладов на конференциях (включая свои), поэтому упор делаю на подачу: пусть людям будет хотя бы интересно это слушать. Нет, толика смысловой нагрузки, конечно, в моих докладах имеется, но я всё приправляю шуточками и смешными слайдами. Шутки при этом стараюсь встраивать нативно в рассказ, а слайдами играю в основном на неожиданности. И ещё громкими тезисами кидаюсь, чтобы не засыпал народ. Думаю, у меня хорошо получается чувствовать аудиторию. Правда, речь хромает: всё ещё много экаю.

Ну а ещё по фоткам я наконец-то увидел, как растолстела моя ряха за последние полгода. Надо завязывать с доставками еды и налягать на баскетбол.

Девлог #0
#лайт
Начали снимать дневники разработки по Encased. В этом выпуске общая информация про игру, а также рассказываем о работе с комьюнити. Ребята на видео как-то подозрительно много улыбаются. Наверное, потому что меня пока нет в офисе. Ну, ничего — в августе навещу их снова!

https://www.youtube.com/watch?v=z5lMainBskQ