Система типов и Чужие (2)

начало

Таким образом, даже игры класса ААА с многомиллионными бюджетами лишены реальной свободы и творческого поиска. Игровой процесс практически всегда жёстко ограничивается гейм-дизайнером, а игрок в лучшем случае может долго бродить по огромному миру, никак с ним не взаимодействуя. Причём в играх наподобие Alien: Isolation свобода игрового творчества пришлась бы особо кстати — ведь очень интересно именно выживать (а не крошить орды врагов) с помощью собственного ума и способностей.

Итак, на помощь приходит метапрограммирование. Нам надо придумать некий DSL, который позволял бы создавать игровые миры с практически неограниченной свободой взаимодействия. Этот DSL, определяющий соответствующие взаимодействия, будет композиционным.
Композицией в математике занимались многие отечественные учёные, от Мальцева (мальцевские алгебры) до Глушкова (алгоритмические алгебры). Композиция функций (морфизмы в теории категорий), главное, закрывает от нас «смысл» композируемых объектов, абсолютно абстрагируясь от их содержимого.

Говорят даже, что суть категории — композиция, а суть композиции — категория.

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

Но движок подсказывает нам хорошую идею: поскольку мы не можем вручную формализовать все мыслимые варианты взаимодействия, давайте будем динамически вычислять последствия взаимодействий объектов самых разных типов.

Начнём с простейшего примера. Допустим, у нас есть функция, вычисляющая скорость ракеты (некий объект), и на вход ей мы подаём строку «hello, world». Самое удивительное, что среди мэйнстримовских языков со статической типизацией мы не найдём такой язык, который бы позволял специфицировать подобный случай для особой обработки. Мы прозаически получим ошибку компиляции.

Поэтому наш композиционный DSL обязан предлагать качественно иную схему. В стандартном композиционном подходе тайпчекер должен уметь определять, в самом общем случае, применимо ли некое действие (например, вычисление скорости) к некоему объекту (например, строке). В данном случае тайпчекер сочтёт его неприменимым. Но в нашем случае в композиционном DSL-языке должны быть правила вычислений, которые вычисляют такую применимость динамически! Самое же главное, что ручного программирования для определения подобной применимости (аппликативности) не требуется. Тайпчекер и общая семантика вычислений нашего DSL предоставляют всю необходимую информацию не только для определения такой применимости, но и для определения её последствий!

То есть, несмотря на комбинаторные числа потенциальных взаимодействий, мы ограничиваемся вполне разумным объёмом программирования, поддерживаемого DSL и тайпчекером, для определения, какие взаимодействия поддерживаются и каковы будут их последствия.

Далее мы рассмотрим, как применить эту потенциально мощную идею на практике.

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

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

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