- Home /
Object Inheritance with Triggers
So I am creating an item system for my game, with an item class and then individual classes for the specific items. My sword item has a OnTriggerEnter function, in order to detect when it hits the enemy. However, this overrides the OnTriggerEnter function in the item class that detects when an item can be picked up. From what I've seen I am not able to call the base class OnTriggerEnter from the child class OnTriggerEnter. Is there any work around to this?
Answer by Bunny83 · Apr 18, 2020 at 06:04 PM
You have to be more thoughtful about your abstract concepts. Not everything is or should be an item. Even I don't do any mincraft modding I'd like to use it as a reference here. First of all what MC has in each slot of the inventory is not an item, but an itemstack. An itemstack is an item type combined with an amount. A dropped item in the world is not an item but an entity. The entity is a seperate wrapper class which represents the dropped item in the world. The visuals can actually look completely different from how the item is represented in the inventory or when you hold it in your hand. The entity object in the world actually just contains a reference to an itemstack in a variable. So every item-entity is essentially the same thing in the world. So what the entity represents simply depends on the "payload" / the itemstack referenced by the entity.
Likewise you should seperate the usage of an item from its abstract representation. So if you use an item as weapon you might be using a seperate generalized melee weapon class which does handle the actual fighting mechanics (just the same way how the entity handles the pickup mechanics). This class is not part of your item in your inventory or the item you drop on the floor. The weapon class might reference your weapon item in order to configure the weapon stats, decrement it's durability or something similar. So the actual interaction between the player and the world / other entities is done by seperate specialized classes.
Of course that's not how you "have to" design your game. Of course it's possible to directly let a single object represent itself in all cases. However in that case you would need to remember in which state the item is (stored in an inventory, equipped as tool / weapon, dropped on the floor as entity). With this state you can simply decide which code needs to execute depending on the state. However such a concept is not recommended because you put too much responsibility into a single class / object. So I would highly recommend to seperate your concepts. In MC when you place down an item block (not dropping) the item does not become part of the terrain. Instead if the block can be placed there the terrain is modified and at the same time the itemstack count is decreased. Of course if the count drops to 0 the itemstack is removed. Most of the things I've said about MC can be read here.
You generally want to think about how you actually want to represent your object in the various situations. Even games like Half-life has seperate models for dropped ingame weapons compared to equipped first person weapon models. So hopefully you get the idea. In Unity most people represent abstract items through scriptable objects, but you don't have to. The scriptable object could have two references to two seperate prefabs. One is used when you drop an item on the floor (so the world model prefab just gets added to a generic dropped item entity) and maybe a seperate first person model which you can actually equip as weapon.