Metal Gear

Разделение игр на две описанные выше категории позволяет несколько уменьшить рассогласование между системой ИИ и потребностями проектировщиков. При традиционном подходе проектировщик отвечает за детальную проработку всей архитектуры игры, начиная от низкоуровневого определения поведенческих характеристик персонажей и заканчивая разработкой сюжетной линии в целом. Естественно, при таком проектировании никак нельзя обойтись без персонажей, управляемых с помощью анимации. Однако от системы ИИ в подобных играх требуется немного — управлять поведением несобственных персонажей строго в соответствии с замыслом проектировщика и разработанным им сюжетом.
Но если проектировщик попытается применить такой же подход, основанный на явном контроле, к интеллектуальным несобственным персонажам, то неизбежно получит конфликт, в таком случае система ИИ должна выполнить коніфетное действие в определенной ситуации в соответствии с указанием. Конечно, в какой-то степени этого конфликта можно избежать, используя традиционные методы явного управления системой ИИ (например, в анимационных вставках).
Как не трудно догадаться, с помощью принудительного отключения ИИ проблему не решить (иначе вместо игры вы получите компьютерный видеофильм), и здесь проектировщик, использующий традиционные подходы, может оказаться в тупике. Иными словами, создавая игру с интеллектуальными несобственными персонажами, проектировщик не может сказать им: "Идите туда-то и сделайте то-то", поскольку персонажи могут "не захотеть" лезть под пули или прыгать с десятого этажа вниз головой.
Таким образом, традиционные подходы к проектированию в подобных играх не позволяют породить нужную сюжетную линию, в этом как раз и заключается суть конфликта. Вот почему проектировщики игр с четко прописанным сюжетом испытывают, мягко говоря, затруднения с неявным контролем, не понимая того, что часть своих проблем им нужно просто переложить на специалиста по ИИ. В подобных случаях нужно всегда четко идентифицировать игровую ситуацию и решить, какой тип контроля в ней нужен. При этом можно руководствоваться простым, но всегда работающим правилом — контроль должен быть неявным в тех случаях, когда нужно выполнить более одной операции.
Например, если мы хотим, чтобы за дверями после их открытия оказался другой игрок (любой; неважно, какой), — это явный контроль. Здесь задача сводится лишь к инициализации новой сущности в игровом мире. Однако для того, чтобы за дверями оказался именно ваш напарник Марвин, требуется применить неявный контроль. Суть проблемы в том, что ваш напарник должен "захотеть" подойти к двери и реализовать это желание в заданное время, преодолевая все препятствия, возникающие у него на пути. Если мы просто перенесем Марвина в нужную нам точку, это разрушит внутреннюю логику мира игры. Таким образом, этому персонажу для достижения нужного нам результата следует выполнить несколько операций — в таких случаях не обойтись без неявного контроля.
Решение конфликта заключается в том, чтобы проектировщик сначала согласовал со специалистом по ИИ все типичные ситуации, в которых требуется использование неявного контроля. Только после такого согласования щюектировщик может по мере необходимости использовать во всех остальных ситуациях явный контроль. Идея состоит в том, что для разработки средств ИИ нужно заранее знать, какие "рычаги" понадобятся проектировщику для организации неявного контроля, поскольку с организацией явного контроля в современном производстве игры проблем не возникает.
Подобное согласование позволит разработчикам ИИ получить свободу действий, нужную им для создания системы ИИ. Проектировщики же, в свою очередь, смогут задействовать развитую систему ИИ, не теряя контроля над игрой. Оба эти фактора в совокупности позволят в максимальной степени использовать возможности современных технологий ИИ для значительного улучшения игровой обстановки.