SpriteTile, a fast dynamic tile system (RELEASED)

Hi Eric. I've saved on my poject's folder. But nothing happens. Nothing is saved. If I do a preview it works and I can play with it but when I try to save it all the stuff seems to work but finally nothing is saved.

Thanks

Juan

 

OK, looks like something got messed up with the DLL for the editor. You can use the source code instead.

--Eric

 

Another day, another version! Also, 1.2.2 went live on the asset store yesterday; I didn't get any notification of that.

SpriteTile 1.2.3

Improvements:
• Colliders on empty cells are visible now in the TileEditor.

Fixes:
• Setting tiles with physics colliders from code will work when using SetCamera.
• Saving levels works if using the TileEditor DLL.

--Eric

 

i just updated all my files with the new version and I'm getting the error

"Assets/Editor/TileEditor.js(1488,51): BCE0023: No appropriate version of 'TileManager.SetSpriteData' for the argument list '(int, int, int, float)' was found."

I'm not sure if I updated something incorrectly or if there is some other conflict happening. Any suggestions?

Thanks,
Matt

 

Hi Eric!

Some questions:

1. Can I remove tiles en-masse during runtime, such as removing a large amount of them from the 'map' from say an explosion?
2. Can I easily add tiles as well? Will these have collision?
3. Can I easily identify tiles? For example, query the tile at this location and return a unique index so I might embed extra data?
4. Am I able to construct my own levels via code?
5. How efficient is all this?
6. Can some tiles have different materials? ie opaque... efficiency with PVR hardware.
7. Can some tiles animate? not essential but still a nice-to-have.

Thanks

 

Sounds like you have an old version of the TileEditor script. I'd recommend removing all the SpriteTile files and reimporting.

1. Yes.
2. Yes.
3. Yes.
4. Yes.
5. Quite efficient (runs on mobile with no issues).
6. Not currently, but in the next version.
7. Right now there isn't a built-in animation method, but it's not hard to do this yourself with the current API (see docs), and the next version will have something built-in.

--Eric

 

Sounds great. So it's no problem to destroy a bunch of tiles with colliders and add some while gameplay is in progress on mobile? great!

Thanks for replies.

 

There are two kinds of colliders, a "fake" collider where every tile is just considered either passable or not passable, which has virtually no performance impact, and polygon colliders using the 2D physics engine. With polygon colliders, you'd want to be reasonably conservative about creating and destroying zillions of tiles, since that's relatively costly (if those tiles have colliders). However SpriteTile does use a "lazy update" system where all the changes are noted and then only applied at the end of the frame, in order to minimize the polygon collider rebuilding.

--Eric

 

Hello Eric, I'm using SpriteTile to build a game!! Surprised right? Anywho, I'm trying to manage loading and removing the tile levels that I've created using the SpriteTileEditor and I'm having some issues. Loading the first level from a file and setting it up is no problem, when I try to remove it (using EraseLevel), the tiles disappear but it I'm seeing the SpriteTileColliders, the SpriteTileLayers and the SpriteTileSceneManager still in the scene. Since I have to call SetCamera after I load a level and SetColliderBlockSize before, I have to do some awkward checks to see if I've already set them when attempting to load another level or else I get errors. In addition, after loading a new level, there are some nasty side affects that appear like the tile positions have been shifted.

It seems like I might be missing something simple or just doing it wrong. Essentially, my goal is to clear out the tile level when complete and load a fresh one from a .bytes file over the course of the game. I've also tried manually removing the SpriteTile objects after calling EraseLevel but there are some hooks that throw errors inside the library. Can you shed some light on a good way to handle this?

Btw, this library has saved me a bunch of time and I was able to very quickly create a game prototype with it. So far it's been great.

Thanks!

 

I'm not surprised! But I'm pleased! You're correct about EraseLevel, where the collider/layer objects are still in the scene after using it. This is so they can be re-used, instead of having to regenerate them. The actual colliders are reset, so the level is properly cleared.

However, it's not necessary to use EraseLevel if you're just wanting to load a new level. You should be able to just call LoadLevel without having to do anything else. Do you have more details about side effects after loading? It should just work, and tile positions shouldn't shift...if you want to send me a project that demonstrates this, send me a PM. You're right that it can be a bit awkward the way SetCamera is handled; I'll change it for the next version so it will be simpler to use.

