Forum.iFiction.Ru

Порождай детали от fixeditem и присваивай им в качестве location главный предмет. Они будет переносится с ним вместе и не будут отображаться в списках.

Если компоненты нужно отделять, сделать их как просто item, но придется подмодифицировать функции типа listcontcont, чтобы не печатали лишнего. Или подыгрывать флаг isListed для деталей, обнуляя его когда деталь прикреплена к предмету. Прикрепление/открепление, естественно, делается на обработчиках соответствующих глаголов.

fireton написал:

у меня в нескольких комнатах есть окна, а в них, естественно, оконные стекла.

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

Если возиться так с каждой декорацией, не хватит никаких сил закончить игру. Стёкла эти оконные, они тебе для паззла нужны или просто чтобы были? Сделай стекло синонимом окна. Если надо разбивать, делаешь свойство isBroken у окна. Если надо открывать форточку -- открываешь окно. Игрок ведь будет мыслить именно так: открыть форточку = открыть окно, разбить стекло = разбить окно.

Можно ли не определять "оконное стекло" в каждой комнате, а сделать класс "окно", в котором есть и стекла, и форточки (к примеру).

Сделать можно. Есть оператор new для динамического порождения объекта. В классе "окно" сделать свойства-указатели на динамически порождённые стёкла, форточки и что там надо. Вариант с переносом стекла в комнату конечно прост и будет работать, но чем-то он мне не нравится.

Но, вообще, ТАДС рассчитан на уникальные предметы. Когда игрок ссылается на похожие предметы, можно определить, что имелось в виду, если у каждого предмета есть индивидуальность. Железная дверь, низкая дверь, массивная дверь. Такие предметы и запоминаются лучше и создают атмосферу. А с множеством одноликих предметов с одинаковыми лексемами могут быть проблемы.

Отредактировано Gremour (19.02.2008 14:52)