So in terms of hitting a specific fps target, it all boils down to optimizing your code in terms of AI, Collision Detection, and or render code?

a profiler or timers are used to determine what code is too slow. then that code is optimized to run faster. It may be the type of code you mention (AI etc) or it may be some entirely different sections of code. never make assumptions about whats fast and whats not. test and time everything to be sure.

So in terms of PC games, do developers pick their target hardware specification based on the hardware they developed the game on?

you start by determining what the "average" user's PC will be when the game is done. if it takes 2 years to make the game, you have to guess what will be the average gaming PC in two years and target that hardware. This way you don't have minimum system requirements that are too high, yet you have as much hardware power as possible to work with. Console hardware is not an ever-moving target, and thus much easier to predict what hardware the users will have when the game is released.

Why do some developers aim for 30 frames per second? Whats the advantage of that? I would think a developer would want to aim for as high a framerate as possible, since if the target is at 30 frames per second then the frame rate would have to be lower than that (To the point were the perception of smooth motion is gone.). Is it due to the complexity of the game and the algorithms used will never allow the game to reach a certain frame-rate over 30? Or is there something else at play?

lower frame rates = more time per frame to do more stuff.

higher framerates mean doing less, or optimizing code. nobody wants to cut features out of a game. and optimizing code is more work. higher framerates only increase the smoothness of animations. framerates don't need to be high to be playable, they need to be consistent, IE not drop frames. The fact is that you only need to run at 15 fps to be playable, anything faster is just smoother animation, and nothing more. you can notice a bit more responsiveness at 30 vs 15 fps. but not at 60 vs 30 fps.

many folks run render as fast as possible, for smoother animation. this is the primary driver behind higher framerates.

some games are more complex than others, or target slower hardware, and thus have lower target frame rates.

Why do some developers aim for 30 frames per second? Whats the advantage of that? I would think a developer would want to aim for as high a framerate as possible, since if the target is at 30 frames per second then the frame rate would have to be lower than that (To the point were the perception of smooth motion is gone.). Is it due to the complexity of the game and the algorithms used will never allow the game to reach a certain frame-rate over 30? Or is there something else at play?

I've worked on a bunch of 30fps games and recently some 60fps ones.

Typically a developer re-uses the same technology and workflows from one game to the next -- nothing is from scratch, but built on the shoulders of your previous work.

If the previous game ran at 30fps on an Xbox, that's your starting point for your next game... and if you want your next game to run at 60fps, then that means optimizing your code to run 2x as fast! That's a huge demand! Especially as sequels usually have higher demands -- people expect it to look better, so it's actually higher than 2x performance to take a sequel from 30fps to 60fps :o

To get that done quickly, you can reduce the numbers of things -- less characters alive at a time, less animation data, less pixels (lower resolution), etc... but then you're reducing quality...

To get it done properly, you need extremely experienced programmers to rewrite the parts of the game that take up the most time... If a senior engine programmer costs $150k a year, and requires 6 months to re-architect one engine system, and there's a dozen systems that need to be rewritten... that's almost a million dollars worth of code!!! Not to mention the extra time that you need to push back your release date depending on how many staff you have on hand...

There's also the issue that the CPU and the GPU run in parallel to each other.

(Generally) All the game code runs on the CPU, and graphics mostly runs on the GPU with a decent amount of CPU work too...

If the GPU workload is 33ms per frame, then it doesn't matter how fast your CPU code runs, you can't possibly hit 60fps -- so you may as well settle for 30fps (solid 30fps feels better than an fps that varies e.g. from 40 to 50).

Likewise, if the GPU workload is 10ms, but the CPU workload is 33ms, then again you're stuck at 30fps... so you may as well triple your GPU workload and bring it up to 33ms per frame as well.

For console games with fixed hardware, it theoretically is a tradeoff between frame-rate and fidelity / amount of stuff... but in practice, it also largely depends on how much time/money you're able to spend on re-writing your inherited code...

Wow, thanks everyone. Very informative posts.