Теория типов и игровой фреймворк (4)

предыдущая серия

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

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

— Сами взаимодействия желательно визуально показывать: например, из крана льётся жидкость соответствующей текстуры, а бензин загорается от энергии (ваттов).

— В конце концов, в каждой локации игроку доступен некий перечень взаимодействий, однако как он о них узнает?

Конечно, эти «проблемы» — скорее забавные задачки для саморазвития. Вот примерная схема фреймворка для создания абсолютно интерактивных миров:

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

— Из-за того, что все сущности интерактивны, появляется комбинаторное число возможных взаимодействий. Дизайнеру уровней конечно сложно предсказать, какие взаимодействия будут играть роль в конкретной сцене. Здесь и может помочь система типов и тайпчекинг, когда мы вручную вырабатываем-локализуем множество взаимодействий в локации. Зато в результате мы получаем сотни способов, подчас очень необычных, добиться нужного результата! Причем все они представляют собой корректные логические цепочки.

—  Самое главное, в процессе игры человек не решает условные головоломки, а реально применяет свои творческие способности, получая реальный опыт!

Сегодня в играх великолепно проработаны технологии визуализации, а вот сам игровой процесс остается на очень низком уровне. Среди игр конца 1980-х — начала 1990-х годов часто встречались шедевры, требовавшие многих месяцев погружения в очень сложный мир. Но при этом они недалеко уходили в плане картинки от псевдосимвольной графики. Теперь же практически все проблемы с красивостью решены — дело за качественным геймплеем.

Собственно, с точки зрения игрока описанная выше схема напоминает лучшие творения в жанре текстовых игр: мы можем приказать «посмотреть вокруг», затем детализировать внимание на одном предмете, получить список взаимодействий с ним, и т. д. Причем эти списки могут формироваться автоматически (на основании сигнатур типов). Здесь также параллельно возникают, например, возможности скрытого обучения программированию!

Далее мы рассмотрим единичные игры с более-менее развитой игровой свободой, и конкретные игровые движки с уникальными возможностями, частично отвечающие нашей схеме. Принципиальный момент тут в том, что в этих движках обычно применяются собственные DSL — да, порой с сильнейшими, шедевральными идеями и концепциями, которые, по большому счёту, нигде больше не встречаются. Мы тут затронем не только очевидные, но и контр-интуитивные для метапрограммирования моменты: использование как встраиваемых DSL, так и системы типов «реального» мэйнстримовского языка программирования, которая сама по себе уже может выступать готовым языком/фреймворком для написания скриптов на нём самом (пресловутая метациклическая эвалуация).

Поделиться статьей ...Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Share on VKPrint this page

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *