矛盾與規則的結算
引言
規則的制定者往往很難完全看清楚自己所指定的規則的全貌,更別提將其精確而又完備地描述出來。
最典型的例子,就是“以子之矛攻子之盾”,桌面遊戲如果有“無敵的矛”和“無敵的盾”,玩家們一定會產生爭議。
電子遊戲會以既定的程式來處理所有的規則問題,一定會有確定的結果(包括以一定規則進行隨機,也是確定的結果),由於程式處理的確定規則的存在,這些誤解倒也並不會引起爭議。但也常常會出現“實際執行的規則”和“玩家理解的規則”乃至“作者設想的規則”存在衝突的情況。如果處理好這些衝突,是設計系統複雜的遊戲的時候必須要考慮的。
矛與盾的層級
很多遊戲裡,裝備上會有“提升5點攻擊”和“提升10%攻擊力”之類的描述。他們放在一起的時候就有可能會讓玩家不知道到底怎麼算的,不過具體的攻擊力數值通常都會顯示出來,玩家也懶得去管這個數值是怎麼算出來的。
有些遊戲會描述為“基礎攻擊力”以避開疊加的問題,不過還是有很多遊戲裡面會把其他裝備/特技/增益提升的攻擊力進一步按比例加成,這樣先計算數值變化,然後再計算比例變化的情況。數值和比例的變化就分屬不同的層級。
在程式中,不需要刻意劃分層級,數值的計算也會按照確定的順序自上而下。但是如果沒有確定的層級,就可能會出現矛A的5點攻擊力加在矛B的10%攻擊力之前,而矛C的5點攻擊力加在之後。使得A和C差了0.5的攻擊力,而他們的文字描述卻是一樣的。
比如說有人裝了兩隻矛(本來覺得這個例子挺奇怪的,後來想想這樣的遊戲不但有而且很火),效果分別是。
“裝備者的攻擊力等於15”
“裝備者的攻擊力等於20”
“裝備者的攻擊力等於15”和“裝備者的攻擊力等於20”這樣的效應非常罕見,他們放在一起的時候的後果顯然是矛盾的,而根據程式實現方式的不同,會有不同的結果,有的會主動判定優先順序,誰大(小)算誰的/誰稀有度高算誰的。
也有很多是按照存放裝備資料的資料結構依次判定每個裝備的效應。決定裝備效應結算順序的方式有很多,或是按照裝備欄順序走或以主裝備欄位為準,可能是後裝備的排在後面生效,可能是根據固定的裝備欄位走,也可能在資料結構裡按某種規則進行排序。
將攻擊力設為15和20的效應只能有一個生效,根據不同的實現方式,會有不同的表現形式,如果程式沒辦法準確地實現規則的描述,無法得到按規則文字想要的結果,可以考慮一下按照程式修改規則的描述,這樣可能比較方便。
角色本身數值/將數值設成某個特定值/增減一定的量/增減一定的比例。同樣的效應放在一起,確保一類效應結算完成後再結算層級更低的效應。需要注意的是層級低有時候因為後結算,會產生更大的影響力,請確保因此而產生的效果是理想的。
常識與特色
由於遊戲的同質化,或者說得好聽點叫趨同進化,很多遊戲的規則都是不言自明的。基礎的規則已經成為了玩家心中的“常識”,好好運用這些常識,能夠省下不少描述規則的麻煩。
而很多遊戲也有自己的特色,會有一些專有名詞,這些專有名詞又可以簡單地分為三類:
- 新玩家看不懂是啥的
- 新玩家看得懂是啥的
- 新玩家以為自己看懂了但其實沒看懂是啥的
使用一些被普遍使用的名詞或者符號可以讓玩家很容易理解,雖然傷害演算法不同,但玩家都知道“攻擊力”越高造成的傷害越高,“防禦力”越高受到的傷害越低。
筆者之前做的遊戲Dog Jam因為題材比較偏門,不得不使用專有名詞,“設計”,“實現”和“構思”大家都知道是什麼意思,但是放在遊戲裡就非常不直觀,玩家很難理解到底是什麼意思。如果是“技能/招式”,“怪物”,“生命值”之類的詞彙,玩家就很容易理解“技能”用來打“怪物”以降低“生命值”,“生命值”歸零會“死亡”。而對於“對著‘構思’使用‘設計’以提高‘實現’”就比較難以理解了。
很多遊戲當中都有一些關鍵字,老玩家只需要看到詞就知道意思,而新人則會看得雲裡霧裡。
比如萬智牌剛出的這張牌。
完全可以只寫“傾曳追溯”四個字就夠了,但是還是為這兩個關鍵字加上了註釋。畢竟新手根本不可能知道傾曳(Cascade)和追溯(Retrace)到底是什麼東西。
不過這種完全不知道是啥意思的詞,玩家反而相對比較容易去理解全貌,會認真閱讀說明。使用常見的名詞,但在某些地方又有些特殊,則可能讓玩家陷入更大的迷茫之中。
例如防禦力,不同的遊戲裡會有“按比例減傷”“定量減傷”的做法,但是有個遊戲裡“防禦力”是“使用防禦指令的效果”,如果玩家不做出防禦動作則完全沒有效果。
這種設計本身也不壞,但因為這個遊戲的其他方面都太過常規了,以至於玩家根本不會用心去研究遊戲的規則,加上這遊戲裡“防禦力”高的角色“生命值”也高,以至於筆者通關了都沒發現防禦力不是那麼用的。
如果它的“防禦力”不叫“防禦力”,而是起了一個專有名詞“XX力”或者是和常見用法稍有區別的“防護力”之類的名字,玩家就更容易留心這項數值的具體效果,而不是像看到“防禦力”時一樣想當然。
使用“常識”可以省下介紹規則的功夫,而在展現特色的時候,請注意“常識”是否會讓玩家對你的特色產生誤解。
惡魔城使用“心”來作為使用副武器的能量而不是回覆生命值的道具,現在的玩家很容易產生困惑。即使是惡魔城誕生的1989年,電子遊戲的少年期,玩家們也對此感到不能理解。這個設定倒是一直流傳了下來,成為了惡魔城的一個特色(也是因為根本沒什麼別的遊戲這麼做)。
無敵只是個詞
矛盾的故事裡,盾的描述是“物莫能陷之”,矛的描述是“於物無不陷也”。在很多桌遊中,都有“不能大於能”這樣的規則,例如萬智牌裡,矛的“消滅”是消滅不了盾的“不滅”的。
“什麼都能穿透”穿透不了“不能被穿透”,聽上去的確是挺彆扭的。而這彆扭的來源,就是“無不”這種遠稱不上嚴謹的描述。
在規則的設計上,應該避免“什麼都能”這種描述。設計了"什麼都能穿透的矛",意味著“不能被穿透的東西”就不能出現。這就成了設計師需要自己進行規避的東西,而非能夠交由規則本身進行處理。
“無敵”這個詞因為比較常用,大家也不會糾結於“無敵”有些情況下還是會出岔子,比如平臺跳躍遊戲無敵狀態下還是會掉進坑裡摔死之類的。一切形式的“無敵”總會有辦法對付,除非設計師主動避開所有能夠觸碰無敵的東西。
如果平臺跳躍遊戲,所有可能拿到無敵狀態的地方,在無敵時間結束之前玩家都找不到坑,或者其他可以殺死無敵的手段,那麼無敵就會成為真的無敵。如果遊戲中所有的盾牌都會被某把槍穿透,那把槍就是真的“於物無不陷也”,雖然遊戲的擴充套件性可能會出些問題,但是……畢竟,“無敵”“什麼都能穿透”“絕對不會死”這種描述,真的用起來還是很有表現力的。
這些描述可能看上去含混不清模稜兩可,但是作為“遊戲文字”來說他們很可能更加優秀。可以有更多有趣的描述,玩家有時也願意享受“無敵”這個詞的霸氣,以及在矛的背景敘述裡放“不知道它和那面盾碰上會怎麼樣”的冷笑話。
不是所有玩家都喜歡閱讀比課本還複雜的遊戲規則的。就像惡魔城,再遲鈍的玩家也能很快理解心不是回血而是用來使用武器的。玩家從嘗試中理解規則的能力是很強的。
作者:茶多酚
來源:indienova
原地址:https://indienova.com/indie-game-development/conflics-in-game-design/
相關文章
- 雲端計算與21世紀的機器規則
- JS中this的繫結規則JS
- JavaScript中this的繫結規則JavaScript
- Mysql-基本的規則與規範MySql
- DRY原則與微服務的矛盾:共享複用會導致耦合 - AllenHolub微服務
- JavaScript this 繫結規則JavaScript
- javascript關於toFixed的計算規則JavaScript
- 規則引擎與機器學習比較與結合機器學習
- C# sizeof 計算規則C#
- canvas非零繞組規則與奇偶規則Canvas
- JS中this的4種繫結規則JS
- id與class 命名規則
- 結構與演算法(04):排序規則與查詢演算法演算法排序
- 【原始碼解析】AsyncTask的用法與規則原始碼
- 連結器規則會引入的巨坑
- MapReduce--Input與Output規則
- 結對專案四則運算
- javascript ==與!=的比較規則(加踩坑)JavaScript
- 規則引擎與ML模型的比較 - xLaszlo模型
- 事件繫結和樣式規定的原則事件
- CSS樣式規則-CSS結構的特點CSS
- 我們都會知道的Javascript:this的繫結規則JavaScript
- 2017天貓雙12購物津貼怎麼結算?使用門檻條件與規則介紹NC
- 遊戲規則的制訂者就真的懂得“規則”與“樂趣”間的關係嗎?遊戲
- Python基礎-不同型別之間的運算規則Python型別
- 配置ModSecurity防火牆與OWASP規則防火牆
- Git忽略提交規則.gitignore配置總結Git
- Drools規則引擎實踐直白總結
- [C++]變數宣告與定義的規則C++變數
- 結對程式設計-四則運算程式設計
- Activity的啟動模式及IntentFilter匹配規則總結模式IntentFilter
- CSS樣式規則之CSS結構的特點CSS
- 矛盾
- JAVA_資料型別介紹與基本資料型別之間的運算規則Java資料型別
- 規則
- .net core Web API引數繫結規則WebAPI
- 如何權衡業務規則的遵守與違反?
- 結對編碼-四則運算 2252118 2252121