Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Рис. 29.2. Двери в видеоиграх бывают самых разных форм, размеров и моделей поведения
Рис. 29.3. Твердые на вид объекты сталкиваются (проникают друг в друга), быстро разрушая иллюзию прочности и реальности объектов. Авторы изображения: Мэтти Розен и Ричард Лемаршан
Чтобы стаб двери (и готовая дверь, в которую он превратится) не сталкивался с окружающим его артом, тщательно продумайте, как его анимировать. Если вы хотя бы немного владеете 3D-моделированием, вы, вероятно, сможете сделать простую анимацию. Выберите точку, вокруг которой вращается ваша дверь, прикинув, где находятся петли на дверях в реальной жизни, и заставьте дверь вращаться вокруг этой точки – она не позволит двери столкнуться с видимой геометрией. Вы можете увидеть пример на рисунке 29.4. Если вы примете это дизайнерское решение, как только внедрите стаб двери в игру, вы поможете тем, кто будет затем работать над графикой и анимацией уже готовой двери.
Рис. 29.4. Тщательно выбирайте опорную точку, вокруг которой вращается стаб, чтобы избежать столкновения
Продуманное создание стабов чем-то похоже на искусство. Каждый стаб подобен зародышу готового игрового объекта и способен сообщить о важных дизайнерских решениях. Рассмотрите возможность сопроводить объект коротким readme-файлом, где вы укажете, какие из принятых вами дизайнерских решений важны и должны быть сохранены в готовом объекте. Чем раньше мы сможем принять ключевое дизайнерское решение, тем плавнее и эффективнее все пройдет при создании игры, а вашим товарищам по команде всегда полезно знать, в каких аспектах они могут проявить свою творческую гибкость и свободу.
Выбирая имена для стабов, помните, что, как и заготовка статьи «Википедии» или функция-заглушка, каждый стаб не просто замещает какой-то объект, он и есть сам объект. Ссылки на объект будут сохранены в готовой игре, и вы не будете заменять весь стаб позже, только его содержимое. Никогда не называйте объект, который вы вводите в игру, временным файлом, сразу называйте его как следует.
Стабы и функциональность
Всегда возникает вопрос о том, какой функциональностью должен обладать стаб. Ответ таков: такой, какую вы сможете быстро обеспечить. Раз стабы похожи на эскизы объектов, то они также могут иметь некоторую встроенную функциональность.
Левел-дизайнеры часто используют условленные цвета при создании блокмеша. Если вы оговорите подобные цветовые условности для стабов объектов, вы сможете передать их форму и функции, даже если стабы еще мало что делают. Прочная стальная дверь может быть светло-серой, в то время как разбивающаяся каменная дверь – темно-серой. Низкие кусты, которые будут шелестеть, когда персонаж игрока проходит через них, могут быть представлены скоплениями зеленых сфер без назначенных коллизий. Панель управления, у которой в итоге будут детальная модель и мигающие индикаторы, пока может выглядеть как простая красная рамка.
Простое кодирование поможет вам добавить некоторое взаимодействие с объектами. Разбивающаяся каменная дверь, которая в финальной игре будет разлетаться на куски щебня, может быть запрограммирована так, что она просто исчезнет при нанесенном ей уроне.
Если вы можете сделать какую-нибудь простую анимацию, подойдет даже двухкадровая анимация открытых/закрытых или включенных/выключенных состояний объектов. Стабы также помогут установить приблизительные логические связи между переключателями, дверями и другими объектами в игре. Постарайтесь спроектировать свой контент и код модульным способом, чтобы вы могли легко вносить дополнения и изменения по мере продолжения работы над объектами и их функциональностью.
Стабы контента против концентрической разработки
Как я упоминал ранее, добавление стабов для полнофункциональности альфа-версии игры знаменует собой отход от концентрической разработки. Мы больше не полируем каждую часть игры до блеска, прежде чем переходить к следующей. Теперь мы быстро вводим объекты в игру, используя плейсхолдеры. Какие риски и выгоды это несет?
Концентрическая разработка наиболее полезна на ранних стадиях проекта. Помните, что мы используем концентрическую разработку, чтобы заложить основы игры. Концентрическая разработка позволяет нам получить четкое представление о самых основных, существенных и уникальных частях нашей игры. Однако в какой-то момент создания каждой игры мы знаем почти все, что нам нужно знать для ее завершения, и мы можем увереннее приступать к оставшейся работе.
Естественно, что на этапе продакшена мы постепенно отходим от концентрической разработки, ведь количество неизвестных в нашем проекте уменьшается по мере того, как мы работаем над альфа-версией. Мы вернемся к концентрической разработке на этапе бета-тестирования, когда игра будет практически завершена. Некая противоречивость, например напряженность между концентрической разработкой и стабами, – неотъемлемая часть любого искусства, а разработка игр, безусловно, является формой искусства. По мере того как вы экспериментируете со стабами объектов, необходимых вашей игре, и узнаете больше о том, как сделать стаб отличным, вы приобретаете уверенность и компетентность в этом аспекте нашего ремесла.
Глава 30
Привлечение аудитории к игре
Альфа-версия – отличное время оценить проделанную работу, которая в итоге приведет нас к началу общения с аудиторией. Мы начали это еще на этапе идеации, когда предполагали возможную аудиторию игры. Я призывал вас продолжать о ней думать и проводить фокус-тесты названия, ключевого арта и дизайна логотипа (на этапе препродакшена в главе 14 и когда вы начали формальный процесс тестирования в главе 24). В главе 28 мы говорили о доработке названия и необходимости завести учетные записи в социальных сетях с уже окончательно выбранным названием игры.
Приближаясь к майлстоуну альфа-версии, мы должны предпринять еще несколько шагов, чтобы найти аудиторию и поговорить с людьми в надежде, что они захотят поиграть в нашу игру. Исторически игровая индустрия делала это с помощью маркетинга, размещая рекламу игр в журналах, на телевидении и в интернете. Сегодня мы можем охватывать