--Eric

 

Thanks for the fast reply. Loading without calling EraseLevel works. I'll try to set up an example project for the other issue. I want to make sure it's not something I'm doing that's causing the issue. I'll post or PM either way.

 

Hi,

Just bought SpriteTile to kickstart Unity conversion of my iOS game (Cavern) but it seems to lack support for non-square tiles - any chance to add this in future update (my tiles are quite non-standard 24x35 pixels)?

Another question, I currently draw "shadow" of wall by drawing wall layer in two passes (one transparent with offset, second actual tiles), is this possible with SpriteTile?

(See attached screenshot, please ignore the wrong other one


BR,
Sami

 

Hi, I just tested a 24x35 sprite and it seemed to work without any issues. What problem are you seeing? Make sure you import as truecolor rather than compressed.

I'd recommend having the shadow be part of the wall, and having tiles be overlapping. (Use drawing order to make sure the floor tiles are drawn under the wall tiles.) That way it can be done in one pass, which would be more efficient, although if you really wanted you could make shadow tiles and use layers.

--Eric

 

How can I set the map grid to 24x35? At least when using NewLevel() grid size is given using only one float. Have to play around a bit with shadows, overlapping is not possible since overlapping transparent parts would create shadow artefacts.

Thanks for quick reply!

-Sami

 

Oh, I see what you mean. Currently the actual grid is square even if the tiles aren't. I'll change that to have an X and Y size for the grid.

Overlapping looks like it would work to me. The shadows wouldn't overlap, only the tiles would. The wall would be fitted to the tile grid and the shadow would be offset down/right (and the pivot for the tile set appropriately).

--Eric

 

The draw call is high. Are you going to reduce the call like 2dtoolkit?

 

The draw calls depend on the Unity sprite batching. You will get best results if you use sprite atlases. As you can see there's just one draw call for the entire screen when using an atlas here:



--Eric

 

Will you implement functions to generate tileset automatically?

 

Unity can already do that if you have Pro; it will auto-generate atlases if you use packing tags. If you don't have Pro, you can put the tiles into a single texture, and use the sprite editor to do slicing using a grid or automatically. http://docs.unity3d.com/Documentation/Manual/SpriteEditor.html

--Eric

 

Is there a way to zoom the tile map, I know that you batch the tiles according to the camera size.

Most zoom functionality relies on changing the camera size. When this happens the number of visible tiles doesn't increase and remains at the number initially created just zoomed out. They also update when scrolling, just limited to the initial tile number.

 

Zooming the map is supported in the next version. (Finished that yesterday actually.) It works for changing the orthographic size, as well as moving the camera on the z axis if it's a perspective camera.

--Eric

 

Excelent, cheers for that. I will hold off hacking something together then.

 

Hi, Did the non-square tiles make it to the next version?

Other than that, sprite tile seems to offer pretty much everything i need.

 

Yep, that feature is implemented.



(Also Tile.NewLevel can take a Vector2 instead of a float.)

--Eric

 

Is there a way to store meta data on a tile basis? much like you can in Tiled(the program)

for instance can i mark tiles in the tile set as a "ConcreteWall" type and a "BrickWall" type, so that in code i can interrogate the tile at a location to get relevent metadata back without having to perform a large lookup based on tileId?

I see that you do that will if a tile is collidable I presume it would be the same method?

Cheers

 

also is it possible to renumber the tiles in the tileset editor if you need the tiles in a specific order?

cheers

 

One possibility is using triggers, which in practice is an arbitrary number that you can use for metadata purposes, which is associated with specific tiles on the map. You can use that in combination with enums, something like:

Code (csharp):

1. enum WallType {Concrete = 0, Brick = 1}
2.  
3. // See if tile at 5,10 is a brick wall (trigger # == 1)
4. if (Tile.GetTrigger (new Int2(5, 10)) == WallType.Brick)...

Or you could use tile types instead of per-square triggers, such as if set 0 was for walls, and in that set tile 0 was the concrete wall sprite and tile 1 was the brick wall sprite:

Code (csharp):

1. enum SetType {Walls = 0, Floors = 1, Trees = 2}
2. enum WallType {Concrete = 0, Brick = 1}
3.  
4. var tileInfo = Tile.GetTile (new Int2(5, 10));
5. if (tileInfo.set == SetType.Walls  tileInfo.tile == WallType.Brick)...

There's a bit specifically for collidable tiles:

Code (csharp):

1. // See if tile at 5,10 is passable
2. if (Tile.GetCollider (new Int2(5, 10)))...

Coincidentally I'm working on that feature right now. It's mostly done; the only thing left is to get the delete tile function working properly with it. With the method I used, all the levels you have saved will always look correct regardless of how you mess around with the tile order (including levels saved with older versions).

--Eric

 

Version 2.0 is nearly, but not quite, here! Changelog:

SpriteTile 2.0
• A number of things have changed--if you're upgrading, you will need to read the update note file carefully! Make sure you have a backup of your project just in case something goes wrong (which it won't, but better safe than sorry)!

