2D Toolkit Forum
2D Toolkit => Support => Topic started by: UtilityFrog on January 10, 2014, 04:18:11 pm
-
Hi
I'm looking into using 2d Toolkit to help me build a roguelike-ish game with a top down perspective and procedurally generated tile based levels.
The entire level will not be visible at once, the camera will only show a portion of the map at any one time. The portion of the map visible at any one time will be on the order of 20 tiles high and 25-30 tiles wide. The size of the entire level is a bit up in the air at the moment, but assume at least 5x the size of the visible area (so roughly 100 high and at least 125 wide). As I said before the entirety of the level structure will be determined at runtime.
So, some questions:
- Given that I'll be generating everything at runtime I'm assuming that 2d toolkit's static sprite batcher is not an option for me. But aside from that, does 2dtk perform any kind of automatic geometry reduction? If I'm understanding how Unity works correctly my entire level only needs to be a single quad with my tile textures mapped on to it. I'm guessing a single quad is better than 12,500 or so. :)
- Will the size of the entire level affect performance or will only the size of the visible portion of the level affect performance? E.g., if I double my overall level size without changing the size of the visible portion will that have a performance impact in terms of rendering? I suspect the answer to this would depend on whether level geometry is collapsed into a single mesh or not, but I'm not sure.
- I'm a little concerned about the claim made in this post (http://2dtoolkit.com/forum/index.php/topic,2907.msg16492.html#msg16492) (the post by whale about excessively large scene files and load times). Given what I've written above, will this be a concern for me? Note that I won't be needing to change the size of my map once created.
Thanks in advance for your help.
-
I've had a look at the TileMap class (http://2dtoolkit.com/docs/latest/html/classtk2d_tile_map.html) and it seems to be able to do what I want, at least going by the default tilemap size. It seems I would be able to generate the level on Awake() or Start() and finally call Build() only once.
I presume the partitioning system is there so you don't get the problem of 1 huge mesh that is always in camera and therefore always being rendered, correct?
So is there anything else I should know about procedurally generating levels using a TileMap? This would be a core part of my entire game so I'd like to know in advance if TileMaps are intended to be used this way or if I'd be bending the system to do something it's not designed for and another approach may be better.
Thanks.
-
Given that I'll be generating everything at runtime I'm assuming that 2d toolkit's static sprite batcher is not an option for me. <- the static sprite batcher will work but the tile map will probably be easier to deal with if you're making a tile based level. Still keep the static batcher in mind - its pretty useful if you want stuff which isn't part of a tiled level and constructing one at runtime is pretty fast too.
But aside from that, does 2dtk perform any kind of automatic geometry reduction? If I'm understanding how Unity works correctly my entire level only needs to be a single quad with my tile textures mapped on to it. I'm guessing a single quad is better than 12,500 or so. <- this is wrong, there isn't any way to do an entire level as one quad. Also 12k quads won't be bad. tk2d splits stuff up into partitions (default size 32x32, with a quad on each tile the max mesh size will be 2k tris.
I presume the partitioning system is there so you don't get the problem of 1 huge mesh that is always in camera and therefore always being rendered, correct? <- Yup. Ultimately if you run into perf issues it will be wise to profile with different partition sizes, but that is a non-destructive operation so there is room to experiment later.
There isn't much else with the tile map, just that creating and optimising poly / mesh colliders is the slowest part of the whole process. If you want to modify tiles at runtime keep that in mind, it will most certainly be more optimal for you to create and manage your own colliders. Also, don't ignore the flexibility static sprite batchers can give you, its useful to keep that in your arsenal for if or when you need it.
-
Given that I'll be generating everything at runtime I'm assuming that 2d toolkit's static sprite batcher is not an option for me. <- the static sprite batcher will work but the tile map will probably be easier to deal with if you're making a tile based level. Still keep the static batcher in mind - its pretty useful if you want stuff which isn't part of a tiled level and constructing one at runtime is pretty fast too.
But aside from that, does 2dtk perform any kind of automatic geometry reduction? If I'm understanding how Unity works correctly my entire level only needs to be a single quad with my tile textures mapped on to it. I'm guessing a single quad is better than 12,500 or so. <- this is wrong, there isn't any way to do an entire level as one quad. Also 12k quads won't be bad. tk2d splits stuff up into partitions (default size 32x32, with a quad on each tile the max mesh size will be 2k tris.
I presume the partitioning system is there so you don't get the problem of 1 huge mesh that is always in camera and therefore always being rendered, correct? <- Yup. Ultimately if you run into perf issues it will be wise to profile with different partition sizes, but that is a non-destructive operation so there is room to experiment later.
There isn't much else with the tile map, just that creating and optimising poly / mesh colliders is the slowest part of the whole process. If you want to modify tiles at runtime keep that in mind, it will most certainly be more optimal for you to create and manage your own colliders. Also, don't ignore the flexibility static sprite batchers can give you, its useful to keep that in your arsenal for if or when you need it.
Hi, thanks for your response!
With regard to the Static Sprite Batcher, I'm assuming you're not referring to using a batcher directly in the editor (like here (http://www.2dtoolkit.com/docs/latest/tutorial/using_the_static_sprite_batcher.html)) but instead creating one via script (like here (http://www.2dtoolkit.com/docs/latest/advanced/scripting_static_sprite_batcher.html))? Just from looking at those two pages it doesn't seem that using the in-scene approach would be possible for me as none of my objects will exist until runtime. Also, is that page on scripting a static sprite batcher up to date? For example, the code in that page uses tk2dBatchedSprite's, but I couldn't find any reference to that class in the api docs.
It does seem that a TileMap is the way to go for me. Two things though:
- I read somewhere on the forum that a tilemap can't contain animating tiles. Is this correct? I suppose it might make more sense to have animating level features be independent sprites anyway.
- Looking at the TileMap api docs, I interpreted the width/height of 128 to be a default value, not a max value, is that correct?
Thanks again for your assistance.
-
The tile map can't have animated tiles, but... you can use
1. prefabs of animated sprites
2. material overrides in the sprite collection, and modify the materials with a custom shader that animates.
128x128 isn't the max value, AFAIK the default max is 1024x1024, but you have full source to this, you can tweak as necessary.
tk2dBatchedSprite isn't a documented feature as it relies on internal behaviour but we kept getting requests about how to deal with it so we documented the only bits which weren't likely to change (merging sprites)
-
The tile map can't have animated tiles, but... you can use
1. prefabs of animated sprites
2. material overrides in the sprite collection, and modify the materials with a custom shader that animates.
128x128 isn't the max value, AFAIK the default max is 1024x1024, but you have full source to this, you can tweak as necessary.
tk2dBatchedSprite isn't a documented feature as it relies on internal behaviour but we kept getting requests about how to deal with it so we documented the only bits which weren't likely to change (merging sprites)
Okay, thanks for your explanation.