Как правильно создавать демки
Art Of Play делится советами о том, как создать демо-версию, используя правильные инструменты, методы коммуникации и командную работу, в рекордно короткие сроки.
Работающая демо-версия позволяет протестировать игровую механику и получить представление о том, как будет играть готовая игра, гораздо больше, чем любой дизайн-документ игры или макет. Это как полезный внутренний инструмент для тестирования концепции перед началом полномасштабного производства, так и часто необходимый шаг для получения одобрения клиента или привлечения потенциальных инвесторов. За последнее десятилетие Art Of Play создала более 70 игр и более 150 демо-версий, и на этом пути мы обнаружили, что работает, а что нет, в основном методом проб и ошибок. В этой статье мы поделимся с вами некоторыми советами и приемами, которые помогут вам быстро и эффективно создать надежную демо-версию, а также расскажем о некоторых подводных камнях, которых следует избегать на этом пути.
Первым шагом, конечно же, является придумать концепцию. Идеи могут прийти откуда угодно, например, из ретроспективного анализа прошлых проектов. Спросите себя, что сработало, чего бы вы хотели больше или меньше, что было бы веселее, если бы это изменилось? Идеи также могут исходить из игры в другие игры или другие средства массовой информации (книги, фильмы) или просто из жизни в целом. Работающая демо-версия позволяет получить представление о том, как будет играть готовая игра, гораздо больше, чем любой дизайн-документ игры. Леммингс, например, начинался как милая маленькая пиксельная анимация, которую один из основателей DMA Design создал в попытке научиться рисовать в Deluxe Paint на Amiga без какой-либо игры в голове. Как только анимация собралась воедино, он начал представлять, как этот персонаж может работать в игре, и остальное, как говорится, уже история.
Идеи иногда могут звучать отлично на бумаге или на встрече, но часто только создав небольшой прототип, вы закрепляете эту идею. Иногда вы находите золото, чаще вы обнаруживаете, что некоторые вещи не работают или вы, возможно, упустили из виду проблему, которую необходимо решить. В любом случае, это важный этап в процессе разработки игры, и превращение первоначальной концепции в рабочую и полезную демо-версию - это и наука, и искусство.
Наука: техническая сторона вопроса
Разработчики игр часто любят говорить о наборах инструментов, которые они используют для создания игр - о новейших и лучших фреймворках, плагинах или шейдерах. Но не менее важны (возможно, даже более важны) инструменты и системы, которые вы внедряете для общения, как внутри студии, так и за ее пределами с клиентами, издателями и инвесторами. Большинство из нас работали в студиях в прошлом, где время утекало на бесконечные и иногда, казалось бы, ненужные встречи. Современное программное обеспечение и инструменты означают, что независимо от того, находится ли вся ваша команда в одной комнате или вы разбросаны по разным континентам, поддерживать постоянную связь и делать это эффективно и результативно никогда не было так просто.
Думайте об инструментах, которые находятся в вашем распоряжении (технические инструменты для создания игр, инструменты для управления командой и общения), как о частях одного набора инструментов. Крайне важно, чтобы вы и ваша команда решили на ранней стадии, какие инструменты и каналы вы будете использовать, и придерживались их, научившись работать с ними вдоль и поперек.
Если ваше внимание разделено между Slack, Basecamp, Discord и электронной почтой, что-то обязательно потеряется. Вы будете получать дублирующие сообщения и не будете помнить, где находилась информация, когда вы впервые увидели или опубликовали ее. Настройте один канал для каждого типа связи и придерживайтесь его. Не нужно много отвлекающих факторов, чтобы замедлить работу, поэтому дайте своей команде пространство, необходимое для эффективной работы.
Если вы работаете в нескольких часовых поясах, важно планировать встречи по мере их необходимости. Когда реальное время не требуется, придерживайтесь предпочитаемого инструмента связи, такого как Basecamp или Discord, где сообщения можно публиковать и просматривать, когда это удобно каждому члену команды. Даже если вы все находитесь в одном часовом поясе или даже в одном физическом месте, избегая необходимости чрезмерного общения в реальном времени, вы можете помочь поддерживать процесс в движении.
Каждый программист знает ощущение, когда в голове удерживается сложный процесс, над которым он работает, а затем его прерывают, и нужно десять минут, чтобы снова войти в "зону". Не требуется много отвлекающих факторов каждый день, чтобы действительно замедлить работу, поэтому дайте своей команде пространство и инструменты, необходимые для эффективной работы и общения.
Мы можем сократить количество времени и усилий, необходимых для создания ресурсов на ранней стадии, избегая совершенства и максимально используя заполнители. Однако, когда дело доходит до сокращения или повторного использования работы вашей команды, сведение активов к минимуму - это только одна из областей, на которой нужно сосредоточиться. Со временем вы накопите библиотеку контента и опыта. С каждым создаваемым проектом, будь то полностью проработанная и выпущенная игра или небольшой прототип, который вы решаете не продвигать дальше, вы узнаете что-то новое и, вероятно, создадите некоторые ресурсы и напишете новый код, который может пригодиться в будущем.
После каждого проекта, независимо от его размера, полезно проанализировать его и обсудить с командой. Выясните, что сработало, а что нет, и это станет частью вашей коллективной "библиотеки опыта". Вы можете использовать этот опыт как короткий путь при обсуждении будущих проектов, чтобы ускорить процесс: "Эй, почему бы нам не сделать это как ABC, как мы делали в проекте XYZ?" Чем больше проектов вы работаете, тем чаще вы сможете указывать на что-то из предыдущего проекта, чтобы использовать в качестве примера и черпать идеи.
То же самое делайте с вашим кодом и ресурсами. Если вы разработали какой-либо новый код, который может быть полезен в другом проекте, подумайте о том, чтобы поместить его в библиотеку или модуль, который может стать частью вашего фреймворка или набора инструментов в будущем. Нет смысла изобретать велосипед снова и снова. Каждый раз, когда вы повторно используете код из предыдущего проекта (если он был хорошо написан и эффективно внедрен в новый проект), вы повышаете свою эффективность и сокращаете время, необходимое для создания следующей демо-версии или достижения следующей вехи.
Нет смысла изобретать велосипед снова и снова
То же самое касается и ресурсов. Хотя обычно вы не сможете повторно использовать финальные ресурсы из игры (если только вы не делаете продолжение или другую игру с той же интеллектуальной собственностью), часто можно повторно использовать заполнители, по крайней мере, на ранних этапах разработки демо-версии, которые можно заменить позже.
Можно потратить огромное количество времени на создание графических и звуковых заполнителей или даже просто на просмотр библиотек стоковых ресурсов. Если вы сможете создать внутреннюю библиотеку (и хорошо ее организовать), вы обнаружите, что сможете быстро взять то, что вам нужно, и просто начать строить намного быстрее.
Демо-версия - это не игра; она не предназначена для выпуска, и поэтому ей не нужна высокая степень полировки. Часто возникает соблазн сделать вещи красивыми и добавить функции и изыски, чтобы впечатлить клиента/инвестора, но основное внимание должно быть сосредоточено на том, чтобы как можно быстрее достичь точки, когда механика, уровень или система работают достаточно хорошо для тестирования.
Демо-версия не предназначена для выпуска, и поэтому ей не нужна высокая степень полировки
Если что-то не работает, вы хотите узнать об этом на ранней стадии, чтобы иметь возможность изменить это или отказаться от этого и перейти к другой идее; на языке стартапов вы хотите "быстро потерпеть неудачу". Если вы стремитесь к совершенству на каждом этапе, вы тратите слишком много времени и ресурсов на эти ранние сборки, которые тратятся впустую, как только вы меняете направление. Есть время для стремления к совершенству, и это время наступает после того, как у вас есть надежная демо-версия, которую вы доработали и протестировали, та, которая, по вашему мнению, может быть превращена в выигрышную игру.
Так же, как избегание бюрократии и поддержание рационализированных коммуникаций означает, что вы сохраняете ресурсы и остаетесь сосредоточенными, активное избегание любых попыток достичь совершенства сохранит вашу команду гибкой и движущейся к вашей цели.
Простые ресурсы-заполнители, базовые планировки уровней, стандартный текст - все это можно быстро и легко создать, и это означает, что вы можете сосредоточиться на основной задаче создания и тестирования демо-версии. Как только у вас появятся идеи, закрепленные в рабочей демо-версии, вы сможете изменить фокус и начать совершенствовать каждую область.
Искусство: сторона клиента и команды
Разработка игр действительно является воплощением брака между технологиями и искусством. Независимо от того, насколько сильны ваши технологические навыки, вы также должны поощрять и развивать творческое мышление в своей команде.
То, насколько творческой свободой вы обладаете, может сильно варьироваться от проекта к проекту. Если вы разрабатываете игру по найму в соответствии со спецификациями клиента, они вполне могли предоставить вам очень конкретные детали в документе по дизайну игры. На другом конце шкалы, если вы разрабатываете игру на основе собственной интеллектуальной собственности, а демо-версия является инструментом для привлечения инвесторов или издателя, у вас будет полная творческая свобода. Скорее всего, вы окажетесь где-то посередине.
Spongebob Squarepants: Code A Character была создана Art of Play для Nickelodeon International
Неважно, состоит ли ваша команда только из вас и партнера или офисов, заполненных сотрудниками в нескольких местах - поощрение инноваций, поддержка креативного мышления и предоставление возможности всей команде придумывать идеи и тестировать их имеет жизненно важное значение.
Легко загнать в рамки. "Джек - дизайнер", "Салли - программист", но лучшие идеи часто приходят, когда люди мыслят нестандартно, а это значит за пределами своего пузыря или области знаний. Будь то широкая концепция игры или идея для небольшой подмеханики, дизайна уровня или особенности, предоставление возможности всей команде выдвигать свои идеи означает, что вы опираетесь на более широкий спектр опыта и в конечном итоге имеете больше шансов найти лучшие решения.
Как только у вас есть эта основная идея, именно команда превратит ее из концепции в демо-версию. Для этого крайне важно, чтобы структура студии позволяла быстро повторять итерации и обеспечивала гибкую рабочую среду. Это означает возвращение к вашему набору инструментов, обеспечение наличия правильных ресурсов и предоставление вашей команде возможности выполнять свою работу, не увязая в бюрократии и процессах утверждения.
Бюрократия, внутренняя политика и необходимость одобрения на каждом шагу - это смертный приговор для быстрого создания демо-версии. Хотя обычно требуется определенное количество бюрократии (особенно если вы работаете на основе брифа клиента), сведение ее к минимуму означает, что каждый может заниматься своей работой и поддерживать движение вперед.
Внутренняя политика и необходимость одобрения на каждом шагу - это смертный приговор для быстрого создания демо-версии
В этом случае небольшая команда, как правило, имеет преимущество перед большой командой. Небольшая команда из менее чем десяти человек, работающая физически в одном пространстве или распределенная, позволяет относительно легко всем быть на одной волне, знать, что делают другие, и постоянно общаться друг с другом.
Со временем вы лично узнаете каждого члена команды, узнаете их сильные и слабые стороны. Чем лучше вы знаете других членов своей команды и то, как они любят работать, тем меньше времени нужно тратить на встречи и тем быстрее вы можете двигаться.
Большие команды тоже могут быть гибкими, но по своей природе больше времени и усилий будет потрачено на управление командой, распределение ролей и поддержание всех на одной волне. Именно здесь системы связи, инструменты и структура, о которых упоминалось ранее, становятся еще более важными.
Еще одним преимуществом небольших команд является то, что по своей сути небольшая команда требует, чтобы каждый человек носил несколько шляп, что может уменьшить количество взаимодействий в проекте. В большой студии, где программисты - это программисты, а художники - это художники, программист может подать заявку на ресурс и ждать, пока этот ресурс будет создан и доставлен художественной командой.
В небольшой студии у этого программиста, вероятно, есть некоторые художественные навыки (а у художников, вероятно, есть некоторые базовые навыки программирования), чего обычно более чем достаточно, по крайней мере, для создания заполнителей или внесения небольших корректировок в код, чтобы поддерживать движение вперед. Независимо от того, в какой студии вы находитесь, рассмотрите возможность расширения своего набора навыков. Наличие возможности носить несколько шляп и предоставление вашей команде возможности делать то же самое ставит вас в гораздо более сильную позицию и помогает поддерживать вращение колес.
Будь то 30 дней или три месяца, наличие крайнего срока, к которому нужно стремиться, помогает держать проект на правильном пути и предотвращает разрастание функций и раздувание. Работа любого характера имеет коварную привычку расширяться, чтобы заполнить любое время, которое вы ей отводите, и в этой области легко продолжать добавлять новые функции и больше полировки. Но это может привести к тому, что проект никогда не достигнет финишной прямой. Если вы хотите, чтобы ваша игра не стала следующей Duke Nukem Forever и действительно увидела свет в разумные сроки, работа в направлении дедлайнов является необходимой частью процесса.
Как только у вас есть крайний срок, вы должны осознавать, что вы ограничены и есть пределы того, чего вы можете достичь. Это означает, что ваш клиент (и мы используем этот термин в самом широком смысле - вашим "клиентом" могут быть потенциальные инвесторы или даже просто вы и ваша команда) должен быть осведомлен, что демо-версия - это всего лишь демо-версия, а не готовая игра.
Это означает, что сначала нужно принять трудные решения о том, что включить - и, следовательно, что не включать - в демо-версию, а затем четко сообщить, в чем будет разница между вашей демо-версией и вашей готовой игрой.
Как только у вас есть крайний срок, вы должны осознавать, что вы ограничены и есть пределы того, чего вы можете достичь.
У демо-версии есть несколько ролей. Прежде всего, она позволяет вам проверить, является ли ваша концепция увлекательной, но это также и инструмент коммуникации. Поскольку вы ограничены подмножеством функций вашей финальной игры, вы должны сосредоточить демо-версию на сути того, что уникально для вашей игры. У вас есть уникальная игровая механика или новая система управления? Это ваш художественный стиль выделяет вас из толпы? Поднимают ли ваши дизайны уровней вашу игру над другими в этом жанре?
Если ваша демо-версия сфокусирована на уникальных аспектах игры, вы можете использовать другие инструменты коммуникации, чтобы рассказать остальную часть истории. Сообщите своему клиенту с самого начала, что будет/не будет в демо-версии, и рассмотрите возможность дополнительного контента, чтобы заполнить пробелы. В зависимости от типа и масштаба игры, это могут быть раскадровки, концепт-арт, видео-макет или что-то еще.
Независимо от среды, выделение времени на планирование вашей стратегии и решение о том, как вы будете обеспечивать, чтобы все были на одной волне с самого начала, позволит поддерживать двигатель в хорошо смазанном состоянии и гарантирует, что вы останетесь на правильном пути, чтобы предоставить демо-версию, которая делает именно то, что вы задумали.
Заключение
Быстрое и эффективное создание демо-версии по сути сводится к трем вещам: опытная команда, которая может работать самостоятельно, но хорошо общаться и сотрудничать друг с другом, правильный набор инструментов (как для разработки, так и для общения) и правильный образ мышления и привычки.
При наличии этих трех вещей вся команда может оставаться на правильном пути, минимизировать ненужную бюрократию и оставаться сосредоточенной на общей картине создания выигрышной демо-версии, а не на мелочах попыток совершенствования и полировки на каждом шагу пути.
Чем больше прототипов и демо-версий вы можете создать, тем больше опыта вы получите, но также больше шансов "найти золото". Angry Birds была 52-й игрой, разработанной Rovio. Первые 51 игры не были "провалами", но они, конечно, не были таким безумным успехом, как Angry Birds, и все же я подозреваю, что каждая из этих 51 игр наращивала их опыт и системы до точки, где Angry Birds стала возможной.
Будь то создание демо-версии к дедлайну для показа клиенту/инвестору или разработка собственной интеллектуальной собственности, как это делала Rovio еще в 2013 году, переход от концепции к демо-версии как можно быстрее и эффективнее означает, что вы можете повторять этот процесс, пока не придете к выигрышной формуле. Как только у вас будет выигрышная демо-версия, в которую интересно играть даже с графикой-заполнителем и отсутствием полировки, вы будете знать, что готовы превратить ее в полноценную игру и дать этим птицам взлететь!