Studio Irregular

半路叛逃 App遊戲製作人的1000日告白

2012-10-05T01:55:00.001+08:00

邦妮的早午餐遊戲團隊的夥伴，半路，出書了。書中分享了半路離開遊戲公司，獨立工作開發遊戲將近三年以來的心得。十萬字，兩百多頁，沒有浮誇的炫耀成就，也沒有成功必勝的“秘密”。只有一點一滴累積的心路歷程。

不知道一般人怎樣看待出書的作者，有的人可能覺得為了賺錢，更多人覺得為了名聲。我一開始只覺得，很辛苦。如果是為了錢，專心開發遊戲可能更為實際。為了名聲，嗯，有可能，我覺得想要變得有名，沒什麼不好，有名之後可以做更多好事。但半路，怎麼看都不是這兩者。

台灣的遊戲界分享 know how 的風氣，還非常有限。我自己常閱讀文章與參考的資料，幾乎都來自國外。參加過的一些分享會，幾乎都是來自獨立工作者或是很小的公司在分享。如果我們分享所學的風氣一直停留在這樣的狀態，則大家永遠只能單打獨鬥，很難在如此高度競爭且全球化的領域生存。我想半路想做的，是分享所學，促進交流。

『傳統即將崩壞，在還有能力脫身之前，我必須離開』

書中讓我十分佩服的是第一章，半路能夠分析自己成長的年代背景，工作一段時間後感受到的限制，以及看到台灣遊戲產業的困境，這一切對一個三十出頭歲的人而言，並不容易。獨立思考，很容易說，但不容易做。那通常意味著你的價值觀必須與許多身邊的人有所衝突，意味著經常是處於與自己對話的狀態，意味著無可避免的孤獨（不是孤僻交不到朋友的孤獨，而是自古知音難尋的孤獨）。

和大家愉快地攪和在一起，輕鬆多了。

第三章描述獨立工作者都必須面對的，心魔。他非常誠實的描述了剛開始，那種時間完全掌控在自己的狀態下，很容易陷入的墮落狀態。看不完的動畫，玩不完的遊戲，越來越晚起床的早晨。然後是他如何立定微小但確實的目標，一天一天，讓自己慢慢脫離那樣的狀態。

另一個必然要面對的，就是挫敗。半路一開始規劃了一個很有野心的遊戲，一個關於遊戲製作人的遊戲（！）他找了當時認識的，還在遊戲公司上班的同事，想要一起做遊戲（這一幕我也經歷過），談了幾次，始終無法付諸行動。挫敗。好不容易因緣際會碰到了美術設計的夥伴，卻在投入三個月後發現，專案失去了方向陷入困境。挫敗。

這就是獨立工作者，經常身處的狀態。有沒有過這種經驗，你聽說某個傢伙正在進行什麼驚人的計畫，通常跟創業有關，然後過一陣子，就沒有下文了。雖然殘酷，但許多個人/團隊就是這樣消失在一個個的挫敗之中。想走自己的路，這就是你必須面對的日常生活。

第三章開始詳細的談邦妮專案！半路與樂風的認識，是透過一位在美國工作的台灣人，在書信往來之間無意中提及。我與樂風的認識，是透過我在前一家公司的一位同事，她後來到遠傳服務，剛好業務需要而牽起來的一條線。人生就是這樣，你永遠無法事先知道這些看似無關的一點一滴，會怎樣串在一起，只有事後回頭看才會驚覺之間的關聯。

『對於選擇走上獨立遊戲開發，或事業開創之路的人來說，『找到合適的伙伴』這件事，是遠比技術、資金、市場等等更難以克服的艱難問題。』

三四章有許多邦妮製作過程的秘辛，許多我也是第一次知道呢。

關於做App這件事，局外人最想知道的，通常是關於銷售的數字吧。這一點，半路異於常人的，坦白的，在書中公開了邦妮的早午餐 iOS 版本的收入。簡單說，扣掉粗估的成本後，這個專案賠掉了超過六十萬台幣！（Android 版本很可能更慘！）這是電視新聞和媒體網站不會報導的。如果是你，會怎麼做？

邦妮的早午餐是台灣少數成功推上三大手機平台的遊戲，其中 Android 在台灣地區透過遠傳電信發行，書中第六章詳實描述了我們合作下來的經驗。在考慮找發行商的朋友可以參考。（一定要參考！）

東西做出了點名聲，就會有人捧錢來找你。邦妮團隊一路走來，不少國內甚至國外的創投有來表達興趣。6 - 2 清楚描述了他們的嘴臉... 歐不，是他們的行事作風。來找你談合作，但連你的作品都沒玩過，夸夸其談關於股權結構，預期能夠量產創意。這些當然都是在商言商，沒什麼好批評的。只是半路或是樂風，如果選擇一口咬下某位創投送上來的蘋果，今天我們想做與能做的，肯定會受到很大的限制。很難得他們有挺住這些誘惑。

末章有半路對於遊戲產業趨勢的觀察，還有跑步的技巧（！）

書本看完後，我還是在想，遊戲社群會怎麼看待半路寫書這一件事。半路把自己的歷程坦白的寫出來，會讓猶豫中的人們勇敢往前踏出一步，或是更加的猶豫退縮？會讓其他獨立開發者嗤之以鼻認為成績也不怎麼樣，或是讓他們更願意分享自己的經驗，互相激勵？

今天參加了他的書籍分享會，我是覺得聽眾大多滿內向的，不像之前在創業圈子看到那麼踴躍討論，也許，是因為他的讀者多是來自部落格的讀者。希望有天能看到讀者與作者之間，在公開場合有更多的對話與更深入討論。

遊戲引擎 - 起點

2012-09-05T17:22:00.002+08:00

遊戲引擎由哪些基本零件組成？想解決什麼問題？是許多遊戲開發者會有興趣的問題，網路上有許多資料可供查閱，也有不少 open source 遊戲引擎可供研究，然而資訊量多，遊戲引擎也通常龐大複雜，初學者很容易迷失其中而不得要領。

我在開發第一套Android上的小品遊戲期間，開始研究 Android 上幾款 open source 引擎 / 遊戲：

有了第一款遊戲開發的經驗後，我開始自己的遊戲引擎專案，目的不是要做遊戲引擎生意，而是讓我接下來的遊戲專案能夠延用上個專案累積下來的經驗 / 程式：

tatala

隨著專案的進行，我打算把一些想法與經驗記錄下來，也與同好分享。

（關於個人或公司是否應該開發遊戲引擎，已有不少過來人討論過並且不建議這麼做。我同意。這邊我想做的是解釋遊戲開發面對的問題，與現行的解法，這些背景知識具備了，在使用起別人開發的商用引擎時，才能知其然又知其所以然，遇到了問題才知道往哪個方向解決。）

你應該先知道...

這篇文章是給程式設計師的，主題是移動平台（mobile platform）上的遊戲引擎設計。需要程式碼說明時我使用 Java，需要圖解時使用 UML。

討論限制在 2D 遊戲，使用 OpenGL ES（我熟 1.x，不過 AndEngine & libgdx 均支援 1.x / 2.x）。此外我以 Android 為開發平台，跨平台不在討論範圍。在程式語言，繪圖 API，運行平台這個層次之上，所有遊戲引擎都面臨類似的問題集（problem set），這些核心問題正是本文的重點。

核心問題：

1. 繪圖 / 狀態更新同步 (Graphics / Update synchronization)
2. 元件式架構 (Component based architecture)
3. 貼圖系統 (Texture system)
4. 訊息傳遞 (Event dispatch)
5. 觸控輸入 (Touch input)

1. 繪圖 / 遊戲邏輯同步 (Graphics / Update synchronization)

遊戲程式最基本的形式，是依序進行“狀態更新”與“繪圖”，如圖一。遊戲狀態包羅萬象，舉凡東西的位置 / 大小 / 旋轉角度等，動畫播放到第幾格，物件之間是否發生碰撞，使用者的觸控輸入，以及遊戲本身的事件等均包含在內。

圖一：基本遊戲迴圈。

圖一的作法可行，但可以改進。因為底層的系統通常有能力一邊用 CPU 運算，一邊用 GPU 繪圖。因此遊戲引擎的第一個門檻便在於：如何充分利用 CPU / GPU，並且協調這兩個工作單元，以避免擾亂了共用的資料。圖二描繪一種常見的做法。

圖二：修正後的遊戲回圈，圖中橘色區域為 CPU / GPU 同時執行的時段。

這個架構使用兩條 thread，其一利用 CPU 運算完成狀態更新後，其二利用 GPU 繪圖，兩者必須相互協調，盡可能重疊在一起，如圖中橘色部分。

1.1 實例分析

上面說的是理論，那麼實務上到底要如何平行處理繪圖與狀態更新呢？以下程式碼節錄自 replica island：

// Inside Android framework.
public class GLSurfaceView extends SurfaceView {
    private class GLThread extends Thread {
        private Renderer renderer

        public void run() {
            while(true) {
                // ...
                renderer.onDrawFrame(gl);

                // ...
                egl.eglSwapBuffers(display, surface);
            }
        }
    }
}

// Create by you, but run on GLThread by system.
public class GameRenderer implements Renderer {
    private DrawQueue queue[];
    private Object drawLock;
    private boolean drawQueueChanged;

    public void onDrawFrame(GL10 gl) {
        synchronized(drawLock) {
            if (!drawQueueChanged) {
                while (!drawQueueChanged) {
                    drawLock.wait();
                }
            }
            drawQueueChanged = false;
        }

        synchronized(this) {
            // drawing
        }
    }

    public synchronized void swapDrawQueue() {
        synchronized(drawLock) {
            // swap draw queue
            // ...
            drawQueueChanged = true;
            drawLock.notify();
        }
    }

    public synchronized void waitDrawingComplete() {}
}

// Create and start by you.
public class GameThread extends Thread {
    private GameRenderer renderer;

    public void run() {
        while (true) {
            renderer.waitDrawingComplete();

            // update draw queue

            renderer.swapDrawQueue();
        }
    }
}

這邊有三個角色，兩個 threads：GLThread 負責管理繪圖，GameThread 負責管理遊戲狀態更新。GameRenderer 實作繪圖，遊戲狀態更新的實作這邊先略過不表。這段程式碼可以這麼解讀：

GLThread 委派 GameRenderer 繪圖。
GameRenderer 利用 drawQueueChanged 等待遊戲狀態完成更新。
GameThread 完成狀態更新後利用 swapDrawQueue 通知 GameRenderer，然後等待前半段繪圖工作完成（見下方說明）。
GameRenderer 完成前半段繪圖後：

GameThread 開始進行下一輪狀態更新。
GLThread 呼叫 EGL:: eglSwapBuffers（後半段繪圖工作）。

因為 eglSwapBuffers 是非常費時的工作（e.g. 6 - 11 ms，詳見下一段：數據量測），因此利用 GameThread 同步處理下一輪狀態的更新，以達到重疊工作的目的。

上述只是可能的做法之一，replica island 這麼做的原因可以參考作者的這篇文章。這個架構可以改進的地方是：GameThread 如果連 onDrawFrame 都不等待，直接進行下一輪更新，要如何同步這兩個工作單元？

1.2 數據量測

這邊我們遇到的核心問題是想要重疊 CPU 與 GPU 的運算，在決定解決方法的過程中，必須有實驗的數據作為設計決策的依據。Replica island 的作者在決定解決方法的過程中，最重要的數據來自他的：SpriteMethodTest（repository 底下的一個 project），以下是我量測到的數據：

Device: Galaxy Tab (Android 2.3.3)
Drawing Method (100 sprites)	Frame time	Draw time	Swap time
Canvas	16	9	0
OpenGL - basic vert quads	16	10	6
OpenGL - draw texture extension	16	5	11
OpenGL - with VBO extension	16	9	7

