Category Archives: Game

tash kalar feature

Tash-Kalar

在棋盤上放置棋子,組成特定的排列來使用卡牌,消滅對手的棋子或完成目標來取得分數。遊戲中很多設計都令小弟驚喜萬分!是小弟的最愛之一。

遊戲時間:中等(60分鐘)
玩家人數:2至4人
學習難度:易
思考難度:難
部件體積:中等
官方網站:http://tash-kalar.com/index.html

從上圖就可以了解這遊戲的主要行動了:放置棋子並完成卡牌的排列要求後,卡牌會在白色的方格所對應的格子中產生較強的棋子,並發動其效果。

遊戲簡介

  • 遊戲有三副不同的卡牌組(四種顏色,但紅色和藍色是一樣的),每玩家各選一副。
  • 玩家輪流行動:放下初級棋子,使用卡牌,或換手牌
  • 使用卡牌前在棋盤上要預先準備好所需求的排列,卡牌會在對應的格子產生新的棋子,而該格子不能有一個比新棋子強的棋子。
  • 如果對手的棋子比你多出指定數量,則可使用”爆發卡”(Flare)發動其免費效果。
  • 死鬥模式:殺丟對手的棋子來獲得分數。
  • 任務模式:完成任務卡的要求獲得分數。

遊戲分析

  • 很多人都把這遊戲定為抽象遊戲,但小弟認為也不是完全的抽象-至少有卡牌可用已經比所有抽象遊戲實在得多。而且卡牌的排列和效果,都和卡牌中的角色有密切的關係,這令玩家能感到非常強烈的生命力。
  • 遊戲時的思考時間非常之長⋯⋯雖然因人而異,但在很多情況下卡牌的組合和排列的可能性都很多,遊戲的容錯性不高(一子錯對手就翻盤了),小弟的最長記錄是一個回合用了二十分鐘⋯⋯不過砌排列就是這遊戲的精髓,正如你去看別人下圍棋不可以嫌別人下得慢一樣:P
  • 遊戲中令小弟驚奇的地方,除了它能把抽象的下棋方式和生動的卡牌結合的天衣無縫之外,就是”爆發卡”(Flare)系統。本來小弟以為這只不過是對太弱的棋手隨便給予一個免費行動,但玩過幾次後就發現這簡直是神來之筆!原來遊戲過程中很容易出現一面倒的情況:多棋子的一方較易出卡牌吃對手的棋子,造成更多棋子更易出卡牌。但有了Flare,這遊戲出現了180度的改變:在任務模式中較少棋子的一方能打出較多的Flare,反而成為了優勢!整個遊戲變成了以最少的棋子來達到目的,或設法令對手浪費棋子。棋子的分佈有著明顯的重要性,不能亂打亂吃然後給對手反勝。(不過棋子太少時選擇也就少了⋯⋯)
  • 如果你試過圍棋,但覺得圍棋的難度太高,所需要記下的定式太多而卻步,不妨試一試這款遊戲。

這遊戲是由著名的桌遊設計者Vlaada Chvátil所作。Vlaada在網站提及他本來不太喜歡抽象遊戲,也不喜歡二人對戰的遊戲,思考完一輪然後令對手很不爽地輸丟的感覺。但近年手遊狂熱,他就在他自己的遊戲想法庫中找出一個畫面簡單的遊戲並希望制作成手遊,也這是Tash-Kalar的初型。他在設計過程中的心情想必也很忐忑,但在測試時發現輸丟的玩家也很樂意再玩這遊戲,所以也相信這遊戲能帶來歡樂,也就繼續研發下去。

小弟看完了筆者的一番話感觸良多,除了因為小弟也是手遊程式員,這遊戲本來也令小弟感到可以打破”令對手很不爽地輸丟而感到不快”。小弟在網上玩遊戲時,即使勝出也會因為對手沉默地離開而感到無奈。但玩這遊戲勝出時,卻能與對手談論一番,或說”這遊戲很有原創性,是時候研究一番了”。這令我感到桌遊的真正力量,不是智慧的角力,而是享受和交流。原來Vlaada對這方面也有很強烈的感受。再者,看到Vlaada大神寫了程式版的遊戲然後自己和自己對玩,身為手遊程式員的我卻沒這麼試過,感到有點汗顏⋯⋯

逃出亞特蘭堤斯 (Survive: Escape from Atlantis!)

