Sure.
The wheel we got isn't terribly great, but it was really the only one we could find with a game port (its a Saitek, not sure of model number/name). Anyway, its potentiometer doesn't reach all the way from 0 to 254, and it doesn't stay centered at 127 (the center moves around at competition, we have to reprogram it), nor is it possible to adjust the pot manually. So to begin, we have in our program constants that define the minimum, maximum, center and dead range of the wheel (it wobbles a bit in the center).
That aside! Initially both sides are fed by the throttle, through some straightening code (if the wheel is centered; the straight code is based on motor encoder inputs). If you want to turn, we take the distance from center and convert it into a percentage (actually a percentage to the min or max), then bring the motor outputs on the side we want to turn to towards 127 by that percentage. If the throttle is low, the percentage is upped by about 25% in order to reverse the wheels on one side and allow a tighter turn. Further, the wheel paddle, when pressed, puts the robot into "turn mode." Then, the distance from wheel center as a percentage is used to reverse one side and go forward on the other, turning the robot in place (at about 2 rev/s for full speed).
Jay said he prefers tank drive, but the robot this year is too fast and too twitchy to make that possible. When you move at near 15 ft/s, you really need a more forgiving method of control, as well as a way to recognize when you just want to go straight (as that's really hard with two sticks).
edit: At Cal Games, the distance from center was added directly to the motor value on one side I believe, which wasn't powerful enough at high speeds and too powerful at low ones. So we switched to a percentage based system and have been generally happy since.
Sorry if I didn't explain it well enough--PM or IM me if you have more questions
.
Jay's post is better, but I'll leave mine too =P