《新巫师入门手册》
第一章：观念篇
■ 内容提要：什么是巫师？怎样做一个巫师？如何做好一个巫师？
第二章：上手篇
■ 内容提要：最简单的房间怎么写？NPC又怎么写？先看懂一些常用的参数？
第三章：理解篇
■ 内容提要：什么是LPC？什么是函数、对象？只有理解才有利于消化
第四章：见习篇
■ 内容提要：我要工作了，怎么edit？怎么update？又怎么用call？
第五章：补遗篇
■ 内容提要：好好消化变量、函数的意义，完全掌握各种符号的运用。
巫师园地 入门手册 观念篇
第 一 章
观 念 篇
认 识 自 己
－－什么是巫师？
巫师是创造者，程序设计师，负责创造玩家眼里的游戏世界。你可以创造任何东西, 这也使得巫师这个位置显得很重要且需担负很大的责任。当一个巫师代表你可以在瞬间取一个玩家的性命，对游戏系统造成很大的损害，或是建立一个人间天堂。任何你想得到的都可以做到。
在目前的大陆，专职的巫师是很少见的。这恐怕主要是因为ＭＵＤ这个游戏还没有一套成熟的商业运营机制来使它产生经济效益，并以此养活那位专职的巫师吧！大多数巫师都是走的“玩而优则巫”的道路。很难想像：一个从未玩过ＭＵＤ的人会有多高的热情和动力去承担如此艰巨、而且是无报酬的工作。但并非说玩得好的玩家就一定要去做巫师，有人就是天生的玩家。流行的对于巫师有专职与兼职之说，这是指在一个ＭＵＤ与两个或多个ＭＵＤ担任巫师之分。我们的观点是坚决反对兼职巫师的，以下摘录的一段文字很能代表我们的看法：
--------------------------------------------------------------------
: 对于目前大部分的wiz兼职实在对于大陆泥巴这个freeware 是最大侮辱了
: 我对于巫师的看法就是该诚恳的，勤奋的，付出在自己最热爱的一个mud
: 而不该去其他的mud寻找所谓的新的创意，或是一个等待开发处女，如果
: 大家的目的是需要提高中国泥巴的整体水平的话，大概你一个单兵作用不
: 大吧，那可需要的是一个整体的力量。
: 兼职的巫师本身就是一种浮华的类wiz ,他们有点技术，热忠于这个那个的
: mud串门做个嘴片子，本身精力也许很多，有任务也许完成，下网了就也许
: 满足于自己名片颇多。
: 如果要获得新的想法，需要在其他mud当巫师才能获得吗？那不是成了看别
: 人的工作成果，“启发“自己的新想法？这...
: 如果觉得另外一个mud比现在所在的mud 更能体现自己的想法思路或风格，
: 那: 坚决的全身心的投入到那个更理想的mud里哪，如果觉得现在呆的mud
: 没发展了。那呆着也是惹那一身烦嘛！居然有人在自己不喜欢的mud里当
: wiz ，这...
: mud 本身就是体现一个创作群体的思想，现在大家对于mud的观念特奇怪，
: 做wiz 的等待admin发任务，admin 抱死自己的权利，不去发现wiz们的长
: 处而只知道门派、地图、daemon的下任务，有技术的wiz抱怨工作简单、无
: 聊，需要提高的wiz抱怨石头太硬。这就导致了巫师这个群体成个很官僚的
: 状况，如果大家真心的做个mud，又何至如此呢。
: 还有就是兼职也导致侵犯某些codes的作者的权利，甚至有人拿着这边的程
: 序到那边去申请职务，这...
: 如果大家真心要把自己做的门派，或是得意的程序奉献给大家，那建议把
: 那些程序放到自己的主页上呀，好坏自有公论嘛，而且大家在你的主页上
: 经过讨论，或者对你是个更大的提高呢，这样大家知道是你的程序，觉得
: 保证你的权利。freeware,sigh，到了中国这个福地，什么都变味了，人们
: 换着法子的保护自己署名的权利，更大一群人拿着去掉开发者的署名的程
: 序做开发. 这... 是freeware 的精神吗？限制巫师兼职根本就不是一种可
: 以用来限制的条件，只是一相情愿的愿望而已。（有删改）
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 166.111.54.141]
---------------------------------------------------------------------
－－巫师的观念：
巫师是什么？巫师并不是神，神只是提供我们服务器、提供我们站点的人物，在我们这里，他们被定义为(gods)，真正的巫师都是同玩家一样通过远程登录上去的用户——只是一个拥有较多权限的超级用户而已。因此本质上也是一种高级的玩家，但他所遵循的原则却要绝对地高于玩家。
****
争吵
****
巫师：永远不要与玩家争吵。如果你觉得自己错了，请于第一时间去改正它，第二时间再向玩家说明。要是觉得丢面子的话，就保持缄默吧。如果你觉得自己没错，就不要理会，对方再纠缠下去干脆 kickout....有些事情是越争越越乱、越争越糟糕。还有一点：你如果上线时手头有事情要处理或者没有二十分钟以上的闲功夫，奉劝你不要现身，隐身处理事情算了。
玩家：永远不要与巫师争吵。如果你觉得自己对的，尽可能地去post或mail，如果觉得自己未被重视受到了伤害又不大可能得到补偿，你可以拒玩这个站点。如果你发现是你自己错了......你完了.........
****
要求:
****
巫师：永远不要对玩家提出要求。如果你觉得确需限制，就直接设计出程序，只要他们在规则的允许之内，任由他们发展。一个好的巫师是完全通过他的程序来实现对世界的调控，而不是言语。话多的巫师工作将会很累很累。
玩家：请不要对巫师提出出格的要求。这是一种很不健康的思想，理论上，玩家与巫师应该是有某种正式的沟通管道，而尽量减少私底下的交易。也就说，巫师应该只是制订规则、写区域、管理维护MUD，而尽量减少介入玩家的生活或成长过程。玩家也应该要尽量不要要求不在巫师工作范围内的事情，最常见的就是向巫师索取仙果、询问打开暗门的口令、某个秘密人物的所在。这种要求直接导致你在巫师心目中的评价直线下降。如果牵涉到要求改武功、提经验的地步的话，可能会带来进行坐黑牢的惩罚。而在此，我们还得指出一点，对于巫师来说“勿以恶小而为之”，最好的办法就是做一个铁石心肠的家伙，拒绝一切超越工作范围的事，否则，你还是去做一个“新手指南”的玩家好了。
****
脾气:
****
巫师理论上不应该有任何的脾气，这也许有点不尽人情，但是我们对每一个巫师都这样建议，上线前深呼吸几次。一上线先hihi，遇到事情先hehe，实在脾气上来压也压不住时，你干脆就quit再拍桌子跺脚大叫几声：“老子再也不做巫师了！”然后心平气和地再 login进去，巫师当然还得做、程序也还得写、丑话还得听。人们不是常说：“我们都有情绪因为我们不是神仙”，哈哈！现在你一在线，你就已经是神仙了。所以........
****
动力：
****
一个纯义务的、没有报酬的工作，初期的那份新鲜劲会随着没完没了的程序、函数而消磨怠尽。因此你得不时地给自己寻找动力。善始善终，巫师应该是程序员届最能考验人的工作之一。
****
水平
****
怎么你也得了解一下 MUDOS吧？实在不行，大致有个概念也成。对于 LPC你总弄懂吧？你所工作的MUDLIB不看完也说不过去吧？也许你目前还不行，但你若真的想当一名好巫师，你就得朝这个目标去做。
——巫师权限简介：
大总管(gods)：这个级别的比较特殊，一般是由你服务器所在单位的工作人员或管理人员担当。严格意义上，只有他们是神。神可以什么事都不做，却可以决定任何事情。不要去向神要求什么？你所要做的事除了沟通就只有祈祷。当然，对于神来说，除了到处goto和参预巫师频道的讨论外，他们也不必要过多的档案处理权。因为服务器就在他们的身边，任何制约对于他们来说都是可笑的，“神打了个呵欠，地上就刮了三个月的风暴”.........
天神(admin) ：游戏的实际管理人，在游戏中所有事情的最后决定者。事实上他们只是神的使者的意义。天神唯一的限制就是不能（确切说应该是不准）修改 /LOG 下的文件，那里只有真正的神（大总管）才能通过服务器的操作进行删除。
大巫师(arch)：天神的助手，一般都是由熟悉系统架构的人来担任的。大巫师也是执行多数区域的 QC 的人选。只有一些涉及系统更动的问题，才必须通过天神进行更新操作，大巫师与天神没有职责上的区别，只有处理权限的不同。
巫师(wizard)：写区域的人, 请乖乖的遵守所有的巫师规则.
巫师学徒(apprentice)：练习生。在这个阶段，你的工作是先熟悉环境和相关规定。调适一下你的心态，并确实的知道当巫师所负有的责任.
－－一些见议：
当巫师好像是在当创造者，任何你想得到的东西都可以通过程序做到。因为这样，请你动手前务必多想想，先把后果想清楚了再做。如果不幸出了些差错，也请完完全全地负起责任并承担后果。永远记住，你的一举一动，不论大小，对这个游戏都将造成一些影响，请尽量让这些成为正面的影响。
善待你的同事并尊重你的上级，巫师级别的划分并不一定是完全反应着能力的高低。而实际上略通编程技巧的人也都知道，一个wizard可以很轻易地把自己改为 admin，而事实上你也别去动这个脑筋。巫师守则的遵守只是靠相互信任与自觉。原理上，用程序我们是可以完成任何事情。系统中的各种防御及记录体系也都是防君子不防小人的，但是我们不希望在程序中看到巫师物品，即使必须要有，一定要加上对使用的人的权限判断，我认为有写巫师物品的时间还不如多设计几个谜题算了。
认 识 工 作
－－在开始制作之前
让我们大略看一下在LP MUD，即所谓战斗 MUD中, 世界的构成方式。这个世界是由一个个的对象(object)所组成, 每个对象有一个对应的程序来描述它的特性。在游戏中所见到的每个房间，每个 npc，每个物品，甚至你自己，都是一个object，都是一段程序。
我们首先写出一段程序来创造出一个全新的对象，然后利用update来更新对象所属的程序, 再用 clone来实际造出一个可用的对象。在这里所谓更新，就是将硬盘里这个文件编译后形成一段代码，这段代码是存在于内存中的。在MUD中，程序只有进了内存方可执行。因此当你修改了或新写了一个文件，那只表明你在硬盘上改动或创造了这个文件，你必须做一下update，将它编译放入内存，你的修改和创造才正式生效。而clone命令其实就是update+move，因为它update的是一个物品或npc，这个物品或npc还需要有地方放。（看起来吃力吗？没关系，当你对 updata和clone的操作十分熟悉后，再想想这段话，你就会chat* oh）在系统里, 我们可以制作各式各样的对象, 但是都可以将之划分在三大类里面: 房间、物品与生物。在制作区域时, 我们习惯将区域放置在根目录下的/d 目录。房间的档案就直接摆在区域的目录下，生物与物品则摆在这个区域中名为 npc及obj的子目录中。
－－制作的基本品质要求
所有的 MUD都有自己的风格、发展方向、跟程序品质的要求。由于这些东东与程序是否能通常执行关系不大。有时仅仅只是一些个人习惯而已。作为MUD这么一个集体创作的作品，这种习惯就有必要有一个集体性的统一，这种统一大约是随著主持这个 MUD的admin而异。事实上又由于每个admin对mudlib的了解程度不一，所以对品质要求的深度也不同。以下是我们“无锡 MUD巫师组”对各位新加盟的巫师的品质要求：
****
命名
****
命名的一个基本原则就是简单直观。一般我们要求使用中文的拼音，如果其英文名很熟知并确实比拼音短小直观的情况下，也可使用英文，当然也包括那些已经约定俗成的如：room、eat、food、cloth等。在使用拼音时，要遵循下列要求：
１，请尽量保证发音准确，没把握请查字典；
２，两字词直接连写，例：大门 damen.c，超过两字请使用隔断符号进行间隔，以免出现难以辨读的情况。
３，隔断符号分“_”和“-”两种，它们两者的区别在于前者两边的关系是修饰的、而“-”两边之间的关系是并列的。东客房可以写成dong-kefang或者是kefang_dong，两者之间的区别相信不需要我再多说了吧。
４，四字词应在两字中间用“-”隔开，象wuxidayu应该写成wuxi-dayu。三字词请选择好隔断的部位。象老管家lao-guanjia就不能写成laoguan-jia，这些看起来似乎有些罗嗦，但的确是必须养成的一种良好习惯。
此外，命名最好形成统一的规范，不管在哪里当巫师，一定要先仔细看一看那里的大部分文件的命名格式，尽可能地与前面的文件相融合。
****
目录
****
目录原则上没有什么过多的限制，有一些传统，你可以通过阅读整个系统的文件来看明白。一般的区域放在/d目录下，每一区域中下面再包含npc与obj两级子目录，用于放置这一区域里的人物与物品，一般不要再增添其它的有关子目录，而可以教授武功的人物请放在/kungfu/class/下的同名称的目录下，我们所要提醒的一点是，在新的区域目录的设置上要相对合理，里面文件过少，就请合并至相近的一个目录中，如果太多，也要尽量拆成两个目录。以免给日后对该目录的操作造成不便。
****
程序
****
程序语言相当简单，但是良好的习惯必须在一开始养成。
１，程序必须缩排整齐，缩排一律用 tab (相当於 4 的空格)，虽然缩不缩排无关程式是否能够执行，但是如果你是一个只求程式执行正确，而不管别人是否容易阅读，在 Mud这样一个由多人共同发展程序的环境中将会十分惹人反感。
例：请采用类似
if(...)
{
if(...)
{
...
}
else
{
...
}
}
else if(...)
{
...
}
else
{
...
}
的风格，不要采用
if(...){
...
}
这样的风格。有人也许会说，我看很多正规的程序员就不这样子嘛！但是你别忘了，LPC是一种特殊的编程语言，它还有有它特殊的工作环境。一是，它的程序有可能会经过很多的人阅读与修改，二是它经常要在zmud这样的客户端软件下进行远程的在线逐行修改，到了那时你就会对这样的规范体会颇深了。
２，开头的注释行并不是可有可无的，最起码得让你的同事对这个程序有疑问时知道找谁？并建议是加上编写和修改的时间。
// 该文件完整的绝对路径 中文名称
// 作者完成或者是最修改日期
// 如有对该文件的重要说明，请写在这一行
３，对于房间的描述应该整齐划一，至少在同一区域下的场景描述都需保持一致。每行控制在57至61个字节之间，建议人物20个字，房间30个字一行。对于人物的描述，出现的信息提示也遵守这种规则。
４，档案路径名称最好和绝对路径无关，这样当你的程序在整个目录被移到另一路径下后仍然能够正常运行，为此你可以用 __DIR__ 这个由MudOS提供的巨集定义表示这个档案目前所在的目录(__FILE__表示目前这个档案的档名)，即使移动之后必须做修正，最好也限於某个 .h 档案。
５，档案中尽量不要直接调用其它目录下的 NPC 或 OBJ ，为扩展性着想，至少房间一定要调用自己目录下的。当然 /CLONE 目录下的除外，如确需要，请直接在自己的目录下复制一份。如果确实发现各个目录对该文件的调用率很大，不妨申请大神直接在 /CLONE 目录下设置。
６，语言风格也许与写作的各个人有关，但是我们这里的金庸风格是十分明显的，什么该有，什么不该有，最笨的方法就是翻翻原著。我们不希望在你创造的区域发现一块德芙巧克力或者是冲锋枪。同时我们也希望区域的设计需要有相当的「原创性」，现在侠客行上衍生出的版本非常之多，我们不希望我们巫师只是在这其间东抄一点、西窃一点。能用自己想出来的东西，最好回避跟一些太出名的作品雷同的东西。在制作时，有关的地理、历史以及相关小说应该是一个好的巫师的必备参考书籍。
７，所有的讯息必须正确而且适当，所谓「正确」是指基干一般常识必须无误，例如：某人拉开一张桌子，自己看到的是“你拉开了一张桌子”，旁观的人也能看到讯息，但却应该是“某人拉一了一张桌”，各有不同。而如果是某人看到桌子心中不由一惊的讯息，旁观的人就不一定能看到了。所谓「适当」是指讯息出现的地方、讯息的长短、标点符号、颜色、出现时间必须尽量合乎真实世界的情形，例如人物add_action的讯息应该要能适当地表达出动作者的立场，不能有看起来怪怪的感觉。写作的时候，应该多想想：现实中应该是怎么样的？
８，景物或物品的设置必须合理，如一株可以爬的树你可以把它写成房间的景物，也可以用一个物品来表示树的存在(可以砍下来带走)，但是一个可以钻进去的地洞就不应该写成一个物品，虽然在程序上是可行的，但却是绝不合式的。
９，人物的强度，也就是它的武功与经验必须合理，我们的MUD虽然采开放式的属性系统，但是另一个重点是：NPC和玩家是同一个世界的人，NPC 的作用不能作为它具有变态能力的理由，换句话说NPC的「强」必须有故事背景设定上的理由，比如根据天龙八部小说你可以把少林寺中的一个烧火头陀设成罕世高手，但这必须要控制在严格的情况下需要在游戏中给予足够的提示。任何应用上的牵强理由而设计的强力NPC会受到最严格的检验。( 请先参照各门派掌门的强度，作为假设的玩家强度水准上限，NPC没有特殊理由不应该强过这些人，而且这种强度的NPC应该是十分「少见」的。)一旦由于某种原因你要将某一个存在的NPC调高，你必须要给玩家足够的提示与声明。
１０、武器装备的强度必须合理，和NPC相同，强力的装备也就是宝物应该是十分罕见的，如果没有适当的故事背景设定，强力的装备会受到最严格的检验，而且这些装备必须是极其罕见的，也要受到一定条件的限制。这里一个例子就是各种杂类的MUDLIB总会在一些好奇的巫师手中出现一些增加1000级的伏魔刀之类的东西，这些东西一旦出现，事实上将会对你（或者是原作者）精心构筑的整个MUD的武功系统的否定。
１１、区域的大小与其中所含的「机关」必须成正比。在这里我们给出一个数字，如果你的区域每过10个房间，都全是一堆用房间编辑器做出来的改改叙述、名称和数字的房间、NPC 、装备或物品，那对于这种阳春区域，我劝你还是自己收回去欣赏、不要作任何通过你上级 QC （也就是对佻的程序进行品质鉴定）的可能性幻想。
此外，还有一些编程原则是必须遵守的：
一、自己定义的函数，在文件开始最好有一个函数原型的定义声明(声明的作法就是在文件的开关几句将这个文件里所用到了自己定义的函数头写上，注意：末尾要加分号)，每个函数前有一个简单的说明也是基本的要求（也就是前面加//的注释行，告诉别人，这个函数是干什么的，是在什么地方调用，如果别人要修改要注意什么）。而一些复杂的地方也最好加上注释。因为在线解决问题时是经常要查看源程序的。
二、若要完成复杂的功能需要对/d、/kungfu以外的目录增加或修改文件，需要先征得大巫师的检查和同意。而在这之前，可以提请巫师组讨论，看看有没有更好的实现办法。
三、做复杂的物件时，尽可能将一些日后可以通用的功能做成inherit或include，以方便以后的编写。
四、为兼容性、稳定性考虑，除非迫不得已，不要直接调用你很少看见过的EFUN(就是一些由MUDOS定义的外部函数，你在整个MUDLIB是找不到它们的说明。)。
怎么开始工作，有人说先做起来再说，有人说先看起来再说，我们的意见是，从简单的房间和人物在编写开始，最简单的起步就是找一些相近的自己也能看得懂的程序来改，这样产生错误的可能最小。待涉及到机关与秘密的制作后，再开始全面地读看MUDLIB的程序，实在看不懂，先跳过去，一直看完，结合我们的中级工作手册（编纂中），我想接下去的自学历程应该是十分顺利的了吧？
为了使这本手册最大限度地通俗易懂，我尽量做到决不过早地向大家提及一大堆专业术语，以免吓跑我们的新巫师朋友，但是......这里，我先提一个，就一个......好不好？我们来理解一个概念－－继承（inherit）。在程序中，继承的意义就在于把很多东东中间的共性提出来，设置成一些标准物。然后，别的程序就没有必要再一个个地重复设置，直接继承它就有了这些特性。继承共分两种：一是标准物件，就是具体的东东，比如说：npc(人物)、item（物品）、room（房间）；第二种就是标准特征，比如说：F_MASTER（可收徒的）、F_EQUIP（可装备的）。多用继承可以大大减轻系统的记忆量，也对我们的工作带来很大的便利。好，下面我们开始写程序了。
我们新巫师不会一上手就去开发新的系统程序，先起手写的大都是一些简单的房间、物品、人物，这类程序首先必需要继承一个标准物件，如：房间要 inherit ROOM; 物品要 inherit ITEM; 人物要 inherit NPC; 道理前面已经讲清楚了。
接下来可能要碰到一大堆令人头疼的函数了，不过没关系，我们先不要去理会它们，做一些简单的房间呀、人物之类的只要用到一个最基本的函数：create()。create()的作用就是在你写的这个程序，不管是房间还是东西，当它被制造出来，它就会立刻启用这一函数，对自己进行一些最基本的设定。函数里的语句格式也很简单，就是：
set("属性",某个值);
到底有哪些属性可以set呢？你可以去找一些程序多看看，也可以问问较资深的巫师。下面为新巫师们列出了一些基本属性：（）里的表示这个属性的类性。string表示是字符串，int表示是数字型。
房间属性
"short"(string) 房间的短叙述。
"long" (string) 房间的长叙述。
"item_desc"(string或函数) 房间中个别景物的叙述，格式为：([ <景物名称>:<景物叙述>, .... ])。其中<景物叙述>可以是字串或 function type。
"exits" (mapping) 房间的出口，包括有门的方向，格式为：([ <出口>:<房间档名>, .... ])。
"objects" (mapping) 房间中的物品、生物，格式：([ <物品或生物档名>:<数量>, .... ])。
"outdoors" (string) 房间是否为「户外」，户外房间可以看到天色变化与气候影响。字串的意义表示房间的气候区，通常和该区域的 domain (即 /d 下的目录名称) 同。
"no_fight"(int) 房间是为禁止作战区域。
"no_magic"(int) 房间是为禁止施法区域。
人物属性
"id" (string) 人物英文名，这个字可以用来识别玩家，通常 "id" 跟 "name" 都不直接用set() 设定，而是用 F_NAME 中的 set_name()。
"title",
"nickname",
"name" (string) 人物的称号、绰号、与中文姓名。
"age" (int) 人物的年龄。
"age_modify"(int) 这个数值会在 update_age() 中被加在人物的年龄上，可以是负数。
"jing",
"eff_jing",
"max_jing"(int) 精，当前精，最大精
"jingli",
"eff_jingli",
"max_jingli"(int) 精力，当前精力，最大精力
"neili",
"eff_neili",
"max_neili" (int) 内力，当前内力，最大内力
"qi",
"eff_qi",
"max_qi"(int) 气，当前气，最大气
"shen_type", (int) 神的类型，0是负，1是正
"str",
"int",
"con",
"dex" (int) 人物的天赋，依序分别为膂力、悟性、根骨、身法
"combat_exp"(int) 人物的实战经验
"jiali"(int) 表示人物打中别人并加的内力点数。
"family"(mapping) 人物的师承门派等记录
"skill"(string) 人物的武功
物品属性
"name" (string) 物品的中文名称。
"id" (string) 物品的英文名称。
"long" (string) 物品的详细描述。
"value" (int) 物品的价值，单位是「钱」(coin)。
"unit" (string) 物品的单位，如：个、把、枝.....
"no_get"(int) 表示物品是否可被捡起来。
"no_drop"(int string) 表示物品是否可被丢弃，如果型态是 string, 则当有人企图丢弃这个物品时会将该字串用 notify_fail 传回去。
武器属性
"skill_type"(string) 这个武器所属的技能种类，如 "sword"、"blade" 等，要注意在 /d/skill下必须有一个定义该武器技能的物件，否则装备这个武器战斗时会有错误讯息。
"rigidity" (int) 武器的硬度，当使用武器相斗时，硬度、武器的重量、持用者的力量将会影响武器受损的机率。
"weapon_prop"(mapping) 武器对持用者的状态影响，通常武器只影响 "damage"，这些状态影响会在武器被装备时用 add_temp() 加到持用者的 apply 上，并於卸除或 dest时减回来。
一个基本的房间，只要有 short <短叙述> 、 long <长叙述>、 exits <出口>就行了。就象：
void create()
{
set("long", @LONG
房间的叙述.......
LONG
);
set("exits",([
"west" : __DIR__"path3",
]);
在这里__DIR__是什么意思？假如说我们写的这个房间的文件在/d/city目录下，那么这个__DIR__就是"/d/city/"也就是“"west":"/d/city/path3"”的意思。在上一章的品质要求里讲过，我们提倡采取这样的写法，因为这样写了以后，不管你这个区域的目录放在哪里、或者是更名都不会受到影响。接下来，我们可以给这个房间里添一点生动一些的东西，比方说，让玩家在这里能够look到什么：
set("item_desc", ([
"景物名称1" : "景物叙述",
"景物名称2" : "景物叙述",
...........(可以有很多)
]);
其中景物叙述可以是一句、几句话，或是一个自定义的函数，这个函数你就写在后面的某个地方，以根据不同的情况显示look景物名称后而出现的信息与效果。所以你可以利用这个功能加以变化，当玩家 look 一个景物时，可能看到叙述，也可能发生一些特殊的事件。
然后下面就再给这个房间加点东西。
set("objects", ([
"物品或生物的档名" : 数量,
...........
]);
如同前面所提到的，建议采用 __DIR__来编写你的路径，而数量则要用整数。
写到这里，有的巫师有点不满足，说，我看见有的房间有时某一方向的门是开的，有时又看不到，要使用open door指令打开门才行，这是怎么做呢？这其实也简单，只不过首先要复习一下前面的继承概念。因为这个门是房间里的一个特征继承，需要用到一些在/include/room.h里定义的一些变量，所以要有文件头记得必须先 #include <room.h>。然后在文件中写上：
create_door("出口方向", "门的名称", "进入方向", 预设状态);
比如说，这里明显的出口有 west、east 和 up。 而你要让西边有一个关上的红木门，你可以这样写：
create_door("west", "红木门", "east", DOOR_CLOSED);
当玩家进入这个房间时，他会看到：
这里明显的出口有 east 和 up。
而当他 look west 时，会看到：这个红木门是关上的。
有关create_door()是如何让你的房间表现出这样的特性的，那就要去仔细看看学习它所继承的/inherit/room/room.c文件了。不过对于新巫师来说，还不必急着去看，只要知道要加上这些语句就可以实现，也就行了。