控制自己的隊員和船隻,離開正在陸沉的亞特蘭堤斯,以及控制生物去阻止對手逃出。

遊戲時間:中等(60分鐘)
玩家人數:2至4人
學習難度:易
部件體積:中等

遊戲簡介

  • 每人有十個隊員,每個都刻有分數。每個玩家輪流把隊員放在中央的島上,然後每個玩家再放兩只船在島的周圍。
  • 玩家輪流開始回合,每回合做三個行動,每一個行動可以移動一個隊員一步,或者移動一個被玩家控制的船一步。在水中游水的隊員每回合只能移動一步。
  • 完成行動後玩家把島的其中一塊陸地磚塊拿走,該格成為海洋,然後執行陸地磚塊背面的指示,或者把它拿起成為玩家的道具。
  • 拿走陸地磚塊後,擲一個骰子決定玩家能移動那一類動物:鯨魚能破壞載了人的船,鯊魚會吃丟一整格裏所有正在游泳的人,海怪會連人帶船都破壞。
  • 隊員離開島嶼到達岸邊則得到相應分數。

遊戲分析

  • 不同分數的隊員有不同的作用:高分的成員要離開,低分的成員可控制船隻阻止對手離開。遊戲沒有指明每一個隊員的功能,但從分數上的分別就讓玩家能自行取捨。
  • 和別人合作控制船隻離開,或者坐在船中讓對手開船,然後控制別的隊員離開,或者把船駛離岸邊⋯⋯簡單的船機制也有不同的變化和互動。
  • 由玩家控制海洋生物是一種簡單的做法,但也可能出現直接針對玩家的現象,而且這機制對勝負的影響很大。基本上被吃得多,或者高分隊員被吃就輸丟比賽,但這部份跟玩家的技能和幸運性關聯不大。可能玩家應考慮如果和其他玩家交涉減少自己的隊員被吃。

兇煞迴廊 (Fearsome Floors)

簡單的逃跑遊戲,玩家的目標就是躲開怪物,把自己的隊員逃到終點。也可以利用隊員的位置阻止對手的移動,或控制怪物的移動。

遊戲時間:中等(60分鐘)
玩家人數:2至7人
學習難度:易
部件大小:中等

遊戲簡介

  • 每人有3至4個隊員,不同隊員在日間和夜間的移動力都不同。每次玩家行動時控制一個隊員移動,反轉它表示該隊員已經行動了並顯示下回合的行動量,然後到下一個玩家行動。
  • 當所有隊員都已移動,怪物會根據怪物卡向前移動。當怪物發現任何隊員時,他會轉向最近的隊員並吃丟他!
  • 特殊情況:如果多於一個隊員和怪物接近,怪物會傻傻的繼續血前進。
  • 怪物碰到牆壁時會在另一個位置出現。即使怪物離開出口很遠也可能碰到牆壁傳送到出口附近!
  • 基本模式中會有一些石頭,可以用作遮擋怪物視線。複雜模式中有更多物品改變怪物的移動模式。

遊戲分析

  • 簡單的怪物移動邏輯,沒有隨機因素令它改變路線,在移動隊員時卻難以遇料怪物的走向,因為任何隊員都可能會令怪物轉向,或製造特殊情況令怪物不轉向。在所有隊員完成行動前,怪物的行動路線都難以確定。
  • 當大部份的隊員位置都確定時,玩家可以利用自己的隊員引導怪物轉向,令其他玩家的隊員被吃!

一網打盡(Cash-a-Catch)

搶拍的拍賣方式,對抗性的買賣,挑戰玩家對物品價值的估算速度

遊戲時間:短至中等(30分鐘)
玩家人數:3至5人
學習難度:易
部件體積:中等

遊戲簡介

  • 由某玩家開始一張一張地拍出貨品卡牌,首先按下按鈴的玩家可用十元購買所有拍出的貨品。拍賣完成後到下一位玩家拍賣。
  • 玩家只可以扣留三類的魚,多餘的魚要丟至垃圾箱,在遊戲完結時扣分。
  • 玩家拍賣前可賣丟魚箱內的魚,同一類的魚的數量越多價值越多。

遊戲分析

  • 搶先購買的拍賣方式很特別,而且變動的不是拍賣價,而是貨品。
  • 在搶先的情況下考慮貨品的價值,對手得到的獲利,和拍下下一張魚卡的風險,對遊戲的經驗有一定的要求。正如一般反應遊戲(twitch game)一樣,是一個易學難精的遊戲。

