koobas.hobune.stream
Separating Gameobjects from scripts
Hey guys I worked in a company and we are experimenting with new ways to improve our current workflow.
So far we have always used prefabs as a collection of art assets and the individual scripts it needs, all balled together in a composite game object.
Now this has always worked great so far in a small team, but we figured if we were to proceed further down the road we will eventually need to separate scripts (logics) from the art assets, in other words, game objects will not contain scripts, only art assets.
Now the problem is logics still need to have a way to refer to the art assets, and one way is to use Gameobject.Find during runtime, but is there a better way to do this considering that art assets may not be immediately available in the scene during runtime and some may be loaded into the project dynamically?
Another problem is the overhead of using AddComponent during runtime, especially on the mobile platform, because it is essentially calling a smaller version of Instantiate, which is expensive, one way we thought of to prevent this overhead is to have a controller script in the scene acting on the art asset instead of adding component, but as usual, is there a better way of doing this?
Was hoping somebody who has been through these things can share with us some of their lessons and some of the current workflow they are adopting.
You can preload assets with Resources.Load() (hiding it behind a loading screen) before Instantiation making it less intense at runtime. If thats not good enough, you can Instantiate disabled GameObjects behind a loading screen and only enable them as needed. Disabled objects only consume RA$$anonymous$$ not CPU, they wont even call Awake if disabled at Instantiation. If you are worried about multiple GameObjects all at once/frequently you can use a GameObject Pool to avoid Instantiate/Destroy calls.
Some Pool Linkage: https://vonlehecreative.wordpress.com/2010/01/06/unity-resource-gameobjectpool/
Since Art assets and Scripts are just as likely to change after release, but their associations are very unlikely to change... I see no reason to worry about your current implementation. Any asset can be dynamically loaded so there is no reason to worry about how you put them together before you use them.
Thanks for the replies guys, but we were actually thinking about AssetBundle, they can't contain scripts can they? Also, we want to know how to replace UI without changing code. As you all would have know, attaching scripts component to UI and changing it again will ask that the UI be reattached with appropriate scripts again, is there a better way of doing this? For example, in web development, CSS can be changed without changing the website and one click u get to reskin a website, this is just an example to illustrate my point.
Well, if you really want to seperate the logic from the art / models it should be done the other way round. A game consists mainly of logic. Art and models aren't needed. They are just "visual sugar". So build your objects and prefabs with just empty gameobjects and scripts. The models can be referenced by the scripts and instantiated either at runtime or inside the editor with some help of editor scripts.
If you have quite complicated object structures you might consider creating some sort of prefab factory which should create your final prefabs in the editor. A few simple Editor scripts can be quite powerful.
That's what Unity already does. The $$anonymous$$eshRenderer component tells the engine what mesh, materials and textures to load at runtime, the SpriteRenderer what Sprite, and so on.
Anyway, art assets are not just "visual sugar", you have to consider the art. If your hero has a "roll" move you usually want to know when the model is smaller to shrink the collider. If he has an attack animation you might need to know when it's finishes so the player can't hit again during the animation. If your hero jumps you probably want to switch to a falling animation when he reaches max height and starts descending. Well, all the animations state for that matter exists because there's art involved and the game flow depends on it.
I'm really exceptical of anyone being able to make a game using placeholders that works as intended without worring about the art assets.
"Now this has always worked great so far in a small team, but we figured if we were to proceed further down the road we will eventually need to separate scripts (logics) from the art assets, in other words, game objects will not contain scripts, only art assets."
It sounds you're going against the engine philosophy. A GameObject should be a collection of Components, and Components add behaviour (behaviour as something more general than a MonoBehaviour script). I can't see why you want a GameObject to only have art assets and not logic. What will you do with, for example, a Collider? Or a RigidBody? Do you consider them art assets? You usually setup the collider in relation to the 2D or 3D model used by that GameObject. Will you use the Transform itself? It's just logic. You're imposing a really arbitrary rule there that will make things a lot more complicated than they should. Can't imagine what will you do if you try to make a multiplayer (networking, not local) game.
