搜尋

搜尋結果

2026看Steam Machine | Steam OS 是不是一個出路?
科技新知
MacauYeah・2026-02-20

在這幾年,筆者都一直分享一些coding anywhere的主題。原本的出發點,其實是因為雲資源及container的出現,是不是讓個人電腦的採購可以越來越不受限?是不是相對選擇會更多,亦應該可以更便宜的選擇? 適逢SteamDeck Linux興起,使用Steam OS道理上會比windows更適配雲資源的開發,而且SteamDeck 可以同步作為手提遊戲機,買台低配的SteamDeck回來,可謂一石多鳥。筆者用著用著,也來了兩年多。現在再來聊它,主要因為Valve未來又有新的硬件Steam Machine推出。這台新硬件,道理上也是跟Steam OS,官方亦宣傳它可以作為PC用。但就這一賣點,筆者很想分享一下它的Steam Deck的使用心得,供各位參考Steam Machine的軟功能是否適合。 https://store.steampowered.com/sale/steammachine 首先,作為遊戲方面,Steam Deck是手提遊戲,硬件比較弱,不能與同世代的PS5或Xbox Series X或PC去對比。我們不應該拿畫面和效能跟其他平台比。但它的OS 層功能,就很直接看得出它有沒有價值。 遊戲模式-Gaming mode 有即時待機功能,但不是所有遊戲都百分百適配。Steam OS的待機,來回玩,再待機,玩過兩三天,總會crash一次。相對之下,Switch就做得很好,就算玩一週也沒問題。Steam OS 也不能說很差,因為PS5等沒有真試過來回待機玩個一週。這裏要表達的,就是遊戲未必為Steam OS而做優化,開發商的目標還是傳統的PC遊戲模式,傳統PC Notebook也有待命,但又有多少遊戲會認真對待?所以Steam OS可以待個兩天,就已經很好 手柄連接算是順利,一般大版的手柄,都可以簡單連接。但它也有做得不好的地方。每次待機換地點,基本上都涉及切換手柄問題。即使內置就有只一個實體手柄,系統並不會自動為你更換第一順位。例如,我原本使用PS5 無線手柄,在家遊玩,這時PS5手柄是第一順位,實體手柄是第二順位。很多遊戲只認第一順位是很正常的。不過在我待機,切換環境,原本的PS5手柄已不存在,但SteamOS並不會把實體手柄順移到第一順位,必需要手動調節。好在,也不需要退遊戲就可以切換。這個對比PC來講,SteamOS已經是做出了改進,但對於Switch和PS4/5,這些根本就是待機一啟動時就要為用戶的問題。可能這是因為SteamOS要考慮Desktop Mode的原因吧,不過筆者就沒有試過在Desktop Mode開遊戲,因為突然要待機外出會更麻煩。 桌面模式-Desktop Mode 這個模式,筆者就專注在取待PC的日常操作上 中日韓輸入法問題,這是大大地阻礙大家入這坑的很重要原因。如果大家都是純英文人,就不需要顧慮這一塊。但筆者就不是一個英文很強的人,多多少少需要直接打中文去找問題。原本SteamOS在Gaming Mode下可以通過 Steam Key + X,叫出虛擬鍵盤,安裝中文倉頡是很易的事。原本這一功能,在Desktop Mode也是可以的。但在寫稿的今天,Gaming Mode / Desktop Mode的中文虛擬鍵盤都一起報廢了,原因未明。筆者只好走回最早期為大家介絡的 flatpak fcitx5+RIME大法。fcitx5可以用,但限制也多。之後筆者再寫一期教學,解決它的限制問題。 辦公室套件。最基本就LibreOffice, OnlyOffice,大家可以在Desktop Mode中的Discovery裏找到。大家想知自己常用的套件是否有對應的版本,可以在https://flathub.org/en 裏找找看。有的話基本可以放心一半,至少經Discovery下載的app,都可以經fcitx5+RIME輸入中文。但這並不代表你可以真的當自己在辦公室工作,那些printer / scanner ,筆者實在沒有太多想法。道理上今年今日普通列印功能,應該通過指定driver就可以做到,但無耐真的不太簡單。日後筆者了解好制式問題後,再來填這個坑。 瀏覽器-就用Firefox吧。 其他瀏覽器有是有的,但最好只用Firefox。Discovery是有筆者最常用的google chrome瀏覽器,但在網安原因下,筆者不敢推薦。Flathub上 Firefox是官方認證的程式,但Google Chrome和Chromium也是沒有認證。如果想使用管方認證的Google Chrome,頂多只能在Distrobox下自行安裝。同樣,如果你是IT人也是英文人,Distrobox再安裝chrome,應該很簡單。但如果你像筆者一樣,還是依賴中文輸入法,你就會很失望,Distrobox經X-server出來的程式,沒法使用前文所講的fcitx5。所以簡單一點的選擇,就是直接使用Firefox。 寫Code,那就得在Distrobox上弄了 Flathub上是有非管方的VSCode,但同樣問題,這個版本你敢用嗎?同樣地,在Distrobox 下安裝 VSCode,是取得官方版本的好方式。只要大家不強求在vscode中輸入中文就可以了(貼上中文是可以的)。使用Dsitrobox做開發類的IT工作,在Contianer範圍內,都算可行的,在Container內安裝java,總比在SteamOS上簡易。但如果你需做一些低層的開發,還是在VM下操作吧。 總結: 如果你很想一石多鳥,你能接受新事物,Steam OS可以一試。 如果你有一些深度的操作或要求,即是是遊戲層面還是工作層面,現時Steam OS都不是一個很好的選擇,除非你的Steam OS不更新,把它硬改回ArchLinux,但這就失去了Gaming Mode的意義。

雲系統的持續更新,大家的選擇是什麼?
科技新知
MacauYeah・2026-01-30