賽駱駝(Camel Up)

就是估算賽果的遊戲,完全是風險和收益的衡量(risk versus reward tradoffs)。

遊戲時間:中等(30至60分鐘)
玩家人數:2至8人
學習難度:易
部件大小:中等

遊戲簡介

  • 玩家輪流作一個行動:擲骰子決定駱駝的移動,拿取一張中段投注卡,放置影響駱駝移動的指示物,或放置一張賽果投注卡。
  • 先投注的玩家能獲得更多獎金。
  • 後來居上的駱駝會疊在同一格的駱駝之上,當下面的駱駝移動時會帶動上面的駱駝一同前進。這令賽果更難遇料,亦令遊戲出現搞笑的狀況。

後來居上的駱駝會得到戲劇性優勢,這令賽果難以估計。但如果不去冒險投注,擲骰子卻會令賽局明朗化,令後來的玩家得益。先行投注可能有更大利潤,但風險也比較大。

那金字塔型的骰子盒是一大亮點!本身就是一個外型很有趣的物件,也保證了只會出一粒骰子。

這遊戲的平衡性難以估量⋯⋯但這就是一個歡樂的賭博比賽,不要太認真就是了。

政變(Coup)

抵抗組織(The Resistance)的另一作品,也是每人有隱藏身份的遊戲,這次玩家不是隊制對決,而是個人對決:只有一個勝利者!

遊戲時間:短(15分鐘)
玩家人數:2至6人
學習難度:易
部件體積:小

遊戲簡介

  • 每人抽取兩個秘密角色卡,代表玩家對該角色的影響力,每種角色有不同的能力。遊戲主要是收集資金,然後使用資金去解除其他玩家的影響力。當玩家失去所有影響力時,他就輸丟了該場遊戲。
  • 當玩家使用角色的能力時,並不需要展示該角色卡。其他玩家可提出質疑,如果被質疑的玩家展示了相應的卡牌,提出質疑的玩家則失去一個影響力,否則被質疑的玩家失去一個影響力。

遊戲分析

  • 隱藏身份直接影響玩家能力的遊戲可算是罕見。富饒之城也算是其中之一,但身份立刻在能力使用後被展示。玩起來感覺很像吹牛(大話啤),但卡牌的能力令遊戲變化很大。
  • 遊戲的對抗有自由的目標選擇,對抗方式也非常直接,所以被針對的玩家就會輸丟遊戲@@(小弟還是喜歡德式桌遊⋯)不過遊戲簡單明快所以輸了也沒相干~再來一局就是了~

正如抵抗組織的作風,遊戲只有很少部件(五個角色,每個角色三張,和一些金錢指示物),卻有豐富的遊戲性。卡牌製作也非常精美。

Zombicide

在KickStarter很有名氣的合作打喪屍遊戲,遊戲版圖很大,很多模型,但玩法卻很簡單。

遊戲時間:中等(60分鐘)
玩家人數:1至6人
學習難度:易
部件體積:大

封面

滿街都是喪屍!!

遊戲簡介

  • 遊戲有不同的戲情,包含不同的地型,特殊物品和勝利條件。不同的角色也有不同的能力。
  • 每回合在指定地點就會在喪屍進入,或者在打開房門時在室內會發現喪屍。喪屍每回合會向玩家移動一格,或向在同一格的生還者攻擊。角色被攻擊兩次就會死亡!玩家可利用物品發出的聲響控制喪屍的移動方向。
  • 特殊的喪屍能每回合行動兩次;大型喪屍只有特殊武器才能對付。
  • 角色停留在室內可以找尋武器和工具,也可能會找到喪屍!武器和工具可用作抵抗喪屍。
  • 角色擊殺喪屍會提升等級,但新加入的喪屍會因應最高等級的角色而增加,所以玩家要管理好每個角色的擊殺數,甚至減少擊殺喪屍來完成任務。

 

OLYMPUS DIGITAL CAMERA

勃艮第城堡(The Castles of Burgundy)

在boardgamegeek.com排名11的遊戲,遊戲重點是擲骰子決定行動的可能性,買賣貨品或擴建城市。

遊戲時間:稍長(九十分鐘)
遊戲人數:2至4人
學習難度:易至中等
部件體積:稍大

封面

遊戲進行中!

