Войти
Игровая индустрияСтатьиУправление

Как создать игру мечты, опубликовать её и не умереть в процессе.

Автор:

Вольный перевод статьи «How to make your dream game, publish it and not die in the process». Автор Juan Linietsky, главный разработчик игрового движка Godot.

Мотивация
Создавать игры очень весело, но очень сложно
Шаблоны проектирования или отсутствие таковых
Движка не достаточно, важен правильный подход к разработке
Начало. Является ли разработка коммерчески оправданной?
Создание прототипа
Создание вертикального среза
Разработка до альфа-версии
Наполняйте игру ресурсами, двигайтесь к бета-версии
Золото
Издание
Самостоятельное издание
Заключительные слова

Мотивация

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

Создание игры | Как создать игру мечты, опубликовать её и не умереть в процессе.

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

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

Я не стал богатым (пока :D), создавая игры, но в процессе я многое узнал… и сейчас я получаю огромное удовольствие от разработки Godot, большее чем от чего-либо ещё.

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

После выпуска Godot, я видел множество разработчиков, работавших над потрясающими проектами с использованием моего движка. Самое большое преимущество Godot’a заключается в его устройстве, он разработан так, что позволяет вам погрузиться в написание кода, который «просто работает» (и масштабируется до большего проекта) без необходимости беспокоиться за архитектуру игры. Многие игры были выпущены, но еще больше были заброшены.

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

Создавать игры очень весело, но очень сложно

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

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

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

Шаблоны проектирования или отсутствие таковых

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

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

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

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

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

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

Многие читатели наверное уже обратили внимание, что Godot был создан для разработки игр именно таким способом. Он стимулирует рост производительности прежде всего в дизайне. Работа системы сцен позволяет применять в разработке игр подход «разделяй и властвуй» (вместо того чтобы беспокоиться о таких бессмысленных вещах, как MVC, разбиение на компоненты и т.д.). Простота GDScript позволяет писать большие куски кода которые «просто работают», и, как только они будут завершены, вы больше не будете к ним прикасаться. Достижение «ощущения», что вещи находятся на своих местах, было задачей, над который мы совместно с Ariel Manzur работали на протяжении многих лет, до того, как Godot стал open source разработкой.

Несмотря на то что в движке многого ещё не хватает, у нас есть нечто особенное, что никто до нас никогда не создавал.

Движка не достаточно, важен правильный подход к разработке

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

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

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

Начало. Является ли разработка коммерчески оправданной?

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

Не совсем. Именно здесь, 99.9% инди-разработчиков совершают свою главную и самую фатальную ошибку.

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

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

До прототипирования вы должны быть в состоянии ответить на следующие вопросы:

1. Ваша целевая аудитория?
2. Как вы достигнете своей целевой аудитории?
3. Как разработка будет финансироваться?
4. Что делает вашу игру уникальной?

Ответим на эти вопросы:

1. Ваша целевая аудитория? Это первый вопрос, который вы должны себе задать. Просто попытайтесь представить себе, кто будет играть в вашу игру. Распространенные ответы:

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

2. Как вы достигнете своей целевой аудитории? Здесь начинаются сложности. Давайте рассмотрим варианты, перечисленные выше:

3. Как разработка будет финансироваться?

Ниже я рассмотрю стандартные способы поиска финансирования:

Наконец самый важный и самый сложный вопрос:

4. Что делает вашу игру уникальной?

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

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

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

Страницы: 1 2 Следующая »

#Godot, #движки

4 марта 2019

Комментарии [31]