Advice needed for design of 2D title with 2D Toolkit

[hippocoder]

Hiya

We need advice on what parts of 2D Toolkit to use ie best tool for the job advice please:

1. we need to make a tile based level with lots and lots and lots of tiles. Lots of them. It's a big level.

2. we need to be able to render some of the tiles either invisible or just hide them. This would need to also remove any collision within that space for the removed tile.

3. we need to query the kind of tile it is - is it a tile that can be destroyed? This isn't too vital, we could maintain separate lists for destructable tiles and solid tiles.

4. A nice-to have would be to change the image of that tile, for example, progressive damage to it.

That pretty much sums up our total needs. Thanks for any advice.

[profanicus]

Hiya

We need advice on what parts of 2D Toolkit to use ie best tool for the job advice please:

1. we need to make a tile based level with lots and lots and lots of tiles. Lots of them. It's a big level.

2. we need to be able to render some of the tiles either invisible or just hide them. This would need to also remove any collision within that space for the removed tile.

3. we need to query the kind of tile it is - is it a tile that can be destroyed? This isn't too vital, we could maintain separate lists for destructable tiles and solid tiles.

4. A nice-to have would be to change the image of that tile, for example, progressive damage to it.

That pretty much sums up our total needs. Thanks for any advice.

2d toolkit is going to make this easy ... The tilemap system is what you need. Basically 2d arrays where each grid location holds a sprite of a particular id, which you can change programmatically. You can have multiple layers, and paint vertex colours (not per layer yet though).

1. Get 2.1 beta 2, and check the tilemap demo included in that, it's fairly sizeable. The editor chunks the resulting meshes to your size specifications, and defaults to a good 'batchable' size for each bit of mesh. If it's so big that you'll need to be streaming meshes in and out, well Unikron can comment on that, and practical limits to the system...

3. Use GetTile and GetTileAtPosition to get the ID of the sprite at a tile grid or world location respectively. Then use that ID in GetTileInfoForTileId to get the structure that holds the metadata.  Each tile type (sprite ID) has built-in string, int, float and prefab (no bool) which you set in the editor, under Data tab. The beta 2 demo also shows the use of the prefab system.

2 & 4. The sprite at a particular tile location can be changed to another using SetTile, and cleared using ClearTile. Call Build after all changes are complete. Any changed collide will be automatically rebuilt (so Cleared tiles will have no collide) but I understand collide changes are relatively expensive. Your collision is set up on the sprites themselves in the Sprite Collection editor.

The system can also read in Tiled .tmx maps if you want to use that editor for some of its advanced auto-edging features, or if you are thinking of procedurally generating maps then some people around here have done that as well.

[unikronsoftware]

Hiya

We need advice on what parts of 2D Toolkit to use ie best tool for the job advice please:

1. we need to make a tile based level with lots and lots and lots of tiles. Lots of them. It's a big level.

2. we need to be able to render some of the tiles either invisible or just hide them. This would need to also remove any collision within that space for the removed tile.

3. we need to query the kind of tile it is - is it a tile that can be destroyed? This isn't too vital, we could maintain separate lists for destructable tiles and solid tiles.

4. A nice-to have would be to change the image of that tile, for example, progressive damage to it.

That pretty much sums up our total needs. Thanks for any advice.

As profanicus says, you really want to be on the 2.1 beta. The tilemap editor has improved massively in that release.

1. How big is big? The current max is 128x128 tiles, but that is pretty arbitrary to avoid people killing VRAM with vertex data. The system doesn't support "streaming" yet, and generates all chunks as the game runs, but if you need a world significantly larger than this - consider using LoadSceneAdditive to merge in tilemaps at runtime (and delete the old ones, of course).

2. Collision is the issue here. If the number of tiles you need to destroy isn't ridiculous, then perhaps use the prefab spawning system for that and have box colliders on them. Recalculating the mesh collider isn't recommended at runtime. If you need more complex collider shapes, then you could have each destructible bit in its own tilemap layer. The whole thing is partitioned, and datat blocks

3. Use tk2dTileMap.GetTileIdAtPosition to take a world position, resolve to tile x & y. Use GetTile(x, y) to get the tile id at a particular tile - this is more or less a unique number for the sprite. You can also type in some metadata per tile in the tilemap editor, you have an int, float and string to play with there. You have lots of options here.

4. tk2dTileMap.SetTile to change the tile, call tk2dTileMap.Build() to rebuild your tilemap. Only the partitions that have changed should rebuild, and that should be fairly quick - you can tweak partition size for this to work better. You're fine as long as collision meshes dont change.

