Forum.iFiction.Ru

noname написал:

входы-выходы в игре вроде бы вполне могут быть описаны библиотекой map

Если карта не вписывается в "квадратики" map - можно попробовыть ее подогнать разбивая локации на части - восточная часть комнаты, западная часть комнаты и т.п.

noname написал:

и от ASBer- твоё мнение по этому поводу?

Платформа не наполненная играми - мертвая платформа. 
Естетственно я могу быть только ЗА! и обещаю полную поддержку.
Работа над первой версией практически завершена - осталось только вычистить ошибки, и отладочный режим сделать понятным для разработчиков игр.
Поэтому сейчас я переключаюсь на библиотеку, документирование, поддержку и т.д.

P.S. noname, спасибо за постоянный интерес к тому что я делаю и за твой энтузиазм - эсли это надо хотя-бы одному человеку, значит стоит работать дальше

из всех тем про ТОМ, эта- пожалуй, самая подходящая для обсуждений работы над играми

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

итак, работа над проектом 'Спелеолог-2' уже идёт. первый шаг:

выкладываю 'план игры' - краткую инфу обо всём, что будет в игре

вторым шагом будет составление перечня необходимых библиотек для этой игры

--------------------------------------------------------------------------------
Прикрепленные файлы:
Спелеолог-2.doc, Размер: 1,928 байт, Скачано: 33

- Фонарик с батарейкой внутри - это классический открываемый контейнер. Пока фонарик закрыт никакие действия с батарейкой невозможны. (нужна библиотека для контейнеров)
- Батарейка - контейнер с замком. Только вместо ключа служит нож. (таже библиотека для контейнеров)
- по остальным вопросам работаю...

Конечно можно сделать и так. Тогда нужно просто создать действие:

action открыл
{
  pat = "открыть=открой @Что:фонарик*Вп"
}
персонаж.открыл()
{ %ты открыл фонарик и вытащил из него батарейку.
   фонарик.описание = "фонарик без батарейки - бесполезная вещь."
   this + батарейка
}

т е ЕСЛИ одновременна подключена и библиотека, в которой описан глагол 'открыл', И модуль игры, в котором описан тот же глагол, но иначе -

ТО будет использоваться описание именно из модуля автора?

// для этого, вероято, необходимо, чтобы модуль был подключён _после_ библиотеки?

UPD:

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

согласен. Дай пример того, как сделать уникальные авторские действия с двумя предметами. и ещё момент: то же самое действие с двумя другими предметами может дать другую реакцию. ИМХО наиболее корректный вариант- в описании действия проводить проверку свойств(переменных) используемых предметов, и исходя из этого выполнять над ними соответствующие манипуляции

Отредактировано noname (27.07.2009 17:06)

ASBer написал:

Для исключения неоднозначностей лучше использовать авторские действия с именами
открыл_фонарик или
noname_открыл или
noname_открыл_фонарик и т.п.

думаю:

допустим, подключена библиотека с контейнерами, в которой описано действие 'открыл'

описываю в модуле действие 'открыл_фонарик', которое выполняет особые манипуляции именно с фонариком

если при этом остаётся возможность открывать остальные контейнеры стандартным образом- это фообще шикарно

pat = "открыть=открой @Что:фонарик*Вп" обеспечит срабатывание действия именно для фонарика и только для него

ок! буду пробовать

UPD

насчёт примера с действиями(пред моё сообщение):

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

UPD UPD:

остаётся ещё вопрос с завалом камней/ камнями = валунами / - как сделать лучше? наверное- добавить синонимов названию локации, в которую будет заложен динамит(он закладывается в завал камней) ? как сделать, чтобы прога понимала обращение по такому синониму во множественном числе?

щазз гляну- вроде бы и ещё какие-то вопросы были

Отредактировано noname (27.07.2009 17:17)

noname написал:

location счастливое_нигде // всё несуществующее хранится здесь
{ cls = место
  отметить_на_карте(100,100,100)
}

Все объекты, которые находятся "нигде" на самом деле лежит в global.item[]
Т.е. создавать специальную локацию для этого не нужно - она уже есть.

noname написал:

// позже стандартное сообщение необходимо будет заменить более литературным,
// подходящим именно к этой игре: 'сплошные каменные стена пещеры не дают тебе пройти на юг'
// да, кста- как изменить стандартное сообщение для _направлений_?

ушел_по_направлению.не_пройти = "сплошные каменные стены пещеры не дают {actor*ДпНе} пройти {направление.предлог} {направление*Вп}"

Отредактировано ASBer (28.07.2009 13:44)

