Начать разрабатывать игры без опыта программирования

Всем привет!

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

Это моя первая статья, в которой я, быть может немного сумбурно, с иронией и сарказмом, расскажу о:

1. Мотивации – зачем я вообще влез в геймдев, имея почти 10-летний опыт в бизнес-анализе, но не умея рисовать и программировать – казалось бы, основные навыки отсутствуют

2. Концепт продукта в самых общих чертах

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

4. Вводные на момент начала работ

5. Примерный набросок тем, которые я планирую освещать в цикле статей

Суть статьи в одно предложение:
Очередной представитель офисного планктона с завышенным ЧСВ решил, что он самый умный и что кому‑то будет интересно читать про то, как он создал себе проблемы и сам же «героически» их преодолевает

А теперь чуть подробнее…

И да, я знаю, что вы все любите картинки, но ниже будет just plane text.

1. Немного про мотивацию

Почти на каждом месте работы я вначале увлекаюсь идеей и продуктами, а потом понимаю, насколько кривые и косые везде процессы. Где-то процессы стараются выстроить, но, например, квалификация разработчиков, мягко говоря, вызывает вопросы. И я всегда скатываюсь в то, что начинаю крыть х@**и всех вокруг – разработчиков за то, что делают костыли, тестировщиков за то, что пропускают очевидные баги, в которые я попадаю чуть ли не с первой минуты проверки фичи, кривые процессы, при которых приоритетные фичи задвигаются назад и так далее. И в какой-то момент я вспомнил Довлатова

А надо бы всё время себя спрашивать: не г@#*о ли я?

Почему именно геймдев? А не аналитика/фриланс или просто какой-то простой проект/приложение?

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

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

Еще один пункт – мне хочется освоить новую специализацию – разработку, и делать это я хочу не на каких-то синтетических задачах, а на вполне конкретных, которые мне интересны

Краткая историческая справка

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

• В тебя попали – ты труп. Ранение в ноги – не можешь ходить, а если попали в руки – прицел сбивается.

• Сохранение одно на миссию

• Враг может тебя и не видеть, но кинуть гранату на звук выстрела

• Обнаружил себя – противник ложится на землю и начинает тебя обстреливать

• И плюс к этому бронетехника и авиация, минометы, огромная вариативность прохождения

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

Теперь про выбор жанра

Очевидно, что сделать тактический симулятор в качестве первой игры, да ещё в одиночку и без опыта совсем нереально – я трезво оцениваю свои возможности. Аркады/мобилки мне не интересны. Поэтому я выбрал для первого продукта 2.5D экономический симулятор на Unity (типичный лайтовый проект, не так ли?). Почему? – потому что его можно докручивать модами и дополнениями, и даже новыми механиками после основного релиза. Плюс, не нужен серьезный дизайн, а с арт-дизайном у меня никогда не было хорошо. На тот момент, мне казалось, что это не должно быть ТАК сложно. Это был фундаментальный просчёт.
А Unity – потому что считается, что это самый простой движок для новичков. Спустя полтора года плевался я от него знатно в некоторые моменты.

2. Концепт продукта

Мне хотелось совместить жанр экономического симулятора с какой-то социальной тематикой – и я выбрал для себя идею симулятора школы. То, что я до этого видел на рынке (не могу сказать, что я просмотрел все игры – мне лень на это тратить время) сводилось к эффективному тайм-менеджменту. По сути, это конвейер, фабрика если хотите, в которой надо наиболее эффективно обработать “детали”. Школа в этом случае не более чем фон или какая-то обёртка. Мне не нравится такой концепт по духу, это не то, чем на самом деле является школа.

В своём продукте я делаю упор на социальное взаимодействие: есть ученики более способные, менее способные. Есть более общительные или менее общительные, задиры, “ботаны” и так далее.
У школы есть функционал расчета основных показателей, для простоты можно назвать один – пусть это будет обобщенная популярность. Популярность учитывает и средний уровень подготовки учеников и общий эмоциональный фон, количество драк, грязь, кол-во разных специализированных классов и доступных предметов, и так далее.
Чем она выше – тем выше и спрос на образовательные услуги, и вы, как менеджер школы, можете позволить принять более звёздных учеников, которые еще выше поднимут уровень.
И тут надо балансировать – вы можете принять “бандита” за высокую стоимость контракта, но он будет шпынять умных учеников, которые могут расторгнуть контракт – и в долгосрочной перспективе вам это принесет скорее убыток, с другой стороны на начальном этапе о вас никто не знает – и у вас нет особого выбора.

