Click to enlarge
Requisite Scrolling Video (Xvid AVI, ~2MB)
The Skinny On Scrolling
The interesting thing about the scrolling method that I settled on is that it's not based on any sort of overall world coordinate system. World coordinates don't actually exist, the only true coordinate system is the screen coordinate system (with coordinates ranging from -16,-9 to +16,+9, for a delicious [and integer-tastic] 32:18 [2x 16:9] visible area).
So how does it work? Each level will be built out of tiles, in order. Each tile has the following data:
- A model to render
- Collision Data
- The Camera Path
The camera path for a tile is currently just an input position and an output position. That is, the position at which the camera ENTERS the tile, and the position at which the camera EXITS the tile.
Now, here's the trick: Say you have two of the same tile next to each other. Each has an input coordinate of (0,1) and an output coordinate of (4, 0). What the system does is it moves the second one so that its input coordinate is in the same spot as the first one's output coordinate. (that is, the second one's input coordinate becomes effectively (4,0) like the first's output coordinate and, relative to that, the second's output coordinate becomes (8, -1)).
However, actual world coordinates aren't strictly necessary, so whichever tile the camera is currently in is considered the "origin" tile. That is, it is used as the basis by which all other visible tiles get their on-screen positioning.
Thus, the setup is easy: figure out where on-screen (given the camera's position in the tile) the tile should display, then make all of the visible tiles to the left and right relative to that.
This is nice for a few reasons:
First off, if, for some reason, a level were RIDICULOUSLY long, I would never have to worry about accumulating floating point round-off error.
The big thing is this allows me to have what is essentially a staple of the shoot-em-up game (and is actually quite visible in the video posted above): an endless loop of background.
These loops are especially useful for when fighting bosses. Say you're zooming down a metallic corridor while scrapping with a boss that happens to be flying along with you. Rather than have to hope that the player finishes the fight before the camera hits the level's end, you can just rely on the fact that the corridor will keep on looping until something triggers the loop's end, signaling that the level should keep going (or end, assuming that there's no more to the level).
This triggering system is not yet implemented, and I hope to get it done this weekend (though I have a ton of other, smaller items on the to-do list, so it may have to wait for the NEXT weekend).
Proximity Alert
One design element that was tricky was signaling to the player that the ship is too close to a wall. The obvious metric is, of course, a shadow. However, standard shadows only cast in one direction, which would be great if all we cared about was distance to the floor. However, we really need "distance to any object." This looks like a job for the existing lighting system!
A new type of "light" was designed: essentially a black light, which has a center, a length, and a radius (thus, the actual light is more like a line light than a point light). Consequently, the fakey shadow from the ship will "cast" onto any surrounding objects.
Click to enlarge
And, once again, that's all we have time for on this week's episode of "What Did Drilian Do Last Weekend". Stay tuned next week, same Bat-Time, same Bat-Channel!
