Применяем 16 лет опыта в геймдеве при переходе на энтерпрайз разработку

Введение и бэкграунд

Всем привет. Данная статья будет описана от лица Ильи, нашего технического директора в Neurosell. Последние 7 месяцев он занимается разработкой технологичных продуктов для ecommerce, однако до этого, как и другие некоторые члены нашей команды, работал в сфере разработки игр, перенося огромный опыт в текущую сферу.

Далее от лица Ильи:

В этой статье я хотел бы поделиться кейсом перехода с геймдева в полностью коммерческую разработку в B2B-сегменте. Затронем как сложности, так и успешные кейсы.

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

Итак, погнали.

Почему вообще так получилось?

Все началось банально и просто - от усталости. Как-то, в очередной тяжелый вечер пятницы, после пройденного релиза, встретились с моим хорошим другом - Максом. За барной стойкой обсуждали жизнь, различные перспективы и проекты.

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

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

В итоге, спустя несколько месяцев (и несколько переписываний критически важной архитектуры), пришли к следующему стеку:

Разберемся, почему именно такой стек?

• NodeJS - В целом, в бородатые годы я писал бэк на пыхе, однако мы живем всё таки в 21 веке и хотелось взять что-то более быстрое и гибкое, понятное для дальнейшего штата разработки и универсальное. Да, есть конечно еще разные Java, Python и Go, но здесь уже скорее встает вопрос опыта, целесообразности некоторых решений и возможности быстрого найма команды. Безусловно, мы используем и Python (для ИИ-сервисов), и C# (об этом ниже), но основные продукты работают на ноде.

• Express - Не отходя от ноды. Почему Express? Ведь есть более современные решения. Однако, руки отбитые в геймдеве, говорят о том, что чем проще и меньше фреймворк, тем лучше. Не хотелось тащить десятки библиотек, часть из которых не будет использоваться в 99% случаев. Простая рациональность. Ну и Express знают по сути все нодеры.

• C# - Для некоторых тяжелых вычислений, используем C#. Думаю, преимущества компилируемых языков перед интерпретируемыми объяснять не особо нужно, к тому же мы используем Shared-код (частично перетекший с проектов из геймдева), который ещё может разворачиваться в WebAssembly, где на JS результатов нужных в браузере просто не достичь.

• JavaScript - Да, я приверженец чистого JS, однако приходится использовать его по минимуму. В основном, потому что в команде есть люди, привыкшие работать с типизированными языками и не знают всех подводных камней JS.
• TypeScript - Для основной разработки критических компонентов используется он. Чтобы банально не было косяков с типами. Возможно, это излишне, но часто спасает жизнь.
• Tailwind - Почему Tailwind а не Bootstrap? А на самом деле мы и Bootstrap используем, просто не на всех проектах. Tailwind удобнее. Bootstrap позволяет быстрее разработать простые приложения. В целом на этом всё.
• Sass - В большинстве случаев, отказались от чистого CSS. Удобнее селекторы и работы с переменными. А на выходе в любом случае получим CSS.
• Webpack - Почему он? Он же древний как этот мир. Ну, на самом деле, хоть и древний, но хорошо изучен, и с задачами своими справляется на ура. При правильной настройке, никаких проблем это не привносит. Hot Reload также помогает.
• React - Здесь мне импонирует схожесть в наших UI-фреймворках в игровой индустрии. Реактивные биндинги и все дела. Да и просто уже это стандарт индустрии.
• PostgreSQL + Sequelize ORM - В основном используем PostreSQL, ибо набита рука. Но в целом, в наше время есть ORM и мы используем Sequelize. Меньше головной боли при проектировании запросов, удобная работа со схемами и моделями.
• GraphQL - Для внутренней работы сервисов - используется GraphQL из-за своего удобства, однако как внешние ручки работы с API - используется Rest, поскольку он более распространен и понятен другим разработчикам.
• Rest API - Для внешних запросов используем более привычный Rest API.

В целом, базу обсудили. Теперь давайте посмотрим на различные подходы и опыт в обеих сферах - разработке игр и коммерческого ПО.

Чем удивил переход в коммерческую разработку B2B продуктов?

На самом деле, отличий именно в подходах к разработке особо нет. Везде используются одни и те же современные стандарты - Git Flow, спринты, ретро и прочее. Однако если капнуть чуть глубже, в среднем по рынку, то различия всё-таки есть:

