There are two ways this is done, because there are two major entities in the game. Everything in frogatto is either a tile, or an object. Objects can do pretty much anything, tiles are much more limited in what they can do (for example they can’t be animated) but are much easier to lay out on a map, and perform better (we have some special optimizations to spare drawing behind opaque tiles).
For both tiles and objects, there will be an image=filename.png
However, only objects specify a rectangular region. What tiles do, instead, is they use coordinates; it’s hard-coded to assume all tiles will be 16x16px (which may be something we can loosen up on). You tell a pattern which tile it uses (say, the 3rd tile down, and the 2nd tile to the right), and then it copies that whole tile.
It’s actually a coordinate. It’s two values, Y and X (in that order, which was a rare bit of pointless convention-breaking on dave’s part). The values are numbers, but in a really unusual twist, they’re not decimal (base 10), or hexadecimal (base 16) - instead, they’re base 36 (0-9, and then a-z; like hex, it counts from zero). There’s a good reason for this, which is that it means these coordinates will always be two letters - unless you’re using a ginormous texture bigger than 1024px in a given dimension, and … you both shouldn’t and can’t do that because we don’t allow more than 2 letters there.
You don’t need to anyways, because we have an automatic system to pull all of the textures out of the game, and “compile” them into a massive texture atlas that compacts them algorithmically (better than any human could ever hope to).
It does both. I think what you refer to by the former is what we call “multi-tile-patterns”; where we have a predefined image that spans several tiles, will only fit an exact pattern of underlying tiles (say, a corner), and can’t be cut into because it wouldn’t seam well with anything else.
What you refer to by the latter; where some modular tiles that would seam well with anything else happen to be laid down to form a complex shape, is what we call regular or “single” tile patterns.
We have limited support for larger patterns; I think we can also do 5x5, and have used it on a couple rare occasions. However, we’ve got a much more powerful and complicated concept called “multi-tile-patterns”, which I need to write a tutorial on. It’s rather unusual, and I’m not sure there are a lot of other games that use it - in fact it might be entirely a new innovation on our part.
There are regular expressions, although the ! may be unorthodox.
!, like in programming, means “NOT”. It means the tile must be “anything but” the type in question to match the pattern.
?, means that, to match, the tile must be either empty, or be the stuff in parentheses, to match. But it can’t be anything else.
Note that (following the rules of regex), these can be combined into groups; for example, a listing like (grs|grk|grb) means it has to be any one of those three (this is an OR operation). If you’re wondering, an “AND” operation is meaningless, since there can only be one tile per location on the map - at least, for that individual zorder.
Which leads to a fairly major point, which is that these tile-patterns only compare themselves within the same zorder. Our tiles are laid out in flat layers, and each layer is assigned a zorder which declared which go in front/back. Tiles will only be compared with each other to give them transitions inside the same layer.
[/URL]