Как стать инди-разработчиком в 40+ лет без опыта и образования

1. Вступление.

Всем привет. Меня зовут Rok и в настоящее время я занимаюсь разработкой коллекционной карточной игры про танки в сеттинге Второй мировой войны — Tank General.

На данный момент мне 44 года. Я не являюсь профессиональным разработчиком и никогда раньше не имел отношения к геймдеву. По профессии я юрист и всю свою жизнь работал именно юристом. Разработчиком я решил стать полтора года назад.

Разрабатываемая мной игра уже имеет вполне рабочий билд. В нём реализованы около 200 карт техники и приказов, три играбельные нации, около 30 штабов со способностями, несколько PvE-режимов, а также сетевой режим, который является основным в моей игре.

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

2. Главный вопрос.

Сразу начну с ключевого вопроса: может ли полный новичок без опыта и образования стать инди-разработчиком? Ответ одновременно и простой, и сложный. На самом деле стать инди-разработчиком в наше время может вообще любой. Но…

Я не помню, у кого услышал эту пословицу, но она очень жизненная: «Всё, что было сказано до «но», — это говно».

Вот и здесь то же самое. Действительно, стать инди-разработчиком может любой. Но… А теперь о самих «но»:

• Первое «но», которое является самым важным: Стимул. Это ваш стимул сделать свою игру. Причём — серьёзный стимул. Если вы просто решили попробовать стать инди-разработчиком, потому что это модно или круто, то, вероятней всего, ничего у вас не выйдет. Разработка игры требует огромных усилий. Если ваш стимул не будет постоянно заставлять вас двигаться дальше, то с большой вероятностью вы довольно быстро бросите геймдев.

При этом не имеет значения, каким именно будет этот стимул. Главное, чтобы он был достаточно сильным. Это может быть жизненная необходимость сменить работу или образ жизни, либо какая-то очень хорошая идея, пришедшая вам в голову. При разработке игры у вас будет немало моментов, когда захочется всё бросить или отложить на потом (особенно на ранних этапах). Хороший стимул способен дать вам пинок и заставить продолжать работать.

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

Тот, кто придумал для этой игры механики взаимодействия разных типов карт танков, — настоящий гений. Карта каждого типа танков играется именно как этот тип танков: например, лёгкий танк может совершить два действия передвижения за ход, что позволяет ему «засвечивать» вражеские техники или прорваться к вражеским САУ. То есть карта лёгкого танка реально действует как лёгкий танк и может подсвечивать врагов. ПТ-САУ имеет механику, которая позволяет ей всегда атаковать первой и не получать урон от контратаки, если враг был уничтожен её атакой. Это даёт ощущение настоящей ПТ-САУ, действующей из засады. И так у каждого типа техники.

А так как я люблю и карточные игры, и обе наши танковые игры, то такая игра, которая объединила оба моих любимых жанра, мне очень зашла.

Я почти 10 лет ждал, пока выйдет игра с похожими механиками. Ждал-ждал, а ничего подобного так и не появилось. И однажды меня озарило:

— «А чего я жду, если можно попробовать сделать подобную игру самому?»

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

• Второе важное «но». Разработка инди-игры требует очень много одного крайне важного ресурса — времени. И не просто много, а дофига времени. Особенно если проект сложный. А если, не дай бог, это ещё и сетевая игра — всё усложняется в разы. Тогда уже требуется не дофига, а дофига-дохера времени. Сразу определяйтесь, насколько вы располагаете этим ресурсом. Если с ним проблемы — постарайтесь не усложнять проект сверх меры.

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

• Третье «но» заключается в том, что стать инди-разработчиком и стать успешным инди-разработчиком — это две совершенно разные вещи. Как уже говорилось ранее, достаточно разобраться с двумя первыми «но», и вы уже можете делать свою игру — сейчас инструментов для этого достаточно. А вот стать успешным инди-разработчиком — это отдельный колоссальный труд, который сильно отличается от самого процесса разработки. Он требует навыков не только разработчика, но и маркетолога, клипмейкера, стримера, издателя и прочее-прочее. Именно поэтому я и написал этот пост.

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

