Эту модельку я делал как фрилансер на аутсорс, вроде это для каких-то Демиургов (не оригинальных частей) но я хз куда именно и вышел ли вообще этот проект. мне давали минимум инфы по задаче.
gamedev
Подписчиков:
249Постов:
1028
indiedev
Как сделать игру и не выгореть? Нужно ли для этого продавать машину? В чём секрет инди-хитов и самых успешных разработчиков?
На последний вопрос у меня нет ответа, так как я пока не выпустил ни одного хита. А вот с остальным мы попробуем разобраться!
В предыдущем выпуске мы подробно разобрали стадию Подготовки: научились генерировать идеи, определились с тем, что мы хотим явить миру и под каким соусом. Дело за малым - разработать игру, продать миллионными тиражами и купаться в лучах славы!
Разработка
При должном уровне умений, хороший прототип вполне может собрать один человек. Максимум - пара из программиста и гейм-дизайнера. Когда же вы определились с тем, что именно предстоит делать, курс намечен - без команды вам уже не обойтись (если, конечно, вы не соло-разработчик, на все руки мастер). Подключаются художники, программисты вспоминают, как писать нормальный код, гейм-дизайнеры - как шить одежду для считать баланс/писать квесты.
MVP
Первый этап Разработки - это создание Minimum Viable Product (MVP), или Минимально Жизнеспособного Продукта.
В классической формулировке MVP это игра, в которой есть всё, но по минимуму: один персонаж, один уровень, одна пушка, один противник. Можно делать всё, что и в полной версии, просто почти нет контента.
Однако по моему мнению, MVP очень индивидуальная сущность, которая зависит как от игры, так и от ваших личных критериев. Я считаю, что главная задача этой сборки - формирование правильного впечатления от будущей игры. Используя актуальный сленг, MVP должна передавать вайб игры.
Этапы разработки на примере кабанчиков.
Поэтому каждый создатель сам определяет количество контента и продолжительность своего MVP. Обычно это от 3 до 15 минут игрового процесса, без учёта репитативного геймплея (рогалики, процедурные головоломки).
Princess Hunter - игра, над которой мы сейчас работаем - сейчас находится на этом этапе. Я очень сильно задрал планку MVP, по сути приравняв его к демо или прологу. Мне хочется собрать 4 полноценных игровых уровня, реализовать 5-7 врагов со своими колодами, 4 вариативных квеста, двух персонажей для построения отношений и даже финального босса. Это неправильный подход - так лучше не делать. Далее станет понятно, почему.
Советы на этот этап:
- Лучше всего начать этап MVP с написания ГДД (гейм-дизайн Документации). Как её писать - тема для отдельного поста и холиваров, но продолжайте следовать принципу “от общего - к частному”. Вместо огромного дока на 400 страниц делайте отдельные мини-доки на каждую фичу или механику, сосредоточьтесь на самом основном.
- ГДД поможет лучше понять вам и команде что делать, а программисту ещё и как.
-Обсудите ГДД с командой и составьте хотя бы примерный роадмап. Он даст понимание сроков, в идеале - дедлайна. Кроме того, это позволит отрезать слишком тяжёлые для этого этапа фичи.
- Не переживайте, что в процессе создания MVP роадмап будет корректироваться, и не забывайте это делать. Определение темпов разработки каждого спеца и команды целиком - одна из важных задач этапа.
- Продумывайте архитектуру вашего проекта. Лучше всего делать его модульным: даже если сейчас вы какие-то механики реализуете костыльно/не оптимально, в дальнейшем их можно будет отрефакторить или переписать.
- На этапе создания MVP допускается локальный говнокод, но сам подход, по сравнению с прототипированием, становится фундаментально иным: теперь вы пишите то, с чем в будущем предстоит работать. В перфекционизм впадать тоже не стоит: время все ещё приоритетнее, чем качество. Ищите компромиссы - это приходит с опытом.
- Это же справедливо и для остального: не старайтесь сделать идеальный баланс или вылизанный арт. Успеется.
- Жизненно важно начать комментировать код, а то и вести минимальную техническую документацию. Может показаться, что сейчас это не нужно и просто трата времени - но в будущем это позволит сэкономить месяцы, а то и вообще спасти проект.
- Организуйте хранилище ресурсов для проекта с возможностью пошарить доступ на членов команды. Например, на гугл-диске. Чем логичнее и структурированнее будет система папок, тем проще будет в будущем. Ни в коем случае не превращайте хранилище в файлопомойку.
- Храните не только финальный арт, но и скетчи, промежуточные варианты. В будущем они могут вам пригодиться. Например, для написания такой статьи.
- Не пренебрегайте бэкапами!
Сбор фидбека
Итак, у вас готов Минимально Жизнеспособный Продукт - маленькая, но всамделишная игра! Это настоящая веха и отличный повод отпраздновать, но расслабляться ещё рано. По сути, всё только начинается…
Обычно те, кто планирует найти издателя, уже на этом этапе начинают рассылать архив с игрой. Это продиктовано как нетерпением, так и усталостью. Однако я советую повременить и перед любыми следующими шагами, будь то поиск партнёра, масштабирование или суицид, провести сбор фидбека.
Покажите игру незнакомым людям. Не маме, трём друзьям и жене/мужу, а совершенно сторонней целевой аудитории, которая не побоится сказать правду в глаза. Это может быть тематический форум, чат или даже закупка покупка рекламы. Соберите отзывы хотя бы нескольких десятков игроков и проанализируйте их.
Сбор фидбека очень важен, потому что позволяет понять, в нужном ли направлении вы двигаетесь, и будет ли игра нужна кому-то ещё, кроме вас и команды. Нет, если проект вы видите исключительно как сублимацию и авторское видение - можете смело пропускать этот этап. Однако я лично считаю, что игра без игрока, как и театр без зрителя, не имеет смысла. Не нужно менять курс целиком, но внести в него коррективы, пока не поздно, бывает крайне полезно.
… в которую вложил душу, 2 год жизни и вырученные с продажи почки деньги.
Не воспринимайте фидбек близко к сердцу и смотрите не на один отзыв, а на впечатление группы людей в целом. Если одному человеку механика не нравится, а девять даже не упоминают её, проблема скорее всего, не в механике, а в человеке. Если одной половине участников плейтеста идея по вкусу, а второй - нет, это тоже не причина все перекраивать. Однако когда в каждом отзыве люди жалуются на ваше концептуальное управление при помощи крутилки громкости на колонках - повод задуматься...
Помимо основной задачи - выявить самые очевидные проблемы пока ещё не поздно внести серьёзные - у плейтестов MVP есть и другая, не менее важная. Команда в целом и вы в частности должны получить обратную связь, позитивную подпитку и осознание: то, что вы делаете кому-то нужно и интересно. Чем дольше вы работаете над игрой, тем сильнее она начинает казаться вам каким-то чудовищным нагромождением бездарно реализованных механик. Квесты и диалоги после сотого прочтения не вызывают ничего, кроме омерзения, игровой процесс видится скучным, безыдейным и слишком простым. Это совершенно нормальное выгорание и замыливание взгляда, которое неизбежно приходит к любому разработчику, делающего игру более полугода. Эти мысли посещали и создателя Stardew Valley, и разработчиков Ведьмака, и автора этих строк. Единственный способ справиться с этим - получить позитивный, непредвзятый взгляд со стороны.
Но нужно быть готовым к тому, что фидбек этот будет не абсолютно восторженным.
Корректура
Как и любые творцы, игроделы очень болезненно относятся к критике. Не факт, что явив MVP миру, вы получите в ответ только лучи добра и чистую радугу обожания. В лучшем из наиболее вероятных исходов отзывы будут сдержанно-позитивные: в целом неплохо, но вот это так себе, это как-то странно работает, а вот это я не понял. Может быть и пожестче: пресновато, скучновато, зачем оно нужно, когда есть [Title_Name]?
В этом случае у вас два варианта действий: заплакать как эмо-девочка и больше никогда не заниматься этой неблагодарной работой, или проглотить подступающую к горлу обидку, вычленить из фидбека рациональное зерно, сформулировать гипотезы, внести правки в проект и показать его снова, желательно уже другим людям. Это действительно сложный, в первую очередь эмоционально, процесс, чем-то напоминающий знаменитую сцену из Большого Лебовски.
Разраб снова и снова получает фидбек от пользователя.
Однако если вы найдёте в себе силы и ресурсы не только стоически выносить мнение от игроков, но и стараться сделать игру лучше, это действительно пойдёт ей на пользу.Советы:
- Слушайте игроков, но не идите у них на поводу. Вам важны симптомы, а не их диагноз. “Игра слишком короткая” - симптом. “Добавьте босса в конце а ещё противников побольше, и чтобы корованы” - диагноз диванного эксперта.
- Стройте гипотезы и проверяйте их, а не стреляйте наобум. Помните, что никто не знает вашу игру так же хорошо, как вы.
- Старайтесь вычленять из фидбека важное и отбрасывать второстепенное. Ищите закономерности. Представьте, что вы - механик, который по звуку работы двигателя пытается определить, нет ли внутри поломок.
- Старайтесь вычленять из фидбека важное и отбрасывать второстепенное. Ищите закономерности. Представьте, что вы - механик, который по звуку работы двигателя пытается определить, нет ли внутри поломок.
- Определите, какого именно фидбека вы хотите добиться,чтобы понять, когда можно будет остановится и двинуться дальше. Помните: лучшее - враг хорошего.
Маркетинг
Окей, у вас на руках MVP, в который приятно играть и не стыдно показывать. Кроме того, вы уже лучше представляете, сколько времени требуется на отрисовку, программирование, диалоги, квесты и всё остальное. Что дальше?
Вариант первый: посчитав трудозатраты на создание игры, вы понимаете, что в свободное время и на энтузиазме будете пилить её лет 5-7, если не случится форс-мажор. И/или трезво оцениваете свои нулевые способности в маркетинге и понимаете, что даже если хватит сил довести игру до конца, про неё никто не узнает, ведь выпуск проекта без плана по продвижению сейчас равносилен торжественному спуску кирпича на воду. Ко дну он пойдёт сразу же, как покинет заботливые руки создателя.
Забавный факт: бетонные суда реально существуют. Хороший пример того, что при умении поплывёт что угодно!
Вывод - вам нужен инвестор/издатель. Не будем сейчас вдаваться в тонкости различия между ними, благо что есть много классных команд, которые помогут и с деньгами, и с продвижением… если проект многообещающий и классный.
Именно поэтому выше я советовал заняться отладкой MVP, а не сразу рассылать его всем издателям из гугла. Как говорят мудрые волки из пацанских пабликов, первое впечатление можно оставить только первый раз. А если оно будет не очень, то второе, скорее всего, и не случится.
Советы по налаживанию контакта с издателем:
- Будьте настойчивыми, но не навязчивыми. Загруженность у многих крупных издателей такова, что ваше письмо может запросто затеряться среди сотен других, ежедневно падающих им на почту. Однако если вы получили отказ, не стоит писать снова или сталкерить сотрудников на конференциях.
- Если у вас за плечами нет нескольких успешных проектов, а в паспорте не написано “Кодзима”, на стадии идеи с вами никто общаться не будет, какой бы гениальной она ни казалась. Но играбельный MVP - уже очень весомый аргумент в пользу того, чтобы на вас обратили внимание.
- Де-юро опытные издатели могут рассмотреть алмаз неогранённый даже в самом грубом прототипе. Де-факто, чем более отполированную версию вы пришлёте, тем выше будут ваши шансы на успех. Однако помните, “отполированную” - не значит длинную!
- Из предыдущего пункта можно сделать неверный вывод, что в идеале издателю нужно прислать уже готовую игру. На самом деле нет: продвижение игр занимает много времени и обычно начинается за год до релиза. К тому же издатель с высоты своего опыта может дать очень ценные советы по разработке, реализовать которые на поздних стадиях будет невозможно.
- Заранее подготовьте ответы на следующие вопросы: описание целевой аудитории, успешные недавние похожие проекты (или убедительные доказательства того, что игра создаст/возродит свою нишу), примерный роадмап разработки, бюджет на разработку, который вам требуется и производный от него бёрнрейт команды (сколько стоит разработка в месяц, включая зарплаты, софт, аренд офиса, если он есть и т.д.).
- Старайтесь искать издателя, у которого есть похожие проекты и успешные кампании. Маловероятно, что специализирующийся на спортивных симуляторах издатель добьётся больших успехов, взявшись за JRPG.
Вариант второй: оценка ресурсов команды показывает, что вы вполне потянете производство самостоятельно. К тому же, у вас есть какие-то веские основания полагать, что игра выстрелит и без помощи издателя: например, вы сами успешный блогер-летсплейщик с огромной аудиторией, которая только и ждёт вашу игру. Или ваш дед застолбил рекламный щит на горе Рашмор
Однако даже если вы решили взять на себя не только разработку, но и продвижение игры, начинать стоит как можно раньше, но не позднее MVP. Формирование комьюнити вокруг игры и сбор вишлистов - процесс очень долгий, но очень критичный. К сожалению, здесь мне нечем особо поделиться в плане опыта, этот путь мы только начали осваивать. Но даже осознание его важности уже даст вам преимущество.
Сложность маркетинга ещё и в том, что он идёт параллельно процессу разработки, поэтому если вы планируете заниматься им самостоятельно - вы отжираете значительную часть времени от создания самого проекта. В среднем это занимает от 20 до 50% времени выполняющего функции маркетолога/комьюнити менеджера и художника, но в отдельные моменты с порывами до 146%. Не думайте, что можете отделаться 10 минутами в неделю!
Однако вернёмся к разработке. Так или иначе, с издателем или без, после минимально жизнеспособной версии вы переходите к самой долгому этапу - Масштабированию.
Масштабирование
Теперь ваша задача - нарастить на скелете MVP мясо контента. Сделать из пробника полноценную игру. Вы уже понимаете, как она будет выглядеть, играться, осталось просто нарисовать, написать и озвучить это дело.
Этот этап - самый рискованный в плане выгорания, потому что долгий и относительно рутинный. К тому же, архитектура уже заложена, и теперь вы сильнее ограничены в создании новых механик и выборе технических решений. Многие классные задумки, которые придут вам на этом этапе, будет придётся отложить до лучших времён или другого проекта.
Однако если на прошлых шагах вы все сделали правильно, у вас есть читабельный и прокомментированный код (у нас, например, с этим проблемы), чёткая цель впереди и дорожная карта, которая поможет до неё добраться. А если удалось ангажировать издателя - то ещё и деньги на разработку.
Перед тем, как начать масштабирование, очень полезно формализовать все требования к проекту: технические ограничения, целевое железо, на котором должна нормально идти игра, формат и разрешение графических ассетов, звуков и музыки. Это позволит вам:
- Оптимизировать ресурсы, сделать разработку более предсказуемой. Художнику не придётся ресайзить сто раз свои картинки, а верстальщик не вскроется от того, что у всех предметов в инвентаре размер +-20 пикселей.
- Поставить производство контента на поток без постоянного поиска в логах и просмотра свойств изображения в проекте.
- Избежать недопонимания между соратниками и сократить количество поводов для конфликта.
- Быстро расширить команду, если появятся возможность и потребность. Не отвлекать ради этого надолго других участников. Чтобы ввести человека в курс дела, достаточно будет скинуть ему док и несколько референсов для примера.
- Не менее быстро найти замену тому, кто отвалился по какой-то причине.
Гейм-дизанер, наконец-таки, может приступать к созданию подробной ГДД, из которой в процессе родятся отдельные ТЗ. Приоритезируйте фичи и составьте план, по которому разработка не будет стопориться из-за отставания кода, арта или гейм-дизайна.
Единого универсального формата ГДД не существует - хороший гейм-дизайнер выстраивает его в зависимости от проекта и команды. Но есть несколько универсальных советов.
Не постесняюсь повторить - задача ГД не написать много, а написать понятно. Меньше всего художники и программисты хотят читать километровые простыни. Пишите ёмко, коротко, используйте кросс-ссылки в духе википедии. Не забывайте, что создаёте технический, а не художественный текст! Избегайте подробных повторов: если элемент работает аналогично уже реализованному или описанному выше, не стоит копипастить. Достаточно упомянуть это и сослаться на нужный кусок текста, при надобности сопроводив списком отличий.
Не бойтесь фичекатить (то есть, отказываться от каких-то задумок) в пользу ускорения процесса разработки или производства более важных штук. Лучше хорошая выпущенная игра без возможности менять причёску главному герою, чем идеальный, но не выпущенный симулятор парикмахера.
Обязательно нужно формализовать разработку, разбить её на задачи, расставить им приоритеты. В идеале это лучше сделать ещё на этапе прототипирования, но если MVP за счёт малого количества контента ещё можно собрать спонтанно, то полноценный проект уже очень трудно. И от масштаба проекта проблемы будут расти кратно.
Это нудно, но очень важно, потому что иначе вы утоните в хаосе и запутаетесь в том, что было сделано, что предстоит, а от чего давно отказались. Чем больше людей в команде, тем животрепещущей вопрос менеджерской работы, но таск-трекингом пользуются даже опытные соло-разработчики.
Кто бы ни взял на себя продвижение - вы, сын маминой подруги или какой-нибудь HypeTrain - заложите в разработку время и на создание промо-материалов. Даже если это будет компиляция будущего игрового контента, её всё равно нужно собрать, сверстать, подогнать под формат и т.д. Не стоит полностью перетягивать одеяло с разработки на маркетинг, но минимум 3 часа в неделю кто-то в команде будет этим заниматься.
Релиз
Итак, месяцы или даже годы разработки позади. Вам и самим не верится, но игра, в целом, готова. Нет, в ней всё ещё есть, что допилить или улучшить, да и четвёртую локацию хотелось бы добавить, но… вы же помните, да? Лучшее - враг хорошего. В какой-то момент необходимо остановиться и явить игру людям.
Естественно, лучше так не делать, если в игре есть известные критические баги. То, что пойдёт в релиз, должно быть оттестировано: нужно быть уверенным, что большинство пользователей сможет дойти до конца без проблем.
Не стремитесь закрыть все существующие баги, особенно если они носят чисто забавный характер (это может даже завирусить игру*) или являются глитчами, то есть дают игроку какое-то неожиданное преимущество. Ни один человек не жаловался на то, что из-за странного бага в битве с финальным боссом отхилил не 100, а 1000 хп, и победил - а вот обратная ситуация может привести к возгоранию кресла!
--
*У многих возникает вопрос - а не стоит ли специально добавлять подобные баги в игру? Что ж, это каждый решает для себя сам. Это паттерн на грани тёмного, но всё зависит от того, насколько часто и в лоб вы это делаете. Чаще всего баг настоящий, разработчики про него знают, но решили не исправлять, а оставить. Яркий пример - ограбление торговца в скайриме путём надевания ему на голову ведра.
Пример из Princess Hunter: из-за неправильных настроек анимации перемещения герой, вместо того, чтобы бегать по полянкам, превратился в Тасманского Дьявола. Я её уже показывал до этого.
В итоге, как и советовали реакторчане, мы решили сделать из этого бага фичу - если герой переусердствует с зельями, то будет крутится как волчок :)
Когда вы подойдёте к релизу, у вас должна быть сформирована фан-база, пропорциональная вашим ожиданиям. Если вы релизитесь в Steam, перед запуском игры у вас должно быть 7-9 000 вишлистов, иначе игра почти наверняка потонет в потоке новинок и не будет видна никому. Помимо того, что вишлисты - это потенциальные покупатели (хотя не стоит рассчитывать на конверсию более 10-15%), их количество на релизе влияет, насколько сам Steam будет показывать игру прочим пользователем.
Поэтому, если вы хотите поддержать разработчика, но при этом не планируете покупать игру (вы принципиальный пират или просто жанр не ваш) - всё равно добавляйте игру в виши, это даст буст проекту на старте. Вам это ничего не стоит, а человеку - реальная помощь. Например, нашу игру!
Перед тем, как нажать кнопку “опубликовать”, выспитесь, запаситесь энергетиками и убедитесь, что все ключевые члены команды, особенно программисты, на связи. Первые сутки после релиза вам предстоит постоянно мониторить отзывы и статистику на предмет багов и крашей. Нужно быть готовым пересобрать, супер-быстро протестировать и перезалить билд игры, пнуть саппорт, если проблема на их стороне. Это - самое напряжное и стрессовое, но и самое важное время, потому что второго релиза у вас уже не будет. Согласитесь, очень обидно потратить пару лет на разработку и словить на старте дикий хейт из-за того, что игра не запускается… или даже не качается из-за локального сбоя серверов стима.
Будьте сильными. Дежурьте посменно. Если в первые сутки игроки не столкнулись с какими-то фундаментальными проблемами, можно слегка выдохнуть. Но расслабляться рано: первую неделю после релиза за игрой нужен глаз да глаз, потому что критичный баг может оказаться в конце игры. Возможно, засада будет крыться не в коде, а в цифрах: уровень, который ваши тестеры проходят с закрытыми глазами, не могут осилить 99% игроков. В этом случае нужно быть готовыми выпускать и быстрые баланс-патчи. Однако не спешите с выводами и собирайте достаточно статистики, чтобы принимать такие решения: самые громкие игроки могут создать впечатление, что их большинство, но это не всегда соответствует истине.
Ваше состояние через 12-14 часов релиза.
Обязательно стримьте свою же игру в первую неделю (или дольше) прямо на Steam - это поднимает шансы на успех и привлекает внимание.
Помните, в самом начале я писал, что у меня нет рецепта 100% хита? Это так, но напоследок я хотел бы поделиться несколькими соображениями, которые, на мой взгляд, увеличивают шансы игры на успех.
- Картинка важна. Исследования показывают, что у пользователя два ключевых фактора, определяющих желание купить: арт и цена. Классный сюжет и офигенные механики он сможет заценить только как поиграет. Это не значит, что на них не стоит делать упор, но не пренебрегайте визуальной составляющей. Она не обязательно должна быть фантастической, но как минимум - приятной, в идеале - выделяющейся.
- Вытекающий из прошлого пункта вывод - не скупитесь на трейлер. Это видео должно быть не просто “мхвм мы тута игру сдмделали вот короче”, а быть максимально крутым и драйвовым. Это концентрация всего самого офигенного, что есть в вашей игре! Найдите того, кто умеет такое, предложите ему денег, шантажируйте, умоляйте, но сделайте своей игре достойное промо-видео!
- Подумайте, насколько игра виральна. Интересно ли смотреть за тем, как кто-то в неё играет? Или играть с друзьями? Хочется ли рассказывать об этой игре? Если на все эти вопросы ответ “нет”, возможно, стоит внести некоторую корректуру в гейм-дизайн. Я не агитирую делать игры специально под стримеров или киберспорт, но иногда смещение акцентов буквально на пару градусов позволит игре выстрелить на твиче или ютубе.
- Редактор может сделать игру бессмертной. Дайте игрокам возможность самостоятельно делать контент - и его поток не иссякнет. HMM III и WarCraft 3 - самые яркие примеры, однако далеко не единственные. Есть множество других, менее известных, но годами поддерживающихся комьюнити проектов. Дело в том, что даже самая крутая игра рано или поздно наскучит, приестся. Через год-два после релиза (скорее всего - намного раньше) её если и будут вспоминать, то просто как пример. Можно подогревать к ней интерес дополнениями, но куда лучше делегировать это самим игрокам. Вполне возможно, что какие-то обретут даже большую популярность, чем оригинал (вспомните историю Dota). И это прекрасно!
Послесловие
Спасибо всем, кто дочитал этот лонгрид, а особенно - оба поста. Ещё раз отмечу, что всё написанное - просто моё частное мнение, дистиллят своего и чужого опыта через призму мировоззрения. Не используйте её как дословную инструкцию. Помните слова Барбароссы:
“На самом деле Кодекс не свод правил… скорее, список рекомендаций.”
Всем добра и мирного неба над головой!Дед - это не возраст и даже не семейное положение, подразумевающее наличие внуков. Дед - это состояние души, в котором ты делишься мудростью, даже если тебя об этом не просили. Вот и я решил запилить очередную простыню на тему разработки инди-игор.
Типичные ошибки новичка-разработчика я уже разбирал. Возникает справедливый вопрос: окей, как не надо делать - понятно… а как надо? Где та самая инструкция, в которой по шагам описано, как выпустить мега-хит? Так вот же она!
Если серьёзно, то ни у кого такой инструкции по очевидным причинам нет. Однако никто не мешает мне собрать небольшое руководство для повышения шансов сделать хоть что-то - и постараться, чтобы получилось хорошо!
Эта статья будет полезна в первую очередь тем, кто очень хочет делать игры, но не знает, с чего начать. Опытные разрабы давно выработали свой подход, но, возможно, они тоже найдут здесь что-то интересное.
Всё описанное ниже ни в коем случае не является истиной в последней инстанции или универсальной методологией. Это просто выжимка из моего опыта и наблюдений, приправленный примерами из Princess Hunter. Следовать ей или нет каждый решает сам :)
Создание игры можно условно разделить на три больших стадии:
- Подготовка
- Разработка
- Релиз
Каждая стадия состоит из этапов. В этой статье я расскажу про Подготовку.
Идея
Коммерческая разработка начинается с исследования рынка, определения ниши, рентабельности затеи и попытки угадать тренды на основе текущих тенденций. Это обстоятельный метод для минимизации рисков тех, кто, в первую очередь, хочет заработать денег.
Инди-игра рождается из идеи. Не важно, идея это механики, сэттинга, сюжета или чего-то на стыке - главное то, что она пришла вам в голову и теперь не даёт покоя. А реализовать вы её хотите именно в виде игры.
Это может быть задумка для абстрактной головоломки (Baba is you), дикий мешап вселенных (Wizard with the Gun), посылка вроде “смесь милоты и оккультизма” (Cult of the Lamb) или даже удачный набросок главного героя, из которого вырастет целая вселенная (Hollow Knight). А может быть просто навязчивое желание сделать “свой ответ Civilization” или “классные гонки на асфальтоукладчиках”.
Как я уже писал в прошлой статье, сами по себе идеи (без реализации) не особенно ценны. Однако без них все прочие шаги просто не будут иметь смысла.
“Но если не придёт герой - не будет и Подвига”.
The Elder Scrolls III: Morrowind
У большинства разработчиков с идеями, как правило, проблем нет: ещё до завтрака они на-гора выдают десяток концептов разной степени адекватности.
Другие могут запнуться уже на этом этапе: креативный зуд есть, а вместо мыслей, что бы такое сделать - пустота. Прозвучит банально, но вдохновение можно найти… везде. На идею для игры вас может подтолкнуть фильм, книга, поездка на дачу, строчка из песни, переезд, попытка собрать полку из Икеи. Не торопитесь хвататься за первую попавшуюся мысль: если вы сами не уверены, что хотите поиграть в будущую игру, не стоит её делать. Важно - эта установка справедлива только для стадии Подготовки. В следующих стадиях, если вы до них дойдёте, вы успеете свою игру возненавидеть!
Если же абсолютный творческий ступор полностью блокирует фантазию, а не делать игры вы физически не можете (я знаю и такие случаи), то можно воспользоваться следующим способом. Возьмите несколько игральных костей и присвойте каждой грани какую-то механику, сюжетный троп или сэттинг. Например:
1 - РПГ
2 - Аркада
3 - Гонки
…
2 - Аркада
3 - Гонки
…
1 - Про вампиров
2 - С остановкой времени
…
2 - С остановкой времени
…
Кубиков, граней на них и бросков может быть любое количество, тематика - на ваше усмотрение: жанры, герои, произведения, временные периоды. Делайте броски до тех пор, пока получившееся сочетание не заставит в голове щёлкнуть: “Ага!”
Обычно озарение приходит в момент, когда маховики фантазии начинают раскручиваться и дополнять получившийся набор рандомных вводных деталями: “Гонки в темноте, постапок… А что, если настал буквально КОНЕЦ СВЕТА и мир погрузился в вечную тьму? Гонки… игроки ездят по мёртвому миру между освещенными городами и видят только небольшой кусочек пространства, которое выхватывают из мрака фары его багги… О, можно будет апгрейдить машину не только на скорость, но ещё и обвешивая фонариками… А почему гонки? Может, во тьме за этими машинками охотятся монстры? Нет, ещё круче: в темноте чем медленнее ты двигаешься, тем быстрее течёт время, и если не жать на педаль, то машина будет ветшать на глазах, а водитель умрёт от старости!”
С этим уже можно работать!
--
[Дополнение]: Уже после написания статьи мне подсказали, что есть цифровые варианты генераторов идей:
Менее лампово, но удобней!--
Идея игры Princess Hunter родилась сразу из нескольких, последовательно пришедших предпосылок:
- (Что?) Вдохновленный Helltaker гаремник, но с монстродевочками, а не демонессами;
- (Как?) Классная боевка из Guild of dungeoneering, но не в виде рогалика, а сюжетное приключение;
- (Где?) Тёмная Башня Кинга + Сказ о Федоте-Стрельце Филатова в духе Adventure Time;
- (А ещё…) Дружба и романс персонажей, как в Hades, но с нелинейными диалогами классических CRPG.
Концепт
От какой бы посылки мы ни отталкивались, теперь нам стоит проработать её чуть подробнее: сформулировать базовые правила, вычленить кор-геймплей или описать так называемые столпы геймплея - самые-самые жизненно необходимые механики.
Существует две одинаково опасные крайности на этом этапе:
Написать слишком мало. Например, описанный выше ход мыслей о гонках в темноте - хорошая почва для концепта, но всё ещё не концепт.
Написать слишком много: уходить в частности, отвлекаться на мета-геймплей, придумывать диалоги и названия апгрейдов.
Задача концепта - лаконично, но понятно сформулировать содержание основных игровых механик. То есть ответить на вопрос "Как в это играть?".
Игра целиком и полностью вертится вокруг сюжета, а геймплейно является полным клоном другой игры? Опишите синопсис истории - без лишних подробностей, но по всем основных вехам. Даже если вы делаете классический текстовый квест или кинетическую новеллу, всё равно не поленитесь уделить пару абзацев тому, как именно игрок будет играть в это.
У одного проекта может быть сразу несколько параллельных концептов, отличающихся деталями или фундаментально. Например, те самые гонки в темноте можно расписать как трёхмерную игру с видом от третьего лица, а можно и как топ-даун 2д аркаду в духе Вангеров. Эти концепты пригодятся нам на следующем этапе.
Ещё один важный момент - не гнушайтесь использовать референсы, изучать и декомпозировать вдохновляющие вас игры. Чтобы сделать отличную игру не обязательно производить революцию в жанре или создавать новый. Эрик Барон, создатель Stardew Valley просто делал “что-то типа Harvest Moon”.
Продумывая концепт Princess Hunter, я сразу определил, что игра будет состоять из трёх столпов:
- Перемещение по уровням (в том или ином виде) - здесь было больше вопросов, чем ответов. Про варианты, которые мы перебрали, расскажу ниже.
- Карточная боевка. Костяк команды уже имел опыт в ККИ, к тому же я искренне люблю колодостроение. Поэтому мы смогли использовать и экспертизу, и кое-какие наработки.
- Диалоги. У меня противоречивое отношение к Визуальным Новеллам. С одной стороны, они нравятся мне с точки зрения интерфейса - ростовой спрайт персонажа, смена эмоций и относительно короткие реплики классно выглядят и легко читаются. Но прокликивать километры текста до того, как тебе предложат выбор (нередко уровня “Привет” и “Здравствуйте”) всегда вызывало тоску и уныние. Поэтому я решил совместить красивую обёртку ВН и мощную вариативную начинку в духе Fallout 1-2, где Choices, как говорится, действительно Matters.
Поиск
Отлично, у нас есть Идея и Концепт нашей будущей игры! Вижу цель - не вижу препятствий, начинает полноценную разработку… или нет?
Именно на этом этапе большинство начинающих разработчиков идёт совершенно не туда. Им кажется, что они уже кристально ясно видят игру, нужно лишь дословно переместить её из головы в реальность.
Жестокая правда заключается в том, что даже самая расчудесная идея на практике с ненулевой вероятностью окажется совершенно неиграбельным шлаком… или неподъёмной глыбой. Отлично играющаяся в уме игра может получиться в итоге скучной, глупой или просто раздражающей.
Поэтому перед тем, как начать полноценную разработку, очень важно провести прототипирование. Сделать грубые наброски будущей игры - без графики, буквально “на кубиках” (или бесплатных ассетах), из самых базовых, скелетных фич.
Если механика позволяет - имитируйте её на бумаге; нет - реализуйте в движке. Используйте костыли, изобретайте велосипеды, игнорируйте слово “архитектура”, смейтесь в лицо тем, кто заикнётся о масштабировании или оптимизации. 99% написанного на этом этапе кода всё равно пойдёт в мусорку. Единственная важная задача сейчас - за минимальное количество времени нащупать интересный игровой процесс, перепробовав максимальное число вариантов.
Художникам очень хорошо знаком процесс поиска и компиляции удачных находок. Эту технику очень полезно перенять и гейм-дизам!
Главные правила Поиска:
- Делайте максимально быстро, реализуйте только самые необходимые для игры вещи. Нет, 28 видов машинок с разными характеристиками это не самая необходимая вещь. Даже одна моделька машинки сейчас не важна, сойдёт и летающая коробочка.
- Не зацикливайтесь на тупиковом варианте. Чувствуете, что не получается малой кровью сделать игровой процесс интересным в две-три итерации? Начинайте заново, ищите другой концепт или пересматривайте текущий. Если игра про фехтование уныла с мечом, добавления копья и лука скорее всего ситуацию не исправит.
- Не копируйте бездумно. Референсы важны, но они не эталон для слепого подражания. Конкретная механика может отлично работать в другом проекте, а в вашем - быть не к месту, всё сломать… или требовать слишком большого количества ресурсов на реализацию. Постоянно анализируйте вдохновляющие вас игры. К слову, это касается и сюжетов!
- Экспериментируйте. Даже если вы чудесным образом с первого раза собрали что-то прикольное (вероятность этого мала, но не нулевая) - не поленитесь сделать ещё 2-3 варианта, варьируя правила. В худшем случае это просто убедит в правильности пути, в лучшем - позволит найти что-то лучше или даст задел на новые игры.
- Не бойтесь выбрасывать прототипы в мусорную корзину. Всё израсходованное сейчас время вы с лихвой компенсируете потом.
Прототипирование повсеместно используется в "большом" геймдеве, потому что позволяет сократить траты. Согласитесь, очень больно потратить год-два на разработку игры, создание арта, кода… и на финальном этапе понять, что она абсолютно никакая с точки зрения игрового процесса. При том проблемы не в балансе, а носят фундаментальный характер.
Это случается сплошь и рядом даже в попытках дословно повторить какой-то проект - не учли всех нюансов, переоценили свои скиллы… Формально легендарная обладает всеми характерными признаками файтинга, но вот реализация слегка подкачала.
Детали процесса поиска зависят от жанра и проекта. Так, например, если вы делаете классический 2d-квест, с упором на историю и атмосферу, вам нет смысла экспериментировать с геймплеем (лучше вообще взять движок, заточенный под это из коробки - например, AGS), но стоит поискать арт-стиль и собрать играбельную локацию.
В Princess Hunter мы отдельно и разными подходами протипировали Исследование и Боёвку.
Карточные сражения с простенькой механикой без проблем можно было собрать и потестить “на столе”. Я взял пакетики-протекторы, засунул в них карты старой отечественной ККИ “Берсерк” (это нужно для стандартизации рубашек и нужной “плотности”, чтобы колоду можно было легко тасовать) - а поверх них поместил свои, самодельные карты без иллюстраций, с рабочими названиями и свойствами. Здоровье игрока и противников отмечал монетками. В таком виде я не только протестировал игру, но даже попробовать несколько первых итераций баланса.
После этого мы быстро собрали самый примитивный компьютерный билд на черновой графике. К счастью, выбранная нами система не требовала сложного ИИ.
С исследованием было сложнее. Изначально я видел себе её как лабиринт из квадратных тайлов. Мы думали над 2д-вариантами, смотрели в сторону лоуполи 3д…
Но попробовав разные варианты, мы поняли, что они плохо вяжутся с остальной игрой. Трёхмерные (при отсутствии моделлера) к тому же дороги в разработке.
В процессе поисков мы даже собрали диабло-подобный вариант со свободным перемещением по уровню, но он вообще не сочетается с пошаговой боевкой.
...до черновой графики.
В принципе, на этом этап прототипирования можно было бы закончить, но нам была важна не только сама механика исследования, но и визуализация, импакт. Поэтому мы решили сразу более глубоко проработать исследование не только с технической, но и со стилистической точки зрения.
К стилизованным чиби-персонажам на карте мы пришли сразу, а вот окружение пришлось поискать.
Этот скетч зактронул какие-то срунки в наших сердцах!
Перепробовав уйму вариантов, мы, в конечном счёте пришли к 2.5d: трёхмерная сцена, на которой расположены спрайты объектов и персонажей. Эмпирическим путём нащупали угол и настройки камеры, и, в конце концов, добились классного эффекта объёма и глубины.
Анимация перемещения появилась значительно позже, но в остальном билд выглядел именно так.
Собрав начерно первый уровень, мы поняли: это оно! Вот в этом нам хочется поиграть!
Конечно, этот билд уже совсем не “на кубиках”, и по-хорошему это можно выделить в отдельный этап. Но излишний формализм вредит не меньше полного раздолбайства. Помните: вы сами определяете приоритетность каждого шага. Для некоторых проектов стоит начать именно с поиска стиля. Другие начинаются с музыки и настроения. Любая игра требует индивидуального подхода.
На этом заканчивается Подготовка. Про Разработку и Релиз я расскажу в следующей части. Как всегда, самое вкусное - напоследок.
Спасибо всем, кто смог осилить этот пост. Надеюсь, было интересно.
Так задрали холода и хре-новости, что решили просто нарисовать тёплый арт.
Ну и в виде картинки :)
Всем добра!
Глубокоуважаемые пидоры! Реквестирую помощь прогера под юнити
Собственно ситуация такова - мне критически нужен рероллер .
Реролер - минималистичное приложение из 2 окон, бросающее кубики "дайсы" в настолках, по сути рулетка с цифрами от 1 до 6 и возможностью ограничивать максимальное значение ( чтобы например не от 1 до 6, а от 1 до 4)
Подробнее - первый экран это 3 столбца красного, желтого и зелёного цвета. При нажатии на каждую из цифр она фиксируется ограничивая максимальное значение броска кубика.
Второй экран собственно сам реролер в котором в центре рулетка а снизу 3 кнопки соответствующих цветов, при нажатии на любую из которых срабатывает рерол ограниченный максимальной цифрой указанной на кнопке.
Собственно если кто либо готов ворваться в такой ивент - хотелось бы в личке описать вам подробности и услышать желаемую сумму, а так же эстимейт.
Заранее в десна!
TurboSloths Demo v2.0
Приветствую реактор!
У нашего проекта в стиме стала доступна 2х часовая демо версия! Что бы поиграть надо всего лишь...
Для меня, да и всей команды тоже, это событие огромного маштаба, два с лишнем года разработки как ни как, но и игра заметно преобразилась, от грубого протатипа до безумных гонок
А теперь коротко о том что доступно в демо:
-Первая часть компании, в которой будет прокачка, сюжет, пара боссов и именные гонщики соперники
-Быстрые гонки где сразу можно погрузиться в геймплей без долгой раскачки, для оценки режимов (кроме битв с боссами, они сюжетные)
-Игра в SplitScreen с другом (хотя кого я обманываю) сидя на диване, или по RemovePlay
Ах да, всё это безобразие будет проиходить под зажигательный рок!
На данный момент у нас играют:
Ребята просто шикарные, двоих исполнителей поселил у себя в плей листе (Хотя кому это интересно?)
Как то так, спасибо что прочитали (эту рекламную стену) этот пост, всем кто следил, а кого заинтересовал велком в тэг на реакторе! Надеюсь демо зацепит! А мы тем временем усердно доделавыем проект и движимся к релизу, на данный момент игра будет доступна в стиме и VKplay.
Нашему герою предстоит посетить множество миров. Чтобы не заблудиться, он усердно ( и в меру художественных талантов) зарисовывает в походный журнал схемы всех посещенных им уровней.
Здесь мы собираем самые интересные картинки, арты, комиксы, мемасики по теме gamedev (+1028 постов - Разработка игр)