在開始之前,筆者先解釋一下自己對Linux發佈策略的理解。筆者之前以為自己都尚算了解,但到了兩難問題時,才開始反思。所以都不禁懷疑自己的基本觀念有沒有問題,如果大家覺得筆者多少有些理解上的錯誤,請留言糾正。 普通軟件的發佈 主要分為穩定(Stable / GA), 測試(Edge / Alpha / Beta),特定版本。穩定、測試版本也可能有多個不同的分支,但它們主要是指不同環境下的選擇。通常安裝時,都會安裝最後的穩定、測試,除非最後版本有明顯Bug,我們需要回覆到再去的一個穩定版本。 當我們每次都更新到最後的穩定版本,我們稱之為rolling release. 以docker 官方建議的方式,我們在ubuntu底下,可以看到它的有很多結果回傳。 apt list --all-versions docker-ce Listing... Done docker-ce/noble,now 5:29.1.4-1~ubuntu.24.04~noble amd64 [installed] docker-ce/noble 5:29.1.3-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.1.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.4-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.3-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:29.0.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.2-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.1-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.5.0-1~ubuntu.24.04~noble amd64 docker-ce/noble 5:28.4.0-1~ubuntu.24.04~noble amd64 ... 我們可以選擇過去某個版本,但通常無腦update,就會去到最後一個版本。 Ubuntu的發佈策略 我們換個package看看,如果只看重要軟件的話,例如kernel,我們沒有什麼可以選擇 apt list --all-versions linux-image-generic Listing... Done linux-image-generic/noble-updates,noble-security,now 6.8.0-90.91 amd64 [installed] linux-image-generic/noble 6.8.0-31.31 amd64 apt list --all-versions linux-image-virtual Listing... Done linux-image-virtual/noble-updates,noble-security,now 6.8.0-90.91 amd64 [installed,automatic] linux-image-virtual/noble 6.8.0-31.31 amd64 除了可選擇數量外,另一個最大的不同是,kernel的自身版本其實固定在 6.8.0,就算更新,都是同一個版本的ubuntu補丁版,並不是官方kernel的bug fix版。筆者認為,這應該就是所謂的point release的策略。 (如果大家安裝物理機的話,kernel可能會是6.14,筆者大部份都是VM,還是比較舊的版本。筆者保證,6.8.0-90.91與 6.8.0-31.31之間,曾經是有多個不同版本的。但現在沒法下載回來,除非之前大家有安裝過。) 但相同情況,我們找另一個package看看,由 ubuntu 自己打包的docker 版本,雖然可以選擇的數量是有限的,但它們的版本是不斷更新的,而且不是hotfix版,還有大版本更新。 apt list --all-versions docker.io Listing... Done docker.io/noble-updates,now 28.2.2-0ubuntu1~24.04.1 amd64 [installed] docker.io/noble-security 27.5.1-0ubuntu3~24.04.2 amd64 docker.io/noble 24.0.7-0ubuntu4 amd64 雖然版本是跟著官方docker最新版本,但也有持續跳級更新。如果真的要分類,筆者應該會把它歸類為 rolling release。 Rolling release vs Point release 花了一些時間看例子之後,終於開始討論我們自己的更新策略了。rolling release,最主要的原因是,舊版本無人再免費維護了,有什麼bug,都在最新版本中修復,但也因此有機會出現不相容的情況。point release,最主要的原因是為了維持極強的穩定和兼容版本,這亦代表,除官方專家出手,否則很難有舊版本的bug fix。 那麼我們有什麼選擇? 有point release,當然跟point release,因為程式不可能天天做調整。除非大家想要新功能再升級版本。 沒有point release,就手動自己選擇hotfix版或小版本升級。在升級大版本前,一定要做整合測試。若追求極致的穩定,升級大版本時就不要原機升級,要另起爐灶,似兩個相對獨立的環境並行過渡。如果有container版本,就用container隔離,一般java等都可以這樣建獨立環境。 沒有point release,也沒有可隔離的並行環境:其實 docker 接近這類。對它應的OS層的存取,雖然可以用VM隔離,但通常都不實際。因為重新安裝OS, 設定外部環境,成本很高。docker 在中 lab 並行升級是可以,但投産環境並行真的不實際。沒有辦法之下,筆者還是原機升級。頂多是lab中實現更多的整合測試。

你開始寫 Spring Boot 測試案例了嗎?
科技新知
MacauYeah・2025-11-29

雖然筆者過往做 spring boot framework 教學中,都有滲入一些測試用例。筆者也曾經困惑了很長一段時間,所以就獨立開一個主題,聊一下筆者在實務上對spring boot test 的理解。 測試案例究竟測試什麼? 測試用例 (test case) 是確保你的程式碼正確性與穩定性的重要步驟,但在 framework 下,並不是所有功能都很容易寫成測試。所以在討論 framework 測試之前,釐清測試的本質。 function input - business logic - function output 這意味著我們輸入某些資料(input),然後經過業務邏輯(business logic)的處理,最後產生結果輸出(output)。 我們的測試目標,其實就是確保業務邏輯正確。而我們的手段就是經檢查概定的輸入資料,核對輸出結果。 那麼只要我們可以生成輸入資料,就一定可以檢查輸出結果了吧?其實不是的,因為實務上的輸入和輸出沒有這麼簡單。筆者常接觸到的輸入輸出如下 輸入 function 輸入參數 系統狀態資料,例如:資料庫狀態、外部API結果。 輸出 function 輸出參數 寫入系統(影響到)的資料,例如:資料庫狀態、使用外部API時的輸入參數。 總之就是考慮了狀態機 (state machine) 的問題,每個狀態+外部輸入都是一個測試用例,然後核對狀態機去了下一個什麼狀態。 言下之意,我們就是暴力地生成輸入參數和模擬狀態資料,道理上就是可以進行測試。 Spring boot web framework 中,我們又會測試什麼? function input - business logic - function output在Spring boot web就變成如下 controller request - business logic - controller response在 Spring Boot test 中,我們可以用模擬的 MVC (MockMvc) 測試來驗證 controller 的行為。不過,其實進入 controller 前經過很多系統轉換,而這些道理上跟Framework的技術大相關,與業務邏輯小相關。所以為免折磨自己,可以將業務邏輯單獨封裝成服務(service)。之後直接測試服務 ,易寫也易讀。 controller request - service input - business logic - service output - controller response道理上 controller 能做的業務邏輯,服務 (service) 都可以無腦重現。這樣還可以重用服務,減少測試的數量。 如何實現輸入? 直接 new Object。大部份的情況下,因為業務是自己編寫的,應該都可以直接 new 出來。 經 json 檔讀入。如果輸入的參數量太多,逐個經 java new 是很耗時的,我們可以經 json 反序列化變成 Object。但這亦只限於自己可以操作/改寫的類。 Mockito 模擬那些無法簡易經 new 或 json 反序列化的 Object。例如:spring security authentication object 我們在使用時,其實只看到 interface。我們難似自己實現一個可以反序列化的類,那麼我們可以使用 Mockito 來模擬這些資料。一些外部API的結果,我們也可以用使 Mockito 來模擬。 什麼情況下不進行測試? 有些情況下,我們可能選擇不對某些功能進行測試,原因可能包括對功能的了解不足或是單純的懶惰。以下是一些例子: 僅進行配置的Function:如果你的 Function 只是在 Framework 中填寫配置,而且你並不太了解它的運作原理,可能就不需要進行測試了。例如,Spring boot web 中,需要大家配置一個SecurityFilterChain Object,它要求大家將 HttpSecurity 轉換為 SecurityFilterChain 。因為輸入的 HttpSecurity 是系統固定的參數,我們亦沒有檢查它的狀態。這種情況下,它的輸入及輸出,其實我們都沒有真正理解。我們硬測試的話,測試功能可能只流於表面。若我們真的要做測試,也是經過MockMvc進行端到端測試(end-to-end testing),測試它在事後的影響範圍。 單純的框架功能:例如資料庫的儲存庫介面(repository interface),雖然是在框架下生成的,對於自己手動調整的部份功能,筆者通常亦不會進行單獨測試,通常都會搭配業務邏輯一起進行。它可以使用 Mockito 進行模擬測試,或用測試環境的真實資料庫進行測試。 面對的挑戰 總括來講,筆者盡可能地把測試用例限定在業務邏輯中,就可以大大地降低寫測試的技術難度。但筆者還是有些問題並未完美解決。 測試用例的數量可能很多,因此共用與維護變得相當困難。逐個用例獨立編寫輸入也是很累的。對於 Mockito 的使用,筆者還是可免則免。因為要逐個功能模擬,編寫量就指數提高,這亦難似配合外部變化。一般來說,能優先使用測試環境或者 Docker 來模擬環境的,就盡量用。 離線開發、離線測試。系統依懶的外部功能越多,想做單機開發的難度就越高。即使前述有 Docker 測試,對於持續整合(CI)來講也是有一定難度。那麼這時,Mockito 就是一個可取的選擇。但這又回到編寫量及難以偵測外部變化問題。 希望這篇文章能幫助你更好地理解測試案例的編寫方向,並在Spring boot web開發中加入你自己的測試!

