SpriteTile, a fast dynamic tile system (RELEASED)

That's a good question; I hadn't really thought about that at all. So I will have to think about it first.

I'm not quite sure what you mean by polygon shader. You can use any material with any shader for the tiles, though obviously not all shaders would be appropriate for sprites.

--Eric

 

OK, I thought about it and multi-camera support seems pretty straightforward. Just a matter of using a 4D array instead of a 3D array for the tiles, and an array for the cameras instead of one variable...I think. Also have to account for different viewport rects, but that's fairly trivial so I've done that part now.

--Eric

 

Thanks for the recent updates. This is getting better and better!

 

Oh my bad, I meant colliders. It's not a high priority for me, I just thought I'd ask.

Looking forward to the multi-camera support!

 

Oh, custom polygon colliders...I do have plans for that, yes.

--Eric

 

Can you add a ScreenToMapPosition for world coordinates too?

Right now if I go beyond the bounds of the map it logs a lot to my console when I use GetTile()

 

I could do that, but in the meantime you could use Camera.WorldToScreenPoint and use that with ScreenToMapPosition.

--Eric

 

Portable - I'd love to know how you went about it.

I have a license with Aron Granberg's A* Pathfinding and have used it with a 3D game - but I'm having a hard time figuring out how to implement it here.

I don't need groundbreaking 1000s of units AI, but i'd be nice to get this knocked out since it's so critical to basic movement for a point click game.

 

Eric - how big do you think you could make a level before it just really started to bog down? 5000 x 5000?

 

It will never bog down; a 5000 x 5000 level is equally as fast as a 50 x 50 level, or a 500,000 x 500,000 level. The only thing to be concerned about is running out of RAM. You can usually figure on 7 bytes per tile, unless you use per-tile materials in which case it's 8 bytes per tile. (Plus the overhead for the tile sprites of course, but that's always limited to the tiles you actually see on-screen and is therefore a fixed cost that never changes no matter how big the level is.)

--Eric

 

Is that when you'd expect lag to drop in or a complete freeze?

So if I'm doing the math on this right - a pretty crappy PC should have 2GB of RAM - or 2.147e+9 Bytes. The Square Root is... 46335.7313528 ... Divided by 8 = 5791. So if I kept it below 5,500 x 5,500 we should see flawless results?

I am asking this more out of curiosity/planning and in no way am I challenging - this kinda stuff is out of my comfort zone.

 

5500 x 5500 = 30,250,000 x 7 = 211,750,000 / 1048576 = 201.9MB. If it had to page stuff out to allocate that, there probably would be some temporary lag. What happens if Unity couldn't allocate 201.9MB? No idea...I'd expect a crash, maybe.

--Eric

 

Hi Eric,

When can we expect an update with Split-screen support? I'm eager to get it in my game.

I got SpriteTile from the Asset Store

 

Hello Eric!

First, your asset is great, thanks for your job!

I have one question: is it possible to build the tilemap directly in the Scene, instead of saving in files?

Thanks again, kind regards!

Nic

 

I've actually done that and was going to wait until I had some other features done before releasing 2.2, but if you want the code in its current state just send me a PM with your asset store invoice ID. It could probably use some more testing anyway considering it was suspiciously easy to do given that it's a pretty fundamental change. Or maybe the code is actually structured well.

To use it, SetCamera can take an array of cameras now:

Code (csharp):

1. var cameras : Camera[];
2. var level : TextAsset;
3.  
4. function Start () {
5.     Tile.SetCamera (cameras);
6.     Tile.LoadLevel (level);
7. }

You can use an arbitrary number of cameras that are set up in any configuration:

Hi, you can use the SpriteTile API to build levels in code without needing to save files. If you mean building tilemaps actually in the scene view, then no, that's not possible.

--Eric

 

The next version is about done, minus some more QA and doc updating. Changelog currently is:

SpriteTile 2.2

