金幣、鑽石、寶石、水晶？

大家都已經知道的理由：為了混淆遊戲貨幣跟現實貨幣的對價關係。但是其他的沒有辦法用現金換貨幣的遊戲呢？

Triple Town 作者 Daniel Cook 的看法：

這樣比較容易平衡遊戲經濟。每種貨幣可以對應到某個遊戲面向，如果那個面向經濟效益太強大，只要調整那種貨幣的產出跟消耗就能解決，而不會影響整個遊戲。

更容易設定玩家目標：每種貨幣都可以清楚的提示玩家目標跟他目前的進度。

讓玩家有數個清楚的發展路徑：貨幣即是進度、如何有效產出貨幣則是玩家的策略。如果全部只有一種貨幣，發展路徑也被全部混在一起，徒增玩家選擇的障礙。

當然，多種貨幣會讓遊戲變的比較複雜，不容易上手。但是 Game-as-Service 的目標是要提供數百小時以上的遊戲時間，這樣的經濟系統是讓熱情玩家去鑽研用的。同時，這樣的系統也容易凝聚遊戲社群，讓玩家一起解讀。

先說結論，我用 OmniFocus 用了五年以上了，目前依然滿意。

現在的生產力工具實在太多了。為了在焦慮的身心與環境中活下來，我試過許多工具，看到 Bruce 討論到，分享一些心得。

快速的收納臨時出現的想法跟待辦事項。

現實中大部分的事情都是突然想到的。吃飯時突然想到一則文章的標題、工作時想到明天是老婆生日要買禮物、買咖啡時想到苦思許久的 bug 要怎麼解。

這種時候，能快速的收納這些小事就很重要。GTD 很重要的 Inbox 觀念便是如此：清空腦中那些大量漂浮的雜事。收納的門檻越低，越能保持頭腦清楚。

OmniFocus Mac 版的全域熱鍵跟 iOS app 都能達到這個目標。

快速的看到需要做的事。

重點是「看到」而不是「搜尋到」。待辦事項應該在收納時，或是每週 review 時整理好。平時應該要能直接「看到」當下可以做的事情。而不是花額外的力氣去「搜尋」出要做的事。

以 OmniFocus 而言，就是用 perspective 去彙整 Tag（以前叫做 Context）。

準備一個叫 Low Energy 的 Perspective，在腦力不足但是又睡不著時，可以找點雜事來做。

或是一個叫 Writing 的 Perspective，在滿肚子牢騷不想寫 code 時可以直接找個主題來寫。

隱藏不該看到的事項。

這點我覺得是很多工具漏掉的部分。

在現在高度 context-switch 的環境，人腦早就被訓練的極易分心。如果沒有一個獨立的輸入介面，導致輸入資料時會看到其他不相關的事項，這些都會造成額外的腦力負擔。原本只是要記下購物清單，結果剛好看到明天有個會議要開。好不容易從腦中清掉的資訊又再度回到腦中，徒增焦慮。

而 OmniFocus 的輸入介面夠乾淨，不會看到額外的資訊。整理的功能也夠完整。輸入之後不需要另外搜尋，該看到這些事情時自然就會看到。

—

不過，生產力問題本質上是個性問題，不習慣的方法也不用強求自己，那也只是徒增焦慮而已。

在系統中遷入一個動態輕巧的 scripting language 一直是個常見的設計。像 Rust 這樣的系統語言，雖然效能好，但是上手門檻較高。這時若是能遷入一個像 Lua 一樣動態型別，簡單易懂的語言，便能大幅提高系統彈性。

最近為了實做 actix-lua，研究了一下 Rust 跟 Lua 之間的介接，順便學了不少 Rust 跟 Lua 的設計，筆記在此。

Lua Binding 的選擇

Rust 現在有數套 Lua binding，比較常被人提到的是 lua, hlua 與 rlua 。

lua 基本上是直接把 Lua 的 C API 直接移植，沒有做多餘的包裝。所以需要絕對的效能的話，這可能是你的最佳選擇。不過安全性跟 UB 就要自己處理了。

hlua 提供是比較高階的介面，不讓你直接存取 Lua Stack， …

遊戲開發對很多開發者來說是個陌生的領域。遊戲對於效能的極高要求跟規格的不確定性，產生出了許多特有的系統架構。Data-Oriented Design 便是個有趣的設計模式。

相較於其他設計模式，Data-Oriented Design 深受硬體快取（cache）架構影響。對於現代的高度 pipeline、高速的 CPU 架構而言，資料的存取方式對效能有非常大的影響。比起 L1、L2 cache，對主記憶體的一次存取帶來的是數百倍的效能損耗。

為了避免太過抽象，就用個實際的例子來解釋吧。

假設我們的遊戲中有許多的球，每個球有顏色、位置、半徑等等資訊。對於學過物件導向的人而言，很可能直覺的設計成這樣：

