作者  [e-mail]_,                                     看板  MUD         
 標題  Re: 致 Annihilator的公開信                                             
 時間  Dept. of Computer Science, Nat'l Tsing Hua  (Thu Nov 25 09:51:26 1999) 
 來源  SimFarm!bbs.ee.ntu!freebsd.ntu!news.cs.nthu!not-for-mail               
───────────────────────────────────────

汀 <[e-mail]> wrote:
> 然而他與其他 mudlib 的部份精神又有些類似, 既然 Ruby 宣告「重頭寫過」,
> 那 ES2 mudlib based 的定義已不復存, 然而就我個人於 ES2 mudlib 中探討
> 之後歸納出一些結論, 其中不考慮是否其精神與其他 mudlib 相同:

>             1. 繼承上出現 /feature 的物件特性分類
>             2. 將能共用的 function 自使用者物件分離, 寫入 daemon
>                如 combatd.c 等
>             3. ROOM 系統的同變數多層化設定技巧 ( 即dbase ([]) )
>             4. 與玩家有直接關係的物件分為 LOGIN_OB 與 USER_OB, 以區隔訊息
>                以 exec() 與 tmp_dbase["link_ob"] 做連接
>             5. 使用者資料的同變數多層化設定技巧 ( 類似 3. )
>             6. 玩家攻擊方式採用 mapping 方式呈現 ( action )
>             7. 技能系統的 /daemon 目錄規劃
>             8. condition 的設計
>             9. /feature 下的其他各種創新部份
>            10. board 系統的設計

        從系統本身所顯現的功能差異性, 大部份的情形之下, 沒有辦法
        用來證明系統 A 是否 based on 系統 B 的程式碼來建構的. 因
        為即令是以修改的形式來進行, 仍然可以達到功能差異的區隔.

        很多人跳槽到另一公司後, 開始發展與原公司同樣性質的軟體時,
        往往選擇保持一間 clean room. 不把過去任何的程式碼帶過去,
        以免誤用, 犯了侵權的行為.

--
+--
|道德的人創造不道德的社會| 回信位址：[e-mail]              -王建興-
                       --+