Need a little help.

try and be more specific about what help you want.

You mean, you want help building your Camera Class?

Any help you say, well a few tips then.

If you can use a texture for something instead of geometry, do it.

Get a working game design doc working, it will cut your development time into a fraction of what it would be.

using the scale 1.0f unit = 1 meter is a good scale to use.

Allways keep youself dry when in cold climate, if you get wet you could freze to death.

Don't try taking on making the next blockbuster doom3 clone in the first go.
Infact, pong as a more suitable subject fo you to begin with.

To make a great game it takes about 30% coding and 70% making the graphics.
Can you do the graphics?

Normalmap everything.

Don't go using way to many textures, and if you got multiple objects with the same texture, render them in one go.
Infact, you would do good if you render stuff on a per texture basis instead of per object basis.

I can do the modeling pretty good, its pretty much just getting the camera and movement controls and stuff.

and I'm not trying to make a doom 3 clone, this a totaly different kind of game

As lc_overlord said, a design doc is key. Get everything defined before you even touch code. A design document is basically a decomposition of the game on paper. It has nothing to do with art. It has more to do with the various states that your game will be in and how those states are represented.

Here are a few questions you should ask yourself:
- Is this a multiplayer game?
Proly no, but keep in mind that you wont be able to add this later.

- How is the craft going to move?
The craft is obviously going to move foreward, left and right. Will it be able to go backwards? Will it be able to go up?

- Is the terrain going to be flat, or is there going to be elevation?
If there is elevation, then you will have to modify your levels to handle this.

- What types of impediments are the players going to be facing?
Pitfalls, speed bumps, or just a plain old race track?

- Do you just go around the track once to win, or will you have to go around multiple times?

- What does it mean to win?
Do you win by completing x amount of laps? Are there going to be various conditions you have to fulfill to win? Are there going to be different modes of play that define how you win?

Answering these questions is very similar to building a board game. In this initial phase it is important to make sure that your game is playable. Once you have answered the questions that define what the game is, then you can start building a technical model around the game. This means taking your game model and defining it in abstract terms. Heres examples of the questions you would ask yourself:

- How are you going to represent the player?
List the basic attributes of the player in the game.

- What are the obstacles of the game?
You want to create a basic model that will let you define the attributes of any obstacles that you might put into the game. Complexity could range from a full tesselated collision model to a grid of squares with different values indicating their significance to the player. For example, you could say that the obstacle is max, a 16 x 16 grid of integers, and each square is a 1x1m square in the game. Then you could use this as a bitmap where a 0 represents normal road, 1 represents no road and 2 represents an oil or something to that effect.

- What types of power ups are there and how do they affect the player?
Again, a similar task as the obscales definition but fortunately this is easier. The reason its easier is because you already have the player defined. These items simply modify the attributes of the player, increasing his velocity, or decreasing his health, as the case may be.

- How are you going to represent a level?
A level is a collection of obstacles and items, which the player must play on. This is where you tie everything together. A game consists of one or more levels potentially tied together by a storyline. If you want a good place to start looking at examples of how all this stuff fits together, take a look at the starcraft campaign editor. It is a more complex example of a technical definition of a game. A level definition can simply be a text file. You could invest time to make a world editor, but this really isnt required unless your game gets very big.

A "game engine" is essentially the thing that will take your level definition and let you play the game. You can also add save states that will let you save differences between the player's attributes, and the normal attributes.

You dont necessarily need to define everything at once; it might be simpler to define a part of the game, implement it, test it and move on. However, it is safer to define everything before you implement. This way, if one part of your design conflicts with another, you have spent no time implementing the design, so changing it is easier.

Hope this helps,
- llvllatrix

thanks for the replys, that was very helpful. it starts with in the Matrix Revolutions. when they try to get away from the Sentinels, and you have to pilot the mechanical line. so thats my problem. because the mechanical line is supposed to be so small, it would be prolly be pretty difficult to get a camera in there with the ship and all the sentinels without clipping