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

One consideration in favor of C/C++/obj-C is that you can mix and match various libraries for different areas of concern. In other words, you are not stuck with the implementation of a feature in a framework.

I use this approach in my games; using chipmunk for 2D physics, Lua as an embedded scripting language, and an openGL ES implementation from Apple. I write the glue to tie all of these together in a C language. The final product being the ability to define game objects, create instances of them, and handle events as they interact with each other in C functions exposed to Lua. This approach is used in many high performance games to much success.

Answer 2

I would recomend you try pyglet.

• It has good performance, as it utilizes opengl
• Its a compact all-in-one library
• It has no extra dependencies besides python

Do some tests, see if you can make it fast enough for you. Only if you prove to yourself that it's not move to a lower level. Although, I'm fairly confident that python + pyglet can handle it... at worst you'll have to write a few C extensions.

Answer 3

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.

Answer 4

You need to ask yourself if you are in this to build an engine or to build a game. If your purpose is to create a game, you should definitely look at an established gaming engine. For 2D game development, look at Torque Game Builder. It is a very powerful 2D gaming engine/SDK that will put you into production from day 1. They have plenty of tools that integrate with it, content packs, and you get the full source code if you want to make changes and/or learn how it works. It is also Mac OSX compatible and has Linux versions in the community.

If you are looking for something on the console side, they have that too.

Answer 5

Yeah unless you just want to learn all of the details of the things that go into making a game, you definitely want to go with a game engine and just focus on building your game logic rather than the details of graphics, audio, resource management, etc.

Personally I like to recommend the Torque Game Builder (aka Torque 2D) from GarageGames. But you can probably find some free game engines out there that will suit your needs as well.

Answer 6

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.