Формальный язык, близкий к универсальному

#разработка_игр #естественный_язык

Подскажите, пожалуйста, есть ли сабж в природе? Интересуют языки для описания (возможно,
виртуальной) реальности, как можно более универсальные и компактные, позволяющие описывать
объекты, явления, понятия и пр. Грубо говоря, позволяющие запихнуть в БД описание небольшого
мирка/карты/локации с мобами-реками-озерами-деревьями и проч., достаточное для его
построения игровым движком при условии наличия соответствующих методов в нем.

Если таковых нет, подойдут всякие исследования-эксперименты на эту тему.

UPDATE

Так как меня не понимают, уточняю: метка разработка-игр здесь потому, что люди из
этой сферы вероятнее всего этим тоже интересовались, мне сабж нужен не для разработки
игры (пока, по крайней мере). Совсем крутым был бы формализованный аналог википедии.
Условие: текстовый, понятный человеку формат. 

Не нужны размеры/модели объектов (т.к. какому-нибудь двумерному движку а-ля супермарио
эти ваши три-дэ, градиенты и альфа-каналы побоку). Просто общие свойства: 


искажения/координаты/цвет для ландшафта; 
размер/хитпойнты/макс. скорость/модель поведения (вида "спокойный"/"агрессивный"/"труп")`
для мобов;
какие-то характеристики игрока(-ов).

    

Ответы

Ответ 1

Их очень много т.к. у каждой системы он свой, но "универсального" пока нет. Зато
есть куча редакторов карт и локаций)

Погуглите "игровые движки" и посмотрите gamedev.ru

Язык программирования для разработки игр.


Ответ 2

Задача, если я правильно понял, вырождается в простой поиск формата для хранения
сцены. Поскольку то, что вы определяете как "мир" - в простейшем случае это коллекция
таких сцен, понятия "локация" и "карта" же вполне себе собираются термином "сцена".

Понятно, что это так, если вынести за границы вопроса скриптование, поведение объектов,
их Interaction и AI.



А дальше задача сводится к тому, чтобы просто взять и выбрать удобный формат для
хранения этой сцены. Лично мне по душе, например, формат Maya. Многие движки для того,
чтобы сохранять пайплайн разработки максимально простым и прозрачным просто содержат
конверторы из этого формата в какой-то свой внутренний формат, который может быть более
оптимальным с точки зрения времени загрузки и компресии.

Можно также глянуть в сторону Collada и вообще подобных форматов.

Понятно также, что придумать взаимно-однозначное отображение для произвольного взятого
формата сцены на некоторую БД - это тоже не самая сложная (хотя, наверно, и не очень
тривиальная) задача.




3D scene file format & viewer
Is there a 3D scene format specific or well-suited for raytracing


Ответ 3

Судя по тексту вопроса, вопрос скорее из области экспертных систем и баз знаний,
так что стоит посмотреть в сторону языков/структур представления знаний:


mainstream ООП, встроенный в ваш рабочий компилятор -- странно почему не подходит.
Если хочется загрузку из человеко-читаемого текстового формата (DSL язык) в рантайме
-- примените парсер на flex/bison или ANTLR, который формирует в вашем случае описание
мира или области знаний, или например начальное состояние игры. Синтаксис произвольный,
какой сами захотите. Синтаксический анализатор в процессе работы (синтаксически управляемая
трансляция) дергает конструкторы, которые добавляют в сцену объекты. Как распробуете
метод, скорее всего добавите активность объектам -- например обработчики событий, задаваемые
как список вызовов встроенных функций. Достоинство подхода: движок отвязан от конкретной
реализации игры (можно даже по HTTP с игрового сервера тащить в виде потока .txt.gz),
синтаксис описания произвольный, при этом ничего не тормозит, т.к. после загрузки и
создания всех объектов их поведение отрабатывается движком в машинном коде.
онтологии и семантические сети, в частности Semantic web и языки RDF/OWL, скорее
всего нужно будет расширить своими типами, и подобрать библиотеки для обработки этих
описаний. Описания задаются в XML-разметке, парсер и редактор есть в составе библиотек.
Сложно в понимании (концептуально), XML синтаксис тяжел для ручного редактирования,
не применим в рантайме для игр и приложений реального времени -- только генерация кода
на компилируемых языках, или другая неспешная обработка.
фреймы Минского -- имеют внутреннюю активную природу, поищите реализации интерпретаторов
(машин вывода), в идеале построить систему которая будет генерировать статический код
на вашем рабочем языке программирования из абстрактного описания, причем сама генерация
описывается отдельным набором фреймов. Если добавить машину Минского в гейм-движок,
на ней же можно реализовать и AI. Тогда вместо трансляции нужно будет сделать визуализацию
определенных фреймов через DirectX/OpenGL и ввод событий от игровых контроллеров. Парсер
скорее всего свой. Подход и инструментарий малоизвестны, при применении в рантайме
игры и ИИ реального времени может оказаться неприемлемо тормозным. Опасно -- вместо
игры можно случайно написать экспертную систему.
Попробуйте описать дерево классов на Python, и реализовать транслятор в ваш язык,
Python (или Java) поддерживает reflection, поэтому можно программно обрабатывать описания
классов, методов, и генерировать код на нужном языке. Если Python не понравится синтаксически,
можно использовать PLY. Возможна не только генерация кода, но и динамическое создание
классов, объектов, методов и структур данных.
в худшем случае придется написать собственный диманический DSL язык, позволяющий
описывать классы объектов и их взаимоотношения, генерирующий код в оффлайне на рабочем
языке (java/C++/..) или работающий целиком в рантайме внутри (игрового) движка. По
скорости работы особых ограничений нет, если применить динамическое создание байт-кода
(JVM) и/или JIT-компиляцию (LLVM). Очень опасно -- можно случайно стать программистом-компиляторщиком,
или слепить Skynet


Ответ 4

как можно ... описывать объекты, явления, понятия и пр. ... в БД


На мой взгляд, для этого идеально подходят Графовые базы данных. У графа есть узлы
(вершины), ребра и свойства. Три эти сущности позволяют формально описывать любые объекты,
их взаимосвязи и характеристики.

Например, есть объекты Игрок, Моб, NPC и другие. Связи между ними могут быть следующими:

Моб (узел) нападает (ребро) на Игрока (узел) в зоне видимости.
Моб имеет 500 очков здоровья (свойство), тип атаки - ближняя (свойство), сила удара
50 (свойство), видит на 50 метров (свойство) и т. п.

Игрок может нападать (ребро) на Моба. Игрок может общаться (ребро) с NPC. Игрок имеет
300 очков здоровья. Игрок может разучивать (ребро) заклинания (узел). Игрок имеет 10
единиц золота (свойство).

NPC даёт задания (ребро) Игроку. NPC неуязвим (свойство). Игрок может выполнять (ребро)
задания (узел).