Device: Nexus S (Android 4.1.1)
Drawing Method (100 sprites)	Frame time	Draw time	Swap time
Canvas	17	8	0
OpenGL - basic vert quads	18	10	7
OpenGL - draw texture extension	18	5	11
OpenGL - with VBO extension	18	10	7

SpriteMethodTest 量測了四種繪圖的方法，其中 Canvas 是 Android drawing API 作為對照組，draw time 是指 OpenGL 繪圖 API （glTranslate, glVertexPointer,
glDrawElements...）所花時間，Swap time 則是 eglSwapBuffers 所花時間。有趣的地方在於橘色那行，使用 glDrawTexfOES 繪圖時速度最快，eglSwapBuffers 最慢。這也是 replica island 選用 draw texture extension 搭配 game thread 平行處理的理由。

1.3 進階討論

目前我看到的手機遊戲引擎大多屬於上述的架構。這個架構主要問題在於：沒有利用 CPU 開始出現多核心（multi-core）的特性。隨著雙核手機甚至四核平板開始在2012年上市，遊戲的狀態可以更進一步切成多個部分，然後由多條 threads 同時執行。此時的門檻則上升成：如何同步控制這些 threads 存取共用的狀態資料。

理論上可以按功能（繪圖資料 / 遊戲邏輯 / 輸入控制等）切分 thread - 稱為 function parallel model，也可以按照資料切 - 稱為 data parallel model，按功能切分可以進一步區分成 synchronous 與 asynchronous，上一節介紹的即屬於 synchronous function parallel model。欲了解更深入，有篇文章是個不錯的起點：

Multithreaded Game Engine Architecture

下一篇，我們來看 component based architecture.
（待續...）

玩遊戲 - Jazz: Trump's Journey

2012-08-06T01:15:00.002+08:00

by Bulkypix

記錄並且分析一下最近在玩的一款遊戲。

以路易斯阿姆斯壯的生平故事為靈感的一款動作遊戲，讓玩家化身為名為 Trump 的爵士樂手，體驗1920年代的紐奧良。

遊戲的基本元素為：

Platformer：主要元素為馬利兄弟式的平台跳躍，部分關卡需要一點技巧。
時間控制：Trump 手上有支喇叭 (Trumpet) ，吹出來的音符可以凍結時間，許多場景需要靠控制時間才能通過。
音樂：遊戲中可以聽到許多好聽的爵士樂，是這款遊戲的一大特色。
畫風：2D平面，畫面給人淡淡的憂愁。並且刻意加上一點雜訊，讓玩家有在看老舊電影的錯覺。
解迷：收集音符以及照片，有些就在路上，隨手可得，而有些隱藏在一些容易忽略的角落，得花點手腳收集，但並不影響過關。

遊戲的目的很簡單，就是從一個入口開始，走到出口。而遊戲的過程，即在訴說阿姆斯壯的故事，從尋找夥伴，到參加嘉年華，遇到歌手兼心愛的女孩，以及與情敵之間的競爭等等。

遊戲分析：

看得出來設計者刻意降低這款遊戲的難度，所以沒有血超多的怪物，也沒有超高難度的跳躍。如果你遇到很難跳過去的地方，通常是因為沒有想到更好的方法，例如利用剛才出現過的箱子，就不用跳得那麼辛苦。
主角沒有血或是幾條命的限制，摔死就會從上一個 checkpoint 復活。這個設計主要是上面降低難度的考量，不過會跟下一個項目的收集音符/照片有點衝突。
收集音符/照片增加了一點遊戲的耐完度，讓玩家會想再次到訪玩過的場景，試著收集完整的音符/照片。但有些音符在收集時，可以利用故意摔死的偷吃步收集到。這應該不是作者的本意，作者的設計應該有不用摔死也能收集到的方法，但摔不死的這條規則會鼓勵玩家用偷吃步。
時間凍結的元素可以看得出來有 Braid 的影子，主角手中的喇叭可以凍結時間，暫停會移動的東西，然而有規則就有例外，於是有些東西又可以不受影響而繼續動作，而要過關就需要善用這幾種物件之間的交互作用。有點可惜這部分沒有看到超出 Braid 的創新設計。

缺點：

遊戲控制：左右以及上下的兩組按鈕居然是分開的兩組分別放在不同的位置，結果導致很多時候，按完左右之後，手指要離開，再去按上下鈕，結果常會按不到正確位置。常見的作法是一個圓圈讓左手拇指透過滑動（不需離開螢幕）就可以觸發上下左右四個方向。無法理解這款遊戲為什麼這樣設計。
程式的品質：音樂這款遊戲的重點，可惜的是，許多地方音樂的處理很突兀，像是暫停時音樂會很突兀的停止，以及過關時音樂會突兀的停止又突兀的播了一小段。這些小地方處理得不夠精緻，如果能善用 fade-in/out 會更好。
劇情文字分兩種，一種你可以按按鈕再繼續下一段，一種無法控制，這種我通常還沒看完文字內容就跳走了，無法理解為什麼要區分兩種。

整體而言，這款遊戲畫風與音樂搭配得宜，使得遊戲過程是一段愉快的體驗！

給二十幾歲的我

2012-07-24T02:36:00.000+08:00

最近在網路上看到一篇文章，在談創業（startup），文章很長，遣詞用字對非英語系的我們來說可能有點困難，而且談的是美國矽谷的 startup，和台灣的情況很不一樣。但是，文章的內容很有料，作者顯然對創業的觀察很深入，很可能有豐富的 startup 經驗。看著看著，我的思緒飄回了那些年經歷過的 startups...

文章：Don’t waste your time in crappy startup jobs.

我在科技業待了八個年頭，加入過兩家台灣主要軟體公司，也參與過兩次 startups，2011年開始 self employment，在這兩年台灣興起的創業育成單位待過一陣子。我的第一個東家是台灣非常少見的大型純軟體公司，我有幸參與它被外商收購前的最後一年，在裡頭見習了軟體產品開發的整個流程。在公司被收購後，我選擇離開到了一家 startup。

當時我的角色就是文章中提到的 J.A.P (just a programmer)，談的薪水比前一份工作好一點，也有一點點股票選擇權（屬於文章中提的 nickel -- 五分錢的股權），當時（2007）智慧型手機正要興起，我們目標做關鍵軟體元件 -- 輸入法，看起來頗具潛力，我們懷著改變手機產業的理想（文章中提到的 changing the world 情結），同事們都像戰友，感情很好，必要的時候加班，總是義無反顧，我們就這麼奮戰了一年多。

事情，並沒有如我們所願的發展，老闆們在談的生意並不順利，公司開始走下坡，員工與老闆之間開始有摩擦，接著員工開始離開。還好 founder 中有很棒的人，即使公司到最後，資金也一直沒有斷掉過。但在經過不算短的掙扎之後，我也只能選擇離開，而老闆最後 cash out 公司的剩餘價值，把軟體賣給台灣的手機大廠。

Startup 期間，身為主要軟體開發人員，我的功力並沒有顯著提升，如文章中所提，startup 的軟體專案是為了搶攻市場，通常時程緊迫，需求經常變更，過程中很難有時間與精力從中慢慢學習 / 改善技術。

我的第二間大型軟體公司是台灣手機大廠，雖然它是大型且上市的公司，但我們在裡面的工作形態倒是很像 startup。異常緊迫的時程，經常變動的需求，頗有彈性的組織架構，唯一的差別是我們不需要為資金擔心 :)

在這間手機公司我遇到許多高手，我很想說我從他們身上學習到許多，但我沒有... 大家都太忙了，我們總是急著把手上的問題“處理”掉，很難有時間與精力從過程中學習 / 改善。在完全燃燒了兩年後，我選擇了離開。

我下一間公司又再次選擇了 startup，它給我非常大的工作彈性，可以做自己有興趣的題目，我們的目標是當時正要起飛的 App 產業。在這邊我才開始有時間/精力用比較緩慢的步調，一邊做一邊學。一年多的時間我們做出了幾個頗具人味的 Apps :)

然而 App 產業百家爭鳴的速度來得實在太快太猛，當我們用自己習慣的速度前進時，這個世界用瘋狂的速度把我們吞噬掉。我們的金主開始介入公司的營運（以當時的情況來說，這很合理），而我認為當時公司規模已經太大，不適合做 App 了，同時有著前一家 startup 的經驗，我知道剩下的只是時間的問題，於是再度選擇離開...

幾年的 startup 經驗下來，我主要以 engineer 的身份參與，對於公司治理與股權結構則是旁觀者的身份，稱不上經驗豐富的創業人。但如果有機會跟當年初出社會開始工作的我講幾句話，我會這麼跟他說：

先加入讓你有學習條件的大公司，學習正規軍的打法，再考慮進 startup
關於薪水，你不應該只想著維持前一份工作的薪資水準，共體時艱更是完全不健康的態度。你應該衡量你承擔的風險，包括原本在大公司可以領到的薪資/股票，以及 startup 公司兩三年內可能無法調薪的狀況，主動去爭取一份合理的薪水。
靠 startup 的股票賺大錢很不切實際（尤其當你早就知道 90+% 以上的 startup 都是以收掉結束）
在 startup 大家都是好朋友，沒有老闆，只是個迷思。Startup 就是公司，就是一份工作。如果你對自己的生涯沒有規劃，進去 startup 也不會讓你更有方向感。
想辦法破除 "changing the world" 的迷思。這點最困難，尤其是現在許多人腦中都配備了賈博斯傳奇與臉書奇蹟。具理想性是好事，但更重要的是正確理解改變世界這件事情的微眇機率，以及其主客觀條件。
不想再為老闆賣命，所以選擇 startup，為自己工作，也是常見迷思。Startup 當然也有老闆，老闆的上面還有金主，金主通常也有其老闆。為自己工作（self employ）不是 startup，比較像是一種生活方式，像是獨立遊戲（indie-game）工作者，那是一種非常辛苦，而且收入微薄的狀態，再次強調，那不是 startup。

而年輕的我很可能會這麼回我：『你當然會這麼說，因為你只是個 startup loser』

當然我是 startup loser，如果一定要去分誰贏誰輸的話。不過，其實我並不後悔加入 startups，我在 startups 階段的人生，過得還滿愉快的，我在第一個 startup 公司期間，我參加朋友的活動而認識了我的老婆，我沒有因為 startup 繁忙的工作而耽誤了該有的生活 :) 此外我和兩個 startups 的幾位同事一直都能保持聯絡。

我只是認為，人們不應該因為不切實際的迷思或單純的“理念”，而輕易選擇進入 startup。年輕的確是本錢，但年輕也是一去不回的無價之寶，年輕在你的天平上應該有著更重的份量。

我在創業育成單位認識一位朋友，有一次言談中我無意冒犯了一位台灣創投界的超級明星，結果那位朋友後來對我很冷淡。我特別記得這件事是因為，第一，我當時說話沒有分寸，後來一直引以為戒。第二，那位朋友顯然對這位創投明星有著不尋常的崇拜。

持平而論，一位創投明星，與一位經歷過兩輪 startups 的 nobody，兩者應該都能夠有創業相關經驗可供參考，但這位朋友顯然對於遙遠的創投明星的一字一句，興趣遠大於每天就在身邊的這位 nobody。而這個現象，正是我對這兩年創業潮最常見到的觀察。充滿熱誠與理想的年輕人，看在風險投資者的眼中，是何等的美味。年輕的朋友們，尤其是工程師出身的我們，你應該要多看，多聽，更重要的是，多想。少數過來人（像是上面提到那篇文章）願意苦口婆心提醒你的迷思，一定要破除，這樣你才有可能看清，並且找到真正很棒的 startup 工作，創造真正屬於你自己的事業！

那些年，我們一起追的女孩

2012-07-02T12:08:00.001+08:00

獨立創作遊戲是件很辛苦的工作，我們都知道。我們都在追求自己設計的遊戲能被許多玩家接受，我們也知道作品要賣座，需要點運氣成分。但是，我總覺得有什麼要素或特質，是創作者必須追求與堅持的，而在現實的環境下要堅持那些要素與特質，正是我認為創作工作者真正辛苦的地方。