遊戲概要

  • 擲骰子決定玩家可以拿哪些建築物,把建築物建在哪處,或賣出哪些貨物。玩家可使用工人去改變骰子的數值來增加選擇。
  • 大部份建築物在建造後立刻發生效果,只有少數建築物有持續效果。
  • 玩家可透過買賣貨物或建造某些建築物來賺取銀幣,用作購買建築物,但每回合只能購買一次,而且數量有限。
  • 玩家可透過建造農場,特殊建築物,或完成區域(用同類建築物填滿區域)來得到分數。建造同類的農場,或較早完成區域的玩家能得到額外分數。最高分的玩家勝出遊戲。
  • 建築物的選擇隨著玩家的拿取而減少,在每一階段開始時保充。每個玩家在每回合有兩個行動,每一階段有五個回合。遊戲在五個階段後結束。

遊戲分析

基本分析

  • 由於建築物種類比較多,新玩家需要花一些時間去了解建築物的功能。
  • 遊戲的平衡性:
    • 每階段保充的每種建築物的數量都是指定的。
    • 玩家可透過建造船隻改善行動排序。
    • 玩家的建設規劃是預先設定好的,不會出現太極端的建設規劃(例如全部都是農場⋯)。
  • 遊戲中很少正反饋系統(positive feedback)。大部分的建築物也沒有持續效果,即使有也不會有很大的影響力,未見到一些疊加性效果令回合效果倍加的情況。
  • 玩家的取捨主要在於優化行動的順序和工人的消耗上。消耗工人能得到更好的選擇,但消耗得太快的話會浪費更多的回合去獲取工人。由於較早完成區域的玩家能得到額外分數,而且回合有限,越少回合則能建的建築物越少,浪費回合意味著得到較少分數。
  • 玩家之間的主要競爭在於建築物的選擇上:農場的種類,先完成哪類建築物,特殊的建築物,有限的出購建築物。

衝突輕微

感覺上就是哪種和一名玩家爭同一資源就令第三者得益的遊戲。遊戲得分的方向很多,在遊戲進行的前部份衝突較少。

回合效益

和卡坦島比較,這遊戲令每個玩家的行動質量都相差不遠,不會出現像卡坦島中獲取資源的差異很大的情況。幸運性也只在工人的消耗上去體現,這也能由資源分配上去改善。與其說它是骰子行動遊戲不如說是使用工人的考量。整體來說主要都是回合效益和分數的計算。

Playmaker_DuelingBlades

PlayMaker 初試

PlayMaker係一個Unity Plugin for Finite State Machine (FSM),
可以drag & drop咁edit個state diagram。
如果你試過用code寫有關state ge嘢你就知道佢有幾好啦XD
其實買咗佢好耐一直冇時間試,
而家終於可以試返夠本:P

 Asset Store – Playmaker
Playmaker_DuelingBlades
DreamfallThumb

基本功能

  • 建造一個State
  • 喺個state度加transition(每一個transition對應一個event),定義個transition會去邊個state(drag個transition就會拉到條箭咀出黎)
  • 喺個state度加action,一到呢個state佢就會做曬成個state嘅action。本身有好多action可以㨂,或者自己做custom action
  • Action可以控制send邊個event同幾時send,如果個state有相應嘅transition,個FSM就會switch去個transition所指嘅state
  • State可以接收global transition,無論佢本身喺邊個state一收到global event都會跳去相應嘅state
  • 有variable可以用。當喺action填資料嗰陣可以直接填上值或者variable。可以令variable顯示喺inspector度
  • 一個FSM只有一個current state(呢個絕對係feature唔係limitation!)。當個editor play緊個FSM dialog會highlight current state/行過乜嘢state。可以喺個state度set break point做debug,亦可以即時睇到每個variable嘅值(睇到值呢個feature應該歸功於unity XD)

用途

  • Organic AI - 好多時生物嘅AI都係一個FSM:patrol,follow,fire,die⋯
  • Trigger - 例如一度門,有”打開”同”關閉”兩個state
  • Stated Control - 如果做一尐複雜嘅control,例如touch dragging gesture,可能會需要考慮”touch down”之前同之後,”touch up”之前同之後做唔同嘢,有2至4個state
  • Stated UI – 例如Button會有Enable/Disable兩個state,或者可能會有唔同state show唔同function

