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

GitCafe發表於2015-02-02

圖片描述

“在一個晚上我的母親問我今天怎....麼不開心”
“我說在我的想象中有一個小遊戲...摩擦摩擦...”
(神經病 -_-|||)

事情是這樣的,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

相關文章