Coding Anywhere: 依賴服務的選擇
科技新知
MacauYeah・2025-04-22

年多前,筆者購入steamdeck, 經過一輪軟件定制,把它變成一個可以作為IT從業員開發機的方案,也介紹了一些coding anywhere的想法 https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/14175/Coding Anywhere 工作方案 https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/14352/Steam OS 3.5更新,內建 podman, distrobox https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/14149/開發者在Steamdeck上的另一個選擇: Gnome box 在試驗了一年多後,筆者對於依賴服務的模疑,又有另一層感受。什麼是依賴服務?就像你寫的程式庫,可能需要資料庫儲存、可能需要問AI等等。所以在開發時,都要確保這些服務的存在。一般,要麼就是在本機上自行安裝,要麼就是經過互聯網使用雲服務(public cloud或者你團隊提供的private cloud),也就是本地模擬還是互聯網模擬。 本地模擬的得失 本地模擬,主要是考慮金錢上的優勢與資源的獨立性。 金錢成本 - 互聯網資源大部份都不會是免費的,如果本機的硬件足夠,可以在本地完全模疑,有一定上的優勢。但如果該服務在本地安裝,都要計授權,可能不沒有太大差異,例如那些report engine, report designer,即使本地開發都要逐台開發機計算。但其他大部份,如資源庫的實現,都有本地開發免費授權。所以本地安裝道理上有一定的成本優勢。 資源獨立性 - 當一個團隊共用一些互聯網服務時,可能會互相干援。即使團隊在開發時,可以經profile使用不同的資源,但發生誤用的情況還是很常見。(除非大家已經有一套很健全的開發用profile,只在本機生效,亦只在必要時才會被提升到程式碼的版本控制當中,不會誤會地覆蓋他人,也不會忘了提交。但這是很有挑戰的一件事)。反觀本地模擬,因為那些服務並不會在團隊中分享,就保證不會被誤用。 學習成本高 - 本地模擬,就有一個莫大的痛點,就是學習成本高。我們可以找到很多本也安裝資料庫的教學,本地LLM AI的架設也不少。但我們並不是很輕易地就可以無師自通,有時為了初次安裝,所花的時間成本也大得令人卻步。 coding anywhere轉移成本高 - 因為全部本地模疑,代表我們必需要有一台足夠強大的主機。但如果我們的移動接入點,綁定了在某台特定的強大主機,我們活動空間也相對減少。 互聯網模擬的得失 直接使用互聯網的服務,主要體現於用錢解決問題的優勢 即開即用 - 能用現成的就用現成的。例如你目標是使用mysql cloud database,就直接伸請使用。如果你還要在本地安裝或使用Cloud VM安裝,就還要自行安裝管理介面等工具。因為成本問題,實在要自行安裝,使用cloud vm也有一定的方便性。使用cloud vm 有一定的快取,可以減少安裝所需要的時間。當我們養成自動化的習慣,clould VM 也可以隨時刪掉,有需要才重起。 解決單機無法模擬的情況 - 某性依賴,並不能簡單地經過本地單一部主機去做到。例如我們要模擬一些叢集功能。我們可能要在主機或網絡設備作出一定的調整,才可能提供bridge network。這一點在辦公室網絡下限制更多,不是隨便就可以建一個可以互通,又可以訪問互聯網的環境。另一些如block storage等資源,還會對硬件有一定的要求,也不是軟件模擬就可以做到。我們若不經過互聯網取得,至少也要在團隊下的private cloud上去建立。(不過如果是從零自建private cloud環境,初次投入的成本可能直接使用public cloud 低。 ) coding anywhere轉移成進一步下降 - 作為移動接入點,就剩下那些不可互聯網化的部份,例如domain name,有時還是localhost比較方便,又例如有一些硬件相關開發,硬件部份必需經過本地接入。 就以筆者的個人經驗來講,除非public cloud的價錢實在不可接受又或是自動化幾乎不可能,否則使用public cloud會有時間成本上的絕對優勢。如果要走本機模擬方向,必需要對Container、VM、網絡等有深刻的了解,才會成事。

