| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

怎麼從一個mudos開始構架一個LPC library

Page history last edited by PBworks 13 years, 7 months ago

 

 

 

- 作者:darks  發表時間:2001年6月5日 12:53

 

--------------------------------------------------------------------------------

 

首先我們應該知道mudos提供哪些服務

我們可以從許多lib中找到我們需要什麼

假設我們的lib還是擁有很多現在mud的特性 比如戰鬥 人物和世界

我們需要一些最基本的東西

比如 master.c user.c login.c <include>

你完全可以使用不一樣的文件名 甚至修改出自己的mudos

你也可以完全使用一個成熟的lib來修改 不過這裡要討論的不是這些。

我們需要一個指令目錄 一個系統配置文件的目錄 一個數據保存的目錄 一個幫助文檔的目錄 一個安全系統 一個角色系統 一個戰鬥系統(如果你是戰鬥類的 根本不需要這個)

一個網絡服務提供系統(這個一定需要嗎?可以不需要) 一個核心守護 一個時間系統(如果你的mud只有簡單的時間概念 也根本不需要這個) 一個處理文字的系統

我們可以找出很多lib都有的通性 這些文件可以這樣描述:

// Daemons

// maintains information on legitimate character creation

#define CHAR_D                  "/secure/daemons/chard"

// support to chinese character

#define CHINESE_D               "/secure/daemons/chinesed"

// handles fighting events

#define COMBAT_D                "/secure/daemons/combatd"

// handling core daemon state

#define CORE_D "/secure/daemons/cored"

// handles the loading and rehashing of verbs

#define COMMAND_D               "/secure/daemons/cmd_d"

// handles domain state and build rooms

#define DOMAINS_D "/secure/daemons/domains_d"

// emote daemon

#define EMOTE_D                 "/secure/daemons/emoted"

// the management daemon a user connects to before determining their real body

#define LOGIN_D                 "/secure/daemons/logind"

// handles mud's Quests

#define QUEST_D            "/secure/daemons/questd"

// handles security of Lpmud

#define SECURITY_D              "/secure/daemons/securityd"

// handles intermud services

#define SERVICES_D              "/secure/daemons/servicesd"

// management daemon of time/disasters/scenario

#define TIME_D            "/secure/daemons/timed"

// handles update events

#define UPDATE_D                "/secure/daemons/updated"

// virtual daemon

#define VIRTUAL_D               "/secure/daemons/virtuald"

// handling vote security

#define VOTE_D            "/secure/daemons/voted"

 

 

構架lib 最先要考慮的不是針對一個遊戲 而是一個遊戲支持所必需的內容 連接 服務 和表現 而我覺得 可擴展性 在經歷這麼多年以後 對於Mud而言 已經日益重要

 

 

 

1.指令    

       是玩家接觸mud world的直接界面 沒有好的指令 就算這個角色不是blind 也會感到看不到東西的感覺 所以最基本的指令 是look say quit who 等等 注意say代表的是交流的意思 而不是現在mud的含義-"說"

 

 

 

2.數據保存

       正式開啟mud world的時候必須考慮的問題 你可以使用傳統的文件保存方式 也可以採用msql/mysql數據庫方式 要注意的是 不要以為傳統的方式是一個無效的或者無能的方式

