iT邦幫忙

2021 iThome 鐵人賽

DAY 13
0
Mobile Development

FPS dungeon crawler game devlog系列 第 13

Dungeon Mizarka 013

怪物實作

怪物是由多個子物件組合而成的,其階層看起來可能會是如下所示

利用子物件達成其功能的分類,目前的分類主要為四大類

  • AI
  • Inventory
  • Stats(Attribute)
  • Directional

其中的Directional是負責怪物面向的部份,而這個部份其實是很複雜的。

面向

提到面向,又回到前幾天的考量。由於是固定90度呈現,所以怪物應該是會有四個面向的呈現,合併怪物左邊和右邊看起來是一樣的,仍有三個面向的呈現,但在目前能利用的資源考量下,也就只能提供一個面向也就是正面的呈現。實際上光是呈現正面也有些不容易,多數能使用的資源其實是左、右面向(側邊)的,但也就將就的進行其呈現。

多數時間點怪物都是以面向玩家為主要呈現,隨著玩家的位置而調整自己的面向,且沒有任何需求要背對玩家,實際上,以Sprite為主的呈現,正反二面都會呈現,只是看起來像是左右顛倒,也沒有多大的差異。

而玩家的攻擊是直接按壓後生成從玩家到按壓點的射線,且這個射線仍是以怪物的本體或是額外配置物為基準點進行判定。所以多數的配置物都會放在怪物的前面,也就是在玩家和怪物本體之間。也就因為這個考量點,除了Sprite的呈現有其面向,其它配置物也會有,故需要額外再開設一層子物件進行,也就是這裡的Direction Base。

也就是有這些考量和資源利用的限制,可能要配合Direction Base的旋轉進行側邊的顯示。

思量後決定先用側面45度角的方式呈現的側面,日後再搭配背後呈現的機制(可能會用Shader處理,也可能直接加工美術圖像)。

再度回到Inventory的製作

後來UIS開發者有回覆

My guess is that you are having issues adding items at edit time because we serialize them using a custom serializer. So you must serialize and save the component each time you make a change.

Another approach you could take is having another component which adds items to an inventory on start by reading a text file.

和我想的差不多,也就是利用額外的一份資料,不論是ScriptablObject也好,Text檔案也好,又或是另一個專門放資料的元件。利用Variables元件,則會看起來像是這樣

用這個方式做直接的問題是在於,如果額外準備了一份資料,除了Equipped(裝備)有需要進入到UIS裡讓裝備放置在場景中合理的位置,Backpack和Drops的意義變得稍稍薄弱。

這裡的Backpack是怪物的背包,在Variables裡已放入了一放資料,其實在Runtime也可以直接使用了,不用透過UIS的Inventory進行。畢竟在UIS裡,對於這部份的處理也就是拿出道具後生成ItemObject gameobject,再執行引用。更不用說Drops,概念也是差不多,只是這個ItemObject有額外的Pickup元件。

說實在的這和已經有一份資料(放在Variables),能做的事幾近相同。但為了要配合UIS目前的序列化機制,只能用這個方式進行,不是很優的解決方案,但暫時只能這樣了。

接下來要開始進行怪物和道具之間的整合,也要開始實際在Runtime時利用UIS提供的機制給予相對應的行為了。


上一篇
Dungeon Mizarka 012
下一篇
Dungeon Mizarka 014
系列文
FPS dungeon crawler game devlog30

尚未有邦友留言

立即登入留言