I wrote an article a few months ago about some methods independents are utilizing to develop games with a very limited amount of resources. Many of these ideas are things that we try to follow to develop Zero Gear in an efficient manner. The article just went up on Gamasutra, check it out!
The last week or so I have been taking a shot at re-doing our first player model for Zero Gear, the original model didn't sit right with a lot of people or me included. Luckily I stumbled into contact with Edwin Rhemrev, a concept artist in Rotterdam. We talked about how much we enjoyed kart racing games, and offered to do some concept pieces for us. He came up with a lot of differently styled and awesome looking characters. This is the one that I based my character model from. After a couple days of modeling I had the base model done that everything else would build upon.
Once this step is complete, I unwrapped and textured the body and head. This step involves some tricky and/or tedious work assigning how the flat 2d texture is wrapped around the 3d model. Luckily there are a lot of different tools to help you do this, just imagine trying to cut out a set of skin tight clothes out of a piece of paper for a doll, in a shape so that all the seams match up perfectly to fit the contours of the body. Sounds pretty tricky, doesn't it! These are the flat textures I created to wrap around my character
Now we have something that looks like a character, the next step is making him move like one.
To animate the character, I make a skeleton that fits the proportions of the body and has joints in all the proper places. Then I have to assign all the verticies to correct bones in the skeleton, and after that is done I can animate the bones in the skeleton to move in whatever way I wish and the body will follow. The entire animation process is something I have been learning as go, and it has filled me with a lot of respect for animators, as it is clearly a discipline to master in and of itself. Here is a screenshot of the program I use to animate the skeleton:
The animation is done using "key-frames" on a timeline. In a nutshell this involves moving something to a position and setting a "key" and then moving the same thing to a different position and setting another "key" farther down the timeline. Using this process, the animation between those two keys are filled in for you and the result is a smooth transition between the two positions. Here is a short video I created of some animations I created for this character.
There are still some additional steps to be taken to get the character into the game, but it is mostly complete at this stage. I will be following this same process to create multiple other new characters for the game. After finishing this guy, I posed him in a little scene and rendered out a poster-type image for fun. Click on the links to the right of the image for a number of different sizes.
This is a more technical post but don't run away!
When designing a game (or any application) we tend to want to separate the graphical user interface (GUI) from the game logic. A way of doing this is called Model-View-Controller (or MVC). Here is a summery of what this means:
MODEL: This is the code and data that controls your game. An example could be setting the color of the player.
VIEW: This is your GUI. An example is a GUI widget to select a color and a button to apply that color to the player.
CONTROLLER: This is what ties the MODEL and the VIEW together. It is some logic that takes the color selected from the GUI and applies it to the Player in game.
The reason for doing this is that is separates the MODEL from the VIEW. This means we can easily change the VIEW without changing the MODEL and vice versa by only changing the CONTROLLER. And most the time we don't even need to change the CONTROLLER.
Here is the way I am handling this:
MODEL: In C++ I have code that sets a player's color Player::SetColor(colorVal)
CONTROLLER: This is where Lua comes into play. Lua is the CONTROLLER that receives this event from the VIEW. The Lua code calls the C++ code Player::SetColor(colorVal) with the color from the event. This modifies the MODEL which changes the color of the player on screen.
It might seem complicated but it actually simplified things greatly and allows us to change one aspect of the game without affecting other things.
While Brian has been toiling away at the bolts and gears under the hood of our game to implement our networking system, I have been working on getting our environments polished up and in the game. While I was playing around with Ogre's fixed-function environment mapping features, I noticed a method of environment mapping listed that I had never tried out before, cubic_normal mapping. According to the manual: " Generates 3D texture coordinates containing the camera space normal vector from the normal information held in the vertex data." While that is pretty self explanatory, let me explain to you how it is different from most of the environment mapping utilized by Zero Gear. The environment mapping I use a lot to make things look shiny, simulates a cube sitting around whatever it is applied to. I basically use a black cube with a few white highlights around the top panel of the cube, and when applied to an object, a white highlight appears reflected as from the top of the scene. In this method, the cube is static. However, using this cubic_normal method, the cube that objects are reflecting is locked to the camera, so wherever you move around in the scene, the cube moves with you. An easy way to look at it, is one method the cube is a room you stand in, and the other method the cube is a box you wear on your head that moves around with you. This is significant becuase I can easily use this second method to simulate rim lighting. Since the environment map is locked to your view, it will always be facing in one direction, and you would just need to build a cube map that simulates a halo of light on all sides. Here is the cubemap that I came up with:
Here is a screenshot of what this environment map looks like applied to an object, with both the cubic_normal and cubic_reflection methods:
The environment map on the left remains relative to the model, and using the method on the right, remains relative to the camera.
This method has some advantages and some drawbacks.
- It's fixed-function which means it is fast and will work on low end hardware. Also it does not require another pass for cards that support multi-texturing (almost all of them).
- It can be implemented using Ogre's material script, which means I don't have to mess with a shader language.
- Artist control. I can change the cubemap face assets, and the resulting effect without touching a line of script or code.
- It looks pretty good!
- It's not per-pixel. This means that the effect relies on the verticies of the model to figure out how to apply the map. This means that the effect will be less accurate on very low poly objects.
- Cubemap asset takes up memory. If this were done using a shader there would be no memory hit, but using this method requires 6 textures - one for each face of the cubemap.