不過利用高效的mysql方式 還是比較好的 這裡的數據 不要單純的認為是玩家本體的數據 一個mud不單單只有這些數據 更多的數據可能出現 比如地圖(rooms) 動作(emotes) 物件((objects) 技能(skills)

 

 

 

3.安全系統

       傳統的es安全模式借助於uid系統,這是快10年的系統了。而每個LPC Library都可能會有自己的系統。注意一個mud往往有三部分構成 分的比較明白的就是mudos 還有兩部分是  LPMud 和 LPC Library 的說法。比如常說的 ES TIM-II NIGHTMARE 都是LPC LIbrary

而ES3 就是  ES LPMud,比如fy3這個LPmud 使用的ES lib library。安全的做法很多 而且沒有一種是絕對安全的畢竟這個mud系統先基於unxi更基於internet。但是目的只有兩個:安全和使用性。安全是指能保證原創者的利益,使用性是指能發揮使用這個 LPC lib的人的自主性,不要單單認為是設計者或者是大家說的巫師(wizard)。

 

 

 

4.角色系統

        如果你的lpmud不需要角色,那麼這個可能對於你是無足輕重的。如果你要求體現完美的人物特性,那麼複雜而不冗餘的系統是需要的。一般角色所要表現的東西都應該考慮一下。傳統需要的是 表現 生命 動作和交流。

 

 

 

5. 戰鬥系統

        首先 確定你的lpmud是否需要戰鬥 這裡的戰鬥是指比較複雜的戰鬥 包括西方的魔法和東方的戰鬥都是戰鬥。戰鬥系統的表現方式有很多種 需要提醒的是 心跳並不是唯一處理戰鬥的方式。就好像現在很多遊戲都使用既時系統但是還有很多的遊戲在採用回合或者半回合的方式。ES的lib比較東方化 但是帶有明顯的西方mud的特性 就是心跳來處理普通技而傳統武俠是沒有skill perform的區分的。記住,沒有心跳一樣可以戰鬥。戰鬥要處理的事情就是 怎麼決定出手(心跳是AI處理的一種途徑) 怎麼決定結果(傷害 迴避等等) 怎麼決定仇殺等等 表現方式(描述)

 

 

 

6 網絡服務系統

         更多的服務被包含到intermud3中,mudos顯得更像是一個server服務提供者,最多可以達到4-5個端口,可以用來提供包括http/mail/ftp/finger/telnet/等等服務 其實我們可能根本不需要這麼多一個最基本的telnet或者ftp用來處理一些文件服務 一個簡單的UDP交流可以用來保持相關mud之間簡單交流。另外 文件自動更新功能數據統一風格 分站區域互連和漫遊也在考慮的範圍之內

 

 

 

 

7.時間系統

        一個時間系統,用來保持整個Mud的發展,天氣/災難/故事的發生都可以歸納到這一類。良好的時間系統可以用來紀錄mud world的歷史,這方面參考國外的mud可以收益良多。好的系統已經出現了時間 天氣 季節 區域 災難等等的結合。東方太陽西方雨。

 

 

 

 

一些基本的設置用來維持一個LPC lib,而作一個LPMud,還需要更多的變化和環境。不僅僅是一個LPC lib。就好像一個linux系統 單單只有內核是不行的。

 

 

 

我的概念中有三部分的東西    

 

 

 

作者:darks  發表時間:2001年6月9日 09:19

 

--------------------------------------------------------------------------------

 

Mudos是LPmud的driver 他提供最基本的一些函數和事件 以便設計者可以利用這些函數構架出一個LPmud 而LPmud中有一部分稱為LPC library,比如ES lib,Lima lib等等,Library擁有一些基本的系統,包括connect的處理和character的處理等等,最基本的一種lib就是隨mudos發佈所帶的Lil,這個lib可以稱做lib的典範,沒有任何地圖,只有一個void,這個lib不能用來遊戲,根本不能常規的稱之為LPmud,但是這確實是一個lib,該有的都有了。Library的特點就是共同性,不管這個遊戲是什麼,這個Lib都不需要怎麼改動。比如基本的dbase treemap繼承什麼的 都是屬於ES lib的範圍,但是一些技能,一些任務系統(至少我以前看到的都是屬於整個LPmud範疇)都是LPmud範圍的。fy3的task系統,在有坐標的 mud中已經可以看作是一個lib範圍的設計了。因為程序和數據已經分開,不需要修改系統就可以變化出新的內容。我現在不太清楚國內的mud對任務系統是不是已經分化出來了。但是挺多的任務在我的影響中和地圖、人物(LPMud本身)是分不開的。這些任務只能說是整個LPMUD的一部分,用 Nightmare的話來說,就是:這部分屬於 This LPMud,但是不是 This LPC Library的一部分,使用這部分代碼許可權歸This LPmud的管理者,而不需要通過LPC library設計者的許可。也就是說,將一個Mud的使用或者改寫許可分為兩部分,只要擁有Lib的使用許可,你都可以使用,所以你可以使用ES lib來架設任何自己設計的Mud,因為這個lib是被Annihilator許可的。但是你不可以隨便拿個Mud的架,因為還有很多內容不是ES lib的範疇,而屬於那些Mud的管理者。

 

 

簡單的來說,就是MUD是一個整體,是一個獨特的個體。而Mud library可以是一個基礎,可以在lib基礎上,製作出很多類似的Mud。

 

 

如果當你的設計Mud Library的時候,加入了共性的任務結構,也就是說,可以應用於符合規則設計出來的世界。那麼不管世界如何改變,這個系統都會被適用。這才能說是,這個Lib的任務系統。由於事件的共性化非常複雜,所以沒有一開始就提出來,但是我倒是很希望能歸入lib中,這樣子,基於這個lib開發的LPmud,將具備極佳的任務擴展性。

 

 

--------------------------------------------------------------------------------

 

 

兩袖清風

 

 

MUD本身就是在模擬一個相當複雜的世界,要想把他們都歸納出一個包羅萬象的共性出來,可能嗎?或者說容易嗎?    

 

 

 

 

 

作者:jackyboy  發表時間:2001年6月9日 22:14

 

--------------------------------------------------------------------------------

 

darks認為我們的目標應該放在哪一部分上?

 

是lpc library?還是driver?

 

 

對於一個MUD,我們關注的是外在表現多於內在的實現方式,是麼?

 

 

由一個系統的外在我們怎麼去歸納出來這個作為基礎的MUD LIBRARY呢?

 

 

到底目標是哪個?我覺得有好多概念性的東西如果不說得夠通俗易懂的話,怕少有人能明了一個提案的意圖,乃至最終加入進來。這方面的解釋我想一來也可以讓自己更加肯定什麼是最需要去做的,二來也可以讓更多的人明白和加入。應該多做做這個事。:)

 

 

