|
Part 1 of this article discussed some of the impetus behind moving our existing isometric engine over to Shockwave 3D, and discussed the basic theory behind scrolling games.
Sample Director 8.5 movie source is available for download in ZIP or HQX archive format (both files are approximately 1.2MB). If you have Shockwave 8.5, you can view the 3DISO engine (~185K).
2 Tile Engines and Scrolling Theory (continued)
2.2 Scrolling in Two Dimensions Simultaneously
Scrolling in two dimensions can, in some sense, be thought of as an extension of single direction character movement, with a mathematical structure of a slightly more rigorous base. Simultaneous scrolling technology has been around for a while now, with classics like Nintendo's Legend of Zelda and Sega's Phantasy Star Series (see figure 7) serving as an impeccable example of the genre. Indeed, most systems to this day operate on the following two principles:
- That the data structure that holds the center point stores with it information about the angle the character is heading, and
- That the engine has the capability to convert between the local (character) coordinate system and the Cartesian (screen based) coordinates.
Such systems are consistent with the Turtle Graphics methodology developed at MIT under Ableson [5], although they can be implemented through a variety of mechanisms.
 |
|
Figure 7: Phantasy Star I release date 1988. Originally released for the Sega platform, copyright 1988-2001 Sega® Corp.
|
Generally speaking, it is easiest to think of the movement of a character in a 2D scroller by using vector-based mathematics. Assume that a character has an angle (measured in either radians or degrees) and stores within itself an x and y value representing a position on the horizontal and vertical axis respectively. Also assume that the character stores within its structure a speed, or a number of pixels to be moved each frame. By using Pythagorean math, we can assign a vector of movement to the character of a magnitude equal to the characters' speed. By using the equation a2 + b2 = c2 the engine can calculate both the x and y component vectors that would equal such a movement. Then the engine will move the tile structures both -x and -y, to give the illusion that the character moved in a positive direction (see figure 8).
 |
|
Figure 8: Moving in 2 directions where the eventual tile translation is equal to -1 * sqrt(Character X momentum (A) * Character X momentum + Character Y momentum (B) * Character Y Momentum). Note that the perpetual use of the sqrt() function is classically slow.
|
The use of the square root function is particularly slow, and should be avoided in production code. Methods to avoid its use are plentiful in game programming literature, from classic line algorithms at the pixel level, to distance bounding based on the squared distance and co-ordinate conversions to single screen space, through the use of a lookup table. It is also possible to use the angle the character is facing to derive the new x and y location after a move, which is essentially the same idea as above in a slightly more compacted fashion, except that it uses the cos and sin function which, while still generally regarded as slow, may be faster than sqrt on many systems. Depending on the performance requirements of the game you are designing, it may be that using sin and cos in your environment is not an option, just as it may also be the case that such a use is exceedingly trivial. The code to derive the delta-x and delta-y in the Director environment is outlined in figure 9, which is based on the early work in character movement at the Rochester Institute of Technology [6], which is based again in part on Ableson [7] as well as others.
|
--assume degrad = 3.1416 / 180
on move me
x = x + cos(degrad * angle) * speed
y = y + sin(degrad * angle) * speed
-- check for moving more than a tile width
-- or moving more than a tile height
-- move tiles -x, -y
end
|
|
Figure 9: Code Listing for 2D Scrolling Character Movement in Lingo Environment. Originally derived by Kurtz, see [6] for details.
|
Special attention must also be paid to the "wrapping" of the tile, or knowing when to shift the indices into the map lookup functions. The code must now catch the possibility that not only will the character move past the tile size from left to right (x axis) and top to bottom (y axis), but the possibility that if the character is moving at an angle, both of these conditions will be true. An un-optimized version of such a bounding mechanism is presented in figure 10, where rx is equal to the current x value of the character in screen coordinate space, ry is equal to the current y value of the character in screen coordinate space, gTileSize is the length of one edge of a square tile in pixels, and halfTileSize is one half that value.
if rx > halfTileSize then
x = x - gTileSize
gCurrentPosX = gCurrentPosX + 1
if ry > halfTileSize then
y = y - gTileSize
gCurrentPosY = gCurrentPosY + 1
else if ry < -halfTileSize then
y = y + gTileSize
gCurrentPosY = gCurrentPosY - 1
end if
else if rx < -halfTileSize then
x = x + gTileSize
gCurrentPosX = gCurrentPosX - 1
if ry > halfTileSize then
y = y - gTileSize
gCurrentPosY = gCurrentPosY + 1
else if ry < -halfTileSize then
y = y + gTileSize
gCurrentPosY = gCurrentPosY - 1
end if
else if ry > halfTileSize then
y = y - gTileSize
gCurrentPosY = gCurrentPosY + 1
if rx > halfTileSize then
x = x - gTileSize
gCurrentPosX = gCurrentPosX + 1
else if rx < -halfTileSize then
x = x + gTileSize
gCurrentPosX = gCurrentPosX - 1
end if
else if ry < -halfTileSize then
y = y + gTileSize
gCurrentPosY = gCurrentPosY - 1
if rx > halfTileSize then
x = x - gTileSize
gCurrentPosX = gCurrentPosX + 1
else if rx < -halfTileSize then
x = x + gTileSize
gCurrentPosX = gCurrentPosX - 1
end if
end if
|
|
Figure 10: Un-optimized bounding for square tiles in two Dimensions (this can be simplified to a 4 step case statement, and possibly further)
|
2.3 Parallax and Other Enhancements
It should be noted that straight scrollers (and to some degree Isometric engines as well) will benefit from the inclusion of certain visual enhancements to increase the realism of the scrolling illusion. First and foremost among these 'tricks' is to develop a system that approximates parallax scrolling, meaning that objects in the foreground will appear to move a greater distance than those in the background. This can be demonstrated by sitting in a car and driving along a road where you can see a great distance. Focus on a near object, like the guardrail of a freeway, and attempt to observe how fast it is "moving". Then focus on an object in the distance, near the horizon, and observe how fast it is "moving". Neither one is really moving in relation to the world, in fact you are, but the illusion of scrolling is based on the impression that you are still and everything else moves. As such, it must approximate the effect that parallax produces, namely objects in the foreground appear to move faster. This is generally accomplished by placing the graphics on different surfaces or planes and moving them independently.
It is also possible to produce a number of other effects on a 2D plane that emulate natural phenomena. Another common example would be camera perspective. This effect is in response to the fact that, in either a straight scroller or Isometric projection, objects in the foreground do not appear any larger than objects in the background. As this is one of the foremost visual clues that allow us to recognize depth in space, many other techniques are now of primary import, namely overlap (or z position), and shadow. However, some engines attempt to bend or skew the Isometric tile layout such that objects at the "bottom" use slightly larger tiles than those at the top. Usually, this involves drawing the standard projection to a buffer, then using an algorithm to "space out" the images towards the bottom before it is drawn to the screen. Other engines shift the pixels out from the character's position producing a "fish eye" perspective centered on the character. While none of these are mathematically correct, they can add realism beyond the projections implemented here, and should be considered depending on presentation style and performance capability assessment.
3 Isometric Landscapes
3.1 Derivation of the Isometric View
As game engines have become more advanced, engine designers have focused on creating the illusion of depth, or 3D, long before it was possible in hardware. This lead to countless experiments to simulate depth using traditional sprites, one of which was games based on systems similar to the first-person maze presented by this author in earlier research [1]. Another such 'perspective trick' is the Isometric view, which is derived as follows from the earlier work in top-down scrolling tiled environments. Assume that there is a camera in 3D space staring directly 'forward' on a tile, producing a square image on the screen (this can also be thought of as staring 'down' on a tile in top-down systems as shown in figure 11). Next, raise the camera up half the distance between the camera and the tile. This produces a perspective environment where a square tile will now appear to 'slant inward' towards the top in a trapezoidal fashion. Finally, the camera is rotated about the world center by forty-five degrees such that the corner of the tile is now facing the viewer. These viewpoint rotations produce, in 3D space, the view of a tile that matches the standard isometric diamond, where a tile is a perfect trapezoid whose width is two times the height, although by raising and lowering the camera other ratios are possible, and have been used to great success.
 |
|
Figure 11: Derivation of the Isometric View
|
Because the tiles can present 2 sides of the same object, it is possible to present objects in a way that realistically simulates 3D, although there are a few limitations. First, lighting is nearly always 'locked' to a given angle, often using a number of tile layers to achieve the effect by layering separate maps for the shadow elements (see figure 12). While this can produce remarkably realistic results, it is important that all elements be pre-shaded from the exact same angle, or the illusion is destroyed. Because the Isometric projection is parallel, or more formally an orthographic projection, it has no vanishing point (which is why all the tiles can be identical). This distorts traditional depth cues such as size or focus, which tends to be more and more disorienting the larger the view. There have been a few games that have modified the camera projection to bend this rule and alleviate some of the distortion [8], however it still does not approach the realism of a true 3D projection.
 |
|
Figure 12: Layered Iso maps for base, shadow, and object
|
Artwork provided by the author and Shawn P. Boyle, Information Technology Dept., Rochester Institute of Technology, College of Computing and Information Sciences.
All colorized Lingo code samples have been processed by Dave Mennenoh's brilliant HTMLingo Xtra, available from his site at http://www.crackconspiracy.com/~davem/
|