Я слежу за созданием и развитием платформы ТОМ и меня поражает тот факт, что текстовые игры уже дошли до такого, что достаточно просто разбирают команды на русском языке, хорошо строят предложения но никто не хочет сделать на этом какую-нибудь командную строку, которая бы по командам на ЕЯ выполняла бы действия на компьютере. Ведь на первый взгляд: те же самые объекты со свойствами и методами, те же команды. В компьютере даже легче - ограниченное кол-во классов (файл, папка, DVD-привод, ОС, программа...), всё дискретно... Но... Я думаю даже этот движок ТОМ не смотря на всю свою гибкость и возможность подключения внешних функций пока не сможет выполнять такие операции, т.к. основная проблема в том, что в игре все объекты известны с самого начала, а в примере с компьютером - нет. Например по команде "Перемести все файлы с флешки на диск D", чтобы узнать список файлов (объектов), которые нужно переместить, нужно не просто просканировать память и найти объекты, которые находятся в объекте Флешка, а сначала найти флешку, затем вызвать функцию сканирования, которая найдёт все файлы на флешке, превратит их в объекты и добавит в память движка.
Попробую сформулировать свои мысли, почему такого сейчас нет, и в обозримом будущем не появится.
Если отбросить интерфейс и посмотреть на реализацию игровой (или бизнес) логики, то программы с консольным управлением по большому счету ничем не отличаются от программ с GUI.
Как правило исполнительный механизм программы предоставляет некий нерасширяемый набор функций.
- Простейшее действие - фукция без параметров. Вызывается нажатием кнопки, меню, или определенной фразой в командной строке.
- Более сложное действие - фукция с одним или более параметрами. Вызывается нажатием кнопки в диалоге с установкой значений параметров в полях диалога, или фразой определенного формата в командной строке.
И всё! Для 99.99% программ такой архитектуры вполне достаточно.
Если представить множество всех гипотетически возможных действий программы как поверхность, то точки входа функций будут кроличьими норами на этой поверхности. Причем очень редкими - попасть в такую нору наугад весьма сложно.
Команды на ЕЯ за счет своей гибкости покрывают значительно большую площадь гипотетически возможных действий программы.
Что делают парсеры в играх с такими не в меру продвинутыми командами?
1. Разветвляют точки входа в кроличьи норы за счет синонимов и различных вариантов построения команды, тем самым расширяя область принимаемых команд.
2. Мягко "отшивают" игрока, если он не попал в точку, при этом ненавязчиво подсказывая направление к ближайшей норе.
Парсер лишь маскирует ограниченность функционала программы, затуманивая её небогатые возможности.
И я более чем уверен что в неигровых применениях это лишний гемор и для разработчика и для пользователя.
По сути возможности интерфейса на ЕЯ много шире чем функциональность любой существующей сейчас программы.
Чтобы покрыть функциональностью большую часть множества гипотетически возможных действий нужен как минимум Большой Прорыв в теории программирования, но это уже совсем другая история...
