文章列表

街霸六的元宇宙大笪地對戰大廳

手機‧電玩
MacauYeah・2023-12-26

上期就為大家介紹了Modern Mode的新系統。今期就再繼續為大家介紹新的對戰系統。(上期連結: https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/13954 ) 找個陪練很重要 現在街霸五中,網上對戰不外乎是隨機的排名賽、隨機的友誼賽、邀請特定網友在對戰大廳輪流對賽。看下去沒有什麼大問題對不對? 實質上就是一切都很隨機,而對戰大廳很少人懂得運用。 街霸六中一個很重要的改動,就是在隨機的排名賽和友誼賽,加入賽後自訂賽制的玩法。排名賽上遇到五五波的對手,想跟它再打幾場? 可以,馬上進入自訂友誼賽,打個夠。這個改動很必要,在過去的日子裏,特發跟不同人隨便打兩三場,根本不知道應對手段;跟同一個對手來回對策,才會慢慢知道輸在哪裏,有沒有什麼地方是博奕的盲點。猜包剪揼連輸三場,你覺得是對手運氣上壓制你,但連猜十場你也輸,就代表你真的被對方看透。若在排名賽上沒有碰到想賽後重複對戰的對手,遊戲商亦很佛心地重現了一個類似大笪地的對戰大廳,讓你可以在元宇宙坐在一個虛疑街機框下,等待那些跟你一樣不太介意分數,等級差不多、但只想連續思考對策的朋友。 在過去街霸五中,隨機的友誼賽和對戰大廳,對筆者這些低端玩家來說實在沒有什麼用途。友誼賽實力差距很大,基本上就是老手開發新帳號來碾壓新手的地方。對戰大廳則是連線品質參差問題,見到高分的不敢進去,低分的基本上網路卡到不能玩。當時最能遇到熟練度差不多的對手,就只有排名戰,但同一名對手的排名戰機會不多,然後大家又非常在意分數的上上落落,所以當時的對戰實在稱不上快樂。 對比這個情況,街霸六就變得放鬆很多,大家更容易地在大笪地中找到差不多的對手陪練,不用計較分數。大笪地的成功,並不是單純地因為可以自定義對戰,它的連線品質提高,也是穩定在線玩家數量的一大原因。 其他重要改進 單從字文上,或許你覺得整個街霸六都是換湯不換藥。但筆者很負責任的說,它是在硬技術和設計上,都做到很大的改進。雖然不能稱為劃時代的改進,但有了它們,遊戲更友善: 對戰系統可以全平台跨平台對戰,PS、XBox、PC可以大混戰。你能匹配到的有效在線玩家變多了。 提高連線品質,現在那怕是Steam Deck連上Wifi也能網上進行對戰,大家也不那麼懼怕延遲的問題。 大笪地加入社交元素,你還可以通過故事模式,解鎖自定義格鬥技,在非正式的對戰中跟別人惡攪對戰。 練習模式加入極重要的幀數顯示,大家更有條件地自定義練習情境。 玩家們已經極少再需要上網查幀數資料,除了無敵幀需要上網查以外,其他的自行試就好。 官方在練習模式中預錄制了一些情境練習,例如對空、破防、解投等,讓大家可以直接練。但在解投的情境中,更讓筆者明白這遊戲有多麼的爾虞我詐。 這兩期講的東西,都是Capcom針對核心遊戲元素的多項精進。吸收了街霸五的技術和策略上的失敗,街霸六就從軟硬兩方向大改進。Modern Mode在直正意義上可以讓新手入門,但又不致於無腦遊戲。對戰機制,可以讓大家不只關注排名賽,更大地去提供實戰環境讓大家實驗自己的PvP策略。

格鬥新老手也很友好的街霸六 | MORDEN MODE

手機‧電玩
MacauYeah・2023-12-22

