Oversized Tiles Discussion

[clintbellanger]

Discuss a better way of implementing oversized tiles. If done properly it can make mapmaking and display easier.

First, add explicit support for oversized tiles in tile sets. Right now it's assumed that tiles occupy a 1x1 grid area. Tile definitions should allow defining a tile as a specific WxH grid size.

Move collision info to the tiles themselves. For oversized tiles, allow seeing collision info for the entire WxH area.

With much more data being included per tile, we'll probably change the tile set data to look like this:

[tile]
id=#
size=w,h
frame=x,y,frame_duration
frame=x,y,frame_duration ##repeat for animations, 0 means display indefinitely
offset=ox,oy
gridsize=gw,gh
collision=data,per,grid,space

Example, let's say we have a standing torch that is animated.

[tile]
id=100
size=64,128
frame=0,512,3
frame=64,512,3
frame=128,512,3
frame=192,512,3
starting_frame=random ## optional, for animations that we don't want to be in sync
offset=32,112
gridsize=1,1
collision=1

Example, let's say we have a 4x4 floor tile that is a cliff edge.

[tile]
id=101
size=256,128
frame=512,1024,0
offset=128,64
gridsize=4,4
collision=2,2,0,0,2,0,0,0,0,0,0,0,0,0,0,0

The collision represents this kind of floor (2 is a pit, 0 is a walkable area)

2,2,0,0
2,0,0,0
0,0,0,0
0,0,0,0

Tall concave structures should still be broken into convex tiles for correct display order.

The map rendering algorithm will need to be changed. There is a pretty standard recursive algorithm that I think we'll use. The way it works:

• Have an array of bools to mark when a tile has been rendered
• The render function takes in a x,y,w,h area of the map to render. By default this area is big enough to fill the screen.
• When encountering an oversized tile, render the areas behind it first (up-left and up-right) by calling the map render recursively on those smaller subsections
• Treat normal sized creatures as 1 tile larger than they are for rendering order purposes. E.g. the hero can be treated as a 2x2 area (the nearest such area that fits), so that tile walls behind it are always rendered before the hero is rendered. This would fix issues of the hero clipping behind thin walls. A large 2x2 creature might be treated as a 3x3 tile. Etc.
• Oversized tiles should probably be anchored to their topmost corner, for purposes of this algorithm.

Possible issue with this, I doubt Tiled by default would display these oversized tiles in the correct z-order. Maybe that's not a huge deal for map-making, as long as it looks correct in engine?

[pennomi]

I'd definitely like to see something like this in practice. The thing that I would worry most about is breaking Tiled support. Maybe we could bring some of the Tiled devs in here to comment on what it would happen in such a case?

Also, probably a little better syntax on the multi-tile collision would be:

collision=2,2,0,0;2,0,0,0;0,0,0,0;0,0,0,0

Since our file parser recognizes ',' and ';' both as delimiting characters. You could even do a similar thing on the "frame" key, if that would be clearer.

[clintbellanger]

Closing this oversized tile issue. We can reference it later if needed, but breaking Tiled compatibility is not worth it. And oversized tiles are such a special case that it wouldn't make sense for core Tiled.