如果用code做FSM,
好可能就係一個function implement一個state,
未必做到尐同state有關嘅功能,
例如返到上一個state,檢查執行緊乜嘢state,
離開state個陣做某尐action,從外部接收event等等。
更改transition可能要search返個function喺邊,
然後夾硬改個function call@@
改code個陣又要好記得個workflow係點,
或者要自己做好個doc記低佢。

PlayMaker嘅好處就係你做個個machine本身就係一個diagram,
做FSM有關嘅改動都好方便。
佢亦要求每一個state/event都要命名,
其他人一睇唔知detail都知道個大概。
就算係自己改返自己嘢,
見到個diagram都會remind返好多嘢。

缺點

1. 每一個action都係一個script
雖然可以做custom action但係比較麻煩,
就算係做加減乘除都要用action做,
所以如果做大量procedural嘢就會好煩,
一個一個action係咁加會耐過打幾行code好多。
不過可以用send event嘅方法call其他MonoBehavior,
PlayMaker FSM就做返FSM相關嘢然後call 其他script procedure。
如果佢有個好方便嘅UI link去相關嘅script就正囉~

2. 重用性低
例如有一個state有好多action,
想做另一個有同樣action嘅state只可以copy and paste⋯
(或者save template再paste返出黎但係都係冇分別 lol)
除非你做咗個custom action出黎比唔同嘅state用。

3. 唔支援array
本身係冇任何同array有關嘅action/variable type,
更加唔洗講looping。
就算做咗同array有關嘅custom action,
looping 好可能都係由兩個state互相指住黎做。
暫時未諗到有咩好方法可以處理,
大不了所有array有關嘅嘢交返曬比script做

4. Edit mode有bug
呢個可以話係最大嘅缺點~_~
有時undo嘢會有bug(undo的確係唔易做嘅事⋯),
好多時undo完要reload個editor先見到佢係undo咗,
有時改完action sequence之後field value會錯@@
總之做完嘢save咗先,有咩事就reload個scene :P
不過當你做好個diagram去run就未見到有bug,
都係edit個陣尐細bug無傷大雅

其實頭兩個缺點都可以用custom action解決,
而且做custom action都幾好玩㗎XD
大家有興趣可以試下。

初試後感

第一次試我故意將所有都用PlayMaker做,
成個UI Logic同Control都係,
結果當然好悲劇XD

Screen Shot 2014-06-08 at 10.43.14 am

因為每一個button都起碼要做一個state,
咁十幾個button就有十幾個state,
再加幾個state去check邊粒button比人禁,
就變咗一個大到唔想睇嘅diagram XD。

亦由於state嘅重用性低,
加一個case又起碼要加一個event一個transition同一個stage,
為咗方便又要加一個variable(下面再詳細講),
所以如果想加一個同之前類似嘅button都要搞一輪zzz

當中有個FSM設計咗幾個global event,
諗住好似function call咁,call一個event做一樣嘢,
但係每次call都要用幾個action去set幾個parameter,
再用一個action去call,
可能仲要寫多個stage去等個FSM return

結論當然係應該將同FSM冇乜關係嘅嘢抽返比script去做XD
同埋個diagram唔應該做曬個UI hierarchy,
簡單尐講就係唔好一個button一個state,
唔好搞到個UI越多個diagram越大。

啱啱上手個陣會有少少唔知尐state放邊度嘅感覺,
(我嘅意思係放喺diagram邊度,純綷係用家視覺問題XD)
不過用咗一陣之後就OK,
一排stage最好就打直排唔好打橫排~

