Game programming - How to avoid reinventing the wh

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

Today, I believe you are at a point where you can safely ignore the performance issue unless you're specifically trying to do something that pushes the limits. If your game is, say, no more complicated than Quake II, then you should choose tools and libraries that let you do the most for your time.

Why did I choose Quake II? Because running in a version compiled for .NET, it runs with a software renderer at a more than acceptable frame rate on a current machine. (If you like - compare MAME which emulates multiple processors and graphics hardware at acceptable rates)

Answer 2

If you don't already know C++, I would definitely recommend you go forward with a scripting language. Making a game from start to finish takes a lot of motivation, and forcing yourself to learn a new language at the same time is a good way to make things go slowly enough that you lose interest (although it IS a good way to learn a new language...).

Most scripting languages will be compiled to byte code anyway, so their biggest performance hit will be the garbage collection. I'm not experienced enough to give a definite description of how big a hit garbage collection would be, but I would be inclined to think that it shouldn't be too bad in a small game.

Also, if you use an existing scripting language library to make your game, most of the performance critical areas (like graphics) can be written in C++ anyway (hopefully by the game libraries). So 80% of the CPU might actually be spent in C++ code anyway, despite the fact that most of your project is written in, say Python.

I would say, ask yourself what you want more: To write a game from start to finish and learn about game development, or to learn a new language (C++). If you want to write a game, do it in a scripting language. If you want to learn a new language, do it in C++.