[hippocoder]

Hi guys,

Thank you both for the great responses. I'm very surprised that you've solved all my issues from the outset! I would be destroying large chunks of level similar to a low definition even more retro version of worms! (in some cases)

A few more questions if it's not too annoying for you:

1. I was delighted to find that colliders are generated per frame for sprites. In our case sometimes we need to use box colliders that move and change size. Is it possible to get at the data without using physx?

2. Sounds like regenerating level collision would be an expensive task in the tilemap, so perhaps I should query the tile and use my own collision system with rectangles? Our game is strictly square blocks without rotation.

3. Does the tilemap support animated tiles (not a big deal at all, just curious) and does it support having an opaque material and a transparent material? not sure how all that works yet, still diving in!

4. You mention that we need to Build after changing the tilemap - is it possible to avoid the cost of collision being rebuilt, ie having no collision so I can roll my own? As it is square, using Physx may be overkill.

2D Toolkit is brilliant.

[unikronsoftware]

1. Not out of the box, but that is one of the things we'll be looking into in version 2.2. For now, I simply recommend getting rid of the collider code out of tk2dBaseSprite. (CreateCollider, UpdateCollider and EditMode__UpdateCollider). I've still not figured out how I'm going to transition to the new model without breaking backwards compatibility, but thats the fun part of the job

2. In the tilemap layer settings, untick "Collider" to make sure tk2d won't generate colliders at all.

3. I think that would be much much better than using Physx, and pretty easy that you're constrained to boxes.

4. #2 will do the job.

[hippocoder]

Great stuff

So it's looking roughly like this:  any interactive particles are coded by myself, probably using 2D Toolkit sprite for each particle (is this a bad idea? basically, there's a lot of debris and gore that absolutely needs to bounce off the level, so I'm wondering if I should create a skinned mesh full of quads or just use 2D Toolkit sprites).

In any case, I might actually leave the physx colliders on the sprites and just query collider.size (extents seems depreciated in 4.2) - would that work do you think? I can at least then just have easy culling of enemies and such I suppose!

You've done a bang up job on this.

[unikronsoftware]

For the particles, I think one thing to try would be to fill up a mesh every frame with a batch of sprites. Its really straightforward to pull data from tk2dSprites - evertythings precomputed, and all you need to do is fill the vertex array. A skinned mesh could work too, but you're obviously trading off one thing for another there - if you wanted to animate the particles, this would be a lot of work with skinned meshes.

Yeah, annoying about extents being deprecated in 4.2. Physx colliders left on the sprites and query collider.size will work, it just isn't as clean as it should be. Hopefuly 2.2 will fix that.

[hippocoder]

Thanks for the reply

I do hope you're making enough from 2D Toolkit to have a decent living from it as I'd quite like it to continue for some time!

[profanicus]

3. Does the tilemap support animated tiles (not a big deal at all, just curious) and does it support having an opaque material and a transparent material? not sure how all that works yet, still diving in!

I saw this wasn't answered:

No support for animating tiles. It's fairly easy to do though, just SetTile through a sequence of different ids. Obviously only change what is visible to limit Build cost.

Sprite collections do support multiple materials, and hence so do tile maps. You've probably already read this by now but here is the doc page on it.

[unikronsoftware]

I mustve completely missed that. You could animate sprites like that, sure, but you'll be constantly rebuilding the mesh. If thats something that will work for you, then that's a perfectly valid way to go about it. I'd worry a bit about GC hitches though. If you were going to constantly rebuild the mesh, I suggest making partition sizes smaller.

[BicPenatmeter]

Question. Couldn't  TileMap.SetTile() just change the UV coordinates on the existing mesh for those verteces corresponding to the changed tile (as in this case where the user is animating the tile via this method) instead of rebuilding the mesh?

Also, if I wanted to do this manually on the mesh created by the TileMap, because I want to change a specific tile's color or uv values, do you store vertex index data per tile coordinate anywhere? If not, is it possible to calculate vertex indexes through a formula like:

int tileVertexIndex = (x * tileMap.height + y) * 4

? Thanks for your feedback.

[unikronsoftware]

Not really that simple. The tilemap is merged into a large mesh chunks for performance reasons. Each tile in the mesh can have any number of vertices (not limited to 4) and could also be animated. You *can* change tiles colors by using tilemap.ColorChannel.SetColor(...). The positions in the atlas are also not guaranteed to be in any particular order, so changing UVs aren't that simple. You're still free to use SetTile though. It works fine as long as you're not changing colliders at runtime - you can tweak partition size to find an optimal mesh update size for your use case.