「老文補發」寫在GitBubble上線以後

「在一個晚上個人母親問我今天怎....麼不開心」
「我說在個人想象中有一個小遊戲...摩擦摩擦...」
（神經病 -_-|||）

事情是這樣的，2014 年 11 月底的某一天傍晚，我正在電腦前思索如何增加咱們 GitCafe 的微信粉絲數，一直一來，咱們 GitCafe 的微信公衆號粉絲數其實徘徊在 2000 左右，基本上咱們的粉絲天天僅保持着 10-20 的增加。在咱們的「程序員會生活」系列專題面世以前，咱們在微信的內容運營上不是這個活動就是那個活動的信息發佈，訂閱咱們微信公衆號的小夥伴也是知道這點的。

沒錯，能夠說是至關的單調、枯燥。而此時距離 2014 年的聖誕節剛好還有一個月。

「咱們 GitCafe 是否是能夠來一發什麼有意思的東西呢？」

伴隨這個想法，我腦子裏忽然就回想起當年的一個奇葩遊戲——「圍住神經貓」，這個遊戲上線 48 小時以來，PV 達 1026 萬，IP 達 241 萬，而它的開發時間僅一天半，美術一人，程序一人。

想一想就shi了是吧，當時我心裏的真實心理活動是這樣的：「咱們也來作一個小遊戲看看咯，試試看病毒營銷怎麼樣？無論最後它會不會火會不會有效，試試總不會有錯的咯！」 而事實上呢，我在加入 GitCafe 以前作了 2 年的 Java 程序汪，來 GitCafe 以後才轉型做了市場，在這以前對於什麼是市場並不沒有深入的認知，對 「病毒營銷」 這個名詞都也只是 「大概就是那麼回事兒」 的水平。但是這些都沒法抑制我心中的一團熱火，感受這件事，在這個時間點，咱們應該去作，並且相信必定會作得好。

懷揣這股熱情我立刻在一張 A4 上手繪了一個簡陋的效果圖，並寫了幾個大概的規則。咱們的老大 Thomas 和市場總監 Richard 看完草圖並聽完個人想法後也表示了支持，並示意鼓勵咱們放手去作。（這裏也要感謝託尼瑪在工做上給予的極大自由度）。

次日我帶着那張原始的草圖把個人想法告訴了 G-Room 的小夥伴們（G-Room 是 GitCafe 內部的神 (xie) 迷 (jiao) 組織，有機會下次給大家介紹），他們也表示了強烈的支持。而特別幸運的是，咱們的前端工程師 Ryan 具備至關豐富的移動端開發經驗，開發一個基於 Html5 的遊戲對他來講根本就不是個事兒。當天晚上我開始畫起了 GitBubble 的原型圖。但畢竟我不是做設計出身，再加上 Ubuntu 狗找不到什麼好的原型設計軟件，因此...我是用金山的 WPS Presentation 畫的，是的，就是這麼任 (diu) 性 (ren)。

你們能夠看下當初的原 (cu) 型 (cao) 設計：

這裏有個小插曲：爲了給個人PM演示我到底要什麼效果，我不得不在Presentation裏一個個加好動畫效果，使它看起來像那麼回事兒，下面是當年的效果(說多了都是淚)。

原型視頻地址:
http://v.youku.com/v_show/id_XODUzODYwNzY4.html

次日我拿着這套Presentation去給Ryan演示效果，得到了確定的回覆「能作，不難。」接下來的事情就像是一場線下的Hackathon那樣，我拿着個人Idea和原型依次說服了咱們的前端王子Ryan、型男插畫師Kawi來做個人搭(da)檔(ye)。固然，一個項目要進行的順利須要一個PM，我厚着臉皮邀請Gina幫助我在項目任務分配及進度管理上多費點心。
這裏要再次感謝咱們的前端小王子Ryan，那個時候他還在忙於咱們GitCafe Enterprise版本的前端工做，可是在看完Presentation後沒幾天，他就作出了第一個基於html5的GitBubble原型，大家感覺下。

你們其實已經能夠看出這個原型雖然還很是樸(chou)素(lou)，可是在遊戲機制上已經初見雛形。爲了豐富整個遊戲的質(B)感(ge)，省得上線上被你們吐槽成過於low的遊戲，我又對於一些規則作了細化，這裏給出部分設計文檔內的內容，因爲咱們GitCafe團隊成員骨子裏那股對產品快速迭代的追求，其中有部份內容已經和如今你們手裏玩的GitCafe有所出入：

