PCgame 版 (精华区)

发信人: boat (——★船儿★——), 信区: mud
标  题: 巫师入门观念篇续
发信站: 听涛站 (Tue Feb  6 18:24:20 2001), 转信


认 识 工 作


－－在开始制作之前
　　让我们大略看一下在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 的空格)，虽然缩不缩排无关程式
是否能够执行，但是如果你是一个只求程式执行正确，而不管别人是否容易阅读，在 M
ud这样一个由多人共同发展程序的环境中将会十分惹人反感。
例：请采用类似
　　if(...)
　　{
　　　　if(...)
　　　　{
　　　　　...
　　　　}
　　　　else
　　　　{
　　　　　...
　　　　}
　　}
　　else if(...)
　　{
　　　...
　　}
　　else
　　{
　　　...
　　}
　　的风格，不要采用
　　if(...){
　　　...
　　}
　　这样的风格。有人也许会说，我看很多正规的程序员就不这样子嘛！但是你别忘了
，LPC是一种特殊的编程语言，它还有有它特殊的工作环境。一是，它的程序有可能会经
过很多的人阅读与修改，二是它经常要在zmud这样的客户端软件下进行远程的在线逐行
修改，到了那时你就会对这样的规范体会颇深了。
２，开头的注释行并不是可有可无的，最起码得让你的同事对这个程序有疑问时知道找
谁？并建议是加上编写和修改的时间。
　　// 该文件完整的绝对路径 中文名称
　　// 作者完成或者是最修改日期
　　// 如有对该文件的重要说明，请写在这一行
３，对于房间的描述应该整齐划一，至少在同一区域下的场景描述都需保持一致。每行
控制在57至61个字节之间，建议人物20个字，房间30个字一行。对于人物的描述，出现
的信息提示也遵守这种规则。
４，档案路径名称最好和绝对路径无关，这样当你的程序在整个目录被移到另一路径下
后仍然能够正常运行，为此你可以用 __DIR__ 这个由MudOS提供的巨集定义表示这个档
案目前所在的目录(__FILE__表示目前这个档案的档名)，即使移动之后必须做修正，最
好也限於某个 .h 档案。
５，档案中尽量不要直接调用其它目录下的 NPC 或 OBJ ，为扩展性着想，至少房间一
定要调用自己目录下的。当然 /CLONE 目录下的除外，如确需要，请直接在自己的目录
下复制一份。如果确实发现各个目录对该文件的调用率很大，不妨申请大神直接在 /CL
ONE 目录下设置。
６，语言风格也许与写作的各个人有关，但是我们这里的金庸风格是十分明显的，什么
该有，什么不该有，最笨的方法就是翻翻原著。我们不希望在你创造的区域发现一块德
芙巧克力或者是冲锋枪。同时我们也希望区域的设计需要有相当的「原创性」，现在侠
客行上衍生出的版本非常之多，我们不希望我们巫师只是在这其间东抄一点、西窃一点
。能用自己想出来的东西，最好回避跟一些太出名的作品雷同的东西。在制作时，有关
的地理、历史以及相关小说应该是一个好的巫师的必备参考书籍。
７，所有的讯息必须正确而且适当，所谓「正确」是指基干一般常识必须无误，例如：
某人拉开一张桌子，自己看到的是“你拉开了一张桌子”，旁观的人也能看到讯息，但
却应该是“某人拉一了一张桌”，各有不同。而如果是某人看到桌子心中不由一惊的讯
息，旁观的人就不一定能看到了。所谓「适当」是指讯息出现的地方、讯息的长短、标
点符号、颜色、出现时间必须尽量合乎真实世界的情形，例如人物add_action的讯息应
该要能适当地表达出动作者的立场，不能有看起来怪怪的感觉。写作的时候，应该多想
想：现实中应该是怎么样的？
８，景物或物品的设置必须合理，如一株可以爬的树你可以把它写成房间的景物，也可
以用一个物品来表示树的存在(可以砍下来带走)，但是一个可以钻进去的地洞就不应该
写成一个物品，虽然在程序上是可行的，但却是绝不合式的。
９，人物的强度，也就是它的武功与经验必须合理，我们的MUD虽然采开放式的属性系统
，但是另一个重点是：NPC和玩家是同一个世界的人，NPC 的作用不能作为它具有变态能
力的理由，换句话说NPC的「强」必须有故事背景设定上的理由，比如根据天龙八部小说
你可以把少林寺中的一个烧火头陀设成罕世高手，但这必须要控制在严格的情况下需要
在游戏中给予足够的提示。任何应用上的牵强理由而设计的强力NPC会受到最严格的检验
。( 请先参照各门派掌门的强度，作为假设的玩家强度水准上限，NPC没有特殊理由不应
该强过这些人，而且这种强度的NPC应该是十分「少见」的。)一旦由于某种原因你要将
某一个存在的NPC调高，你必须要给玩家足够的提示与声明。
１０、武器装备的强度必须合理，和NPC相同，强力的装备也就是宝物应该是十分罕见的
，如果没有适当的故事背景设定，强力的装备会受到最严格的检验，而且这些装备必须
是极其罕见的，也要受到一定条件的限制。这里一个例子就是各种杂类的MUDLIB总会在
一些好奇的巫师手中出现一些增加1000级的伏魔刀之类的东西，这些东西一旦出现，事
实上将会对你（或者是原作者）精心构筑的整个MUD的武功系统的否定。
１１、区域的大小与其中所含的「机关」必须成正比。在这里我们给出一个数字，如果
你的区域每过10个房间，都全是一堆用房间编辑器做出来的改改叙述、名称和数字的房
间、NPC 、装备或物品，那对于这种阳春区域，我劝你还是自己收回去欣赏、不要作任
何通过你上级 QC （也就是对佻的程序进行品质鉴定）的可能性幻想。
　　此外，还有一些编程原则是必须遵守的：
一、自己定义的函数，在文件开始最好有一个函数原型的定义声明(声明的作法就是在文
件的开关几句将这个文件里所用到了自己定义的函数头写上，注意：末尾要加分号)，每
个函数前有一个简单的说明也是基本的要求（也就是前面加//的注释行，告诉别人，这
个函数是干什么的，是在什么地方调用，如果别人要修改要注意什么）。而一些复杂的
地方也最好加上注释。因为在线解决问题时是经常要查看源程序的。
二、若要完成复杂的功能需要对/d、/kungfu以外的目录增加或修改文件，需要先征得大
巫师的检查和同意。而在这之前，可以提请巫师组讨论，看看有没有更好的实现办法。

三、做复杂的物件时，尽可能将一些日后可以通用的功能做成inherit或include，以方
便以后的编写。
四、为兼容性、稳定性考虑，除非迫不得已，不要直接调用你很少看见过的EFUN(就是一
些由MUDOS定义的外部函数，你在整个MUDLIB是找不到它们的说明。)。
（下篇－－上手篇》）


--

※ 来源:．听涛站 cces.net．[FROM: 匿名天使的家]