dimanche 9 juillet 2017

Best design practices: lookup table or class field

I am designing a little video game in c# and unity. I have objects that do not inherit from monobehavior and store the data (attack boost, hp boost, etc.) of an item (a sword, a potion, etc.)

However, I also need to create a unity gameobject with a physical representation of the item (they can be dropped and picked up).

I will be using the Resources folder; however, I am wondering what is the better way of designing the system...

Should I be making a public static string property within each item, using which I will know where to find the related prefab and then (through a third class when I want to create an item that shows up physically in Unity) use a database class whose job would be to take in the string, search through a dictionary, and return me a prefab for which I will be able to instantiate later on. (This will be processed at runtime for each prefab I look up.)

Or should I make a gameObject within my item and look for whats in the resources folder during construction of my item. Then through the third class, I would not need to use a database or anything like that and just instantiate the gameObject directly.

------- (Third) Class that wants to Instantiate something ------

public static GameObject InstantiateDroppedItem(Item item, Vector3 location) 
{
    GameObject toInstantiate = ItemDatabase.LookUp(item.ResourcesLocation);  // ItemDatabase = static class, ResourcesLocation is string property
    return Instantiate(toInstantiate, location);
}
// Have to make a ItemDatabase static class beginning with an empty dictionary that takes in string and outputs an item prefab. The process for looking up an item via the location string will be: 

1. Check if item prefab already in database, if yes, get it and be done. If not in database, look it up, then store it into the database.

OR

public static GameObject InstantiateDroppedItem(Item item, Vector3 location) 
{
    return Instantiate(item.ItemPrefab, location); // ItemPrefab is GameObject property
}
// Have to make complicated Item constructor that searches the Resources folder for the prefab used to initialize ItemPrefab gameObject property.

Neither options seem good.

--- The ItemDatabase dictionary is an issue in how I have to implement a lot of stuff. And as coding goes on, I will have a SpriteDatabase (for the items when they are displayed in the UI), etc. So if I decide to go all the way with making a ton of databases, I can just get rid of programming in an object oriented fashion and make an item contain just an id and everything else needs to be looked up. This makes updating/creating an item very difficult as you need to modify every single database. Seems very complex and will take a toll on debugging and future development. --- Setting the gameObject property item constructor I think violates the idea that a class should do just one thing. (Somehow this one is also interacting a database.) And also that it is now dependent on 'using UnityEngine'. Seems like inter-dependencies are growing.

I know a lot of ways that can get the job done, but every time I code something, I end up looking at it and constantly wonder if I should be implementing it differently. Thanks so much for reading this and also any answers are much appreciated.

Lastly, if you have any resources you think would help me with my issues, please tell me (there are many many similar things... I guess I don't have a general sense for what's best.)

Aucun commentaire:

Enregistrer un commentaire