2020年9月5日 星期六

花在別人身上的錢 比花在自己身上還要快樂?

每個人願意消費在遊戲上的額度上限是不一樣的

與其透過機制鼓勵玩家消費更多 不如讓具有更多消費額度的玩家消費更多在這些 消費能力有限的玩家身上

這是我最近跟朋友討論的議題 太多遊戲設計的是彰顯自己的價值 利用自己有強力的裝備與角色來做炫耀 讓他人吹膨自己 但當自己的強度膨脹到一個無人可及的地步時 就讓這些高端的消費族群流失掉了 很簡單 高處不勝寒 我是第一名了 然後呢? 頓時失去目標了 遊戲內容也很容易就被這些高端玩家以碾壓的方式體驗完 玩家的最後就只剩下競爭與聊天 而當成為第一 是孤單的

這類高消費者 為何願意砸重金來玩這款遊戲 絕對不要自吹自擂說 因為自家遊戲產品設計的好 而是這個玩家本身的條件與特質 如此而已

所以我在想把他的消費讓更多人收益 既然遊戲營運有9成的營收靠著5%的金字塔玩家在供應著 就應該要設計一個能夠讓他們持續消費的機制讓他們能夠保持遊玩動機與消費額 而這些玩家是需要這些低消於無課玩家去支持他們在遊戲中的地位

待續…

2020年7月25日 星期六

系統功能 社群好友

我們來談一下社群好友功能吧

大部分的連線遊戲經營到後期,不外乎會需要社群去維持遊戲的活耀人數,
而良好的社群機制,可以提高玩家願意持續進行重複遊戲操作的體驗,
重點是人的反應在遊戲中所帶給玩家們的驚奇感,往往是遊戲機制上難以去呈現的


營運面:
待補充...

設計目的:
1. 提升玩家在遊戲中的生命週期
2. 藉由玩家在互動的過程刺激消費

設計初衷:


設計要領:
玩家之間的連結性越強,越不容易流失
玩家互動的過程產生樂趣


設計方法:
待補充...


玩家面:
待補充...


玩家動機:
利用對方玩遊戲玩得好的特性
可以邊玩邊聊天的特性
一起玩會有額外獎勵的特性

利用自身優缺點找平衡的方式
喜歡用自己的玩法玩 但又有缺陷 找其他玩家補足自己的缺陷

心理預期:
待補充...


體驗過程:
玩家感覺是在跟人玩遊戲
期待好友玩家上線

玩家手段:
1. 拉現實中的好友一同遊戲
2. 認識好朋友

成功經驗不能複製 但失敗的可以




Unity UGUI使用心要



UGUI 把設置SetActive開關 做到Canvas.enabled 這樣子 所有的Awake and Start就可以呼叫到了
然後開關所耗的效能就會變得更小

Canvas 靜態與動態面板要分開 靜態面板要勾static

何謂靜態 就是不改變 RectTransform內部的參數。可以做單純的開關變化與其他參數調整

禁止使用Awake 與 Start 在會開關的物件上,自己寫init呼叫使用

面板開關要寫在自己物件上 給外面存取使用

先把設定參數放在面板打開前先設定好
面板關閉後 再設定參數 可以減少畫面上的瞬間變化

資料最好統一由一個資料管理員處理
每個UI的資料都去抓他的來用,UI本身不放暫存,在資料做變化時,通知UI事件觸發的方式去變更UI顯示資料。

手機解決黑頻問題
Use 32-bit Display Buffer 不要勾選.... 舊機子很容易閃退 或是 黑頻....




狀態機 模式

using System.Collections;
using System.Collections.Generic;

/*
    泛用型 狀態機

    可以讓使用者 專注寫狀態就好

    對外直接使用 AI<T>

    撰寫邏輯使用繼承 State
    State內取用 樣板資料 來取得客製化數據 來做對應的變化

    事件取用方式?

    對外事件操作方式
        取得data後 可自行註冊內部事件

    定義資料
        這裡面定義可能要處理的資料與行為
    定義狀態類別 : state
        這裡面使用資料
    定義AI : AI<資料>
        讓外部取得data連結 然後做控制
        AI本身就是執行動作
*/

/// <summary>聖淨之風</summary>
namespace Aether
{
    /// <summary>行為</summary>
    public class AI<T> where T : new()
    {
        /// <summary>狀態機</summary>
        Context context = new Context();

        /// <summary>建構式</summary>
        public AI()
        {
            context.data = new T();
        }
        /// <summary>執行動作</summary>
        public void RunAction()
        {
            context.RunAction();
        }
        /// <summary>取得目前狀態</summary>
        /// <returns>目前狀態</returns>
        public string GetState()
        {
            return context.GetState();
        }
        /// <summary>取得資料</summary>
        /// <returns>回傳資料</returns>
        public T GetData()
        {
            return (T)context.data;
        }
    }
    /// <summary>狀態機</summary>
    public class Context
    {
        /// <summary>資料</summary>
        public object data = null;
        /// <summary>狀態池 - 減少new的使用</summary>
        Dictionary<string, State> stateDict = new Dictionary<string, State>();
        /// <summary>目前狀態</summary>
        State stateNow;

        /// <summary>更換狀態</summary>
        /// <typeparam name="T">狀態類別</typeparam>
        public void ChangeState<T>() where T : State, new()
        {   //取得狀態
            string l_strClassName = typeof(T).Name;
            State l_state = stateDict[l_strClassName];
            if(l_state == null)
            {
                l_state = new T();
                stateDict.Add(l_strClassName, l_state);
            }

            stateNow = l_state;
            stateNow.SetContext(this);
        }
        /// <summary>執行動作</summary>
        public void RunAction()
        {
            stateNow.RunAction();
        }
        /// <summary>取得目前狀態</summary>
        /// <returns>目前狀態</returns>
        public string GetState()
        {
            return stateNow.GetClassName();
        }
        /// <summary>取得資料</summary>
        /// <typeparam name="T">類型</typeparam>
        /// <returns>類型</returns>
        public T GetData<T>()
        {
            return (T)data;
        }
    }
    /// <summary>狀態</summary>
    public class State
    {
        /// <summary>狀態機</summary>
        protected Context context = null;

        /// <summary>設定狀態機</summary>
        /// <param name="i_context"></param>
        public void SetContext(Context i_context)
        {
            context = i_context;
        }
        /// <summary>運作行為</summary>
        public virtual void RunAction()
        {
        }
        /// <summary>取得類別名稱</summary>
        /// <returns>類別名稱</returns>
        public string GetClassName()
        {
            return this.GetType().Name;
        }
    }
}

首儲獎勵設計

最近在思考 消費後所帶給玩家的反差感 過低的消費額度 很難製造反差 或是 成本太低 製造反差給予玩家的獎勵設計制度不能太高

不過大多數遊戲為了能夠促使玩家做出首次消費 來提升 往後消費意願 往往都會設計 首儲獎勵 首儲獎勵通常會給予很高的反饋 而這個反饋也只有第一次有效 這樣既能刺激新進玩家消費 也能夠保持一般消費玩家的公平性

而首儲獎勵的獎勵內容物 最好是當玩家第一次接觸遊戲時 能夠清楚明瞭滿足當下需求的獎勵
不要設計需要玩家在玩一陣子之後才會有需求的內容物 而是當下就有迫切需求的內容物 比如:鑽石、體力、新手裝備、高星角色之類 通常都是給予玩家能夠更順暢的進行遊戲體驗為主