Следующий фрагмент я хотел выделить в отдельную статью, но вынужден объединить со вступлением, чтобы пройти модерацию. Говорят, что вы любите длинные статьи и жадны до технических подробностей. Смею вас огорчить, код выкладывать я, увы, не буду. (клик – закрывает статью).

3. Подготовительные шаги

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

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

Итак, давайте начнем конкретно по шагам.

Шаг 1. Концепция

Самый первый шаг, который вы должны сделать – это написать концепт (и это касается не только игры, а в целом любого продукта). Неважно, какие отговорки вы для себя придумаете: “Да у меня все в голове, память отличная”, “Да какой тут концепт, это и так все понятно”, “Слушай, игра для мобилки, ну просто развлечься” – неважно, вы должны сесть и написать документ, в котором обозначите:

1. Что вы хотите сделать

2. Как увлекать игрока. Тут зависит от жанра. Для гонок это могут быть какие-то интересные трассы, для квестов – разного рода головоломки, для конвейеров/фабрик – механики развития или технологии и так далее

3. Как выглядит основная игровая петля. Расскажу на примере гонок:
   Вы начинаете с примитивной тачки, выбираете одну из немногих доступных себе трасс, далее стараетесь выиграть гонку, получаете приз и плюс к “уровню”, за деньги прокачиваете тачку, а новый уровень открывает вам новые более сложные трассы с более сложными противниками. И так далее.
   Т.е. Трасса -> Деньги -> Прокачка -> Трасса…
   В различного рода симуляторах-менеджерах примерно так же по сути. Есть объект, которым ты как “менеджер” управляешь. Этот объект выполняет какие-то функции:

   • Больница – лечит пациентов. За деньги, естественно. На стартовый капитал вы открываете кабинеты -> получаете деньги с пациентов -> достраиваетесь -> цикл

   • Школа – обучает. На стартовый капитал строите классы -> привлекаете школьников, они платят вам деньги -> достраиваете новые классы -> цикл.

   • Магазин – обслуживает покупателей. Тут аналогия такая же.

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

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

Цель шага 1 – сформировать у вас понимание того, что вы хотите получить. Поверьте, даже если вы считаете, что оно у вас кристально ясное – скорее всего, это далеко не так.
Примерный критерий успешности шага 1 – это если вы собрали друзей, выложили им идею своего решения и смогли ответить на все их вопросы – зачем в это играть, почему это интересно, а что будет если …. Если же на какой-либо вопрос вы сходу ответить не можете (очень важно отделить быстрый ответ, который вам сиюминутно пришел на ум от того, который фактически записан в концепции – если вы быстро соображаете, это еще не повод не фиксировать идеи на бумаге), то это значит, что вам необходимо еще проработать эту тему и подумать над идеей. Например, в своем симуляторе для меня некоторое время была неочевидна механика поступления денег для развития школы.

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

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

Картинка (да, я обещал just plane text, но передумал)

Шаг 2. Декомпозиция по модулям

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

1. Фича-модули:

   1. Камера. Этот модуль отвечает за перемещение камеры по сцене, зуммирование и повороты.

   2. Модуль грида. Этот модуль отвечает за хранение информации об объектах в ячейках (клеточках) и пересчет визуальных координат объектов при поворотах карты

   3. Модуль строительства. Этот модуль отвечает за размещение объектов, повороты, pipeline строительства-сноса)

   4. Модуль поиска пути. Тут все понятно – поиск оптимального пути между двумя заданными точками.

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

   6. UI – выделил в отдельный модуль, тк для симуляторов ux очень важен и будет куча всяких формочек-окошек.

   7. Модуль симуляции. Он отвечает за переключение режимов симуляции, строительства, паузу, скорость симуляции и т.д.

2. Инфраструктурные модули:

   • Игровое меню

   • Профиль + настройки (кастомизация клавиш)

   • Сохранение – загрузка

   • Модуль обработки команд пользовательского ввода

   • Шина событий

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

