#TileMath

[fevicrete]

How to calculate the number of tiles you need?

Calculating the number of tiles you need depends on the area you want to cover with tiles and the size of the tiles you plan to use. Here are the steps to calculate the number of tiles you need:

Measure the area: Measure the length and width of the area you want to tile using a tape measure. Record the measurements in either feet or meters.

Determine the size of the tiles: Decide on the size of the tiles you want to use. Common tile sizes include 12 inches by 12 inches, 18 inches by 18 inches, and 24 inches by 24 inches. Make sure to measure the size of the tile in the same unit of measurement as the area you measured in step 1.

Calculate the area of one tile: To calculate the area of one tile, multiply the length and width of the tile. For example, if you are using 12-inch by 12-inch tiles, the area of one tile would be 144 square inches (12 inches x 12 inches).

Convert the area to the same unit of measurement: Convert the area of one tile to the same unit of measurement as the area you measured in step 1. For example, if you measured the area in square feet, convert the area of one tile to square feet.

Divide the area of the space by the area of one tile: Divide the total area you want to cover by the area of one tile. This will give you the number of tiles you need. Make sure to round up to the nearest whole number to account for any waste or extra tiles you may need.

For example, if you want to tile a bathroom floor that measures 8 feet by 10 feet using 12-inch by 12-inch tiles, you would follow these steps:

Measure the area: The area of the bathroom floor is 8 feet x 10 feet = 80 square feet.

Determine the size of the tiles: You plan to use 12-inch by 12-inch tiles.

Calculate the area of one tile: The area of one tile is 12 inches x 12 inches = 144 square inches, or 1 square foot and 1/9 square feet.

Convert the area to the same unit of measurement: The area of one tile is 1 square foot and 1/9 square feet.

Divide the area of the space by the area of one tile: The number of tiles needed would be 80 ÷ 1.125 = 71.11, so you would need to purchase 72 tiles (rounding up to the nearest whole number).

[browndragon]

Liquid Tiles and State Machines

Hello again! I got stuck in a rabbit hole, but I had fun.

One of the things I built is strictly less fun than the other, so I'll lead with it even though it's not what you wanted. The other is the pretty video above.

State Machines

TL;DR: See https://www.npmjs.com/package/@browndragon/sm .

I got annoyed that the big state machines in javascript were too verbose for what I wanted, so I wrote my own. I think I've already written this post, but this time it's even better.

Each "state" (inconsistently called a node) is a function that returns another node. You load some initial node up in a state machine (here called Cursor). The Cursor invokes its current node whenever you call next (and whatever it returns is the next node). However! It's invoked in the context of the Cursor itself, so you get some interesting bells and whistles automatically: this.here is the current node, for instance -- normally it's hard to get access to that in javascript, but not so here. Since they're each function objects, they're less prone to object equality stupidity of certain sorts, and more prone to it of other sorts. There is no method to predeclare the set of states that exist, so your states can create states (by returning inner functions for instance). These are all features I thought I'd need ;).

You can write nodes that assume they're useful for their side effects, or nodes that assume you'll examine the state machine's here. Cursors implement the iterable & iterator interfaces, so you can use them in loops and such also.

However, for more power you need the full Machine (which extends Cursor). This does things like track state for every node (which is why the nodes are not called states...), with advanced features like history, traps (so that if a node returns undefined it can be rebound to actually go to handleUndefined()), and similar. This makes them O(n) in the number of nodes (and indeed, O(n) in the number of calls to next), but sometimes that's the featureset you need!

Give it a try. Or don't!

Liquid Tiles

TL;DR: The demo above, but the code isn't published anywhere [yet].

I kept playing with dough connected by springs, but I think I'd need to do tile deformation or shader tricks to make the dough look good. As written, the arbitrary offsets allowed glue tiles to shift, leaving gaps. Ensuring coverage would require stretching the tiles or having additional backing color. Or: a change in scheme.

