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

Объявление

Открыт сайт tom2-game.ru.


Последнюю версию платформы можно скачать здесь.

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

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

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

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

Страница: 1

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

1

  • Автор: ASBer
  • Администратор
  • ASBer
  • Зарегистрирован: 2010-02-01
  • Приглашений: 0
  • Сообщений: 858
  • Пол: Мужской
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2020-04-29 19:52:52

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

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

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

2

  • Автор: ASBer
  • Администратор
  • ASBer
  • Зарегистрирован: 2010-02-01
  • Приглашений: 0
  • Сообщений: 858
  • Пол: Мужской
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2020-04-29 19:52:52

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

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

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

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

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

3

  • Автор: ASBer
  • Администратор
  • ASBer
  • Зарегистрирован: 2010-02-01
  • Приглашений: 0
  • Сообщений: 858
  • Пол: Мужской
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2020-04-29 19:52:52

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

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

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

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

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

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

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

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

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

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

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

4

  • Автор: ASBer
  • Администратор
  • ASBer
  • Зарегистрирован: 2010-02-01
  • Приглашений: 0
  • Сообщений: 858
  • Пол: Мужской
  • Провел на форуме:
    21 день 0 часов
  • Последний визит:
    2020-04-29 19:52:52

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

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

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



}

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

Страница: 1

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