圖片來源：http://www.sonymusic.com.tw/pop/appleofmyeye2011/

2011年台灣出現了一部電影：那些年，我們一起追的女孩。這部電影打破了兩岸三地一堆的票房記錄，就銷售成績而言，這部作品是一位創作者的美夢成真。電影內容好看/感人與否非常主觀，沒什麼好討論的（事實上我有不少朋友看完後直言，這真是一部很膚淺低俗的電影，是呀，我們的青春，很多時候似乎正是這麼膚淺低俗...）我認為有討論價值的，是一部票房五億的電影，其創作過程與創作者本身。

讓我們試著來分析一下這部電影所謂成功（以票房來衡量）的因素，並嘗試從中學習創作工作者必須具備與堅持的要素與特質：

題材新穎：愛情，更具體的說，是學生時代的戀情，已經在古今中外的電視電影小說中，被講到爛掉的題材（！）
演員陣容堅強：除了女主角和配角郝邵文外，沒人演過電影（！），女主角拍過幾部電影，但實在稱不上是家喻戶曉的大明星。
大導演：九把刀，網路小說作家，沒有拍過電影（！）
專業團隊：攝影，沒有拍過電影（！）
大製作：柴智屏，老牌電視劇製作人，沒有製作過電影（！）
資金雄厚：電影開拍前主要投資人（非常理性的分析了投資報酬率之後）帶著電影最主要的資金離開，後由導演與製作人兩人一人出資一半，電影才得以開拍。
上映檔期超讚：2011年台灣影壇最受期待的電影，是魏德聖導演的賽德克巴萊，那些年在8月19日上映，正衝兩個禮拜後賽德克巴萊的首映（！）

好，你知道我想表達的，看著這些客觀條件，哪一位創業 / 投資 / 電影專家可以在2008年（電影開始籌劃）告訴我們，它具有成功賣座的條件？所以我們可以事後諸葛的說，成功的因素不在上列這些號稱很重要的項目。

那，什麼是這部電影成功的要素？什麼是我認為創作工作者必須具備且辛苦堅持的東西？

作者對自己作品本身的感情：電影中男主角送給女主角最後一句話：『新婚愉快，我的青春』，這段愛情定義了作者的青春，我們不用懷疑作者投注了極大量的感情在這個作品中。而作者如此強烈的想要把小說拍成電影，我相信一定有比賺錢還重要無數倍的感情因素在其中。九把刀在北大的演講中，提到當投資人撤資，在最難熬的時候發生的『神的微笑』事件：

我去棒球打擊場打球... 通常（120公里的球道）如果二十顆球能打飛出去七八顆，那就是很好的成績。而那天晚上下著傾盆大雨，球也滑，棒子也滑，根本沒人去打球，只有我一個... 沒多久，右手就受傷了，於是我換左打。

突然，心中有個念頭... 我對著心中的神說，神啊，如果我認真拍電影，電影會很成功的話，請讓我有十顆安打。二十顆球，第一顆，飛過圍牆，安打。第二三四五... 九十都是安打。

我嚇到了，為了跟神作確認，我又跟神說，如果剛才不是巧合的話，請再給我五個安打。第十一顆安打，十二，十三，十四，都是安打。到第十五顆球飛出來的瞬間，我心中的自信與恐懼同時擴大到了極限，我心中閃過一個數字，台幣五億。

...我跟心中的神說，如果傾注所有的愛與努力勇氣來拍電影，票房可以有五億的話，請再給我一個安打... 讓它擊中打擊場最上方的銅鑼。... 所以當我揮中這個安打擊中銅鑼，全場奏樂的時候，忽然間我感覺我聽到了神的笑聲，我知道，最大的股東進來了。

請注意，我並不是要強調這邊有所謂的神蹟發生，雖然我相信九把刀講的是真實事件，但我想強調的，是創作者本身投注了多少的心血與感情在他的作品上，讓他能做到平常看似不可能的事情！這樣奇特的事情，是作者投注感情與心血的身心狀態反應出來的結果，而不是原因。

特質二：堅持你看到的那道光。九把刀指定陳妍希作為女主角的不二人選，我不知道陳妍希有什麼特質讓他如此堅持，但他肯定看到了什麼東西。九把刀自己說：『就算電影拍爛了，至少也曾和陳妍希擁有過一個美好的夏天』這些看似無釐頭的理由背後，我看到的是創作者對故事某些必須具備的特質的極度堅持，而不是，為了電影賣座（a.k.a 賺錢）而應該挑選更有名（a.k.a 更貴）的女主角。

女主角的名字，並不是真實那位女同學的名字，改了一個字（儀 -> 宜），但是發音必須相同。作者說：『我想要柯景騰在雨中大喊：沈佳儀，我喜歡你！』想聽到這句話，所以發音不能改變。這邊堅持的，是忠於作者自己的感受。其實每個人心目中那位女同學的名字都不一樣，叫什麼名字對觀眾而言並不是關鍵，但作者/導演自己需要相信，這部電影是在演他和他那位女同學的故事，所以名字對導演自己很重要，他必須堅持。

特質三：觀眾的感動。懂電影的專業人士，應該有辦法把這部電影拆解成，許多用來感動觀眾的操作手法。我不是懂電影的專業人士，但就愛情電影這個老掉牙的題材而言，我覺得九把刀的許多手法，有做到不落俗套。他安插了許多小小的元素在裡面去感動觀眾：被沈佳宜戳爛掉的制服角落，沈佳宜的馬尾，柯景騰排隊打電話，男主角最後撲上去親新郎的橋段。故事本身無疑是感人的，但正是這些小小的具象化的細節，在發揮所謂扣人心弦且回味無窮的效果。

特質一：對你的作品要有感情，是最重要的。如果沒有的話怎麼辦？很抱歉，這點沒得商量，雖然我不知道具備什麼條件才會成功，但我相信對作品缺乏感情，是保證不會成功的。所以如果你是作者，換一個題目吧。如果你參與開發的是別人的作品，那換一個能讓你感動的別人的作品吧。

特質二堅持你看到的那道光，這邊多少牽涉到一點天份，因為你還是得先看到些什麼東西，然後才有堅持不堅持的問題。但我相信你看到那道光的時候，自己會有所感覺。而延續第一點談到的，如果對參與的作品有感情，通常會有某些特質 -- 那些讓你之所以投入感情的特質 -- 會讓你想要堅持。因此當現實要求你妥協，去改動到那些剛好是你堅持的特質時，請發揮你的堅持，並且相信你的堅持，一定會有觀眾能感受到。同時你也必須瞭解，堅持與固執之間，只有一線之隔。大多時候你必須不斷和自己內心對話，確認你的確看到了重要的東西，值得為了它而堅持。

特質三也很不容易，以開發程式來說，我們都知道當開發進入瘋狂階段後，我們眼中只看得到待處理的 feature list 和 bug list，我們腦中所發揮的部門，必須是主管理性思考的部分。這時候你根本顧不到什麼玩家的感動，這麼抽象/感性的事情。如果主管玩家的感動（spec制定者），和負責開發的人是兩組人馬，你可以想像衝突的場面非常容易出現。如果不幸的你是獨立遊戲開發工作者，這兩組人馬通常指的是你自己，於是你可以想像角色轉換之間，那種接近精神錯亂的危險。但無論如何，成功的作品一定有它感動玩家的要素/手法，你一定要能夠轉換角色，從施工的工程師角色抽離出來，去觀察/揣摩玩家在玩你的遊戲時的內心感受。

圖片來源：http://www.appleofmyeye.com.tw/

最後，即使是九把刀，我也認為這些成功的因素，不能保證他的下一個成功。這是這個世界很殘酷的本質，當你有辦法去抽離/分析別人成功的因素出來的時候，你無法直接複製那些因素然後期待得到一樣成功，因為客觀的條件改變了。因此請不要執著於他人成功的故事，更重要的是自己不斷去嘗試與摸索，去寫屬於你自己的故事。

Indie Game: The Movie

2012-06-26T10:48:00.001+08:00

"That creation of this highly glossy, commercial product, is the opposite of making something personal.

- Jonathan Blow

開發遊戲，或者說，開發軟體的人，他們所經歷的過程，生理上的，心理上的，人際關係上的，財務上的一切，很少局外人能夠理解。

獨立製作遊戲，是非常個人化的遊戲，通常只有兩三個人參與製作，往往沒有什麼資金支援，卻又是設計者最能自由發揮的製作模式。

Indie Game: The Movie 這部紀錄片在 kickstarter 首輪募資得到六百多萬台幣的贊助，長期追蹤記錄了兩款獨立製作遊戲的開發/上市/後續的過程，分別是 super meat boy 以及 FEZ。

Super meat boy 是一團肉球，他跑過的地方還會留著他滲出來的血水。在你急著替他貼上血腥暴力的標籤之前，傾聽一下作者怎麼詮釋這個角色背後的隱喻：『小肉球對於這個世界是毫無防備的，他連皮膚都沒有，好像他隨時都活在痛苦之中，一丁點東西就可以重重的傷害了他』。

兩個人，三年多的開發時間，很可能沒有人付他們薪水，程式開發 Tommy 說：『不管這款遊戲賣得如何，只要有一點錢，能夠支持我基本生活所需，就能夠讓我繼續做我想做的遊戲』。

當然 super meat boy 賣得很好，超好，超過一百萬套的銷售肯定給他們帶來非常可觀的收入。但我相信 Tommy 說的，重點從來都不是錢。

Steve Jobs 曾說過：『如果沒有薪水你是否還願意做現在在做的事？如果不願意，那這個東西就不值得你投入』，很多人也讀過這些話，但，有多少人嘗試過沒有薪水工作？又可以撐多久？做出什麼樣的作品來？

"I make video games because I can... I can still make something that express myself..."

- Tommy Refenes

FEZ 是兩個遊戲中比較極端的一個例子，獨特的設計在 2008 年即在 IGF 得獎獲得肯定，卻在 Phil 對細節與品質的堅持下，改了又改，磨了又磨，最後花了五年的時間，才於 2012 年上市。

你可以發現從事獨立遊戲製作的人，都有其非常獨特的人格特質，Phil 非常投入 (attached to) 他的遊戲，以至於他的情緒他的一切都被其牽動着。當記錄片記者問到，萬一遊戲最終失敗收場，他會作何感想，Phil 說：『我會自殺』，許多在場觀眾想必都為之動容。是的，就是如此的投入。（我自己倒是很放心的想著，真正會自殺的人是不會對著鏡頭說的 :P）

我還沒有機會玩到 FEZ，但看看他的遊戲畫面，真是非常清爽宜人是吧～ Phil 說他的遊戲沒有魔王，也沒有死亡，只有偶而失序的電腦世界，需要磁碟重組後恢復穩定，這是一款會讓你緩慢獲得放鬆的遊戲。

"I basically feel like... the entire world is falling apart around me these days."

- Phil Fish

在注意到 indie game 之前，我對遊戲界逐漸感到失望，就像我對好萊塢電影感到失望那樣，一個又一個大成本大製作大卡司的電影，聲光效果完全讓人目眩神迷，但我一點感覺都沒有... 他們無法觸動我的感受，我看著變形金剛的主角歇斯底里的戰鬥着，但我感受不到他為了什麼而奮戰。

但是看看 indie game，每一款都如此特別，好像在訴說著作者自己的故事，而且只說給你一個人聽。如果你玩過 LIMBO，你會驚訝的發現，原來光用黑與白，就可以表現出如此詭異的場景與氣氛。如果你玩過 Splice，你會驚訝的發現，簡單的幾個規則，居然可以建構出這麼多樣而複雜的排列組合，而且解謎的過程，是一條多麼富有挑戰卻又令人滿足的過程。如果你玩過 Braid... 他會顛覆你對時間與空間的既有概念，以及他隱含在背後，一段令人痛徹心扉的愛情故事。事實上，我是因為 Braid 才開始接觸 indie game...

