Max_instances is effectively capped at 1025 (DEF-3780)

Feature requests
#1

I am working on something similar to a tile map that requires flexibility that tile maps do not seem to work for. Right now, I have an array of terrain data that terrain game objects are dynamically loaded from around the player and then discarded when they are out of the player (well, camera)'s range. As I increased the amount of tiles loaded around the player, I found that I began to get this error:

ERROR:GAMEOBJECT: Could not spawn an instance of prototype /main/objects/terrain.goc.
ERROR:GAMEOBJECT: Unable to create instance. Out of resources

around the time that 1024 objects were created. I guessed it was a project configuration issue, and changed max_count, max_resources, and max_instances up from 1024 to 2048 hoping this would solve the problem. With about 1500 tiles attempting to load, I still got the error. In an attempt to get an idea of what was causing the problem, I ran a simple test script:

local foo = {}
for i = 1, 1024 do
	foo[i] = factory.create("#terrain_factory", vmath.vector3(0, 0, 0), nil, {})
end

The terrain object instantiated was a simple script + sprite + collider, and the behavior was unaffected by adding / removing the collider component. The terrain script has functionality to send the sprite a “play_animation” message but it is not called automatically.

With max_count, max_resources, and max_instances set to 1024, I got three of the error mentioned above upon execution. This made since due to three other objects present in the scene, an object running the debug script, a player object, and a camera object for transformation relative to the player. At first I thought the problem had to do with sprites and not game objects, but the fact that there were three errors and the fact that the world and camera objects lack sprites suggests the issue lies in the instantiation of game objects in general.

As I lowered max_count, max_resources, and max_instances to 512, I got a large number of errors, presumably 512 + 3. However, as I raised the variables to 2048, I did not stop getting errors; I continued to get two errors. After some experimentation, it seems that the culprit setting is max_instances, and that max_instances is effectively capped at 1025. Do you know what might be causing this? This bug is causing a lot of frustration and I imagine there might be other developers having problems due to this bug.

I am running the editor on OS X, with 4 GB RAM, in case this turns out to be some platform or memory-related issue.

Best way to spawn a lot of moving sprites/particles?
Noname 2.5 Shooter (Open source)
One script or multiple? Impact on performance
#2

Thanks for that excellent bug report! When I tried to repro, I spawned a game object only containing a sprite. So you can try to remove everything but the sprite from the game object you are spawning to see if that makes a difference. I’m afk atm but will try to repro again using the info in your report.

1 Like
#3

Thanks, I removed the terrain script component from terrain objects and now the max_instances setting behaves as expected! Some number (which I would guess to be hidden, not configurable) seems to be limiting the number of instances of a script that can be created. That explains “Could not create script component, out of resources.” Adding a script component to the object instantiated a lot repros it like you suggested. I hope there’s some sort of workaround or fix for this, for now I’ll leave the terrain zoomed in.

Problem with RDG number of GO
#4

Ok I understand. The limit for scripts could be exposed but you should really consider a different structure. Having a separate scripts for each thing is just a lot of scripts to run. I don’t know anything about the purpose of your scripts, but see if you could use just one script that handles all of these things. It could even make more sense, if you compare it with the problem of a physics engine for example.

1 Like
#5

Ok. If you could expose the script limit in the next Defold release, I would really appreciate it. If it’s not something that can be or should be done, that’s alright. Since I currently don’t have any other options, I’m looking into using one “manager script” for the terrain. I only really need the terrain script on certain tiles that perform logic every frame, the others probably don’t need the script to stay, so I guess I could also have terrain tiles delete their script components unless they are one of the few tiles that need scripts.

By the way, it seems like allowing for large amounts of scripts might be a good idea, because people coming from engines like Unity might be used to doing things in a structure that uses large amounts of scripts, and it seems like something that Lua can probably handle since Unity compiled to HTML5 / JavaScript can handle quite an amount of scripts running in parallel.

#6

Using a script always has an overhead cost, so the more scripts you use the more processing you are wasting in overhead. Regardless of the performance aspect, we always recommend people to use “centralised” scripts (or “manager”) because of how frequently you tend to need the context of the “many objects” when writing that code (this is what I was getting at with the physics engine comparison). It also helps with control over what’s going on, like when whatever the things are doing should stop happening or change in some way. Then you don’t need to tell “everybody”, but only the script dealing with that.

1 Like
#7

Faced with the same problem as the author.
Is it possible to remove this restriction?

#8

Yes, we could probably make it configurable. But it’s not a very common request (this thread is almost three years old!).

What does your script do? In most cases there’s an alternative solution to having that many scripts.

#9

I know it’s better not to do that. My game is in the early prototyping stage and I don’t want to do premature optimization. The game runs very well with 1000 instances on my laptop PC.

1 Like
#10

Well…
Taking well informed early decisions based on experience is not premature according to me :slight_smile:
I consider it keeping a clean house, and as we know it’s a lot easier to keeping a house clean as opposed to do a full clean at the end of the project. And this is part of the philosophy of Defold, helping users keep a clean house during a project.

Edit: A lot of ppl don’t know where the quote comes from, or that it’s most often a misquote as well. Here’s a good post about it:
http://www.joshbarczak.com/blog/?p=580

Note, I’m all for taking shortcuts to try ideas, but I don’t want ppl to make decision based on a misquote. :slight_smile:

4 Likes
#11

Please just add the ability to increase the limit of 1025 instances to the project’s configuration file.

P.S. I hope that the very limited capabilities of Box2D are not due to the philosophy of “keeping a house clean”. :smiley:

#12

Actually, it is much more comfortable to code the game when each object has its own script. Defold perfectly runs even with 1000 GO instances with the scripts.

I’m making a prototype of the Tower Defense game, where on the final wave on the stage there are VERY many objects and I hit the limit of 1025 instances.

#13

I’ve added DEF-3780 for this. No promises on when this will be done though.

2 Likes
#14

It all depends on what you do in the scripts. If you start running a lot of code in update() it will definitely have an impact on performance.

1 Like