Additions:
• Multi-camera support. An arbitrary number of cameras in any configuration can be used, and each camera will only draw as many tiles as needed, the same as with a single camera.
• Tile.AddLayer, for adding new layers to a level at runtime.

Changes:
• Level layers are reversed, in order to be consistent with Unity's layer order. That is, layer 0 is now the bottom layer and higher layer numbers are on top. Existing levels can be converted easily in the TileEditor by using the layer up/down buttons.
• Tile.SetCamera can use a Camera[] array in addition to a single camera. Also, calling SetCamera() with no arguments will use all cameras tagged MainCamera (if there are more than one) instead of just the first.
• Tile.ScreenToMapPosition can optionally take a camera number, if multiple cameras are used.

Fixes:
• Tile.GetLevelBytes returns correct data if tiles have been rearranged, so levels saved in code will work properly.
• Cameras with altered viewport rects work correctly.

TileEditor Additions:
• "Show preceding layer" toggle, for drawing the layer underneath the current layer, if such a layer exists and has the same dimensions as the current layer. The preceding layer is drawn at 50% alpha to make it easier to distinguish from the current layer.
• "Show next layer" toggle, for drawing the layer on top of the current layer, with the same conditions as above. The next layer is drawn at 50% alpha so you can still see what you're doing.

TileEditor Changes:
• If a tile already exists in the current set, it won't be loaded. This means that you can add new sprites to a sprite sheet, load the sprite sheet with the "Load" button, and only the new tiles will be added. This also means that you can add a number of sprites to a folder, load them using the "From Folder" button, and again only the new tiles will be added.
• The undo queue is no longer reset when changing layers. If you undo a change that was made on a layer other than the one currently selected, you're automatically switched to that layer and the undo is performed. (Unless you're showing the preceding or next layer and the undo occurs on that layer, in which case you can see the undo occur anyway so there's no need to switch.)
• The currently-selected layer number is saved with the level, so you don't need to manually switch to the layer you were working on last when loading a level.
• The "new level" button confirmation dialog text is better worded, and won't appear if the level is saved.

TileEditor Fixes:
• Adding and removing tiles from Random groups works correctly if the tiles have been rearranged.
• If deleted tiles are in the undo queue, undoing will work without errors.

--Eric

 

Version 2.2 out now! (On my site; asset store to follow.)

--Eric

 

This plugin seems reallyinteresting to use, specially with the compatibility with the native sprite system n_n.

I was just wondering about some things about this plugin:
1. Do you have any plans to handle Isometric tiles any time soon?
2. Have you considered implementing a way of importing external tilemap systems? I am specifically referring to the Tiled map editor format.
2. It there any chance that I could create some sort of importer in editor to create my own tile system form a Tiled scene?

Thanks a lot...
Italo F. Capasso B.

 

1. You can do isometric tiles currently; it's just a matter of using the drawing order to make sure the correct tiles render on top of the others:



2. I have indeed considered it, though I wasn't sure if there was enough demand. Since there's some interest, I'll look into it.

3. I would expect so.

--Eric

 

Version 2.2 is up on the asset store!

--Eric

 

2.2.1 is out, which fixes a problem with the TileEditor window not working in empty projects. I've uploaded to the asset store, but if you want an immediate fix, you can import the SpriteTile/Resources/TileManager.asset file from the demos package (you can leave out the rest), and then get rid of the missing tiles in the editor.

--Eric

 

Hi again Eric.
I'm encountering a minor issue with the way polygon colliders are currently generated. It seems like the generator takes the alpha of the tiles into account when creating the combined polygon colliders. This is a nice feature, but it isn't one that I actually want. Is there some way to make the colliders behave as though all tiles are perfectly square?

 

Currently SpriteTile just uses the polygon collider of the sprite as generated by Unity. I have plans to allow for custom colliders, but until then a slightly convoluted work-around is to 1) make another layer, 2) use a square sprite with a polygon collider in the places you want, then 3) use SetLayerActive to make that layer invisible. The polygon colliders in the layer are not affected.

--Eric

 

