《揀愛》製作人2021年終總結:一些發行和新專案的經驗和想法
歡迎關注亞恆B站主頁:https://space.bilibili.com/31078113
今年…就覺得挺庸庸碌碌的…忙了一年也不清楚在忙什麼的感覺…
(用日語說就是:空回り)
《揀愛》相關
上一年我基本一直在忙《揀愛》的移植工作,這些移植的工作一直到今年上半年都沒有停過。就是到了今天,也還時不時會出現一些需要處理的工作。雖然確實比較無趣,但不得不承認這部分工作佔據了我今年的很多時間。還是每個平臺簡單總結一下吧。
【國內移動端】
國內移動端的移植是所有平臺中最痛苦的。有很多讓人無奈的地方,例如版號申請的拉扯,例如問題頻出的防沉迷、髒字檢測系統之類 sdk 的接入,例如國內的安卓平臺並非都支援買斷制遊戲等等。也有很多我一意孤行的地方,例如,在準備時間不足的情況下,為了延續有意思的發售日子,選了 520 發售,搞得自己肝疼。例如被告知 520 當日也是某易的重大釋出會,這天宣傳資源會被大幅度佔用,但我仍然選擇了這天。例如在明知手機玩家更習慣免費體驗部分遊戲內容,再付費解鎖內容,而非在進去遊戲以後就馬上付費買斷,卻仍然選擇我們能做到的接近買斷制體驗的購買方式(哪怕根本找不到第二個遊戲這樣做)。為了維護我所認為的各個平臺的“相對公平”,也是為了我所認為的保證玩家體驗一致。因為發行商也好、付費方式也好,我們沒少被罵是事實。因為我的一意孤行,影響了遊戲的評價和銷量也大概率是事實。我很清楚目前我所在意的各個平臺的“體驗公平”、“價格公平”平臺根本不在意,玩家也大概沒有多少人在意。而只有我自己想貫徹這種公平根本起不到什麼作用,也因為很多平臺的限制,導致根本無法落地。例如,蘋果端的售價只能按照預設的檔位:1 美元、2 美元等等(打折也只能在這裡面選),但 NS 遊戲的售價卻是 5 美元起的,所以一意孤行沒有真的貫徹到我希望貫徹的東西。大概換來的後果,就是遊戲收到了原本可以避免的差評和罵聲,我和小夥伴的收入也少了。雖說不上後悔,但下次碰到類似情況,我會重新考慮要怎麼處理的。某種意義上,也算是有收穫吧。
【國外移動端】
從結果來說,《揀愛》的海外移動版算是涼了,到目前為止,上線 1 個多月銷量不足 20 份。我在這過程中犯了很多錯誤,也學到了一些東西。
· 失敗的發行
我在自己的文章裡一直強調:“哪怕沒有發行商,開發者自己也要做好發行工作”結果這回輪到我自己犯這錯誤了 ( ̄▽ ̄)
→ Apple Arcade:
雖然說以《揀愛》這樣已經發售一段時間的老遊戲+並不出色的國外銷量和影響力,要爭取上 Apple Arcade 感覺機會不太大。但坦白說我還是應該要嘗試爭取一下的,起碼可能會是一種引起蘋果編輯注意的方法。畢竟對於買斷制手機遊戲來說,在國外,app store 是最最重要的平臺。而對於我們這種沒有經費自己做宣傳的遊戲來說,Apple Arcade 應該算是目前最理想的渠道了吧。
→ 蘋果的官方投稿渠道:
另外,遊戲上線之前也很應該通過蘋果的官方渠道,去投稿一下,讓蘋果的編輯最起碼能在你的遊戲上線前看到你的遊戲。這些渠道網上查一下就能看到,之所以沒有去做完全是因為發國外版的時候主要心思在遊戲開發,而不在這個上面,麻痺大意導致的。對於 app store 這種每天 1000+款應用上架,又不像 steam 那樣有個性化演算法推薦的平臺。蘋果編輯是否給你推薦成為最最重要的因素,但我卻無視了這一切直接上架了。實在是過於隨便。
→ 重名問題:
這個說實話應該是比上面內容更大的問題。在國外的 app store 和 google play,有一款和揀愛(LoveChoice)幾乎同名的免費氪金遊戲:Love Choice(之後稱同名手遊),而我在為揀愛命名英文名字的時候卻完全不清楚。甚至在上架之前,我也完全沒有嘗試在 app store 和 google play 搜尋過關鍵字 LoveChoice。畢竟目前無論在百度還是 google,搜尋 lovechoice 的話,搜尋結果幾乎都是揀愛相關的。但其實在海外的 app store 和 google play,那個同名遊戲才是這個關鍵字的霸主。而且它的體量還挺大的,熱度也一點不低。最可怕的是,它並非一個遊戲,而是一個系列的遊戲。直接導致海外玩家搜尋 LoveChoice 的話,大概要下翻好幾頁才能找到我們的遊戲。而且那個同名遊戲的風格和揀愛差了十萬八千里,我想搜尋 LoveChoice 的玩家看到同名遊戲那些圖以後,也基本對我們的遊戲失去興趣了吧( ̄▽ ̄)
給大家感受一下國外同名遊戲的畫風:
搜尋 LoveChoice 出來的東西,我們也太格格不入了吧……
→ LandingPage:
很久之前我就在國外開發者的視訊裡面,聽說過 LandingPage 的重要性。但很長一段時間我都是不以為然的。畢竟在國內的環境,真的很少人會去看一個遊戲的官方主頁,但我現在知道錯了。在國外的環境,有自己的 landing page 並一直好好運營真的很重要!特別是對於有多個平臺的遊戲來說。
目前在 google 搜尋 lovechoice,出來的會有 steam 頁面,和主機端的頁面。但卻永遠不會搜尋到我們自己的網頁。原因很簡單,這網頁是我們最近才做的…之前一直沒有做,很大原因是因為我自己根本不會做網頁,也一直懶得去接觸相關的知識。而如果一個手機玩家,它從某些渠道聽說過 lovechoice 的名字,去 google 上面一搜,他就會看到 steam 頁面和主機頁面的連結,而很容易就會覺得 lovechoice 是一個只在 pc 和主機上有的作品。然後哪怕他還很用心地在 appstore,或者 googleplay 上面搜了 lovechoice,結合上面的重名問題,基本上他也看不到我們的遊戲。再加上我們還是個買斷制遊戲,我想,這就已經打消 99% 玩家的興趣了吧。
相反,如果我們一直就有運營自己的 landingpage,起碼我們可以在 landingpage 上面寫上我們有登入哪些平臺,一個平臺的流量也能通過這個 landingpage 也能稍微帶活其他平臺。
這點,多平臺的國外遊戲都做的很好,例如 baba is you 之類的。
對了,貼上我們簡陋的 landingpage 連結,歡迎大家去幫我們提高那麼一點點熱度。
https://akabastudio.com/lovechoice/
→ 沒貼小廣告,沒做國外社群運營:
沒到國外的社群貼小廣告,也沒有運營 discord 之類的平臺。
當然一個人能做的有限是個問題,但懶和麻痺大意的問題更嚴重。
總之,海外 App 發行這塊確實我做得很糟糕,可以說直接導致了遊戲的涼涼,這也跟團隊的成員道個歉。我的鍋。
個人感覺,對於國內開發者來說,這一塊比起其他任何平臺都需要發行商的幫忙。文化隔閡和遊戲平臺的問題尤其顯著。雖然我也知道買斷制的尷尬盈利能力,讓我幾乎不太看的到做這塊業務的發行商也是事實。
· 伺服器相關
因為沒有發行商的幫助,原本通過 steam 伺服器實現的一些功能需要我們自己學實現了。原本是一個很好學習伺服器知識的機會。但也是因為我心思已經主要放在新專案上了,一直不想去碰它。最終還是找了一個程式朋友幫忙完成的,網頁的搭建也是他幫忙的。不得不說,只是提需求,不用寫程式實在太爽了。再次確認了自己真的很討厭寫程式碼,以後有條件不用自己做程式的話,我估計就一行程式碼都不會寫了。
但這次我自己也看了一些伺服器相關的東西,起碼現在不會再覺得它是很難的東西了。一些簡單的功能還是完全可以自己實現的。
【Steam 正式版】
有幸請到幫《極樂迪斯科》做漢化的輕語工作室幫忙重新翻譯了《揀愛》的英語版本,效果可以說是立竿見影。雖然說我自己的工地英語翻譯也能夠準確傳遞意思,但《揀愛》畢竟是一個需要讓人感動的敘事遊戲。同一個意思的不同表達,效果可以說的是差之毫釐謬以千里。經過重新翻譯的版本,再也看不到老外吐糟翻譯不行的問題了,隨著轉入正式版,也在國外帶來了一波熱度。從之前的國內:國外銷量接近 9:1 的比例,到現在約 6:4 的比例,比例上來說算是“健康”了不少。另外,可能是因為有一個韓國百萬級 youtuber 發了揀愛的視訊,所以韓國的銷量在一段時間內力壓國區成為第一,也算是意外之喜。雖然我一句韓語也不懂,但感覺他的視訊效果是挺不錯的。有感興趣,懂韓語的朋友可以去看看。https://www.youtube.com/watch?v=L1_VWjDvGZg
【國內 PC 版】
基本沒有什麼想說的,發行商幫忙處理了很多事情。算是所有移植裡面最不需要我操心,也沒怎麼出現大問題。wegame 的玩家比我想象中的要多。沒了。
【主機版】
主機版的西班牙發行商,雖然也是大包大攬不用我操心,但是工作效率和質量真的有點想讓我吐槽的。雖然我知道疫情對歐洲影響很大,但足足兩年的移植時間也讓我很懷疑他們的工作效率。然後主機版在他們的移植之後多了不少惡性 bug,例如簡體中文無法顯示,只能用繁體中文玩,在某些場景下會卡死之類的,最討厭的是我明明知道要怎麼改,但是因為程式碼根本不在我手上我壓根改不了。郵件交流也是回覆十分慢,十分氣人。
這裡也跟購買了主機板的玩家道個歉,但有些事情我確實控制不了。
本年度算是徹底將《揀愛》這個專案結項了。想想獨立開發整整五年還只有《揀愛》這麼一個小體量的正式上線專案,也是夠效率低下的( ̄▽ ̄)。這種“一魚多吃”的方式確實可以幫助我解決部分經濟問題,但終歸不是長久之計,但起碼我下個專案開發期內的生活費是都有了著落。一個人攬下太多的工作也是個問題,特別是把很多和遊戲設計和開發無關的工作也攬下來確實不是個好的選擇。不過目前沒有條件組成團隊也是事實,就挺矛盾的。
我想,要是有條件,將移植工作交給有能力的發行商處理應該算是最優解了吧。
希望下一個專案能解決這些問題吧。
新專案相關
因為專案的名字還沒有正式公佈,這裡我就叫它“三國專案”吧。這是一個和兩位朋友合作的專案,一個是歷史迷策劃兼專案發起人:今一,另一個是美術大佬 chan 哥,而我主要負責遊戲設計的落地以及程式部分。已經 32 歲的我是三人當中最年輕的一個,是個真正的老男人開發組。
遊戲是三國題材的單機 slg。是的,和光榮三國志幾乎一樣的型別。如果說把遊戲內的設計風格做個定位,我個人感覺是介於光榮三國志、太閣立志傳、十字軍之王之間的。從它們那邊借鑑一些優點,然後再加上一些我們自己的東西。當然體量上會比上述幾位前輩小上一截,畢竟三個人挑戰幾十人團隊去做的型別本來就已經足夠無謀了。
事實上游戲是在 2020 年末正式立項的,所以到現在滿打滿算已經開發一年了。經過這一年的開發,我發現這種歷史題材的 slg 遊戲的開發,比我想象中更加無聊。
遊戲設計與歷史還原的矛盾
理想情況下,利用適當的系統設計和細節設計去儘可能還原歷史,是這類 slg 應該追求的部分。但實際落地的設計裡面,就少不免會有遊戲性與歷史還原衝突的部分。在絕大部分的遊戲當中,遊戲性都是優先度最高的,與遊戲性相沖的部分都應該為遊戲性讓路。但我們實際操作中,卻發現很多時候歷史還原優先度是高於遊戲設計的。簡單地舉個例子,在策劃今一翻查大量文獻,整理出近二十個那個朝代的官職名和對應職責之後,我們發現這裡面的很多官職,事實上並沒有職能上或者等級上的明顯差別,只是一個稱謂上的不同而已。如果是普通的遊戲,這些差不多的職位就應該被簡化成五六個不同等級或是真正職責範圍有所不同的職位。這樣簡化,一來可以降低玩家的理解門檻,二來去掉冗餘部分也避免了系統上的混亂,三來,開發上也是更省功夫的。可謂喜聞樂見。但放在一個盡力還原歷史的 slg 遊戲中,設計的目的就完全不一樣了。我們最終還是保留下來了這所有的職位,並儘量讓它們多少都能夠存在一些差異性。哪怕可能只是體現在人物對話上的差異。為的也就是那種還原歷史的味兒。這點其實和一些 crpg 遊戲挺相似的,一些設定雖然功利地看系統上幾乎沒有作用,只是徒增複雜度,但是如果系統設計上照顧到了,就會讓人感覺世界更可信,人物更真實。這種因為型別的特殊性,將其他因素放在遊戲性之上的設計傾向,倒是和我喜歡的敘事向遊戲十分相似。
勞動密集型的開發模式
Slg 從來都是龐雜系統的代名詞。而我們又想用 rts 方式而非戰棋作為戰鬥呈現、儘可能支援 mod、內政系統也希望做一些自己的創新的情況下,整個專案的複雜度瘋狂上升。作為半道出家程式的我感受到前所未有的程式壓力。當我研究 rts 的 ai 設計、學習什麼是兵力分佈熱力圖、什麼是行為樹、怎樣支援 mod、怎樣構建可信的人物行為時,經常感嘆自己智商不夠用。然後系統的數量多,設計的複雜度也是 slg 的特色,對應的就是程式這邊非常之勞動密集型。當然這本身就是我選擇這個專案的重要原因之一,足夠困難、複雜而體量大的專案,可以把作為程式設計師的我逼到極限,相信專案完成之後,我的程式實力就可以更進一步。這種 OJT(On Job Training)的思想,算是我在日本工作時期的遺產吧,個人覺得對於很需要平衡生存和進步的獨立遊戲開發者,是個不錯的想法。
另外,策劃需要一個人填充所有的遊戲資料(人物 profile,文字,指令碼,戰鬥地圖 etc.),美術需要一個人完成所有美術資源(立繪、ui、背景 etc.)所以其實對於我們三個人來說都挺像一種極限運動(大霧)。某種意義上,強度不低於 gamejam,但這次的 gamejam 可能要持續個兩三年。
哪怕說這個遊戲的開發上這麼有挑戰性,但因為不是我自己的專案,而且設計上的自由度實在受限嚴重。時間長了,難免還是會感到無聊。另外這次也是我第一次參與到不是自己發起的專案的開發當中,現在我能某程度理解之前參與我專案的人為什麼都顯得沒那麼有“參與感”了。其實完全是因為發起人“參與感”往往太強的原因。
這個專案的相關內容會在遊戲公佈後慢慢寫的,暫時就寫這麼多吧。遊戲出來以後我也打算在做一個遊戲設計開源系列,去分享一下這個遊戲設計過程中的心得(挖個大坑)。
視訊相關
今年發了一個【遊戲設計開源計劃】系列視訊,每月一期共 7 期,已完結。
雖然受到了 5 毛後期,佛系配樂和我的廣普影響,視訊的質感確實有點拉跨,但我覺得對於開發者同行來說,視訊的內容還是挺有參考價值的。不論設計的水平如何,起碼這些設計案例和經驗分享,都是經過真實的上線專案驗證的。我也儘量在裡面把我最真實的想法、反省和設計思路都說出來了。
當三國專案完成以後,我也希望能夠抽空再做一次這樣的系列視訊。希望這些經驗能給其他開發者一點參考。
一直以來,我都很奇怪,獨立遊戲開發者之間討論遊戲設計的情況十分罕見。而作為玩家的時候,給開發者提出一些對於遊戲內設計的疑問,得到的往往是“我已經收到了你的建議,謝謝”一類的官方回答(當然可能這是客服回答的,並非開發者)。我十分反感這種回答方式。沒有哪個設計是完美的,更沒有哪個設計師是一開始就很厲害的。為什麼就不能承認自己作品裡面的缺點呢?如果一個玩家在時間並不長的遊玩時間內都能感知到的設計問題,作為設計師的你卻不能作正面的回應,是不是證明你在長達數年的開發過程中根本沒有想清楚呢?哪怕回答這些問題我們清楚,但是因為受到開發資源所以我們沒有辦法解決,或者因為其他設計上的考慮我們做的取捨都好,哪怕這些決策在後來看不是完美的。但發現問題所在,才是進步的第一步。
所以我先拆解和覆盤了自己的專案,因為比起別人的作品,當然我會更瞭解自己的作品。製作起來也會比較容易。下一年也有計劃去做一些不同形式的遊戲相關的視訊,希望能夠把遊戲設計的討論推廣到更大的人群中去,又或者能在玩家當中種下一些遊戲設計思考的種子那就更好了。當然,對於我這個只有幾千粉的小 up,大家聽聽就好了 hhh
個人相關
Gamejam
今年沒有參加過 gamejam,就挺失敗的,但不得不說疫情以來去參加 gamejam 的動力小了很多。另外也是平時開發確實已經夠累了,有點提不起勁的感覺。往後大概也是隨緣參加吧,碰到覺得有 idea 的題目就參加。
身體
身體一直挺差的。屬於大病沒有但小病不斷的情況,體重沒控制好,體檢報告也不怎麼好看。更加過分的是上年開始甲溝炎就一直反反覆覆沒好過,經常疼得連路都走不好,痛苦。堅持了一段時間的跑步減肥,正覺得有點起色了就犯甲溝炎,真是鬱悶。
中年人的養生看來要搞起來了( ̄▽ ̄)
經濟
收入比上年要差,但還是挺不錯的,加上現在上的平臺多了。三國專案完成之前的生活費應該還是有保障的。而三國專案的目標就是能賺到養到一個三人團隊的錢。希望能實現吧。
遊戲
今年也是玩的遊戲不多。也沒有特別想說的。
以上,一如既往的突然結束。
總的來說,這五年還是過得挺精彩的,希望之後五年能更好吧。
加油!
相關文章
- 日常專案經驗總結
- 開發中的一些經驗總結
- 《軟體專案經驗總結》
- 總結Django一些開發經驗Django
- 初中高階的 git 和 gerrit 技巧【大型專案實戰總結 && CR 經驗】Git
- 建立“防洪系統” ! 製作人分享做好專案前期管理的10條經驗
- 經驗總結--我的小程式開發和進化之路
- Redis在專案中合理使用經驗總結Redis
- React專案從Javascript到Typescript的遷移經驗總結ReactJavaScriptTypeScript
- 【原】深度學習的一些經驗總結和建議 | To do v.s Not To Do深度學習
- Kotlin專案中 GlideApp 構建失敗經驗總結KotlinIdeaAPP
- 影像分類:來自13個Kaggle專案的經驗總結
- 《最終幻想 7 重製版》開發者專訪:關於致敬經典和開拓創新的思慮
- Android開發經驗總結Android
- iOS開發經驗總結iOS
- 用vue做專案的一些總結Vue
- 《五行》從0到1設計遊戲——專案管理經驗總結遊戲專案管理
- 關於程式和執行緒 自我的一些總結執行緒
- 關於微服務的一些總結和經驗之談,來看看你都瞭解嗎微服務
- [日常] SinaMail專案和技術能力總結AI
- Flask後端開發(二) - 功能實現和專案總結Flask後端
- 關於DDD和COLA的一些總結和思考
- 2020年的一些思考和總結
- redo log 和 binlog 的一些總結
- 內部業務系統的一些經驗總結
- 基於 abp vNext 和 .NET Core 開發部落格專案 - 終結篇之釋出專案
- 大老師的前生——AlphaMao專案的回顧和總結
- iOS開發經驗總結2iOS
- iOS開發經驗總結3iOS
- 關於VUE專案地圖開發中大量點標記繪製一些總結Vue地圖
- 資深架構師的經驗分享——軟體專案開發和決策架構
- 2年經驗總結,告訴你如何做好專案管理專案管理
- Java專案中MongoDb學習和使用總結JavaMongoDB
- 一個專案經理的切身經驗總結:測試用例可以被替代嗎?
- 使用七牛雲端儲存的一些經驗總結
- 演算法工程師老潘總結的一些經驗演算法工程師
- Akka實踐一些總結(java專案)Java
- LNMP 環境部署 Laravel 專案的一些總結LNMPLaravel