Docker 中的非管理員用户 Docker non-root user
科技新知
MacauYeah・2025-03-14

Container USER為何重要 在制作Docker Image的過程中,有時會接觸到 USER 這個設定。這事關到最後的 Docker Container內部運行的那個 user 到底會有什麼權限。大家也要知道,Docker Container 其實也只是一個 Linux 上的程序,也就是如果Container內權限過大,也有機會從 Container 內部存取到 Host上的資料。 一般情況下,Docker Image 預設的 USER 就是 root,最基礎的base image都是一樣。而我們想換,其實也相當簡單,就像Linux上起User一樣,只要經指令RUN adduser xxx 或RUN useradd xxx 也可以在 Docker Image 中創建帳號和 home 資料夾,之後就隨時經USER xxx來切換 實際上是不是這麼簡單? 如果你將要Container中執行的程序,是一個binary,平常你在Linux中也是以 non-root 方式執行,那麼是的,就是那麼簡單。例如你執行系統中的java, node, python,原本在Linux中就已經是誰都可以,那麼你的docker container 也應該沒有難度。 但如果原本的安裝包,預設是由system service來啟動,我們就要花點力氣,看看那個service是怎樣呼叫binary的,然後就一步一步模擬它的做法。例如筆者有打包的codeserver,預設是system service啟動,但它也有提共binary的執行方法,安定好home資料夾後,我們也可以手動啟動。 泛生之檔案權限問題 上述binary的情境之所以簡單,是因為大部份情況下,我們都只對於container 內部運行考慮即可,因為預設投產情況下的運作模式,都是隨時起、隨時刪、隨時砍掉重練,只要container內部運作可以自給自足,就可以了。Docker Swarm的運作也是如此,所以它不預期有的持久化資料權限的問題。 而持久化資料權限的問題,其實早在單個Linux伺服器就已經存在。同一個伺服器中,不同process就有不同的UID,當他們需要共同讀/寫某些檔案,就會設定多人權限。同理,當多個Container要共同檔案,也是同樣問題。在討論共享檔案之前,我們先看看預設 Docker Storage Mount 會給我們什麼權限。 如果是bind mount,bind mount的權限預設會是Host內的檔案或者資料夾的權限。 如果Host是root,container內是non-root,container有機會無法讀寫bind mount內的檔案。 留意權限設置就可以解決問題 如果Host是non-root,但container 內是root,從container內生成的檔案,Host的non-root user就無法使用。 Host是non-root的話就一定無解,Host至少有sudo權限,臨時變成管理員,去修正問題。 如果host和container也是non-root,但UID不夾,其實也不能交換使用。 跟上述一樣,最後要靠sudo來解決問題。 如果host和container也是root,就沒有權限問題,但就有安全性的風險。 如果是volume mount,就還是看看 mount path 是docker image layer中現有的 path還是新起的path 大部份手動建立的named volume都是root 經docker compose起的named volume滿足以下條件的話,將會是non-root。 docker image 中的已有該path存在。 named volume未存在,docker compose會把對應path的內容在初次建立時抄到named volume 中。 例如ubuntu:24.04中的/home/ubuntu,存在於docker image中,它的擁有者就是UID 1000,我們經docker compose HOME_VOLUME:/home/ubuntu,在HOME_VOLUME建立時,就會是UID 1000。但如果是 NOT_EXISTS:/home/ubuntu/somethingNotExists,那麼NOT_EXISTS建立時,也會是root 上述討論的Storage mount是集中在單機情況下,使用HOST OS的本地儲存。若現在的場境是多機共享的share storage,就會更麻煩,還要看看那個share storage本身的屬性。例如常見的Linux NFS,其實有指定的權限,跟NFS的Login權限有關,如果你的process本身對檔案權限很敏感,就請先不要挑戰NFS(例如postgresql)。 Rootless mode - Rootless 模式 Rootless 模式指的是在Host中,執行Container的使用者,不需要是管理員,筆者就常用於開發環境中。投產環境中反而沒有聽過這樣的討論,因為投產環境很少可以讓非管理員去執行這麼重要的環境管理。 雖然只是開發環境,但這像前述的bind mount討論中,如果Host是non-root,但container 內是root,又或是兩者non-root,但UID不夾,也會出現權限問題。無腦的將host user加入docker group,只可以讓非管理員可以運行docker,但解決不了權限問題。 真正有條件解決的,可能就會向linux subgroup的方式發展。暫時筆者用得比較順的rootless mode,可以無腦用的,不是docker,是podman。有興趣的朋友可以經podman官網看看教學,它給筆者的感覺就像是自動轉換UID。 podman rootless mode 想看更多 筆者已經將過去的文章重新整理成gitbook,有興趣睇更多的讀者,可以來筆者的gitbook再翻一翻 https://macauyeah.github.io/AProgrammerPrepares/

超高CP值“德州美式煙燻烤肉”!親友聚會必食!
生活在我城
Cheers!・2024-10-30

