Hey everyone.
We are a bunch of enthusiasts willing to create a good driving game, iconish like GranTurismo series for PlayStation series and Forza series for XBox, but for PC. Emm, I know that's a hard stuff, I'm normal in physics, I can write some simple programs, but I'm a n00b in ASM for sure. Mainly, I'm a 3D modeler.
So we are willing to find a possible car nerd or a guy into driving sports / drifting / Japan / programming physics or just ASM. No, I'm not willing get some one, who'd do all the work instead of me. But a good PC game nowadays needs a good engine, awesome physics, great models, beautiful environment, smooth multiplayer and interesting gameplay... Then there will be success. Game, physics conceptions are mainly ready. Also I've got some resources to maintain multiplayer server, so it won't be a problem.
We need a new member of our small rigid team.
Sorry, no money or something, probably, until we finish it. So you shouldn't enter if money is what you need.

p.s. Money breaks projects. :P Motivation is the key.

Feel free to write what you think about the idea and developing.
Posted on 2008-03-02 21:12:24 by Diskovod
There are many many options and pitfalls/gotchas and things-made-easy in gamedev, I recommend just using existing engines or libraries or at least copy/paste/modify existing code. Thanks to nVidia and ATi, it's usually hell to support all DX9-class (and above) cards. And you mostly end-up calling API. So, it's better to put an ASM coder to write most stuff in C++, and only in the end make him optimize all critical parts. A coder without a black-belt in ASM will only cripple the project :P. (those C++-only kids go into endless loops around OOP praises, it's scary and funny).
For physics, use Bullet - you can later optimize it further (though the author seems to know ASM and maybe his lib is ok as it is).
For tools, you do need a sh*tload of tools - but coding each one them oneself is generally time-consuming and brings morale down. The tools I currently remember are: 3D object importer/converter, bone vertex-weights editor (if not present in original mesh), vertex-displacement editor (also if not present in original mesh), bone/displacement animator with multiple tracks (haven't seen ready tools like it, I know Valve and NaughtyDog implemented their own), world-editor with octrees/whatever and dynamic-lights,static-lights with precomputed lightmaps or vertexmaps, script-editor (not necessary much), effects-editors (particles), shader-editors.

It's all easy if you know precisely what you want and say "no extra features will ever be added". But if at some time you change the requirements and make the programmers modify their existing code and start thinking anew (or tell them "we may be adding some features later") - you've just shot yourself in the foot and the project will never complete unless you (finally) pour a lot of money and delay milestones. Basically, the project may only fly if right from the start you've pin-pointed everything except the art (that won't require changing the code).

Multiplayer makes all code that handles object-movement require another way of thinking and it'll be very hard to tweak in your case, as the cars are moved by many things: user-input, physics momentum, physics collision-response, and thanks to lag, for it all to look ok - you have to fake, fake fake. So, do warn your programmers to handle even single-player input like the multiplayer-mode input right from the start.

Money doesn't necessarily break projects. Unless you get a bunch of employees, that aren't diehard fans of the genre the project is in. Whoever it is, gamedev is very requiring in  time, knowledge and vigor, and people do need to eat and pay bills. Chances are you won't get a good game programmer (as almost all such will be already taken by studios with 4-digit monthly wages, unless it's a 16-yr-old genius that skips school) and you end-up with some apprentice that simply has spare time after his primary job's 8 hours/day - and loves cars. It's quite easy for the apprentice to get taught erroneous (obsolete) things about gamedev from articles on the net. There are dozens of thousands of tutorials about gamedev on the net, that will lead newcomers to make all bad decisions in designing the game-engine.

I'm also doing a similar project in my spare time (except I uhm hate cars), have fixed it all to run only on GF7x00 with opengl2.0, making some/all of the tools - but I'm not any serious about it, I just want to explore and hopefully make some nice-looking 15-minute game just for kicks (I'm both the coder and artist). Kinda balancing all angst I have from my job as a mobile-games/software developer (severe limits, ultra-slow cpus and OSes, little RAM, almost no ROM, ultra-inconvenient-and-buggy OSes) ^^.
Posted on 2008-03-03 17:54:44 by Ultrano
For the record, the Bullet physics library is the perfect example of "a week spent improving an algorithm is worth ten weeks spent optimizing loops".

It's terrible in terms of cpu optimizing, but the algos are a real breath of fresh air and help to bring sanity to the table of the dining philosophers.
Posted on 2008-09-07 10:57:16 by Homer