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.
I have a confession: I trust Netflix more than my friends. When someone recommends a movie or a show, I check Netflix first to see my personal rating on Netflix. Basically, Netflix has solved the recommendation problem for television.
The Discovery and Recommendation Problem for Indie Games
The discovery problem for indie games boils down to this simple statement: Find games that a player is likely to finish.
(Note: I’m talking about single-player games that have a definite end. The discovery problem for multi-player games is VERY different from single-player games.)
Games have a bigger time commitment than television. Games can also have bugs, difficulty spikes or implement bad design decisions that force players to give up without seeing a game to its end. At the same time, players are more likely to recommend a game that they’ve finished.
A discovery system for indie games has to take all this into account and show recommendations that a player is likely to finish.
Obstacles to creating a Discovery and Recommendation system for Indie Games
- Classification is hard: Classifying indie games is hard. Indie games are still constantly innovating making it hard to classify them in any coherent fashion. Even if you can perfectly classify games, something like the graphical style might discourage you from playing a game all the way through to the end.
- Measuring time commitment: Unlike television, it’s impossible to determine the time commitment needed to finish a game. This depends on many factors including your skill level, whether you are willing to use walkthroughs, if you are a completionist etc.
- No database of indie games: The information on indie games databases like indiedb.com is not publicly accessible. On the other hand, in order for an indie game to get on Steam (which does have a public API), it needs to be greenlit. The end result is that there is no centralized database with information on all released indie games.
- Psychology might be more important: When Netflix sponsored a contest to improve their recommendation engine, there were two schools of thought: statistics and psychology. In the end statistics won over the psychology in improving the recommendations that Netflix provider. However we play and recommend games based on feeling a lot more than logic.
- Measuring engagement: Measuring engagement for Netflix is relatively simple. If you watch half of all episodes of a TV show, you’ve shown an engagement of 50%. Netflix can determine down to the second when you stop watching a show. How do you get this information for games? Do you have players rate their experience? Do you have developers implement a tracking API and if so, what’s their payoff?
- Non-standard experience: Bugs and glitches, difficulty spikes and other factors all make the game experience different for different people.
None of these obstacles are insurmountable, but they seem to be a lot harder than even when Netflix accomplished.
- How Netflix Reverse Engineered Hollywood
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.