{"__v":32,"_id":"55917cfd4e50b50d001960eb","category":{"__v":8,"_id":"543b9b0065bf840e00b473d9","project":"543b9b0065bf840e00b473d5","version":"543b9b0065bf840e00b473d8","pages":["543b9b0065bf840e00b473db","5488547ff291f61400c02bfd","548909a4c178b40b00aa307d","548a68631bd6c40b00f77733","548eb5afe52d2b0b001b9a20","55079db843d3400d0052fd40","5507e16243d3400d0052fdee","55917cfd4e50b50d001960eb"],"reference":false,"createdAt":"2014-10-13T09:27:28.477Z","from_sync":false,"order":0,"slug":"documentation","title":"Documentation"},"project":"543b9b0065bf840e00b473d5","user":"543b9aa865bf840e00b473d1","version":{"__v":11,"_id":"543b9b0065bf840e00b473d8","project":"543b9b0065bf840e00b473d5","createdAt":"2014-10-13T09:27:28.467Z","releaseDate":"2014-10-13T09:27:28.467Z","categories":["543b9b0065bf840e00b473d9","543b9ef065bf840e00b473e0","54890012f291f61400c02d36","54890902f291f61400c02d3e","54890c43f291f61400c02d44","54890d71c178b40b00aa3086","5508125c0c4d8c19008a5f83","55094050961f17170070abbd","550945111c38c50d006118ad","550a4c2e42fff40d00ae6049","55221c074801a40d00a77610"],"is_hidden":false,"is_beta":false,"is_stable":false,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"createdAt":"2015-06-29T17:14:37.909Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"order":1,"body":"This is a brief overview of the entirety of the graphics behind a 2d game. You'll come across these terms quite often throughout the use of the kit as well as the documentation.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"1. Sprites\"\n}\n[/block]\nAny 2d image used in 2d games is called a Sprite. They can be either **static**(in case of buildings, trees and other objects) or **animated**(in case of a player or enemy character).\nYou'll be working with 2 things throughout the use of this kit with **2d Toolkit**:\n**1. Sprite Collection**\n**2. Sprite Animation**\n\n**Sprite Collection:**\nA **Sprite Collection** is simply a collection of images stored within a Sprite editor. It is a part of 2d Toolkit and can be created by simply right clicking and going to **Create>tk2d>Sprite Collection**. Like so:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/ir3VrAbTju0uCpfYRWNw\",\n        \"Untitled.png\",\n        \"723\",\n        \"909\",\n        \"#3a7c75\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nIt is not only used for say a set of images(like a group buildings that follow a theme) but it's also used to create a collection of images that are part of an **animation**.\n\nSay for example you have a **2d character** with a **walk animation** of **30 frames/images**. To use them within the kit, you must first add all of these frames within a new **Sprite Collection**. **Sprite Collections** can also have multiple sets of animations, making sure that they are numerically named in proper sequence. For example:\n**Walk Animation File Names:** ManWalk**0**01 to ManWalk**0**30\n**Run Animation File Names:** ManWalk**1**01 to ManWalk**1**30\nNotice that in this example, both animations have **30 frames/images** but the 1st digit of the 3 are different(for walk it is 0, for run it is 1). This **file naming scheme** is important as it'll allow you to automatically input the frames for animation(discussed later in **Sprite Animation**).\n\nThese **collections** can also be referred to as **atlases** throughout the documentation. They are also called within scripts whenever a **Sprite** needs to be called. In these docs, folders are specified where each category of **Sprite Collection** are stored and scripts have access to all **collections** used throughout the kit and can call **Sprites** by names from within their respective **collection**. Both **Collections** and the **Sprites** within are called from their respective drop down menus on the scripts. Like so:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/5UOLaMf2Sxq8WABhaoBH\",\n        \"Untitled.png\",\n        \"415\",\n        \"385\",\n        \"\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nHere is an example of a **Sprite Collection** of the buildings within the kit:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/0O9xvVoJQGLcCoSLCSIY\",\n        \"Untitled.png\",\n        \"1666\",\n        \"964\",\n        \"#a03c23\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nTo **import**, simply drag in the collection of images from the **folder** under the **Projects** folder navigation panel into the **Sprite Collection** you created and then click on the **Comit** button located on the top right corner of the **Editor window**.\n\n**Sprite Animation:**\nTo Create:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/Ise0Zm1WS8adJLgJiav5\",\n        \"Untitled.png\",\n        \"709\",\n        \"899\",\n        \"#3b5f63\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nAs discussed above, **Sprite Animation** is a collection of a set of **frames/images** named sequentially. This **collection** is called from a **Sprite Collection** of sprites.\n\nToo many **Sprites** and **Collections** in one doc!\nLets get a little technical:\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://www.filepicker.io/api/file/S9ukiTy2TQe8oVV8W8Cn\",\n        \"Untitled.png\",\n        \"1671\",\n        \"965\",\n        \"\",\n        \"\"\n      ]\n    }\n  ]\n}\n[/block]\nThe red arrow in the image above is pointing to a **Create** button on the top left corner of the **Editor** window for a **Sprite Animation** file. Clicking it will show two options: **Clip** and **Copy**. They are as they sound, clip lets you create a new clip of an animation from a collection and copy copies the clip.\nA clip is selected to show you what options are available. You may assign a name for the animation clip, for example: **ManWalkE** where E stands for East since every **character/unit/creature** animation needs to be set in 8 different directions: East, West, North, South, North-East, South-East, South-West and North-West so that he can be shown to traverse the 2d **Tile Map** in all directions.\n\nThe **Speed** of the animation can be controlled either via **Frame rate** or **Clip time** which are both available on the right side panel whenever a clip is selected. Adjusting one of these parameters will automatically change the other to make the math work.\n\nThe **Wrap Mode** will decide whether the animation will be **looped** or **played once** along with other options. You may playback your animation and it'll play in repeat which allows you to adjust the parameters in **realtime** and view the change which is highly productive.\n\nThen you have the **Collection** and **Sprite** drop down menus whose functions should be perfectly clear to you by now. They'll allow you to **call** your collection of images for the **clip** you are trying to make.\n\nFinally you have the **autofill** button which was discussed in **Sprite Collection** where correctly named sequences of frames will be filled in automatically for the clips which saves a lot of work load.\n\nThat wraps up the first thing you should know which are **Sprites**. If you wish to learn more, **Google** and **Wikipedia** have chunks of info on the topic. But the info discussed here will help you get started with this kit.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"2. Tile Maps\"\n}\n[/block]\nTile Maps are basically the **land** on which everything from objects to buildings to characters stand on. It can be the grass, sand or even the ocean. They are created via small tiles that are each Isometric in shape and follow a fixed dimension set for each image used with a tile. It's a very good idea to use the same dimensions for all of your tiles since they will be painted side by side and one would not desire \"holes\" in the middle of their map.\n\nThe 2d Toolkit has the ability to paint out such maps with tiles at ease and render them with maximum efficiency for mobile gameplay. With fairly a small collection of sprites/tiles, one can generate different lands/maps. **Static Objects** such as trees, rocks and other plantation are separate from the tilemap layer and are created differently, discussed on the Add Objects to Map page. They are much like buildings with their own collider set.\n\n**Why do we use tiles instead of a large image of the whole map?**\n**Isn't that more efficient?**\n\n**Short answer:**\nOh Dear Lord...no...\n\n**Long technical answer:**\niPhones/iPod Touches/iPads all have a Unified Memory Architecture which mean that both the CPU and GPU share system memory. There is no dedicated video memory and so a tiled environment is used over a pre-rendered, high quality image because a single 1024x1024 px ARGB32 Texture2D can use up to **4-8MB** of memory.\nOur island tile map example has a size of 17920 x 25340 px, each tile has 256x181 px. So without using tiles, a lot of memory would be consumed by the map alone. But with tiles, the source image of the entire base environment layer is a single 1024 px image, and the tiles are diced to reduce the total size of the image atlas/sprite collection. This is discussed once again with proper images on the 2D Graphics Manual page under the section **Mobile's Limited Memory & Efficient Tiling**.\n\nThis topic was just to give you a small preview. The creation of Tile Maps is discussed in great detail on the terrain page.\n\nEach set of sprites exist on their own separate layers in order to properly show characters in the foreground/background and layering is discussed in better detail in the topic below. Tile Maps usually always stay at the bottom most layer.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"3. 2d Layers & Colliders\"\n}\n[/block]\n**2d Layers:**\n2d Layers are much like the layers on graphics editing programs like **Photoshop** or **GIMP**. If you have not used graphics editing software then simply put:\nImagine a piled stack of transparent papers. Each one has a different image painted on it. Lets say the paper at the bottom has the background of grass, the one above it has trees, then the one above has rocks and so on and so forth.\nWhen one would look from the top of this piled stack, the full image would be visible. This is exactly how 2d Layers work in this kit as well as pretty much all 2d games. 2D means each layer has the x and y dimensions but additionally they possess a Z depth value which takes into account the foreground and background definitions when these layers overlap, for example a character walking behind a building or tree.\n\nUsually objects like trees and rocks have a large collision area around their front as opposed to their back so that a moving character cannot step too close to the tree when in the foreground such that they overlap but will be able to travel behind the tree. More on colliders is discussed below. This makes life simple when placing tree or rock objects as we only need to make sure its Z depth is higher or it's in a more elevated layer in contrast to the characters(whether playable or enemy) so that it appears infront of the character at all times since we only need to worry about the background. But in case these objects aren't just on the sides of the map but also around the middle area, they too can be spliced to a top and bottom half to allow proper foreground/background viewing.\n\nSo the **million dollar queston** is, how does this work when it comes to buildings where the character is able to appear both infront **and** behind buildings or construction sites?\n**Magic? Witchcraft? Complex scientific math?**\nNone of the above.\nIt's as simple as a **cutoff region** within the building or any other large object that needs to be able to show characters both infront and behind it. You will find details on how this is done when you create your own buildings which is dicussed under **Player Village>Replace Static/Animated Buildings** section in the documentation.\nSo how does this work?\nA **building** will be cropped into a **top** and **bottom** portion.\nThe **Top** portion will be elevated to a Z depth which is **above** that of the **character layer** so that when they overlap, the characters appear behind it.\nThe **Bottom** portion will be, you guessed it, at a Z depth **below** that of the **character layer** so that the characters may appear infront of it when overlapping occurs.\n\nThis **cutoff region** is best determinded by the maximum height of the playable character and the colliders that will be surrounding the building to ensure the character does not set foot too far in or get too close to the cutoff region. There are preset values within this kit so there is nothing to worry about and all this talk of cutting off buildings may seem difficult, but it's not. The instructions are very detailed and the cutoff happens through code and in most cases do not even need to be touched since using default building sizes like those in our kit will allow your own building prefabs to work out of the box.\n\nOnce you begin making your own building prefabs, all of this will become a lot clearer. This is to give you a taste of how things work.\n\n**Colliders:**\nCollision is just as it sounds and you have probably come across this term in games. In the old days of gaming, it used to be this invisible wall you hit while playing and now it's as sophisticated as a message popping up when you're close to a collider that asks you to turn around as you cannot go further.\n\n2d Games also rely heavily on collision. The colliders are applied on the tiles and this is very important since the kit uses scripts that have AI to create paths which avoid tiles that are obstacles/collidable. When a single tile is set to be a collider(by using an obstacle tag), characters will never be able to traverse over the tile and the path creator will never use these tiles to calculate paths to get to the location a player is trying to get to. The use of obstacles or colliders is important as an inefficient design can lead to characters not being able to properly traverse the map or even reach certain areas.\n\nColliders on objects like trees and rocks must be applied manually as maps will usually have them for decorations so having one attached to the prefab is not as efficient as creating a unique boundary of colliders for a specific location taking the aesthetics of the placement of the objects into account.\n\nColliders on building prefabs are automatically generated as the user will be able to tap and place them wherever the game will allow thus they need to fall properly on the underlying grid. This is achieved through the BuildingCreator script and all of it is automated so following the steps to achieve this will suffice. You will find more detail on this under the **Player Village>Replace Static Buildings** section in the documentation.\n\nHopefully this brief preview of these topics have been helpful and they are all discussed in more depth about their uses in the kit in other parts of the documentation.","excerpt":"","slug":"3-generic-things-to-know","type":"basic","title":"3 Generic Things To Know"}

3 Generic Things To Know


This is a brief overview of the entirety of the graphics behind a 2d game. You'll come across these terms quite often throughout the use of the kit as well as the documentation. [block:api-header] { "type": "basic", "title": "1. Sprites" } [/block] Any 2d image used in 2d games is called a Sprite. They can be either **static**(in case of buildings, trees and other objects) or **animated**(in case of a player or enemy character). You'll be working with 2 things throughout the use of this kit with **2d Toolkit**: **1. Sprite Collection** **2. Sprite Animation** **Sprite Collection:** A **Sprite Collection** is simply a collection of images stored within a Sprite editor. It is a part of 2d Toolkit and can be created by simply right clicking and going to **Create>tk2d>Sprite Collection**. Like so: [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/ir3VrAbTju0uCpfYRWNw", "Untitled.png", "723", "909", "#3a7c75", "" ] } ] } [/block] It is not only used for say a set of images(like a group buildings that follow a theme) but it's also used to create a collection of images that are part of an **animation**. Say for example you have a **2d character** with a **walk animation** of **30 frames/images**. To use them within the kit, you must first add all of these frames within a new **Sprite Collection**. **Sprite Collections** can also have multiple sets of animations, making sure that they are numerically named in proper sequence. For example: **Walk Animation File Names:** ManWalk**0**01 to ManWalk**0**30 **Run Animation File Names:** ManWalk**1**01 to ManWalk**1**30 Notice that in this example, both animations have **30 frames/images** but the 1st digit of the 3 are different(for walk it is 0, for run it is 1). This **file naming scheme** is important as it'll allow you to automatically input the frames for animation(discussed later in **Sprite Animation**). These **collections** can also be referred to as **atlases** throughout the documentation. They are also called within scripts whenever a **Sprite** needs to be called. In these docs, folders are specified where each category of **Sprite Collection** are stored and scripts have access to all **collections** used throughout the kit and can call **Sprites** by names from within their respective **collection**. Both **Collections** and the **Sprites** within are called from their respective drop down menus on the scripts. Like so: [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/5UOLaMf2Sxq8WABhaoBH", "Untitled.png", "415", "385", "", "" ] } ] } [/block] Here is an example of a **Sprite Collection** of the buildings within the kit: [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/0O9xvVoJQGLcCoSLCSIY", "Untitled.png", "1666", "964", "#a03c23", "" ] } ] } [/block] To **import**, simply drag in the collection of images from the **folder** under the **Projects** folder navigation panel into the **Sprite Collection** you created and then click on the **Comit** button located on the top right corner of the **Editor window**. **Sprite Animation:** To Create: [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/Ise0Zm1WS8adJLgJiav5", "Untitled.png", "709", "899", "#3b5f63", "" ] } ] } [/block] As discussed above, **Sprite Animation** is a collection of a set of **frames/images** named sequentially. This **collection** is called from a **Sprite Collection** of sprites. Too many **Sprites** and **Collections** in one doc! Lets get a little technical: [block:image] { "images": [ { "image": [ "https://www.filepicker.io/api/file/S9ukiTy2TQe8oVV8W8Cn", "Untitled.png", "1671", "965", "", "" ] } ] } [/block] The red arrow in the image above is pointing to a **Create** button on the top left corner of the **Editor** window for a **Sprite Animation** file. Clicking it will show two options: **Clip** and **Copy**. They are as they sound, clip lets you create a new clip of an animation from a collection and copy copies the clip. A clip is selected to show you what options are available. You may assign a name for the animation clip, for example: **ManWalkE** where E stands for East since every **character/unit/creature** animation needs to be set in 8 different directions: East, West, North, South, North-East, South-East, South-West and North-West so that he can be shown to traverse the 2d **Tile Map** in all directions. The **Speed** of the animation can be controlled either via **Frame rate** or **Clip time** which are both available on the right side panel whenever a clip is selected. Adjusting one of these parameters will automatically change the other to make the math work. The **Wrap Mode** will decide whether the animation will be **looped** or **played once** along with other options. You may playback your animation and it'll play in repeat which allows you to adjust the parameters in **realtime** and view the change which is highly productive. Then you have the **Collection** and **Sprite** drop down menus whose functions should be perfectly clear to you by now. They'll allow you to **call** your collection of images for the **clip** you are trying to make. Finally you have the **autofill** button which was discussed in **Sprite Collection** where correctly named sequences of frames will be filled in automatically for the clips which saves a lot of work load. That wraps up the first thing you should know which are **Sprites**. If you wish to learn more, **Google** and **Wikipedia** have chunks of info on the topic. But the info discussed here will help you get started with this kit. [block:api-header] { "type": "basic", "title": "2. Tile Maps" } [/block] Tile Maps are basically the **land** on which everything from objects to buildings to characters stand on. It can be the grass, sand or even the ocean. They are created via small tiles that are each Isometric in shape and follow a fixed dimension set for each image used with a tile. It's a very good idea to use the same dimensions for all of your tiles since they will be painted side by side and one would not desire "holes" in the middle of their map. The 2d Toolkit has the ability to paint out such maps with tiles at ease and render them with maximum efficiency for mobile gameplay. With fairly a small collection of sprites/tiles, one can generate different lands/maps. **Static Objects** such as trees, rocks and other plantation are separate from the tilemap layer and are created differently, discussed on the Add Objects to Map page. They are much like buildings with their own collider set. **Why do we use tiles instead of a large image of the whole map?** **Isn't that more efficient?** **Short answer:** Oh Dear Lord...no... **Long technical answer:** iPhones/iPod Touches/iPads all have a Unified Memory Architecture which mean that both the CPU and GPU share system memory. There is no dedicated video memory and so a tiled environment is used over a pre-rendered, high quality image because a single 1024x1024 px ARGB32 Texture2D can use up to **4-8MB** of memory. Our island tile map example has a size of 17920 x 25340 px, each tile has 256x181 px. So without using tiles, a lot of memory would be consumed by the map alone. But with tiles, the source image of the entire base environment layer is a single 1024 px image, and the tiles are diced to reduce the total size of the image atlas/sprite collection. This is discussed once again with proper images on the 2D Graphics Manual page under the section **Mobile's Limited Memory & Efficient Tiling**. This topic was just to give you a small preview. The creation of Tile Maps is discussed in great detail on the terrain page. Each set of sprites exist on their own separate layers in order to properly show characters in the foreground/background and layering is discussed in better detail in the topic below. Tile Maps usually always stay at the bottom most layer. [block:api-header] { "type": "basic", "title": "3. 2d Layers & Colliders" } [/block] **2d Layers:** 2d Layers are much like the layers on graphics editing programs like **Photoshop** or **GIMP**. If you have not used graphics editing software then simply put: Imagine a piled stack of transparent papers. Each one has a different image painted on it. Lets say the paper at the bottom has the background of grass, the one above it has trees, then the one above has rocks and so on and so forth. When one would look from the top of this piled stack, the full image would be visible. This is exactly how 2d Layers work in this kit as well as pretty much all 2d games. 2D means each layer has the x and y dimensions but additionally they possess a Z depth value which takes into account the foreground and background definitions when these layers overlap, for example a character walking behind a building or tree. Usually objects like trees and rocks have a large collision area around their front as opposed to their back so that a moving character cannot step too close to the tree when in the foreground such that they overlap but will be able to travel behind the tree. More on colliders is discussed below. This makes life simple when placing tree or rock objects as we only need to make sure its Z depth is higher or it's in a more elevated layer in contrast to the characters(whether playable or enemy) so that it appears infront of the character at all times since we only need to worry about the background. But in case these objects aren't just on the sides of the map but also around the middle area, they too can be spliced to a top and bottom half to allow proper foreground/background viewing. So the **million dollar queston** is, how does this work when it comes to buildings where the character is able to appear both infront **and** behind buildings or construction sites? **Magic? Witchcraft? Complex scientific math?** None of the above. It's as simple as a **cutoff region** within the building or any other large object that needs to be able to show characters both infront and behind it. You will find details on how this is done when you create your own buildings which is dicussed under **Player Village>Replace Static/Animated Buildings** section in the documentation. So how does this work? A **building** will be cropped into a **top** and **bottom** portion. The **Top** portion will be elevated to a Z depth which is **above** that of the **character layer** so that when they overlap, the characters appear behind it. The **Bottom** portion will be, you guessed it, at a Z depth **below** that of the **character layer** so that the characters may appear infront of it when overlapping occurs. This **cutoff region** is best determinded by the maximum height of the playable character and the colliders that will be surrounding the building to ensure the character does not set foot too far in or get too close to the cutoff region. There are preset values within this kit so there is nothing to worry about and all this talk of cutting off buildings may seem difficult, but it's not. The instructions are very detailed and the cutoff happens through code and in most cases do not even need to be touched since using default building sizes like those in our kit will allow your own building prefabs to work out of the box. Once you begin making your own building prefabs, all of this will become a lot clearer. This is to give you a taste of how things work. **Colliders:** Collision is just as it sounds and you have probably come across this term in games. In the old days of gaming, it used to be this invisible wall you hit while playing and now it's as sophisticated as a message popping up when you're close to a collider that asks you to turn around as you cannot go further. 2d Games also rely heavily on collision. The colliders are applied on the tiles and this is very important since the kit uses scripts that have AI to create paths which avoid tiles that are obstacles/collidable. When a single tile is set to be a collider(by using an obstacle tag), characters will never be able to traverse over the tile and the path creator will never use these tiles to calculate paths to get to the location a player is trying to get to. The use of obstacles or colliders is important as an inefficient design can lead to characters not being able to properly traverse the map or even reach certain areas. Colliders on objects like trees and rocks must be applied manually as maps will usually have them for decorations so having one attached to the prefab is not as efficient as creating a unique boundary of colliders for a specific location taking the aesthetics of the placement of the objects into account. Colliders on building prefabs are automatically generated as the user will be able to tap and place them wherever the game will allow thus they need to fall properly on the underlying grid. This is achieved through the BuildingCreator script and all of it is automated so following the steps to achieve this will suffice. You will find more detail on this under the **Player Village>Replace Static Buildings** section in the documentation. Hopefully this brief preview of these topics have been helpful and they are all discussed in more depth about their uses in the kit in other parts of the documentation.