Jonathan Blow，Braid 的作者，是一位非常發人深省的遊戲設計師。透過他設計的遊戲，他的文字，和他的話語，你會發現對遊戲這件事有了完全不同的體認。Indie game 記錄片中用 Jonathan 獨白的方式，闡述了遊戲設計的精髓：『（設計遊戲）就像挖掘出你自己最深處的缺陷和弱點，然後放進遊戲之中，看會得到什麼結果』。這句話完全顛覆了我對遊戲的認識！我一直以為遊戲是要建構一個完美的世界，讓我們得以暫時逃離這個不完美的世界...

"Things that are personal... have flaws. If you don't see a vulnerability in somebody... you're probably not relating with them on a very personal level."

- Jonathan Blow

遊戲設計師花費了無數的心血，開發了遊戲並且上市之後，無非希望得到玩家的欣賞。Jonathan 分享了上市後三到四個月之間，他陷入了深層的憂鬱。雖然他的遊戲獲得許多的好評，但那些他的設計背後，最深層的想法，卻很少被提及：『你以為可以透過遊戲，和這個世界得到某種連結，但卻發現，那樣的連結並不存在...』。

移植並上市了一款手機遊戲的我，也許稍稍能夠體會一點他的感受：我會仔細閱讀每一則玩家的留言，上網找尋遊戲評論，而每一個讚美能讓我高興的微笑，每個批評（特別是那些不善意的）也總能讓我失落好一陣子。好像那些讚美與批評都是當著你的面直接對你說的。

而來自家鄉的玩家，對於遊戲必須付款才能玩到完整版的批評，讓我特別感到沮喪。如果批評的是遊戲會當機會lag，我會樂於接受。如果需要付款的批評來自其他國家的玩家，我也只會告訴自己這些人不是我們目標的玩家。但不是，這些批評多來自自己的家鄉... 我最想得到的連結（認同，而非鈔票），似乎並不存在。

.......................................................................

電影結束了，這個世界還是持續轉動着，super meat boy 仍然只會是少數成功的例子，獨立遊戲製作仍然是一條孤獨到爆炸的路，不會有所改變。

但或許，因為這部電影，這世界多了幾位更有心的玩家，願意去體會獨立製作遊戲內，甚至遊戲外的故事。也因為這部電影，這世界肯定會多了幾位認真的傻瓜，勇敢踏上獨立創作之路。

更或許，因為這部電影，能夠啟發更多的我們，對於自己的工作自己的作品，無論是不是遊戲，投注更多屬於自己的 -- 靈魂。

隨想：Scripting Language

2012-06-22T02:05:00.000+08:00

關於程式設計，我算是半個科班（先自學而後碩士轉攻資訊工程），我從不以老手自居（雖然年紀也是三十好幾...），工作以來多在純軟體公司，接觸到的也都是硬底子工程師，大家熟悉的也幾乎都是 C/C++ 這些所謂 system programming language。

直到一年多前我出來創業，接觸許多相對年輕的工程師（例如三十歲以下），然後我發現我們對程式設計的定義很不一樣 :) 他們通常指的是 JavaScript 或是 Ruby 這樣的開發語言/環境。我不是要說這些是比較膚淺或簡單的程式設計（事實上對我來說一點都不簡單...），而是想指出，如果我沒離開先前的環境，根本無法體驗這樣的文化衝擊，以及幫助我後來的視野更加寬廣。

今年切入遊戲開發的領域後，開始接觸幾個 game engine 像是 Unity3D 或是 Corona SDK，也開始學起了 scripting language 像是 JavaScript 以及 Lua。為了更瞭解各種程式語言的關係，我找到一篇非常棒的論文：Scripting: Higher Level Programming for the 21st Century

這是一位史丹福大學教授 John Ousterhout 在 1999 年發表的論文，啓發了後來許多 scripting language 的設計。他主要在比較傳統 system programming language ( C/C++/Java) 和 scripting language (Shell/Perl/Tcl...)，他認為主要差別在於 scripting language 是：

Typeless
Interpreted

他並且強調 scripting language 雖然犧牲部分效能，但在產出和彈性上比較占優勢。

這篇論文有幾項可以提出來討論：

第一個是物件導向 (Object Oriented) 程式設計中的繼承導致程式難以理解/維護。的確，單看一個 class 很難理解該物件的全貌。不過 scripting language 中有的利用組合的機制來表達物件，要理解單一物件，還是得要追根究底把組成的元件追蹤過，我認為並沒有比繼承容易理解。當然十幾年後的現在來看，我們多了許多先進的開發工具可以協助開發者減輕理解程式碼的負擔。

另一個值得討論的觀點是：scripting language 常用來組合既有的元件，像是 Unix shell script 用來組合工具程式（透過 pipeline），或是遊戲引擎中的 Lua 用來組合 C/C++ 語言開發而成的元件。當然我們也可以把類似的觀點應用到 system programming language 上。例如我自己的專案 Bonnie's Brunch 完全使用 Java 開發，而為了表達遊戲教學相對複雜的流程，我把整個流程切割成小單元像是邦妮說話 / 客人點餐等，並且用 command pattern 封裝這些行為，然後我就可以像 scripting language 那樣很抽像的描述整個流程，像是：邦妮說話 (把要說的話當參數傳進去)，等待使用者點某顆按鈕 (這又是另一個 command)，收到 tap event 後邦妮再說另一段話等等。

現在我們知道許多應用，需要 scripting language 與 system programming language 攜手合作才能完成。因此善用 scripting language 的關鍵，在於分辨哪個部分適合以 system programming language 封裝成元件，該論文建議的方法至今仍有效：

基本資料結構及演算法傾向的問題
效能瓶頸的地方
需求明確且不容易更動

以上情形適合用 system programming，反之則適合以 scripting language 來實作。

你是哪個世代的程式人員呢？你是否像我忽視了 scripting language 在許多應用的重要性？或者，你的程式開發之旅開始於 scripting language，而總是想著無法掌握系統底層真正運作的面貌？也許，我們早該跨越彼此的鴻溝，學習彼此的優點，更彈性的運用與組合不同的程式語言。

WWDC 2012 觀後感

2012-06-13T16:02:00.002+08:00

2012 WWDC開幕的那天，在台灣我們正遭逢超大豪雨的襲擊。被雨聲吵到睡不著的我，索性起來看文字轉播。

身為手機軟體開發者，我們很難 (也不應該) 忽略蘋果公司的動作，因為她的一舉一動，牽動業界的勢力版圖，也牽動終端消費者許多行為改變。以下是一點我的觀後感想。

看到次世代 MacBook Pro 的規格與理念之後，可以用驚世駭俗來形容我的感受。我並非所謂果粉，我購買的第一款蘋果電腦是2011年時買進的 MacBook Air，而且還是因為其他廠商找不到我需要的規格才不得已才購買。我沒有 iPhone，只有一台 2009 年款的 iPod Touch。

我的驚訝來自於身為軟體工程人員，我對於視網膜 MacBook Pro 的軟硬體工程上的突破感到震驚，解析度高達 2880 X 1800 的視網膜顯示器，一次把像素 (pixel) 提升到目前業界標準的四倍，這對顯示晶片的效能，系統架構包括資料傳輸和散熱能力等等，是多大的挑戰，更不用提軟體從作業系統到應用程式，會有多大的衝擊。當時我在 Google+ 上留下幾句感想：

上次的air讓非蘋陣營花了三年才勉強追上，蘋果這次出手的規格，恐怕五年都不夠追了。

不過冷靜想想，新款MBP也把工程極限推進得太大步了，螢幕解析度直接推進四倍以上，實在很難想像GPU效能提升追得上，開賣後免不了會傳出問題？

是的，我非常佩服 Apple 追求極致的企圖與勇氣，但也不會急著去購買這個產品 (是啦，價格太高貴也是重要原因...)。

這個產品我看到一個方向，就是工作用 (專業用) 電腦的移動能力 (portability) 成為趨勢。PC 產業一直有著核心使用族群，包括遊戲玩家和專業工作者（影像處理，程式開發等），如果 Notebook 將來的趨勢可以滿足這類核心族群，那 PC 進一步萎縮則可以預期。

綜觀今年 WWDC，我會說 Facebook 會是最高興的人，而 Google 則是最落寞的人。

Facebook上市以來股價表現不佳，最常聽到的疑慮來自手機上缺乏廣告收入。iOS6 Safari 瀏覽器的 Smart Banner 無疑是 Facebook 非常樂於見到的。這邊又一次看到 Apple 極權式的思維（沒有不好的意思），網頁要出廣告可以，但請使用 Apple 的方式/風格來處理。就使用者的體驗來說，這樣的設計可能是比較好的。

另一個亮點是 iOS 與 Facebook 更緊密的結合，強調只要登入 Facebook 一次，即可使用包括拍完照片後直接分享，或是透過 Siri 語音輸入後直接分享到 Facebook。這邊又一次看到 Apple 與 Google 不同的思維，在 Android 手機上其實技術上都可以做到上述的事情，你可以透過語音輸入把想分享的文字說給手機，然後透過 App 分享到 Facebook。如果你有安裝 Facebook App，也可以透過 single sign-on 機制避免重複登入。但 Apple 幫你把這些事情全都串好了，使用者儘管享受使用即可。喜歡便利性的人把這叫做方便/體貼，但也有人不喜歡這種缺乏彈性的設計，更有人會擔心如此緊密的結合可能帶來的後果。

最後，身為手機遊戲開發者，除了 iOS 上可以省去和 Facebook SDK 搏鬥之外，其實今年 WWDC 我沒有看到什麼改變遊戲規則的事情，iOS App 生態系還是持續凌駕 Android App 之上 (orz)。歐對了，還要持續追蹤 MacBook Pro 上市的後續發展。

Game Engine的一點想法

2012-06-11T22:02:00.003+08:00

我踏入遊戲領域的第一個案子 Bonnie's Brunch for Android 完全使用 Java 手工打造，於是一個單純移植的專案，加上後續的金流 SDK 整合，花費將近五個月開發。以這個案子的規模而言，實在是太長的開發時間。

根據 Game Developer Magazine 在 2012 年五月號的一篇調查報告 (pp. 10)，53% 移動裝置遊戲開發商表示正在使用或是即將採用 Unity3D 遊戲引擎。14% 的開發商使用 Unreal Engine，另外有 10% 使用 cocos2d。看起來採用商用遊戲引擎的開發商佔了絕大多數。但，值得注意的一項數據是，在銷售成績最頂尖的開發商當中，也有 39.8% 使用自行開發的遊戲引擎。不算低的自行開發比例，讓我想到Kingdom Rush 的開發商很熱心的回答了開發相關的細節，他們的 web 版本使用 Flash ActionScript 開發，引起我注意的是：

沒有使用像是 PushButton 之類的 flash game engine，而是自行開發塔防專用 (tower defense) 遊戲引擎。
僅使用三套小小的 3rd party library，看起來其他部分都是自行開發。

我發現有不少優秀的遊戲開發商並沒有使用現成的商業遊戲引擎。Game developer magazine 的調查還有一項：每五位開發商有 4.45 位使用遊戲引擎的首要原因是為了加快開發速度。

從這些數據我得到一個非常粗略的結論：大家都想要用最快的速度開發，同時也想要自己的遊戲賣座 (廢話^^)，但是結果來看，最賣座的遊戲中，卻有將近四成的開發者使用自加開發的引擎。這些數據似乎告訴我們欲速則不達。

我目前採取的策略是，為了讓遊戲開發達到合理的速度，並且減低跨平台的 effort，Unity3D 這類的跨平台遊戲引擎值得投入資源研究。但我們也必須了解套裝遊戲引擎不會是遊戲開發的銀彈。效能瓶頸似乎是其中一個常見的問題。另外，以我非常粗淺的對遊戲引擎的瞭解，像 Braid 這樣顛覆傳統，遊戲進行的時間可以雙向前進或後退的遊戲，用傳統遊戲引擎似乎不容易做到。