Hey Eric, I have SpriteTile displaying infinite terrain right now, and I'm using white sprites so that I can color them individually. Is there a way to do that? I see some things in the documentation about materials, setting the material of an individual tile, or setting the material for all of the tiles, but I don't see anything in the documentation about accessing material parameters of a particular tile.

The only thing I see really is SetLayerColor, but in that case I would need 32 layers, one for each color in the foreground and background, and that's a lot of layers. Is there a simpler way?

 

Per-tile color options are on the to-do list. Right now, you could potentially use different materials with different tints, and assign those to tiles.

--Eric

 

But different materials would increase the amount of draw calls, correct? Whereas tinting a tile would not.

 

Correct.

--Eric

 

Gah, this thing's working real nice too. Oh well I can develop other parts of this for now, I have a giant set of something like five hundred monochrome sprites that can be colored, and was trying something out with them. I suppose it would be less draw calls using the layer color method for now. Is there a maximum number of layers?

How much booze/women/money can I throw at SpriteTile for that feature? Do you accept Dogecoin?

 

It was on the to-do list for the next version anyway, no need to throw stuff. There's no maximum number of layers. (Well...whatever Int.MaxValue is.)

--Eric

 

It's about damn time, lol.

Oops, I mean, "Thanks Eric!", hahaha

This was my biggest complaint originally, as the old order didn't make any sense at all compared to what is standard. At the time I was told it's a matter of opinion, but it's always nice when the correct opinion wins out. That's my opinion anyway. Which interesting enough just happens to be the correct one.

Great job Eric! And to all those who complained about this, which I'm sure is the reason we finally got it

Another great product, with great updates as usual

This really is a great improvement, even if it seems like such a small feature.
Future users will be glad.


edit: The split screen feature is pretty neato too. Great updates.

 

Well, I think you were the only one. But I did take it into consideration, and it made more sense this way with the AddLayer function.

--Eric

 

Hey man. I just bought SpriteTile, and I'm trying to setup a simple scene with a simple map to get the stuff working, but it don't work.

I'm using Unity 4.5

My script is in C# :

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3. using SpriteTile;
4.  
5. public class World : MonoBehaviour {
6.  
7.     public Camera tileCam;
8.     public TextAsset level;
9.  
10.     // Use this for initialization
11.     void Awake () {
12.         Tile.SetCamera(tileCam);
13.         Tile.LoadLevel(level);
14.     }
15.    
16.     // Update is called once per frame
17.     void Update () {
18.    
19.     }
20. }

I made a new scene, added this to a new game object in my scene, saved a map, gave its reference to the game object along with the camera, and... Nothing happen. :/

Might it have to do with the 4.5 version?

 

SpriteTile doesn't have any problems with Unity 4.5. I would guess that the camera isn't positioned where it can actually see the level...the TileEditor will show world positions of each tile (at the bottom of the level view), so pick a tile, note the x/y coords, and move the camera to that spot.

--Eric

 

I checked the tiles and none of them are enabled nore refer to my tileset texture. Instead they refer to an "external texture" stuff.

I added the project, in case you want to see it.

 

I deleted the attachment because it contains the SpriteTile dlls. Do not publicly post other people's assets please. As I said, position the camera where it can actually see some tiles in the map, and it will work.

--Eric

 

Oops, sorry about the dll. :/

Ok, now I see some tiles, but it is not really intuitive to have the tiles display only when the editor is playing.

Anyway, I'm gonna play with this. Thank you. :]

 

You can use the preview feature if you want to see the tiles without the editor being in play mode.

--Eric

 

Score!!!!!!!!!!! The power of ONE!

*brags*

lol jk

More like, the power of two! Form of: One lazy guy who said one QQ and one guy who did all the development!

*transforms*

 

After turning the procedural example into an infinite scrolling map, I went about porting the scripts in that example to the One True Language: C#. It took me a bit because they are coroutineception, and I've never played with those before. I am considering possibly releasing those so that people can see how to do it, looking through the thread it seems to get asked a lot, but first there's some optimization stuff to do, and some more tweaks I want to make.

 

