i'm making a procedurally generated side-scrolling and destructible tile based world. So far I've got : - the values generator (for deciding which tile to place where) - a testing scene generating one object per tile (a mesh with 2d box collider, inactive at start) - map chunking (separating the map into chunks to show only what is visible) - visibility based on orthographic camera size (it's not much but the camera can zoom in or out) - the chunks are 32x32 tiles in size - the maximum chunks I've seen is around 25

This works fine for testing the world generation, however there is massive stuttering when moving around with camera zoomed out to the maximum. It's less when zoomed in, but it is still noticeable.

From testing, I've found out that its obviously the building in the scene that causes the major part of the stuttering.

I've been searching for better ways of building the scene but there are a few constraints that make most of the non viable : - The world is destroyable, so I need to be able to interact with each tile - There are textures coming on top of the tile texture depending on context (selection rectangle, decoration, glow...) - The tile texture itself is not a single sprite but a repeatable texture, so it needs to be places based on coordinates so it properly repeats itself.

So far I've looked at : - TileMaps - Mesh melding - Texture bombing

None of these seem to be able to fulfill the constraints fully.

Is there a way to fulfill the constraints while improving scene building or am I missing something? Please help.

  • \$\begingroup\$ if loading the scene objects is causing stuttering issues, why not create them in a separate thread? I’m pretty sure the current version of unity supports multi-threading now. Check this out youtu.be/ja63QO1Imck \$\endgroup\$ – Savlon Feb 23 '18 at 21:32
  • \$\begingroup\$ @Savlon I already saw that video, however, creating and moving scene objects is always done in the main thread. It's the bottleneck, and the main issue of the stuttering. \$\endgroup\$ – madks13 Mar 5 '18 at 13:44

It is a lot more expensive to destroy and create objects than to move objects around. For some objects, you might not know how many are supposed to appear, and so they might not be ideal for reuse, but even some of the destructible tiles could be disabled when destroyed, moved ahead when out of view, and then re-enabled. You may even create extra tiles at the start just in case, leaving them disabled or somewhere out of view until you need them.

| improve this answer | |
  • \$\begingroup\$ I actually use object pooling. Sorry for not mentioning this before. I pool scene objects, map data (since i'm generating several layers), and resources (textures...). \$\endgroup\$ – madks13 Feb 23 '18 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.