街霸六已經出了半年有多,但筆者也是近期在購買steam deck 後才加入街霸六。一玩就實在愛不惜手,特別是steam deck的加持,讓筆者可以在午休時間大方地玩。 可能好多網媒都有介紹它,亦十分讚賞它的單機故事模式。但對於沒有時間筆者來說,慢慢跟故事拜師成長,解鎖不用招式,實在讓筆者耐不下心。而真正讓筆者感到友好的,是它的操作系統和對戰系統,讓它可以達到老手有老手的開心,新人有新人的快樂。今期,就升為大家介紹它新的操作系統。 MORDEN MODE 經常有人誤會,格鬥遊戲玩的是連招,如果人人都可以自動連招,根本就是小朋友遊戲,拿不上大台,也不會有舉辦比賽的價值。所以有一些人,會看少「任天堂明星大亂鬥」的價值,因為不論多新手,都可以打出基本combo。但說實在,它是街霸6出來以前,最有條件同時允許新老手同樂的遊戲。 格鬥遊戲,什至其他競技遊戲,對於同等操作熟練度的選手來說,他們的比拼是應對策略。而相對公平的競技遊戲,應對策略就是很像是博弈,沒有100%安全的招,就像包剪揼一樣,可以有特定的對應策略。格鬥遊戲與包剪揼最大的差異,是在足夠熟練和專注的情況下,雙方是有條件作出對策的,所以格鬥遊戲不完全是盲猜。而過去最大的問題,就是格鬥遊戲太難讓新手學會博奕,外人看去就是combo為王,搓招難,就放棄吧。 街霸五在容納新手方面,其實都下過很多努力,包括減少每個角色招式數量,較寬鬆的combo 輸入時間,提供可錄影、重播、幀數檢視的練習模式。可惜搓招門檻始終也是讓很外行人放棄的原因。而街霸六,則提出一個很多人都提過的做法,但沒有廠商真的成功過的做法,那就是一鍵搓招與傳統搓招共存的做法。 玩家可以在對戰前,選擇新的【Modern Mode】(現代模式),然後享受以下功能便利。 簡易使出必殺技。通過 單一方向鍵+SP鍵使出不同的【必殺技】 單一方向鍵+SP+AUTO鍵使出不同的【OD必殺技】 單一方向鍵+SP+重攻擊鍵使出不同的【超必殺技】 攻擊力比較搓招或【Classic Mode】有下調 簡單使出連招。通過 不同的單一攻擊鍵+AUTO鍵 連打 使出三套特定的連技 攻擊力比較搓招或【Classic Mode】有下調 若要使用【輕、中、重必殺技】,仍需要使用傳統的搓招方式。 攻擊力回到100%。 對比【Classic Mode】,【Modern Mode】有些拳腳攻擊、必殺技的差異化版本無法使用。 例如Luke在MORDEN MODE中只可以使出後重拳,沒有後重腳。 例如Ryun在MORDEN MODE中只可以使出中旋風腿,沒有輕、重版本。 但依然可以打出大部份的搓招 + 連技。 當然,玩家可以選擇【Classic Mode】(傳統模式),一切按鍵都跟過去一樣,有輕、中、重之分。 筆者最欣賞的,就是這個【Modern Mode】的出現。因為它可以降底學習成功,但又不失公平性,讓新、老朋友可以打出一場有博弈味道的友誼賽。例如正面跳入攻擊,在過去的高端對局中,只能作為突襲的戰術,不能隨便跳。但在低端對局,正面跳入攻擊就經常是老手欺負新手的一個有效途徑。新手想要對策正面跳入,必需經過一個搓招,才能使用昇龍拳來穩定對空。但在【Modern Mode】,簡單一鍵昇龍,就可以代解威脅,雖然攻擊力變底,但正面跳入不能當是賴招使用,讓大家回到思考何時跳入的博弈問題中。 如果說【Modern Mode】只為新手當做過渡期而使用的模式,那就真的小看了它的設定。在遊戲正式推出後,意外地出現高端對局中使用【Modern Mode】,因為它可以提供快更的反應速度,可以彌補一些角色上的短處。 對筆者來講,【Modern Mode】最重要的並不是簡易必殺技。因為追求傷害量的情況下,搓招很必要的。筆者看上它的原因是它能有效地簡化Drive Rush的輸入,令到筆者可以更易地通過【延長攻擊手段】最得反應的時間。一般讀者可能不明白進攻方為何要反應,不是防守方才要做反應嗎? 在格鬥類遊戲中,大部份時間防守就是死按一個【後】或【下後】鍵就足夠,在街霸六當中,更因為有Over Drive、Drive Impact等系統,防守方有更多博奕下的對策方案。怎樣打穿敵人的防守,是進攻方要用腦的事,更因為如此,有些人選擇打後手,等對方出錯,反而很有利。 但進攻才是格鬥遊戲的重點,要走向高分層次,就必需要跨越【Hit Confirm】的障礙。經過【Hit Confirm】,若然連招中途就發現打不中對手,就以一個更安全的攻擊收尾;若然打中了,做使用更多資源打出更高傷害。提高自己【Hit Confirm】的反應能力,基本就是跟年齡作對。所以筆者就需要經過其他手段,例如:Drive Rush來延長自己的攻擊節奏,好讓反應不來的筆者有更多時間選擇打安全招還是全力攻擊。 下期,筆者會再聊一聊對戰機制的改進

找一個可以私有化的協作平台

科技新知
MacauYeah・2023-12-19

在現今這個網路為王的年代,大部份文書等編輯工作都可以在Google Drive, One Drive那邊多人協作。唯一的問題是,你是否考慮資料保密問題。 一些開放資料,放在雲端上,故然無問題;個人用資料,就自己為自己負上保密責任。但作為一家公司,把自家客戶的資料放在Google Drive、One Drive上,你又會否覺得足夠保密? 不放在這些協作平台上,改為自購一個NAS File Server,把共享檔案都放進去,這樣又足夠方便嗎?現在File Server最大的問題,是無法提供同時協作編輯的功能,想在同一個檔案,多人同時更新不同的部份,是不可能的。 Etherpad-lite 如果大家只需要一起寫文字稿,可以試用Etherpad-lite https://github.com/ether/etherpad-lite 。 筆者試用過,它提供實時協作,其他人的更改可以即時顯示,也有一些基本的排版功能。缺點是lite版沒有好好處理大量的資料問題,一次過複制貼上大量文稿的話,會出現網路問題。 NOCODB 如果大家需要的是試算表,可以試用NOCODB https://github.com/nocodb/nocodb 。它強大的地方,是可以匯入CSV, Excel,做欄位搜尋。老實講,這些功能,對於一個IT人來說,隨便安裝一個資料庫,例如:MySQL、 MSSQL, 都可以做到匯入結構性資料,並供多人操作資料。但對於普通用戶來講,要學會操作SQL語言,實在有難度。而經過nocodb之後,可以把MySQL等轉化為常見的試算表型式,實在驚喜。而且,它也能提供一些簡單的填表方式(Google Form)

Switch / Steam Deck / Mobile 使用體驗大比拼 (三)

手機‧電玩
MacauYeah・2023-12-14

上兩期,筆者從機身重量、續航性兩方面,對於遊戲機身便攜性的影響,今期最後一期,就從穩定性方面去討論,最後再做一個綜合影響。 沒有對比也就沒有傷害 - Mobile - Smart Phone 筆者所講的穩定性,其實就是正常運行一個遊戲,不會出現閃退的情況,讓你可以正正常常玩完一款遊戲。但因為Mobile原本是多用途機器,你玩著玩著,可以就要跳出遊戲回覆信息,但再次回到遊戲後,能不能正常運行的不知道。 大部份iOS遊戲,因為舊iphone機能限制,基本上跳出去後,都因為不夠RAM,回來後遊戲會重置。除非你打死不切換,否則一款遊戲沒有頻繁auto save功能,根本玩不下去。Android可能會好一點,有不同機型可以選擇,多一點RAM總是安全一點。 強行地用Linux運行Windows的黑科技 - Steam Deck 老實說,Windows已經不夠穩定,用Linux運行Windows Game,會比較穩定嗎?不過最幸運的是,Steam Deck有技術支援,更有社群支援,各遊戲經過Steam官方驗證,連續遊玩下閃退情況都很少。不穩定的原因,反而是Steam Deck主機本身。 在筆者遊玩的經驗中,待機後再打開,有一定機會率會整個遊戲閃退。這些問題在遊玩大作,特別是3A大作,會引來一個很不愉快的體驗。因為它們的auto save位置點一般都是以情節點來做考量,而以上班族來講,三步一待機的使用情境也很常見,那麼觸發閃退的機會率就很高。某次啟動會隨機引起閃退遊戲,真的欲哭無淚。 筆者也翻查過網上的資料,一年多前就有這個問題存在,而官方亦無法根治。筆者在寫稿的途中,還在測試坊間一些可能的補救方式,但因為時間不長,不敢說這問題是可以解決的。 穩定發揮 - Switch Switch在穩定性真的無可挑剔,多次待機後都沒有太多問題。完全貼合它的市場定位:在家可以隨時在電視玩,出外也可以四處走。隨時隨地停,隨時隨地再開。最多最多都是遊玩實體卡帶時,因為接觸不良而閃退。但這些不可避免的,因為實體卡始終是物理型態存在,跟著Switch四處奔波,難免會出問題。但下載數位版,存放於SD卡就不會有閃退。至少SD卡不會像實體卡會經常替換,所以出問題的機會也較少。 綜合體驗 其實討論了幾個方面,筆者都從是省心遊玩的角度出發去討論。 Mobile在裝備上會最少煩惱,想最輕鬆出問,這個是不二選擇,但考慮玩非課金類遊戲就最沒有保障。 Steam Deck優點是移動堡壘,若你玩的是高性能需求的遊戲,你只能選它。但想隨時玩就未必做得到。 Switch 在重量和穩定性上面最有優勢,考量延續性體驗,這個是首選。

Switch / Steam Deck / Mobile 使用體驗大比拼 (二)

手機‧電玩
MacauYeah・2023-12-12

上期,筆者為大家簡介機身重量對於遊戲機身便攜性的影響,今期,繼續從續航性方面去討論對於便攜性的影響。 依然是王者 - Mobile - Smart Phone 就如同重量一樣,續航性的理論值,依然是Mobile最優勝。單看電池容量,其實無能說手機最優,就算現在的iphone15,電池容量其實也比Switch, Steam Deck要低。能比得上的,可能只有iphone 15 Pro。但若果連同充電的方便性,Mobile是最易邊玩邊充的。一般來講,如果不以全效能去運行遊戲,Mobile是的電量是相當安心的。 但也如同重量一樣,續航性理論值,是Mobile最好,但不是安心長期遊玩的媒介。 一來,Mobile,一般都是用作社交通訊用,它的電量是分享給一整天使用的。一不小心遊戲時間長了,那天晚上可能就沒有電話用。除非大家想隨身攜帶奶媽(充電寶),但這是用重量來換取遊戲時間。所以筆者不會把它當作首選。 巨無霸 - Steam Deck 空有其名的巨無霸。在電池容量上,它是三者中最大的一款,但因為它對照的遊戲效能,是PS4/5、XBox One/X/S、PC等的大作上面。那些主機大作,對電量是極其大需求的,單憑散熱風篇的聲音,你就知道不秒。一般遊戲的預設畫面品質,就只夠1-2小時的遊戲。實在想延長,就必需要下調Frame Rate或是畫面品質。 玩消耗戰必選的設備 - Switch Switch預設電量不多,但因為畫面其實也不能要求太多,所以它的續航性不低。相比Mobile,Switch就是完完全全的純遊玩設備,也不需要筆者去刻意規劃電量。沒電?關機就好。待機也是單純的待機,不需要什麼定期連上Wifi、GPS,藍牙亦單純地為耳機及手柄使用。想更省電,就待機前就全數關掉就好。 綜合體驗 老實說,看完重量及續航性之後,Steam Deck主打市場明顯不是遊戲掌機,而是一台可以搬走的PC。你可以方便地整台電腦帶走,從自己家到公司,從公司去親友家。它的體型,比主機和Notebook要細,它的售價,也比一台Notebook要便宜。但想拿著玩?可能不會特別開心。 Mobile在重量及續航性綜合考量,其實很有競爭力。不過考量用途問題,否則你也很難安心用Mobile來玩遊戲。 老任的Switch,重量及續航性在初推出市場之際,筆者都不看好。但實用和對比之後,畫面效能和續航性控制得還不錯。

Lambda 表達式之可讀性

科技新知
MacauYeah・2023-11-24