class Ball {
 Point position;
 Color color;
 double radius;
}

這樣的作法很符合人對世界的理解：每個球是獨立的個體，有自己的屬性。

不過，如果遊戲中有數百萬個球在移動，這樣的作法的效能就不太好了。每個球的座標都經過物件導向的層層封裝，分散在記憶體四處，spatial locality 非常差，在更新的過程中產生了大量的 cache miss。

There’s no ball

如果採用 Data-Oriented Design 的話，作法會變成：

class Balls {
 vector<Point> positions;
 vector<Color> color;
 vector<double> radius;
}

於是我們的程式中不再有「獨立的球」這個設計存在，所謂的球，只是透過一個 index，含蓄的存在遊戲世界中。

這樣的作法，對人而言並不直覺，但是對硬體而言，效能好上許多。大多數的 vector 實做，都會將其中的內容放在一段連續的記憶體空間中。因此 spatial locality 很好，對 CPU 而言，他能很輕易的猜到接下來要存取的記憶體位址，省下許多猜錯而損失的 CPU cycle。

SoA 與 AoS

這兩種作法又分別被稱做 Array of Structs 跟 Structs of Arrays。前者是用一個陣列存放許多獨立的 struct（class），後者是用一個 struct（class）存放許多陣列。

實際開發時，很難臨時在這兩種模式中轉換。對程式而言，model 遊戲世界的方式完全不同。所以常常一開始用了直覺的 AoS 開發，發現效能不好，需要換成 SoA 時卻無從下手。

遊戲開發在介面設計跟系統架構上，都有很多很經典的範例啊…

第一次看到 Studio Moniker 的作品，是個叫做 Do not touch 的群眾外包式的 MV（？），透過記錄瀏覽者的滑鼠軌跡，共同創作出 MV 的內容。

MV 中隨著音樂，不斷出現指示，例如要求游標指向你的所在地、你想去的地方、要你跟著綠色指標移動…等等

比起單純的，工廠式的群眾外包。這樣的協作方式更留下了個人風格。大多數的滑鼠游標都是乖乖的依照畫面指示動作，也有些游標刻意反其道而行。

當畫面出現裸女，即使指示寫著「不要遮住她」，許多游標也硬是要幫畫面中的人物遮點。

當無數的游標跟隨著畫面上的指示流動，群眾的本質也昭然若揭。

—

Studio Moniker 是個來自阿姆斯特丹的互動設計工作室。作品大多以科技與群眾為主。與許多知名組織都有合作過。像是與 Mozilla Foundation 合作，為網路中立性而戰的 Paperstorm.it；以及與 Google Data Art Team 合作的，在 VR 空間中協作舞蹈的 Dance Tonite。

Conditional Design 是他們所提出的設計宣言：與其被媒體所限制，他們選擇透過制訂規則，讓參與者在共通的規則下自由發揮，來產生出各種奇妙的成果。

怎樣的規則呢？譬如與 Yorkshire Sculpture Park 合作的 sculpture.cam ，他們替公園中的雕塑各準備 120 張不同角度的剪影，讓遊客自行對照剪影，找到正確的角度後拍照。便得到了由群眾協作而成的雕塑的 3D 模型。前述的 paperstorm.it 也是透過單純的「散發傳單」這個動作，讓人自行在地圖上塗鴉。

獲獎無數的 Radio Garden 也是如此，透過簡單的將各地的電台呈現在 3D 的地球上，產生了一種新的探索各種實況資源的感受。原本各地從來不曾聽過的電台突然變的垂手可得。極簡的介面也讓探索的門檻大幅降低。

像是透過一扇窗，偷看當地人們的生活。也許那邊某個餐館正放著這些音樂，或是某個無法入睡的少年也正在聽著這個電台？

—

比起光影炫目的多媒體資訊藝術，這種低調、群眾的藝術更符合現代網路的狀況：被誘導的群眾、由細節透露出來的個人風格、以及網路特有的，不斷疊加而成的表現方式等，都是有趣的議題。

數年前被 Do not touch 衝擊後，意外在去年的 Dutch Design Award 又看到了他們的作品，從此之後再也回不去原本的世界了。

另外，他們網址的品味相當不錯，radio.garden、tonite.dance 跟 sculpture.cam 都是超棒的網址啊 XD。

一切都是為了效能

故事要從 boxed value 跟 unboxed value 說起。

所謂的 boxed value 是指：不直接存取 primitive value，而是透過指標來操作數值。近代的程式語言常常都用這種方法操作資料。而 unboxed value 就是指直接操作值，不經過一層指標。

以下擷取、修訂自 2018.03.29 我在 iThome Serverless All-Star 的分享的逐字稿

究竟為什麼要用 Serverless 呢？

