How should I store certain game data?

Have you looked at "ScriptableObjects"? And also singleton patterns?

You could make an "Item$$anonymous$$anager" class that wraps your items, and implements a singleton pattern, which you would then access by Item$$anonymous$$anager.GetInstance() or something.

The question will probably be how you intend to build/store your list. If you are directly referencing the prefabs (via linking them in editor/etc) it might get tricky (if you are doing this, they don't need to be in the resources folder, fyi). If you are just storing names (ie, paths to the prefab as strings), it shouldn't be too difficult.

Im actually storing all the prefabs in the resources folder and then using Resources.Load("items/"+filepath); to load all the prefabs.

I did originally have an ItemHandler class that had an AddItem and such but I didnt know how to access that class from other places (I'll look into singleton patterns as it seems to be what I might have been doing without knowing it)

From experience with scripting in another engine, I just would populate an array either directly or using a function. I'm trying to get used to the whole all code must be in a class to be executed thing because I cant just have standalone code just sitting outside doing something. Or can I?

If I do make a Item$$anonymous$$anager or ItemHandler again, where would I create this object and how would I be able to reference it from other scripts?

Are you aware of static classes and functions (which is what the singleton pattern relies on)?

In c# you can't have code outside a class (as far as I'm aware) but you can build static classes that serve only as a place to put code ($$anonymous$$athf is the first one that springs to $$anonymous$$d). So for example, you could make ItemHandler a public static and access its functions like ItemHandler.AddItem(someItem);. This sort of use of statics is generally frowned upon though. The "why" I'm not so sure on, but I know that if at some point later you decide you need to have a second instance it requires a lot of refactoring. (I'm dreading the moment the client asks for multiplayer atm...). However, this approach would require nothing in the scene.

While you could make a ScriptableObject, and save an instance in your hierarchy, you will probably be better off making a GameObject to put it in. I think if you don't have a "hard link" in your scene, unless its in the Resources folder it will be "optimised" out of the bundle, but if it is in the Resources folder you'll have to have a class in the scene loading it anyway. While you could put that logic in a class using the item manager, if another class needs to use it you'll have repeat yourself.

An advantage you might not be aware of, is that if you use instances over statics, you can declare the class with the [Serialisable] tag, and then the contents will be visible in the inspector, which could save you a lot of time debugging. One gotcha I feel worth pointing out though is that nothing will ever be "null" if its serialisable (you can still use default(x) though). But a string you can see in the editor (for example) will never be null, only "". This can be particularly annoying when you have code that works fine then you turn on debug mode (which lets you see private serialisable fields) and everything breaks!

Also with serialisable classes, you can create all the data in the editor and not have to write logic to parse text files, which might be handy depending on your project.

Well, a class in the scene will be loading it already so that takes care of that.

I thought the singleton thing was actually making a class and then only making a single object from that class but making a static class seems like it would work better because I could access it from everywhere and I wouldnt really know how to make the other one (one object of a class) be accessible everywhere.

This is going to be a multiplayer game but I'm not sure how unity handles client and server sided? I assumed it was best to just start as it was single player and then split it to multiplayer later? Even so, there should only be one instance of this class and it'd be on the server as the client wouldn't really need it.

The serialisable feature seems nice but I think the gotcha and the ability to access the static class everywhere outweigh the benefits. I can just use usual debugging tactics if all else fails.

Thanks for all the help!

I meant more like... multiplayer would mean they'd want a second instance of the puzzle in a puzzle game, or a second inventory, or... etc. I haven't got around to worrying about the actual networking side of it! But since I used singletons over statics, it wouldn't actually be that bad.

Very simple example of a singleton implementation in c#:

 public class SomeSingleton {
     static instance = null;
     public static SomeSingleton Instance {
         return instance;
     }


     void Awake() {
         instance = this;
     }
 }

You would then access this anywhere like SomeSingleton.Instance.DoStuff(); (its a static property). The gotcha is only a problem if you don't know about it ><