In a traditional isometric RPG, switching sprites is pretty simple: If the character is moving south, show his face; if he’s moving north, show his back. That works because the player’s point of view is always from the same direction. But what happens when the player’s view is arbitrary? When the camera can face any direction, choosing the right sprite suddenly becomes a lot more complicated. For Himeko Sutori, I had to invent a few new techniques for putting a sprite on a surface:
- Utilizing sprite sheets in a game engine not meant for character sprites
- Always turning the sprites toward the camera
- Choosing the right sprite based on character direction and camera direction
- Layering the sprite sheets for modular characters
Any one of those can be a story all on its own. For the truly curious, you might have to wait until I release my source code with the Himeko Sutori campaign builder. But for now, I’ll just show you some more of Himeko Sutori’s materials and try to explain what’s going on, focusing on number 3, which was really the most challenging of the four tasks.
Let’s start by explaining this material:
The UDK material editor lets you use vectors as a convenient way of storing three numbers. (There can actually be more or less than that, but let’s just say three for now.) Usually, you use those three numbers to represent red, green, and blue values. The vectors (0,0,1) and (1,0,0) could be used to represent blue and red (and that’s why those boxes at top-right show up as those colors), but here I’m using them to represent directions.
I find the object’s front/back and right/left directions with a vector transformation of (0,0,1) and (1,0,0). Then I find the direction from the camera to the object with a simple vector subtraction, and then I take a dot product, relative camera direction with the object’s front direction, and relative camera direction with the object’s side direction. The absolute value of the dot product tells me whether the camera is more closely aligned with the front/back or right/left. Then I check to see whether the dot product is positive or negative, to decide between showing the front or the back, or between the left or the right.
(If you’ve got all that, then you’ve got the chops to be a game programmer or technical artist. If not, don’t worry. I’ve done the work for you and after you’ve built a few Himeko Sutori campaigns, you can move on to tougher assignments.)
Then you take all of that material from above, and you combine it with some more nodes that divide up the sprite sheet, and choose the appropriate row and column from the sprite sheet…
And you’re almost there. But there is one problem that has to be fixed in code, and there’s no solution–as far as I can tell–that can be applied using only the material editor. The problem is that in item number 2 listed back at the top, “Always turning the sprites toward the camera,” we mess up the vector transformations. Although the character in the game might be facing a certain direction, his sprite is always facing the camera. The solution to that is performing the red and blue transformations in the character’s code, and sending the results to the material as a parameter. And when you’ve done that, you have sprites that change automatically based on camera direction and character facing: