Советы для команды из одного разработчика

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

Вы можете сделать такую игру?

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

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

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

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

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

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

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

Первые 90% кода приходятся на 90% времени разработки. Оставшиеся 10% кода приходятся на другие 90% времени. Том Каргилл из Bell Labs

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

Чем больше ваша игра, тем больше мелочей вам предстоит исправить. Поэтому всегда держите в виду временные рамки.

Классная идея, но как насчет вашей игры?

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

Предположим, что вы делаете 2D-платформер, с подводным сеттингом и крутой механикой веса. Звучит отлично, но вы не сможете создать код «крутой механики веса». Нужно разбить задачу на части, чтобы понять, как это будет работать на определенном уровне.

  • Каким образом игрок становится легче или тяжелее?
  • Как это повлияет на взаимодействие между игроком и врагами?
  • Кто выступит в качестве врагов?
  • Каковы их модели поведения?
  • Могут ли они взаимодействовать со сценой?
  • Какие объекты находятся на уровне?
  • Как они взаимодействуют с игроком и врагами?

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

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

Часть бумажной карты Shadow Complex

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

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

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

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

Разве это не задача прототипов?

Прототип разбирается почти в каждом постмортеме о разработке игры. «Создавайте прототипы и тестируйте, пока не создадите то, что вам понравится».

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

Прототипирование и тестирование занимают свою определенную нишу в разработке игры в одиночку. Просто нужно проделать это по другому.

Много слов было сказано о прототипах, во время интервью с разработчиками этой игры

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

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

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

Конечно, все зависит от платформы разработки. Если вы делаете прототип там, где много вещей уже было сделано за вас (GameMaker или даже редактор уровней LittleBigPlanet), то создание прототипа займет не так много времени и усилий, особенно для одного разработчика. В этом случае, создавайте столько прототипов, сколько душе угодно!

Я могу начать прямо сейчас?

Когда у вас будет готовый дизайн, выработанная специфика того, как все будет работать, и вы будете точно знать, как поступить с прототипом, тогда все готово!

Спасибо за внимание!