The need to have a gameobject to start a script .. :/

Unity Engine
1

Hello,

I know, this is an old one, and that it is how Unity works … But I’m starting to hit a big wall in regard of framework optimisation because of this restriction.

For example :

  • In case of Additive level loading, I am forced to run a script in each level that scans for duplicated system objects and cleans any unnecessary clone (like the “core” gameobject which hosts the MVC controller). It also forces me to graduate my system functions deployment, so that there is no conflict due to these duplications. Huge pain in the ass …

  • In case of system protection (routines that scans if everything is ok database wise), it forces me to write a flag on a DontDestroyOnLoad object at Application Start which tells that I don’t need to run that test at each new level. Kind of overkill …

  • In some way, it forces to use Additive Level Loading, so that you need to load an empty scene at start, with DontDestroyOnLoad persistant system objects that would deploy all the game views. This is the most annoying part to be honest, as it forces any game testing to start from that empty scene. I can’t pick a scene, hit play, and tadam everything is ok. I have to play that empty system scene each time, and create an interface to load any random scene. Overkill once again … :confused:

  • It also force to expose those system objects. Even with creating a non MonoBehaviour class inside these, they’re still instanciated in a public gameObject, or we have to use static functions, which is not that optimal either.

If there was a way to launch a script without it needing to be attached to a gameobject, we could save a lot of clunky coding workflows for sure.

With Unity being used by big AAA studios, I don’t understand why any of them had complained about that yet ?
Flash forced me to use the same empty system scene logic back when I coded games for a very security sensitive business (national lottery). And it felt very awkward, unnatural, and unappropriate for any “serious” framework.

Long story short, is there any alternate way to load a persistent script without attaching to a gameobject ? Or any plan from Unity to create such capability ?

edit : Plus I guess it wouldn’t be hard to implement at all, like the matter of an hour : just insert a unique, invisible, static and persistent MonoBehaviour at the start of any Application, that could be overriden by the coder.

1 Like
2

I dunno if its relevant or not to your uses or methods, but static methods can be invoked without being attached through any gameObjects with ease. Creating a new instance of an object through this method might help …

sorry, im not to sure honestly.

PS : Just looking through your site , nice stuff m8.

3

Yep that’s what I’m doing actually, but I still need to create a GameObject in each scene that “triggers” those static deployments.

4

yes the bad thing is the fact that every script that is a monobehavior needs to be atached to a game object in order to run but it doesn’t has to be set up in the scene, you could make a empty gameobject at runtime then add the script at runtime to that empty gameobject.

5

ahh right , i see what you mean.

6

But you still need a script attached to an already existing gameObject to instantiate that script you’re talking about … :confused:

aka : whatever solution is found, there is always the need to have a preloaded gameobject in any scene.

7

I guess thats the magic there … thats Unitys big trick… the gameObject. Haha.

8

more like burdenObject :stuck_out_tongue:

9

keep in mind you could try creating the script as a class and maybe call the update on it or something? it seems that you are having problems having a script on a gameobject. it really doesn’t do anything bad being like that it’s just a empty game object. maybe try re coding your system to be more manegable?

10

The problem is not to have an empty gameobject, it is the whole way of structuring that is forced to us. As I wrote extensively in the OP, the whole need to have an empty scene for management is kind of clunky (as much as the Update solution, which is the same as the first example in the OP). There’s no need to recode my system actually, as it works, but I was just asking if there was any plan for proposing an alternate way of loading scripts, which would remove that way of script management.

11

The reason why big company havent complain about it. Is that it SOO simpel and so good to use.

I think it’s your though wise to each coding problem that is the main problem.

I think you need (if not already) learn to use OOP language.
Because it look to me that way. You overthinking it all and still in the old days wise of programming.

Think class and reuseable object!

12

Please, people, if you have anything useful to propose other than “you’re doing it wrong”, I’ll kindly ask you not to post.
I’ll repeat : I know how to handle that way of coding, thank you (and I know OOP thank you too, lol). I was just asking for an alternate way.

Reusability is precisely why I’m hitting a wall : you have to recreate an object at each scene for it be reused (or create it outside of that scene), which is kind of contrary to the base definition of reusability and puts unnecessary additional work to make it persistent.

Exposing a way to systematically load an overrideable Unity script at Application start without the need to depend on any gameObject would solve that problem.

1 Like
13

Visual C#, whit a Graphic engine… good alternative!

14

Can we stay professional, and on-topic please.

15

None of the replies you have received are helpful and I can understand your frustration. I think part of the problem is your first post doesn’t have a clear question in there, it’s a wall of text and it pretty difficult for the reader to determine exactly what you’re asking. The more specific context you give the question the less likely people are to help. If you take the time to make you question generic, short, and concise it will be easier for people to reply.

I interpret your question as this:
“How can I make singleton objects which work for both ‘play in editor’ and proper builds?”

