Game programming - How to avoid reinventing the wheel

Question

Summary:

Can I program a \"thick client\" game in C without reinventing wheels, or should I just bite the bullet and use some libr

Answer 1

There are alot of different solutions to the issue of abstracting and each deals with it in different ways.

My current project uses C#, DirectX 9, HLSL and SlimDX. Each of these offers a carefully calibrated level of abstraction. HLSL allows me to actually read the shader code I'm writing and SlimDX/C# allows me to ignore pointers, circular dependencies and handling unmanaged code.

That said, none of these technologies has any impact on the ease of developing my AI, lighting or physics! I still have to break out my textbooks in a way that I wouldn't with a higher-level framework.

Even using a framework like XNA, if most video games development concepts are foreign to you there's a hell of a lot still to take in and learn. XNA will allow you to neatly sidestep gimbal lock, but woe betide those who don't understand basic shading concepts. On the other hand, something like DarkBASIC won't solve your gimbal lock problem, but shading is mostly handled for you.

It's a sufficiently big field that your first engine will never be the one you actually use. If you write it yourself, you won't write it well enough. If you use third party libraries, there's certainly aspects that will annoy you and you'll want to replace.

As an idea, it might be worth taking various libraries/frameworks (definately make XNA one of your stops, even if you decide you don't want to use it, it's a great benchmark) and trying to build various prototypes. Perhaps a landscape (with a body of water) or a space physics demo.