implement a chest class with different fields

Unity Engine
1

Hi all.
I have a chest class with different fields (rubyVal,diamondVal,coinVal,etc).
Chests have different items (some of them have only coins, only diamonds, only rubies or combinational items)
I can implement with one class like below:

public Class Chest{
int diamondVal;
int coinVal;
int rubyVal;
}

and if they are zeros so the chest doesn’t have the items but it is not good
or can implement with one arrayValue (0,1,2) diamondVal,coinVal,rubyVal
and I can implement with several classes
which implementation is the best?
Can I use template design pattern?

2

I would implement an item class. Like so.

public Class Chest{
    List<Item> items;
}

public class Item {
    string name;
    int amount;
    ...
}
3

@Kiwasi - If I may ask a related question (hopefully it’s OK for OP);

How would you go about making Chest with items that are not same class and also be able to serialize / deserialize these in Unity Inspector properly, while not using ScriptableObject items?

… So far I’ve been thinking about using different lists for different item types (clothes list, tools list), and hide them (or make better looking) somehow using Custom Inspector.

I’m thinking about items that are that much different that they wouldn’t have same fields and so on.

Currently I’m using the setup you described.

4

Yes, Thanks.
and if items have different functionality, I can use abstract class or interfaces

5

but one problem…
I need to implement like below

for(){
if(items[i].name=="diamond"){
//do something
}
else if(items[i].name=="coin"){
//do something
}
...
}

but it can be implemented

public interface IItem{
void GetReward();
}
public class DiamondItem:IItem
{
int amount;
public void GetReward(){
//something
}
}
public class Chest{
List<IItem> items;
public Chest(){
}
public void GetReward(){
for(){
items[i].GetReward();
}
}
}
6

@mahdiii

Just asking - if you are going to have a list of items using system of your example;

How would this work any better in the end, compared to @Kiwasi 's example?

His super simple example seems to be only thing that Unity swallows easily…

For example - if you create an item list using your IItem idea - Let’s say one item is DiamondItem, and maybe another item, of class CoinItem, implementing IItem too… how do you handle inspector serialization?

Maybe with a bit of custom inspector I could show the class specific fields based on it’s class in List, but would it serialize (by Unity Inspector) any better than having Cats and Dogs in Animal List?

My issues is, after Play/Stop you’ll end up with animals, losing the specific Cat and Dog instances which you could be able to cram into list using some editor.

EDIT: and I’ve used interfaces really little, but I’ve gotten the impression that they don’t serialize in Inspector. You’d have to make Custom Editor or Custom Inspector / PropertyDrawer, even then wouldn’t you run into this serialization issue… unless you circumvent this manually without Unity system.

1 Like
7

Note that with the latter example, you might end up coupling a lot of logic to the items itself.
You may either want to return the items to process them somewhere else, or return some kind of set that contains all rewards which can then be processed any further.

Well, that’s a situation in which it appears to be a good idea to start using scriptable objects as data containers.
Indeed, interfaces do not serialize by default in the inspector.

However, to be honest, once you enter the world of highly flexible level and game design and balancing aspects, you’d probably choose to handle these fine-grained data way much differently anyway.

But that always depends on the scale of the project, of course.

8

The best option is ScriptableObjects. You can create many different serializable types of Item, configure all the data in edit mode, store them all in one generic list of Items, and all the specific data will be retained if you cast to the specific type at runtime.

9

Thanks but my question was not serialization problem.
My question was oop design pattern that it is better to be implemented with interface rather than below action:

for(){
if(items[i].name=="diamond"){
//do something
}
else if(items[i].name=="coin"){
//do something
}
...
}
10

It’s definitely better to implement an interface or create virtual functions to fulfill your needs per-item than to create ever-expanding branches. Keep the logic modular. Also avoid using raw strings for anything, they’re subject to change and typos.

11

You wouldn’t. Not with the setup I described. Unity doesn’t support polymorphism in the inspector.

If the items needed to be seperate classes, you could use scriptable objects, gameobjects, or you could load them dynamically at runtime.

1 Like