koobas.hobune.stream
Creating a scene using script (which Start() to use)
I want to create all the objects in the scene through scripting. That would be 1 camera, 1 light and 2 stretched quads with textures. The question is where do I put my code?
Is there an application-level Start() function? Or even better, a Start() function related to my particular scene. There are no other objects where to put my code, since the scene is empty at start.
You must have at the very least, one empty object in the scene with a single script attached to get things going. You could have some static classes in your assets folder and access them through this "main" script. Say you just have an empty object named "Scripts", and a script named "Startup". Then you have a script named "Static1" in your assets folder with some values. Why is that a probelm btw?
You cannot execute code without having something existing in the scene. End of story. You could insert an empty game object with a single script to instantiate everything during Awake(), but unless you have something in the scene, nothing will be executed. There is nothing you can do about this.
Ok, thanks for the answer. I hope that part of Unity will improve as it would be really useful for the scene to have scripts.
Is it really so hard to have a single object in a single scene? I'm hoping they are concentrating on other features myself :)
You could always instantiate a new script, or call other functions from the code, that would remove the huge case statement with a lot of code in it - at most you'd have one line in each statement, and it would be much more readable. Having said that, it does make a certain amount of sense as to why the scene itself doesn't allow this - Unity is designed to work with the editor - you're supposed to build environments with it, and while you can instantiate everything from script, it's not designed for that purpose. The overhead of a single dummy object in the scene is absolutely $$anonymous$$uscule - in fact, it's just about equal to the size of the GameObject class, which will be a few hundred bytes at most. If you only need the code to run at the start of the scene, you can always destroy that object at the end of the Start() function, too, which will stop it from having any impact at all on your scene - especially since destroying a single GameObject with only one script attached is a very $$anonymous$$or operation.
As I said - you can destroy the GameObject immediately after the execution of the code, which removes it from the update loop. The benefits to having it on an object like this are in consistency, and the performance hit is barely larger than just executing the function on its own. You'd be surprised about how little scene initialisation is necessary, too, since games will actually often need to run things in the update loop without having a visible object there, too, so you might as well use that object for the initialisation. I think the problem you're having with this is that you consider a single GameObject to be a big overhead - it's really not. It's a few hundred extra bytes, for the duration of a single function, which are then discarded in 100ths of a second and never used again - it's simply not a huge overhead. You'd get a bigger overhead by setting up a regular expression, and many games use those left right and centre.
But the scene itself isn't an object in the same way that GameObjects are. That's the point.
Good reference, just keep in $$anonymous$$d you still need a script in your scene to access these System.Object scripts. I know you know that, just posting for others that may not. +1 :)
I always create an empty object in the scene called God, and attach a script called God.cs. I use that script to manage all the top-level game stuff.
