2D Toolkit has a powerful level (tile map) editor, but sometimes when you need to use a different format for tile maps like Tiled (.tmx) or you want to create randomly generated levels, you’ll find that you need to dynamically display the level from scratch. The game that I am creating called Pocket Tales uses Tiled and also creates randomly generated levels, so I had to figure out how to dynamically display a tk2dTileMap using the 2D toolkit. I’m not going to describe how to parse a Tiled (.tmx) file, but if you some example code on parsing a Tiled (.tmx) file, please take a look at TurnItUp, an open source library for creating turn based Roguelikes and RPGs that has basic support for Tiled files.
- Create an empty tile map in the editor with the maximum size that you anticipate your level being. Instructions on creating a tilemap in 2D Toolkit can be found here.
- Create an additional tile map in the editor for each tile set that your level uses. Note: 2D Toolkit’s tile map limit you to only one tile set per tile map.
- For each tile map create as many empty layers as you think you will need. Note: I use 4 layers in total for all my levels, one for the background, one for the obstacles, one for interact-able objects and finally the top most layer for the enemies and the player. This essentially means I create 3 layers for my first tile map which uses a tile set for the level graphics and 1 layer for the second tile map which uses a tile set for the enemies and the player.
Code to dynamically display level
I created two empty 2D Toolkit tile maps called BoardTileMap and CharactersTileMap with 3 and 1 layers respectively.
boardTileMap = GameObject.Find("BoardTileMap").GetComponent();
charactersTileMap = GameObject.Find("CharactersTileMap").GetComponent();
// Then use SetTile to dynamically set the tile based on the input format, whether it is another tile map format like Tiled(.tmx) or even randomly generating the level
charactersTileMap.SetTile(0, 0, 0, 1);
charactersTileMap.SetTile(3, 2, 0, 3);
// Finally call Build() on both the tile maps
- Overlapping tiles when using pixels per meter with a value other than 100 The tk2dCamera has a setting called pixels per meter. Sometimes you’ll find that you get overlapping tiles in the TileMap if you use a setting other than 100 pixels per meter. I just left this setting alone.
- Imported and displayed tiles are NOT the same color as the originals This is a problem with the way you’ve imported your tile sets into Unity. Take a look at the imported tile maps in the editor and make sure you adjust the import settings to get it to look right first.
- Tiles are blurry and not pixel perfect This is because Unity has applied a filter to your imported tile set, usually bilinear filtering by default. Click the original image used for the tile set and make sure that you set the Filter Mode to Point.
- Different tiles are being displayed other than what you expect Keep in mind that 2D toolkit’s tile ids start at 0 and 2D toolkit uses -1 to denote an empty tile. Other formats might use a different system. For instance Tiled uses 0 to denote an empty tile and tile ids start at 1.
- Level looks flipped or tiles are placed at the wrong location Keep in mind the origin of 2D Toolkit vs other formats. For instance the origin for Tiled is top left whereas 2D Toolkit’s origin is bottom left.
- My second tile map doesn’t seem to be displayed or seems to be displayed underneath my first tile map This is a sorting issue. There are various ways to get around this, but personally I found that using a separate sorting layer in Unity (introduced in Unity 4.3 specifically for 2D games) for the tile map that I needed to go on top worked well.
If you’re an experienced software programmer with experience in unit testing or you are developing a logic heavy game or reusable game engine, make sure you unit test.
If you’re new to programming and your game does not have much logic or is still in the rapid prototype phase, don’t unit test.
After a long hiatus of nearly 8 years, I’ve finally come back to game development. During that time, I was focused on developing web applications with Ruby on Rails.
One of the side effects that I’ve noticed when programming in Unity is that I crave Test Driven Development. During my stint as a Ruby on Rails developer, I got used to writing the tests first and then writing the code that passed those tests. There’s something about TDD that scratches a personal itch of mine. I did some research and concluded that TDD is not practical for Indie Game Development. However unit testing is a a very viable option in Unity.
Unit testing might be right for you if:
- You’re an experienced software developer: If you’ve worked with unit testing before and know how to write maintainable unit tests, unit testing is right for you. Keep in mind that decoupling the logic of your game is especially important in Unity if you want to write maintainable unit tests. You have to know how to use mocking and dependency injection to decouple your unit tests from other systems in order to write true unit tests.
- You’re developing a logic or AI heavy game: If your game has a lot of logic or a complicated AI, you can save a lot of time and effort by using unit tests. Unit tests make is simple for you to setup different situations for your AI and then test out how your game logic or AI reacts to each situation. You can fine tune your AI without ever having to create a complete level in your level editor and then running the game until the point where you can view how the AI acts on screen.
- You’re developing a set of games in the series: If you’re breaking your game up into a trilogy or chapters, unit testing will definitely help you create a maintainable engine for your series.
Unit testing might NOT be right for you if:
- Unity is your first programming rodeo: If you’re new to the world of programming, Unity is an especially hard system to learn unit testing on. The Unity MonoBehaviours are untestable and you’ll see an error “Security Exception : ECall methods must be packaged into a system module” if you try to instantiate any Unity MonoBehaviours in your testing code.
You’re rapidly developing prototypes: If you’re building a prototype (you really should, you know), there’s little reason to create unit tests. Look, unit tests are great, but they require time to write and maintain. You need to trust your unit tests and if you’re constantly rewriting all your unit tests because you’re radically redesigning your game, you’re going to burn out.
- Your game depends on a graphic, audio or user interface hook: Unit testing elements like graphics or audio is wasted effort for most indie developers. Unit testing is better suited to testing logic and flow.
The short answers are yes and no respectively. It’s possible, but not worth it for most indie developers.
Keep in mind that I am not talking about Unit Testing which has its place in any Unity project. What I’m talking about is adopting the philosophy of Test Driven Development (TDD) for the entire life cycle of developing a game. This philosophy is just not worth the effort for Unity projects.
Three Reasons to not pursue TDD in Unity
In my day job, I primarily develop web applications in Ruby on Rails. Web applications (especially those written in Ruby on Rails) are unique in that an extensive infrastructure has been developed to enable TDD: unit test frameworks, integration test frameworks, test runners, continuous integration services and more. Also, what’s unique is that there is actually some consensus in the Ruby on Rails community on which tools to use.
- Lack of tools for Unity: There is almost nothing like the Ruby on Rails TDD infrastructure for Unity. Take a look at this forum post: http://forum.unity3d.com/threads/8809-Test-Driven-Development. There is no consensus on even which unit testing framework to use. UUnit which is mentioned in the post seems to be abandoned and the documentation for what does exist is pretty sparse.
- The solution is pretty complex: In order to implement TDD for Unity, you need to implement a Model-View-Controller (MVC) framework and Dependency Injection in your project. If you’ve never heard of Dependency Injection or even MVC before, that’s already a good reason to be concerned. This is a lot of programming background you require to get started with TDD.
- ECall methods must be packaged into a system module: It seems to be impossible to create a Unity class in your test code. This isn’t really a problem for creating unit tests. The classes you design should interact with Unity game objects as little as possible. But when you adopt TDD, you need to be able to create Unity objects to test the code fully.
As an indie developer, you need to prototype your game quickly. Adopting TDD in Unity creates a ton of hurdles that you cannot afford to jump through. Pragmatically unit testing your code is a much better use of your time.