因此長期來看，想要開發出具有自己獨特元素，且具備優越效能的遊戲，我們對軟體底層架構必須有很深地掌握，逐步擁有自己能完全掌控的底層模組，是很重要的核心能力。因此現階段使用遊戲引擎還有一個重要的目的，就是學習遊戲引擎的構成要素，設法掌握當中的關鍵技術/元件，必要時必須能夠以更強大的元件或甚至自行開發的元件替換。

話說最近學習用 JavaScript 做 Unity3D 遊戲開發，對於從 strong typed 的 Java 轉換過來的人來說，還真是適應不良>"<

一時之間很難接受天外飛來一個 object 也不知道是什麼型別，就直接叫用它的 function... 然後 function definition 也不明確定義回傳值的型別。哈哈，還有段期間要適應。

API Design Notes

2012-05-30T22:22:00.000+08:00

給程式設計師 / for programmer

前一個專案檢討說嘴夠啦，切換心智回工程師模式：

Michael.嘴泡模式.setEnable(false);
Michael.工程師模式.setEnable(true);

Bonnie's Brunch for Android 專案在和國內廠商整合付費 SDK 的時候，遇到幾個 SDK 在 API 設計上的缺失，實際上也造成我們 App 整合時發生問題，我想把一點經驗和大家分享了。

Naming and Class Responsibility
一開始，為了給 App 啓動時檢查是否是合法的版本，於是 SDK 設計了一個叫做checkAccess 的 function：

public class LicenseChecker {
    public static interface LicenseCheckerCallback {
        public void allow();
        public void dontAllow(int reason);
    }

    public void checkAccess(LicenseCheckerCallback callback);
}

這邊大致上沒有太大的問題。然後下個需求，是做 App 內購買 (In-app billing in Android's term)。設計者通常希望使用者不需要面對太多 function name，於是沿用了 checkAccess 這個名字新增一個 function 且新增加了一個參數：

public class LicenseChecker {
    // ...
    public void checkAccess(String productId, LicenseCheckerCallback callback);
}

至此，LicenseChecker 已經開始負責超過原先設計要它做的事情 (check license 之外開始做起了買賣)。然後你可以想像 client side 會有一個 LicenseCheckerCallback 卻是在處理跟 in-app billing 相關的事情，名不符實。

當然這些上述的問題主要是 naming，改一下名字也就好了。致命的問題是設計者很可能假設了 client side 必須用同一個 LicenseChecker instance 做 App 啟動檢查以及購買的動作。但 client side 在不知情的狀況下，以下寫法完全合法但不 work：

// on Game activity's onCreate
LicenseChecker checker = new LicenseChecker();
checker.checkAccess(this);

// ...

// when user do the purchase
LicenseChecker checker = new LicenseChecker();
checker.checkAccess(productId, this);
}

不 work 的原因是第二個 LicenseChecker instance 的第一個 checkAccess 沒有被叫到，而第二個 checkAccess depends on 第一個 checkAccess 的 side effect！

這邊我們看到的第一個問題是權責混淆加上名不符實，改善方式：

把用來處理買賣的 API 從 LicenseChecker class 拉出來，改名 (doPurchase)
新增一個 callback interface 給買賣的 API (PurchaseCallback)

第二個問題是 doPurchase 之前需要 checkAccess，一個可能的設計是：

新增一個 class (LicensePassport) 用來封裝 checkAccess 之後的 internal state change
LicenseCheckerCallback 在成功的時候傳回 LicensePassport
doPurchase 明確要求 LicensePassport 做為參數

這時候 LicenseChecker class 已經不符合需求，改用一個權責範圍更大的 class (SimpleSDK) 包住這些 API：

public class SimpleSDK {
    public static class LicensePassport {
        // internal state you need to do in-app billing
    }

    public static interface LicenseCheckerCallback {
        public void allow(LicensePassport passport);
        public void dontAllow(int reason);
    }

    public void checkAccess(String productId, 
        LicenseCheckerCallback callback);

    public static interface PurchaseCallback {
        // ...
    }

    // request caller to provide LicensePassport, which
    // can only obtained by calling checkAccess.
    public void doPurchase(LicensePassport passport, 
        String productId, PurchaseCallback callback);
}

Listener/callback Thread Issue
另一個問題發生在 callback，請看以下 scenario：

// on SDK side
public class SimpleSDK {
    public void someAPI(Callback callback) {
        //...
        callback.onSuccess(this);

        updateSomeState();
    }

    public State querySomeState() {
        return someState;
    }
}

// on client slide
public class Client implement Callback {
    public void onSuccess(SimpleSDK sdk) {
        State state = sdk.querySomeState();
        // do things depending on state value
    }
}

眼尖的你是否看到問題了？onSuccess 回來 client side 的時候，SDK 還沒去 updateSomeState，所以 client 在 onSuccess 裡面去 querySomeState 問到的會是還沒 update 的狀態。

SDK 設計者會在文件中明確“要求” client side 在收到 callback 的時候必須另外開一個 thread 來作後續的動作，以 Android 程式來說可能是：

// on client slide
public class Client implement Callback {
    public void onSuccess(final SimpleSDK sdk) {

        activity.runOnUiThread(new Runnable() {
            public void run() {
                State state = sdk.querySomeState();
                // do things depending on state value
            }
        });

    }
}

但想要用文件去限制 client side 以特定方法使用 SDK 容易衍生許多不容易抓到的問題。比較保險的方式還是先 updateSomeState 完成再 callback。

Equality Issue
接下來這個問題比較一般性，不是 API 設計特有的：

String id = "some unique id";

Key key1 = new Key(id);
Key key2 = new Key(id);

if (key1.equals(key2)) {
    // expect to run through here
} else {
    // but actually run through this path
}

語意上那個 if 是想要判斷 key1 代表的值是否等於 key2 代表的值，但以 Java 為例，前提是 Key class 要改寫 (override) equals member function (請參考這裡)。其它語言也一樣，要區分：

比較兩個物件是否為同一個物件 (這時候所代表的值當然相等)
兩個 references or pointers 也許是指向同一物件，也許指向兩個不同物件，但比較它們兩個所代表的值是否相等

是兩件事。大部分語言的語法 (ex: '==' in C++) 可以直接比較兩個物件是否為同一物件 (第一項)。不過第二項屬於程式邏輯，通常需要明確 call function 作比較。

PS: 這次我們的 App 整合 SDK 很可能也遇到這個問題。有一個 API 需要帶類似上面 Key 的物件進去。Call 兩次這個 API 每次帶不同的 Key (但所代表的值一樣)，卻會得到不同的結果。可能的原因是 Key class 沒有 override equals (Key class 由 SDK 提供)。

邦妮的早午餐 - 事後諸葛之三

2012-05-25T17:41:00.000+08:00

咦怎麼還有第三篇？不是該說的都說得差不多了（不該說的也說了吧？）

這年頭電影或小說至少要有三部曲，強的有到七部曲，所以我不能輸！

作為一個還有待市場驗證的產品的開發人員，我要厚顏無恥的講我們可能做得好的部分！（怎樣～咬我呀～～咬！）

產品
關於創業，你看過滿坑滿谷的文章，告訴你應該要找到你的潛在客戶，了解他們的需求然後針對這些需求開發（這種文章通常文末會附上他們公司最新舉辦的活動訊息）。你應該也看過一種文章告訴你忠於自己的想法，你不該試著取悅所有人，因為那代表你無法取悅任何人。

總之，你看過各式各樣的說法，通常互相抵觸矛盾。於是得到這些所謂的秘密都是 bullshit 的結論。（ＰＳ：你很可能是對的）

我當初在考慮要不要找現在的夥伴合作之前，我只做了一件事，把他們的產品（就是一款遊戲）玩完一遍，發現我喜歡這個遊戲，想著如果我能夠把它帶到 Android 平台來應該是很酷的一件事。

最初的這個感覺非常重要，在日後開發過程中，一天玩個十幾二十次是家常便飯。如果你不是很喜歡這個產品，你早就彈性疲乏，變成只想趕快了結這樁苦差事。

設計
我沒有參與到邦妮的早午餐的設計。不過我認為我的夥伴們當初在做設計的時候有些不錯的特質：

簡單：整個遊戲的核心就是，把客人要的午餐兜起來，然後拿給客人。並不是說簡單就一定好，只是當初設計的出發點就不是要做一款 hardcore game，也希望在相對簡單的技術內就可以達成的遊戲，事後來看，這原則是有守住的。
變化：雖然說遊戲核心很簡單，但結合不同的食材，再搭配不同屬性的客人，讓玩家玩的過程必須調整做早餐的策略，而不是一昧追求更快的速度而已。有款遊戲叫 defender，下載人數超多，但玩了一陣子你會發現，它沒有什麼變化，敵人就那四種，然後血越來越多，你就一直升級你的武器，讓它攻擊力越來越強。我無意批評 defender 因為它對某類型玩家黏性超強，但我自己會覺得像個機器人一樣在玩這款遊戲，我不希望做出來的遊戲是像這樣把玩家當機器人搞。
美術風格：發行到全球也是一開始的目標，這點我還滿佩服我的夥伴們，think global 只是一句話，真的去做了你才能體會有多難。身在台灣的我們，怎麼知道什麼美國人喜歡什麼美術風格，而美國人能接受的風格，法國人難道也照單全收？關於這點我實在沒能夠有什麼建議，除了選擇對的夥伴之外。（靠廢話）

溝通
軟體開發最核心的能力是溝通，而良好的溝通前提是把對的人擺在一起。（團隊/人的討論請見本系列首部曲）

遊戲移植確定開始後，我們團隊兩個星期見面開會一次，每次兩小時左右，開會內容是：

進度報告
問題討論
閒聊（像是如果發了之後該怎麼辦之類的，由於我們先前沒有經驗因此事先準備有需要的）

開會前我會整理要討論的內容，開完會後也會整理會議結論和行動方針，用 google doc 的形式記錄（而不是 email）。總之，必須讓會議討論是有效果的。

開發後期測試版本開始出來之後，我每個星期出一個版本，見面開會變成每週一次，持續兩個月左右。如果有比較急的問題就透過 mail 討論。

品質
身為開發人員我要厚顏無恥的說，我對品質的要求，可能達到偏執的程度。我是那種連書櫃的背面（看不到的那一面）都堅持要上漆的傢伙。看到一個 bug 我會睡不著覺，解掉才能安心入睡的傢伙。解掉 bug 還不夠，程式碼還要看起來順眼...

關於產品品質，你看過滿坑滿谷的文章，告訴我們產品的品質根本不重要，有沒有打中甜蜜點才是重點（這種文章通常文末會附上他們公司最新舉辦的活動訊息）。同時你也看到好多文章，討論賈伯斯如何要求品質到瘋狂的程度，所以他公司的產品才會成功。

總之，你看過各式各樣的說法，通常互相抵觸矛盾。於是得到這些所謂的秘密都是 bullshit 的結論。（ＰＳ：你很可能是對的）

無論如何，我就是對品質有點偏執，所以我也只能做我自己，花着許多小時修正一個又一個 99% 的玩家不會看到的小問題。盡管如此，上架後還我是收到了幾個 crash report。

所以我的建議會是，就做你自己吧，問心無愧的開發你的 App，稍微偏執OK，不要真的發瘋就是了。

結論
該吃晚餐了，你也應該有自己的生活。
開發這款遊戲的過程我大概能維持朝九晚五的生活，即使熬夜我也不是在開發這款遊戲 :D

邦妮的早午餐 - 事後諸葛之二

2012-05-23T22:32:00.000+08:00

唉呀呀，說好是事後諸葛，不過我上一篇一不小心就開始講起什麼 source control 的重要性之類的東西，真抱歉... 咳，說真的，這個專案到底學到什麼教訓（lesson）呢？

一，Android 機種眾多
這大概是 Android 開發人員唯一可以驕傲的對 iOS 開發人員炫耀的地方吧。

