流浪方舟重點設計問題覆盤
前言
我們在去年,就對《流浪方舟》進行了全面的覆盤,其中的設計部分,是非常值得聊聊分享一下的。
流浪方舟當然有很多設計上的問題,當時有設計續作《流浪方舟2》的想法,也針對這些問題設計瞭解決方案。當時解決的大方向很有意思,就是全面轉向PVE和GVE,如今再看,仍舊有一定可行性。但基於本身的喜好,認可以及擅長,這個方向並不是優解,所以權衡之後pass了這個大方向,轉而設計了現在飛牌的方向。但其作為和當前思路的一個對比,仍舊是非常有參考價值的。下面的重點問題覆盤,將會以方舟1的問題——原本PVE思路如何解決(代號舟2)——最新思路如何解決(代號飛牌)這樣的格式來展現。希望能對大家有所啟發,如果有思考不對的地方也歡迎交流,會對我有很大幫助。
舟1問題1:數值校驗問題
核心機制的位移,湧現,以及追求爽快,整體單位發射移動速度較快,包括生存能力偏低等原因,導致了單局單次碰撞數值反饋不明確,玩家並不能在高速移動中看清碰撞的具體數值變化。這就又直接導致了數值校驗難,成長顆粒度不夠細等問題。
更進一步,物理湧現碰撞會轉化成攻速,導致戰前養成和戰中策略操作的佔比失衡。
舟2最佳化方案:
- 調整物理系統,調整湧現佔比,保證發射瞬間速度不下降太多的前提下,減慢整體位移速度和減少位移距離。目標是使得玩家單個英雄操作的碰撞總數下降,但是強調單次碰撞的成果,包括增強對連擊數這個引數的強調。
- 配合上述最佳化,同時戰中操作英雄數量進行調整,例如將其改為3個,在保證核心機制多次碰撞基礎體驗的前提下,戰場關注的單位越少,數值越集中。同時增加單個英雄的血量,並且配合英雄生存能力的提升,碰撞感知可以做的更明顯。
- 戰中的互動UI也配合最佳化,增加總血條,連擊數變化強調等等
- 整體目標為戰前養成和戰中策略操作的佔比約為7:3
代號飛牌新思路:
放下物理彈射PVP校驗數值的執念,將成長,數值校驗,對群割草釋放等體驗,放在PVE和GVE中。PVP,可能會有養成,但養成拉差明確控制得非常小,只作為階段性成長的hook或者用其他剋制的投放手段,稀缺地放出。並且將PVP和PVE兩者數值完全分離,但機制儘量統一。商業化不直接賣PVP數值,主賣PVE和GVE效率,機制橫向收集,次賣外觀,BP等。
舟1問題2:先後手問題
舟1設計上過於追求用核心機制來達成先後手平衡,對後續設計的挑戰較大,同時即使做到了平衡,玩家初見感知還是有先後手優劣勢。
為了先後手問題和滾雪球問題,舟1將核心機制設計為五人依次上場的模式,並且死亡後其他隊友頂替回合的機制。這導致,前幾回合和後幾回合殘局,都是碰撞次數更少,離核心樂趣更遠的低體驗過程。並且由於前兩回合單位數量少,感知上還會放大第一回合空場的負面反饋,使得先後手問題更明顯。
同時還會引出養成相差很大的兩方戰鬥,仍需等對方上完至少五回合才能結束戰鬥的節奏問題,不利於PVE和高養成玩家體驗。
舟2最佳化方案:
不在局內機制上糾結先後手平衡,將先後手放到局外決定。整體上,用最簡單的速度值決定先後手,並且根據局外的裝備等自由分配的屬性,加入簡單的上校博弈,例如局外選擇高速裝備,該裝備的其他屬性就會弱一些。最終,在養成進度差不多的玩家間,形成高速-中速-低速的迴圈剋制。
代號飛牌新思路:
透過核心機制本身解決。利用能量增長機制,單回合運算元增加,總決策數增加,來解決先後手問題。整體單局決策數增加,就更容易分配敵我回合的決策數,平衡先後手更簡單。
舟1問題3:操作輪替問題
前面說的舟1是操作輪替的機制,也就是一個英雄死亡後,不會空出該英雄的回合,而是順延後面的英雄頂上。因此,會出現低強度的英雄擠佔高強度英雄回合,收益反而下降的問題。這也是我們遊戲單核是最優解的原因,不利於平均養成。
同時,單回合運算元過少,集中在一次操作,放大了單次操作和決策負擔,更放大這個問題。
舟2最佳化方案:
前文的生存能力佔比最佳化後會自然解決一部分問題,但根本的解決方案,是讓英雄單位的價值有更大的一部分,轉移到跨回合生效,超越回合的限制。
例如一部分英雄不能操作只提供在場效果,上陣改為6個英雄,三個可操作英雄,三個輔助英雄,可操作英雄全部死亡後失敗。
例如最佳化生存能力佔比,增加在場技能,夾擊輸出等跨回合生效的收益權重。
代號飛牌新思路:
飛牌小卡組快速輪換,不放回隨機的核心機制,從根本上沒有輪替問題。
舟1問題4:節奏問題
舟1過度追求絕對時長短的快節奏體驗,但是本身有效體驗才是關鍵,時長只是一部分考慮,勝負本身帶來的正負體驗強度,單局付出的代價等等,都影響玩家對待單局的態度。
一局單局體驗,若是過程足夠有效,則時長可以適當延長。反之,優先已經保證有效體驗足夠的單局,時長越短負擔越小。
舟1對單局時長過於嚴苛的把控,導致整體節奏偏快,使得整體英雄環境輸出能力偏高,生存能力偏弱,導致流派間差異拉不開(都是一回合秒殺,談何生存流派)。
同時,由於前述輪替上場的機制,有較多比例的低效時間,反而影響節奏。
舟2最佳化方案:
全部單位直接上場,跳過前期輪流上場的低效時間,加入前期回合的保護機制和後期回合的加速機制。整體上,保持更長時間的多單位VS多單位的高體驗時間,加快整體節奏,減少垃圾時間。
代號飛牌新思路:
不追求2分鐘或3分鐘一把,而是不超過10分鐘的最低前提下,只關注有效時長,包括敵方回合我方的操作空間(不幹等對方),包括更密集輕量的操作和策略,重點是人人間的互動博弈。
舟1問題5:外掛問題
外掛的核心設計理念是將遊戲核心機制的發揮(英雄技能)拆出來自由搭配,來提供一個新的養成維度和有效的追求。
外掛問題的本質是對遊戲核心機制的過度使用,過度追求自由搭配的策略性,帶來可玩性的同時,破壞了設計對戰鬥體驗的規劃和掌控。
幾次外掛的迭代則可以看出,最初追求數量,但是核心機制本身的問題導致對核心機制的利用極難平衡。
從而大數量的外掛有大多數對玩家來說是無用的外掛,導致實際可用的外掛提供的內容體驗有限。
並且,外掛自由搭配的互動成本非常高,刪減外掛數量不能解決問題,因為更換裝配的英雄數量不會減少。
最後,外掛對核心機制的利用顆粒度不好把控,例如復活外掛,單復活的效果價值就遠超其他數值,導致不同外掛價值上下限,獲取難度差距過大。
舟2最佳化方案:
統合外掛為少數複合外掛,同時每個英雄公共使用這些複合外掛,既能平衡不同外掛的價值,也降低了互動成本和決策成本。
做更縱向的外掛養成,用外掛來承載一部分公共養成,包裝上不一定是用現有的外掛包裝。
通用核心機制的釋放,做的更可控,更好規劃,非通用核心機制的釋放,全部放在英雄上面。
代號飛牌新思路:
對核心機制的拆分自由組合,需要非常慎重,以套裝效果這類的可控方法來釋放機制會更好。同時,作為可玩編輯器的“磚塊”的重要一環,搭建“build大廈”免不了需要大量的“磚塊”,透過一些硬性限制來統一最終目標(最大秒傷),然後放開一些機制組合上的約束,反而更容易百花齊放(多種途徑達到最大秒傷,因有限制,反而設計自由度更大)。
舟1問題6:長線問題
舟1的長線思路是依賴單V單的同步PVP,在重養成,DAU和社交不見長的情況下,效果並不好。該思路決定了頂層設計的偏向,導致了上述的很多問題,包括技能設計難度,數值驗證難度,追求競技性帶來的問題等。
舟2最佳化方案:
舟2會保留已經驗證的單人同步PVP,但定位不做為長線的依託,而是主要作為限時玩法,多人PVP的教學等意義。
核心機制上,舟2最佳化長線的方式有兩個,內容更新能力以及玩家創造內容:
1加入可破壞的場景元素,以及可配置場景物件的關卡編輯器,服務於後續持續更新有效不同體驗的關卡
2核心機制更適配多人合作,合作PVE模式作為未來長線遊玩內容的重要一環,例如門票副本等等
代號飛牌新思路:
不再依賴單V單PVP,核心機制上就為多人混戰和GVE而設計,PVP仍舊存在,但只作為多人模式的引導,以及一種副加模式。其他思路可以看賽季的文章。
舟1問題7:單局理解成本問題
舟1單局理解成本上還有一定最佳化空間,包括技能,外掛,狀態等等。
護甲和護甲穿透也是冗餘設計,由於不是單純的加減法,導致碰撞的傷害更加不明確,進一步增加了第一點數值反饋問題。同時也增加了局內的理解成本,多的兩個數值維度,玩家感知不到實際追求動力不足。約等於沒有。
舟2最佳化方案:
減少技能數量,一個主動,一個在場即可,中間兩被動技能冗餘,可以放到其他地方去養成。
如前文,外掛最佳化為複合外掛。
將現有除法護甲機制,改為減法護甲機制,更適合我們核心機制。加入護盾機制和護盾過載機制,外顯感知更明顯,同時輔助解決湧現佔比問題。
代號飛牌新思路:
每張卡一個技能效果,不要外顯不明顯的護甲或減傷機制,儘量保持局內所見即所得的原則。
總結
整體來說,舟1最底層的問題來源在於立項之初,對養成商業化的理解很淺,核心機制都是以單對單PVP為核心進行設計,後續開發又偏向數值養成,才導致了後面的一系列問題。
舟2的思路是純PVE,偏日卡like的養成,相當於只繼承了舟1物理碰撞機制的表現力和小部分樂趣。我認為不是最好的路子,也不是適合我的方向。
而飛牌的思路,因為還比較早期,整體方向上雖然非常明確,但具體的設計還不一定是最優方案,還得繼續測試持續迭代設計,也希望大家多多討論斧正。
來源:魚塘遊戲製作工坊
原文:https://mp.weixin.qq.com/s/Dvl5e59wt7APMZVoN_WbcA
相關文章
- ssh問題之覆盤
- 棋盤覆蓋問題
- 如何做線上問題覆盤
- 覆盤:裂變遊戲設計探索遊戲設計
- 分治演算法-求解棋盤覆蓋問題演算法
- @程式設計師,安全問題必須重視!程式設計師
- 覆盤 PHP 經典面試問題解決過程:上臺階問題PHP面試
- 樹上最小點覆蓋的一類問題
- 【問題覆盤】在Ubuntu 20.04下安裝OFED驅動Ubuntu
- 前端技術分享:頁面效能優化問題覆盤前端優化
- 【完虐演算法】LeetCode 接雨水問題,全覆盤演算法LeetCode
- 一次線上OOM問題的個人覆盤OOM
- 分散式重複提交問題架構設計思路分散式架構
- 我的2023年:程式設計師的自我迭代、技術覆盤與生活點滴程式設計師
- 豪奪日本暢銷榜第二!《明日方舟》日本市場營銷覆盤
- 開發者如何走的彎路:Into the Breach設計覆盤
- 真實案例:人工智慧(AI)產品設計覆盤人工智慧AI
- Android 面向切面程式設計 AOP 解決連續點選開啟重複頁面問題Android程式設計
- 深度覆盤-重啟 etcd 引發的異常
- Docker殺掉了容器?問題分析與解決過程全面覆盤Docker
- Dubbo 穩定性案例:Nacos 註冊中心可用性問題覆盤
- 最小路徑可重複點覆蓋
- 21年技術建設覆盤
- 線段覆蓋問題
- mp-vue微信小程式多層路由跳轉問題覆盤Vue微信小程式路由
- MyBatis版本升級導致OffsetDateTime入參解析異常問題覆盤MyBatis
- 管中窺豹-ssh連結過多的問題分析及覆盤
- 盤點一個Pandas實戰需求的問題
- IPv6轉換常見問題盤點
- 域名解析常見問題盤點及解答
- 覆盤|怎樣做好一次覆盤
- 做專案覆盤時,是如何覆盤的?都覆盤哪些內容呢?
- kettle流程設計問題
- 程式碼設計問題
- 棋盤問題
- PHP程式設計師遇到問題的冷門知識點PHP程式設計師
- HBase高階特性、rowkey設計以及熱點問題處理
- 百萬級GMV視訊號覆盤3點思考