說實話,有時候我看了發出來的帖子不知道是有所獲還是無所獲,即使有所獲也是有點混沌似的。:)

 

 

 

--------------------------------------------------------------------------------

JackyBoy

 

 

關注的是外在的表現    

 

 

 

 

作者:darks  發表時間:2001年6月11日 09:14

 

--------------------------------------------------------------------------------

 

但是外在的表現的擴展性需要有好的lib支持,比如,使用了數據庫和不使用數據庫的lib,他所能表現的東西差不多,但是擴展性差了很多。比如擁有fy的 task系統,修改這個任務系統就非常方便,也很容易擴展,但是不是這種的,就比較困難。driver我不認為非得修改,因為專門有人在為這個工作。 driver有時候是和mudlib不可分的,因為一個lib的撰寫總是和一個特定編譯出來的driver聯繫在一起。由於driver的特殊性,我覺得發佈的時候,不應該包含driver。而mudlib顯然和這個不同。

 

 

 

簡單的來說,我們關注外在表現,但是這個只有在一個共同的底層lib上才能發揮出來。或者是基於ES或者基於Lima或者其他。。。而基於ES lib的Mud,國內已經開發的很多了。這個lib基本上已經被開發的差不多了。如果再想求突破,比較困難。就好像現在的很多遊戲都是用Quake3引擎,當然遊戲本身和Quake3完全不一樣。但是如果Quake3引擎沒有突破,那麼整個遊戲,也就看上去是那樣子的。:)

 

 

Blizzard的優點在於將成熟技術的潛力發揮到極點,他的遊戲技術不是最前衛的,但是確實最成熟的。基於成熟的技術,可以將遊戲的可玩性發揮及至而無技術後患。目前的國內基於ES的Mud就是類似這種情況。但是現在Blizzard本身也很難突破starcraft了,所以他們開始使用3D,使用這個以前不成熟,但是現在已經完全成熟的技術。我想,我們也該這麼做了吧。比如簡單的說,數據庫的使用,就應該被拿出來,別擔心現在的環境,mysql已經大行其道,而等你開發完成,估計早已經是非常成熟的環境了。

 

 

開發一個東西,應該將效果定在週期以後的環境,我是這麼認為的。

 

--------------------------------------------------------------------------------

Comments (0)

You don't have permission to comment on this page.