小編作為識食之人,新濠天地頤居三樓嘅「御膳扒房」絕對係必打卡之地!自今年3月開幕以來,呢度成為咗家庭聚餐、朋友聚會、浪漫約會嘅理想之地,餐廳專注於烹調美式牛扒,將炭火扒房魅力提升至新境界。廚師利用來自美國喬治亞州嘅紅橡木煙燻,將每一塊扒都保留最純正嘅風味。而且,餐廳仲可以睇到路氹金光大道嘅靚夜景,絕對令你嘅用餐體驗更加完美! 餐廳資訊: 地址:澳門新濠天地頤居三樓 營業時間:星期二至星期日,晚上6時至10時30分(最後點餐時間晚上10時) 著裝要求:時尚休閒;男士禁穿涼鞋或無袖上衣 孩童政策:歡迎任何年齡賓客入座 查詢或訂座: (853) 8868 6681或tastingroom@cod-macau.com 官網詳情:https://s.ctm.net/htUY1 御膳扒房——您的gathering好去處 御膳扒房特別挑選28天熟成美國和牛、頂級黑安格斯谷飼牛和美洲野牛,肉質軟嫩多汁,炭烤風味一絕!餐廳嘅Josper木炭烤箱無需插電或瓦斯,能達300-350度的高溫,快速鎖住食材嘅原汁原味,散發出誘人炭火香氣,令人垂涎欲滴! 不論係私人聚會定係家庭聚餐,貴賓廂房可容納14位賓客,等你係典雅嘅環境中盡情享受美食。 最近御膳扒房推出好多CP值超高嘅抵食菜色,等小編帶你睇睇餐廳兩款特推菜單! 德州美式煙燻烤肉——風味醬汁,味道極佳 「御膳扒房」主廚特調嘅德州風味醬汁,淋喺肉表面,再燻製出獨特香氣,味道絕佳!選用櫻桃木、山胡桃木及蘋果木炭火燒製嘅大理石花紋美國SRF極黑和牛腩、肥嫩牛仔骨,以及多汁豬腩扒,最佳火候激發煙燻飄香,皮脆肉汁四溢,帶來獨特嘅味蕾享受。 櫻桃木煙燻美國和牛牛胸 配洋蔥沙律及牛汁,奢華大理石花紋和牛胸肉在櫻桃木上燻製,風味獨特。 300g / $568MOP 山胡桃木煙燻牛小排 肥美嫩滑嘅牛小排,使用山胡桃木片燻製,增強濃郁煙燻味。 300g / $498MOP 600g / $888MOP 蘋果木煙燻五花肉 多汁嘅五花肉,用蘋果木燻製,配以香甜青蘋果醬,味道和諧平衡。 200g / $388MOP 配菜 忌廉甜粟米 $98MOP 碳烤雙孢菇 $128MOP 炭燒牛排番茄 $128MOP 限定推廣期:即日起至 11月30日 CP值超高!六道菜精選晚餐$2888+ 御膳扒房推出咗適合3至4人分享的6道菜晚膳套餐,套餐包含餐廳大部分嘅招牌菜式,包括1,200克嘅厚切T骨牛扒、極級牛肉他他、香煎帶子、龍蝦或牛肝濃湯、番茄沙律及其他美味甜點。對於有選擇困難症嘅你黎講,絕對係最佳選擇! 對於唔鐘意牛肉的賓客,單點菜單上仲有羊架、燒雞、波士頓龍蝦、海鱸魚等選擇。 呢個套餐真係物超所值!份量非常適合家庭及朋友聚會,同時包含餐廳大部分的招牌菜,快啲約埋你嘅朋友一齊來享受美食啦! 御膳扒房: 地址:澳門新濠天地頤居三樓 查詢或訂座:(853) 8868 6681或tastingroom@cod-macau.com 官網詳情:https://s.ctm.net/htUY1

感謝賢者模型工作室 - 修復那些年還沒建好就斷樁的模型
手機‧電玩
MacauYeah・2024-09-13

不知道80、90後的朋友們,今年年初有沒有留意Gundam電影? 一向熱愛Gundam的朋友們,一定知道這套大熱作品Gundam Seed Freedom的出現。那是原本的Seed Destiny的後逐全身劇情,正因如此,玩具商也馬不停蹄地推出新模型。在電影加持的情況下,其實很多老模型,都推出重賣(再販)。筆者也不例外,在看過電影後的,不斷翻老模的格價。 不過,最佔上心頭的,並不是購買欲,而是筆者過去,有一台模型組裝到一半就斷臂的MG脈衝高達(Impluse Gundam)。 上網找模型群友求助,不外乎都是找補件或當殺肉(即係給他人當補件或改件用)。但這次勾起回憶,不如就來個修復吧,死馬當活馬醫,實在救不了,就當殺肉吧。 筆者的情況,是因為模型手臂連結點斷裂,用膠水是無法修復的。經一位網友的指點,這必需靠打樁修復。 打樁,基本上有三要素:手鑽(連鑽頭)、銅棒、萬能膠。萬能膠很易可以解決,在本澳各大超市及文具店均有售。手鑽(連鑽頭)、銅棒,就麻煩一點,五金店的都很大,不適合模型玩具用。當然,有何事,去萬能的淘寶就有售。 在淘寶購物車當下,筆者還是很猶豫。萬一買錯了怎辦?淘寶單價不貴,但運費可很要命。是不是找個懂修復的大師,幫忙看看情況,再由大師下單比較適合。 就是這樣,筆者就不斷在網路上找,到底澳門有沒有模型工作室。一找,還真有一家【賢者模型工作室】,主打噴塗裝備的工作室。當時筆者還厚顏地私信問店家,如果不噴塗只素組的話,有免費位置嗎?店家還很慷慨的回答,是的,素組不收費。收費部份,就是耗材購買、噴塗裝備租用。坐位上,只是租客優先。 所以筆者就在本年的八月份,去【賢者模型工作室】朝聖一下,順便帶著斷臂的脈衝,看看有沒有路過的大師幫忙指點一下。【賢者】就如當初對話中了解的一樣,主打噴塗。筆者雖然對噴塗了解不多,但見在場裝備,一定是專業級。賢者不單是提供上色工具,還解決了很多抽風問題,在家想要一個這樣安全的制作環境,一定價值不菲。因為家庭環境問題,放棄噴塗的朋友們,真的可以去【賢者】現場看一看,應該會有所得著。 說回筆者原本的脈衝高達,剛好當晚店長【賢者】在場,拿起筆者的模型細看了一翻,然後就講了一句:"簡單,我幫你修吧"。筆者原本還以為只是來取經,然後再逐一買工具,想不到熱心的店長,突然出手幫忙,實在喜出望外。 手鑽開孔 上銅樁,最後插入主體中 回家再組裝外肩甲,浴火重生 在整個修復過程中,慷慨的店長用的都是他自己的工具,只是他手中沒有已開封的銅樁,筆者就現場買一份吧,其餘一分錢都沒有收取筆者的。店長不但為筆者修復了模型,還省下了工具錢,還傳授了補樁的要點,筆者實在收穫巨大。想不到,澳門玩具業中,還有這麼良心的店存在,實在值得支持。 若然讀者們跟筆者一樣,因為任何原因,有一些未完成的作品(模型、GK),不妨一齊帶上去【賢者】,看看模友們能不能為你帶來新的方向。店長不一定在店,有需要可以加入他們的交流群,打聽一下店長的駐店時間。交流群也不會有店家的推銷產品,不過群友們會推坑團購,大家要管好自己的心。 【賢者模型工作室】 官方專頁 https://www.facebook.com/insmws/

