Народы, вот у нас много человек писало на всяких левых языках типа бейсика, паскаля и даже экшнскрипта. Я пробовал на С++. Внимание, вопрос.
Как у вас там всё было устроено, и как устраивать надо? Чисто конкретно программёрский вопрос. Как представлена карта? Двуменрый массив чтоли? Если да то как вверх и вниз ходить? Трёхмерный чтоли? Как вы обрабатываете команды и где находятся обработчики? У меня мелькает картинка, что в самой дубовой слепленной абы побыстрее игрушке каждая локация - это функция:
function Kuhnya()
begin
command:=WaitForCommand();
case command of
'юг': Gostinnaya();
'север': Say('сюда нельзя')
end;
end
Ну что-то в этом роде. Каждая комната - это вот такая функция. Мне бы узнать как сам каркас программы устраивается. Думаю, и всем будет интересно посмотреть кто и как делает.
А?
Неактивен
У меня карты, как таковой, нет. Есть одна большая процедурина, в которую передается разложенная на составляющие команда (Глагол, ОснОбъект, ВспОбъект, ДопОбъект). Суть процедурины выглядит примерно так:
Если Комната="кухня" Тогда
10
ИначеЕсли Комната="прихожая" Тогда
10
КонецЕсли
Таким образом можно реализовать перемещение в произвольное количество направлений...
Неактивен
Во, Олегус, дружище, спасибо за ответ.
Уже что-то. По-моему если щас все выскажутся - это будет страшно полезно для создания платформы.
А сколько километров у тебя эта процедурина? Умереть же можно!
Неактивен
Если тебе это интересно, то для меня комната - просто обрабатываемый объект, который имеет некоторые св-ва.
Т.е. карты как таковой нет, а функция работает лишь с объектом, вытащенным из файла.
Выглядит ето примерно как у Олегуса, только чуть не так:
комманда=GetCommand();
while(ВыходыНеКончатся)
{
Выход=GetNextRoomExits(комната);
if(Выход==комманда)
{
if(комманда==true) GoToLocation(комманда);
else Show("Выйти тудыть нельзя.");
}
}
if(НиОдинИзВыходовНеПодошел) Show("Нету тут такого");
Вот...
Неактивен
Namor написал:
А сколько километров у тебя эта процедурина?
Умереть же можно!
;D
// основной модуль
// my_game.cpp
# include "my_lib.h"
void main()
{
MyGame G("game_name.dat", "default.txt", 1);
};
Все! ;D
8)
А если серьезно.... то - да... километры.
А конца-края все еще не видно...
Но уже есть несколько вещей, которые хочется обсудить... а также несколько идей, которыми, даже, может стоит поделиться... Если это хоть кому-то интересно...
Неактивен
Думаю, все же, что для ИФ будет полезен более объектно-ориентированный подход. Не надо привязывать обработку команд к отдельным комнатам. Тем более не надо сваливать их все в одну кучу. Возьмем, например, Гидру
Комнаты - объекты (впрочем, как и все остальное). В каждом комната-объекте хранятся ссылки на др. комнаты-объекты по направлениям. Выглядит так:
SquareRoom.Map={S:RoundRoom,W:CorridorRoom}
Т.е. здесь SquareRoom, RoundRoom, CorridorRoom - это комнаты-объекты.
Само же движение игрока вместе с необходимыми проверками происходит там, где оно и должно происходить - в обработчике глагола "идти". (кстати, глаголы - тоже объекты. Очень удобно).
Вообще, получается достаточно четкая структура.
Получаем от игрока строку команды. Разбираем ее и узнаем, какие объекты в ней упоминаются. Т.е. получаем объект - глагол, объект актер, объект предмет...
Затем просто вызываем спец. ф-ию у объекта глагола, передав ей остальные объекты. А уж она должна все необходимое проделать.
Примерно так.
А вообще, если интересно, смотрите исходники - они на Питоне, а Питон один из самых самоописательных языков, так что особых проблем с пониманием возникнуть не должно.
Неактивен
WildWizard написал:
Думаю, все же, что для ИФ будет полезен более объектно-ориентированный подход.
Никто не спорит.
Не надо привязывать обработку команд к отдельным комнатам. Тем более не надо сваливать их все в одну кучу..
Я привязываюсь к объектам игрового мира. Мне так кажется логичнее. И пока меня никто не разубедил.
Само же движение игрока вместе с необходимыми проверками происходит там, где оно и должно происходить - в обработчике глагола "идти". (кстати, глаголы - тоже объекты. Очень удобно).
Я использую внутреннию переменную типа Phrase.
Думаю - полный аналог твоих объектов-глаголов.
Комнаты - объекты (впрочем, как и все остальное). В каждом комната-объекте хранятся ссылки на др. комнаты-объекты по направлениям.
Мне больше по душе метод передвижения, реализованный Olegus'ом в "Мути".
Поделюсь одной идеей (Вдруг кому будет интересно). Каждый объект может быть контейнером (обладать свойством). И отличаться от локации только тем, что в него нельзя войти, к примеру. Это мне позволило во-первых, использовать единообразную обработку осмотра ко всем объектам, во вторых, использовав рекурсию (см ниже), разнообразить выдаваемые программой описания.
Пример:
>осм стол
.. Какой еще стол???
[стол == еще не видим]
>осм комнату
[(все, чья локация == ID комнаты) = видимо]
... ля-ля-ля стены-пол-потолок-всякий хлам, стоит стол...
(все что в комнате и видимо)
[стол == видим, шкатулка == еще нет]
>осм стол
... окурки-бутылки, шкатулка...
[шкатулка = видима]
>осм шкатулку
... то-се, пыль - паутина, лежит ключ...
[ключ = видим]
>осм ключ
ключ...
>осм комнату
... туда-сюда,
[комната == локация, контейнер -> выдаем описание всего, чья локация == ID комнаты]
стены-пол-потолок-всякий хлам, стоит стол
[==контейнер-> выдаем описание всего, чья локация == ID стола]
, на нем -окурки-бутылки, шкатулка
[=контейнер-> выдаем описание всего, чья локация == ID шкатулки]
, в ней - пыль - паутина, лежит ключ
[==не контейнер]. Ну - ключ... (конец ветви)
[продолжение перечисления предметов в комнате] А теперь... Гы! 8)
> положи стол в шкатулку
[стол.Location = шкатулка.ID]
> осм стол
или там > осм комнату
..тыр-пыр.."У вас тоже Де-Жа-Вю, товарищ! Лечиться надо!"
В принципе - ни чего не стоит ограничить вложенность, чтоб не загромождать описания всякой всячиной. (кажется, чем что-то наглядное изобретать, можно было бы код вставить...ю )
А вообще, если интересно, смотрите исходники - они на Питоне
А просто идеи-алгоритмы рассказать? ? ? Лениво или жалко?
Неактивен
Да лениво пересказывать алгоритмы. Это же просто один к одному по исходникам читать - какой смысл?
В Hydra все объекты - контейнеры. Очень удобно. Взято, конечно, из информа. Игрок - контейнер. В нем содержится инвентарь. Сам игрок содержится в контейнере комнате, в кот. содержатся др. предметы, кот. тоже могут быть контейнерами.
Хотя, наверное, стоит разделить находиться В чем-то и находиться НА чем-то, а то возникают определенные проблемы, как с той стиральной машинкой, В которую можно ложить предметы и НА кот. можно ложить что-нибудь...
Неактивен
WildWizard написал:
Да лениво пересказывать алгоритмы. Это же просто один к одному по исходникам читать - какой смысл?
Согласен.
В Hydra все объекты - контейнеры. ...Хотя, наверное, стоит разделить находиться В чем-то и находиться НА чем-то, а то возникают определенные проблемы, как с той стиральной машинкой, В которую можно ложить предметы и НА кот. можно ложить что-нибудь...
Что может быть проще!! ;D Стол - локация? (подрзумевается - на столе) Чем не локация? Ну и: под столом, за столом, в столе ets. - тоже локации.
К примеру - "смотри под стол".
На столе ну, скажем пепельница. Под ней - тоже что-нить быть может? Пусть будет отдельная локация. А раз локация - то и контейнер.
И потом - "поставить" и "положить" - разные действия с разным результатом.
Неактивен
Ar.A.B. написал:
Стол - локация? (подрзумевается - на столе) Чем не локация? Ну и: под столом, за столом, в столе ets. - тоже локации.
К примеру - "смотри под стол".
На столе ну, скажем пепельница. Под ней - тоже что-нить быть может? Пусть будет отдельная локация. А раз локация - то и контейнер.
И потом - "поставить" и "положить" - разные действия с разным результатом.
Зачем локация? Можно просто отдельные объекты сделать, работающие в качестве контейнеров.
А вообще, у меня система немного другая - можно создать (объявить) объект с практически любыми свойствами, всё прописывается на скриптах.
Неактивен
RealSonic написал:
Зачем локация? Можно просто отдельные объекты сделать, работающие в качестве контейнеров.
Так и есть. Объект любой может быть локацией (или контейнером - не вижу разницы). А может и не быть.
Неактивен
Ar.A.B. написал:
Так и есть. Объект любой может быть локацией (или контейнером - не вижу разницы). А может и не быть.
Небольшая разница всё же есть. Локация может содержать игрока, а контейнер - только другие предметы. Хотя, это вопрос предметной области, в каждой реализации она своя.
Неактивен
RealSonic написал:
Локация может содержать игрока, а контейнер - только другие предметы.
Возможны варианты моей фантазии вполне хватает чтоб с ходу придумать несколько ситуаций, когда возможны исключения.
)
Не вижу смысла разводить множество разных сущностей, когда можно обойтись и небольшим их количеством
1. В локацию перейти можно, а в не_локацию нельзя никак.
2. В контейнер можно поместить предмет (при условиях) а в не_контейнер - нельзя.
Для простоты можно считать каждую локацию контейнером по умолчанию. А можно и нет. Все в руках автора.
Неактивен
Ar.A.B. написал:
1. В локацию перейти можно, а в не_локацию нельзя никак.
2. В контейнер можно поместить предмет (при условиях) а в не_контейнер - нельзя.
Полностью согласен с такой концепцией.
Неактивен