Android 程序猿：嘿！我有一千多款機器的相容性要處理，厲害吧～
iOS 程序猿：啥！我只有四五款（委屈的樣子），那你怎麼處理？
Android 程序猿：哈，當然是撒手不管囉～

我們遊戲上市第三天就有個傢伙留下一顆星的評價說他的 galaxy y 根本不能跑。查到網路上的資料顯示這個系列的機種對 OpenGL ES 的支援有問題，於是只能趕快把這系列機種從銷售名單上剔除。不過傷害已經造成了，而我們事先也無法過濾所有幾種，只能等不開心的玩家來抱怨（願意抱怨的你還得感謝他）。

所以我的建議是？邊做邊學吧，有些機種花（惡）名在外，遇到一個就封殺一個吧。

二，廣告
我們本來一直天真的想維持所謂遊戲的質感，不想放廣告。但後來有經驗的人告訴我們 Android Apps 有多麼依賴廣告的收入後，只好乖乖把廣告加了上去。目前還沒有足夠數據可以判斷廣告收益到底值不值得（廣告商 OS：因為你值得！），等我們有更多數據後再來報告了。

有個心態要調整的是，我們的製作團隊會去想：”放廣告＝質感較差“ 這件事情。你可以把這個心態當成天平，天平的另一端是：“遊戲好玩＝玩家就會掏錢買” 這件事情。這兩件事情對 iOS 玩家和對Android 玩家來說意義並不一樣。簡單說，Android 玩家（特別在某些地區）認為遊戲好玩之外，它還必須是免費的（天經地義的！）。這時候我們去堅持天平的另一邊，說為了質感不放廣告，就會變得很奇怪。這個天平可以進一步延伸思考的是，如果我們完全開放所有遊戲內容（變成完全免費），只靠廣告收入，這樣收入是否一定較少？（我認為不是簡單的一句廢話一定比較少，這樣而已）

另外，放廣告花時間的地方在於要避免廣告妨礙了玩家體驗遊戲，例如，遊戲進行中，如果只是把廣告的 view 藏起來，它有可能還在背後偷偷更新廣告，結果會造成遊戲進行不順暢，這時候請放心，玩家不會說：歐我想是廣告在背景作祟。玩家只會說：什麼爛遊戲，一點都不流暢！

所以放廣告是門藝術，要拿捏的恰到好處，讓玩家有點煩又不太煩。

最後，我們使用的廣告商是 AdMob，根據有經驗的朋友分享，他的投效率並不好，有人推薦 millennialmedia，下次可以試試看。

三，代理商
嗯，重點來了... 遊戲做完了，放上去 Google Play，你會發現只有兩三隻小貓會莫名其妙的發現它，然後下載去玩。當然，連我們自己也都只能用一字不差的關鍵字才能找到自己的遊戲，然後你不禁會去想這兩三隻小貓到底怎麼有辦法發現我們的產品。

“品質良好又好玩的遊戲” ＝ “賣座” 這件事情大概是初次創業的小朋友第一個會幻滅的想法。我們當然不是小朋友啦，所以我們找代理商！在台灣你不容易發現專業的 App 代理商，比較常看到的是通路商兼做發行。

這次我們在台灣合作的代理商本身也還是這行的菜鳥，所以合作起來非常辛苦。從談合約開始，你會發現他們的合約當初可能是別種合作案在用的，有不少不合宜的內容，需要你主動反應。建議談和約時注意：

拆帳比例記得談清楚，拆帳有效期限也要有，通常是兩年到三年
發行商願意提供的資源最好寫下來
發行日期最好有個雙方都可以接受的範圍寫下來

我們從代理商那邊得知的行銷手段大概有這些：

傳簡訊
Facebook粉絲頁
發新聞稿

由於台灣地區的發行還沒完成，我們還不知道這些行銷手段效果如何。不過如果你需要和通路商合作發行 Android 遊戲，你應該注意：

收費 SDK 的整合：一套 SDK 在設計的時候，會有他的假設，有他預想被使用的情境。我們在整合的時候碰到超過 SDK 設計者當初的假設，因此花了不少時間在驗證是誰的問題，和修改 SDK 上面
Google Play 帳號需要經過審核才能收費：這一點開發 App 的我們應該都知道，但很可惜我們的發行商忽略了這件事，這是台灣 Google Play 一直無法上線的原因。所以記得確認這些順利上線所需的細節。

你該不該為你的遊戲找發行商？答案見仁見智。但無論找與不找，行銷對於小開發商都是一件很困難的事，也是你必須認真思考研究的部分。

四，In-App Purchase 可能比你想得要複雜一點
我們的遊戲是免費下載，可以玩十五小關（總共五十小關），然後要花錢購買才能玩剩下的關卡。一開始會以為在主選單加個購買按鈕即可。不過當玩家玩到第十五關的時候，要怎麼激發玩家購買慾望？這件事情我們沒有在一開始就規劃，於是在開發後期只能以較少的 effort，加一個對話框去做：

如果重來一次，我可能想把它弄得更生動一些，例如邦妮會跟你說購買完整版有那些可以期待的遊戲內容等等。

好啦，鐘聲響啦，放牛吃草！

邦妮的早午餐 - 事後諸葛之一

2012-05-21T23:58:00.003+08:00

隨著專案接近尾聲，我想把一些過程中學到的經驗與教訓和朋友們分享，主要分成 Android 遊戲開發，以及一般性的專案管理。

邦妮的早午餐是由樂風視覺創意公司和幾位獨立工作的夥伴設計開發完成，遊戲猿有篇夥伴們的專訪。2011年底我經由朋友的介紹和樂風的夥伴們認識，進行幾次溝通後，確認雙方理念/需求接近，於是決定展開 Android 版本的移植，2012年五月十六日全球版本上市。

我很幸運，Android 版本做的是移植（而非新遊戲的開發），光是需求明確（有 iOS 版本作為 reference）就讓專案管理複雜程度下降許多。不過，Android 版本有個獨特的需求，就是 Free 版本內建付費機制購買完整版（in-app purchase - IAP），而事實證明，光這一點的改變，引發的連鎖效應就超過我們開始所能預期到的影響。

先談點團隊的人的因素，這是一切開始之前，最重要的事情。所謂雙方理念接近是很抽象的，層次拉到最高來看，雙方的願景是什麼？即使你的出發點是很俗氣的“做時下最夯的App然後海撈一票”也OK，重要的是雙方要能開誠佈公讓對方了解。願景會影響許多後來面對問題時的選擇，例如：產品品質與上市時間的取捨，宣傳的手法等。

我之前完全沒有開發遊戲的經驗，我確定自己是認真的想切入遊戲產業，我想藉由這款遊戲了解程式方面比較底層的基礎，例如 OpenGL 的使用，entity / component 架構，texture 的管理，event dispatch 等等。所以我不會用最“快”的技術/工具移植這款遊戲，我選擇用 Android 的標準語言 Java 來開發，而且沒有使用第三方遊戲引擎或 library。這是我的理念/想法。而樂風方面想嘗試 Android 市場，他們需要長期配合的夥伴，賺錢當然也很重要，但更重要的是多方嘗試/了解 Android 遊戲市場。此外，樂風對於品牌的經營與口碑的建立非常重視，對於遊戲品質十分堅持，這方面雙方理念是比較接近的。

我必須強調，技術上，我選擇 Java 從頭到尾手工打造這款遊戲，就專案時程考量而言是很糟糕的選擇。如果你有遊戲開發的基礎背景，你應該選擇遊戲引擎/套件來進行移植。

專案管理方面，我的工作室一直都是使用 FogCreek 公司的 FogBugz 來做 project management。這套系統雖然表面上是做 bug tracking，不過拿來做專案管理也可以，它有以下特點：

Web based：這年頭我還滿習慣使用線上的軟體，一方面不用一天到晚做軟體升級，另一方面也不用擔心資料備份。
Evidence Based Scheduling：這個功能是我持續使用 FogBugz 做 project management 的主要原因。我們都知道軟體時程很難掌握，也聽過許多宣稱很厲害的預估方法，不過 evidence based scheduling 還是我比較認同的方式：基本上你先列出工作項目，然後自己評估需要的時間，然後開始和結束一個工作項目時告訴這套系統，它就會記錄你預估的時程和實際所花時間之間的落差，隨著工作項目的累積，系統逐漸可以掌握你這個人預估時程的可信度，下次你預估完新專案的工作時程後，它可以相對準確的抓出預估完成的時間！
Free：這套系統採用每月計費，每人每月費用是 25 塊美金，一年下來要價台幣約 9000，可以說不便宜，不過它有創業方案，如果你的團隊是兩個人以下，可以免費使用。將來團隊增加了，才開始付費。

Source control：你的專案應該有 source control (吧？！) 在台灣我聽過不少待在上市公司的朋友說他們 source control 就是自己的硬碟，好一點點的說他們有 source control server，不過放在工作地點的同一間辦公室內。Source control 最基本的功能是備份，重點是異地備份，至少要在不同的辦公大樓（考慮到大樓火災），更好是在地理上距離夠遠的地區（考慮到地震等天然災害）。Source control 更重要的功能當然是同步開發：讓夥伴們可以同時進行程式開發。另ㄧ個重要功能是做版本控管，常見的做法是區分開發與穩定兩條路線（branch），同時你的產品也經常需要區分版本：英文版 / 中文版，或是區分不同客戶（如電信商）等版本。使用 source control 可以讓你事半而功倍（事實上比較可能的原因是不使用 source control 就準備等著搞砸 XD）。

我們專案的 source control 選擇 Kiln -- 剛好又是 FogCreek 公司的產品，選用的原因是：

Mercurial：Kiln 這套產品選用 mercurial 這套版本控管工具，而我之前已經熟悉 Git（早先曾經被 subversion 荼毒過所以改用 Git），而 Git 到 mercurial 之間沒有什麼學習曲線。同時 mercurial 是我用過的 source control 當中做 code merge 最好用的，值得推薦。
遠端備份：Kiln 也是 web based，code 放上去就完成遠端備份（不可以偷懶就是了，我至少每週 push 一次上去遠端）。
Free：一樣有兩人以下免費的方案。

遊戲開發很重要一部分是和美術人員的溝通，其中最重要的是圖檔的取得。我的夥伴有很好的圖檔命名習慣，每次給圖也會同步有文件記錄，文件內容簡單卻很有效：圖檔名稱搭配使用時機和貼圖位置等。不可以小看這些動作，隨著圖檔變多，檔名和座標等資訊很容易亂掉。我們這種低科技但有效的作法就是一份表格文件，重要的是每次都必須 update 以同步真實的狀況。

歐一轉眼時候不早了，下次我們來談談比較屬於 Android 開發的部分，包括廣告和收費機制。See ya!

危機處理

2012-05-17T17:09:00.001+08:00

Bonnie's Brunch for Android 終於在 5/16 上架到 Google Play（抱歉... 台灣地區還沒開賣，原因請看本文最後一段），以及某台灣電信平台（F 公司的 S 平台XD)。然而才一天 S 平台就發生購買完的遊戲顯示未購買的情況，於是緊急下架，開始危機處理。

由於我得到的資訊只有：“遊戲購買之後隔天變成未購買”，而且無法取得發生問題機器的 log。其實一開始是不知所措的，我重新看過一遍購買的流程的程式碼，由於流程單純，也沒有 unit test，一時之間肉眼“看”不出問題所在。S 平台的 SDK 用來尋問購買狀態的流程如下：

流程如此單純，只有一個可能了：callback 沒有回來。而 App 一開始假設玩家沒有購買，於是 checkAccess 沒有 callback 回來改變購買狀態，於是已購買的玩家就被當成沒有購買...