以下係尐值得注意嘅嘢:

  • Annoying Active Browser
    我唔知Windows版係咪都係咁,我用Mac版開咗PlayMaker Editor之後佢個自動開Action Browser,然後用Cmd+Tab去另一個panel個陣佢會loop住select PlayMaker Editor <-> Action Browser。解決方法就係將Action Browser merge去PlayMaker Editor,成為同一個panel
  • Event “Forwarding”
    “Get Mouse Button Down”  Action係會等Mouse Button Down然後sent一個event 。如果一個state用”Get Mouse Button Down” Action去下一個state,而下一個又有”Get Mouse Button Down”,咁下一個state又會因為咁去再下一個state。因為佢用咗Unity嘅”Input.GetMouseButtonUp”,同一個message loop都會收到同一個result。
    仲有呢個唔知係唔係bug:如果喺state A收到event 1會去state B,然後state B收到event 1會去另一個state,就算個FSM只係收到一個event 1都會連續跳state,更可能因為咁出現dead loop。所以某尐位我會delay 0.1秒先send event。呢個問題有待查證。
  • Variable for GameObject value
    就算你想reference嘅GameObject係喺個scene度,我建議你開個variable裝住佢而唔係直接set落個action度,一來要改動嘅時候只要改個variable就改曬全部action,二來可以display in inspector令你見到曬呢個FSM用緊邊尐GameObject
  • FSM callback
    如果FSM A等FSM B做完嘢先去下一個state,但係又唔想FSM B直接reference FSM A(Modular Programming!!),可以喺FSM B開一個GameObject variable,係FSM B做嘢之前set個variable做FSM A,再用”Send Event By Name” action 通知個variable ge FSM。不過咁做令呢個callback只可以有一個receiver(PlayMaker冇支援array⋯)。或者call script再call其他FSM。
  • Save FSM as a Prefab
    如果你唔將個FSM GameObject save做Prefab,然後你個project上咗version control同人地夾黎做,咁個scene file其他嘢conflict咗就會連累埋個FSM。但係save做prefab之後prefab嘅variable對scene GameObject嘅linkage會冇曬,然後又好可能會出尐不必要嘅error(尤其是”Call Method” action)
    解決方法係所有action都唔好直接reference GameObject,而係用variable
    至於”Call Method”我就直接comment了CallMethod.cs第102行(errorString += “Behaviour is invalid!\n”;)
    記得唔好改prefab FSM然後revert to prefab,如果唔係連scene嘅FSM variable都冇曬reference。應該係改scene FSM然後apply to prefab

改良提案

  • Script linkage
    如果可以加粒掣係同script有關嘅action度,一click就彈去個句function就好囉,不過unity plugin黎講應該做唔到。
    或者做一個script execution action然後可以加幾句script。
    Variable嘅class應該要implement operator,唔洗下下都會dot佢個value出黎
    現在:variable.Value = value;
    建議:variable = value;
  • Every frame
    好多原有action都有”Every Frame”呢個flag,用法係當個FSM stay喺嗰個state個陣,個action每個frame都會做嘢,唔洗做多個transition過一個frame loop比自己咁煩。但係唔知點解唔係個個action都有。其實應該要改到個super class本身就有
  • Comment Block
    我見其他graphical programming都會做一個冇用ge rectangle放喺一堆note下面說明個堆係乜,可以寫埋字做說明

以我所見PlayMaker都算係幾好玩幾幫到手嘅嘢,
有賴Unity Asset Store尐update都做得幾好,
雖然要比錢買但係值得一試~

程式內購(In-App Purchase)價格定位

寫咗兩篇內購嘅文,
講咗內購質素嘅問題(程式內購(In-App Purchase)分類法),
而家講吓內購嘅價格問題。
我相信好多玩家(包括我自己)
都對某尐遊戲嘅內購格價格有質疑,
咁內購嘅價格又點定呢?
我認為應該由內購嘅本質去評估

內購嘅本質(一):一個實在嘅產品

聽起嚟好似「呀媽係女人」,
但係你諗真尐,睇下人地對內購嘅論述,
又有幾多人真係以「內購係實在嘅產品」嚟睇?
又有幾多開發者以呢個原則對內購定價?
依我睇真係冇乜邊個。
將呢一句說話諗深多層,可以拆開以下幾個概念:

一個需要成本去做嘅產品

開發者比咗金錢時間去做,當然想賣多尐錢,唔係搵鬼做咩~
一個內購,
令程式員做多幾多嘢,
令美術畫多幾多嘢,
令音效/音樂做多幾多嘢,
令遊戲設計者諗多幾多嘢,
全部都係成本。

一個有市有價,有供求嘅產品

就正如一隻下載收費嘅遊戲一樣,
你隻遊戲多人玩,賣貴尐當然好正常,
但係要睇清楚一點,
手機遊戲有冇所謂供不應求呢?
當然係冇啦係咪?唔通太多人下載iTunes Server會死咩?~
就算隻遊戲係網上遊戲要用到server,
server service都唔係咁易會供不應求,
更加唔會話越多人玩個人均成本就上升。
所以我認為就玩家人數而言,你隻遊戲多人玩,
都唔應該因此比冇咁多人玩嘅遊戲賣貴太多。
當然你可以因為名氣大而賣貴尐,呢個下面再講。