……

規則:

1.戳破（手指點擊）帶有Git/GitCafe 命令的泡泡便可得分
    1-1.點擊任意帶有GitCafe命令泡泡 + 100分
2.戳破空白泡泡會扣減時間
    2-1.目前設定 - 1s 
        (因此玩家能夠選擇犧牲時間來戳破若干白色泡泡 有機會去戳另外一個帶有相同命令            的泡泡得到加成得分) 
    2-2.點擊白色泡泡 沒有分數 （或者扣50分 這個在模塊裏先作成 - 0 分就好）
3.連續戳破相同有效泡泡會得分加成
    3-1.得分公式  f(cnt) = 100×2^(cnt-1)
    3-2.cnt: 同命令泡泡連擊數 (因此靠相同泡泡刷分能很厲害！)
4.吃到帶有GitCafe泡泡會加時間
    4-1.目前設定 +5s
5.泡泡會從小變大，最後會自動爆炸
6.泡泡變大速度會變快（意味着爆炸會愈來愈快）
    6-1.f(s) = 2^(s/2)
    6-2.s:泡泡存在時間(秒)
7.隨機出現Shake事件：
    7-1.Shake事件出現時，其餘事件暫停：
        7-1-1.泡泡出現、變化的速度會變得很慢不會出現、變大、消失
        7-1-2.計時中止
    7-2.Shake事件得分：
        7-2-1.上下晃動手機
        7-2-2.得分公式：f(times)=10×sqrt(2^times)
        7-2-3.times=Shake期間 手機晃動次數
    #此時須要搖晃手機進行刷分
8.Game Over後出現的界面：
    8-1. [關注GitCafe]：引導用戶關注GitCafe微信公衆號
    8-2. [曬一曬]：曬分數到朋友圈
    8-3. [再來一發]：從新開始

……

在對這些細節作了進一步的規範化後，GitBubble的可玩性又上升了一個檔次，可是咱們的界面依然很樸(chou)素(lou)對不對？

因此說，人有時候不得不認可本身是多麼的 Too young, too simple, sometimes naive

那天上午從Slack上看到Kawi給出下面2張圖的瞬間，房間裏每一個人嘴裏只蹦出了2個字--「臥-----槽------！」，大家再和當初我設計的原型比較下，是否是有股屌絲逆襲高富帥的感受

慢慢地，Tips 畫面、泡泡爆炸效果、得分效果、Shake 界面動畫、結束畫面......這些元素一個個從 Kawi 神奇的腦殼中跑到了現實，再由 Ryan 以一個個 document.getElementById() 和 function 去賦予生命。因爲咱們的素材很是精美，因此咱們又不得不得對運行效率問題表示擔心。咱們不斷的去尋找各種手機做性能測試，雖然在主流機型上上表現很是不錯，可是在一些老舊機型上一些動畫效果並不能很好的展現，對於這些用戶咱們真的表示很是抱歉，咱們尋找了不少方法試圖作到優雅降級，但很遺憾的是對於那些過於老舊的機型——「臣妾真的作不到啊T^T」。

….

很快，時間來到了 2014.12.19 。

這是一個值得記念的日子，GitBubble 實裝了全部的得分、扣分、加時間、Shake 事件的功能，僅分享功能還沒有實裝，這意味着什麼？一個最最接近完整版的 GitBubble 完成了！

我異常興奮地拿着這個版本的 GitBubble 給幾個同事去試玩，其中最厲害的那位玩出了當時的最高分 31W。

可是問題也來了：
a.點擊泡泡後，得分在泡泡內顯示，致使 「戳破」 的效果有延遲
b.增長時間的 GitCafe 泡泡與普通泡泡無差別，不具有強烈的用戶品牌認識度
c.本因做爲彩蛋出現的 Shake 事件刷分收益太高，遠高於戳泡泡收益，影響平衡，還不如叫 GitShake……
…….

——系列的問題擺在咱們面前，怎們辦？

「怪我咯？」 各個改呀！

做爲程序員出身的我很是理解 PM 汪頻繁更改需求的感覺，當時真的生怕我剛一開口向 Ryan 提需求就被回一句 「U can u up,No can no BB」 -_-|||。可是咱們的前端王子 Ryan 很是爽氣地就開始着手修改代碼，並告訴我如今就是讓你們多挑刺，多挑刺多修改多迭代才能讓咱們的產品是拿得出手的！碰到這樣的程序猿還有什麼好說的，我要是個女的分分鐘給他生孩子啊！

