Очень хочу посоветоваться с уважаемым сообществом в целом и с Грандом в частности вот по какому вопросу. Мне сильно не хватает в RTADS возможности задавать части предметов.
Например, кружка. У кружки есть ручка плюс рисунок на боку. Хочется, чтобы их можно было исследовать отдельно. При этом они, понятное дело, должны перемещаться вместе с кружкой. Также было бы неплохо имет возможность создавать отделяющиеся части (например, снять наконечник с копья). Опять же, хочется иметь возможность создать набор частей тела, перемещающихся с актером ("дернуть бомжа за нос").
Для фиксированных предметов такой проблемы, практически, нет. Никто не мешает насоздавать кучу предметов прямо в комнате. Но с переносимыми объектами - беда.
Я крутил adv.t так и эдак, похоже малой кровью не обойтись. Объекты-компоненты должны находиться процедурами поиска доступных и видимых объектов, с ними должны быть запрещены некоторые действия ("взять ручку кружки" отдельно от кружки, например).
Также, непонятно с уточнениями. Есть ружье и есть револьвер. У каждого из них есть курок. Можно, конечно, ввести описание вида "курок ружья" и "курок револьвера", но раз уж мы их прикрепляем и так, то лишние определения вроде бы можно упразднить...
Кто что думает? Возможно ли такое сделать без особых изысков?
Неактивен
GrAndrey написал:
А части как фиксированные предметы с location равным целому объекту?
А они не будут показываться как содержимое контейнеров, скажем? Плюс проблемы с отделением и уточнениями - остаются. А еще я думал, что хорошо бы сделать так, чтобы у объектов-частей было бы некое описание, которое выводилось бы при осмотре объекта-целого. Скажем, compdesc = "Курок ружья взведен. "
Было бы удобно.
Или все это от лукавого?
Неактивен
Порождай детали от fixeditem и присваивай им в качестве location главный предмет. Они будет переносится с ним вместе и не будут отображаться в списках.
Если компоненты нужно отделять, сделать их как просто item, но придется подмодифицировать функции типа listcontcont, чтобы не печатали лишнего. Или подыгрывать флаг isListed для деталей, обнуляя его когда деталь прикреплена к предмету. Прикрепление/открепление, естественно, делается на обработчиках соответствующих глаголов.
Неактивен
Gremour написал:
Порождай детали от fixeditem и присваивай им в качестве location главный предмет. Они будет переносится с ним вместе и не будут отображаться в списках.
Если компоненты нужно отделять, сделать их как просто item, но придется подмодифицировать функции типа listcontcont, чтобы не печатали лишнего. Или подыгрывать флаг isListed для деталей, обнуляя его когда деталь прикреплена к предмету. Прикрепление/открепление, естественно, делается на обработчиках соответствующих глаголов.
Спасибо, буду думать. Некоторых плюшек не получится сделать, но в целом... Надо класс специальный написать что ли...
Неактивен
Для кружки с ручкой и картинкой достаточно fixeditem.
Для объекта с опциональными деталями (у меня есть мишень, в которую можно метать нож, и он там застревает) достаточно простого метода ldesc с проверкой локации детали, без мудрежа вроде compdesc.
Советую программисткие замашки ограничивать. Получается программирование ради программирования, наворот системы для того, чтобы использовать один частный её случай. А игра в итоге страдает.
Неактивен
Советую программисткие замашки ограничивать. Получается программирование ради программирования, наворот системы для того, чтобы использовать один частный её случай. А игра в итоге страдает.
Да понятное дело. Однако, трудно отказаться от мышления, сложившегося в течении многих лет.
Все от узости мышления...
Неактивен
А вот как сделать класс предметов с предопределенными частями? Скажем, у меня в нескольких комнатах есть окна, а в них, естественно, оконные стекла. Можно ли не определять "оконное стекло" в каждой комнате, а сделать класс "окно", в котором есть и стекла, и форточки (к примеру). Или таки наш друг copy-paste?
Неактивен
fireton написал:
А вот как сделать класс предметов с предопределенными частями? Скажем, у меня в нескольких комнатах есть окна, а в них, естественно, оконные стекла. Можно ли не определять "оконное стекло" в каждой комнате, а сделать класс "окно", в котором есть и стекла, и форточки (к примеру). Или таки наш друг copy-paste?
Решения "в лоб" предложить не могу, но, опять-таки, если это окна (их не надо таскать из комнаты в комнату, и их части тоже), то всё достаточно просто. Создаёшь класс для комнаты с окном и переопределяешь enterRoom:
class RoomWithWindow: room enterRoom(actor)= {// Перемещаем форточки и стекла Fortochka.moveInto(self); Steklo.moveInto(self); pass enterRoom; } ;
Если необходимо иметь возможность форточки открывать/закрывать, а стёкла бить, то вводишь в том же классе RoomWithWindow соответствующие булевские свойства-флаги состояния и описания/реакции форточек/стёкол генерируешь с учётом этих флагов.
Неактивен
fireton написал:
у меня в нескольких комнатах есть окна, а в них, естественно, оконные стекла.
Вот из-за этого у меня загнулся первый проект. Двери с ручками, на дверях таблички, и понеслось.
Если возиться так с каждой декорацией, не хватит никаких сил закончить игру. Стёкла эти оконные, они тебе для паззла нужны или просто чтобы были? Сделай стекло синонимом окна. Если надо разбивать, делаешь свойство isBroken у окна. Если надо открывать форточку -- открываешь окно. Игрок ведь будет мыслить именно так: открыть форточку = открыть окно, разбить стекло = разбить окно.
Можно ли не определять "оконное стекло" в каждой комнате, а сделать класс "окно", в котором есть и стекла, и форточки (к примеру).
Сделать можно. Есть оператор new для динамического порождения объекта. В классе "окно" сделать свойства-указатели на динамически порождённые стёкла, форточки и что там надо. Вариант с переносом стекла в комнату конечно прост и будет работать, но чем-то он мне не нравится.
Но, вообще, ТАДС рассчитан на уникальные предметы. Когда игрок ссылается на похожие предметы, можно определить, что имелось в виду, если у каждого предмета есть индивидуальность. Железная дверь, низкая дверь, массивная дверь. Такие предметы и запоминаются лучше и создают атмосферу. А с множеством одноликих предметов с одинаковыми лексемами могут быть проблемы.
Отредактировано Gremour (19.02.2008 14:52)
Неактивен