Когда я создаю прототипы, как мне легче исследовать игровое поведение?

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

^{(фотография из блога Интерком )}

Например, я считаю, что итерационные циклы для настройки поведения (то есть связывание и перезапуск приложения C ++) настолько длинные, что убивают все творческие способности. Я создаю инструмент, чтобы справиться с этим.

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

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

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

Многие крупные современные движки (Unity, Unreal и т. Д.), Как правило, делают это, помещая их редактор в игровой движок, так что вы можете делать большинство модификаций вживую, даже не перезапуская игру. Меньшие движки / игры обычно сосредотачивают работу в другом направлении; сделать так, чтобы игра компилировалась и запускалась так быстро, что не имеет значения, нужно ли вам перезапускать игру для каждого изменения; вы все еще будете тестироваться до истечения этого пятисекундного периода.

В моем текущем проекте мне потребуется около десяти секунд, чтобы выполнить небольшую перекомпиляцию, связать, запустить игру и затем перейти к игровому процессу (большая часть этого генерирует визуализируемую геометрию мира при загрузке сохраненной игры). И это слишком долго. Поэтому я создал отдельные «тестовые» игровые режимы, которые позволяют мне тестировать различные части игры, не загружая все реальные игровые ресурсы, поэтому я могу входить и выходить намного, намного быстрее; обычно через две-три секунды. Если я хочу протестировать некоторый интерфейс, я могу сделать это без загрузки в настоящую игру. Если я хочу проверить рендеринг, у меня есть другой режим, в котором я могу проверить это, опять же, не загружая всю игровую систему.

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

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

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

Хорошо прототипируйте, уменьшите стоимость идей тестирования.

Мой рабочий процесс настроен для небольших игр, но я нашел эти вещи полезными:

• Технология, дружественная к прототипам.  Мне показалось полезным использовать динамический язык программирования и фреймворк, такие как Lua ( LÖVE хорош для 2D), JavaScript или Lisp / Scheme, где для того, чтобы заставить программу что-то сделать, требуется минимальное нажатие клавиш, даже за счет затрат. всего остального. Как только вы знаете, что вы хотите, и хотите улучшить его, оптимизируйте или портируйте на какой-нибудь другой движок.
• Контроль версий.  Храните прототипы в хранилище с контролем версий . Ветвь ранняя, ветвь частая. Это позволяет вам чувствовать себя комфортно, не беспокоясь о том, что вы потеряете или забудете что-то. (У Git самая дешевая модель ветвления.)
• Автоматизация сборки  Убедитесь, что вам нужно сделать как можно меньше для того, чтобы запустить работу. На мой взгляд, даже не нужно нажимать кнопку слишком много: я обычно есть Makefileс make watchцелью , которая бежит inotifywaitв петле, реагирующих на изменения файлов, автоматически компиляции / запуска игры. В интерпретируемом или JIT-скомпилированном языке это происходит мгновенно.

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