Самое главное – даже не думайте лезть в модуль NPC раньше времени. Это самая сложная часть игры как идейно, архитектурно, так и алгоритмически. Это самый трудоёмкий кусок и, если вы начнете его пилить раньше времени (раньше, чем у вас появится понимание того, как должна быть выстроена архитектура и как решать типовые задачи), то это приведет к тому, что вы скатитесь в прокрастинацию, потому что масштаб и уровень задач там несопоставим с вашим уровнем и умением их решать. Это как в игре с персонажем начального уровня пойти на локацию с мобами уровня финала игры – вас просто вынесут с одного “тычка”, а попытка прохождения “в лоб” будет весьма долгой и нудной.

Здесь я специально не раскрываю деталей этих сервисов – я планирую большую серию статей и опишу их чуть подробнее в последующих выпусках.

 Как итог этого раздела, с учетом набитых шишек, я выделил бы следующее:

1. Симулятор/менеджмент – очень трудный жанр для человека без опыта разработки, тк именно тут и нужно кодить логику, очень много кода и очень сложная логика. Ладно бы еще только кодить – её вначале надо придумать. Сейчас я бы выбрал что-то типа платформера/бродилки где ты управляешь персонажем и проходишь линейные карты – за полтора года я бы уже запилил даже не прототип, а прям что-то ближе к альфа-релизу, но уже поздняк метаться.
   С другой стороны – в симуляторах вы научитесь кодить и проектировать логику, и скорость роста навыков будет сильно выше, чем если бы вы устроились разработчиком в штат.

2. Если у вас нет опыта, то цель первых 3-4 месяцев должна быть не запилить MVP какой-то игровой механики, а, простите, научиться хотя бы в базовое проектирование логики, понять синтаксис языка программирования и научиться самым первым шагам в модульности. Без этого вы далеко не уйдёте. Пока что нельзя скормить llm красивую идею и получить готовое работающее решение уровня известных симуляторов колоний.
   Скажу по себе. Базовый грид я сделал после одного или двух месяцев работы и далее на протяжении года у меня визуально не менялось ни-че-го, хотя кодовая база была около 20к самописных строчек.

3. Не читайте умных книжек. Я прочел паттерны проектирования Мартина Фаулера еще будучи системным аналитиком, но по-настоящему понимать их ты начинаешь только на практике. Книги – просто рассказ, красивый язык – все, что нужно для маркетинга и продаж, не более. Навыки вы получите только на практике и никак иначе.

Шаг 3. Выбор движка и визуала

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

• Огромное количество обучающих материалов (спустя полтора года скажу, что им грош цена, потому что не подходят для “продакшена” – простите, если кого-то задел, но я так считаю)

• Куча платных и бесплатных наборов – мебель, тайлы, персонажи и так далее.

• Бесплатный редактор

• С# – мне хотелось научиться на нем писать код

• Говорят, что Unity удобен для начинающих.

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

А вот с визуалом интереснее. Тут есть принципиальная развилка:

1. 2D

   

   Плюсы:
   – Простые визуалы – по сути обычные 2D картинки, которые можно легко сделать самому.
   – Можно наклепать что-то самому

   Минусы:
   – Нет ощущения “глубины”
   – Нельзя увидеть постройку со стороны. Представьте, что, например, The Sims был бы 2D – вроде построили дом, а стены увидеть нельзя. Ну такое. Такой визуал нельзя выбирать для игр, в которых механика строительства одна из основных.
   – карта обычно не поворачивается.

2. 2.5D
   Это по сути 2D, которая притворяется, что она 3D – я выбрал именно такой вариант

   

   Плюсы:
   – Тоже 2D картинка, не нужно делать 3D-модели
   – Есть ощущение глубины, можно скрывать или показывать стены, можно увидеть всю постройку целиком
   – В теории можно перейти на полноценное 3D менее болезненно, чем с обычного 2D
   – Можно наклепать что-то самому

   Минусы:
   – Поворот сделать можно, но только на углы, кратные 90 и без анимаций – просто состояние карты чик – и в один кадр перерисовывается.
   – Для каждого из поворотов надо делать свое изображение предметов/моделек
   – Как и в обычном 2D предметы нельзя свободно “вращать” – для каждого угла должна быть своя 2D картинка
   – Чуть сложнее работа с координатами – надо вникнуть в изометрическую проекцию и сделать преобразования координат.
   – Нужно поизвращаться для работы со светом и тенью. Динамическое освещение (это когда, например, персонаж проходит под лампой и у него плавное меняется освещение разных частей тела в процессе движения) – вообще без шансов.

