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

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

Уточнение и исследование
(изображение из блог Intercom )

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

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

47 голосов | спросил Jonas Byström 21 PMpTue, 21 Apr 2015 14:38:43 +030038Tuesday 2015, 14:38:43

7 ответов


1

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

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

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

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

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

Код Throwaway был одним из Nevermind's вынос. Я полностью согласен, и Трабант применяет его.

ответил Jonas Byström 28 Mayam15 2015, 11:15:55
28

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

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

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

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

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

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

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

ответил Trevor Powell 21 PMpTue, 21 Apr 2015 15:30:40 +030030Tuesday 2015, 15:30:40
17

Чтобы прототип хорошо, уменьшите стоимость тестирования идей.

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

ответил Anko 21 PMpTue, 21 Apr 2015 15:47:34 +030047Tuesday 2015, 15:47:34
10

Как разработчик, сосредоточенный в основном на прототипировании, вот немного советов из моего опыта.

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

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

ответил Nevermind 21 PMpTue, 21 Apr 2015 18:42:55 +030042Tuesday 2015, 18:42:55
4

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

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

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

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

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

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

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

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

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

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

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

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

ответил Kostas 22 PMpWed, 22 Apr 2015 12:24:57 +030024Wednesday 2015, 12:24:57
3

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

ответил Don Kirkby 21 PMpTue, 21 Apr 2015 23:56:38 +030056Tuesday 2015, 23:56:38
0

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

Его как хороший код ...

Много IFs там.

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

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

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

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

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

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

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

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

ответил helena4 23 J000000Thursday15 2015, 12:51:48

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132