hey people-
starting to get results with unity scripting but would like to hear others approaches for larger projects.
It seems that for a script to run it needs to be attached to a GameObject, but is there a way to have a scene attach script?
Something that will be the ‘game manager’ and can overlook all the global variables, destroy/create objects when needed and even serialize scene data for cross-scene events?
How are you guys approaching these larger script requirements that aren’t tied to a single GameObject?
You can attach scripts to empty gameobjects, so For example if you have a gamemanager class, just place the script onto an empty gameobject in your scene.
In our projects, we have a few of these empty objects in the scene, just running scripts.
ok cool, thanks for the reply - I had thought about that earlier but it seemed too hacky to do without asking here first
And what if a scene isn’t loaded? Such as startup front end, where do you ‘attach’ this script that deals with the menu GUI, or loading a saved user profile - these aren’t related to any Scene, but are ‘GameManager’ scripts. Wouldn’t there be some initial script that gets fired?
When you create a build, you have to include scenes. It will load a default scene, which is where you would place your gamecontroller script object.
We use the awake function of the gamecontroller script, to trigger of initialization of our other scripts. That way we have control of the order things happen in (a problem we had for a little while there).
We work from a rule of internal initialization in Awake, and gathering information from other objects in Start. That eliminates most of out ordering issues for initialization.
ok I’ll look into that.
I’ve only been using Unity for a day, a group of us are trying to put it through the ropes before considering licensing.
I’m used to getting the whole game done in c++ , game objects still have code associated with them, but you still ‘orchestrate’ the game through a gamemanager.
What about a situation like this… you have a Goal and a Ball gameobject… when a goal is scored (rigidbody contact with Ball) I want a ReSpawn() event to happen in a master script… this will be a complex event: effects, audio, stats adjustments, player position restarts, physics restarts, camera animation… etc etc - point being it’s a scripted event big enough to not be tied to one gameObject. If a ‘goal’ is determined by a bool set in the Goal object, then how does a script not explicitly attached to the Goal object know about this? …or conversely, how would the Goal object fire off a method in a script not attached to itself?
…I’m sure its just a “re-thinking” for Unity before I get with the flow of it, being so used to the other tech I use. How are other people dealing with complex game scenarios?
You could attach the master controller to the goal, that’s very easy to do.
Two, you could broadcast the event to several objects which take care of various parts, e.g. a script to keep the score, the ball gameobject so it respawns itself, etc.
Three, you can simply use a static function if you don’t mind globals. I usually have a “Preferences” script static.
thanks for the tips Tom - so far I’m doing the hack of having a dummy GameObject that hosts all the code that will run the events in the level.
Now, what about having persistent data across scene loads?
When a game starts, (no scene is loaded yet), the player may want to chose a wide range of game settings. So, how can I pass these settings (a struct would do here) to an object that hasn’t loaded yet in a scene that also isn’t loaded?
Murcho, are you saying a front end menu would actually be a scene with a single GameObject in it that controls any UI?
So far, I’m under the impression an entire projects source code is dropped onto GameObjects that have a Transform in 3D belonging to a particular scene. Is that not backwards to most of you?! (unless I’ve missed something!) Having to create a scene, then a 3D object within the scene without a render element so that you can attach a new class to work with back in your code!
It’s actually a pretty OO solution. Instead of having a bunch of different “types” of things you can put into your scene, you have an eminently extensible GameObject container which can hold any of the built-in components (including rendering) as well as anything you write yourself without forcing a separate API on programmers. It’s essentially what separates a game builder from a game engine. If the overhead is that a GameObject contains a Transform (and whatever under-the-hood stuff calls Update() on every component, etc), I’m willing to pay that price to separate rendering, physics, collision detection, and scripted behavior from a GameObject’s inherent GameObjectyness. Now, if only the GUI system operated on the composite pattern .
.