3. 3D

   

   Плюсы:
   – Все модельки – полноценные 3D объекты, их можно разворачивать под любыми углами – безграничная вариативность построек и размещения предметов
   – Проще сделать свет, тени. Можно сделать динамическое освещение разных частей тела
   – Можно сделать плавные повороты, менять угол обзора камеры – в общем простор для фантазии.

   Минусы:
   – Сам уже сходу не сделаешь, надо тратить больше ресурсов и вникать в принципы построения 3D-моделей. Другими словами – нужен дизайнер (пока еще желательно человек).
   – Более ресурсоемкие с точки зрения вычислительных мощностей

Для себя я выбрал вариант 2 – изометрические объекты, но с полноценными 3D персонажами (об этом расскажу значительно позже). 3D было очень заманчивым, но я прекрасно понимал, что я не потяну и разработку и дизайн в одного. А в будущем при желании можно перейти на 3D.

Подготовительные шаги заняли еще около 2х недель – я их закончил аккурат к новому году.
Я еще раз посмотрел на концепцию, на схему, на объем…для меня это было интересно, но есть нюанс – это вводные, с которыми я входил (конечно, на момент 2024го мне было все равно на эти вводные)

3. Итак, вводные такие

1. Проект стартанул в 2024 прямо в новогодние каникулы

2. На момент старта я написал 0 (ноль) осмысленных строчек кода в прошлом. Какая-то программка на 300 строчек на С++ в универе ради получения зачета не в счет, я уже все забыл

3. 0 сделанных и законченных лично мною каких-либо проектов

4. 8 лет опыта работы бизнес/системным аналитиком в разработке web-приложений – могу придумать концепцию продукта, выделить фичи, декомпозировать их на мелкие требования, оценить их с точки зрения сложности/пользы и т.д. Это, очевидно, плюс. Но это работа в команде над частью решения

5. Работаю 8 часов в день 5/2, время на проект – по вечерам и в выходные

6. Использую llm как ментора и код-ревьювера.

7. Я увлекающийся.

Не сказал бы, что это красивая картинка для входа в gamedev, в особенности пункты 2 и 3.

Но, как сказал один известный человек

У нас есть… что было. Сегодняшняя ситуация, которая есть. И нужно смотреть, какой мы можем…Что делать..

4. О чем буду писать

За чуть более, чем полтора года у меня накопилось некоторое количество собранных граблей, которыми я могу поделиться. Цикл статей будет интересен (ну, я на это надеюсь):

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

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

3. Просто людям, которым интересно понаблюдать со стороны, как кто-то пытается что-то собрать из г@#на и палок.

4. Да мало ли кому ещё

Так вот, я постараюсь написать несколько статей на следующие темы:

1. Как я декомпозировал продукт на базовые сервисы и прикидывал, с какой стороны к этому приступить, осознавая весь масштаб и свою тотальную некомпетентность.

2. Почему в итоге я решил максимально изолировать игровую логику от типов данных конкретного движка

3. Как у меня появился, не побоюсь это так назвать, фреймворк поверх Unity с обобщенными механиками

4. Что может быть общего в покраске стен, перемещением персонажей по карте и взаимодействием NPC между собой

5. Как мне удалось перевести сервис поиска пути с одного из самых тяжелых игровых сервисов с ~ 300мс на один запрос с обработкой 10к нод в один из самых оптимизированных ~150мс на 1000 запросов.

6. Как я построил систему управления персонажами и отрефакторил архитектуру NPC-сервиса так, чтобы с 25 fps на 1000 активных анимированных агентов в кадре у меня стало 60fps на 10 000 (десять тысяч) активных анимированных агентов в кадре (это сильно больше НФТ по максимальному кол-ву активных агентов в кадре для игры, но все же).

7. Плюс, буду писать про конкретные фичи, что было сложного с той или иной механикой

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

P.S. Я все еще считаю себя непрофильным разработчиком, поэтому, некоторые мои решения для вас могут показаться наивными, или даже в корне неверными – я просто делюсь своим опытом и не стремлюсь прогнуть чью бы то ни было точку зрения, доказав, что надо делать строго по-моему.

Это первая статья из цикла статей по геймдеву, спасибо, что дочитали её до конца. Если вам понравилось, и вы хотите быть в курсе новостей и обновлений – можете следить за выходом релизов в X или смотреть за выходом обновлений здесь. (на англ)
Да-да, у меня огромная аудитория.