Tiles Properties

From Staredit Network Wiki
Jump to: navigation, search

Here is an overview of the terrain example being used during this whole part:


One of the first thing you might want to know about the tiles properties is how they block units. That part is really important when you try to create a new blend (or simply when you try to do isometric terrain).

For this part, we'll use this image:


"What you see is not what you get." At start (see Main Image), people could think this blends gave enough space for a lot of units to fit in it, but as you can see, there are grey areas a bit everywhere. That's not a good thing and you'll see why.

When trying to place a unit in SCMDraft 2 (but not when you try to copy-paste one), there are two things you must check: these grey areas that appears and also that green (or red!) rectangular that surrounds your units. Let's start off with the rectangular: it represents the real amount of space the unit is taking in the map. As you can notice with an Archon (see Main Image), even though it fits within 1 tile, its image in itself is much bigger. To determinate if a unit can walk through a certain area, select this unit and try to move it from a certain point to an other point. As long as you'll be able to make it move between these 2 points without getting a red rectangular, it means that the unit will be able to walk through, but not always without any problems! We'll talk of these "problems" a bit later. On the other hand, we have the grey areas. When the rectangular surrounding a unit collides these areas, it becomes red. I guess you get what this means: grey areas are unwalkable areas.

Right over, we've talked about some "problems" you can meet regarding some blends and their walkability. One of the most known blend causing such problems is exactly this one:


Even when you check at the grey areas, it seems like a Zergling or even a Marine could easily walk through it, but in-game, Starcraft's path-finding AI makes it a bit different: the players might some times need to click at precise places to make their units move forward. Clicking at the wrong place could make it run back. These specific kind of blends aren't really recommended for games. Try avoiding them as much as possible. As an example, I've used a Defiler. While testing the collisions, I saw that the Defiler will never be able to walk through this specific blend.

Side-note about unit's sizes Talking of units' sizes, you might want to learn the size of some specific units (see Main Image): All the units shown at the bottom left have this "useful" size: 1 tile x 1 tile. Except the Defiler which is only used as an example through the example and the Ultralisk. Indeed, the Ultralisk is the only unit of Starcraft that is larger than 1 tile. Though this happens only horizontally. As you can see, he fits within 1 tile vertically.

Another example of "What you see is not what you get", but more flagrant is shown into this image:


When you were looking at the Main Image, you might have thought that this blend was walkable by very small units only, but it isn't walkable at all. In fact, even a 1 pixel unit wouldn't make it through. As you can see, the grey areas are linked and make it so you cannot pass from one side to another (by passing there) without getting a red rectangular.

Just as a second "side-note" about walkability, I'd like you to take a look at this image:


Now, what you see is the contrary. When looking at the Main Image, you may think a Defiler wouldn't pass that bush, but simply because what you see is a Sprite but not a Doodad, is it fully walkable and I guess 100% of the units could pass it. Anyways, that was just a quick note telling you sprites can also be used to something else than for "block coverage".

Now, an other important part of the tiles properties is the vision.

Terrain vision is a problem that terrainers somewhat rarely face. This is because most extended terrain blend within their own terrain height, or elevation. However, some tilesets can have blends that cross the terrain height line. For example, the top corner bridge tiles are used to blend high dirt to dirt in Jungle. Another bridge tile can also blend with the corners of a Temple. While these examples have stable Terran Vision, some do not. We'll be looking at a piece and analyzing its vision problems.

To check vision, you can either play it on a map or use the Preview Fog layer on SCMDraft2. You can refer yourself to the wiki about Fog of War for further information about this tool.


Now, let's use this blend as an example.


Blend wise, the piece is decent. Now let's view the vision from different angles.


The ghost on dirt cannot see the high terrain. This is stable vision.



On the cliff, you can see everything from any position as long as you're on the High Dirt elevation. This too is stable vision.


On the small bridge tile, the ghost can't see anything. This is because the bridge tiles are surrounded by High Dirt tiles, which are in different elevations. This is unstable vision.


The ghost, on dirt, cannot see the high terrain. This is stable vision.

You must be aware that vision blocks aren't only appearing when you are playing on a high ground's blend (literally). As soon as you use a high ground tile, you have possibilities of having vision issues.


Terrain elevation's theory is pretty simple: as long as you're on the same elevation, you see the terrain of the same elevation layer and the ones that are of a lower level of layer. For example, in Jungle, when a unit is on "High Temple", it can simply see any terrain around him. You can see a list of all the terrains' elevations at Terrain Type Elevations.

Creep/Null tile:

Those two tiles are also known for having weird behaviors. Read more at Null Terrain.

One of the Null tiles is walkable. That specific Null tile is the very first one to the right of the Creep tiles in SCMDraft 2's Tileset Index:


Though you must know one thing about it: units can walk from it to any other walkable tile, but the inverse is not right. If you try to walk from a Dirt tile to that Null tile, it will not work. That implies that you must create "move" trigger for this specific case.

Post Scriptum: Notice that during the whole article, I've only been talking about the blocking properties of groups of tiles, but you must be aware that even though this kind of knowledge is mostly applied to those, it takes its very source into individual tiles' properties.