Семь раз отмерь - один раз начни: как не потонуть в проекте мечты

Самые очевидные советы о том, как начать разрабатывать свой проект, которые никто не соблюдает

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

Каждый день где-то в отдалённых уголках Земли рождаются сотни «революционных» проектов. Ровно столько же их и умирает, оставляя редкие следы исходными кодами на GitHub и историей переписки на форуме. Одни выдерживают несколько дней, вторые пару месяцев. Третьи могут убить год. Особенно упёртые тратят несколько лет, доводя свой труд до чего-то осмысленного, вычищенного и приспособленного к использованию, но балласт ошибок прошлого не даёт проекту взлететь, максимум окупив пару месяцев разработки.

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

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

Отсюда и ниже каждый приём я буду сопровождать примером на всем известном концепте о «корованах». Если вы не знакомы с топиком — прошу сюда.

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

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

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

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

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

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

«3д-экшон», говорите? Сколько на рынке 3D-Action игр? Десятки тысяч? А игр про эльфов сотни? Сколько игр с прокачкой и покупками? Почему я как пользователь должен выбрать именно вас? Если ваш концепт не отвечает на этот вопрос — ему место на свалке. Да, это жестоко, но идей намного больше, чем времени на их реализацию — вам действительно не жалко несколько лет жизни на то, что заведомо утонет?

Даже известный вам Кирилл смог додуматься до волшебной формулы «Грабить корованы». Вы вообще видели игры про грабёж корованов? Это можно попробовать.

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

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

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

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

Подумайте о том, какой спрос удовлетворяет ваш концепт. Ваша игра очень весёлая? Очень ненапряжная? А может слишком напряжная? Может она передаст какой-то уникальный опыт, в котором нуждаются люди? Помните, что ваш проект — это всего лишь инструмент, который должен предоставить пользователю чувства, опыт, ресурсы. Не делайте игру самоцелью.

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

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

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

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

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

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

Вы же не будете питаться солнечной энергией во время разработки, да? Вам лучше сразу продумать эту деталь. Тут есть много вариантов, но «есть» они только в теории, а по факту придётся брать что осталось.

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

Да, у успеха есть формулы. Чаще всего они стохастические, но тем не менее. Я дам лишь самую простую.

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

Успех = ф1 + ф2 + ф3 + ф4 + ф5

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

Успех = среднее(ф1, ф2, ф3, ф4, ф5)

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

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

Подумайте сами, какая игра была бы более успешной и любимой: с одним крутым режимом осады замка или с тремя посредственными режимами осады, охраны и руководства?

Этот пункт логически следует из прошлого пункта. Концепт — это ваш локомотив. Это то, что прежде всего запомнится, это то, чего будут требовать пользователи. Будет слабая реализация концепта — и всё остальное провалится.

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

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

Так ли нужны эти корованы и набеги? Хватит ли автору времени, чтобы сделать и основной режим, и дополнительные события? Или же можно добавить опций в основной игровой режим с осадой замка? Никто не станет оправдывать вашу игру словами «режим был не очень, но за то дали грабить корованы, это было весело», вместо этого скажут «разработчик занимался фигнёй, нам это не надо».

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

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

А теперь, составьте список критериев, по которым вы будете оценивать свои идеи. Критерии можете придумать сами, но лучше возьмите побольше. Например, весёлость, потенциальная популярность, бесконфликтность (отсутствие потенциальных конфликтов с другими деталями проекта), сложность реализации, скорость реализации.

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

На примере корованов: допустим, у нас есть 10 потенциальных игровых механик, но у нас есть ресурсы на реализацию только 5 из них. Давайте построим табличку:

Как видно, нам лучше сделать: выкалывание глаз, прыжки, 3D-графику, сохранения и лишение конечностей. Жаль, но корованы не попали. Впрочем, поменяем коэффициенты — и результат может измениться.

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

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

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

Каждый этап разработки занимает определённое количество времени. У каждой студии и у каждого разработчика тут будут свои показатели, я лишь перечислю цифры, которые я знаю из своего опыта или слышал с чужих уст. Подсчёт будет вестись в трудоднях при условии, что вы работаете над игрой А-уровня в одиночку 20 дней в месяц по 8 часов в день (40 часов в неделю) и что вы обладаете необходимым навыком на среднем уровне.

Теперь, если вы работаете не полный рабочий день, а например 10 часов в неделю, то умножайте эти цифры в несколько раз, то есть в 40/10=4 раза дольше. Добавьте к этому, всё вышеперечисленное с неопределённой вероятность, зависящей от степени начального планирования и вашего текущего навыка, придётся переделывать.

На примере корованов. Допустим, автор умеет всё вышеперечисленное. Тогда, берём по минималкам:

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

Ну, всё, да не всё. Во-первых, ассеты не бесплатны. Программные подсистемы стоят в среднем по 50 долларов, модели по 15, эффекты по 30. Не знаю, как у вас, а у меня таких денег не водится.

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

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

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

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

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

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

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

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

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

Будьте готовы к тому, что вам всё это надоест и вы захотите на «пару дней» (на самом деле на несколько недель) на другой проект.

Будьте готовы к выгоранию, к мыслям о том, что «это всё бесполезно, у меня ничего не получится, я не должен был это начинать».

Будьте готовы к тому, что возможно вы не приспособлены к самостоятельной работе и поэтому постоянно будете терять концентрацию, от чего ваша эффективность упадёт. Одно дело — целыми днями работать над проблемой, которую уже давным давно решили за вас. Другое дело — вступать на новый, неизвестный вам доселе путь, в котором вы ничего не понимаете. Так что смело снижайте количество месяцев в году с 12-ти до хотя бы 9-ти.

Этот вопрос не так просто, как кажется. Не думаю, что смогу дать вам ответ на этот вопрос, но поделюсь рассуждениями.

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

Успеете ли вы доделать проект до момента пересечения кривых? Вряд ли. Такое прокатывает с проектами для хакатонов, но не с приличным ПО. С другой стороны, хорошее ПО дорого стоит — и не факт, что ваша «правильная» архитектура вообще окажется подходящей и потом пригодится.

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

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

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

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

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

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

Вот здесь вы можете найти шаблон дизайнерского документа.

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

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

#лонг #разработкаснуля