[經驗] 雲端夯肉2020設計心得與檢討
這是來自中秋的限定線上烤肉活動。
這個靈感是來自離開學校後,與朋友們協商烤肉時間時,總是因為相隔兩地或是班表對不上等問題,最後只好找間餐廳隨便聚聚又匆匆忙忙離開時的有感而發。
表達式留言板讓大家輪流做主角
雲端烤肉有一個很重要的概念是來自看著隔壁家的大學生們悠哉的聚眾烤肉,那是只有一張白紙的青春,正準備寫故事,所以我決定提供一個平台,並把說故事的權力交給了來夯肉的人們:食物可以自由命名。
也因為這個概念,就算是知道是哪些人使用程式洗版,且系統保有踢除惡意攻擊系統時,我也不打算做任何動作,因為不知道未來會怎樣的才是故事,例如有人用程式碼買冰塊;就會出現用程式碼買木炭的人,最後只要在一旁負責笑就好了。
沒有殺生、沒有污染、不用保持社交距離、不用清潔隊打掃環保烤肉
這是一個百人烤一個烤盤的社會實驗,就像是 Twitch Plays Pokémon 中秋烤肉版本,因此這主要不是聊天室,而是一場遊戲,介面必須簡單且直白,目的就算不明確也要有一個目標。
聊天室的設計
基本上大家都陌生人,所以沒人會打算在留言板說話是一開始就確立的方向,除了一些基本的溝通,不如用事件來填滿這個區域,再透過烤物的翻面與收回功能把你想說的話呈現給所有人。
後續檢討
一開始藉由聊天室呈現添加木炭冰塊時效果是好的,可以有效呈兩邊的拉扯,但在腳本開始加入後,就造成了大量訊息堵塞事件排程與造成手機設備當機的狀況發生,應該把大量的重複設計透過像是 Facebook 表情泡泡那樣,並在累積一定時間後把統計傳到客戶端降低系統壓力。
特效的設計
雲端夯肉在定時間會有中秋煙火的發放,在大麻烤的剛好時會有迷幻彩蛋效果等等,能使畫面有更多驚奇,也能讓人們在追求小木屋時有額外的目標。
後續檢討
- 彩蛋太少,且提示不夠容易被忽視,要求火力合理的情況下也辦不到。
- 煙火特效容易導致行動裝置卡死。
食物的設計
雖說大家可以自由設計,但食物內還是得有一些相對的背景,開發時有人提議說想烤吉娃娃,所以衍伸出了外星人這個商品,試圖引導使用者去發想。
當然事後的發展不會這麼簡單,海星的目的當初只有想到喔好棒三點了,沒想到後續成為各種嘲諷專用的商品。
食物的獎勵本質商品兩面烤得最佳的情況下分配其價值的 1/10 ,但在價位10 萬起的商品必須折損到 1/100 成為有效加速並防止過度通膨的存在。
後續檢討
- 可以建置垃圾回收機制,不然香料幫實在太瘋狂了,有大半的時間配合高火力讓所有人只能獲得一元。
- 超過 10 萬後的商品缺乏鑑別度,直接烤外星人(30萬)實在很多。
- 試著讓彩蛋搭配商品額外獎勵的說明。
阿婆柑仔店的設計
阿婆柑仔店就是簡單的商店入口,不止販賣我們常吃的商品,也偷偷地販售著違禁品與野味,別怪阿婆不擇手段,她可是兩天賺入 2472133108 台幣的最大贏家。
後續檢討
- 商品的排序在行動裝置中一眼能看見的東西太少了,試著使用 2 個商品排版模式。
- 讓使用者可以看到柑仔店的收入。
- 可以在柑仔店看到一些常買商品的排序與歷程(發票?),還有一些統計數據。
火力的設計
一開始最高火力就是一百,有鑑於限制本身就是缺乏發展的代名詞,因此採用朋友建議的開發某個提升火力的管道,所以添加了失去理智的源頭:啤酒。
在活動過程中有人提出為什麼木炭 +4 火力而冰塊只有 -2 火力,是故意設計給兩強相爭時,有人把火力鎖在 1 的話大家都不用玩了。
後續檢討
- 或許可以考量一間限制火力的休閒烤肉房。
- 最低火力不該是 1 的。
- 火力失控是早晚會發生的事,由於不能因噎廢食,我還真的沒有想到對應方法。
金錢的設計
小木屋是個意外,但這個意外成為了這個系統最成功的部份,原因是我們一開始打算設計成兩百萬,因為如果加入的人數不多的話能考到兩百萬就是極限了,但我不小心多打了一個零。
過去所有製作的遊戲中,最棒的設計都是意外。
遊戲發放的獎勵金非常少,主要的收入是利用涓滴效應,透過烤完肉後的紅利分發,也就是必須呼朋引伴才能完成結局,雖然人多起來就開始被大火和香料洗版,但到了末期為了買下小木屋也能看見大家團結一心開始購買紅利最多的外星人與控制火力維持品質。
後續檢討
- 這樣的設計容易讓人想要屯房而不願意花錢,很值得反思。
- 是否要上線才能領到錢,其實這值得糾結,因為我也懶得掛著。
- 可以有另一種累積的管道,例如飽足感設計。
烤盤的設計
翻面是烤肉的精華,朝向火力的那一面烤熟的速度是另一面的兩倍,不翻就是烤焦,造成紅利減少,且必須兩面都烤熟才拿夾下烤盤,當人們想把你快速夾下烤盤,就會幫你翻面。
而烤肉醬就是不認同的議題,可以用烤肉醬把它抹掉,外星人:GUN-841是最多人抹掉的商品,如果你去查一下番號大概能理解。
後續檢討
- 夾起商品的人應該出現名子。
- 夾到自己商品應該有相對應的獎勵,還是以共享為主值得思考。
- 夾起來的人與買商品的人沒有綁定在食材上,少了一些數據可以統計有點可惜。
程式與管理面的設計
從發想到發布僅有三天的時間,大量的系統漏洞會被攻擊是預料之內的事,但也好險這幾年來沒有白混,系統崩潰並無找上門來。
之所以決定只為期兩天,純屬系統有逐漸失控的傾向,從後續的通膨來看也是對的,未來的下一個版本大概也是為期兩天。
後續檢討
- 最糟糕的就是我們把公告也寫在聊天欄中,在大量事件狂洗的情境下,有發等於沒發。
- 由於所有資料都儲存在記憶體,如果出現死機等問題會功虧一簣,或許Docker + Nodejs + MySql可以試看看。
- 要好好的處理一下 GA 和網域的問題才行,有許多人被 ADB 給擋住了。
- 採用第三方驗證制度,這次的自由進出機制導致洗錢與洗版叢生,雖然說這是一個陌生專案必須承擔的風險。