Java作為一個真OOP物件導向的程式,在設計和編寫上是很嚴謹,什至是囉嗦的程度。近年很多Programmer因為各種原因,都放棄Java跳船去其他語言。 Javascript是其中一個很多人的選擇,因為Javascript有nodejs的加持,在Web世界下,可以同時走frontend、backend路線。而Javacript亦有一個很明顯的特性,就是大部份的library都以callback的型式出現。另外,Javascript也讓很多人覺得很簡潔,這除了是因為它沒有強型態的規限外,另一個原因也是因為有callback的大量使用。 Function Pointer 其實callback,籠統一點講就是在一個function A傳入另一個function pointer B。而編寫function A的作者,並初期並不知道function pointer B的實際操作會是什麼。A作者只是強調在特別定時候,它就會使用這個function pointer B。而這種把function pointer 傳來傳去的做法,就可以看成是Functional Programming的基礎。 Functional Programming除了把function pointer 當成是一等公民以外,還有很多附加要求,例如: Pure Function: 它只會使用到自己的Local Variable本地變數,這樣它的作用域就鎖死在Function內部,就不會有副作用。 傳統的OOP,Class中不少變數會以Class Attribute型式存在,雖然它們可能是private attribute,但還是獨立於Function外,這樣各Function的操作,都要靠作者好好地記著Class Attribute的狀態。 Nested Functions: 與普通程式語言類似,很多情況下都需要local variable,而Function Programming要足夠好用的話,就需要彈性地在function裏定義local function pointer。 Java Lambda 表達式 其實從Java 8開始,就有提供Lambda表達式,這是一個可以制作匿名function pointer的方法。所以硬要講,Java也可以做Functional Programming。 但必需要盡早強調的是,Java經常性地使用class attribute,它們很多時候都會引申請狀態的概念。即是在它們必需經過特定步驟後,class attribute才會有特定的意義。也就是Lambda表達式想保持Pure Function的特性,它可以使用的時期就有很大限制。 但我們還有必要使用Lambda嗎? 以筆者的經驗來講,它還是有作用的,特別在於它可以改善Class Function的閱讀性。 例如下面一個Java Class。它是一個工廠,提供一個服務可以生產一堆車。那些車而需要經過特定檢測,才能推出。 public class Factory { // ex1 public static List generateListOfCarByForLoop() { List tempCars = new ArrayList(); // many other logic // many other logic // many other logic List passTestCars = new ArrayList(); for (Car car : tempCars) { if (car.getWheels().size() == 4) { // many other check logics // many other check logics // many other check logics passTestCars.add(car); } } return passTestCars; } } 中間的for loop可以用lambda來改寫。 // ex2 public static List generateListOfCarByLamda() { List cars = new ArrayList(); // many other logic // many other logic // many other logic cars = cars.stream().filter((car) -> { if (car.getWheels().size() == 4) { // many other check logics // many other check logics // many other check logics return true; } return false; }).toList(); return cars; } 有人會說,上述ex2只是形式上改變了,沒有特別易讀。就像ex3這樣,把特定邏輯抽成獨立function,才是真正的易讀,對嗎? // ex3 public static List generateListOfCarByForLoopFunction() { List tempCars = new ArrayList(); // many other logic // many other logic // many other logic List passTestCars = filterCarsByWheelsSize(tempCars, 4); return passTestCars; } private static List filterCarsByWheelsSize(List originalList, int targetSize) { List passTestCars = new ArrayList(); for (Car car : originalList) { if (car.getWheels().size() == targetSize) { // many other check logics // many other check logics // many other check logics passTestCars.add(car); } } return passTestCars; } 上述ex3是一個有效的改進。如果大家不計較傳入參數的先後順序及交互影響的話,就已經很足夠。 但如果大家對於多參數的解讀又怎樣? private static List someotherfunction(List cars, List wheels) 大家又會不會突然停住,想想到底是cars影響wheels,還是wheels影響cars? 對於多參數的function來講,相互影響就會越來越多,但使用Lambda的話,可以針對性地表達這是一個Predicate Lambda。 // ex4 public static List generateListOfCarByLamdaComposition() { List cars = new ArrayList(); // many other logic // many other logic // many other logic List wheels = new ArrayList(4); cars = cars.stream().filter( filterCarByWheelSizePredicate(wheels) ).toList(); return cars; } private static Predicate filterCarByWheelSizePredicate(List wheels){ return (car) -> { if (car.getWheels().size() == wheels.size()) { // many other check logics // many other check logics // many other check logics return true; } return false; }; } 就最後的ex4版本,可以很明確的知道是cars被Predicate所作用。 如果大家還有其他使用Lambda的明顯好處,也可以一起來Github分享大家的Code

Switch / Steam Deck / Mobile 使用體驗大比拼 (一)

手機‧電玩
MacauYeah・2023-11-21

還記得很早開Blog之初,筆者一直都集中於主機遊戲評論。筆者不想放棄主機的主要原因是移動端難有一個款可以提供高品質的遊戲,不論PVE類型機還是PVP類型。 但逐漸地,各種遊玩動機,例如個人作息、方便性、遊戲品質,都有了很大的改變,經過漫長的時間,筆者最後亦都完全放棄主機,進入Portable Gaming時代。 筆者第一台便攜型機,就是PSV,不過因為已經停產,聊太多也沒有重要意義。但重提它的原因,主要一些操作體驗需要拿來做對比。那時的PSV,左右肩健各有一個,也就就沒有所謂的L2, R2 (ZL, ZR),左右有類比搖桿L3, R3,所以當時完全是一個比PSP的進階替代品。筆者也對PSV有很高評價,因為它的重量、續航性、軟件穩定性,都對得起筆者的期待。亦因此,筆者對於第一期的Switch,都認真失望。不過Switch最後卻成為筆者現今最支持的平台,這亦主要是因為它的重量、續航性、軟硬件穩定性。 今期算是第一期,筆者就先從Switch、Steam Deck、Mobile的重量、型狀,來影響它們的便攜性。也因為一些外置設備影響,重量、續航性、軟硬件穩定性自己都會互相影響。 最輕的一定別無他選 - Mobile 各大手機,在成型設計上,沒有預設手抦,所以一定是最輕的。但前題是你的遊戲對捽MON(搓玻璃)有做優化。現在很多競技手遊,已經發展出一套相對可以接受的捽MON設計,一些跨平台移植的PVE遊戲,亦都盡最大努力地加入附助機制援解捽MON下的不便。 但但但但,如果你需要真的最佳化操作體驗,Mobile配手柄的話,就不一定是最輕的選擇。在最入門的情況下,買一個很經濟的手柄,配上支架,你就可以把手柄、手機一起拿著玩。但問題是這會直接影響重量。最入門的選擇,手柄的重量通常都不輕。如果你配上一體式支架,手柄托著手機,就完完全全可以重過一台Swtich。有一些極致的手柄,可以很輕,合來會比Switch還輕。但這種很柄依然還有一個很大的天敵,就是不能與手機套共存。每次使用手柄,都要拆一次手機套。而手機套的設計,通常都是易裝難拆(這樣才能保證不便隨便跌出來),所以那怕你的手柄多輕,但每次你都要東攪西攪,便㩦性大打折扣。 結論是,若果你需要輕,而且即開即玩,你就要接受捽MON的選擇。你需要精準操作,就不能要求即開即玩。 巨無霸 - Steam Deck 如果大家有一直接關於外文媒體,有時候你會看到它們評價Steam Deck的重量為:「沒有你想像的那麼重」。 That is fake!!!!!!! 老實說「沒有你想像的那麼重」,只能在你沒有比較對像時才能說得出口。在配上外設手柄的手機情況下,我已經覺得重,怎麼可能這台Steam Deck不重?抱著這台Steam Deck到處走,真的不容易。你想通勤期間想拿出來玩玩而整天背著他,不能說是很化算。你連續拿著玩個三十分鐘,也不是很好受。 不過筆者依然會覺得它有存在價值,主要是它可以帶著PS4以上的品質遊戲到處走,那些重量,是可以接受的。魂系遊戲、Capcom動作遊戲,也只有Steam Deck才能提供。想到處可以刷一場爽快的動作遊戲,有60fps,聲畫特效都打開,那是多麼美好的一回事。更重要的是,因為快餐打個兩、三場,也不過十五分鐘,電量不是筆者最大的問題。它預設的手柄按鍵也夠用。所以筆都會把它排在手機更高的評價。(據說其他Windows掌機,更重、更耗電,很難想像它們還是走便攜路線) 結論:重,但可以滿足你的聲畫需求。 中規中矩 - Switch Swich在預設配件的性況下,不重,除非你拿著玩超過一小時。Switch平常最多人投訴的是Joy-Con手感問題。筆者覺得這是官方的一個合理選擇,對比PSV,什至更舊的設備,Joy-Con不算手感差。最影響體驗的,其實是它易壞的問題。大家聽得最多的,是它搖桿的漂移問題。但其實還不止,手柄充電、接觸配對,都是可能出現問題。但老實講,手柄屬於消耗品,再加上Jon-Coy的內部的設計比同等體量的手柄要複雜,如果兩年換一套Joy-Con,不能說是不合理的。 扣除Joy-Con的成本差異性後,基本上它的重量很適合隨身攜帶,而且手感可以接受,它也有齊各個功能健、陀螺儀,在極致的體形下做出全功能的手柄,玩動作遊戲也是可以接受的。加下可拆性,就算壞了手柄,不用整台送修也是一個優點,找第三方手柄也是一個選擇。 結論,在於通勤的情況下,在原裝的情況下,就極快地從待機到進入遊戲,那是極重要的一件事。而且重量不重,每次帶著四圍走都不是問題,這也是它的面對碎片化時間之下,還能有高開機率的原因。 (最後筆者選了一套重量、價錢都合理的第三方手柄,它主要是不能當成無線手柄使用。但價錢便宜,而且手感更好,而且重量不會暴升。) 重量的綜合體驗 由可接受的重量範圍,Switch的便攜性最高,其次就是mobile,但在衡量重和按鍵的操作性,Steam deck 比mobile讓筆者更有遊玩的意欲。 下期,筆者會再從續航性方面去討論對於便攜性的影響。

澳門IT教育 | 到底現在缺什麼?

科技新知
MacauYeah・2023-11-10

筆者最近跟朋友聊天,也剛好在進修,談到一些IT知識的傳播問題。進修課的導師,或更廣泛的教育機構,都很積極地宣傳,人必需經常upgrade自己,接受新知識。而不同的導師,就是用不同的方式,去介紹新知識。而最普偏的知識傳播方式,就是人與人之間有溝通。 溝通,好像好實制好有效,對不對? 對。溝通是很易的,不過掌握知識,是很難的。所以阻礙大部份人持續進修的原因,其實是實踐知識的成本,包括時間、空間、金錢。但最近在接觸一些大公司的官方課程後,至少在software上,都有遠端的實驗環境。 Cisco 在多年前就有提供Packer Tracer,可以模擬一些網路情況。雖然不多,但至少可以實作打command。Oracle、SQL Server,現在除了提供免費的開發版本多,還有提供docker版本,希望把本地初次安裝的問題也解決了。Oracle的官方班,還會提供雲端的預安裝版本,你就可以省下本機資源做其他整合測試。寫程式方面,在早期,為推廣Web Frontend開發方面,已經有JSFiddle,很多朋友要試code,要做POC,都可以直接跑起程式看效果。這些,都是推廣IT知識的良好切入方式。 近年多得VM、Docker、VSCode,即使Web Backend,什至是Binary program,也完全可以提供遠端的實驗環境。良心的Github、GitPod,還有提供一定量免費的VM、Docker服務,你想把整個IDE放上Cloud,真的不再用像筆者以前要自己研究的CodeServer,用它提供的就好。不過遠端的環境還是有限制,例如你需要模擬硬件,或是需要很健全的測試環境,例如frontend backend cookie domain rewirte,又或是需要健全的除錯工具,都還是要等等。 好多事,雖然不能馬上上production,但look and feel,是吸引新朋友加入的重要關口。現今澳門IT的教育發展,就是總是留存在實體課,去指定的教室讀者PT教材,使用指定機器。若導師準備充足,就還好,可以順利實習,邊聽講解邊做實驗。頂多就是上課時間、地點不夠便利。但預者有一些老師不備課,食老本,Lab沒有提前預習,做live demo時才錯誤百,修正錯誤的時間成本很高。若要想更多人持續接受新事物,就必需要提供足夠多的可以實操的Lab,而且要可以自行重複。 對於澳門IT教育機構,希望可以提供更多的網上資源,讓學生可以解放地點和機器的限制。對於現在的IT/Software的從業員,希望大家都可以擁抱Docker/Linux Container,這樣才能最低成本地試用新事物。

Spring官方教學 | Spring Certified Professional 2023

科技新知
MacauYeah・2023-11-07

筆者作為一個網頁程式開發者,使用Spring Boot開發已經有六年。從當初Spring Boot 1.x開始,查看官方Tutorial七零八落,慢慢摸索,到大改版升級2.x,都碰過不少釘。最近Spring Boot亦要升級到3.x,正式進入Java 17時代。筆者亦不斷Update自己,保持程式於一個可支援的狀態。 相對以前,現在入門Spring Boot已經比1.x年代輕鬆很多。主要前些年某些網頁開發的概念,例如REST API,已經深入行業,大家不再糾結要走傳統MVC還是RESTFul API,也使得Spring Boot這樣的Framework,可以有一個受眾比較廣的統一入門教學。 筆者最近也正式參與Spring Academy的官方教學,好好地厘清一些概念。 官方連結 https://spring.academy/paths/spring-certified-professional-2023 在讀過官方的幾個章節後,真的覺得很適合有興趣的人去看一看。主要是因為: 官方以一個經典例子作為切為點,教學REST API,In Memroy Database。它還介紹了一些簡易的HTTP Code Standard、Test Case。真的比其他民間教學更有系統性。 提供一個可以在網頁上就實驗到的Lab實習環境。那是極為重要的一件事,因為九成人,在setup java 及library dependency (maven, gradle)時,都碰釘到直接放棄。有時是因為公司工作環境比較有要求,並不允許你使用一鍵安裝的java套件及它的library dependency;有時則因為網路安全,java把你公司的firewall當作a man in the middle (MITM) attack擋了,也有時是因為你公司的firewall把java擋了。Spring Academy在一個遠端的https網頁提供實驗環境,真的比本機開發要易入門很多。 Spring Academy可要多謝vscode、code-server,及其他VM、Container技術。 在真實環境中,筆者也有自己的code-server,打包java / os cert等等,盡量減少firewall問題。 因為官方教學持續以Spring boot的最新版本作為教材,它更新的速度總比民間要快。只是官方的教學不會全面覆蓋到所有Spring project。如果大家作為Web入門的話,還是有推薦的。 在Spring boot 3.x當中,因為要求Java 版本至少為17以上,那些教材也有使用一些Java 17的新語法(Syntax),實在也令人驚喜。 基本上Java 17現在可以簡化getter / setter / switch statement,這些在開發Web的環境下都是很重複的事。在Java 11或以前,只能經過IDE去生成getter / setter等,但似始都有會一大堆Code佔據你的頁面。 官方教學及Lab環境暫時免費,除非大家很在意的修業證書,不然都可以自由免費看。 官方教學真的值得一看,雖然距離真正開發還差很遠,筆者日後若有條件,會針對官方沒有提及的內容作補充,分享一些在技術面上所需求的最少可運行配置。

Coding | Test Case 值得寫嗎?

科技新知
MacauYeah・2023-11-02

很多做軟件開發的朋友,其實都會聽過Test-driven的開發模式。就像Scrum一樣,名氣很高,但試過的人很少。為何會這樣呢?筆者認為,並非開發者懶,而是編寫Test Case的難度真的高。對比開發程式本身的成本,寫Test Case的時間/學習成本一樣高。 造成這些高成本的原因很多。一來是因為開發者並不像過往一樣,慢慢從零寫程式,一般都應用Framework去預構建一些東西,例如打包Database connection pool,Dependency injection。Framework是好用的,但就令你要模擬Mock up特定資源,變得越來越複雜。所以一般中、小型開發,都鮮有人懂得做Test Case(除了大神獨立開發者外)。筆者對於Spring boot等Framework,都摸索了很久,才能模擬一些特定資源。但Framework一更新,就很多部份都要重寫。所以筆者沒有很強調要做Test Case,因為成本認真大。 最近,在摸清一些test case 基本concept後,筆者又重新開始嘗試編寫test case。以下假設用的是object oriented programming 在開發自己的class,為每個public function,都寫test case。很多IDE, 都有提供相關自動生成test case function signature的功能(就是為你的目標function,起一個只有外框的test function。)vscode雖然不是原生支援java,但只安裝基本的java test package,就可以達到同樣效果。 在不依靠framework的情況下,自己class要『引用』的其他class object,不要經過自己使用new來生成object。全部經set function來傳入你要引用的class object。除非你的class是作為Factory Pattern(工商模式)生產某些object,不然你就不會再有new字眼。 在為自己class編寫test case時,就會可以模擬被『引用』Object的行為。這個object在傳統上可以使用oop中的interface類型來達到模擬又不會影響到原結構的做法。實在不想做interface,java還可以用mackito 這個libraray來硬改Object的行為。 同理,自己class要『引用』一些外部資源,那些設定資源的config,都應該要set function傳入。這樣你在test case中才能起一個臨時的模擬外部資源。 在不使用framework的情況,要全數去自行模擬,當然很痛苦,但至少你可以做一些很簡單的測試。 在使用framework的情況下,還有些教學都是教你mockito繼續模疑。但這會是很痛苦的,因為這樣叫做unit test,單元測試,你要模擬所有東西。在折衷的情況下,應該底層元件做unit test,但上層的元件就做integration test,整合測試。 在做integration test時,就差不多等同使用framework行起部份或必要的資源。而那些必要資源,可能指是的database service, network service。我們可以在test case中設立不同的config,從而把framework指向一些備用資源。 Database好貴,腦細不會付錢set up多一套,自己電腦不夠強,也不能跑起多個開發用Database。好在還有h2 database可以幫你,它是memory可以操作的。只要你的framework支緩就好。在初次使用Framework時,你總會覺得為何Database層要設得這些抽像,其實為的就是讓你可以隨時換Database。不論做測試還是做移植,都會少很多問題。 模擬Network service還是沒有銀彈,要麼就mockito硬改行為,要麼就是提供一套測試用service。筆者曾經為模擬別人的Network Http API,也花了相當時間自己建立dummy server,提供模擬效果。無論dummy的效果有多假,有多局限,例如if id == 1,always return true,也是有一定價值。當你做source code refactoring (重構),又或是做framework升級時,還是讓你可以安心一點。

今時今日,課金手遊值得遊玩嗎?

手機‧電玩
MacauYeah・2023-10-20

原本筆者想做一個掌機遊戲 - Switch,Steam Deck, Mobile Phone的詳細對比,但最近手機的手遊真的讓筆者有太多感受,所以筆者先直接聊一聊遊戲機制問題。 說實話,手機 - Mobile Phone這個載體,一定是受眾最廣的。非競技類免費/課金遊戲讓大家最開心,下載不用錢,開局刷首抽,不課也開心。而對於鍾情遊戲,用課金買資源,理應亦是符合輕、重不同情度的玩家。走一次性買斷路線的遊戲,也適合無網路情境。 免費/課金遊戲又分兩大類,一些是買消耗道具,提供提示或額外資源,一些就是抽獎制,把某些特別資源限制在低機率的彩池當中。以最近的Monster Hunter Now為例,就是走前者路線。可以買回復藥或增加素材的道具,供特殊情境使用。以星穹鐵道為例,就是抽獎制,某些特別角色需要從彩池中抽出。 Monster Hunter Now鼓勵大家走出門,多去一些不同的地方,原意是好的。星穹鐵道設定階段等級上限,讓特殊角色跟普通角色差異有個限度,原意也是好的。上述兩個例子,都是鼓勵大家享受遊戲基礎玩法,不需要每一刻都想著課金問題。而筆者心中的強烈反轉點,亦是因為玩了這兩款遊戲,才爆發出來。 手遊發商始終要找到收益的來源,所以通過設計一些心理關口,等玩家忍不住的時候,就課金下去。營運需要金錢,合理回收成本,大家都應該可以理解。筆者對於之前一款競技手遊,也本著支持支持的態度,去課金兩三輪。因為遊戲課金目的很明確,就是提前解鎖指定角色。筆者課出去,亦玩到想玩的角色,大家都合乎預期。 但問題是MHN和星穹,雖然看似課也能玩,但實際上,兩者玩下去都很痛苦。MHN的資源囤積速度很慢,選錯武器走錯開發路線,想換武器就得花相當大的時間成本。即使課金,也不能取得指定武器素材,也不能指定出現的魔物,使課金的確定性變得很低很低。 星穹也類似,遊戲原本就有每日取得資源上限。課金可以抽多個角色,但無法讓你重塑角色。在資源有限的情況下,你不單要考慮養那個角色,還要考慮養哪個技能,壓力也真大。到後來,可能你更在意資源收益,去猛翻功略找養成策略,而不是去研究過關機制。 這還引伸另一個問題。我課金,為了更好地享受遊戲,隨時想玩就玩,忙的話,就先不玩,有時間,就多玩玩,但上述兩遊戲都不行。MHN課金道具染色球,亦需要玩家無時無刻打開遊戲,在指定的時空標記魔物。有空想多打兩場?不行。星穹的課金模式還有分一次性和月票制。月票制雖然每日資源變多,但你若很忙,沒時間玩,那天的資源就會浪費掉。之後即使你很閒,也不能多玩。 或者有人會說,無限課金不就解決問題了嗎?但這樣的話,筆者寧願支持買斷制遊戲,至少一次性付費之後,不論怎樣重塑,也是在連續的時間內可以重來的事,再加上對機制上的熟習,多次重塑的時間會會更短。 即使講了這麼多的不是,上述兩遊戲還是相當出色的。MHN以動作遊戲規格來看,是非常能發揮手機的便攜性同時能以最直觀的方式去實作動作遊戲的刺激感。星穹的聲畫演出絕對是上上成,回合制戰鬥並不讓玩家覺得沉悶。但兩遊戲的問題就是課金收益讓人蛋疼非常。 或許,之後筆者還是會出一篇掌機遊戲大評比,但可能課金手遊就不在對比範圍裏面,能比的就只有一次性付費遊戲

Miffy米菲控必去-澳門上葡京MIFFY創意展

生活在我城
MacauYeah・2023-10-17

唔知點解上葡京會唸到搵米菲做主題,哩隻來自荷蘭的公仔一直低調地遊走唔到國家但係澳門真係比較少出現,但相信米菲控一定知道佢係荷蘭同日本有幾受歡迎!話說上葡京今次舉辦的MIFFY創意展由9月25日至11月12日係酒店舉行,場內唔同地方有超過100隻Miffy,還有 #Miffy主題下午茶、文創禮品、親子工作坊等,集打卡、美食、購物等等。 身為米菲控的筆者當然要帶埋佢個嫰B去探望吓咁可愛的米菲!! 周六12:00首先去到酒店大堂酒廊嘆翻個 “Miffy 主題下午茶”(費用:MOP268+15%,供應時間11:00至18:00)再加點一個大蝦意粉先! 落單後,係附近影吓靚相,之後好快等到飲品: 圖1. Miffy Latte OMG好靚好靚好靚呀!!!飲落還可以但沒有很驚豔。 圖2. Miffy Orange Ballon 香橙啡?!一望有點疑惑,但飲落特別可以哦!很香橙味的咖啡。 圖3. 大蝦意粉 一大碟,小小辣,味道OK 圖4. Miffy吐司配雪糕 終於等到最期待的吐司,看着很美嘛,食落…..外皮不脆,內里算軟,但除了上層有雪糕味,包有包味外,應該算是有點失望…… 圖5. Miffy朱古力焦糖撻 很美~~表面是甜甜的焦糖,下層是濃濃的朱古力,很甜甜的一道甜品 圖6. Miffy甘筍蛋糕 嗯~以經有點飽,但咁可愛一定要試,係清香的甘筍味,蛋糕很軟。 食到一半,可愛的主角米菲登場,係場內大方同大家影相呀! 嫰B更然立即衝埋去影相同摸摸啦~~~ 總結:兩大一小食哩個餐+一個意粉有點多,建議單點自己想食的都很足夠不一定要點餐,但米菲控叫一個主題餐是常識吧?哈~ 食完仲可周圍行吓,場內仲有好多不同大小設計的米菲公仔同精品,歡迎大家一齊黎同米菲見個面哦~~~ 資料補充: 上葡京官網 https://www.grandlisboapalace.com/tc/restaurants-n-bars/glp-lobby-lounge 餐廳不可預訂, 餐廳登入澳娛會員有95折(可以提前登記) https://supremecard.sjmresorts.com/tc/my-membership

SCRUM:用一半的時間做兩倍的事

科技新知
MacauYeah・2023-10-13

這個假期,筆者沒有再去寫Code增值。取而代之的是看看書,吸收一下新思維,把頭腦好好更新一下。機緣巧合之下,翻開了早在幾年前就讀過的書《SCRUM:用一半的時間做兩倍的事》。當下心頭一陣心酸,為何SCRUM明明是資訊行業裏面的表表者,但自己在實踐上,就總是無法應用?所以又重新讀了一遍。 先講講SCRUM是什麼,SCRUM是暫件開發上的一種迭代模式,它有另一個名字,也是我們更常聽到的是【Agile-敏捷開發】。它主張的是以最短的時間,造出最少的實際產品,讓客戶真的可以驗證當初的需求是否合理。而不是像瀑布式開發,先做好最前面,再做中間,再做最後面,然後再等客戶總體驗收。非科技業的朋友,可以想像成是ISO 9001機制上Plan Do Check Act。 理論筆者就不講太多了,筆者直接就講講實務上的問題。 首先,你要有一個團隊。沒有團隊你就不能在相互幫忙的情況下得益 但不是坐在同一辦公室的就叫做團隊,大家要真的一起協調,大家的目標和時間上可以協調,會一起幫忙解決他人問題的才叫團隊。所以,大部份情況下,當公司為了方便管理,都希望一個人負責做一個Project,每個同事是自己的project的Team Leader,這就沒有了緊密合作的意義。 你要有做專心做同一Project權限。這樣你才不會因為分心,因為做轉換,而浪費時間。 但基於公司營運,接新單新Project一定會天天都接,即使同事手頭上舊單未完成,都要強行跟同事加入新的工作說明,著手新Project的酬備。主要是因為平均分配各個客戶的期待,每個Project都要定期交點東西出來。公司也認為每個Project不可能一口氣進行下去,總有些時候是要等客戶、供應商回覆,轉換Project才不會讓同事閒著。 你要有心力去解決實際問題,讓你工作越來越順暢。這樣才會越做越快。 但問題總是每日新鮮,特別是你每次都要接觸新事物,解決方案亦不是一天就可以想到,所以會讓人失去衝刺的熱情。 運用了SCRUM/Agile開發後,應該可以走少很多不必要的路。 但其實只有你在基礎能力都很超班,新事物都不用掃雷,你才會有可能覺得少走點。就以軟件開發來說明,若你沒有自動化的CI/CD的伺服器,每次都要花很多時間才完成發佈,你想讓客戶驗收新功能的頻率一定很低。你的同事連SVN/Git都不用,你想取用他人的新功能來測試的難度也很高。你的開發環境沒有分為開發/測試/驗收/上線,開發時改爛了就根本無辦法Rollback。及早驗收這不是代表你做錯事的機會變少,只是提早一點知道,讓錯誤不會繼續延伸下去。因為要重新改造而花掉的成本也是很明顯的。 一切一切在重讀《SCRUM:用一半的時間做兩倍的事》時,筆者也看到一些人生的希望。 若沒有團隊,但只要堅持專心做同一個Project,單人團隊也是一個可以嘗試的方向。當你專心做同一件Project,你會少了轉換成本,也不會感到同時多個Project的爛尾感,更容易累積信心和成就感。 當有問題真的解決不了,不是轉換Project,而是面對問題,要麼Workaround,要麼就解決它,把新增成本交給客戶/老闆做決定。因為Plan Do Check Act的週期性,即使不是開發出完全滿意的產品,至少客戶都有部份功能可以用,也驗收過。公司收帳也應該跟開發期週期掛鈎,驗收過了,就收回開發費用。雙方有意見,不願意繼續開發,就按照剩餘未開發的部份收取解約金。以醫院的收費模式來舉例,一個慢性病,不會一下就可以治好。每次覆診,都會獨立計算診金,病人不願意繼續,可以選擇轉醫院;自己認為足夠了,也可以不再去覆診。 如果客戶/老闆沒有因為堅持最初的合約一字不改,後續因為分歧而產生的負面情感也沒有這麼大。有些問題,可以及早止蝕,對公司與客戶都好。作為員工,在中間做磨心的情況也可以減少,不必為一開錯誤的開頭而繼續走下去。

Steam Deck With Podman

科技新知
MacauYeah・2023-10-06

Steam Deck With Podman 眾所週知,Steam Deck預裝的是一台Linux主機。但它的系統比較特別,為了可以安全更新,所以系統最主要的部份都設定為唯讀(read only)。也就是,傳統你可以直接在Linux上經管理員權限安裝的軟件包,全部都會被擋,即使你把唯讀部份設為可讀寫(read / write),在下次更新時,都會被一次過覆蓋掉。 筆者作為一個負責任的機迷+開發者,怎樣可以白白讓一台Linux機只可以玩遊戲呢? (怎樣跟老婆交代呢?) 所以筆者千辛萬苦,找到一個折衷方案,讓他可以當為開發機使用,那就是Podman。(當然,若果大家有條件有金錢,直接改裝Windows就可以了。) Podman是什麼? Podman跟Docker一樣,都是一些管理和運行Container的主程式。跟Docker不一樣的是,它是Open source,而且是daemonless。 所謂的daemonless,就是不會有一個背景程式去長期管理Container。好處是不會因為背景程式死了,就全部Container一起掛掉,預設也不需要走管理員權限路線。但也因此跟Docker有一些使用上的差異,例如Podman沒有原生的docker-compose結構,即使坊間有python寫的podman-compose去硬對應docker-compose,但某些network是跟結構還是不能直接從Docker轉移過來。 就筆者早期的踩雷經驗而言,用Podman跑起一兩個獨立固定Port的Container來說,都很夠用,也不會遇到奇怪的Bug。所以這次,亦用來作為Steam Deck運行整合式開發的Container。 不平凡的安裝之路 install homebrew Steam OS 3,雖然可以使用更改read / write,再使用pacman來安裝podman。但因為Steam OS更新後,全部要重來,工作量和網路流量都不少,所以筆者改為使用homebrew來安裝podman。homebrew只需要首次安裝時使用管理員權限,之後就會在/home資料夾下留下可執行的程式,所以它不會被Steam OS更新所破壞。 install podman 記得記得重新開機,之後應該就可以成功運行container