I'm not sure if there is an issue with having lots of small prefabs like this, I mean they are like 6kb each, so very small, have no mesh, colliders or components like that. These would probably go in your Resources folder. So if you had 10 spells you would have 100 prefabs in various folders that control the settings for each spell and related effects. It makes it really easy to create your spells very quickly, the only problem is that one spell might involve say 10 prefabs in total, but they are using a common set of script components. Then you create a number of extra prefabs for that spell for any particular effects that the spell does, like it might do damage or something, and you attach the appropriate effect script to that.
Currently I have it setup so that you create an ability, you create a prefab for the Ability and attach an Ability script to it, allowing you to setup all of the values. Yeah I'm still debating over which way to go. If/when that starts to get unwieldy, you can look at investing the time and effort into implementing an external store, loader scripts, and authoring tools to work with your external data format if needed (since you'll then need some way to create those external data stores). That's certainly fine for a prototype or if you only have a limited number of such things to assemble. Again, for simpler cases, the simplest approach is probably best create a script, drag it onto a game object, drop in the assets (sounds, particle systems, etc) and configure the value attributes through the inspector. You could create a game object or prefab for each that has all of that set, or you could externalize it in a database, XML/CSV/TXT file or whatever else you wanted.
Again, though, it depends on much the same things - how much of it there is, what you need to store (for example, for spells, you would probably have sound effects, gfx / particle systems, and other assets as well as the value data like type and amount of damage, range, etc. Sorry, didn't realize you were talking about static / design-time data.
0 kommentar(er)