3. Не главный, но важный вопрос (и мои советы).

А теперь тоже очень важный вопрос: как, собственно, делать эти ваши игры начинающему инди-разработчику? С чего начать, за что браться, если только на одном YouTube сотни видео-роликов о том, как делать игры и изучать движок? Как во всём этом не запутаться?

Недавно я смотрел видео одного инди-разработчика, который занимается разработкой своей RPG в 3D на Unreal Engine (его проект мне, кстати, визуально очень нравится). Он дал совет начинающим:

• посмотреть вот этот курс для новичков на YouTube;
• вот этот курс у такого-то автора;
• потом вот этот…

В итоге он пришёл к выводу, что для того, чтобы начать работать на Unreal, нужно посмотреть 200-300 видеоуроков, и только потом можно смело приступать к разработке.

На мой взгляд, это не совет, а антисовет. Если ты новичок и начнёшь с попытки посмотреть 200-300 видеоуроков, то где-то на 10-20-м видео ты всё бросишь, и на этом твой путь в геймдеве, скорее всего, закончится. Это очень нудно и, на мой взгляд, малопродуктивно — смотреть такое количество уроков без практической работы именно над своим проектом.

Вот мой первый и, как мне кажется, крайне важный совет:

Совет один: не пытайтесь изучить всё сразу. Начинать надо постепенно, с базовых небольших механик. Составьте алгоритм разработки (нейросети вам в помощь) и сразу начинайте делать игру шаг за шагом с самого начала. Не заглядывайте сильно вперёд, а сосредоточьтесь только на текущей задаче.

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

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

Главное — ничего не бойтесь и сразу начинайте работать. Если мотивация не подведёт — вы всему научитесь сами (и время на это выделите).

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

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

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

Казалось бы, какой бред — какой код, если я понятие не имею как его писать? Да и зачем этим заниматься, если есть нейросети, которые могут писать код за тебя? Ответ простой — для начального обучению программирования вам и не надо уметь писать код. Найдите видео, где программист начинает проект с нуля, похожий на вашу задумку, и вместе с ним пишите код, повторяя все его действия. Это не научит вас самостоятельному программированию, но даст главное — понимание, как работает код, как он структурирован и как взаимодействует с игрой, а также даст умение устранять базовые ошибки.

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

Сейчас я пишу код с помощью нейросетей — это удобно и проще. Но долгое время я писал код вручную по видео с YouTube, чтобы понять, как это работает. Да и выхода особого не было — когда я начинал, бум нейросетей ещё случился, а существующие нейросети были совсем тупенькими.

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

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

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

Чаще всего добавление новой механики требует правок в 3-4 скриптах, каждый из которых занимает тысячи строк. А нейросеть комфортно работает с объёмом примерно 2,5-3 тысячи строк. Если загрузить в неё 10 тысяч строк разом, она выдаст такую белиберду, что только поломает игру. Поэтому я не только знаю, за что отвечает каждый из сотни скриптов, но и в какой части скрипта находится нужный блок кода, чтобы при необходимости скормить его нейросети и получить результат, который не только не поломает проект, но и будет работать.

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

Совет пять: не делайте сетевой свою первую игру! Разработка сетевой игры намного, НАМНОГО сложнее, чем разработка обычной несетевой игры и может, с большой вероятностью, вообще похоронить ваш первый проект. По моему опыту, проще сделать три несетевые игры, чем одну сетевую. Если есть хоть малейшая возможность избежать сетевого режима — обязательно избегайте.

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

Совет шесть: если в вашей игре есть обычный несетевой режим и по какой-то причине вам всё же нужно добавить сетевой, то:

• не пытайтесь адаптировать несетевой режим под сетевой!