時空幻境 - 熱情傳奇 (情熱傳說) 心得分享
手機‧電玩
MacauYeah・2023-09-19

雖然這遊戲出了有點久,但對筆者來說真的一波三折。玩完後,有一股很強的感概,所以還是寫編評價來比達一下感受。 時空幻境 熱情傳奇 Tales of Zestiria ,其實是在PS3未期推出的作品,當時亦有跨代登陸PS4。那時亦因為推廣PS PLUS 會員,也作為特別作品送給當時的會員,筆者也是當時就下載了這遊戲。但筆者總因為各種關係,玩到一半,就被其他事情吸走了。再回來,總是覺得斷了片一樣,總是想從頭玩,好好看一遍劇情。就是這樣,前十小時的部份,起碼玩了三次。 這遊戲有這麼吸引嗎?即使不斷重來,也想玩? 首先,這遊戲的總評價真的不算特別好,能玩下去,有一部份出於對Tales of 系列的情懷,而另一部份,就基於友善的暫停機制,以及剛好的ARPG動作遊戲難度。 我們先聊一聊那些做得不夠好的地方 劇情 整體來說,本作劇情走捨身成仁的路線,有一些命題,在前期刻意說一半,故弄玄虛,到最後才解答的劇情。中途夾雜一些奇怪的小黃色笑話。總之就整體很慢熱。 戰鬥 系列的傳統,慢慢地在戰鬥中加入新機制。這作也不列表,前期單人模式,前、中期加入BG神依合體,中期加入爆發特技,中、後期加入秘奧義。 但最麻煩的是普攻(遊戲中叫作【特技】),它一改傳統,普攻由今集開始,也會隨著使用量有改變。一開始只會有段數差異,隨著使用量增加後,同一個段數配搭不同方向會有新招式。概念是好的,但它對Buffering(預按鍵的時機)做得不太好,導致初期筆者試不出方向鍵的差異,久而久之,忘了有這些特別的技能可以用。 以上,就是筆者覺得最讓人有機會棄坑的原因。我們再看看那些吸引人的地方 戰鬥 扣除方向鍵的問題後,其餘的機制也很有探索的深度。【奧義】剋制【特技】,【天響術】剋制【奧義】,【特技】剋制【天響術】。因為任一角色只有其中兩類技能,要變換只能通過【神依】能力,但需消耗BG(有累積條件的資源)來進行。在BG資源短缺的情況下,如何使用特定兩類技能來應付挑戰、決定何時消BG以換得更多優勢的就變得很有必要探討。 它的裝備系統也是對上述這些策略有所影響,不同裝備有額外技能獎勵,有些對BG資源有累積加成,有些對SC回復速度有影響(體似魂系的耐力槽)。能否通過合成去保留技能優勢,同時保持裝備等級跟得上遊戲進度,也是需要研究研究。 如果大家有看Speedrun,除上述策略需要考究外,還要會不斷測試不同角色招式對控場的差異,玩家可以自由選擇其中一位角色進行人手操控,其他交由AI控制。 整個戰鬥機制,筆者在經過50多小時的一週目主線遊玩後,還覺得有探索的空間。所以對筆者來說,戰鬥機制並不沉悶。 可以暫停的系統 這遊戲,除了在少數的特定CG過場外,所有部份都可以暫停。對於筆者這種,忙起上來三分鐘就會被打擾一次的工作/家庭環境,不能暫停的遊戲真的玩不下去。雖然新主機(PS5/Switch等),對於待機功能已經很成熟。但這遊戲是PS3年代的作品阿,那時制作組已經特意制作暫停工能,而且在非劇情和戰鬥的情況下,還提供任意的快速存檔功能,那可是比同類RPG遊戲,什至是動作遊戲,都要友善。多得這個功能,筆者才能少數地完成在PS平台上的遊戲。 劇情 也多得戰鬥的可探索性,以及可以暫停的系統,讓筆者玩到最後,一些劇情上的疑點也得到了解答。整體劇情並不完美,但也不差,能看完結局,也是一件樂事。其中主角的身世的伏線,處理得不錯。開場故意不提,也沒有讓人刻意深討。但越到後越期,在不經意地變得有越來越有關係,多了一份突如奇來的驚喜。 總結 因為多次重玩,所以筆者對於怎樣可以破關,變得很有執念。或許對比現在的遊戲,老遊戲的聲畫表玩顯得過時,但其內的操作機制,筆者還是很推薦大家去試試。

發佈Docker Swarm App的選擇 - CI/CD系統的參與
科技新知
MacauYeah・2023-08-25

