ТОМ2 - платформа для парсерных игр

Объявление

Платформа ТОМ предназначена для создания текстовых игр на русском языке и имеет развитый парсер, позволяющий взаимодействовать с играми с помощью команд на близком к естественному языке. В данный момент активно разрабатывается версия ТОМ 2.
Последнюю версию платформы можно скачать здесь.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » ТОМ2 - платформа для парсерных игр » Дневник разработчика » Концепция пространства


Концепция пространства

Сообщений 1 страница 4 из 4

1

В очередной раз переделываю перемещения между локациями, хотелось бы сделать всё просто, но пока что-то не очень вырисовывается...
Данная тема - это скорее попытка разложить по полочкам собственные мысли.

Вначале опишу к чему пришел и что твердо себе представляю:
1. Локация - это всегда корень дерева объектов находящихся в ней.
Следствия:
а) не может быть вложенных локаций;
б) запрещено прикреплять локации к объектам.
Пояснения:
Было заманчиво сделать возможными в игре следующие конструкции:
- Концертный зал (локация), в нем сцена (вложенная локация). Сцена видна из зала, а переходя на сцену попадаешь в другую локацию.
- Поляна (локация), на ней домик (объект), внутри домика комната (локация). Находясь в домике продолжаешь оставаться на поляне, сам домик присутствует сразу в 2х локациях.
- Площадь (локация), на ней трамвай (объект), в трамвае салон (локация). Перемещаясь по локациям трамвай таскает за собой внутреннюю локацию со всеми пассажирами.
Но на практике все эти конструкции оказались сложными для восприятия в коде игры - интуитивно не понятно как такие локации влияют друг на друга. Желание сделать "всё как на самом деле" здесь в очередной раз сыграло злую шутку. Значительно проще когда локации независимы и в случае необходимости в игре отдельно прописываются их взаимодействия для каждого конкретного случая.

2. Локация должна иметь координаты вида Х.Y.Z + именованное подпространство
Следствия:
а) образуется обычное трёхмерное пространство;
б) можно легко определить что находится на западе или сверху от текущей локации.
Использование подпространств:
подпространства можно использовать для различных целей
- изменение масштаба (улицы в городе в одном пространстве, комнаты в домах в другом более мелком подпространстве);
- служебные пространства (например герой может блуждать в собственных мыслях).

2

Теперь то, что не так однозначно: перемещения

Требования к функционалу перемещений. Должны работать команды вида:
- Перемещение в указанную локацию: >иди в гостинную
- Перемещение по сторонам света + верх/низ: >иди на север; >лезь вверх
- Перемещения, подразумевающие наличие входов и выходов: >войди; >выйди
- Перемещение с указанием различных объектов, присутствующих в локации:
  >иди в дверь
  >иди в дом
  >иди по мосту
  >иди в сторону города
  >поднимись на башню
  >спустись вниз по лестнице

Требования к функционалу осмотров. Должны работать команды вида:
- осмотры по сторонам света:
  >посмотри на север
  >посмотри вверх

- осмотры с указанием различных объектов, присутствующих в локации:
  >посмотри в окно
  >выгляни за дверь

Текущая реализация:
Сейчас эти задачи решаются введением в локацию специальных объектов класса "направление".
Направление это не предмет, это что-то вроде вектора. Его нельзя пощупать, но можно пройти по направлению, или же посмотреть по направлению.
Объект класса направление имеет 2 обязательных свойства:
- внешнее_описание используется при осмотре;
- конец_пути указывает на локацию перемещения или содержит описание ошибки, если перемещение по этому направлению невозможно.

Недостатки текущей реализации:
1. В локации набирается множество синонимичных направлений. Команды >иди на север и >войди в дверь используют два разных объекта направления "на:север" и "в:дверь", хотя в результате персонаж всё равно пойдет в локацию находящуюся на севере.
2. Проверку на возможность перемещения на север нужно дублировать во всех объектах направления (дверь может быть закрыта).
3. Помимо направлений в локации необходимо создавать переменные или объекты с именами "север" и "дверь", чтобы обеспечить адекватную работу команд с ними: >осмотри дверь; >север;
4. Направления являются объектами и должны иметь уникальные имена. Если из разных локаций можно уйти на север, то имена направлении должны быть что-то вроде "на:север:1", "на:север:2", "на:север:3", и т.д.
Всё это приводит к громоздкому и трудноуправляемому коду внутри локации.

3

Поводя итог можно выделить приоритеты:
- Перемещения по сторонам света (по компасным направлениям) являются наиболее часто используемыми.
- Прочие перемещения как правило можно сопоставить с одним из компасных перемещений.
- Конечную цель компасного перемещения можно вычислить по координатам локаций.
- В некоторых случаях необходимо явно указывать локации как конечный пункт перемещения.

Из этого следует

План действий
А. Разделить класс "направление" на 2 класса: "направление" и "описание_направления". Это позволит описывать направления с помощью 2х переменных вместо одного объекта (убирается п.4, код становится менее громоздким):

Код:
var на:север = пастбище_оленей //переход к локации пастбище_оленей
var на:север:описание = "на севере ты видишь стада пасущихся оленей" //вид на север

Б. В стандартной библиотеке для компасных направлений в классе локаций сделать вычисляемые описания (частично убирается п.3):

Код:
class место
{ ...
  var север = {на:север:описание}
  ...
}

Для дверей всё равно будет нужна еще одна переменная или объект в самой локации, т.к. описания различны:

Код:
var дверь = "старая неплотно закрытая дверь" //описание двери
var через:дверь = пастбище_оленей //переход к локации пастбище_оленей
var через:дверь:описание = "сквозь приоткрытую дверь ты видишь стада пасущихся оленей"

В. Для локаций ввести дополнительные системные свойства, соответствующие компасным направлениям.
Например north для северного направления.
Тогда для каждой локации будут возможны директивы:

Код:
north = пастбище_оленей //указываем локацию, если локация не задана напрямую - значение находится по координатам
//north = fail,"путь на север закрыт" //вместо локации можно указать ошибку, если это направление закрыто
north = "на севере ты видишь стада пасущихся оленей" //указываем описание вида на север
goto north //команда перехода на север
%{north}//команда вывода описания

Г. Для локаций ввести дополнительную секцию для проверки возможности перемещения. Секция выполняется внутри команды goto и в зависимости от результата проверки переход осуществляется, либо выдаётся ошибка.
(убираем п.2)

4

Ожидаемый результат
В идеале код локации должен сократиться и выглядеть примерно так:

Код:
location в:доме
{ это помещение //класс локации из стандартной библиотеки
   north = "на севере ты видишь стада пасущихся оленей" //вид на север

  == check == 
  //секция проверки перемещения
  ошибка, "дверь заперта" если перемещение = north и дверь.заперта



}

*north - предполагаемое новое ключевое слово для направления


Вы здесь » ТОМ2 - платформа для парсерных игр » Дневник разработчика » Концепция пространства