第67章 雜交版的實現
對於穿越前的那個世界來說，植物大戰殭屍的二次開發並不非常容易。
每一種獨特的新玩法都相當於是從頭開始做了一遍。
這自然跟這部作品本身的架構有點關係。
這款09年就已經發售了的作品基於C++開發，使用的並不是現代那些成熟完整的遊戲框架，在各個方面都有一定的缺陷。
但林琅從頭做一遍，自然不會再老老實實地去一比一照抄，從開發之初，他就選用了C#作為主架構的首選語言。
哪怕不藉助HarmonyX這種注入補丁，他也能夠輕鬆加入各種模組支持。
得益於他內置的程序集加載器，只要模組的結構符合規範，便可以在啟動遊戲時動態熱加載這些置於外部資源中的模組。
也因此，增加新的植物、殭屍、玩法等的工作量也得以驟降。
對於植物大戰殭屍這款遊戲來說，雜交版的完整體量已經完全可以當作DLC來賣了。
不過林琅不打算這麼做，也不準備完整復刻雜交版出來。
畢竟只是一個用來當作模組開發教學的項目，只要能利用到那些接口就足夠了。
過於繁多的內容反而會打擊玩家的創造熱情，這些應該由他們自己去發掘。
這套體系想要實現起來非常簡單。
一個完全面向對象的高級語言，對於遊戲來說是非常優雅的。
首先這些所有新增的植物，自然還是要遵循植物大戰殭屍的底層邏輯，繼承自同一個基類，也就是實體類。
為了便於使用，林琅已經提前對實體類進行了諸多衍生實現。
比如殭屍類、植物類、射彈類等，它們皆出自實體，卻又各有不同。
而這些子類也自然都有著易用的實現。
就如林琅現在打算做的『雙發仙人掌』，自然就繼承自植物類中的『射手類』。
顧名思義，不論是豌豆射手、雙發豌豆、機槍、還是雙向等，它們皆可以繼承自該類。
只需要覆寫它內置的發射函數和彈丸種類的定義，便可以定製出一款截然不同的植物。
而對於不會編程的玩家來說，林琅也貼心的準備了一個完全可視化的工具。
射速、彈速、子彈類型、子彈路徑、擊中行為……
他幾乎為所有可以設想到的情況都預置了接口，實現了一套完全數據化驅動的體系。
這套機制可以讓玩家在完全0代碼基礎的條件下肆意發揮自己的想像力。
你甚至可以做出一個發射櫻桃炸彈的機槍射手！
沒錯，彈丸可不一定要是豌豆或是尖刺之類的。
林琅一不做二不休，乾脆將子彈的限制移除，讓所有基於實體類的實現都可以被當作彈丸。
而為了兼容這一點，他又將子彈的移動剝離成單獨的腳本，以動態掛載的形式實現。
這套機制非常巧妙，它就像是把所有東西都給『插件化』了一般。
我們大可以將任何東西都視作一個容器，一個能夠填入任何腳本的容器。
比如子彈，直接為它掛載『移動腳本』和『擊中腳本』，就可以僅靠修改這兩個腳本的參數的情況下讓子彈千變萬化。
最可怕的是，這個所謂的『腳本』，同樣是一個可以隨意繼承實現的類。
不過想要自定義新的腳本就很難在不編程的情況下做到了。
這套體系便是整個模組API的核心邏輯。
基於此，可以開發出無數匪夷所思的充滿想像力的另類玩法。
不過對於腳本的靈活應用，林琅打算留給他已經想好了的第二款模組。
當下這款自然還是集中在讓大家了解如何新增自定義的植物和殭屍等。
繼承自豌豆，將發射函數延遲片刻額外執行一次，並將子彈的引用替換成仙人掌刺。
僅僅如此操作，一個雙發仙人掌便做出來了，當然他還需要為其準備一套美術素材。
同樣的邏輯，陽光炸彈只需要繼承自櫻桃炸彈，為爆炸擊殺後添加一個生成一坨陽光的效果即可。
有射手類，當然也會有投手類，儘管它們都出自一個叫『攻擊型植物』的父類。
這樣的設計雖然非常便於理解和使用，但並非像看上去那樣完美。
複雜的重重嵌套帶來的是代碼的高度耦合，這其實並不符合編程追求的解耦思想。
一環套一環的層層依賴，帶來的結果是災難性的可維護性。
假設某一天林琅突然想要動一動實體類這個萬物源根，就有可能一腳踢翻整座『屎山』。
不過所見即所得，這對於模組開發者而言卻是一件好事。
不消多會兒，林琅便為幾種常見的植物類型都做好了變種版本。
但這還沒完，儘管可以直接為它們設置好陽光消耗，直接載入到卡池中，但他還是選擇了另一種方式。
回到主菜單的那個墓碑之上，這玩意兒其實並不像肉眼看上去那樣排列了幾個按鈕來實現。
事實上這整個UI都是完全程序化生成的，邪門到家。
為什麼要捨近求遠的搞成這樣的設計呢，這自然也是為了模組作者。
只需要在Mod類的主入口中聲明一個『菜單類』，執行註冊，它便可以就這麼直接顯示在墓碑之上。
藉由此，模組作者只要想，甚至可以完全在不靠注入的情況下對整個UI體系都做出客制化修改。
也就是所謂的『資源包』、「數據包」功能。
林琅在主菜單加入了一個『合成』按鈕，只要點擊，就可以跳轉到一個特殊的場景。
將植物卡組合在一起，只要符合他設置的配方，便可以解鎖雜交版的植物。
當然這整個合成卡牌的場景也是完全程序化的，只不過是調用了內置的『卡槽』類，又調用UI工具生成了一個顯示所有持有卡牌的倉庫。
對於0基礎用戶，林琅則是在開發工具中設置了一個可視化的UI設計工具，拖拽組件到對應位置即可。
一整套下來，一個全新的玩法便誕生了。
接下來便是運行工具包中的『編譯打包』工具，調用他準備好的程序集將一切都編譯成模組文件。
「來來來，又整新活了，來玩玩看。」
每一種獨特的新玩法都相當於是從頭開始做了一遍。
這自然跟這部作品本身的架構有點關係。
這款09年就已經發售了的作品基於C++開發，使用的並不是現代那些成熟完整的遊戲框架，在各個方面都有一定的缺陷。
但林琅從頭做一遍，自然不會再老老實實地去一比一照抄，從開發之初，他就選用了C#作為主架構的首選語言。
哪怕不藉助HarmonyX這種注入補丁，他也能夠輕鬆加入各種模組支持。
得益於他內置的程序集加載器，只要模組的結構符合規範，便可以在啟動遊戲時動態熱加載這些置於外部資源中的模組。
也因此，增加新的植物、殭屍、玩法等的工作量也得以驟降。
對於植物大戰殭屍這款遊戲來說，雜交版的完整體量已經完全可以當作DLC來賣了。
不過林琅不打算這麼做，也不準備完整復刻雜交版出來。
畢竟只是一個用來當作模組開發教學的項目，只要能利用到那些接口就足夠了。
過於繁多的內容反而會打擊玩家的創造熱情，這些應該由他們自己去發掘。
這套體系想要實現起來非常簡單。
一個完全面向對象的高級語言，對於遊戲來說是非常優雅的。
首先這些所有新增的植物，自然還是要遵循植物大戰殭屍的底層邏輯，繼承自同一個基類，也就是實體類。
為了便於使用，林琅已經提前對實體類進行了諸多衍生實現。
比如殭屍類、植物類、射彈類等，它們皆出自實體，卻又各有不同。
而這些子類也自然都有著易用的實現。
就如林琅現在打算做的『雙發仙人掌』，自然就繼承自植物類中的『射手類』。
顧名思義，不論是豌豆射手、雙發豌豆、機槍、還是雙向等，它們皆可以繼承自該類。
只需要覆寫它內置的發射函數和彈丸種類的定義，便可以定製出一款截然不同的植物。
而對於不會編程的玩家來說，林琅也貼心的準備了一個完全可視化的工具。
射速、彈速、子彈類型、子彈路徑、擊中行為……
他幾乎為所有可以設想到的情況都預置了接口，實現了一套完全數據化驅動的體系。
這套機制可以讓玩家在完全0代碼基礎的條件下肆意發揮自己的想像力。
你甚至可以做出一個發射櫻桃炸彈的機槍射手！
沒錯，彈丸可不一定要是豌豆或是尖刺之類的。
林琅一不做二不休，乾脆將子彈的限制移除，讓所有基於實體類的實現都可以被當作彈丸。
而為了兼容這一點，他又將子彈的移動剝離成單獨的腳本，以動態掛載的形式實現。
這套機制非常巧妙，它就像是把所有東西都給『插件化』了一般。
我們大可以將任何東西都視作一個容器，一個能夠填入任何腳本的容器。
比如子彈，直接為它掛載『移動腳本』和『擊中腳本』，就可以僅靠修改這兩個腳本的參數的情況下讓子彈千變萬化。
最可怕的是，這個所謂的『腳本』，同樣是一個可以隨意繼承實現的類。
不過想要自定義新的腳本就很難在不編程的情況下做到了。
這套體系便是整個模組API的核心邏輯。
基於此，可以開發出無數匪夷所思的充滿想像力的另類玩法。
不過對於腳本的靈活應用，林琅打算留給他已經想好了的第二款模組。
當下這款自然還是集中在讓大家了解如何新增自定義的植物和殭屍等。
繼承自豌豆，將發射函數延遲片刻額外執行一次，並將子彈的引用替換成仙人掌刺。
僅僅如此操作，一個雙發仙人掌便做出來了，當然他還需要為其準備一套美術素材。
同樣的邏輯，陽光炸彈只需要繼承自櫻桃炸彈，為爆炸擊殺後添加一個生成一坨陽光的效果即可。
有射手類，當然也會有投手類，儘管它們都出自一個叫『攻擊型植物』的父類。
這樣的設計雖然非常便於理解和使用，但並非像看上去那樣完美。
複雜的重重嵌套帶來的是代碼的高度耦合，這其實並不符合編程追求的解耦思想。
一環套一環的層層依賴，帶來的結果是災難性的可維護性。
假設某一天林琅突然想要動一動實體類這個萬物源根，就有可能一腳踢翻整座『屎山』。
不過所見即所得，這對於模組開發者而言卻是一件好事。
不消多會兒，林琅便為幾種常見的植物類型都做好了變種版本。
但這還沒完，儘管可以直接為它們設置好陽光消耗，直接載入到卡池中，但他還是選擇了另一種方式。
回到主菜單的那個墓碑之上，這玩意兒其實並不像肉眼看上去那樣排列了幾個按鈕來實現。
事實上這整個UI都是完全程序化生成的，邪門到家。
為什麼要捨近求遠的搞成這樣的設計呢，這自然也是為了模組作者。
只需要在Mod類的主入口中聲明一個『菜單類』，執行註冊，它便可以就這麼直接顯示在墓碑之上。
藉由此，模組作者只要想，甚至可以完全在不靠注入的情況下對整個UI體系都做出客制化修改。
也就是所謂的『資源包』、「數據包」功能。
林琅在主菜單加入了一個『合成』按鈕，只要點擊，就可以跳轉到一個特殊的場景。
將植物卡組合在一起，只要符合他設置的配方，便可以解鎖雜交版的植物。
當然這整個合成卡牌的場景也是完全程序化的，只不過是調用了內置的『卡槽』類，又調用UI工具生成了一個顯示所有持有卡牌的倉庫。
對於0基礎用戶，林琅則是在開發工具中設置了一個可視化的UI設計工具，拖拽組件到對應位置即可。
一整套下來，一個全新的玩法便誕生了。
接下來便是運行工具包中的『編譯打包』工具，調用他準備好的程序集將一切都編譯成模組文件。
「來來來，又整新活了，來玩玩看。」