Instantiating world grid problem

Unity Engine
1

Hey guys,
I have a turn based strategy game, in which the map is a grid, and the cubes are instantiated using this:

	for (int z = 0; z < 50; z++) {
			for (int x = 0; x < 50; x++) {

				Instantiate(Brick, new Vector3(x, 0, z), Quaternion.identity);
				Brick.name = "Brick" + name;
				name += 1;
			}
		}

Pretty straight forward. But I was wondering, when I want to start adding to the map, should I do it all in code, or should I copy and paste the map from the game once it has instantiated, and add it to the scene so that I can stop instantiating it, and have the ability to freely edit it?

I tried this, and it worked, but made the game unplayable, due to lag. I mean, there are 2500 blocks, but I can’t imagine why it didn’t lag before hand.

Any suggestions as to what I can do, or should do, to take my map generation a bit further?

Thanks,
Danny

2

I may not completely understand what you are asking… so sorry if i sound stupid, but - If the map is static, just get it to how you want within the scene?

Or make the Map generation run on start up (before people can play, then simply stop the for loop running anymore)

3

Well, the map has 2500 cubes, so it would takes forever to make sure they were all lined up correctly.

And to instantiate them and use that seems like the best option to me, but its being a pain to implement and I don’t understand why…

4

What parts are being a pain?

5

Performance. When I was instantiating them, it ran fine - but for some reason, doing it this way has dropped the fps to around 2.

6

Just a heads up, having 2500 of any game object instantiated at once is probably going to produce some performance issues, especially if they have colliders and/or rigidbodies and/or renderers that any camera can see. That said, if the slowdown issue is only during instantiation, just spread the instantiation out over several frames by using a Coroutine: Unity - Manual: Coroutines

edit: Also note that the scene view in the inspector counts as a kind of rendering, and thus incurs a performance hit if the scene and game tabs are displayed simultaneously in the editor.

7

Sorry, i have probably explained badly. The instantiation takes a while, but after that performance is fine. My problem is when I use the grid that isn’t instantiated, because then performance takes the huge dip.

Is there something about instantiated gameobjects that makes them easier to render or something?

8

I’m not sure you’re properly using these words. Any gameobject which exists in the scene has been “instantiated” once, and is thus an “instance” - but you don’t normally call it “instantiating” if you’re doing it at design time.

Whether you do this at design time in the editor, or at runtime via code as in your first post, the result is the same, except that the loop during startup incurs a performance hit. The fact that this only happens once at startup means you can hide the resulting performance hiccup behind a load screen if desired.

9

Check what the cubes have attached to them (scripts, rigibodies etc) in both situations, ensure they all have as little as is possible.

Make sure you also are not running Instantiate if you have added the cubes to the scene yourself… Like AlwaysSunny has said, once the objects are there, performance should be the same (if what i stated above is true).

10

Oh apologies, I thought it was only instantiating if it was through code.

Yeah I made sure of that, don’t worry. My mind is just a bit blown that this is happening, it doesn’t seem logical to me at all. This is what is on each cube:

	void Update () {
		GameObject camera = GameObject.Find ("Main Camera");
		moveUnit moveUnit = camera.GetComponent<moveUnit>();

	if(this.gameObject == moveUnit.nextMove) {
			ifActive = true;
		}

		if(this.gameObject != moveUnit.nextMove) {
			ifActive=false;
		}

	if(ifActive==true) {
			this.renderer.material = active;
		
		}

	else {
			this.renderer.material = normal;
		}

	}

And:

	void Update () {
		 
		moveUnit moveUnit = maincam.GetComponent<moveUnit>();

		if(Vector3.Distance(this.transform.position, moveUnit.activeChar.transform.position) < moveRange) {
		 
			inRange = true;
		}
		else {
			inRange = false;

		}
		if(inRange==true) {
			this.renderer.material = Matpossibles;
		}


	}

Am I missing anything?

11

You should avoid using GameObject.Find() wherever possible - at the very least, put that in Start() and keep a reference instead of getting it every Update tick. Likewise, avoid per-frame calls to GetComponent wherever possible. To squeeze even more performance from your scripts, avoid calls to the built-in convenience functions like something.transform and something.renderer, likewise by creating references to them in Start()

2500 calls to GameObject.Find() and GetComponent<>() is a recipe for bad juju. So is 2500 of any gameobject, for that matter. I’d look at alternative ways to achieve the same result.

Best,

12

Instead of having all 2500 check every Update whether they are equal to moveUnit’s next move, maybe you could put make two public functions:

public void ActivateSquare() {
this.renderer.material = active;
}
public void DeactiveSquare() {
this.renderer.material = normal;
}

Then in the moveUnit’s code where it sets the value of nextMove, call Activate for the new Move and call Deactivate on the old square.

I think if I’m understanding correctly, only one of those 2500 is going to be active at a time? So it doesn’t make sense to test all 2500 every Update.

13

Alright, I have no clue where to start with a different method for this though. You got any ideas?
Yeah, I’ll have a go with optimizing all the code, see if that improves it, thanks both of you for the suggestions!