經過檢查發現該 SDK 真的不是 100% callback。解決方法是回報該公司然後等待 SDK 更新。歐我忘了，這裡是地球，這招不管用的。反應問題完並且得到官方制式回答的同時，解決的方法是：購買完成時，將這份資訊（經過加密）寫入db，然後 App 啟動時購買的狀態先從 db 讀出來，同時去詢問 SDK 購買狀態。如果有 callback 則可以更新購買狀態。萬一沒有 callback，則已經購買的玩家可以繼續玩。

當然這個作法有個漏洞，如果玩家先前購買了但之後交易被取消（信用卡繳不出錢之類的），而遊戲打開的那次檢查 SDK 剛好沒有 callback，則玩家可以繼續玩。這個漏洞，比起已購買的玩家突然發現自己不能玩，是比較好的選擇。

修改過後的版本已經送審，希望這兩天可以重新上架！

此外，代理台灣地區 Google Play 行銷的（還是）F 公司，在我們計畫上架日期已經錯過了一天之後（！），突然想起來，忘了要求我們在遊戲開始的畫面加上他們 S 平台 logo，於是，打火弟兄再次義無反顧的出動了：

好了，危機處理的第一個步驟就是心理建設：了解事情永遠不會像我們想得那樣順利的進行。第二個步驟是在處理問題的時候，想想看這段程式碼做了什麼假設，再想想如果假設失敗的情形或許可以看到問題發生的原因。

說到這裡，Google Play 台灣的版本又有狀況了，在預定上市日期過了兩天之後（！！），收到代理商的訊息：他們 Google Play 的帳號在付費的部分還在等 Google 審核，預計最快一週後開通。在心理建設後，想想原先的假設：台灣的玩家都很期待。然後再想想這個假設不存在，唔為什麼我沒有感覺好一點 >"<

心情隨筆 by some programmer

2012-05-02T16:56:00.001+08:00

「生也有涯，學也無涯，以有涯追無涯，殆矣」

莊子

曾經，一位影響我很深的程式設計作家很生動的寫下了“資訊焦慮症候群”（很高興我還找得到他的文章：1995.08），那是所謂資訊開始爆炸的年代。

在將近二十年後的今天，我想可以姑且稱之為後資訊核爆的年代吧 :)
我很難想像今天資訊工程科系的學生，面對龐大的資訊如何能夠不感到徬徨迷惑。

嗯，我想我把層次拉得太高了，身為後資訊核爆時代的我們，無論你是不是程式設計師，首先必須面臨的就是 email 和 Facebook 的轟炸。所以有人好心的提醒了我們：每天必須清空的五件事。清空 email？我想八成以上的人都沒做到。所以，停掉你從來不會看的電子報，只處理真正重要的 mail 吧，然後一天結束之前，把還沒讀的信件 mark read，甚至砍掉吧。就像那些路上錯過的大多數路人一樣，我們沒有緣分～

Facebook 是個可怕的東西，許多人把大半人生都花在 Facebook 上而不自知，每三分鐘就要看一次，搭車時一直看，上完廁所後也要檢查看看，睡前更是必看，睡不着還要爬起來再看。歐買尬，要戒掉 Facebook 就像戒掉抽煙一樣，說來容易做到的人少。就從一個下午不看開始吧 ><

然後你會發現，不看 Facebook 不每隔三分鐘檢查一次 email，還是有很多東西會黏着你，twitter 就是這樣的東西，在程式設計師圈子裡似乎頗為流行，一些該死的 browser plugin 或是手機 App 更非得無時無刻提醒你有新的推文要看！這是另一種 email 的轟炸。停用這些東西吧。

回到程式設計師的身上，有人利用禪學幫助自己定下心來寫程式：禪道程序員的10條原則。重點就是 focus，一次做好一件事。不過大部份的我們，似乎總是需要花大半輩子才能說服自己，多工模式（一心多用）是很難寫好程式的。我看到好多年輕的朋友，總是能夠一邊看文章一邊收 mail 一邊聽音樂一邊聊天一邊偷瞄走過去的女生，同時還能一邊寫 code，非得等到夜深人靜的時候工作效率才能達到最高。時間拉長來看，他們的產出並不比朝九晚五的人來得高。Focus，是這個年代的程式設計師最重要的修煉。

說到 focus，你有沒有試著去找過現在有多少種程式語言？光聽過名字就不下四五十種，有一種資訊從業人員多年來的學習狀態就是，X 語言學到一半，就聽說 Y 語言更厲害，於是開始學 Y，然後又聽說 Z 更厲害。這樣是很難精通一種程式語言的。但我很有興趣什麼都想學怎麼辦？還是 focus，選擇一種技術，學習並且用它來做至少兩三個真的產品。你不可能每兩三個月就換一套語言還能專精。

關於程式語言，聽說現在許多學校只教 Java（請參考 Joel 的文章），Java 當然是很好的程式語言，BUT，如果你想成為“好”的程式設計師（好而非頂尖，頂尖牽涉到天賦，而好是可以透過苦練而得），你非得了解程式底層執行的細節，就像 Joel 提到的，無法徹底了解 pointer 和 recursive 你的功力會有很大的侷限性。我的看法是，還要加上 multi-threading，沒有徹底瞭解執行緒在遇到 concurrency 就會有很大的盲點，不知道 multi-thread 程式為何可以執行，又為何會當掉。而即使你只是寫 Android App，multi-threading 也是必定會碰到的東西。

所以在你的學習清單裡面，請不要遺漏了能夠讓你學習 pointer / recursive / multi-threading 的“低階”程式語言。C 是個不錯的選擇 XD

說到低階，現在還有在寫組合語言的程式人員應該不到 1% 了吧？程式設計大師 Knuth 在他談演算法的書中卻堅持使用組合語言，他認為只有透過組合語言你才能完全掌握程式底層運作的一切細節，而程式設計師的優劣，正是取決於你對底層運作細節的掌握程度。

你是自學程式設計的人嗎？我是。因此我非常樂於知道麻省理工學院有把許多課程公開：OpenCourseWare。裡面你可以找到美國頂尖學府用來培養學生的課程，像是 Joel 提到過的 6.001 課程，我才開始自學。最近頗為熱門的 functional programming，在 6.001 中是教材的一部分（而已！），而這門課還只是電腦科學系學生的第一門程式設計必修課程。哇嗚，你感受到他們課程的強度了嗎 XD

寫到這邊，我也該切換回開發模式，回去專心 coding 了，我這個單工又低頻的傢伙～

邦妮的早餐賣到哪去啦

2012-05-02T13:56:00.000+08:00

邦妮的早餐移植已經告一段落有一段時間了，為什麼還沒上市呢？(~冏~)
原來遊戲不是程式寫完上架賣然後就等著收錢了(哈哈這不是早就知道的嗎)

認真點～是這樣啦，我們在談遊戲代理。在遊戲接近完成，開始著手處理行銷和營收的事情後，發現不少事情和當初規劃 (想像？) 的不同，一點經驗分享給大家。

首先，我們移植的平台是 Android，在開發很後期我們都還是希望能不走廣告路線，但在和 Google 台灣負責 Google Play 的人談過之後，我們發現，除非你已經是知名遊戲發行商 (EA, Rovio...)，否則排行榜中的熱門 App，不管你是賣道具或是分免費/付費版，基本上廣告營收都佔據一半左右的收入 (！) 有 iOS 銷售經驗的開發商，對於這點應該滿驚訝的，不過這是 Android 市場的特性。

另外，關於某些地區無法賣App (我們最熟悉的就是台灣啦) 以及 In-app Billing 等爭議，我發現各種傳言都有，目前確定的資訊：

台灣：無法賣 paid App, 但可以 In-app Billing (別再相信不實的傳言，台灣是可以遊戲內賣道具的)
大陸：無法賣 paid App, 也無法 In-app Billing！

需要特別注意的是，只要你的 App 有 In-app Billing (程式會宣告BILLING permission)，那在大陸地區的 Google Play 是連出現都不會的，換句話說，你完全進不去這個市場。

關於中國這個市場，還是以通路為主的市場，想賺錢得找像中國移動這樣的電信商，透過它自己的收費機制收錢。這也是目前我們花最多時間在談的部分。

可以想像，在 Android 平台，有許多在地化的收費機制，因此你的 App 在收費這部分需要花點心思，讓這個模組容易抽換。

最後，合作夥伴先前在 iOS 的經驗告訴我們，限時免費是很有效的衝高使用者的手段，我想在 Android 上免費促銷的手段可能更為必要，這點留待上市後再和大家分享啦。

PS: 還有一個 (從內部) 聽來的數據可以分享：如果你的 App 要錢而且賣了一千套，那你可以預期轉免費之後平均下來可以賣 20 倍，也就是會有兩萬人免費下載來用。想搞限時免費的朋友可以參考一下～

歐 One more thing，順利的話，五月中可望看到邦妮在 Google Play 上賣早餐 (中國除外.. 那還得花點手腳，才能搞定)

近況更新 Bonnie's Brunch

2012-03-14T21:20:00.000+08:00

Bonnie's Brunch 移植到 Android 版本終於達到 alpha 版本！已經開始測試階段，相信不久後可以跟大家見面囉！簡單抓幾張畫面先跟大家分享囉：

這張是主選單，最重要的按鈕是那顆"Buy Full Game"^^

關卡選擇畫面，邦妮的早餐採用分數低標解除下一關的方式，從1-1開始，達到低標的分數後就可以前進到下一關，而且低標很容易達到，我看到的玩家大部分關卡都第一次就達到了～

每一關開始會介紹這關即將登場的人物或道具！

遊戲進行中！客人頭上顯示他想要的餐點，玩家利用下方的道具製作餐點交給客人後即可得到分數。每個客人都有不同屬性，有的客人沒耐心，有的客人喜歡點難做的早餐，也有美女客人出現後大家會變高興的。畫面右方的客人是食評家，讓他高興也可以增加其他客人開心程度，不過，萬一讓食評家等太久生氣走掉就完蛋了，因為其他客人也會跟著走掉呢！

遊戲當中有設計特殊關卡，客人一個接一個排隊，看你能用多快的速度服務客人，就能得到越高的分數，搭配緊張的背景音樂，玩起來可是相當刺激的呢！

此外，遊戲中有非常詳盡的教學，給第一次玩的玩家上課，保證一次就上手！（遊戲教學可是花了我們很多心血製作的呢，即使會玩了也請花點時間欣賞一下嘛XD）

以上是邦妮的早餐的簡介，接下來還會需要一點時間測試，除錯，以及效能優化，以確保所有玩家都能有最棒的遊戲體驗！請再稍微耐心等待一下 :D

Java Programming Pitfall - GC

2012-02-01T14:30:00.000+08:00

My current project is a small game on Android. My game continuously GC (garbage collection) even nothing happend (no touch input, no game event dispatch, only openGL rendering). The frequency of GC is very stable: every 9 seconds, this clearly has something to do with the game's main loop. But even turned off rendering did not help. I started tearing off game entity (which runs on every game loop) and found GC frequency reduced but still not gone. After extensive reading main loop code, I found root cause of the GC:

    // in main loop
    // ...
    Collections.sort(objects, comparator);

I found its a logical error to do this sorting in every frame (sorting is required only when something add to or remove from objects). So I fixed it and GC is gone at all.

Further investigation about Collections.sort I found:

    // in java.util.Collections
    public static  void sort(List list, Comparator comparator) {
        T[] array = list.toArray((T[]) new Object[list.size()]);
        Arrays.sort(array, comparator);
        ...
    }

The "new Objects" caused GC if done enough times. So you should use it with caution.

Further discussion: reduce sort only reduce GC frequency, not eliminated it. To do that, I need to quit using ArrayList, replace it by primitive array, and use Arrays.sort.

Also, I wonder if there is better method to find out the cause of such GC except reading lots of codes. I think on Android, execution profiling should be a good place to start, since the code which caused GC must be executed often enough to take a place on the profiling result. In my case, the code which invokes the sorting is number five in execution time distribution. If I start with the profiling, I can found it without extensive reading codes long main loop!

Programming Pitfall

2011-12-26T17:18:00.000+08:00

For programmer (beginner -- intermediate)