• Сниженные темпы разработки - Возможно, на первый взгляд, разница может быть незначительной, однако как показало моё личное исследование и опыт, в геймдеве более жесткий темп разработки (в особенности, если касаться мобильных игр), связанно это, с многими факторами, однако основной - это, как бы то не было смешно, банально более А/Б-ориентированный и экспериментальный подход к разработке продуктов, нацеленный на максимальную прибыль.
• Заказчики - В геймдеве, как правило - у твоего продукта один или максимум два заказчика, в лице продюсера и / или издателя. Здесь же (если брать B2B сферу), каждый новый клиент - это новый заказчик. А у этого заказчика может быть еще один заказчик и так далее. Из этого выходит следующий пункт.
• Клиенты у клиентов - Помимо того, что ты несешь ответственность за успешность твоего продукта и бизнеса, тебе приходится отвечать еще и за клиентов у твоего текущего клиента. Из этого выходит, что вся разработка и поддержка разбивается на два направления - поддержка непосредственно продукта и его конечных пользователей (заказчиков), а также поддержка, которая распространяется на конечных пользователей заказчика.
• Более низкий порог входа - Как ни крути, в геймдев вкатиться куда сложнее, поэтому наблюдается неприятная ситуация, когда на рынке очень много некачественных кадров низкого и среднего звена (еще больше чем в геймдеве), а как и следствие, и сложности в подборе действительно крутых специалистов.
• Перегрев рынка - Огромный стек технологий (предположим в геймдеве 3 основных игровых движка и еще пару решений для бэка, а в энтерпрайзе это десятки технологий только для фронта), большое количество различных компаний и аутсорс-студий, фрилансеров, демпинг рынка и многое другое. Ну и еще - геймдев сообщество более сплоченное, узкое, хотя и не сильно уступает в объемах рынка.

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

Какой опыт из геймдева помогает?

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

Комплексность технологий

Первое и одно из самых важных - комплексность технологий. В игровой индустрии разработчикам приходится изучать и работать сразу со множеством сложных подсистем внутри игровых движков, таких как работа с графикой, физикой, аудио-данными, оптимизацией. Особенно важную роль играет оптимизация, поскольку разработчикам рано или поздно приходится углубляться в фундаментальное понимание оптимальной работы с процессором, оперативной памятью и многими другими аспектами, поскольку игры - очень комплексное программное обеспечение, где нужно экономить каждый байт памяти.

Архитектурные решения и оптимизация

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

Сетевые решения

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

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

Работа с сетями - также один из важных аспектов (в особенности в онлайн играх), где нужно продумывать алгоритмы для моментального отклика подсистем. В отличие от корпоративных решений, где уведомление или сообщение может прийти с задержкой пользователю даже до пол секунды, что не будет так критично, то в многопользовательских играх в реальном времени, такие задержки уничтожат продукт (в особенности в динамичных проектах, вроде шутеров).

Работа в команде

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

Работа с инновациями

Работа с инновациями, которые часто зарождаются в самом геймдеве. Такими примерами могут быть и новые GPU, и новые направления, как VR / AR. В целом, разработка игр сильно двигает прогресс в железе, а разработчики игр, более грамотно понимают, как эффективнее использовать его ресурсы.

Геймификация

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

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

Какой опыт мешает?

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

Моменты, которые мы выделили для себя:

• Коммуникации бизнеса с разработкой и понимание технологий развиты слабее, чем коммуникации бизнеса внутри геймдева, что создает дополнительную нагрузку за счет дополнительного этапа онбординга новых клиентов;
• Бизнес развивается более шатко за счет меньшего внедрения продуктовых метрик, которыми покрыты 99% продукта в геймдеве (не считаем инди-разработчиков, там больше творческая история);
• В геймдеве любая механика строится вокруг психологии пользователя, его поведенческих факторов;
• Продукты запускаются сложнее из-за присутствия дополнительного звена в цепочке разработке (клиента);
• Качество запускаемых MVP должно быть на порядок выше, в особенности, если до клиента не был донесен продуктовый подход;
• Меньше автоматизации в процессах. До сих пор множество вещей делается вручную.
• Слабо обоснованные технические решения, которые могут в дальнейшем отстрелить колено (погоня за неоправданными технологиями).

Понятно, что все, что я описал достаточно индивидуально для каждого бизнеса, просто я постарался сделать среднюю оценку на основе своего опыта (ИМХО).

Если у вас есть еще какие-то примеры, либо наоборот, противоречия, буду рад обсудить с вами.

Что хотелось бы в будущем?

В целом, нам нравится внедрять все практики, которые мы перенесли с собой из разработке игр. Однако в будущем, хотелось бы максимально внедрять продуктовый подход геймдева, минимизируя потери, при этом, восстановив четкость всех процессов и цепочки разработки на тот же уровень, что и ранее.

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

Чем занимаемся сегодня?

На сегодняшний день мы развиваем целый спектр сервисов для создания экосистемы ecommerce 3.0. Мы развиваем новые решения для электронной коммерции на базе ИИ, методологии геймификации (с перенесенными механиками монетизации в геймдеве) и персонализации множества процессов за счет социальных механик.