1. Используйте движок, который позволяет вносить изменения БЫСТРО. Это включает в себя такие вещи , как «Не дожидаясь компиляции», но и «изменить положение вещей во время выполнения», «легкость отладки», «доступность тестовых активов» и т.д. Я лично люблю Unity3D, но это не лучший инструмент там. Лучший инструмент зависит от игры: например, Unreal Engine компилирует код медленнее, чем Unity3D, но может быстро запускать несколько подключенных клиентов. Для сетевой игры это часто компенсирует затраты на компиляцию. Учтите также знакомство. Если вы одарены C ++, даже лучший движок Javascript не принесет много пользы, и наоборот. Не тратьте время на борьбу с незнакомыми технологиями (я имею в виду, изучайте другие языки / фреймворки, но не одновременно с созданием важных прототипов).
2. Научитесь беспощадно отбрасывать существующие функции. Привязка к вещам, которые вы уже реализовали, является анафемой для успешного создания прототипов, но отказаться от своей работы сложно.
3. Если вы не работаете с игровым дизайнером, проведите четкую грань между «ношением шляпы программиста» и «ношением шляпы дизайнера». Добавление новой классной игровой функции кажется очень заманчивым, но не делайте этого, когда вы находитесь в положении дизайнера. Скорее попробуйте создать увлекательный игровой процесс (желательно несколько вариантов) с тем, что у вас есть; составить список функций, которые могли бы помочь, а затем реализовать (некоторые из них) их.
4. Быстрое прототипирование предполагает баланс между двумя противоположностями. Вы хотите сделать вещи как можно быстрее, поэтому вы пишете плохой код. Но вы хотите как можно больше менять вещи, поэтому вы должны написать хороший код! Учитесь балансировать эти два. Извините, я не могу придумать какой-либо конкретный совет о том, как на самом деле это сделать, но, по крайней мере, осознаю эту проблему (-8

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

Можно разделить разработку игр между этими четырьмя фазами:

• макетирования
• уточнение игрового процесса
• развитие
• улучшение производительности

Я считаю, что изучение игрового процесса происходит в основном на этапе создания прототипа, и вот несколько советов, которым я стараюсь следовать:

• Начните проектирование с бумажного прототипа. После того, как у вас будет четкое представление о том, какой может быть игра, начните ее кодировать, чтобы вы могли реально почувствовать взаимодействие. Может быть, это бесполезно для 3D-игр, но лично мне это очень помогло в прошлом.

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

• Быстрые итерационные циклы важны (как уже указывали другие). Выберите игровой движок, основанный на его способности быстро показать вам то, что вы кодировали. Вы также не должны заботиться о производительности или графической точности на этом этапе.

• Ограничьте вашу сферу. Если реальный игровой процесс 2D (обычная стратегическая игра, JRPG), прототип в 2D. На этом этапе вам важны только отзывы об игровом процессе .

• Не тратьте время на полировку или поиск активов. Нарисуйте что-нибудь на бумаге, сфотографируйте, порежьте в Photoshop, возможно раскрасьте и используйте в качестве спрайта. Включите микрофон и скажите «пиу пиу». Положите два кубика и сферу вместе, и у вас есть робот. Всегда имейте в виду, что изучение возможностей игры является вашим первым и единственным приоритетом.

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

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

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

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

Я согласен с ответом Тревора Пауэлла, что скорость итерации крайне важна для вас, чтобы оставаться в творческом настроении, а не просто полировать. Большой источник вдохновения для меня - выступление Брета Виктора «Изобретая по принципу» . К сожалению, трудно найти реальные инструменты на этом уровне. Я сам пытался создать его для разработки на Python, который позволял бы мне запускать код Python во время его набора. Это называется Live Coding в Python .

Я создал инструмент для создания прототипов под названием Trabant, который:

• это ТОЛЬКО 3D и игровая механика (без интерфейса, без текста, ничего);
• требует очень мало кода и никаких ресурсов для создания прототипа;
• 3D модели создаются в коде с использованием ASCII art ;
• позволяет итерацию за секунду;
• имеет поддержку моделирования твердого тела;
• работает на Windows, Mac, Linux и iOS;
• использует известный язык общего назначения, Python;
• имеет IDE для Windows и iOS.

Я построил 30 тестовых прототипов в нем, чтобы проверить выше.

Как подчеркнул Тревор Пауэлл, итерации должны составлять <5 секунд, и я считаю, что итерации <1 с почти в пять раз лучше.:)

Анко отметил, что использование динамического языка - хорошая идея, я выбрал Python, поскольку он является одним из наиболее широко используемых . Что касается автоматизации сборки, тестирование в Trabant выполняется так же быстро, как нажатие клавиши F5 в IDE (или F6, чтобы протестировать ее на iPad), и, поскольку в этом случае нет никакого шага сборки, оно не становится более быстрым, чем это.

Одноразовый код был один из фиги в выносе . Я полностью согласен, и Трабант навязывает это.

В дополнение к скорости итераций Тревора Пауэлла, которая действительно важна, вот еще несколько полезных соображений:

Это как хороший код ...

Там много IFs.

Чем солиднее концепция, тем меньше нужно играть. Если вы знаете, что мясо, которое вы пытаетесь сделать, становится прототипом - что ставить и как расставлять вещи по отношению к центральной опоре (ваше главное).

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

В любом случае приверженность технологии не имеет значения, если то, что вы ищете, может быть смоделировано без особой глубины - создайте прототип на том, что вы хотите / можете.

Не тратьте лишнюю секунду на ресурсы. Загрузите все из Интернета. Фирменный или нет. Вы хотите почувствовать свою концепцию на работе - если графика не является вашей основной особенностью, никто не собирается предъявлять вам иск за эксперименты со звуками других людей, текстурами и всем остальным, пока вы не положите ее на полку в магазине. Если вы уже не профинансированы - убедить людей в том, что концепция стоит того, - это то, что даст вам деньги, чтобы получить ресурсы, которые вы хотите. Я видел, как ребята из игровой студии представляли игровые концепции с модифицированными версиями проприетарных игр, на которые у них нет прав.

Это как вы строите масштабную модель. Хотя это здорово иметь миниатюрную жизненную копию того, что вы хотите. Иногда достаточно вырезать его из журналов, изготовить вручную и склеить кусочки. Каждый, у кого есть воображение, не собирается думать, что вы на самом деле построите небоскреб из того же картона, с которым вы показали масштабную модель. А в творческих индустриях - это своего рода предпочтительнее работать с людьми с неким воображением. Если они не могут заглянуть за черновик некоторых проблем, чтобы увидеть потенциал всей концепции, они редко, если вообще оценят продукт. Отсутствие признательности означает, что они менее готовы совершать, и это нисходящая спираль. Разница в том, как настроить отношение вашего ребенка к покорению мира и вместо этого сказать: «Вы даже не можете правильно завязать свои ботинки, маленькая глупость,

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

Однажды я прототипировал игру, используя исключительно изображения в формате gif и давая им немного общего с javascript. Это не ослепительно, но оно показало, что я хотел показать. Не важно, будете ли вы позже разрабатывать его исключительно для Xbox.

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