Вы, конечно, можете попробовать, но, скорее всего, ничего не выйдет. Там всё слишком по-другому. Я потратил около двух месяцев на это с полностью нулевым результатом. Бесполезная работа продолжалась, пока я наконец не включил голову и не понял: единственный способ — переписать весь код с нуля, но уже как сетевой. Прямо с чистого листа — с самых начальных механик и до самого конца. И только после этого процесс сдвинулся с мертвой точки. Не делайте как я — не стоит терять время на попытки безуспешной адаптации несетевого режима под сетевой. Время — наш самый ценный ресурс.

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

В этом плане мне сильно повезло с Unity. Один раз я немного подкорректировал пару строк кода, и теперь для компиляции проекта под Android достаточно буквально нажать две кнопки в движке, чтобы переключить платформу. В RuStore я уже разместил демо-версию для Android, и она вполне играбельна, в том числе по сети. Кому интересно — можете потестить, игру найти несложно (Tank General). Если моя игра в Steam будет успешной, я планирую выпустить её версию в том числе и на Google Play, и тогда она станет полноценно мультиплатформенной.

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

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

Совет девять: если вы хотите успеха своей игре — уделяйте время маркетингу!

Я изначально был крайне наивен и считал, что если сделать хорошую игру, то достаточно просто разместить её в Steam, и она сама найдёт своего игрока. Думаю, вы уже понимаете, насколько я был «умён». Полтора года я по своей наивности был сосредоточен исключительно на разработке, считая продвижение второстепенным делом.

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

Одно скажу точно: примите как факт, что первое время отклика на вашу игру, скорее всего, будет очень мало. Не отчаивайтесь. Капля за каплей…

В моём случае, только после окончания разработки базового сетевого режима, который пожрал огромное количество времени и сил, у моей игры появилась какая-то видимая завершающая точка. И я тут решил поинтересоваться, а что, собственно, делать дальше. И просто ужаснулся, каким же я был идиотом! С бешеными глазами я побежал платить взнос за размещение игры в Steam, оформлять страницу игры и изучать как, собственно, продвигать мою игру. Чтоб люди вообще узнали, что существует такая вот игра. К большому моему «удивлению», люди самостоятельно совсем не желали этого делать. Хорошо, что точка невозврата для меня ещё не настала и, надеюсь, еще можно исправить ситуацию. Правда, для этого пришлось сдвинуть сроки выхода игры.

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

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

Этот совет я сам интуитивно выполнял, но хорошо он расписан у Славы Гриса, как и многое другое, что я озвучиваю в этом посте. Я многое полезное почерпнул из его книги и видео. В том числе оплату взноса за Steam и оформление странички делал по его лекциям на YouTube. Если он каким-то чудом увидит этот пост — Слава, тебе отдельное спасибо, ты реально помог.

4. Ошибки (не только мои).

Ошибка одна: не пытайтесь делать сразу свою игру-мечты!

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

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

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

Я в своё время буквально несколько дней потратил на базовое изучение Unity и сразу начал клепать свою игру. Это неправильно, но лично мне это особо не навредило.

Ошибка два (не моя): в анализе данных есть понятие «ошибка выжившего». Если коротко, очень важно делать выводы не только на основе чужих успехов, но и (что порой даже важнее) на основе чужих ошибок и неудач.

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

Поэтому затрону несколько ошибок, с которыми сталкивались другие разработчики (меня эта чаша, надеюсь, миновала).

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

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

Очень важно перед началом разработки провести хотя бы небольшой мозговой штурм: какой потенциал у игры? Сколько конкурентов? Что нового она может привнести в жанр, как его расширить или углубить? Есть ли какая-то фишка, которая действительно улучшит жанр?

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

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

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

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

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

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

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

Конечно, может повезти, и ваш друг окажется так же сильно мотивирован, вы будете отлично дополнять друг друга, и участие пойдёт только на пользу. Но такое бывает редко. Чаще всего это только усложняет процесс и требует ещё больше времени.

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

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

На этом у меня всё. Огромное благодарность всем, кто осилил пост до конца. Надеюсь, мой пост окажется кому-то полезен. Также, буду благодарен любой конструктивной критике.

Всем успехов, а особенно начинающим инди-разработчикам!

А если моя игра вам интересна — вы сами знаете, где найти о ней информацию. Всем успехов!