(Новичкам к прочтению перед открытием новой темы) Манифест разработчика, всякому ищущему или собирающему команду.

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

***

Правда в том что... У *каждого* геймера есть по нескольку идей буквально по поводу каждой игры в которую он играл и игровым разработчиком или геймдизайнером его это не делает. Здесь поправить, тут сделать как там, здесь вот модельку поменять - и эта игра станет еще замечательней! Голова каждого геймера склонного к критике полна подобных идей. Наличие идей и вера в них не значит ничего, кроме того что вы любите играть и деконструировать игры. Идея для игры - это не просто некая мысль. Идея для игры это в первую очередь документ. Если документа нет и все что вы знаете о своем проекте это то, что это ГТА в стимпанк сеттинге, то этой идее нужна проработка. Можете промотать в конец статьи и прочитать два последних спойлера. Да, в первом приближении может казаться что воу, круто, стимпанк ГТА, фантазия сразу рисует крутые стимпанковские суперкары, злых техномагов, и так далее. Ваша задумка может быть сколько угодно крутой на первый взгляд, но эти идеи годятся разве что на то, что бы пощекотать фантазию, и к игровой разработке имеют не больше отношения, чем споры за политику на кухне к политике реальной. Пока нет документа - ваши идеи это просто идеи, они могут быть классными, но что бы собирать команду - нужен документ. Если вы не понимаете почему это так важно, то вот вводная - любая коммуникация, любые движения проекта должны фиксироваться документально. Просто возьмите за правило что любая деловая активность должна сопровождаться документом. Дали задание художнику - это документ (ТЗ), пообщались с командой и выработали новую механику - это документ (диздок), естественно любое взаимодействие с внешними сущностями - это тоже документы. Дисциплина должна быть железной, это окупается.

——

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

Если ответ на этот вопрос "Руководство" или "Геймдизайн", то вот скажу так. Этот форум имеет богатую историю и есть местный фольклор. Людей без навыков открывающих темы по набору называют "Дирехторами", "Корованщиками" и "Победителями великанов", в зависимости от амбиций и специфики проектов, и такие темы очень быстро уходят в сторону обсуждения личности автора, его непомерных амбиций и бесперспективности. Вы ведь этого не хотите?

——

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

——

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

Представьте что код вами написанный по всем правилам программирования - не работает, при этом никакой дебаг и траблошутинг не помогает - нужно упрямство, что бы найти ошибку, и решение находится иногда и через пять и десять часов. Представьте что ваша игра это 100 картинок 1920х1080 или 50 персонажей - а это одной работы художникам на года так два-три. Представьте что нужно создать 200 уникальных новых трехмерных моделей. Представьте что вы все сделали правильно, все работает, но при этом тормозит и это не лечится. Представьте что для того, что бы игра принесла деньги, вам надо сделать перевод её текстов на три языка, и для этого вам надо пройтись по всем 10 000 строк вашего проекта и присвоить им переменные. Это колоссальный труд. Да даже банально, представьте что в какой то момент появляется задача требующая долго рутинно вбивать описания предметов из документа в ассеты.
Это надо держать в уме находясь на берегу. Если вы думаете что игровая разработка это приятное приключение и просто веселая прогулка - вас ждет много очень неприятных открытий. Возможно вы думаете что геймдев - это как наряжать елку. Нашел в интернете модель оружия и врага, куда-то там добавил в проект, и вуаля, получился дум. Нет, в создании игры очень и очень много просто мелких рутинных задач, которые требуют просто сесть и в течении месяца каждый день по 5 часов ковырять какие-то мелочи. Не похоже на веселье, м?
——

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

Говоря языком статистики - по Байесовски ваше предприятие по созданию игры с шансом почти 99% загнется либо еще до прототипа, либо после - уже на этапе масштабирования.

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

——

Согласно теории принятия решений самое разумное решение которое можно принять учитывая Байесовскую модель вероятности - это вообще *не* начинать игровую разработку, если у вас нет бюджета и команды. Потому что если взять во внимание, что шанс вообще её закончить - меньше процента, что шанс выпустившись получить хотя бы какую то аудиторию - так же меньше процента, что все время пока вы разрабатываете игру и вы и ваша команда расходуете невосполнимый ресурс который (опираясь на вышесказанное) - не будет скомпенсирован, в конце концов что отсутствие бюджета многократно усложняет задачу - то надо трижды подумать и все взвесить прежде чем ввязываться в это. Не торопитесь. Осмыслите этот абзац.
——

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

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

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

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

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

Еще одна очень частая ошибка начинающих - это игра в "понарошку". Не обладая нужным набором компетенций, опираясь на какие то в целом не верные концепты начинающие часто принимают крайне не верные решения, например им кажется что Pixel Art это такая примитивная графика для инди игр, а значит если силенок мало, то лучше делать в пиксель-арте, чем в другой графике. Или что визуальная новелла состоит в основном из текста и картинок, а значит её сделать проще. Это ошибочные суждения, опираясь на которые вы принимаете в корне не верные и не выгодные для проекта решения. Шутер масштаба Counter-Strike или даже Overwatch при наличии ресурсов, сделать быстрее и проще, чем даже самую маленькую новеллу. Pixel Art практически не масштабируется и не сопровождается, т.е вносить новое и редактировать старое при наращивании мяса - становится с каждым новым ассетом все сложнее и сложнее. Это решения которые могут буквально помножить на ноль всю вложенную вами энергию.

——

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

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

98% Команд распадаются сделав первые три ассета. Гореть факелом, помните? Что бы затащить разработку нужно вести за собой людей и примером своего неуемного усердия показывать КАК надо пахать.

Что значит "На энтузиазме"? Многие почему то подразумевают под этим просто отсутствие оплаты. Правда в том что это означает эмоциональную вовлеченность. "На энтузиазме" значит что человек искренне хочет этим заниматься. Если вы не готовы по 15 часов в день делать проект, то почему вы ждете что ваш художник бросит все его прекрасные занятия и будет рисовать для вас день и ночь?  Это возможно только если он этого по настоящему сильно хочет.

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

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

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

Третий дельный совет - джемы. Практика-практика-практика. Маленькие проекты, сжатые сроки, веселое коммьюнити, соревновательный дух!

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

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

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

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

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

——

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

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

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

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

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

Пятый совет - Токсичные установки. Это само по себе тема для отдельной статьи. По сути своей хорошего успешного и крутого разработчика отличает именно mindset. И первая самая лютая токсичная установка это "Мой проект соберет миллионы". Ваш проект с самой большой долей вероятности будет где то на дне стима с 10 отзывами. Просто примите что единственная не токсичная мотивация к творчеству - это заниматься творчеством из любви к искусству, и потому что вы хотите воплотить в реальность свой собственнйый проект. Всё остальное это токсичное смещение фокуса на себя или свой проект, т.е самоутверждение. Но вы ведь не ради лайков этим заняты, верно?)
——-