Forum.iFiction.Ru

есть ли смысл как-то разделять эти плоскости на уровне платформы?

Поддерживаю данную идею, но внесу некоторые поправки. Эта идея хороша, но реализация всегда внесет свои коррективы. Т.е., в момент реализации может возникнуть необходимость смешивать некоторые участки этих систем (плоскостей) для их же связи или по причине не возможности иначе связать разделенные системы. Иначе говоря, полного разделения не достичь.

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

Если еще конкретнее разобрать, то ID лучше использовать, как промежуточный объект или структуру (в общем любой тип данных подходящий для этого), содержащий, как сам ID, так и сигнатуру (допустимые свойства и действия объекта) для привязки их к языковой системе. Причем, нагромождения не будет, скорее наоборот, особенно если каждая система будет независима (в разумных пределах) от другой в плане выполнения своих задач. Т.е. языковая работает только по своей части и отсылает нужные данные, через промежуточные системы для свзяки с другими, и реагирует получая от них данные таким же образом (намного проще реализовывать эту промежуточность ввиде движка надстройки (посредника), связывающего все в единое целое).

Естественно в плане языка менять ничего не надо, все это проделывается только на уровне платформы. По отношению к сюжету (или 3 плоскости) можно поступить по той же аналогии. Полагаю, что этим я ответил на твой вопрос ичерпывающе, хоть и не прямо.

возможно для описания 3х различных сущностей лучше подошли бы 3 различных языка в рамках одной системы?

Я не могу сказать, что мой проект щас есть в релизе, но и не могу также отрицать, что у меня используется подобная вещь. Просто вообрази себе данные ввиде блоков, которые раскладываются моими тэгами. Наполни эти блоки воображаемой жидкостью, состоящей из команд в этих же тэгах и в некоторых атрибутах тэгов. И... если приглядеться, то только объектные блоки не шибко связаны между собой. Устраняем это путем связки сосудов и прочими канальчиками с затворами, которые управляются с помощью отношений (они чем-то похожи на классы в ртадсе типа повехность, контейнер, только гибче и классами не являются). Вуаля, получилась целая система описания, использующая сильные стороны каждого из языков, своего рода гибрид. Иначе говоря, при добавлении парсера  получаем 3-4 языка в рамках одного (отношения в правилах имеют свой язык для упрощения их использования и это хорошая почва для парсера, как и для меню).

Главное, чтобы языковые средства не были мудренными и у авторов может возникнуть некоторая дизориентация, т.к. в основном у нас привыкли пользоваться одной языковой системой, а не комбинированным вариантом. Но это все мелочи.

есть ли системы, где эти плоскости реально разделены?

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

К тому же, при более глубоком анализе, можно заметить, что разделение нескольких частей механизма ПО на отдельные системы приносит свои плоды и используются в многих программах в том числе и в современных игрушках (в тех же самых навороченных движках даже).

Как видишь, это идея уже давно применяется даже по аналогии. Использовать или нет, это уже на твое усмотрения. Я лично за, обеими руками.