好多人將個槪諗放咗入遊戲入面,
覺得遊戲本身就係一個市場
遊戲入面嘅內購就根咗個內購對遊戲嘅影響嚟定,
例如遊戲入面有尐有限嘅卡牌,
然後令玩家炒過個價,比好多錢開發者。
呢個係一個好錯嘅諗法!希望係開發者或者玩家嘅你唔好咁諗。
當然影響力大嘅內購就會貴過影響力細嘅內購,
喺呢度我好難說服開發者,
但係作為一個精明嘅玩家請你諗清楚,
一隻遊戲嘅定價係幾多。
希望你識得一隻遊戲嘅總付出,預先作一個評估,
然後唔好出多過嗰個價。
記得要向唔同嘅遊戲格下價睇清楚,
真正嘅市場係「遊戲業界」唔係「遊戲世界」。
當然,你有錢,比多尐,我唔會反對,
但係我都希望你係了解咗先,覺得值,先至比。

其實只要你諗下,
一隻做咗好耐嘅大作,例如Diablo 3,賣緊四百幾蚊,
一隻做咗唔知幾耐嘅網上遊戲,有人每個月比緊幾千蚊玩,
就會覺得有尐問題。
冇錯一個遊戲仲要睇埋有好多唔比錢嘅玩家,
冇錯我講過以前嘅遊戲定價太低,
但係新式嘅遊戲都應該根據市場,理性地去定價。

P.S. 好多人都唔鍾意尐開發商將尐遊戲抄黎抄去,
但正正只有當該類遊戲有足夠多人去做,
先可以明確地定價。
如果開發商做出一個同另一隻遊戲好類似嘅遊戲,
但可以開發更大嘅市場,或者有助遊戲定價,
咁佢就係做緊好事,係良性競爭。

一個有藝術成份,有名氣成份嘅產品

一個藝術品值幾多錢,一個有名氣嘅品牌可以令產品提升幾多錢,
我認為呢個先至係除成本以外,令內購價格提升嘅最有力理由

攞一尐實物卡牌遊戲做例子:Magic the Gathering
每張牌都好認真畫都好鬼靚,
而佢亦都係出名喺遊戲平衡性同多樣性上面做得好,
佢賣嘅卡有幾貴,大家可以做個參考。

又例如League of Legend (LoL),
唯一一定要比錢嘅內購係外表(Skin,只係令角色睇起嚟唔同),
亦都係有名「最多人玩嘅網上遊戲」,
佢個價都可以攞嚟做參考。
而且值得留意嘅係台服外表比美服平。

一個買咗令自我感覺良好嘅產品

其實同上一個論點差唔多,
又攞返LoL為例,
買左一個英雄外表比其他人睇,
有種好似自己好有眼光嘅感覺。
雖然呢種虛榮感有尐爭議性,好似唔係好健康,
但係我覺得呢種虛榮感應該都算係娛樂嘅一種,
反正遊戲就係娛樂係咪?玩下啫~

產品就要有明確付費指標

亦即係話賣家要令買家可以估計比幾多錢先得到佢要嘅嘢
「冇明確付費指標」就即係話買家比咗錢之後又唔知洗唔洗再比。

例如你買咗一個洗衣機,佢壞完又壞要係咁比錢,
咁就係一個「冇明確付費指標」嘅例子,
因為你唔知佢幾時又壞,賣家一開始又冇同你講,
成件事好似比人呃咗咁。
所以而家買電器都實包埋保養,
咁買家就清楚:比XXXX蚊起碼用到幾年。

又例如你比咗一個RPG嘅價錢去買一隻RPG Game,
點知打完第一關就要你比錢先玩到第二關,
你一定會告到佢甩褲啦係咪?
咁亦都係一個「冇明確付費指標」嘅例子,
因為賣家冇令買家知道個價只係買「第一關」,
玩家比錢前亦估計唔到玩曬個遊戲要幾多錢。

至於有尐遊戲一開始唔洗錢,但係入面有好多內購,
咁就未必係「冇明確付費指標」,
呢個問題要睇遊戲業界嘅一般做法,同埋開發者有冇清楚說明。
如果遊戲業界有一般做法,
咁作為玩家應該有能力去理解並估計支出,
唔可以話唔知然後話人地呃你。
或者有尐遊戲要一直比錢先玩到,
咁只要開發者講清楚係咁,玩家知道大概一個月要比幾多,
亦都唔算係「冇明確付費指標」。

