2D Toolkit Forum

2D Toolkit => Support => Topic started by: tenpn on October 22, 2013, 06:50:00 pm

Title: Best practices for large scrolling terrain?
Post by: tenpn on October 22, 2013, 06:50:00 pm

Hi folks,

If you wanted to develop a top-down RPG, like Zelda or Realm of the Mad God, with tk2d, what would be the best approach to rendering terrain?

(http://cdn2.steampowered.com/v/gfx/apps/200210/ss_4924acdd427eba824f6dfd051b5fa0d48e835c82.1920x1080.jpg?t=1357608465)

I'd like to use the tilemap editor to place a few items of interest in a sparse world, and leave large gaps. These gaps would be filled in at game start with one of a selection of grass sprites. Obviously the whole terrain could then be statically batched. Instantiating a prefab for each empty tile in the world is unfeasible. Even one per tile on the screen, and then scrolling as the camera moves, is too much with a sufficiently zoomed-out camera! At a lower level, I could just decide on sprites at draw time and batch them appropriately, but this is Unity and I'm not allowed to do that. :)

Any help much appreciated.

Title: Re: Best practices for large scrolling terrain?
Post by: tenpn on October 22, 2013, 07:14:01 pm

I think a corollary question then is, how do you manage rendering large dynamic or procedural worlds in tk2d? A gameobject per on-screen tile with a custom back end managing the current sprites seems like it's not going to batch well, especially with a smooth-scrolling camera.

Title: Re: Best practices for large scrolling terrain?
Post by: tenpn on October 22, 2013, 11:26:59 pm

So I got pretty far using a scriptable static batcher: http://www.2dtoolkit.com/docs/latest/advanced/scripting_static_sprite_batcher.html

There's a hard limit of 128x128 on these. Via twitter Unikron told me to aim for ~20x20 batches for best performance, but ofc YMMV, always profile this type of partitioning.