Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 15)
Существуют также ДВИЖКИ ДЛЯ НАЧИНАЮЩИХ РАЗРАБОТЧИКОВ, такие как GameMaker: Studio, Stencyl и др. В отличие от Unity, все-таки требующего каких-то знаний о С#, они вообще не предполагают наличия навыков программирования. Это конструктор, где вы можете собрать игру из готовых частей. Создать новую механику на базе такого движка почти невозможно. Но если разработчики хотят сделать игру дешевле и проще, то это отличный вариант: например,
Также нужно упомянуть о ПРОПРИЕТАРНЫХ (ЗАКРЫТЫХ) ДВИЖКАХ, доступ к которым любому желающему не предусматривается, – например, Frostbite, на котором разрабатывается
Итак, чтобы сделать выбор, прежде всего нужно отсечь движки, которые не подходят выбранной игровой платформе. Если вы делаете типовой проект, скорее всего, лучшим решением станет выбор универсального движка, Unity или Unreal. Если вам нужны оригинальные решения или игра специфического жанра, посмотрите более специализированные варианты: например, создавать визуальную новеллу лучше на базе специально разработанных для этого жанра движков. Если в вашей команде нет опытного программиста, стоит обратить внимание на движки для начинающих. Если для проекта нужно много программирования, а ваш программист уверенно владеет только C#, имеет смысл выбрать соответствующий движок.
Далее следует определиться с требованиями к качеству графики. Даже инди-команды, используя, например, Unreal, могут рассчитывать на качественную и красивую картинку при наличии хороших моделей. Помните, что пропасть между «отличной» и «просто хорошей» графикой за последние годы сильно сократилась.
Использовать опыт предшественников – тоже хорошая идея. Если у вашей игры есть референсы, логично посмотреть, на каком движке они были созданы, и проанализировать, почему было принято то или иное решение.
Игровые прототипы
Прототипы – это неконечные игровые продукты, создаваемые для того, чтобы проверить свои идеи и ответить на вопросы. Например:
• работают ли наши гипотезы и основные фичи;
• работают ли они так, как мы запланировали;
• играют ли люди в нашу игру так, как мы запланировали;
• может ли понравиться игра нашей аудитории;
• какие части нашей игры вызовут у нас наибольшие сложности.
Создание прототипов позволяет как можно скорее выявить слабые стороны проекта и устранить их. Прототип, созданный с целью ответить на конкретный вопрос или вызов, – самый полезный. «Интересно ли будет играть в мою игру?» – пример плохого вопроса. Лучше: «Как долго сохраняется интерес к основному геймплею?» или «Сколько анимированных объектов в одной сцене в максимальном качестве поддерживает наш движок?» Версия для среза первого впечатления от игры не сможет ответить на вопрос, не будет ли скучно играть пятнадцатую сессию, поэтому следует четко обозначить цель исследования.
ГЕЙМПЛЕЙНЫМИ ПРОТОТИПАМИ называют версию продукта, в которую так или иначе можно поиграть и проверить игровые механики. Например, как работает боевая система или сколько нужно времени, чтобы пробежать конкретный уровень платформера.
Проверяется либо комбинация более или менее стандартных идей, либо жизнеспособность и последствия инновационных решений. Цель здесь – выявить проблемы, над которыми мы по тем или иным причинам не задумывались.
Ответы нужно получить максимально быстро. Если прототип отвечает на поставленные вопросы, абсолютно неважно, в каком качестве он сделан.
Бывают чисто ФУНКЦИОНАЛЬНЫЕ ИЛИ МЕХАНИЧЕСКИЕ ПРОТОТИПЫ, созданные, чтобы проверить гипотезы без каких-либо программ. Это могут быть, например, бумажные прототипы: настольная игра или просто нарезанные листочки бумаги. Таким способом отлично тестируются всевозможные разновидности стратегий и карточных игр.
Если ваша игра про принятие решений и игровую механику, бумажные прототипы – это то, с чего следует начинать. Это экономит кучу времени и сил, ведь выкинуть бумажку и написать новую – намного проще, чем править код.
Этот способ будет вполне эффективным даже для создания прототипов шутеров от первого лица. Если на каждое действие вы выделите своим игрокам определенное количество секунд (с помощью секундомера, например), то сможете пошагово изучить механики даже для игры в реальном времени: сколько шагов или выстрелов в секунду может сделать игрок, какого размера карта нужна для каждого уровня, какой вид оружия эффективен против монстров с разными характеристиками, сколько патронов и здоровья необходимо и так далее.
Если играется хорошо, стоит попробовать собрать прототип в простой игровой системе. С помощью готового игрового движка, разработка на котором будет наименее затратной, проверяем, насколько интересны придуманные нами игровые механики, полностью пренебрегая графикой. На этом этапе стараемся использовать максимум готовых решений: программы и низкоуровневые движки, которые позволяют быстро скомпоновать из ассетов базовый геймплей. Если игра планируется на Unreal Engine 4, прототип для нее все равно вполне можно собирать с помощью Game Maker и аналогичных программ, главное – быстро, просто и дешево; лучше использовать знакомые инструменты, чтобы не тратить время на изучение новых.
Для создания прототипов можно использовать и чисто графические методы (Flash, Figma и пр.), тогда эта работа ложится на плечи художника-дизайнера. Этот метод подходит для игр, где важно проверить, например, как решения игрока влияют на геймплей (в какую сторону он отправился, какой вариант в ветке диалогов выбрал и прочее).
Ради упрощения создания прототипов допустимо срезать целые пласты геймплея. Для комплексных, сложных игр лучше вообще тестировать отдельный функционал и игровые механики.
Когда вы проверяете какие-то инновационные идеи, которые нельзя найти в Unity или Unreal Engine, задача усложняется. Есть несколько вариантов решения этой проблемы.
Если мы хотим протестировать какую-то комплексную систему, можно попробовать использовать наработки предшественников. Допустим, вы хотите добавить в игру механику осады замков. Чтобы оценить, впишется ли фича в игру, уже многое должно быть готово (боевая система, прокачка персонажей). Создавать целую игру, чтобы проверить одну фичу, долго и неэффективно. Стоит постараться найти движок наиболее похожей игры и «прикрутить» туда нужный функционал.
Другая ситуация: сложный технический запрос. Например, гейм-дизайнер задумал сделать жидкого персонажа, который должен правдоподобно перетекать, менять форму, иметь определенные способности и адекватно взаимодействовать с более привычными героями. Такого с помощью готовых решений не соберешь, подыскать подходящую программу может быть проблематично. Обычно над такими нетривиальными задачами трудится отдельный программист, задача которого – максимально быстро написать код нужной нам системы. Такой прототип не ответит на вопрос о стабильности решения или совместимости с полноценным движком, просто нужно в сжатые сроки сформировать и оценить задуманный геймплей.
МАТЕМАТИЧЕСКИЕ ПРОТОТИПЫ создают, чтобы убедиться, правильно ли работают математические расчеты. Причем методы могут быть вообще не связаны с реальной игрой, а работающий над ними специалист может обладать знаниями скорее в области математики, нежели гейм-дизайна.
Чтобы создать АРТ-ПРОТОТИП, необходимо проанализировать игры, которые мы считаем конкурентами, и оценить стандарты индустрии для выбранного жанра. Причем не только сегодня, но и на момент предполагаемого выхода игры. После этого арт-директор и технический художник (или кто-то, выполняющий их функции) принимают решение, графику какого качества мы хотим обеспечить в нашей игре.
Принципиальное отличие от геймплейных прототипов состоит в том, что даже на раннем этапе, когда еще может не быть проработана игровая логика, арт-прототип нужно делать на выбранном движке. Если вы сумели продемонстрировать запрашиваемый уровень графики на CryEngine, нет никаких гарантий, что такую же картинку покажет Unreal Engine 4. Проблемы на данном этапе вполне могут быть аргументом для того, чтобы отказаться от одного движка в пользу другого.
В результате принятых решений необходимо создать арт-прототип – демонстрационную сцену. В зависимости от поставленных задач мы таким образом проверяем, могут ли наши художники красиво нарисовать нужную картинку, или, при другом подходе, оцениваем технические возможности нашего движка, сделав высокополигональную[49], но при этом совершенно необязательно красивую, модель.
Такие ТЕХНИЧЕСКИЕ ПРОТОТИПЫ проверяют производительность или технические идеи. В первом варианте методы те же, что и с арт-прототипом, – собрать сложную, нагруженную сцену и посмотреть, как все работает на целевом железе. Это необходимо для понимания, насколько мы сможем оптимизировать игру к моменту запуска. Особенное внимание здесь уделяют сложным сущностям: большому количеству однотипных объектов в кадре, сложным анимационным системам, разрушаемым объектам.