Case study: glitched tiles
Posted: 2011.09.06 (19:51)
I guess this is the right place to post this.
Case study: glitched tiles
Disclaimer: these are the "true" glitched tiles, i.e. produced by tileset code. Something about the artifical NaN-trapdoor generated GTs will be added later if there's anyone interested in those.
Lately I was porting parts of N engine to JavaScript, and decided to use it to pursue some of the bugs of the engine and get to know better how they work. Since there is not much info about the glitched tiles (GT), I decided to start with them.
Preface
True GT is a tile with ID higher than those of "5" tiles. When a GT is initialised, the type identification code block is skipped to the last part, where it is assumed that it is a "5" tile, which is the cause for the glitched tiles to exist. The difference in the command flow from the "5" tiles is that the only properties that are set up are the general type and the sprite, which is set equal to "5Q" tile regardless just because it has the highest index in the bank. (The sprite, as you might have already noticed, does not depict any of the physical properties of the GT, it is just a confusing picture.) All the other properties are left intact, so if there was a tile, it's sx, sy, signx and signy are inherited by the glitch tile (more on that below). This results in existence of two major types of glitched tiles:
How to create a GT
Replace one of the symbols in the tile code with a symbol which code is higher than that of a uppercase Q (for example, it can be any lowercase letter). It doesn't matter which symbol you choose, the only requirement is stated above.
Now, how to create a certain type of glitched tile? There are three possible outcomes for the GTs in the second tileset, depending on the first tileset (the preloader):
Inner workings, exposed
First, let's get familiar with notation of the collision maps I made. Here are two legit tiles on a 3x3 grid, simulated and in-game:
Clean GT
Here's a collision map of a door, a "E" tile and a clean glitched tile:
The CGT has 8 corners: 4 like a E tile, and 4 in the middle of each side similar to door's edges. These corners, when approached from appropriate directions, work exactly the same way as the usual ones. But if you approach them from inside or from the side (anywhere where there is an edge between gray and color) you'll get propulsion in the direction of the corner, the higher gradient - the more propulsion. Also note that you can slip inside and out of the CGT unaltered through tiny openings between "force caps" and corners.
As you can see from white pixels, the game's AI does not discern between a E tile and a CGT, so you can sit inside/behind a CGT without drawing attention.
Dirty GT
A "1W" tile and a dirty GT:
This one has 2 edges connected by 3 corners which are exactly the same as on the other tiles. The other side of it, though, presents us a diagonally oriented forcefield with rather high gradient followed by an area of great force which kills N immediately on contact - that's why this type of GT is not very useful. An interesting thing about these is that the "filling" has the same orientation regardless of the tile's orientation, as seen below:
The "1" tiles and dirty GTs are the same from game's AI viewpoint.
Practical value of all this
none?
Case study: glitched tiles
Disclaimer: these are the "true" glitched tiles, i.e. produced by tileset code. Something about the artifical NaN-trapdoor generated GTs will be added later if there's anyone interested in those.
Lately I was porting parts of N engine to JavaScript, and decided to use it to pursue some of the bugs of the engine and get to know better how they work. Since there is not much info about the glitched tiles (GT), I decided to start with them.
Preface
True GT is a tile with ID higher than those of "5" tiles. When a GT is initialised, the type identification code block is skipped to the last part, where it is assumed that it is a "5" tile, which is the cause for the glitched tiles to exist. The difference in the command flow from the "5" tiles is that the only properties that are set up are the general type and the sprite, which is set equal to "5Q" tile regardless just because it has the highest index in the bank. (The sprite, as you might have already noticed, does not depict any of the physical properties of the GT, it is just a confusing picture.) All the other properties are left intact, so if there was a tile, it's sx, sy, signx and signy are inherited by the glitch tile (more on that below). This results in existence of two major types of glitched tiles:
- clean: fully symmetric, has 8 corners (it's not a typo, read on) and no solid edges nor body.
- dirty: diagonal symmetry (4 possible orientations), has 2 proper solid edges and 3 corners, the body is of a complex shape and doesn't have stable edges.
How to create a GT
Replace one of the symbols in the tile code with a symbol which code is higher than that of a uppercase Q (for example, it can be any lowercase letter). It doesn't matter which symbol you choose, the only requirement is stated above.
Now, how to create a certain type of glitched tile? There are three possible outcomes for the GTs in the second tileset, depending on the first tileset (the preloader):
- "5" tiles from the first tileset remain the same (Physically. The sprites always change to 5Q, remember?)
- empty ("D") or full ("E") tiles give clean GTs
- any other tiles give dirty GTs; the solid 90 degree corner present in the original tile remains in the same place - that's how you get 4 sorts of DGTs
Inner workings, exposed
First, let's get familiar with notation of the collision maps I made. Here are two legit tiles on a 3x3 grid, simulated and in-game:
- white pixels are placed where the function QueryPointvsTileMap returns true. That is, the game's AI (rocket, gauss, etc) thinks that those parts of tileset are solid (which is true for legit tiles).
- blue and black lines are tile edges. In the game there are three types of them: "off", "solid", and "interesting". Solid edges are shown as black, interesting as blue. Solid edges are most important: they're a certain obstacle on anyone's way.
- colored pixels show direction (hue) and strength (lightness) of the force which the game will apply to a ninja if her center happens to be in those coordinates. Use the outer walls' colors as a guide to determine direction easily.
- gray pixels are where ninja's movement is not affected by the tileset in any way.
Clean GT
Here's a collision map of a door, a "E" tile and a clean glitched tile:
The CGT has 8 corners: 4 like a E tile, and 4 in the middle of each side similar to door's edges. These corners, when approached from appropriate directions, work exactly the same way as the usual ones. But if you approach them from inside or from the side (anywhere where there is an edge between gray and color) you'll get propulsion in the direction of the corner, the higher gradient - the more propulsion. Also note that you can slip inside and out of the CGT unaltered through tiny openings between "force caps" and corners.
As you can see from white pixels, the game's AI does not discern between a E tile and a CGT, so you can sit inside/behind a CGT without drawing attention.
Dirty GT
A "1W" tile and a dirty GT:
This one has 2 edges connected by 3 corners which are exactly the same as on the other tiles. The other side of it, though, presents us a diagonally oriented forcefield with rather high gradient followed by an area of great force which kills N immediately on contact - that's why this type of GT is not very useful. An interesting thing about these is that the "filling" has the same orientation regardless of the tile's orientation, as seen below:
The "1" tiles and dirty GTs are the same from game's AI viewpoint.
Practical value of all this
none?