Whoa, glad you mentioned this. I was looking at SpriteTile but if there are no C# examples, I'll pass for now.

 

There are C# examples; most of the demos have both JS and C# scripts, and all the code in the docs is 100% both C# and JS.

--Eric

 

Eric is correct, all but three of the demos have scripts in both languages. I'm just more interested in the procedural stuff, and that particular one did not.

 

The main reason that one doesn't is because I'm considering some kind of built-in tile-by-tile movement functions, so I didn't want to spend time converting something that might not actually be necessary anyway.

--Eric

 

Thanks for all your hard work. I just got my characters walking around and colliders working! I've had a lot of fun with this product so far.

I have two questions:

1: Is there a way to apply additional variables or tags to a tile? I need to know more about a tile than whether or not it is a collider. I need to know, for example, rather a particular tile is grass or wood or stone. Collider = False, Type = STONE, Color = RED. Is there a way to add additional information to tiles within the editor without editing the source code?

2: I'm making a top down adventure game, similar to The Legend of Zelda: A Link to the Past on the SNES. Is there a way to control the draw order of tiles managed with SpriteTile and the scene's other sprites? I would like a character to be able to walk either in front of or behind a tile depending on their position on the map. If a character approaches a fence tile from the bottom, she will obscure the fence. If she approaches a fence tile from the top, part of her will be obscured by the top of the fence. (Note: My fence tiles are slightly taller than the tile based grid that holds them.)

In the past (pre-unity) I accomplished this by constantly re-sorting my sprites by their y position as they moved around the map. I'd start by drawing the top row of tiles, then I'd draw any sprites positioned on that top row. Then I'd move one row down and draw that entire row of tiles, followed by any sprites positioned on that row, and so on until I hit the bottom of the map.. Is that still the recommended approach here?

Thanks for any help you can provide.

 

1. You can use GetTile, which tells you the set number and tile number for any tile. Or you could use triggers; each tile can have a number from 0-255 associated with it that you can use for any arbitrary purpose. Or use both.

2. You can change the order in layer for any tile using SetOrder. (Or you could possibly change the order in layer for the moving sprite instead, depending on the circumstances.) It might be more efficient to look at the tiles that the character is moving toward and altering the order for that particular tile rather than all of them on-screen.

--Eric

 

Hi, nice tool. But is there a possibility to specify position to load level at?

 

The bottom-left tile is always 0,0. You can move the camera after loading a level if needed.

--Eric

 

Hi Eric,

I've been using SpriteTile with much success so far. Thank you for creating it. It saved me a lot of work so far.

However, I've just spend a few hours trying to debug a really annoying issue. And now that I finally figured out what was going on, I figured I'd tell you just in case that will help people do this in the future.

Basically, my issue was this:

Code (c#):

1. Tile.NewLevel(new Int2(mapSize*2, mapSize*2), 0, 0.16f, 0, LayerLock.None);
2. Tile.AddLayer(new Int2(mapSize*2, mapSize*2), 0, 0.16f, 0, LayerLock.None);
3. Tile.AddLayer(new Int2(mapSize, mapSize), 0, 0.32f, 0, LayerLock.None);

If you try to use layers with different sizes over each other, the tiles do not match up, due to their origin being in the center. I thought I'd fix this by just setting their origin to the bottom left. This worked fine for the tiles, but your collider code does not assume this is happening, so my collisions were suddenly not matching my display any more (in fact, they were even more off than before).

I finally solved that using

Code (c#):

1. Tile.SetLayerPosition(2, new Vector2(0.08f,0.08f));

Which just shifts the entire layer to align. But for some reason that feels like a hack. Anyway, do what you want with it that solution works for me (for now).

 

SetLayerPosition is quite reasonable for that sort of thing and I wouldn't call it a hack.

--Eric

 

can i load multiple levels at the same scene?