Additions:
• The screen size/aspect ratio/orientation can be changed arbitrarily at runtime, and the tiles will be automatically updated as needed.
• Tile.LoadGroups for loading a groups file.
• Tile.CopyGroupToPosition for copying a specified group to a position in the map, with an optional offset (for adjusting the "pivot point" of the group).

Changes:
• Tile.SetCameraAuto is removed, and Tile.SetCamera now does what SetCameraAuto used to do. Tile.MoveCamera and Tile.SetCameraPosition are also removed. If you were using those functions, just move the camera's transform directly. (As a side effect, the problem with using SetCamera in Awake in webplayers is apparently banished.)
• You can move the camera on the z axis (zoom in/out) for perspective cameras, or change the orthographic size for orthographic cameras, and the tiles will be automatically updated as needed. Note that zooming out can potentially create tons of GameObjects if you zoom out too far, so limit zooming to a sensible amount.
• Since camera rotation can potentially cause errors, having the camera not be rotated is enforced.
• Tile.SetTileMaterial can be used to set the material of a particular type of tile, so all instances of that tile will have a given material.
• Tile.SetTileMaterial can also be used to set the material of a specific tile in the map. These two methods can be combined, where setting a material for a specific tile in the map will override the material for a tile type.
• A non-square tile grid is possible now, so Tile.NewLevel can use a Vector2 for the tile size instead of a float. A float can still be used, in which case the X and Y tile grid sizes will be the same.
• Likewise, the LevelData class now uses a Vector2 for the tile size.
• Tile.GetTileSize returns a Vector2 instead of a float (guess why!).
• Tile.SetCamera should now be called before NewLevel or LoadLevel, instead of after. This means there's no need to track whether SetCamera has been called after loading a level, since it can just be called once in Awake or whatever and forgotten about.
• For the sake of consistency, tile layer positions are always reset when loading a level or making a new level, even if the level is the same size as the previous level.
• The level format is version 2 now. SpriteTile 2.0 will load files from earlier versions, but SpriteTile 1.2 and earlier will not be able to load SpriteTile 2.0 files.
• The Editor and Resources folders have been moved to a SpriteTile folder for better organization. (The Plugins folder is not moved, since that's a Unity limitation, sorry.)

Fixes:
• Fixed issue with loading a level of the same size as the previous level, where on-screen tiles could fail to update properly.
• Fixed error that could potentially occur in camera movement code with non-square levels.
• Changed use of System.Text.Encoding.ASCII to System.Text.Encoding.UTF8 for better compatibility.

TileEditor Additions:
• There's a ">" button next to "Tile size", which enables a non-square tile grid; the "Tile size" changes to "Tile size X" and "Tile size Y". Click the "<" button to change back to a square tile grid.
• There is a "Move" button now for the tile list (which replaces the "Delete" button, which has been moved: see below). This is useful for rearranging tiles after they've been imported, in case you want a different order for coding or other purposes. You can move tiles around in the list as desired without having to worry about messing up either the current level, or previously-saved levels or groups. They will continue to load and work as normal.
• Tiles have a "Non-transparent" checkbox, which if checked will cause them to use a non-transparent shader by default. Opaque shaders can improve performance, so it's usually a good idea to enable this for tiles that have no transparent pixels.
• Tiles also have a "Use dynamic lighting" checkbox, which if checked will cause them to use a lighting-enabled shader by default. Lighting will reduce performance, so leave this disabled unless you need the tile to react to lighting.
• Options to auto-load the most recently used level and group files whenever the TileEditor window is opened.

TileEditor Changes:
• The "Delete" button for tiles is changed so that it's only accessible after clicking the "Move" button first.
• The trigger overlay will also show the trigger numbers on the tiles, so they can be seen at a glance without having to hover over the tiles.
• Using the "pick tile" function (pressing the "p" key) will scroll the Tiles window to the selected tile.
• Improved path handling when loading and saving levels/groups/sprites, and the saved paths are also per-project now instead of universal.

TileEditor Fixes:
• Fixed loaded groups being upside-down.
• Fixed issues with groups not being handled correctly when deleting a tile.
• Tiles that are part of atlases keep their number suffix when using the Refresh button or re-starting the TileEditor. They also use the Unity sprite name now, so they start with 0 instead of 1. e.g. MyTile-1 becomes MyTile_0.
• Using the "pick tile" function will work if the tile is the first tile in a set.
• Fixed editor preview displaying too large previews anyway and potentially crashing the editor.

--------

You may notice there are no animation features in this update, for which I apologize. It was getting to be quite a large update as it is, though, and I didn't want to delay any more than necessary. In the meantime it's still possible to do animation yourself using the current API without too much trouble, though I recognize that built-in functions would be ideal...keep an eye out for version 2.1.

--Eric

 

Version 2.0 is out now! Update notices are being sent out to anyone who bought from my site. I'll upload it to the asset store next.

--Eric

 

Hello, any news about the availability in the asset store ?

Thanks.

 

It's still pending review. Not sure why it's taking so long; usually they are much faster.

--Eric

 

It's finally on the store now!

--Eric

 

How would you go about implementing a 'health' system for a tile.

say for instance I have 2 layers:

1 - Base Ground Tiles
2 - Wall Tiles.

I want the wall tiles to be able to be destroyed. Therefore they need a health parameter. Usually you would create a gameobject for a wall section with a health variable for each section.

Im trying to work out if it is worth using spritetile for this and then maintain a separate data list for holding a TileData object for each tile or to just implement it using custom gameobjects.

Or possibly attaching a script holding that data to the objects sprite tile generates somehow?

Any thoughts?

 

You could easily use the trigger value for that, and use GetTrigger and SetTrigger to get and set the health (with the limitation that the health number must be between 0 and 255). The trigger is really just an arbitrary number that you can use for anything.

That definitely won't work because the objects generated are part of a pooling system that aren't related to the actual tiles (except temporarily). If you don't want to use the trigger value for whatever reason, then the best option would be to make your own 2D array that's the same size as the level, where each entry in the array corresponds to a tile.

--Eric

 

A few questions,

1. Does this support collisions with Unity 4.3's box colliders?
2. Is there a way to ignore collisions (like having one way colliders)?
3. Does this ignore hidden edges (so that a collider moving over tiles won't "clip" and get stuck between tiles)?

I've built a lot of my game under Unity 4.3's system, and my current problems have no hacky workarounds, so I'm desperate to keep the work I've done thus far. A lot of my code uses 4.3's box collider's bounds, collisions, triggers, etc., so it'd be a life saver if SpriteTile integrated with this.

Thanks.

 

No, it uses polygon colliders, but box colliders are just polygon colliders under the hood anyway. So if you have a collider in the shape of a box, it's basically the same thing as a box collider. Depending on what you're doing, though, you may not need any physics colliders at all, and can use the collider attribute of a tile instead. Under this system, a tile is considered either passable or not, so it's sort of like a box collider.

Although if you mean do the physics colliders in SpriteTile collide with box colliders, then yes.

If you use the collider attribute instead of physics colliders, you can choose to ignore it under conditions that you define, so that would definitely work. If you're using physics colliders, you could use the physics layer collision matrix, and put your sprite on a layer that would ignore the tile colliders temporarily, then switch it back again, which would effectively do one way colliders.

As far as I know colliders don't get stuck between tiles; you can check out this demo and see for yourself. I don't do anything special with colliders, except that colliders are actually constructed from groups of tiles rather than having a separate collider for every tile, so that may or may not be having an effect. Also, you can also overlap tiles slightly if desired, which also means the colliders would overlap a bit, which could be beneficial too. (The demo doesn't do this though.)

--Eric

 

Thanks for the quick reply Eric! I thought up a few more questions, along with followups to your response

4. So this pools the tiles and only renders them as the camera nears them; does SpriteTile also do this for entities? For example, if there are enemies with AI scattered around the screen, is there a way to "attatch" them to your pooling system so that the AI isn't performed when it's not needed?

5. Are the levels saved in another file or something similar (that can be parsed and used in other frameworks/engines other than Unity), or is that under the hood or something and locked into Unity?

I'm a bit confused on what you mean by using collider attributes instead of physics colliders. If I use collider cells instead of physics2d colliders, will I still have access to things like Physics2D's raycasts (or something similar) and the Physics Layer matrix? I'll have to look into the collision matrix suggestion for one way platforms (I'm already using almost all of them; I have to check if I'll have space for another layer).

Awesome, I've been toying with my own importer to get the same effect, so if yours already bundles them then that's great.

 

No, that's something you'd have to do yourself; it's too game-dependent to have that built-in. A couple of common techniques are to use OnBecameVisible/OnBecameInvisible, or to use trigger areas.

It could be used in other engines if someone wrote an importer; the data isn't particularly tied to Unity. I could publish the file format specs if anyone's interested.

No; see here for a demo of the tile collider attribute. The player is prevented from entering colliders with this feature, rather than using physics, since tiles are declared passable or not passable.

--Eric

 

Thanks for clearing these up for me Eric. I'll have another look at your docs later, thanks for your time .

 

Hey there. I just bought this from the asset store, but it seems like there isn't any way to view gameobjects in the scene and the level at the same time. Is that correct? I really want to be able to place and edit enemies in the scene while the level terrain is visible. Otherwise making sure that enemies and other gameobjects get placed in the right spot is liable to become tedious and very time consuming.

 

Hello,

I guess you should use the «Editor Preview» functionnality.

 

Yes, the preview function will do what you want.

--Eric

 

Ah right, found it. Thanks.

I was going to ask about saving modified levels from a script, but I found one of your demos already has an example of doing so. I notice that you don't have a clear section for this in the documentation though (or if you do it isn't clearly listed in the contents). It might be worth adding a quick section under Coding Basics just to make it easier to find.

Edit: I may have encountered a bug. If I set a tile to use a default 'order in layer' other than 0, it doesn't show up when I go to draw it in the level editor. Am I overlooking something?

Edit2: Ok, it's definitely a bug, but it went away after I closed down unity and reopened it. Hopefully it won't happen too much, because that could get really annoying.

 

Sorry, didn't see your edits earlier. The order in layer thing is a bug, yes, which is fixed in the next version. Right now you can work around it without having to restart anything by first setting a tile in the level view to the desired order manually, so drawing the tile will work correctly.

--Eric

 

Forgive me if this feature already exists and I simply overlooked it, but it would be nice if you could specify which collision layer tiles use. I have separate collision layer for the ground than for other things (such as characters, event triggers, projectiles etc.). I have made a workaround where a script iterates through all the tile colliders and manually sets their collision layer to the ground layer and it works fine. It just isn't as elegant as might like.

Great product by the way.

 

Thanks! That's a good point about having a function to specify the collision layer, so I'll put that in the next version.

--Eric

 

Unfortunately I seem to be hitting another bug, and this one is rather more serious. When I transition to a new scene I get the following error:

MissingReferenceException: The object of type 'Transform' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object.
UnityEngine.Transform.get_position () (at C:/BuildAgent/work/d3d49558e4d408f4/artifacts/EditorGenerated/UnityEngineTransform.cs:27)
SceneManager.ForceUpdate ()

I am erasing the current level just before I load the new scene, and the new level is loaded in the Start() function of a script in the new scene. I am setting the camera to the one being used in the new scene before I try to load the new level, so I'm pretty sure it isn't referring to that.

 

I did actually fix a bug regarding loading new scenes for version 2.1. In the SceneManager script, both the LateUpdate and ForceUpdate functions should start with the same line, namely "if (camTransform == null) return;".

--Eric

 

Are you sure it is the same problem? It shouldn't be null. I'm explicitly setting the camera before I attempt to load the level. And the error occurs when the LoadLevel function is called.

 

Hi Eric5h5
does this now include the infinite scrolling mode? (player remains center of coordinates?) or is this feature still on the to do list

Looks like a great asset I didn't see before. Considering