Dough is just a really thick liquid, right? (Over a long enough timescale, aren't all solids?) So how would I model a liquid? I might do it with freely chosen blocks connected by links (the current dough system), but that would likely be too chaotic. Instead, I'd probably split the liquid up into regular domains and analyze each domain. So I did that! Liquid tiles are the result, a system similar-to but different-from phaser Tilemaps, but providing a similar grid-based interface to the world.

First, the data structure

I'm continuously at a loss for high quality datastructures, so instead I write my own low-quality ones. I needed a store of tile information -- unindexed integer 2-tuple keys, arbitrary1 values. Easy enough; I wrote a dense one which uses an allocated array of fixed size (so that array[y*width+x] is the value for (x,y)) and a sparse one which uses fully arbitrary (x,y) pairs and stores points under their stringification. As I write this, I realize that these data structures are not so very different in javascript, where arrays can arbitrarily allocate keys, but what's done is done.

I called the keys in this datastructure x,y tuples, but that's not entirely true: they're really u,v tuples; I wrote a little tilemath class to hold the geometry for mapping between an XY space (like phaser) into the UV space of the tiles (like the tilemap indices) and vice-versa. I am pretty sure it still has some ugly edge effects (tiles do nothing to fix the default anchor(0.5, 0.5), potentially favoring the top/left sides! etc), but it's functional by visual test. The naming scheme (xy space vs uv space) provides very sensible method names -- u(x) is pretty unambiguous. There's no obvious uv analogue to width and height, so I settled for uCount and vCount, which is what it is.

Second, a dip in the Pool

Obviously, we need a Pool of tiles (where tiles are just managed instances of Image, Sprite, or subclasses). A Pool is obviously a Group2, providing mechanisms to manipulate its managed contents -- putTileAt and removeTileAt for instance. But then the next question: what are you putting in these tiles; how are you passing the grid-based information which you need to pass to them into them? I say that Tilemap got this right, you're passing them a tileId (whatever your arbitrary first parameter to putTileAt is); I say that Tilemap got this wrong in that it knew that tileIds were lookups into arrays which were preregistered along with spritesheet geometry etc.

Everything else: mappings and shadows

Anyway: I created Conformers to address the problem of how to map tileId onto actual asset. Conformers are functions which take a tile entry (a gameObject, uv coordinates, tileId, maybe other stuff) and makes the game object conform with the other parameters. A simple one can setFrame(someTexture, someFrame) by just looking the tileId up in a big array; a more complex one might play(someAnimation) or do wangId calculations or whatever. This is also a great place to put state transition logic, since you can detect whether this conformation is a change from a previous state, or a put for a state that the tile was already in.

Okay! Now we're ready: since I know I want this to follow dough blobs around, and the doughblobs are acted upon by the rest of the physics system, I needed some ability to have a sprite "cast" an effect into the dough tile system. I called this a ShadowPool (which extends Pool extends AutoGroup extends Group). Every element of the shadow pool's WatchGroup casts a shadow into the pool made of tileIds; each tile's tileId the bitwise or of its place within the element's boundary (so for instance the upper left corner of an element's boundary is 0b0010, the bit for the lower right corner set.) That, at long last, is what the video above is showing, with fancy transition effects.

Next?

The animation of specific dough elements remains tricky; doughjiggle is still going to look bad under this new quantized regime, even as the interior of the dough looks better. But now I can emulate slugs, and spilled paint, and footprints, and other mass nouns without feeling like I've got to pay the cost of a full tilemap. Indeed, since tilemap layers render in one pass, using a pool even for walls might let me do the fabled "figure in front of bush & behind tree" 3/4 view I've been after this whole time. Certainly the ability to "layer" collisions by material type is very valuable to me, and missing from the current tilemap classes.

I'm now imagining a hybrid scheme: dough is drawn as nodules (free moving spheres of dough with weakly drawn borders) on top of a ShadowPool which draws the base of the nodule, thus the outline of the dough group (wang tiles with strongly drawn borders). Dough regions which quiesce could remove the nodule and mark the tiles from the shadow pool as "permanent", so that they can take over the nodule's mass. Animating the movement of the base can add more detail to this, since it can theoretically hide the quantization by masking portions of the tile and sliding it out in the (known!) direction of change. For instance, if the tile had been undefined and now has the bottom right set, it is clearly sliding in from the bottom right. This will cause slightly strange initial effects (of course), but edge effects are to be expected.

Fast moving dough would be represented as nodules (large borders). Slow speed dough would be thin-border nodules on top of a ShadowPool, sticking-and-unsticking the dough and an unstable equilibrium. Stopped dough would be pure ShadowPool entries. Dough spring would be provided via interaction with the shadowpool.

I mean, arbitrary at first. Obviously they're gonna be tiles. ↩︎

As an implementation note, each Pool is actually a singleton group; that's just more convenient to my way of thinking about these things. ↩︎