This is how I make singleton classes for my project:

	bool isInitialized = false;
    private static MySingleton sInstance;
    public static MySingleton instance()
    {
        if (sInstance == null)
		{
			//NOTE: game object name in heirachy *MUST* be "MySingleton"
			var go = GameObject.Find("MySingleton");			
	        if (!go)
			{
				var prefab = (GameObject)Resources.Load("Singletons/MySingleton");
				go = (GameObject)GameObject.Instantiate(prefab);
				go.name = "MySingleton";
			}
			
			sInstance = go.GetComponent<MySingleton>();
			if (!sInstance.isInitialized)
			{
				sInstance.init();
			}
		}
		return sInstance;
    }
	
	void init()
	{
		DontDestroyOnLoad(this);
		isInitialized = true;
	}

I store all of my singleton classes in Resources/Singletons

16

Thank you for your suggestion Petroz. I thought repeating the problem X times would be clear enough :

Mainly, the title which resumes the problem :

then examples,

then a short version :

then 2 lines later, another resume :

then, 4 posts later, yet another resume :

then yet yet another, far more descriptive resume :

and then a final one :

Seriously, I’ve wrote the same explanation 6 times lol :stuck_out_tongue:
I think the problem is not the lack of concise question, but more that people are just not interested.

So I’ll write it a 7th time, maybe it’ll deliver this time :

The problem I’m trying to expose is not about bypassing the need to attach a script to a gameobject, because in the end, you will always need to trigger any non MonoBehaviour class from a MonoBehaviour script. Singletons, Static classes, etc are not solutions, they are just bypasses. But in the end, the bypasses don’t change the need to start everything from a gameObject.

Also, about wall of texts, I thought there were still some professional coders here, who are used to read walls of texts on other forums (gamedev.net, blogs, enterprise documents, etc). And even if the first post still had blurry zones, there were several posts under it which would go straighter to the point.

So if spending 40 seconds to read a 31 lines long paragraph is too much to ask, then I should simply stop searching for help here.
(not against you Petroz, and thank you for your time, really)

This is another debate, but I come to see that people’s attention span on forums are shorter and shorter as years go by. Which is dumb considering the very original nature of discussion forums.

Anyway … Thank you all, I’ve already started a workaround.

1 Like
17

In reality it takes at least few minutes to read and digest it. If 10 people take 3 minutes each to read it that is 30 minutes spent that is not actually helping you. If you took 5 or 10 minutes to re-read it and reduce it to the minimum text to clearly convey your point then you have saved everyone else time. There are heaps of posts on these forums and when your is among 100 unread posts if each took a few minutes to read each one then this would become a full time job :slight_smile:

I still don’t exactly understand why it is a problem that all code is started from a GameObject. If you need global init code to run before anything else then the singleton design pattern allows for initialization on first use which is just as good.

I am glad you have found a solution to your problem, I still don’t completely grasp what the problem is.

18

Sheesh … I’ve explained why with concrete examples :confused:
(I’m already using Singletons, on a sidenote)

ok, super ultra concrete precise no-need-to-think example :

  1. you have a MVC framework, with mvc persistent classes which are monitoring everything in your whole game.
  2. these classes have to create persistent other classes at application start, and these classes should never be destroyed because of gathered info during the whole game. They are complex, so they cannot rely on PlayerPrefs.

So here, you have either to :
a) insert this MVC into a DontDestroyOnLoad gameObject in an empty scene at start, which will AdditiveLoad every level.
Problem : you can’t test any level on the fly. You’ll always have to load that first empty scene and deploy the whole game scenario until you reach that level (or create a dev interface to that level, but with complex games, you can understand the burden).

b) or insert the MVC gameobject into every level. Problem : you couldn’t be able to AdditiveLevelLoad because of MVC duplications (and therefore conflicts. Or you have to create a cleanup routine, but good luck with it as MVC is supposed to be the first thing loaded)

c) The script you posted is another way to go, but it still requires to be called from an existing gameObject (here, let’s say a “system” gameObject put in every level), which leads to the same problem as in b). If you want to AdditiveLoad every level in your game, you’d end up having to clean each new “system” gameobject on load.

So of course the problem is not impossible to bypass, and there are always solutions. But I can’t see the elegance in them, as they all require some unnecessary clunky bypasses.
Meanwhile, if Unity provided creating a simple unique, overrideable, invisible, systematic MonoBehaviour on Application start, which we could fill with these kinds of persistent stuff, we wouldn’t need all those things we’re talking about.

In one word : why making it so complicated when it could be so simple ?

19

So my first answer was to have a singleton which is attached to a prefab inside resources. You can load that prefab by path; which means you do not need any empty scene. It also means that no matter which scene you load if it’s “play in editor” or just a normal build, it will always be there and will always be initialized first.

20

But you need a gameobject to load this prefab … :wink:
(= the whole “system” scenario in my previous post)