Совет для прототипирования #7: Выберите легко редактируемый игровой движок

Традиционный метод разработки ПО чем-то напоминает выпекание хлеба:

1 Написание кода

2 Компиляция и компоновка

3 Запуск игры

4 Поиск в игре той части, которую нужно тестить

5 Тестинг

6 Назад к шагу 1

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

1 Запуск игры

2 Поиск в игре той части, которую нужно тестить

3 Тестинг

4 Написание кода

5 Назад к шагу 3

Если код можно менять, когда игра запущена, это ускоряет весь процесс и позволяет вам проходить больше циклов в день, что, в свою очередь, повышает качество вашей игры. Раньше я использовал Scheme, Smalltalk и Python (я большой фанат Panda3D:www.panda3d.com), но, в целом, подойдут все языки с поздним связыванием. Если вы боитесь, что эти языки программирования медленно запускаются, помните, что игры можно писать с использованием нескольких разных кодов: напишите второстепенный контент, который не нужно будет сильно изменять, на чем-то быстром, но статическом (Assembly, C++ и т.д.), а для написания более важного контента используйте медленный, но динамичный язык. Это может потребовать дополнительных усилий, но оно того стоит, так как у вас появляется возможность воспользоваться преимуществами Правила Цикла.

Совет для прототипирования #8: Сначала делайте игрушку

Никогда не задумывались, чем игры отличаются от игрушек? В игрушки весело играть просто потому, что они интересны сами по себе. В играх есть цель, и они позволяют пользователю испытать гораздо более глубокий опыт, основанный на процессе решения проблемы. Тем не менее, не стоит забывать, что многие игры были созданы на основе игрушек. Мяч – это игрушка, но бейсбол – это игра. Меленькая фигурка, которая бегает и прыгает – это игрушка, а Donkey Kong — игра. Вы должны убедиться, что с вашей игрушкой весело играть, до того как вы приступите к процессу создания игры вокруг нее. Может оказаться так, что, сделав игрушку, вы обнаружите неизвестные ранее черты, которые делают ее такой веселой, и вас появится большое количество новых идей, которые можно использовать в игре.

Геймдизайнер Дэвид Джонс говорит, что для создания игры Lemmings его команда пользовалась именно этим методом. Они просто подумали, что будет интересно создать маленький мир с толпами маленьких созданий, которые ходят туда-сюда и занимаются своими делами. У них не было четкого видения игры, но идея такого мира звучала интересно, поэтому они взялись за ее воплощение. Как только у них появилась “игрушка”, начались серьезные обсуждения того, какую игру можно создать вокруг нее. Джонс говорит, что в случае с Grand Theft Auto все было также: “GTA не делали как GTA. GTA делали как средство. Это должен был быть живой, полноценный город, в котором было бы интересно играть”. Как только “средство” было разработано, и команда убедилась в том, что это действительно хорошая игрушка, им нужно было решить, какую игру из нее можно сделать. Им показалось, что город был похож на лабиринт, поэтому они решили взять механику лабиринта из источника, который они посчитали достаточно надежным. Джонс продолжает: “GTA произошла от Pac-Man. Точки – это маленькие люди. Вот я еду в своей маленькой желтой машинке. А привидения – это полицейские”.

Если вы будете сначала делать игрушку, а уже потом приступать к созданию игры, вы сможете радикально изменить качество вашего проекта в лучшую сторону, потому что на выходе вы получите фан сразу по двум аспектам. Но если ваш геймплей создан на основе самых интересных частей игрушки, вы сможете добиться того, что два аспекта будут дополнять друг друга в наивысшей степени. Геймдизайнеры часто забывают об этом ракурсе. Чтобы не повторять их ошибок, читайте Линаз #15.

Замыкание цикла

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

Неформальный Цикл:

1 Придумали идею

2 Сделали из нее игру

3 Редактировали и тестили игру, пока она не стала такой, как вы хотите

Теперь этот процесс стал более формальным:

Формальный Цикл:

1 Постановили проблему

2 Придумали несколько возможных решений

3 Выбрали одно решение

4 Составили список рисков, связанных с этим решением

5 Сделали прототипы, которые смягчают эти риски

6 Испытали прототипы. Если с ними все хорошо, закончили.

7 Постановили новую проблему, которую нужно решить, и вернулись к шагу 2.

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

Цикл 1: “Новый гоночный симулятор”

● Постановка проблемы: Придумать новый гоночный симулятор

● Решение: Гонки на подводных лодках (с торпедами!)

● Риски:

○ Не понятно, как должна выглядеть подводная гоночная трасса

○ Возможно, игра не будет достаточно инновационной

○ Возможно, технология не сможет поддержать все водные эффекты

● Прототипы:

○ Художники рисуют наброски подводных трасс

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

○ Программисты тестируют упрощенные водные эффекты

● Результаты:

○ Подводные трассы в виде “светящихся дорожек” выглядят хорошо. Подводные тоннели – это круто! Круто будут выглядеть и летающие подводные лотки, которые периодически выныривают из воды!

○ Ранние прототипы выглядят достаточно интересно при условии, что субмарины будут очень быстрыми и маневренными. Нужно будет обязательно сделать из них “гонки на субмаринах”. Смесь плавания и полетов выглядит свежо. Скорость подводных лодок должна увеличиваться, когда они летят, поэтому нам нужно придумать, как можно ограничить время полета. Немного поиграв, мы поняли, что в игре должен быть мультиплеер.

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

Цикл 2: Игра про “гонки на субмаринах”

● Новая постановка проблемы: Создать игру про “Гонки на Субмаринах”, в которой субмарины могут летать.

● Детальная постановка проблемы:

○ Непонятно, как должны выглядеть “гонки на субмаринах”. Нужно определиться с внешним видом, как субмарин, так и гоночной трассы.

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

○ Нужно понять, как обеспечить поддержку режима мультиплеер.

● Риски:

○ Если гоночные субмарины будут выглядеть “слишком мультяшно”, это может отпугнуть игроков постарше. Если они будут выглядеть слишком реалистично, это будет выглядеть глупо на контрасте с таким геймплеем.

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

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

● Прототипы:

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

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

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

● Результаты:

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

○ После нескольких испытаний стало ясно, что на протяжении большинства уровней, 60% подлодка должна быть под водой, 20% — в воздухе, и еще 20% — ближе к поверхности воды, где игрок будет собирать необходимые пауер-апы, которые позволят ему набрать высоту, набрав при этом ускорение.

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

Цикл 3: Игра про “летающих динозавров”

● Постановка проблемы: Создать игры про “летающих динозавров”, где рептилии состязаются в скорости под водой и над ее поверхностью.

● Детальная постановка проблемы:

○ Нужно понять, сколько нужно времени для анимации всех динозавров.

○ Нужно разработать “правильное” количество уровней.

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

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

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

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

Не нашли, что искали? Воспользуйтесь поиском: