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 library or SDK? I'm a moderate C programmer and am not afraid to work with pointers, data structures, memory locations, etc. if it will give me the control I need to make a great "thick-client" game. However, I'm thinking of eschewing high-level languages & frameworks for the sake of power and control, not ease of use.

I'm interesting in tinkering with a 2D fighting/platforming game as a side project sometime. I'm primarily a Linux server-side programmer with experience in Python, Ruby and PHP. I know that there are excellent frameworks in some of these languages, like PyGame. I am also aware of the success people have had with stuff like Air and .NET... but I have some concerns:

• Performance: Scripting languages are notoriously slow. If I'm making a real-time game, I want it to be as snappy as possible.
• Huge binaries: Using frameworks like .NET or scripting languages like Ruby often result in big CLRs or libraries that you wouldn't otherwise need. The game I want to make will be small and simple--I don't want its CLR to be bigger than the game itself!
• Extra stuff: Honestly, I just don't like the idea of inheriting some big game library's baggage if I can wrap my head around my own code better.

I'm asking this question because I know I'm very susceptible to Not Invented Here Syndrome. I always want to program it myself, and I'm sure it wastes a lot of time. However, this works out for me remarkably often--for example, instead of using Rails (a very big web project framework with an ORM and GUI toolkit baked in), I used an array of smaller Ruby tools like rack and sequel that fit together beautifully.

So, I turn to you, SO experts. Am I being naive? Here's how I see it:

• Use C
  • Cons
    • Will probably make me hate programming
    • High risk of reinventing wheels
    • High risk of it taking so long that I lose interest
  • Pros
    • Tried & true - most A-list games are done in C (is this still true today?)
    • High level of control over memory management, speed, asset management, etc., which I trust myself to learn to handle
    • No cruft
• Use framework or SDK
  • Cons
    • Risk of oversized deliverable
    • Dependent on original library authors for all facets of game development--what if there isn't a feature I want? I'll have to program it myself, which isn't bad, but partially defeats the purpose of using a high-level framework in the first place
    • High risk of performance issues
  • Pros
    • MUCH faster development time
    • Might be easier to maintain
    • No time wasted reinventing common paradigms

What else can I add to this list? Is it a pure judgment call, or can someone seal the deal for me? Book suggestions welcome.

Answer 1

I believe you are working under a fallacy.

There are several frameworks out there specifically for game programming --- written by people with much experience with the complication of game design, almost certainly more tha you do.

In other words, you have a "High risk of performance issues" if you DON'T use a framework.