Tiles at the edge

[Fyll]

Half of the reason for having the Edge and Bottom blocks is so that the blocks that are next to the edge merged off screen. What should happen if, say, you were to freeze the block that's at the edge? Should the frozen block merge with the off-screen block? Or should it still treat the off-screen block as if it were water?

Part of the implementation of BlockGroups was that edges were done by simply adding an extra block (one that's equivalent to the one next to the edge) just off-screen (which is why the block behind the entrance thinks it's just an air block, and you can walk through it). This method means that if you freeze some water by the edge, it won't merge.

Personally, I think the ice looks quite nice as platforms rather than necessarily stretching off-screen, but I'm thinking that their may be other things that we'd rather did (not that I can think of any off of the top of my head).

Thoughts?

[DivFord]

Only objection that occurs to me is that ice would essentially never end up more than a block high. I mean, you're never going to fire the ice wand from the sides or from below, so you'd only ever freeze the upper water blocks. Is that a problem? I'd have wasted some effort on the art, but I think I'd live :P

With regards to the "equivalent" block, how is that determined? It seems like calling the stone the equivalent of entrance blocks would solve the walking out the level problem.

[Fyll]

The BlockGroup needed it's own data (as it's an Object), so just copies the data from its first Block. Therefore, when the edge Block gets added to the air's BlockGroup, it effectively loses its identity (but not it's interactions) until it gets removed from the BlockGroup (such as by having all of the Blocks connecting it removed).

When I said "except interactions", I meant how, for example, if water tiles went next to the edge of the screen, you could freeze the water next to the edge, but (if you somehow smashed the ice) you wouldn't be able to freeze the edge Block, even though it thinks it's water. The reaction to being hit by the bullet gets passed through to the Block itself, and it's still an edge block.

More simply, when something asks a BlockGroup for information about one of its Blocks, the BlockGroup just pretends everything is a copy of its first Block. When something actually interacts with one of the Blocks, BlockGroup connects you to the Block in question.

RE: Only one Block thick Ice - To be honest, that seems like what you'd expect. I'm not sure how you'd freeze through more than one Block anyway. It is technically possible to freeze a water tile below you while underwater, without freezing the one you're in if you time it right. That'll look wierd anyway, and would need improved water physics (#45).

[DivFord]

Won't that be quite problematic, if, for example, the entrance is the first block in an area of air?

Are we maybe overcomplicating this? My solution in other projects has always been a CheckSame function which returns true if the queried block is outside the screen/map bounds, and otherwise returns true if the two blocks are equivalent, and false if they aren't.

[Fyll]

Nope, because the edges get added after everything else (specifically because of that worry, in fact).

The reason for putting the edges into the BlockGroups is because they only check other Blocks inside the same BlockGroup, so to allow them to merge with the edges, the Edges need to be inside the BlockGroup.