內購嘅本質(二):複合市場嘅分水嶺

呢個內購功能只適合於某「免費增值商業模式」(Freemium Business Model)。
呢度係只係考慮某尐包含會比錢同唔會比錢玩嘅玩家嘅遊戲。

呢個世界一向都係貧富懸殊㗎啦~
如果你話有錢嘅人出曬錢,令一班冇錢嘅人都有錢玩,
你話幾咁和諧呢?XD
而家就係有一個咁嘅方案:
冇錢嘅人一世唔比錢,都仲可以繼續玩,
有錢嘅人比好多錢,得到佢想要嘅好處。

呢種做法可以話機乎所有Freemium遊戲都用緊。
遊戲世界一分為二,甚至更多,
唔同付費能力嘅人玩緊唔同嘅平衡設定
(並唔係話開發者令比錢嘅人有著數,
而係做遊戲平衡嘅時候要考慮唔同付費能力嘅玩家)。
不同嘅內購就係不同平衡設定嘅分水嶺。

而呢條數就要計計佢啦,
假設你隻遊戲要每玩家平均每月比十蚊你先夠數,
而比錢嘅人最多得10%,
咁就即係話比錢嘅人平均每月比一百蚊你先夠數。

用呢個模式嚟定價嘅時候,
設計者就唔應該高估付費玩家嘅百份比,
亦即係話,要接納大量嘅非付費玩家
呢個估量係由市場而定,
付費能力較高嘅一群就係大概少於10%。

內購嘅本質(三):試用期嘅限制

最簡單嘅例子就係開發者本身就諗住賣一百蚊,
但係轉左做免費下載,限住你玩幾耐玩幾多,
然後要你用一百蚊開放所有嘢。

如果用呢個邏輯嚟定價,咁個價就好簡單,
就係成隻遊戲嘅總價值,當返佢係下載收費咁睇。

個案分析

以下指出一尐具爭議性嘅個案,用上面所提及嘅邏輯分析一下:

解放功能

解放內容嘅爭議性應該唔大,總之開發者成本增加當然可以收費,
但係將”功能”當作產品咁賣就有得拗。
我認為如果個功能係開發者額外投放成本去開發,
或者會增加維持成本,
咁當然都可以收費。

例如LoL入面嘅英雄(開放使用英雄嘅功能),
好多玩開Dota嘅人可能會覺得佢Lock住曬尐英雄唔比人用,
但係其實佢每做一隻都要人物/外表/技能重新去做,
個人認為都係值得比錢支持嘅。

但係如果嗰個功能本來就係遊戲嘅一部份,
只不過係一個外加嘅限制令你用唔到,
例如一隻RPG本來你可以行嚟行去,
但係佢限咗你只可以行十步,再行就收錢,
咁我就會用令一個角度睇,就係「試用期限制」。
如果佢個收咗一個錢就乖乖地比曬你玩,咁就OK。
如果佢呢度收完嗰度又收,缺乏收費指標,就似係呃人囉~

節省時間/能力提升

一尐多人連線遊戲嘅內購令玩家節省時間或者能力提升,
可以用「複合市場嘅分水嶺」呢個邏輯嚟定價。
作為比唔起錢嘅玩家喺呢個模式下能力會較低,
但係亦都有好處:就係唔洗錢玩。
如果你唔比錢根本過唔到關,咁就唔好玩啦~

一尐單人遊戲嘅內購令玩家節省時間或者能力提升,
可以用「試用期限制」呢個邏輯嚟定價。
如果你比一次錢唔可以永久地節省時間或者能力提升,
亦即係開發者冇乜持續性開支下係咁收你錢,
咁就好可能係唔合理,

買家得益VS開發者成本

曾經有開發者會設計一個能力強大嘅內購,賣好多錢,
而開發成本只係好少。
作為精明嘅玩家就要清楚內購定價唔應該只係睇買家得益,
為遊戲而付出嘅總支出應該要以遊戲市場而定,
以「一個有市有價,有供求嘅產品」嘅邏輯去定價。

賣家要考慮買家想法,買家要了解市況

其實講到尾內購就係一個新式收費方法,
大前提都離唔開原有收費方法嘅概念
只要大家都覺得合理,其實可能性可以仲有好多。