聊一聊游戲版本運營
大家好,我是才哥。
今天我們聊一聊游戲運營里的版本運營模塊的工作,介紹一下這個崗位的主要工作內(nèi)容。
簡單來說,版本運營日常工作主要是負(fù)責(zé)保障游戲線上運營的穩(wěn)定性,同時也可能需要去處理一些線上的突發(fā)事件。
基于此,做好版本運營我們可以從以下幾個方面進(jìn)行展開,更好的服務(wù)于項目以及我們的用戶。
1. 基礎(chǔ)
對于版本運營同學(xué)來說,可以從游戲研發(fā)期開始介入,完成一些基礎(chǔ)性的版本運營工作,比如SDK接入、運營工具、GM工具以及平臺能力項接入等等;在進(jìn)行游戲測試調(diào)優(yōu)之前,還需要梳理版本維護(hù)更新發(fā)布流程、多版本(包)管理、渠道上下架操作、tlog埋點以及運營數(shù)據(jù)后臺等等。
1.1SDK接入
今天我們不聊那么細(xì),簡單介紹SDK所包含一些基礎(chǔ)內(nèi)容和拓展內(nèi)容。
1.1.1基礎(chǔ)內(nèi)容
賬號體系、充值以及SDK數(shù)據(jù)上報(一般是客戶端日志數(shù)據(jù))
賬號體系
- 從用戶角度來看,登錄游戲的方式可以有多種,比如賬號密碼登錄、手機號登錄又或者第三方賬號如QQ、微信、微博、蘋果id登錄等等;
- 而對于同一個游戲(不同渠道包算不同的)來說,這些登錄方式最終都是一個賬號體系之下的;
- 從產(chǎn)品角度,其實支持多種登錄方式,那么這些不同的登錄方式其實就需要去對應(yīng)的開發(fā)者后臺申請對應(yīng)的參數(shù)。
關(guān)于這些參數(shù)的申請,不同的公司的流程可能不一樣,有的可能是中臺部門負(fù)責(zé)或者商務(wù)同學(xué)負(fù)責(zé),也有的可能是版本運營同學(xué)負(fù)責(zé)。但是不管怎么樣,最終基本都需要版本運營去進(jìn)行對接協(xié)調(diào)(作為項目組與其他部門之間的溝通橋梁),所以作為版本運營,把這些流程與實操都熟悉掌握很有必要。
tips:一般參數(shù)申請需要提供產(chǎn)品的基礎(chǔ)信息,比如 名稱、包名、icon以及簡介等等,這部分差不多就是需要版本運營同學(xué)來準(zhǔn)備了。
充值
對于有內(nèi)購的游戲來說,充值是必不可少的。國內(nèi)常見的充值有支付寶、微信支付與蘋果支付等,此外還有手機話費卡支付、銀聯(lián)卡支付等等;海外可能就是GiftCard、PayPal、VISA/萬事達(dá)等等。同樣的,這些支付方式也是需要去對應(yīng)的開發(fā)者后臺申請參數(shù),它們的流程和賬號體系基本一致。
SDK數(shù)據(jù)上報
SDK數(shù)據(jù)上報一般是SDK自帶的一類,主要是設(shè)備信息與SDK相關(guān)信息一類的數(shù)據(jù),可以提前和中臺部門了解下具體有哪些預(yù)設(shè)數(shù)據(jù)上報等等,這樣就便于后續(xù)測試驗收。
1.1.2拓展內(nèi)容
除了上述的基礎(chǔ)內(nèi)容之外,我們還可能涉及到其他的一些拓展內(nèi)容,比如:
為了方便用戶在游戲里進(jìn)行交流,需要接一些第三方的語音SDK;
為了更好的采集用戶行為數(shù)據(jù),可能會接入做的比較好的第三方數(shù)據(jù)平臺的SDK;
為了進(jìn)行流量變現(xiàn),可能會接入第三方的廣告SDK;
為了方面用戶手機號登錄,可能會接入手機號一鍵登錄的SDK;
為了收集用戶體驗游戲時設(shè)備的一些奔潰信息,可能會接入第三方的崩潰上報SDK等等。
同樣的,我們?nèi)绻枰霞芤恍┞?lián)運渠道,則還需要接入這些聯(lián)運渠道的SDK,這個SDK則會帶有上述第1部分中的基礎(chǔ)內(nèi)容以及一些渠道定制化的內(nèi)容(比如浮窗功能、內(nèi)置社區(qū)等等)。
以上只是部分拓展內(nèi)容,實際項目中會根據(jù)項目本身的產(chǎn)品需求進(jìn)行第三方SDK的選取,而對于第三方SDK的接入也基本上都是 提供產(chǎn)品的基礎(chǔ)信息用于參數(shù)申請,作為版本運營的同學(xué)也一定需要搞清楚這個SDK的功能是什么,以及如何驗收。
1.2運營工具
顧名思義,運營工具就是在游戲運營過程中會使用到的工具,常見的發(fā)公告、跑馬燈、全服郵件等等就是。
我們按照功能類型可以分為以下幾類,具體詳情需要根據(jù)具體項目進(jìn)行定制化:
用戶信息查詢
通過用戶賬號、角色I(xiàn)D或昵稱等查詢用戶信息,不同的產(chǎn)品信息展示有所不同
- 當(dāng)前詳情信息(如等級、充值金額、背包信息等等)
- 歷史信息記錄(如道具操作流水、充值流水等等)
資源管理
比如公告、跑馬燈、全服&單人郵件、push消息等等
服務(wù)器狀態(tài)管理
開/關(guān)服、預(yù)開服(維護(hù))、排隊人數(shù)設(shè)置、白名單等等
游戲功能管理
為了盡可能保證游戲線上運營的穩(wěn)定性以及能盡快的響應(yīng)線上突發(fā)事件,游戲功能管理模塊可以無限拓展。最簡單的就是對可能出現(xiàn)問題就會影響線上的功能都做開關(guān)功能,在線上出現(xiàn)問題時第一時間進(jìn)行功能關(guān)閉處理,讓負(fù)面影響盡可能小。
- 比如 角色 開關(guān),關(guān)閉某個角色則該角色無法使用,如果該角色出現(xiàn)數(shù)值異常則可以第一時間先關(guān)閉之;
- 比如 充值 開關(guān),關(guān)閉某充值則該充值項無法充值,如果該充值出現(xiàn)異常比如充值給的獎勵配錯了,則第一時間關(guān)閉之;
- 比如 某活動出現(xiàn)問題,我們也可以關(guān)閉活動,則也可以減少損失;
再比如 某期間 要求玩家不能改名,我們就可以關(guān)閉改名功能等等。
以上只是部分由于某功能異常導(dǎo)致的問題的快速響應(yīng),作為版本運營同學(xué)需要對游戲的各個功能都有清晰的認(rèn)知,又能考慮到可能出現(xiàn)問題的邊界情況及其負(fù)面影響,然后和對應(yīng)的策劃一起商量確定其功能開關(guān)的具體功能為最佳。
通過上述功能可以看到,運營工具就是游戲運營同學(xué)操縱游戲的核武器,熟練掌握并能不斷完善該核武器,可以極大提高我們的工作效率以及應(yīng)對突發(fā)事件的處理能力。
(提個小問題,某運營同學(xué)在給個人發(fā)送補償郵件的時候不小心發(fā)到成了全服,怎么快速處理可以讓損失最小?)
1.3GM工具
GM工具其實也是運營工具的一種,這里我狹義的指代對用戶狀態(tài)操作的工具
通過用戶賬號、角色I(xiàn)D等對用戶進(jìn)行相關(guān)的狀態(tài)操作,不同的產(chǎn)品用戶狀態(tài)有所不同
- 處罰類型(如:封號、禁言、禁止某玩法、禁止排行榜等等)
- 信息修改(如:強制改名、道具刪減、修改段位等等)
比如,某用戶在體驗游戲的時候開掛了、故意送分了等等,我們就可以對其進(jìn)行封號處理;某用戶昵稱不雅被舉報了,我們就可以對其進(jìn)行強制改名等等。
需要注意的是,不管是運營工具還是GM工具,我們在設(shè)計的時候都需要考慮該功能使用后如果會影響玩家的正常體驗,則一定要給予玩家合適的前端提示。比如封號后,玩家登錄的時候需要有彈窗提示告知玩家 因為什么原因被封到什么時候之類的;我們關(guān)閉某個功能后,需要在玩家點擊該功能的時候提示 該功能暫時關(guān)閉之類的。(具體功能具體分析了)
此外,就是這些工具的具體功能需求,對于運營同學(xué)來說就是在某個網(wǎng)頁前端進(jìn)行輸入與結(jié)果的展示。而實際上涉及運營與網(wǎng)頁前端的交互、中臺(制作網(wǎng)頁前端的部門)與游戲服務(wù)器之間的交互、游戲服務(wù)器與客戶端之間的交互以及玩家與客戶端之間的交互。其中前2類交互需要版本運營同學(xué)去撰寫具體的需求,后2類的交互則需要版本運營與策劃溝通并大多數(shù)情況下由策劃去撰寫具體的需求。
1.4平臺能力項接入
像我們在SDK接入里提到的很多功能如QQ、微信和微博等第三方賬號登錄方式,一般來說它們也提供諸如分享等功能,這些就屬于平臺能力項。不過,這些第三方的能力項大部分都是僅用于各自獨代的一些產(chǎn)品。
此外,我們接入的聯(lián)運渠道,它們一般也會有一些平臺能力項供接入使用,比如浮窗、內(nèi)置社區(qū)等等。
我們可以根據(jù)自己的產(chǎn)品需求來進(jìn)行相關(guān)能力項的選取。
1.5版本維護(hù)更新發(fā)布流程
當(dāng)我們的產(chǎn)品開始接觸用戶,就會有新內(nèi)容、舊內(nèi)容迭代以及一些問題修復(fù)等等,這就涉及到維護(hù)更新與發(fā)布了。有明確的更新發(fā)布流程,可以讓我們這類工作高效有序的展開。
一般來說,更新可以分為以下2類:
強更
也叫冷更、大版本更新等等,用戶需要更新一個完整的包,大多數(shù)時候,這種更新需要停服操作
熱更
這是一種更新頻率非常高的方式,用戶在現(xiàn)有的版本基礎(chǔ)上更新一些游戲資源即可,一般不需要停服操作
對于強更這種情況,一般都是提前準(zhǔn)備好了完整的包上架渠道或者CDN,到指定的時間進(jìn)行停服操作,操作結(jié)束后玩家自動更新最新的包,這種情況一般涉及到比較大的版本內(nèi)容更新或者比較底層的代碼改動。
對于熱更這種情況,一般可以分為兩種:用戶無感的更新與用戶需要重啟游戲的更新。無感的更新多數(shù)情況下是一些純數(shù)據(jù)或少數(shù)美術(shù)資源層面的更新,玩家在游戲中就靜默更新了。用戶需要重啟游戲的更新則可能涉及到相對較大資源或者是比較關(guān)鍵的數(shù)據(jù)(比如競技類游戲里的 戰(zhàn)斗數(shù)值)更新,玩家在游戲大廳則需要重啟游戲進(jìn)行更新。
其實,很多游戲都可以做到基本不需要停服更新,比如多個login、game服等,涉及到服務(wù)器需要重啟更新的內(nèi)容進(jìn)行相關(guān)子節(jié)點的輪流重啟就可以了。
以上的一些具體更新邏輯則需要版本運營同學(xué)和對應(yīng)的前后端技術(shù)、運維和測試同學(xué)一起進(jìn)行協(xié)商溝通并最終確定。
一般來說,更新流程可以概況為以下(具體項目具體討論):
- 確定版本更新內(nèi)容
- pc端驗收(內(nèi)網(wǎng))
- 手機端 ftp環(huán)境驗收 (內(nèi)網(wǎng))
- 手機端 cdn環(huán)境驗收 (預(yù)發(fā)布,無限接近外網(wǎng))
- 運營發(fā)布公告、跑馬燈、各社群&自媒體平臺發(fā)布更新公告(告知更新時間、類型、內(nèi)容、補償方案等)
- 發(fā)布前的操作(服務(wù)器狀態(tài)操作,是否灰度等等)
- 線上發(fā)布
1.6渠道上下架操作
一般除了官方渠道(官網(wǎng)、官方社區(qū)等),我們還可能上架一些平臺或者聯(lián)運渠道等,這就涉及到多版本(包)的管理以及渠道的上下架操作。
作為版本運營,盡量熟悉不同渠道的上下架操作是有必要的(雖然很多時候這些操作可能是商務(wù)或者渠道對接同學(xué)負(fù)責(zé))。
在本地版本包的管理上盡量的規(guī)范,這樣在實際的工作中就可以更加方便。
常見的上架需要準(zhǔn)備的材料有如下幾類:
- 安裝包
- 五圖(icon如果換則加上)
- 更新內(nèi)容
- 主副標(biāo)題(如果換的話)
- 是否新增內(nèi)購檔位等
不同的渠道對這些素材的要求可能不同,整理一份材料需求清單,創(chuàng)建不同渠道的材料文件夾進(jìn)行統(tǒng)一管理可以讓工作效率大大提高。
關(guān)于渠道包提審,在實際操作中可能會遇到很多不同的問題,我們都需要根據(jù)實際情況進(jìn)行一一處理。
常見的有以下一些場景:
- 某渠道SDK更新了,且是需要強制更新版本的,對于這種情況,建議在原定的上架時間前2-3周找商務(wù)同學(xué)進(jìn)行各渠道SDK更新狀態(tài)的統(tǒng)一匯總以盡可能避免此類情況;
- 某渠道新增了一些屏蔽字,是否第一時間補充到游戲屏蔽字庫了;
- 聯(lián)運渠道包不能出現(xiàn)一些外鏈引導(dǎo)類的功能以及廣告sdk等等;
- 一些新的合規(guī)政策的出臺,比如最近1年越來越嚴(yán)格的關(guān)于隱私政策&用戶協(xié)議、防沉迷、隱私清單等的要求,我們需要去研究解讀具體的政策條款,同時也要去了解渠道對這些政策條款的要求,然后合到游戲里。
以上其實就需要版本運營同學(xué)也要時常關(guān)注各渠道以及國家在游戲方面的一些政策規(guī)定等,然后進(jìn)行針對性的預(yù)警或處理,以確保項目穩(wěn)定有序開展。
關(guān)于iOS提審與發(fā)布可以參考我后續(xù)要出的一期介紹哈(敬請期待)
1.7數(shù)據(jù)埋點
數(shù)據(jù)埋點就是對用戶游戲行為以及游戲本身數(shù)據(jù)的記錄,常見的用戶注冊、創(chuàng)角、登錄、登出等等,此外就是和玩家對游戲的各個玩法系統(tǒng)的行為數(shù)據(jù)事件的采集了。
這些埋點數(shù)據(jù)都是元數(shù)據(jù),也就是每一次行為事件都會記錄成一條,我們后續(xù)復(fù)雜的數(shù)據(jù)分析都是基于此。
一般來說,我們可以將事件的屬性分為兩類:通用屬性與事件專屬屬性。
通用屬性 可以理解為在每個事件里都需要記錄的屬性(取不到的不算),比如用戶的賬號、角色id、等級、vip等級、創(chuàng)角時間、昵稱、渠道、平臺等等。
事件專屬屬性 可以理解為每個單獨的事件所需要記錄的屬性,其實這個是數(shù)據(jù)埋點設(shè)計的核心,它的設(shè)計思路其實需要反推,比如我需要通過玩家對局(moba)來分析英雄出場率、勝率以及一些對局屬性數(shù)據(jù)來進(jìn)行平衡性調(diào)整等等,則可以做如下埋點設(shè)計(簡單的參考):
字段名 | 字段說明 | 字段類型 | 備注 |
battle_id | 對局id | 數(shù)值 | |
role_id | 角色uid | 數(shù)值 | |
rank_before | 對局前段位 | 數(shù)值 | |
rank_after | 對局后段位 | 數(shù)值 | |
game_type | 游戲模式 | 數(shù)值 | |
elo_before | 對局前elo | 數(shù)值 | |
elo_after | 對局后elo | 數(shù)值 | |
elo_type | elo類型 | 數(shù)值 | |
faction_id | 陣營 | 數(shù)值 | |
hero_id | 英雄 | 數(shù)值 | |
skin_id | 皮膚 | 數(shù)值 | |
equip | 最終裝備 | 列表 | |
summoner | 召喚師技能 | 數(shù)值 | |
runes | 銘文 | 列表 | |
level | 等級 | 數(shù)值 | |
kill | 擊敗數(shù) | 數(shù)值 | |
death | 死亡數(shù) | 數(shù)值 | |
assist | 助攻數(shù) | 數(shù)值 | |
economy_all | 總經(jīng)濟(jì) | 數(shù)值 | |
economy_creep | 野怪經(jīng)濟(jì) | 數(shù)值 | |
score | 評分 | 數(shù)值 | |
kill_soldier | 補刀數(shù) | 數(shù)值 | |
participation | 參團(tuán)率 | 數(shù)值 | |
... | ... | ... |
當(dāng)然了,數(shù)據(jù)埋點這方面版本運營同學(xué)不一定需要去負(fù)責(zé),像數(shù)據(jù)運營或者對應(yīng)系統(tǒng)的策劃又或者數(shù)值策劃等都可以參與到這個工作中來。除了我們需要用于分析的屬性之外,技術(shù)也可能會提一些用于定位問題的屬性字段,加到埋點設(shè)計里即可。
1.8運營數(shù)據(jù)后臺
有了埋點數(shù)據(jù)之后,我們就可以進(jìn)行運營數(shù)據(jù)后臺的搭建了。
當(dāng)然了,現(xiàn)在很多公司都有自己的的數(shù)據(jù)中臺,我們直接按照他們制定的數(shù)據(jù)埋點的統(tǒng)一格式來,那么基本上就可以很簡單的接入到對應(yīng)的數(shù)據(jù)后臺了,常見的一些數(shù)據(jù)報表基本也就不需要額外去設(shè)計了。又或者我們接入一些第三方的數(shù)據(jù)后臺,按照對應(yīng)的數(shù)據(jù)埋點要求進(jìn)行埋點設(shè)計,一樣可以快速的完成一些基礎(chǔ)的數(shù)據(jù)報表設(shè)計。
其實,有了元數(shù)據(jù),數(shù)據(jù)分析就都好做了。
常規(guī)報表的制作,特殊的專項數(shù)據(jù)分析則可能涉及到SQL或者python的一些處理,這方面可以參考咱們公眾號歷史文章進(jìn)行學(xué)習(xí)。
不過,現(xiàn)在除了游戲里的一些玩家行為數(shù)據(jù)之外,我們還有買量數(shù)據(jù),這方面也是可以集成到運營數(shù)據(jù)后臺的,當(dāng)然也是可以單獨拿出來做分析,結(jié)合游戲里的數(shù)據(jù)看用戶質(zhì)量(留存、LTV、roi之類的)。
2. 進(jìn)階
在基礎(chǔ)部分,我們主要介紹的是屬于基建部分,如果要把版本運營做的更好,我們需要更多的思考,對產(chǎn)品的以及對用戶的。
2.1口碑運營
從游戲測試調(diào)優(yōu)開始到游戲上線運營之后,我們都需要開始關(guān)注口碑運營這塊的工作。核心就是日常線上環(huán)境的監(jiān)控,及時妥善處理游戲的各類突發(fā)運營事件。
游戲面向用戶后,就需要注意口碑。任何一個負(fù)面的問題都會導(dǎo)致口碑的下降,而每次妥善的處理也往往能將口碑拉升。
所以,我們需要游戲線上的運營情況,這個情況可以是直觀的數(shù)據(jù)曲線,也可以是外網(wǎng)輿情,還可以是客服反饋等等。
從數(shù)據(jù)曲線的折線變化我們可以及時發(fā)現(xiàn)線上可能的問題,比如服務(wù)器宕機導(dǎo)致在線數(shù)陡降,接著我們就從外網(wǎng)輿情發(fā)現(xiàn)玩家反饋登錄不上游戲,客服也反饋過來很多玩家掉線等等。
又或者數(shù)據(jù)曲線都正常,有玩家反饋某玩法無法參與等等。
這個時候,版本運營的同學(xué)就需要開始跟進(jìn)并推動處理這一系列問題。
一般來說,大致流程可以是這樣:
- 收集問題(盡可能詳細(xì),用戶賬號或角色id、時間、場景、具體問題等)
- 可自測的先自測(比如登錄問題、充值問題、玩法參與等比較顯而易見的)
- 同步線上問題群(相關(guān)模塊負(fù)責(zé)人都在的專項群)
- 評估風(fēng)險等級
- 高風(fēng)險的緊急處理方案(這個時候要善于使用運營工具和GM工具等)
- 處理方案同步用戶(公告、跑馬燈、社群、自媒體,客服答復(fù)玩家的統(tǒng)一口徑等)
- 協(xié)調(diào)推動問題的處理
- 復(fù)盤總結(jié),一方面嘗試從機制上避免,另一方面看是否可以完善處理機制等
作為版本運營,需要對游戲機制(一些功能的實現(xiàn)邏輯)有非常熟悉的理解,以便于能第一時間對問題進(jìn)行判斷,盡快響應(yīng)!
在事故問題的處理中一定要積極主動的push,協(xié)調(diào)各部門盡快修復(fù)上線!
同時和其他模塊運營同學(xué)(尤其是玩家運營、自媒體運營等)保持緊密配合,盡可能妥善處理外網(wǎng)輿情。
簡單概況對突發(fā)事件的處理就是要做好:全方位(公告、跑馬燈、社群自媒體等)告知玩家處理方案(時間、具體措施、補償方案等),盡快處理,統(tǒng)一口徑!
除了高風(fēng)險的突發(fā)事件的緊急處理外,也需要去關(guān)注日常玩家對游戲的反饋,不管是bug還是設(shè)計體驗反饋,都記錄備案(日期、歸屬版本、反饋類型、反饋內(nèi)容、反饋頻度、玩家信息等),為后續(xù)版本優(yōu)化提供參考。
一定注意,顯而易見的bug和一些合理的建議,能盡快進(jìn)版本就盡快,否則容易讓玩家覺得我們不作為而影響口碑。
2.2版本規(guī)劃
一般來說,游戲性的版本規(guī)劃可能是很早就有制定,不過在運營階段,收集到線上玩家的一些有效反饋建議以及從運營數(shù)據(jù)分析得到的一些參考建議等都可以作為后續(xù)版本的開發(fā)方向。
常見的bug類問題的修復(fù),體驗優(yōu)化類的需求以及玩家的一些對玩法或資源追求的合理性需求等等。以上這些則需要運營同學(xué)對產(chǎn)品、對用戶以及對數(shù)據(jù)都有比較深刻的理解。一定注意,并不是玩家的反饋建議就一定要聽!
2.3測試服
現(xiàn)在很多上線運營的游戲都有測試體驗服,比如每次大版本上線之前,由于涉及到的新增功能點較多。為了更完善的測試(相對趨近于線上正式環(huán)境),我們就可以先安排上線測試體驗服,邀請一批玩家進(jìn)行體驗。一方面可以找bug,另外一方面還可以提前體驗新內(nèi)容然后專項反饋,讓我們可以進(jìn)行上線前的調(diào)優(yōu),這樣正式上線后的版本的版本質(zhì)量更有保障。
其實,對于測試服與正式服同時存在的情況,對于項目組來說相對而言是維護(hù)了兩個正式版本(同時還有開發(fā)版本需要維護(hù)),多多少少會存在一些的工作壓力。如何去協(xié)調(diào)測試服與正式服的工作就顯得比較重要了!
這里,我們的做法大致是這樣:
根據(jù)實際的產(chǎn)品需求,不定期進(jìn)行測試服的測試招募(針對性招募指定屬性人群),進(jìn)行專項的測試。比如要上新的英雄或者玩法,招募一批玩家在指定時間按照測試要求參與,專項提交這些英雄或玩法的bug與體驗反饋,負(fù)責(zé)該英雄或玩法的策劃owner可以加入到測試群了解玩家反饋也可以等測試周期結(jié)束后統(tǒng)一看我們匯總的反饋,或者參與組織的專項訪談!如果測試中間遇到一些阻斷性的bug,比如英雄無法使用、游戲高頻閃退、英雄數(shù)值變態(tài)等,則需要及時處理并更新;如果遇到的是一些其他類型不影響核心測試目的的問題或反饋,則暫時先無視。
另外,就是如果與正式服運營版本之間存在人力需求交集,以正式服為主。
除了專項測試之外,特定的在正式服上線前2-3周進(jìn)行一次相對正式版的測試服跑測,主要是版本穩(wěn)定性測試。
此外,就是非官方組織的測試周期外,有余力的情況下可以多對測試版本進(jìn)行一些維護(hù),確保后續(xù)需要使用的時候合版本的時候問題盡可能的少!
測試服也是需要很好的維護(hù),如果招募的玩家發(fā)現(xiàn)測試服問題一大堆且官方基本不維護(hù),正式服上線后測試服就存在的很明顯的問題還在,那么這些玩家參與測試服的積極性甚至對游戲的積極性都會大打折扣!
2.4版本主題
新的版本內(nèi)容最終確定后,我們就可以考慮對這個版本進(jìn)行主題包裝了,具體主題我們可以找文案策劃一起勾兌,然后找平面設(shè)計進(jìn)行相關(guān)素材的制作。主題包裝的作用有一定的品宣效果,配合買量或者渠道動作,可以把價值發(fā)揮到最大。
常見的主題包含涉及到的工作可以有:
- 新的icon
- 新的登錄界面
- 新的大廳主KV
- 新的宣傳圖
- 新的CG或視頻
- 官網(wǎng)、社群與自媒體的主KV
在新版本正式上線前1-2周,我們就可以安排陸續(xù)進(jìn)行新版本爆料,營造氛圍!
同樣的,我們在定好更新內(nèi)容后,可以將更新內(nèi)容準(zhǔn)備兩套,一套詳細(xì)的圖文類用于官網(wǎng)和社群自媒體,一套簡單的用于游戲內(nèi)公告。
這個時候,我們還可以和商務(wù)一起,將新版本的亮點、賣點梳理,然后找渠道進(jìn)行資源置換!
如何更好的進(jìn)行版本主題包裝,如何借此協(xié)調(diào)各方的資源,將新版本的buff加到最大是版本運營全局規(guī)劃能力的一種體現(xiàn)!
2.5運營需求池
除了收集的玩家有效反饋建議和bug之外,我們在運營過程中也會有一些從運營出發(fā)的需求,比如渠道新功能希望我們能接入一下、市場或買量同學(xué)與外部渠道(短視頻平臺等)的合作需求、運營工具或GM工具新增需求等等。
這個時候,作為版本運營則需要對這些需求進(jìn)行歸檔整理成運營需求池,考慮到項目組開發(fā)人力是有限的,所以并非全部的需求過來都要立馬安排上,如何協(xié)調(diào),就需要版本運營好好考慮了。
我個人比較喜歡的做法就是會先自己熟悉下這些需求的具體背景、大致可能需要的人力資源,然后再跟需求方一起溝通優(yōu)先級,再組織會議溝通進(jìn)行需求的評審(類似策劃需求評審,需要項目側(cè)PM、需求發(fā)起者以及相關(guān)人員一起)。
有些需求可能項目組內(nèi)部就能消化,比如短視頻平臺的合作需要的只是禮包或者游戲內(nèi)宣傳圖,這類找美術(shù)提需求游戲內(nèi)添加配置即可;有些需求可能還需要中臺部分協(xié)助,比如渠道新功能,我們需要找中臺進(jìn)行聚合,則還需要考慮中臺的排期。
懂技術(shù)、會項目管理,是版本運營同學(xué)多多少少需要掌握的!
2.6其他
在線上運營的過程中,我們還會遇到很多各式各樣的場景,版本運營需要根據(jù)不同的場景進(jìn)行合理的安排處理,隨機應(yīng)變。
除了我們之前提到過的突發(fā)事件(bug類)的處理外,其實像外掛或者其他一些玩家違規(guī)游戲行為的處理也需要得到重視,營造和諧的游戲環(huán)境很重要。
關(guān)于外掛,需要考慮其影響面,如何針對性的處理:一方面需要出臺相關(guān)處理流程(如何判定、判定后如何處罰、如何公示等等),另一方面則需要和項目組一起制定能從機制上避免或者自動處罰外掛的方案。
關(guān)于違規(guī)游戲行為(比如惡意送分、刷分、退款、言語辱罵等等),其實也和外掛處理的流程邏輯類型,一方面從運營角度處理,另一方面從機制上完善。
此外,還有一些諸如開服、合服、關(guān)服以及賬號遷移等等都是版本運營在工作中可能涉及的內(nèi)容,這些都根據(jù)具體問題具體處理就好了,不再展開!