а я жду свой день рождения, который будет сегодня вечером

скачал, но посмотрю не ранее, чем завтра ( а скорее всего- послезавтра)

//и, да- не совсем ясно, в какой момент вставлять в игру авторство (она пока далека от готовности). но на всякий случай лучше уже в следующую версию доработки следует включить упоминание автора(Михаила Баланова) и его оригинальной версии(Speleologist)

Отредактировано noname (30.07.2009 15:41)

итак, напоминаю, что сделано:

первый шаг: выкладываю 'план игры' - краткую инфу обо всём, что будет в игре

и

второй шаг сделан: запрос библиотек находится в прилагаемом архиве

теперь позволю себе несколько расслабиться и просто заполнить описания локаций, чтобы снова 'погрузиться' в проект

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

---

исправления посмотрел:
1.

ушел_по_направлению.не_пройти = "сплошные каменные стены пещеры не дают тебе пройти {направление.предлог}

в связи с этим вопрос: можно ли в команде

добавить_препятствие(на_юг,"сплошные каменные стены пещеры не дают тебе пройти на юг") //направление и выводимое сообщение

как-то покороче(одним словом) указать на то, что в этом случае должно выводиться обычное сообщение (см чуть выше)? дело в том, что если препятствий будет несколько, то легко ошибиться в описании фразы в одном из них

2.

this.можно_взять = да //добавил ASBer 30.07.09

да, я у себя эту 'недописку' исправил уже после выкладывания проги

3.

'осмотреть моток верёвки' даёт ошибку

- из всего запроса это осталось последним неясным моментом; надо описать как-то так, что бы 'осмотреть верёвку верёвки' - выдавало бы ошибку, НО 'осмотреть моток верёвки' воспринималось бы нормально // впрочем, если это сложно, то вместо 'моток верёвки' можно сделать просто 'верёвка'

---

Добавил в библиотеку притяжательные местоимения, притяжательные возвратные местоимения и поддержку для притяжательных прилагательных

однако тут возникает некоторая неясность: если я принадлежащую мне фотографию девушки отдал деду, то с точки зрения программы эта фотография теперь моя, девушки или деда? т е боюсь, тут есть поле для игры слов

---

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

---

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

noname написал:

в связи с этим вопрос: можно ли в команде

добавить_препятствие(на_юг,"сплошные каменные стены пещеры не дают тебе пройти на юг")

как-то покороче(одним словом) указать на то, что в этом случае должно выводиться обычное сообщение (см чуть выше)? дело в том, что если препятствий будет несколько, то легко ошибиться в описании фразы в одном из них

Очень просто:
1 вариант: нужно самостоятельно написать функцию, которая будет добавлять типичные препятствия.
2 вариант: сделать препятствие в виде объекта с соответствующим описанием и везде добавлять его.
3 вариант: для добавления препятствий, неотличимых от стандартного сообщения, использовать вызов библиотечного метода в формате:

добавить_препятствие(на_юг)

(сейчас это работать не будет, но сделаю обязательно)

noname написал:

хорошо бы сделать следующую штуку:
- возьми кирку
- осмотри её

Это можно сделать добавив в каждый предмет дополнительную лексему:

this.местоимение = "%; СиЖрЕчНд; Ип; Ип=она, Рп=её; Дп=ей; Вп=её; Тп=ей; Пп=ней;"

Но в случае если в локации будет несколько предметов одного рода - будет возникать неоднозначность...

noname написал:

некоторый объект(напр: пещера) может быть осмотрен в любой локации. как с этим быть? добавлять и описывать в каждой локации?

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

class пещера
{ cls = место
   title = "пещер%; ЖрЕчНдСи; Ип; Ип=а; Рп=ы; Дп=е; Вп=у; Тп=ой; Пп=е;"
}

location зал_1
{ cls = пещера
   //...
}
location зал_2
{ cls = пещера
   //...
}
и т.д.

Если в каждой локации должны быть декорации наподобие "потолок", "стены", "трава" то проще всего их сделать объектом категории mental. Тогда они будут как святой дух - сразу везде и нигде конкретно.

noname написал:

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

В этом случае да, counting наверное самое подходящее.

Отредактировано ASBer (02.08.2009 18:43)

noname написал:

после чего можно будет описывать предметы-какие именно предметы стоит вводить в игру зависит в т ч от того, какие слова будут упомянуты в описаниях локаций

ИМХО лишние предметы, не требующиеся для прохождения, лучше не упоминать.
Я бы начал с самого сложного - с действий над предметами типа "открыть", "зажечь", "срубить".