One computer architecture book that I spent lots of time reading when I was a student, was "Computer Architecture, A Quantitative Approach". There is a section called "Fallacies and Pitfalls" for each chapter, which highlights stuff to watch out when designing a computer. I find the name pitfall suitable for my article which records interesting bug I encounter. And hope my article may help people prevent making same mistake, or at least reduce the time when looking for similar bugs :)

First pitfall I'd like to share is a Java ConcurrentModificationException. Let's take a look at following code segment:

public Entity removeEntity(String entityId) {
    Entity result = null;
    synchronized (entityList) {
        for (Entity entity : entityList) {
            if (entity.getId().equals(entityId)) {
                result = entity;
                entityList.remove(entity);
            }
        }
    }
    return result;
}

The synchronized part is because entityList may access by another thread. Above code generates ConcurrentModificationException at runtime. Once I spotted the word "concurrent", I start looking for code which access entityList without synchronized guard. After checking out all the code, the exception keeps arising at exact same point of code flow. This behavior makes me suspect that its not concurrency issue, because that issue tends to arise at seeming random different points. So I take a look at document for ConcurrentModificationException then I realized I was trying to iterate the list AFTER one element removed. So the fix is simple:

public Entity removeEntity(String entityId) {
    //Entity result = null;
    synchronized (entityList) {
        for (Entity entity : entityList) {
            if (entity.getId().equals(entityId)) {
                //result = entity;
                entityList.remove(entity);
                return entity;
            }
        }
    }
    //return result;
    return null;
}

Funny part of this story, is that if I had not jump into conclusion that this is a synchronization problem once I spotted the word "concurrent", I could have figure it out soon... So do not judge a bug by its name, is the lesson I learned here.

OpenGL Checking List

2011-12-20T12:15:00.001+08:00

Target audience: programmer / OpenGL ES

Even experienced OpenGL programmer can be trapped from time to time, so I made a checklist as a reminder :)

Can't see a thing?

Is viewport set?
Is projection setup? (GLU)

Texture not working?

Is texture enabled?
Is texture client state enabled?

Keep updating...

A Quick Overview of Android ICS 4.0.3

2011-12-18T15:26:00.002+08:00

As Android user, my previous experience was on Nexus S with Android 2.3.7, and I haven't got my chance to use 3.x. Recently I got OTA update to Ice Cream Sandwich (4.0.3). Lots of stuff changed, while many remained. Here's a quick overview.

First, you can jump to Camera from unlock screen, which should be convenient for many users.

Here's the new Home screen. At the bottom, there are 5 sticky buttons, from left to right: phone call, contact, all app, SMS messages, and browser.

Screenshot for adding App shortcut. There are still 4x4 cells. A convenient dropping cell preview is provided. You can now drag to upper-left area to uninstall the App, or upper-right area to show App details. To remove shortcut, long press App icon as usual and drag it to upper area (now changed to remove).

The upper area of Home screen is a sticky search bar. Tap on it to start searching, for both local content and the internet. New feature I saw here is Google provides keywords you have searched before, even keyword from your PC.

In my humble opinion, voice input is one of the best feature on Android, and it just getting better! During my test, I speak (in Chinese) a long sentence, and I can see it translating my input into Chinese while I keep speaking on and on and on! Really amazing. Also the translation quality is good enough for practical usage.

Now, this is the most impressive part of my entire ICS experience: the web browser. The scrolling is just smooth, compared to my previous experience. I can imagine they had done a lot of optimization in webkit. So it improves not only the browser, but also your HTML formatted emails. You got to try it out by yourself.

As a programmer, I was really impressed by the amount of improvement done in software, can improve overall user experience with such a magnitude on the same hardware!

Another stuff I noticed, is the widgets. On ICS, the division between widget and App is becoming blurred. As widget becomes more powerful, you can do more things on Home screen, such as reading email/twitter and G+/Facebook updates. So developers, we should start thinking seriously about design widget for our Apps now.

A slightly difference I notice, is the order of Yes/No buttons. It's reversed! Quite annoying at first for I used to hold my device with left hand, and I can't reach Yes button with my left thumb...

There a lots of updates to build-in Apps of course, but I don't have time to blur personal info out of the screen captures. Lots of UI pattern changed, such as moving confirm button from bottom to top of App. Overall experience is not bad, for you can notice obvious performance enhancement.

As a developer, I hope UI patterns will not change too much in foreseeable future, so we can update/create our App in sync with the lots of new design!

Happy Birthday to Studio Irregular!

2011-12-13T15:56:00.001+08:00

I started working as independent software developer precisely one year ago, and it turned out to be my most inspiring and interesting working experience I've got. I got my chance to working on project like Kloud Photos, which was totally originated from my own idea. And co-working with partners on projects such as Dejabook and Iceberg.

I've been looking around searching for designers to work together, but turned out no luck. It seems every entrepreneur's looking for good designers too, so I guess I am not alone :)

Even things not working out as expected, I keep remain optimistic. I get up early in the morning everyday, and go out for exercise if weather allowed. Then I take shower and breakfast, and started working. When I feel tired, I go to sleep. When I got stuck, I go out for biking or hiking. When I feel lonely, I visit friends. All these are just too luxurious for people who working for company, and I can't live without them now :)

By the end of the first year, I've been given the chance to work on game industry, which by my definition is all about bringing fun to people. And it's just great! I already looking forward to see how it works on my second year!

Happy birthday to my studio!

沒規矩新聞中心

2011-12-05T14:10:00.001+08:00

打從2010年底創業以來，我一直在找尋合作的設計夥伴，很高興我找到了。

樂風創意視覺是一家遊戲設計公司，投入遊戲產業超過十年的時間，早先專注在遊戲美術外包，承接過國內外許多知名遊戲的專案，去年投入遊戲設計，第一款作品今年(2011)在 iPhone 上市：Bonnie's Brunch。

我認為這款遊戲：

定位明確：針對女性玩家，不限定特定語言/地區。
美術風格很棒：從(多國的)使用者回饋得知大部份玩家最喜歡的部分是美術。
銷售成績不錯：在台灣三天內登上銷售第一名，在許多亞洲國家銷售成績也不錯。

沒規矩工作室與樂風展開合作，我們要將 Bonnie's Brunch 帶到 Android 手機上！預計在2012年第一季與大家見面。敬請期待！

經過第一年工作室的草創時期，部落格接下來會做出一些改變：

專注
我們是個技術導向的工作室，我打算定期發表程式開發相關的技術性文章。
國際化
技術性的文章會以英文寫作，以接觸到最多的觀眾為目的。
遊戲導向
部落格開始會以遊戲為導向，遊戲程式開發為主。

遊戲設計這個領域對我而言既熟悉又陌生，熟悉的是高中時期除了玩 PC game 之外，自己也設計遊戲，曾經看完一本小說後感動之餘，用 Quick Basic 語言刻了一個RPG遊戲的地圖系統，主角可以在上面移動，和角色對話 :)

陌生的是早年對遊戲設計的興趣，沒能轉變成一份遊戲設計的工作，如今十幾年後再碰到，遊戲設計對我已經是個全新的陌生領域。這回，看看我們能碰撞出什麼火花！

ICEBERG 專案的程式開發接近尾聲了，週末 (12/4) 我們在政大創立方舉辦了公開測試，找來不少正妹參與 :)

場面熱鬧之餘，我們也從會後問券收到不少寶貴的建議，也抓到好幾個 Android 版本的當機(冏)

下階段我們打算把這 App 介紹給夜店，然後想辦法要店家付錢給我們 XD

Quick Tip About HTTP Post on Android

2011-11-08T21:45:00.000+08:00

To do HTTP post on Android, there are two packages as far as I know:

With java.net you create URL, open connection with HttpURLConnection. Then you setRequestMethod with "POST". You also setDoOutput with true. Then you getOutputStream and starting to post data to the output stream.

With java.net you can also receive data from server with same HttpURLConnection instance, by getInputStream.

Notice your output data usually needs some encoding, in my case, I do encode with java.net.URLEncoder with data I output.

Now, I find life gets easier with org.apache.http. You first create URI, then create HttpPost with that URI. Then you setEntity with data you want to post. And create HttpClient to execute the HttpPost. After execution, you can check server returned status code by checking out HttpResponse.

Here's some code snippet about using org.apache.http

// prepare post data, assume in name-value form
List<NameValuePair> data = new ArrayList<NameValuePair>();
data.add(new BasicNameValuePair(name, value));

// now do http post
URI uri = new URI(urlString);
HttpPost httppost = new HttpPost(uri);
httppost.setEntity(new UrlEncodedFormEntity(data, "UTF8"));  // switch UTF8 to your encoding

HttpClient httpClient = new DefaultHttpClient();
HttpResponse response = httpClient.execute(httppost);

// check status code
int statusCode = response.getStatusLine().getStatusCode();

// read response from server
InputStream is = response.getEntity().getContent();
// ...

PS: a good book about network programming with java.net is Java Network Programming.

創立方開幕記實

2011-11-03T10:00:00.000+08:00

2011/11/3政治大學開辦的創立方舉行簡單的開幕儀式，現場看到二三十位進駐的工作者，校方代表Vicki老師以及他們的工作人員，媒體和外部參觀人員，大家在輕鬆愉快的氣氛中聚在一起聊聊關於創業。

創立方

也許不少朋友不知道創立方是做什麼的，我自己是在參加今年九月份Startup Weekend Taipei活動的時候知道這麼一個地方，在這邊認識目前合作的夥伴，我們也一起在這邊租辦公室作為開會討論的地點。簡單說，創立方提供創業人員一個工作的空間，一個彼此交流的平台。今天一位vpon來的朋友問我，目前台灣有不少創業“育成”中心，為什麼選擇創立方？我說因為我覺得這邊的環境單純，創立方和創業者之間沒有資金投資等等的利益糾葛，而且這邊十分自由開放，你可以改造辦公室，舉辦研討會等等，不會有許多規定告訴你什麼能做什麼不能做。

開幕儀式主要是進駐的人員簡單自我介紹，你可以聽到五花八門的創業項目，從最常聽到的App開發到交友網站服飾搭配藝文表演到先進的server技術研究影片製作 3C產品回收等等。所以我自己一個很深的感觸是，在從事startup的朋友，一定要走出自己的小圈圈，看看第一線的創業人員在想什麼在討論什麼在做什麼。

下半場是一場演講，他們找來Albert這位待過矽谷和中國然後回來台灣的創業家，他目前創立的公司Pebbo是一家很難想像在做什麼的公司 :) 他給了我們一場很棒演講，主題是創意設計，除了幾段印象深刻的video之外，我印象最深刻的是他在Ｑ＆Ａ的時候強調的觀念，idea本身其實不像大部份的人想的那樣值錢，把它執行出來而且做得好才值錢。我也觀察到不少顧問/設計公司很怕自己的idea被客戶學走，這應該是來自傳統製造業的思維，我的產品成分/配方被你學走，你就變成我的競爭對手，但在知識密集的領域，Google/Facebook不但不怕你的程式用他們家的服務，反而還鼓勵你用他們的服務，最好能創新組合出新的玩法。簡單來說，你的idea並不那麼值錢，值錢的是你找到這個idea背後的人/方法。

最後分享一下創立方Vicki老師的幾個不錯的觀念，她說台灣有不少創業育成中心，像台灣大學也在籌辦當中，大家的優勢都不一樣，創立方focus在人才的leadership培養上面，我認為這是個不錯的方向，創業不外乎資金技術和人才，其中又以人為這一切的中心，雖然我不認為有標準作業流程可以培養一位Steve Jobs出來，但不可否認的優秀的領導人才需要有適當的環境才有機會長出來。期望創立方可以成為這樣一個藴育人才的環境。

ＰＳ：我們的辦公室基本上就是教室，像我們待的這間有十幾位創業人員一起使用，這兩天我們稍微佈置了一下這個空間，接下來應該會買一些傢俱來充實這個空間！