晚上下班的時候我在地鐵裏再次打開咱們的 GitBubble，又有了新的意外，GitBubble 的素材大小將近 1MB，地鐵裏的信號基本只能維持 10 幾 K 的速度，甚至還有部分 CSS 加載不徹底致使畫面奇葩無比的狀況。但你要知道地鐵偏偏是我很看中的一段碎片時間，地鐵行徑兩站平均花費 2min，而 1 局 GitBubble 的遊戲時間正好處在 [1,2] min 這個區間以內。

怎麼取捨？

無奈，我再次詢問 Ryan 和 Kawi 是否能夠進一步壓縮素材材質尋找一個素材精度和素材體積的平衡點。當時 Ryan 的一句話馬上打消了這個念頭——「咱們作的是一個遊戲，是一個有質量的遊戲。」 真是醍醐灌頂，確實，咱們寧願讓咱們的玩家多話幾秒鐘下載好素材去體驗一個有厚度的遊戲，也不肯意隨隨便便塞給用戶一個粗製濫造的小做坊做品。在產品質量的打磨上，不管是對於 GitCafe 這個主線產品仍是對於 GitBubble 這個支線附屬物，咱們都一樣重視，這是我司逼格。

大家可能覺得事情到這裏就 Happy Ending 了，那句話怎麼說來着：理想是豐滿的，現實是骨感的。

2014.12.23 冬至

咱們計劃的上線時間是 2014.12.23 下午 4 點，或者說是對外公佈的時間更加準確。我在 22 號的下午開始陸續聯繫了幾家關係不錯的小夥伴但願上線後能幫咱們推一下這個小遊戲。做爲咱們 GitBubble 雲主機服務的提供商 UCloud 天然成爲重點內測夥伴。在暗搓搓的保密協議下，UCloud 的小夥伴們很積極的成爲了咱們的首批內測用戶。

事實證實咱們的內測用戶都很是給力並且十分專業。欣怡，UCloud Mkt一姐，大家別看她成天朋友圈說本身是腦慘兒童歡樂多自黑小霸王其樂無窮，關鍵時刻這種牛逼人物表達專業見解的時候一點都不含糊。試玩結束後立刻就一通電話告訴咱們遊戲在市場策略上考慮不周的幾點，並提出了許多很是寶貴的建議，老實說一開始我也是蠻執拗的沒聽進去，可是回頭想一想她說的頗有道理，本身真心圖樣圖森破，感謝欣怡感謝 UCloud。恩，今年託尼馬還有 32 場裸奔秀（僞） ，你要不要拿張觀摩券？（大誤）

哦對，而後又是一場項目迭代的修羅場，Ryan 不哭站着擼。
…...

再後來，GitBubble 就長成了各位如今看到的樣子，和其餘遊戲相比，咱們在遊戲質量上徹底有自信有底氣說 GitBubble 一點都沒必要它們差，甚至比他們要好得多。GitBubble 是 GitCafe 作的第一個移動端小遊戲，也多是最後一個。它能活多久我不知道，它會不會火起來我也不知道，可是我知道在這開發的期間，咱們經歷過的那些點滴。咱們遇到了許許多多不曾想到的問題，咱們有的選擇了克服有的選擇了妥協，但最終，咱們把它實現了。若是說 Ryan 賜予了 GitBubble 骨骼與血肉，那麼 Kawi 則賦予了 GitBubble 極佳的氣質與長相。感謝兩位一直以來的辛苦工做把個人一個小小 Idea 變成了現實，感謝 Ryan 每個工做到凌晨 2-3 點的週末，感謝 Kawi 在繁忙的工做中還能做出如此完美的視覺設計，也感謝咱們的 PM在整個 GitBubble 項目週期中給與的建議與支持。

最後附上 GitBubble 的地址：
http://gitbubble.gitcafe.com/
推薦使用移動端微信瀏覽器打開，你懂的。(請點擊「閱讀全文」)

今天是 2014.12.24 ，咱們的 GitBubble 剛剛正式上線 1 天，在這個平安夜，但願咱們的 GitBubble 能給各位帶來一絲溫暖和歡樂，感謝各位。

Merry Christmas & Happy New Year！

最後附上GitBubble的地址：http://gitbubble.gitcafe.com
推薦使用移動端微信瀏覽器打開，你懂的。

--- GitCafe 專業打雜 George @Gu_Bonjour