一段時間前,筆者就討論了一些Docker打包的程式的文章,也討論了一些Docker Cluster環境下的選擇。現在也是時候,可以分享一些對於發佈環境的可選空間。 CI/CD系統 CI/CD 全稱是continuous integration (CI) 和 continuous delivery (CD),字面上代表的持續地集成和發佈,實體上就是某台伺服器自動發佈APP。因為使用到Docker Cluster,不論前述什麼選擇 (前文連結 請點這裏),都會有多個node(節點)的出現。要發佈App,總不能一個個node逐個登入設定。所以我們需要一些CI/CD工具,把這個過程都自動化。 在筆者的認知上,CI/CD系統,由兩個部份組成,一個是取得Source Code(程式原始碼)的過程,一個是編譯或發佈Source Code的過程。Gitlab,Github,BitBucket等大型的代碼庫供應商,它們天生為了保存Source Code而提供服務的。不少CI/CD系統都可以跟它們整合,它們提供了存取Source Code的部份,剩下你只要能提供編譯或發佈的伺服器就好。 如果作為小型開發團隊,很少會有意願去自己花錢養一個編譯或發佈的伺服器。(極端地,如果我就是一人團隊,我用自己電腦編譯和發佈就好,伺服器能做的,我自己也能做。)好消息的是,Github提供了一個叫Github Action的CI/CD系統,即使你沒有自己的編譯專用的伺服器,Github Action也可以用Docker Image,提供一個臨時的編譯程序,用完就刪掉。詳細功能還請各位先查看官方教學,筆者也暫時只能零星使用經驗,無法給出有意思的架構。 如果對智慧財產權有高度重視,Source Code不能存放在公開的伺服器,那麼Gitlab Enterprise Edtion則是一個好選擇。運用Gitlab ee,你可以用自己的機器,造一個純本地的庫存伺服器。更強的是,它內建也有CI/CD系統,只要你有間置的伺服器,就可以作為編譯使用。筆者也是從這個方向著手,架設了自己的Gitlab Runner(Gitlab CI/CD系統)。在這裏,就分享一下與Docker Swarm整理的概念。 對於前述兩種選擇,GitLab Runner都可以做得到 底層程式打包成Image並運行在Swarm mode上,每次發佈的是App Binary(執行檔或核心檔案)。 把App直接打包成Image,並運行在Swarm mode上,每次發佈的是App Image。 CI/CD - 打包底層程式成為Image 在這個選擇下,其實就跟傳統自動化發佈的做法類似,只是發佈時,要多個node報行更新指令。如果你使用的底層程式原本就有支援多版本並行,這樣更新時就不用太操心rollback(回滾?)等操作。若系統不支援多版本並行,為求簡化,若遇到要rollback的情況,重跑過去舊的CI/CD操作也是一個做法。當然,我們也可以經過一些備份的操作,來保存被代替的程式,若在發佈過程中出問題,也可以手動重來,不過整件事就越來越複雜。 筆者發佈的基本思路是 使用docker image,編譯和打包App Binary。 使docker image做編譯的好處是,你可以比較放心地假設每次編譯時,你的編譯環境都是乾淨的。 傳送上述的結果至生產環境可以取用的地方。 跳入生產環境執行更新指令 這裏有些隱藏的管理成本,如果你生產環境中有多個node,最後那幾行指令就要多抄幾次。 CI/CD - 打包App成為Image 在這個選擇下,對比傳統自動化發佈的做法,現在要多做一步,就是要包裝自己的Image。不過好處是docker swarm有提供監測工具,在發佈過程每個分身會逐個更新,前一個分身更新成功後才會到下一個分身更新。而且 rollback等的操作,你可以靠docker做到。即是要手動rollback,也可以透過更正docker tags來達到,所以整體上來說沒有比傳統的麻煩。 筆者發佈的基本思路是 編譯App Binary。 打包成docker image。 經docker上傳image。 跳入生產環境執行更新指令。 對比傳統自動化發佈的做法,最後的更新指令,只要執行一次就可以。當然,原本在Docker Swarm中要管理的事還是要好好管理。 CI/CD - 備註事項 雖然CI/CD可以幫忙簡化更新的過程,但實際操作會比上述的例子複雜一些。因為通常對非技術型的外界用戶來說,一個Web App會包含很多不同的功能。上述的例仔,在實際情況下可能需要拆解成很多微服務來進行。所以對管理上還是有相當的挑戰。

用Github寫攻略其實也不難
手機‧電玩
MacauYeah・2023-08-04

