AsAlma的物語 （上）
這是一個無名小玩家的故事，是一個被淘汰者的故事，是從來沒有被傳遞過的故事，是即便寫成傳記也沒有人會願意傾聽的故事。
もういちどすてきなおもいをつくりたい
そうおもったあるまたちへ
2020結語 | AsAlma的使命
開博客這種事，本來是我昨年想也沒想到的事情。 本著”既然沒事幹就寫點圍繞著ECO私服技術文章，順道如果能發跡同人活動就更好了”的構想，設立了AsAlma本站。當時高昂的興致在一個年頭後雖所剩無幾，我的堅持仍然沒有絲毫消退。 回顧我的首篇發文，其脈絡有跡可循: 博主相信社群要素是MMORPG的核心價值——大家一起玩遊戲渡過的時光回味無窮。及後，2020年中森友會的大熱正是體現了社群要素。後來行文一轉，提到近年私服相繼冒出，再而倒閉，暗示私服的不穩定是形成社群的跘腳石。 私服為何站不住腳? 各種因素交織其中。也許本來玩家基數就少得可憐，更不用提流失率了。作為很多私服的結末是，玩家群體失去了興趣，使投入了大量精神、時間的貢獻者感到沮喪，不願再開發、維護遊戲伺服器，可見當中存在惡性循環。 作為破局，博主認為促成可自行演化的社群是必要的。要營造讓玩家投入的環境，要使社群參與每一個環節，順理成章地成為了AsAlma的使命。降低參與的門檻，讓作為社群的搖籃再次歸屬於社群。博主希望玩家能透過探求並理解遊戲整體的運作，從而形成高凝聚力社群。 承接了夙願的AsAlma如一葉輕舟載浮載沉於名為網絡的大海裡，一去了就沒有回頭。誠然，那一天在2021年將不會到來。ECO生態或有如地衣——走千里路，駛萬年船，莫得一寸長；或有如白沙，傍晚的潮水洗刷早上的幹勁；或有如僻靜的小徑，不被行人所察。 乘著風可有誰發現向各位留下的一頁便箋，要如阿魯瑪一般樂於冒險，要如阿魯瑪一般擁有堅強的心，要如阿魯瑪一般結成羈絆。 8
皮露露與As-Alma
此前完結ECO封包篇後，整整半年沒有下文。回想當初，我籠統地以時序和角度劃分五節，卻因篇幅和解釋力所限導致內容過度跳脫。草草完結通信篇後，沒有打鐵趁熱、順水推舟帶出遊戲的主體。 從哪一個角度，要說明如何做一件事是困難的: 包裝經歷、描繪細節、切入話題、明確扼要等等。湧上頭腦就下筆的文章不是鬆散就是直接爛尾，畢竟不是每一個週末都有時間敲鍵盤，更遑論嘗試先做簡單記號然後後來再整合了，那個上下文老早就已不可還原了。久而久之，成了逃避的習慣，要煌了的節奏啊。 寫博客存在基本矛盾: 對象是不明確的。緣份來了，才會有人點進來。點進來的人，說不定愕了一會兒慨嘆這博主到底嗑了啥藥，默默地把目光移到右上角。當時有感而發的一篇文章漂流在互聯網的大海，在三天後成為一件佚事，三個月後迷途的陌路人誤打誤撞地點進來，三年後石沉大海，三十年後在洛陽鏟之下重見天日。 如果打從一開始把自己看成書寫對象，也許比較容易入手。可惜的是我也從沒有書寫日記的習慣。但比起亂寫一通，我更討厭書寫以別人瀏覽為目的的內容。 作為邊緣人的我多年來已經沒有使用社交媒體，我純粹沒興趣了解我沒有興趣了解的事。我研究我有興趣了解的事，所見聞的副產物就是As-Alma。不亦樂乎? 如其嘩眾取寵，倒不如為別人做點事: 例如把3組皮露露擺飾送出去。 願皮露露守護你的冒險。 2
ECO終止營運3週年紀念
不經不覺已經走過了三個年頭。敢問女兒可好? 我陷入沉默，拮据不下。沒有面目面對曾經一伙的大家。 但是，路還是得走。既然已經作出選擇了，不走下去是不行的。即使遍體鱗傷，也不能不多邁出一步。 今年一月，我破繭而出成立了As-Alma網誌。透過這一份得來不易的契機，舊地重遊，以前的我的身影彷彿迷蹤於代碼之中，不由得感慨萬分。當中有一鼓作氣而成的文章，也有不停跳票的文章，例如說好的免IE進入遊戲的下篇，卻姗姗來遲——有關壓縮的秘法的諸事情。 縱使緩慢，一步總比退縮要好，我是如此想著的。或者，要是我有一天也不在了，也不想有些東西埋沒在虛淵之中。經過多月的籌備，適逢ECO終止營運3週年之際(沒錯就是跟今年中秋適逢滿月同一道理)，釋出Maestro壓縮工具。 簡而明了，其作用相約於解凍君和再構築君。至於，Maestro當中的故事就更長了。兩年前，我一股勁頭，利用了ECODbWiki、解壓縮後的原文、eco.exe和靜態分析工具研究。這一股勁頭，直到算法完成為止，一來就是三個月，青春啊。直至今年，才為它準備了網頁圖形介面，使得它比以往的工具更容易使用。 那個夏文，那個青春，就讓它跟隨小蒼蘭的腳步乘著風飄散吧。 3
刻意練習湊談
在如何提升自身能力的文章中，十離八九圍繞「刻意練習」。是的，練習的確熟習自己不擅長的事的良藥。「刻意練習」是不是等同「刻苦練習」?要如何「刻意練習」才能有效率地提升自己的能力? 莫說練習的方法，就連練習的目標也不盡相同，最令人諷刺的是有些人所推祟的刻意練習居然是可以沒有確切的目標。刻意練習，龍蛇混雜。 依博主之見，要實踐「刻意練習」，先要拆解成「刻意」和「練習」兩部分。先說比較直白的「練習」，不就是Exercise嘛。無論是做運動的Exercise也好還是數學課本裡的Exercise也好，重覆地進行某些行為，就可以稱得上是練習。但是每天的工作我們都在重覆地進行某些行為啊不是嗎，「熟練度」上卻沒有實感。照道理如果對一件事情更為熟練了，那麼即使不能把事情做得更快，至少也比較少機會出錯。可是，事實往往就不是這樣的，錯誤總是出現在很靠北的位置上 —— 我不是指直白的編譯錯誤，那些錯誤根本不值一提。這把我們引導到光有「練習」是不足夠的結論，其關鍵在於「刻意」。 之所謂「刻意」，是指「有意識地」。為何要強調「有意識」呢? 是這樣的，工作上也好，娛樂上也好，人總是有一定的「慣性」。處於慣性的思考無法令個人有所得著。「有意識」在這個層面指「非慣性」也。接觸從未接觸過的事物是人容易脫離慣性的時候，「刻意」一詞也因此同時引申為「使其脫離慣性」的意思。到了這裡，許多文章順水推舟，把「刻意練習」塑造成「去玩笨豬跳」的意思。這也正是今天湊淡的批評對象。 透過跳脫舒適圈而重奪意識不失為上策，唯強制自己去脫離慣性博主則不敢苟同。不是每個人都能玩笨豬跳，也不是每個人有足夠的資格挑戰分布式系統。話說，你要是讓畏高的死宅博主去玩笨豬跳，你良心是不是掉了。再者玩笨豬跳到底是能練習三小。我不是MT吧。笨豬跳搞完了，我意識都掉了一大半了吧，「練習」到底是有甚麼意義呢…. 讓後端的人摸索前端 —— 是的，要是能這樣「刻意練習」，那麼全端就誕生了(同薪酬2倍工作量GET)。然而，失去目標的「刻意練習」，如車子沒有目的地，光有一時的燃料是不行的。我也知道根本很難有「刻意練習」的契機和動力，特別是各位下班後已經不是一個完整的人。「刻意練習」成為空談。 再退一步，未必每一種「練習」都能獲得熟練度。甚至，「練習」不代表你能更快，特別是總會聽到朋友說他們不小心deploy到生產環境去了。雖然真要是這樣，老實說，仍是很比較容易補救的: 幾分鐘，或者半小時，總是能回滾。以前在實驗室的時候如果弄錯了一點東西，可能一週也不能補救呢。 回首，「刻意練習」之所以成為空談，是前設了透過強制自己去脫離慣性作為達成條件之故。脫離慣性並非只有一途，依博主所見，甚至有很簡單可行的辦法稍為離脫離慣性，讓付出的時間得到最低限度的積累。我們做甚麼行為會「有意識」呢? 或者，更為抽象地說，有甚麼行為我們可以灌注意識，就如把魔力灌注在手中的魔法棒一樣。嗯，是語言。魔法之所以要詠唱，是依賴了詠唱來輔助集中想像的能力。同樣地，明明法杖可以指定任意一處但是仍然使用揮動法杖來瞄準的行為，是肢體語言。「刻意練習」的魔法，就是語言 + 肢體語言。 可惜三次元世界沒有魔法能夠詠唱 —— 嗯等等，同樣中二的行為三次元的確是存在的…...
動物森友會與伊希歐之夢
喺呢個咩都冇既無人島上，親手製作道具，作用製作既道具去跳過河川，攀上懸崖，發掘化石，充滿發現同驚喜既每一日，響呢個島上渡過。因為咩都冇，所以咩都做得到。 《集合啦！ 動物森友會》香港CM(由零開始製作篇) 近年，電子競技成為消閑娛樂，手機遊戲的速食文化大舉蠶食社交平台。在這情勢下，動物森友會還是成功炒起熱度，大家紛紛創造屬於自己的小島。 動物森友會好玩嗎? 我沒有Switch，我雲玩家。 它看起來真的令人很想玩。這會不會是因為動森是難得的佳作呢? 動森確實賣座，卻不一定是一款佳作。我想，不賣座的遊戲，更不可能被評為一款佳作。 但是它看起來真的令人很想玩。提一個反論，試想想只剩你一個玩這個動森，那麼這個遊戲突然就好像不怎好玩了。雖然這情況好像不會發生，事實上只要斷開網際網絡自己一個人玩就可以了，你可以試試。記住，不能再將遊戲紀錄上傳到社交平台上，也不能從網路上獲取有關遊戲的一切情報，更不能在現實世界裡與他人談及這個遊戲，就假設遊戲是Brain Burst 2039就好了。 加速世界的設定中存在幾個相同的遊戲，分別是Accel Assault 2038和Cosmos Corrupt 2040，但皆已關服。在Accel Assault中，玩家就像玩LOL搶路一樣掀起過激的爭鬥﹔在Cosmos Corrupt中，玩家似乎失去了動力，無所事事﹔Accel Assault好玩嗎? Cosmos Corrupt好玩嗎? 設定上，這三款遊戲的系統同源，可能只存在設定上的差異。假若Brain Burst 2039是一款佳作，那麼Accel Assault和Cosmos Corrupt不可能不是佳作，然而它們卻落得潦倒的下場。 Brain Burst...
概說棧在遊戲的應用(上)
棧(Stack)是一種後進先出(LIFO)的數據結構。升降機的比喻最為直白，亦最難忘，但持著升降機概念的人卻往往不能把棧用得好 — 我說的就是我。 不得不說，棧的印象很容易受限於算法。經典例子是深度優先樹探索(DFS)。 開首就將根節點壓棧，然後 “出棧、比較、將子節點壓棧”這個操作一直重覆下去。 升降機的比喻在此行不通。當然，可以說成: “升降機從頂樓接載一個人出發，下降一層後，一個人出去了，幾個人進來了。升降機再下一屠，剛才進來的幾個人當中最接近門口的一個人出去了，這次沒有人進來…”。升降機的比喻缺少了最重要的部分，就是任務。 棧比較少用，隊列(queue)卻經常地用到。隊列就是一道生產線，每當從生產線拿出，就會進行加工消化掉。同樣，出棧後會進行某種任務(task)。深度優先之所以需要用棧正是因為進行任務的過程中會產生子任務(sub-task)，而子任務比現有任務更為優先。 廣度優先(BFS)亦會產生子任務，不過搜索現在所在層數更重要，於是使用的是隊列。不難看出，使用棧的關鍵在於”單一任務的完成取決於子任務的完成”。 把握優先子任務的概念後，是時候把棧的應用到遊戲中。 回合制卡牌遊戲 另外cards棄牌區本身是一個stack，玩家的行動受最頂的牌影響。當可以出牌，就把牌置於棄牌區頂部。沒法出牌時，視乎是不是被罰牌，要一直找到罰完為止，此處使用了另一個棧，負責做罰牌，罰完就把牌放回去，類近於很經典的雙棧動作還原應用。 每次從牌頂拿一張牌到手上，再檢查手上的牌是不是Draw Two。如果是DrawTwo就摸2張牌，一直直到手上的牌不再是Draw Two，此時把DrawTwo逐張放回去。 不論是隊列還是棧，這兩個數據結構和其他數據結構最大的不同之處是它們不是儲存和尋找的工具，是以內容物到程序跑完會完全出來為前提。不論是壓入棧頂的東西，還是被壓在下面的沉積物，基本上最後都會跑出來。(在雙棧動作還原中，按一下還原後做別的動作，會直接扔掉儲存了被還原動作的整個棧) 玩家出牌代碼如下: 細心的人應該已經發現了”當玩家n-1被罰DrawTwo後，玩家n沒有能出的牌，會重複被罰DrawTwo”的bug… 為了使牌堆能隨時重洗(特別是多人的情況很多時候會不夠牌摸)，不太建議把”空牌”放在棄牌堆裡。反而，會推薦儲存上一名玩家的動作來判定是不是被罰DrawTwo。另外，也不建議把萬能變色卡被指定的顏色儲存在卡上面，我更偏向儲存下一家”出牌的條件”。由於篇幅主要表達棧，這裡跳過實作，自己腦補吧。...
Fizzbuzz湊談
由於找不到方向繼續寫SagaECO 深入淺出系列，先行隨筆。在Google沒有收錄的網站刷SEO是不是搞錯了甚麼 相信大家有聽過傳說中的Fizzbuzz問題，全地表最因難的問題。上一篇”整潔代碼湊談“的文末有提到不應在Fizzbuzz問題紏纏clean code，在此解畫。 The “Fizz-Buzz test” is an interview question designed to help filter out the 99.5% of programming...
整潔代碼湊談
湊談系列第二期…才不會告訴你湊談系列是用來刷SEO吸引潛在的ECO私服的白武士的哼 很多人知道代碼要寫得整潔，很多人知道有Clean Code這本書…我不記得我有沒有看過這本書了，好像有，好像沒有，好像直到專程談一次整潔 代碼之道的一刻介於有和沒有之間… 好吧，你可以當我沒有。 篇幅有限。首先這本書的側重點不在於爭論花括號到底要不要開新行、用tab還是用space、縮進2格抑或是4格，老實說我很久以前真的以為是關於編排的。(如果 編排 = 整潔代碼，生活真是容易多了~)GO語言自帶了編排器(formatter)，然而編排好的代碼不代表它整潔(clena)。用上了再嶄新的工具，再尖端的框架，還是需要駕駛員(派駱駝)的。編排器充其量只是提醒的作用，一行是不是太長了? 括號是不是開太多了? 簡而明了的是，給所有東西起名，三思而後行。Think beyond twice for naming everything. 變量、函數、類別，統統要起名。如果起名實在起得太辛苦，那麼一定有東西是不妥當的，要打醒十二分精神重新檢視，十有九都是抽象(abstraction)問題。名字不一定要短，嘗試使用縮寫只是逃避問題的一種手段，反而長的名字不一定壞。最後檢查一下拼字有沒有錯誤(還真有看過中國大陸人連github repo名字本身已經拼錯了XD)。印象中SagaECO的DB有一個名字就是串錯了，那要改回來是往往更費神的breaking change。 我的看法是註釋不一定要有，前提是有單元測試(unit...
深入淺出SagaECO RPC篇(五) “揚帆啟程”
以下討論基於SagaECO svn ~400版本 源代碼可以從這裡下載 RPC篇終於來到第五篇… 上回提要是每當與伺服器連接時首要的鑰匙交換事項，換言之通信確立後馬上開始通信(傳送門)。 這次介紹登入的詳細步驟，手把手完成最基礎的登入ECO的過程。跟上一章同樣，登入的步驟是由癌炮指定的，跟SagaECO沒有關聯咯。 仔細看很多重覆的流程，無非是檢查版本->登入->做其他事的模式。這裡使用了SagaECO的命名方式。Gate Server的角色很簡單，就是用來做用戶認證，引導到用戶選擇遊戲伺服器的列表裡(C, L ,F , Z服)。 好像盤古開初的時候沒有這個Gate Server。從server.lst可以看出，本來就是讓玩家自己選遊戲伺服器。server.lst中加一行就能在登入畫面選伺服器。可能是後來意識到server.lst裡直接寫IP，容易被DDOS，於是把第一重登入交給Gate Server去做; 或者是Login Server負載大而需要多幾台伺服器，擔當負載平衡(分流)作用。後者推測比較合理，因為這種沒有代理作用的負載平衡器不見得能避免直接去DDOS後面的伺服器。 當伺服器列表交出去之後 Gate...
八二定律湊談
不知道為甚麼，軟件界常常提及八二定律例如是優化工作，卻往往不知所云。 八二定律的全句是: 約20%的變數控制了80%的結果 80/20的法則認為：原因和結果、投入和產出、努力和報酬之間本來存在著無法解釋的不平衡 出處 或曰: 二八定律又名80/20定律、帕累托法則（Pareto‘s principle）也叫巴萊特定律、朱倫法則（Juran’s Principle）、關鍵少數法則（Vital Few Rule）、不重要多數法則（Trivial Many Rule）最省力的法則、不平衡原則等，被廣泛應用於社會學及企業管理學等。 百度百科 不管叫怎樣的名字都好，共通點皆表達出少數比多數重要，甚至被包裝是”最省力法則”。 現在開始破題，掀開八二定律的葫蘆裡賣甚麼藥。 八二定律的抽象點在於原因和結果皆沒有定義好，所以是一個萬能KEY，甚或是只要分布看起來像八二開，那就運用八二定律orz 比如說人類80%時間都在睡覺和吃飯，剩20%時間有用，那你是不是不睡覺了~ 這裡給出一個例子: 扔飛鏢。我也不懂扔飛鏢，假設正中間是50分，外面綠色圈是30分，內圈都10分，外圈5分，扔不中板子當然是0分，最高分的勝出。...
異常狀態特效表
嚴禁轉載Republishing is strictly prohibited転載はご遠慮ください 異常狀態生效時的特效一覽如無意外是首發
深入淺出SagaECO RPC篇(四) “不滅之握”
以下討論基於SagaECO svn 900版本源代碼可以從這裡下載 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 這篇主要覆蓋SagaECO中的NetIO和Encryption類，比較沉悶，是失眠的良藥。 已經去掉無關代碼，但是還是太長了。要表達的其實是客戶端和伺服器確認連線的流程: 客戶端發送長度為8的封包 伺服器啟動鑰匙交換 ，準備私鑰 ，向客戶端發送含有公鑰、長度為529的封包 客戶端收到伺服器的公鑰，準備私鑰，製作共享鑰匙，並向伺服器發送含有 公鑰、長度為260的封包 伺服器收到客戶端的公鑰製作共享鑰匙 連接成立 想當年我自行斷斷續續去湊關鍵字花了幾個月最後才得出是DH交換書本和大神的文章是可以省掉以年為單位的時間可謂不誇張…每每醍醐灌頂每天生活在他們的陰影中實在不要太幸福 具體可以自行參照wiki對應交換所需要的資料。(謎之聲: 再說一次! Ecore是日本的網站非指ECO-Re私服) DH鑰匙交換的計算...
深入淺出SagaECO RPC篇(三) “解耦封包”
以下討論基於SagaECO svn 900版本源代碼可以從這裡下載(約svn 400版本) 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 上文我們已經處理好輸出數據的格式和流程了，我們還有接收封包(Packet)的部分未解說呢。時間關係，讓我們一次過掀開完整的流程。 上一篇說的從Packet類的虛擬方法三巨頭 public virtual bool SizeIsOk 近乎沒有用到、忽略 public virtual Packet New() public virtual void...
深入淺出SagaECO RPC篇(二) “封包結構”
以下討論基於SagaECO svn 900版本源代碼可以從這裡下載 注意: 被分發SagaECO源代碼並不代表你被授權使用、修改、發布衍生的程式換言之SagaECO團隊仍然保留一切權利(雖然SagaECO團隊早就消失了… 這篇主要討論繼承自Packet類的各個封包遊戲客戶端和伺服器透過不同封包來傳遞不同的信息，有玩家出現的通知，有組隊邀請的請求，有聊天信息通知…是聯繫世界中的一切的基礎。SagaECO這個ECO私服也不是例外。 這次我們從伺服器通知某人作出了坐下動作的封包入手。 每一個封包有對應的ID，這時要找的ID是121C。 除了ECore之外，se-a Packet Struct Tools也能查看封包結構。*站主曾經封鎖日本以外的IP，必要時請使用VPN。 可見兩者的記載並不吻合，在這時候建議使用Se-a的結構，它上面的資料是最新的。如果沒有理解錯誤的話，se-a的網站是從2017年起由大家分享封包紀錄。對於121C封包，舊的封包結構不兼容於新客戶端，新客戶端試圖讀取新增的第二個DWORD時舊封包就不夠長了。更常見的不兼容狀況有類型變更，例如金錢從DWORD延長為QWORD，也會導致上述的舊封包不夠長而失效。比較另類的變更涉及OpCode的變更。 兩個工具各有優缺點，整理成如下:Ecore優點– 對於資料的注釋較多、齊全、而且有提供相關連封包和流程– 是除了代碼之外唯一有覆蓋網絡層資料的文獻缺點– 資料比較舊 部分資料不適用於新版客戶端 新系統例如AAA之類 很可能會沒有相關資料–...