iT邦幫忙

2021 iThome 鐵人賽

DAY 12
0
Mobile Development

FPS dungeon crawler game devlog系列 第 12

Dungeon Mizarka 012

今天一樣是要利用Editor Script進行少部份量化的工作,已經了解了怎麼樣用Editor Script產生ItemDefinition,接下來就要將道具加到ItemCollection,也就是Inventory元件裡最主要的資料。

初步的試驗是Inventory和ItemCollection多數行為都不是開放的,如果直接利用

var itemCollection = new ItemCollection();
var inventory = go.AddComponent<Inventory>();
inventory.AddItemCollection(itemCollection);

有很多問題會產生,首先就是inventory內部的item collection list沒有初始化,引用Add時就會出錯,而ItemCollection就算是產生了,也無法調整其Purpose。整體來看,沒有辦法利用全數從零產生的方式進行。只能試著利用很迂迴的方式,先產生Prefab,引用後再調整。

愈往下愈感受到不調整(修改UIS)程式碼,很難往下進行。開發者遵循著良好的Coding Guideline進行撰寫,對於從程式碼端著手了解其用法本來是很讚賞的,但問題是良好的Coding Guideline在沒有開放足夠的API下,很難讓其它開發者進行量化處理。

比方說MonoBehaviour裡面可以開放出來在Inspector調整的值,都是用Serialable加上protected(private),這點似乎是很好的Coding Guideline,但是仔細想想這不是很奇怪地一件事。在Code中用了non public,主要就不希望開放這個值出來讓其它人引用到,可是Serialable,就可以在Inspector進行調整。這裡最弔詭的地方在於,防止這個值被其它Code引用,卻又可以開放出來讓可以操控Inspector的人進行調整。那這裡的意義何在?只是做了一個機制可以被UI調整,不能被Code調整?難不成用Inspector調值的人比寫程式調值的人更加專業、更加可以信賴?

實際上這些會用Serialable加上protected(private)的開發者,應該很少進行量化批次作業。正常開發的週期,只有前幾個GameObject會手動在Inspector裡進行調整。等到確定行為、流程後,多數都是要進行讀表格產生的動作,也就是要利用Editor Script進行產生的動作。若是行為的設定只被弄成操作Inspector的UI才能進行,那真的是讓整個批次作業的難度大幅上升。

就拿UIS裡ItemObjectSlot這個型別為例子

[Tooltip("The transform that will be the parent of the spawned item object.")]
[SerializeField] protected Transform m_Transform;

不過就是一個定位置用的值,弄成SerializeField protected看起來很遵守軟體工程學的Coding Guideline,麻煩的是又沒有開放Set API,根本就是為難用外掛的開發者。

還再試著要怎麼樣調整,也在Discord裡給予開發者反饋,但時差的關係,等到開發者看到,可能也是好一陣子之後的事了,看樣子今天要試出這個部份可能性不大。或許再多花些時間了解eye of beholder系列作和其它的FPDC,發想設計,又或是思考怪物單體部份要怎麼進行設計。

怪物設計

怪物也會有裝備的概念,不論是否為人形怪,都可以進行裝備。這樣的裝備只是為了要讓怪物的基本數質可以有差異化,畢竟怪物的等級數值設定並不是一時三刻可以完成的,可能在這個月當中都不會有太多的著墨,趁著道具系統進入,利用裝備可進行小幅度的能力調整也是不錯的。

如果沒有更好的想法,現階段就會直接採用這樣的方案。若是怪物身上有裝備,就會有額外的圖像資訊顯示。讓玩家可以直接看到有裝備的怪物和沒有裝備的怪物的差異性,如圖中顯示的(用Unity Cube做大小定位)

實際上,也和多數遊戲的Buff, Debuff呈現概念相當,看起來並不會太突兀。

追加二隻後排在一起看比例。

由於怪物是直接拿取免費的圖樣,大小沒有辧法做統一,只能夠依照拿到的美術資料進行調整。直接利用pixel per unit的方式進行尺寸調整。這三隻怪,青蛙、食人花和石巨人,比例上青蛙約為0.5公尺,食人花為1.5公尺再高一些,而石巨人則超過2公尺的高度。之後若是有其它的怪物進來,也比照此方式進行比例調整。

怪物或許會如同玩家一般,可以選擇其行動。為了要展現其行動的時間點,故用同樣的行動條進行呈現,讓玩家可以了解怪物正要展開行動,並決定如何應對。然是否有此顯示需求,還要再進行評估。

怪物的實際呈現和其相關資訊就暫定成這樣,接下來就要進行實際的製作,可能又要花上不少時間了。


上一篇
Dungeon Mizarka 011
下一篇
Dungeon Mizarka 013
系列文
FPS dungeon crawler game devlog30

尚未有邦友留言

立即登入留言