近年，無數人嘗試著製作各種產品。每個開發者剛開始都是興致勃勃，大家都想改變世界，但後來都漸漸失去了熱情。為什麼呢？我觀察到幾個現象：

首先是「好程式」這件事，軟體開發者都想寫出容易開發、容易擴充、容易維護的程式，但是現實的環境往往沒有足夠的資源讓你慢慢開發。大多數的時間都在趕死線。

即使跟主管談，主管都會說「我們另外安排一個時間來重構」，但是從來沒找到這段時間過。於是，程式越來越難維護，開發越來越慢，開發者心情越來越差，產品疊代速度越來越慢，最後就失敗。

為什麼會有這種現象呢？因為軟體架構的價值實在太難量化了，每個工程師對架構都有不一樣的想法，也不一定能好好掌握架構的知識。連工程師都難以捉摸的東西，更不用希望非專業的人能理解了。於是，軟體架構永遠都是第一個被犧牲的。

不過，在 serverless 中，軟體架構的好壞直接表現在你的營運成本上。軟體架構好，執行的速度就快，消耗的資源也少。因為 serverless 是按照 function 使用的資源來計價，這些變化就直接對應到帳單上的費用減少。原本被視為「無生產力」的重構行為，也變成人見人愛的 cost down 行為。好的開發者跟壞的開發者的差別，也能從執行上的成本一目了然。於是，開發者有更多的籌碼去談出一個優化架構的空間。不是每個人都能看懂軟體設計，但是一定看的懂帳單上的數字。

再來是「好產品」，一個產品要符合用戶的需求，才能在市場上生存。但是，軟體的開發過程讓人難以專注在用戶需求上。規劃專案時，大多數的時間都花在「技術規格」、「時程」上，規劃會議上，大家就在一張紙上增增減減，最後妥協出一個實做清單。為什麼會這樣呢？

我認為是因為開發時，讓你分心的東西實在太多了。一個功能不只是一條 SQL，還要考慮資安、擴充性、如何 deploy、如何維護。這些額外的考量，都讓人無法專注在用戶需求上。有人的說法是「從一條 SQL 到上線的距離有多遠？」以現在的環境而言，真的很遠。

而 serverless 把系統架構跟技術細節幾乎都藏起來了。以前，寫一個 function 要上線前，要考慮怎麼 deploy，可以撐住多少流量，資安、監控、日誌、等等無數的細節。現在，只要寫好 function 就可以直接上線，其他的細節 serverless 平台都幫你做好了。產品開發速度更快，開發者需要擔心的事情更少。大家可以專注在同一件事：「用戶的需求上」。做出好產品的機會更高。

把 serverless 結合 tracking 之後，更可以做出更精細的產品分析。將整個使用者的使用流程，轉化成一連串的成本，與最後預期的收益一比較，馬上可以看出：是該優化轉換率，還是優化流量，或是優化某個特別消耗資源的 function？產品方向不再是瞎子摸象，而是更明確的流程。

最後是「開發費用」這件事。軟體開發的成本始終難以預估。時程與需求的變化，讓定價變的很困難。以外包而言，報價永遠是最難的事情。今天客戶需要一個產品，一家估了 100 萬，另一家估 10 萬，其中的差別究竟是什麼？對客戶來說幾乎沒辦法判斷。所以外包總是很容易做不出需要的東西，或是充滿了浪費。維護費更是一個人人都討厭的東西，開發者永遠覺得維護費太低，客戶永遠覺得他的維護費浪費了，怎麼算都有人不滿意。

serverless 提供了一種新的外包計價模式，按照用量計費。因為 serverless 的成本透明，所以開發者的營運成本也很透明。這時按照用量計費，讓雙方都有共同的誘因去優化產品：最大化產品價值。產品使用量越大，開發者收益越高，用的人越多，客戶就越開心。

說了這麼多，其實 serverless 代表的就是把計算力變成 utility 的一個過程。就像水電一樣，大家都需要的東西，規模化到最後，就會變成付錢就能解決的東西。使用者需要介入的越來越少，成本標準化，使用者不再需要搞懂各種規模化的技術：像是 docker, devops, capacity planning, cloud 等等。維運變的更簡單。如果你的環境還沒跟上這些技術，那就跳過他們直接開始用 serverless 吧。

You need “Productivity Hack” to achieve more, they say.

“Biohack” your intelligence with drugs, or become obsolete, some founder claims.

Technologists are crying about a future where human will become the slaves of AI. And the solution they provide, as usual, is more tech.

People in the silicon valley always think technology is the solution of everything. People who live in the woods will tell you that human is both the problem and the answer.

Forget about all these hacks. Think, talk, and understand yourself.

Understand the problem(you) thoroughly before applying a solution to it. It’s the 101 of Engineering and also 101 of being a happy person.

People who advocate hacks before understanding the problem are bad engineers anyway.