今明兩天是難得有空的時間，我今天先擬好架構，明天打算一股作氣 將系統雛形寫好。之前其實已經寫好一部份了，但因為 times_check 的關係(要改成它可以套用的)，就作廢了。 寫戰役系統是為了節慶活動。傳統上舉辦活動需透過 /d/event 目錄 底下各活動物件的寫法，我覺得那個太麻煩了，所以我其實很懶得舉 辦那樣的活動，為了解決這問題才會想寫戰役系統，這樣以後只需要 寫腳本就好了，腳本的好處就是具有可複製性、容易理解、容易管理 及做出變化、... 預計這個東西寫好後，聖殿就有區域產生器、任務系統、副本系統、 戰役系統，這樣艾恩葛朗特計劃就可以實行。 假設使用 /open/cmds/times_check.c 做為驅動引擎，依照斜角巷的 書店寫法，戰役系統必包含底下函數及程式段落: static object times_check; void init() { ::init(); if(!this_files) this_files=base_name(this_object()); if(!times_check) if(catch(times_check=find_object_or_load("/open/cmds/times_check"))) return notify_fail("目前 times_check 有問題喔.\n"); 幾個供 wiz 使用的 add_action(); } int times_check(string names,string files,mixed tmps) { int s,sk; string str; object ppl; if(!times_check) if(catch(times_check=find_object_or_load("/open/cmds/times_check"))) return 1; // 這函數就是 times_check 每隔一段設定時間就會來呼叫的 times_check->set_times_check(戰役標籤,this_files,({參數群}),下一次呼叫間隔); return 1; } 然後當有戰役被觸發時，使用的呼叫程式段就是 times_check->set_times_check(戰役標籤,this_files,({參數群}),下一次呼叫間隔) 然後再依 /std/new_ob/boat.c 的寫法，boat 設有 plane 參數， 而 times_check 函數便是依該參數來決定每一個呼叫週期要做哪 些事情。 由上可知，可套用 times_check 的戰役系統必然也是有設定一些 東西--也就是腳本，然後 times_check 函數再依據寫好的腳本來 執行。 一般來說，總管型的戰役系統的 times_check 函數需能做到底下 判斷: 1.各戰役腳本物件的管理及資料載入 2.同一時間多場戰役的狀況顯示及流控管理 3.每一呼叫週期的 a.該做什麼事 b.滿足什麼條件之下才做下一階段的呼叫 c.否則就持續重覆該階段 d.戰役何時結束、失敗、或中止的判斷 戰役腳本物件必須包含這些設定 4.每一呼叫週期至少需可做到 a.呼叫怪物並設置於指定地點 b.進行全域或特定區域廣播 c.判斷怪物存活情況與玩家擊殺數等 . . 因此仿 /open/cmds/quest，應該要有 /open/cmds/war 這樣的目 錄設置，在該目錄下有多個戰役腳本這樣。 但是，總管型的戰役系統並不是良策(這也是我重寫的原因之一)， 因為同一戰役理論上只會在同一時間被開啟一次，因此戰役之間並 不需要「總管流控的物件」，各戰役由各戰役腳本來兼做戰役管理 即可，根據之前的實驗，套用 times_check 的物件即便被 update 也不會影響 times_check 的呼叫，因此由戰役腳本兼做戰役管理 是可行的，帶來的好處就是 1.戰役資料直接本地端存取 2.戰役所需自行編寫的相關管控函數，就直接寫在該戰役物件裡頭 　，方便其它 wiz 更容易瞭解該戰役架構組成(因為都寫在同一檔) 3.仍舊可寫一個 war.c 總管物件來依需要讀取各戰役物件的狀態 4.避免 war.c 出現頻繁做資料寫入的情況 5.共通函數就寫 war_sample.c 讓各戰役腳本物件 inherit 架構大致是這樣，times_check.c 的利用我寫得算簡單，因此撰寫 可套用 times_check 的戰役系統應該不難。 腳本檔的部份，一般來說就是仿 quest 的架構，因為 quest 也是 屬於流程式的寫法，並設定有可否通過任務判斷、以及循環條件， 但是戰役系統要做的判斷較多，這部份是否適合全部腳本化，目前 仍有疑義，任務的部份因為需要較多判斷的流程較少(通常只有一兩 個流程需要)，所以是採讓 wiz 可自定義函數的做法，但戰役的話 就可能落得每一個流程都需要自定義一個函數來跑，這樣就失去腳 本化的意義。 這個我今天會思考出權宜的做法。 腳本檔編好後，會由 _war.c 指定轉成戰役腳本物件，物件會繼承 sample檔，因此很多函數都會寫在 sample 檔裡頭，我預期會有很 多的內定判斷用函數並可傳值過去，用這個來做腳本檔的簡化，應 該會蠻有效的，我預期這類函數會以 check_ 做為開頭。 最後，腳本物件的資料結構部份，主資料當然以 mapping 格式,雖 然說一個戰役理論上同一時間只能發動一次(直到結束)，但我還是 會預留同一時間(實際上會設定不能同一秒)被發動兩次的情況，而 以戰役標籤(就是 time() 值)當做主鍵值，其下再串被寫在腳本檔 的資料。 明天大致就依所編的這些東西來撰寫戰役系統相關檔案。我是希望 寫好後就能拿教庭戰爭來實驗，未來很多戰役的顯示格式會趨向固 定，但亦會保留給 wiz 自訂的空間。 戰役系統寫完後，下一個我預計寫的將是領地爭戰系統，我定義它 是國家系統的外掛系統，參與條件是被授予幾品官職以上，即可選 擇所屬國轄下的領地來治理，主要遊戲目的是與其它國家的領主打 仗。領地爭戰系統是很早就有的構想，但是卡在「副本系統」，必 須先完成副本系統才能實現戰場生成。 LAechan --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.223.250.36 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/mud_sanc/M.1486354250.A.04A.html ※ 編輯: laechan (61.223.250.36), 02/06/2017 13:57:51