上個月筆者為大家介紹過一位內地的文字攻略制作者Pser_hanser。本月筆者就身體力行,計劃制作一些FF8的協作攻略筆記,亦因此對於協作工具仔細地考量過一翻。 首先協作的基本要素,就是各人可以共同維護。所以國外或內地素人作者,都會以Google Doc或騰訊文檔為主。傳統的網誌就不太適合。而另一方面,就是因為遊戲攻略要考慮附圖的因素,Google Doc或騰訊文檔對於上傳圖片都算很友好。所以對於不熟網頁技術的作者來說就最適合。 不過對於筆者來講,有一個更大的考量點就是歷史記錄和版本差異。因為一份攻略的出現到完善,都會有不同程度的更新。更不用說因為遊戲Bug Fix,導致某些策略上的變更。左思右想,筆者選擇Github + mdBook,一邊可以做多人協作的版本控制,另一方便亦可以自由發佈網頁。 Github的唯一問題可能就是檔案大小問題,若圖檔太多太大,就不適合。不過好在偉大的twitter,現在可以作為第三方存取圖片,筆者的遊戲截圖就可以更方便地上傳及使用。如果大家只是想做輕攻略,就不需要專門為Switch和手機遊戲接上HDMI截取器,可以省下一大筆費用(因為對接Twitter,所以Switch或手機遊戲的截圖的上傳就變得無難度)。 以下是筆者做FF8攻略的初稿,協作連結github (https://github.com/macauyeah/ff8CasualGuide) 截錄一些mdBook的範例 # Disk 01 part 1 - Draft ## Balamb Garden 經過一輪過場動畫後,老師就來接你了。場景轉到課室內,終於可以自由操作。 這時不需要跟傳統方式去開電腦取GF,向外走就好(Quistis會在校園外給你GF),跟老師交談幾句,得知補考的地點後就可以外出。 ![fire caven](https://pbs.twimg.com/media/F1NPIw9agAAQjJp?format=jpg&name=large) 走廊外碰到未來的隊友Selphie,不想煩的話,兩次對話選項都選第二個(speedrun)。 ![donot have time](https://pbs.twimg.com/media/F1NPIw9akAEcKH1?format=jpg&name=large) 從Selphie進來的方向離開,但記得一定打攪一下橋上的路人,他會給你7張卡 ![7 cards](https://pbs.twimg.com/media/F1NPIw_agAAJFWm?format=jpg&name=large) (你現在2樓)進電梯下1樓(暫時沒有選項,所以進電梯就會直達1樓) 在1樓大堂有個導覽板,調查後可以快速移轉。筆者選擇直接去Front Gate。 ![guide box](https://pbs.twimg.com/media/F1NQsHNaAAUriJL?format=jpg&name=large) ![teleport front gate](https://pbs.twimg.com/media/F1NQsHJaAAEaDk1?format=jpg&name=large) 註: 大部份Speedrun玩家都會先去Cafeteria,想早一步取得Quistis卡。筆者因為未弄懂那個必勝法則,所以先跑主線取得Ifrit卡後再回來挑戰。 出校門,Quistis說幾句,它就會給你GF ![Give GF](https://pbs.twimg.com/media/F1NQsHJacAIiI0S?format=jpg&name=large) 後述所有教學都請自行跳過,後期可在Menu > Tutorial慢慢查吧 ### 調整裝備 Junction - Quistis: GF Shiva - Magic, Draw, Item - Squall : GF Quezacotl - Magic, Draw, Item - ![Ability](https://pbs.twimg.com/media/F1NQsHKaYAE7Gj7?format=jpg&name=large) GF - Quezacotl: learn Card - ![card](https://pbs.twimg.com/media/F1NQx2UaEAEiq0g?format=jpg&name=large) - Shiva: learn I Mag RF - ![I mag rf](https://pbs.twimg.com/media/F1NQx5faUAA2EN1?format=jpg&name=large) Config - Cursor: Memory - Camera movement: 0% - Battle Message: max - Battle Speed: max - ![config](https://pbs.twimg.com/media/F1NQx2VaYAAmsUd?format=jpg&name=large) ## Fire Cavern 默認Boss以外隨機戰鬥都以逃跑為主,逃跑方式為長按L2 + R2。有需要完全戰鬥的會再特別說明。 出校園後,向東走,走向一個山洞。進行後Quistis會再有一輪教學。 走到門前,選10 mins進行考試。 ![twitter](https://pbs.twimg.com/media/F1SmNqVaEAAMa-E?format=jpg&name=large) 入洞後,右 > 上 > 上 > 上 > 上 > Boss戰。 在途中,遇敵Red Bats時,Draw指令抽取Thunder(第一項)。Squall, Quistis每人各抽7個以上Thunder魔法。 ![twitter](https://pbs.twimg.com/media/F1SmNqUagAENuOh?format=jpg&name=large) ### Boss Battle: Ifrit - Boss參考LV 6, 1068HP - Squall、Quistis: 對Squall放Thunder魔法,讓Squall先進入黃血狀態。 - ![twitter](https://pbs.twimg.com/media/F1SmNqUagAAj5wt?format=jpg&name=large) - 保守策略,Thunder每次大概扣100HP,Squall的血量大概為200時,就不再使用。被Boss慢慢攻擊就夠。Boss Fire魔法大概扣 60-65,所以即使很不幸,也有兩次援衝的機會。 - Squall 使用 Renzokuken: 筆者有Trigger增傷的情況下普攻平均傷害55,不用Renzokuken的話大概18-20個回合可以送走Boss。道理上使用Renzokuken後也是差不多,數次數就大概知道幾時結束。但因為有時Trigger失誤,筆者會同時使用Quistis攻擊(雖然這樣效率不是最高),所以實戰上比較難去數。 - Quistis: 有條件的話就自己攻擊自己,為後述的Fish Fin戰做準備。 頁面顯示效果 https://macauyeah.github.io/ff8CasualGuide/Disk01-01.html#balamb-garden 有興趣的朋友可以隨時checkout或commit 我的攻略 https://github.com/macauyeah/ff8CasualGuide

單機遊戲轉型|《穿越時空的貓》
手機‧電玩
MacauYeah・2023-04-21

相信有留意筆者文章的讀者們,都明顯看得出筆者大部份都只會玩主機單機遊戲。但隨著時代一直在變,用手機玩遊戲即使怎樣的不好不好,手機平台始終也是最易觸及人群的渠道。良心遊戲商想要活下去,手遊是一個必需要下苦功的議題。 以前,筆者經常介紹SuperCell的遊戲,因為它的遊戲的確有獨到之處,不過可惜的是,遊戲都屬於競技、快速遊玩(快餐?)類型。想玩些有故事,文本長一點的遊戲,SuperCell就無法提供了。 競技遊戲、快餐類,其實真的很適合手機平台。刷刷就一場,比較好填補碎片時間。過去,很多遊戲商都嘗試把主機的單機遊戲移植到手機上,但重點問題是沒有考慮即時Save的做法。碎片時間,真的不夠大家去下一個Save Point,然後下次開遊戲又會被強制重置。(特別是那該死的Square Enix,筆者買的兩款移植手遊,都因iOS升級而無法再遊玩。) 而剩下其他的,就是課金味很農,不課就找不到樂趣。 不課金也能玩的作品 故事類、不課金也能玩的手遊作品其實還有的,只不過真的不多。而筆者看上的兩款,也剛好是以RPG為題材的作品。它們很好地提供了Auto Save功能,即便每過一個地圖、每換一次裝備,也會很貼心的幫你存檔。它們分別是《穿越時空的貓》和《歧路旅人:大陸的霸者》。 兩遊戲雖有課金抽角色機制,但核心樂趣并不是抽抽抽,而且故事與回合制的策略思考。而《穿越時空的貓》則更被實踐證明,不課金,依然可以有效率地通關、爆機。 https://www.speedrun.com/another_eden/ 上述連結為《穿越時空的貓》的Speedurn 排行榜,參賽者需從新開始遊戲,玩到第二十五關,而且不能使用遊戲內的石頭(其中一種可貨金的道具)來進行遊戲。在此規則下,參賽者變相只可以通過教學關卡後,進行一次首抽就不再抽角色(首抽為指定多角色中選取一個)。而這個Speedrun成功的例子說明了一件事,遊戲內的資源,足夠可以挑戰完遊戲。當然,不是每個新手都可以找到那個最優解的路線,但經過研究、規劃,某些遊玩策略是可以有效推進遊戲的。 可能大家會說,玩一個遊戲,重複玩,大量玩,不會悶嗎?筆者以前也是會追新遊戲的人(現在也是),很少會對遊戲進行二週目或高難度挑戰。但遊戲玩多了,慢慢就會發現,有些遊戲是很值得重複遊玩的。那些遊戲,要麼就是多結局遊戲,要麼就是文本深度很高的遊戲,還有一種就是,遊戲機制上存在很多探索可能的。 說到遊戲機制,筆者就要提《歧路旅人:大陸的霸者》。它在破防和資源管理上,有很大的變化空間。雖然這遊戲未有Speedrun佐證,但以之前筆者的遊玩經驗,就算用內置獎勵,也有很多組合可能。詳細推介可參閱筆者前述之文章-良心推薦:《歧路旅人:大陸的霸者》。 最後最後,如果你對於重複遊玩都不太感興趣,只想看看劇情,《歧路旅人:大陸的霸者》依然是一個選擇。對於一般玩家來說,隨時玩、自動存檔、會有猜不透的劇情反轉最佛心的體驗。 (註:《歧路旅人:大陸的霸者》其實也是Square Enix的出品,但遊玩不需要遇先付費。而且因為是相對成功的手遊,斷估不會那麼快就放棄更新。)