GAME DESIGN // 2D PLATFORMERS| BUILD
IMPLEMENTATION TYPE THREE: BITMASK
This is Similar to the smooth tile-based apporach explored last month, but instead of using large tiles, an image is used to determine collision for each pixel. This allows finer detailing, but significantly
increases complexity, memory usage, and requires something akin to an image editor to create levels. It also often implies that tiles won’t be used for visuals, and may therefore require large, individual artwork for each level. Due to those issues, it is a relatively uncommon method, but can produce higher quality results than tile-based approaches. It is also suitable for dynamic environments – such as the destructible scenarios in Worms – as you can ‘draw’ into the bitmask to change the scenario.
HOW IT WORKS The basic idea is very similar to the tile (smooth) algorithm – you can simply consider each pixel to be a tile, and implement the exact same algorithm, and everything will work, with one major exception – slopes. Since slopes are now implicitly defined by the positioning between nearby tiles, the previous technique doesn’t work, and a much more complex algorithm has to be used in its place. Other things, such as ladders, also become trickier.
SLOPES Slopes are the primary reason why this type of implementation is very hard to get right. Unfortunately, they are also near- mandatory, as it would make no sense to use this implementation without slopes. Often they’re the reason why you’re even using this system. This is, roughly, the algorithm used by
Talbot’s Odyssey: • Integrate acceleration and velocity to compute the desired delta-position vector
(how much to move in each axis). • Step each axis separately, starting with the one with the largest absolute difference. • For the horizontal movement, offset the player AABB by three pixels to the top, so he can climb slopes. • Scan ahead, by checking against all valid obstacles and the bitmask itself, to determine how many pixels it is able to move before hitting an obstacle. Move to this new position. • If this was horizontal movement, move as many pixels up as necessary (which should be up to three) to make up for the slope. • If at the end of the movement, any pixel of the character is overlapping with any obstacle, undo the movement on this axis. • Regardless of the result of the last condition, proceed to do the same for the other axis. Because this system has no distinction
between moving down, whether you’re going downhill or because you’re falling, you’re likely to need a system counting how many frames it’s been since the character last touched the floor, for purposes of determining whether it can jump and for changing animation. For Talbot’s Odyssey, for example, this value is ten frames. Another trick here is efficiently computing
how many pixels it can move before hitting something. There are other possible complicating factors, such as one-way platforms (dealt in the exact same way as for tiled (smooth); see part one of this article in last month’s issue) and sliding down steep inclines (which is fairly complex and beyond the scope of this article). In general, this technique requires a lot of
fine-tuning, and is intrinsically less stable than tile-based approaches. I only recommend it if you absolutely
Talbot’s Odyssey, with the collision bitmask overlaid on top of the game, visble in dark red
IMPLEMENTATION TYPE FOUR: VECTORIAL
This technique uses vectorial data (lines or polygons) to determine the boundaries of collision areas. Although very difficult to implement
properly, it is nevertheless increasingly popular due to the ubiquity of physics engines, such as Box2D, which are particularly suitable for implementing this technique. It provides benefits similar to the bitmask
technique, but without major memory overhead, and using a very different way of editing levels.
HOW IT WORKS There are two general ways of approaching the vectorial method: • Resolve movement and collisions yourself, similar to the bitmask method, but using polygon angles to compute deflection and have proper slopes. • Use a physics engine (For example Box2D)
DEVELOP-ONLINE.NET
Obviously, the second is more popular (though I suspect that Braidwent for the first), both because it is easier and because it allows you to do many other things with physics in the game. Unfortunately, in my opinion, one has to
be very careful when going this route, to avoid making the game feel like a generic, uninteresting physics-platformer.
COMPOUND OBJECTS This approach has its own unique problems. It may suddenly be difficult to tell whether the player is actually standing on the floor (due to rounding errors), or whether they are hitting a wall or sliding down a steep incline. If using a physics engine, friction can be an issue, as you’ll want friction to be high on the foot, but low on the sides. There are different ways to deal with
those, but a popular solution is to divide the AUGUST 2012 | 69
The bitmask approach allows finer detailing, but significantly increases
complexity, memory usage, and requires something akin to an image editor to create levels. It also often implies that tiles won’t be used for visuals, and may therefore require large, individual artwork for each level.
Rodrigo Monteiro, Bossa
Worms World Party, featuring destructible terrain as part of its dynamic environments
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60 |
Page 61 |
Page 62 |
Page 63 |
Page 64 |
Page 65 |
Page 66 |
Page 67 |
Page 68 |
Page 69 |
Page 70 |
Page 71 |
Page 72 |
Page 73 |
Page 74 |
Page 75 |
Page 76 |
Page 77 |
Page 78 |
Page 79 |
Page 80 |
Page 81 |
Page 82 |
Page 83 |
Page 84 |
Page 85 |
Page 86 |
Page 87 |
Page 88 |
Page 89 |
Page 90 |
Page 91 |
Page 92 |
Page 93 |
Page 94 |
Page 95 |
Page 96 |
Page 97 |
Page 98 |
Page 99 |
Page 100