Reinvent the wheel!

14.03.2010

This is a technical rant, so be warned. I'm reinventing the wheel. I'm systematically replacing all of other people's code with code of my own. Here's why:

In 2005 I wanted to make a cutting edge indie game engine for my next game. I wanted to compose my engine of different parts, thinking that somehow that would speed things up. I didn't want to reinvent the wheel, obviously. I chose Irrlicht for graphics, Newton Dynamics for physics, RakNet for networking, Angelscript for scripting, and Audiere for sound.

Choosing to use good existing libraries was a good choise wasn't it? It would speed up development, I could start using those sounds and physics and whatnot straight out of the box. As the libraries were updated, my code would become better with no effort on my part. All I had to do was combine the well designed interfaces. Naive thinking.

No library is perfectly suited for the task you have. You're better off writing the code yourself.
  1. The library doesn't have all the features you need, and it never will. If the library you want to use is missing a feature, it will never be there. The maintainer's may tell they're hard at work implementing it. But it will never get in there. If you really need that feature you can't depend on promises. Real life can get in the way, other features can get in the way. It's a risk you don't want to take if you really need a feature. I waited four years for Vertex Buffer support in Irrlicht. It got there in the end, but not the way I wanted.
  2. The library won't suit your needs after all. Newton Dynamics couldn't support the amount of physics objects Driftmoon deals with, mainly because it was a 3D physics library. Turns out I wanted a 2D physics library instead of 3D.
  3. Updating the library will break your software. In the beginning Angelscript had a lot of bugs, it was just getting started after all. But each time it was updated, some of the interface changed, requiring extensive code changes. There's no telling what an update of a library does, maybe it fixes something and adds features, maybe it adds some very clever bugs, requires a complete rewrite of your own code, and removes just the feature you needed.
  4. There will be hard to track crashes and bugs. Audiere crashed the whole game at random intervals (see earlier post about sound libraries). The reality is that a library will have bugs in it, and you may never know whether the problem is in the way you're using the library or within the library. Right now my Irrlicht text rendering becomes crawling slow at some random point in the game. I have no idea what's causing it, maybe it's a bug in Irrlicht, maybe I've done something wrong.
  5. The library interface will suck. Newton Dynamics wanted you to build your code around it. You didn't tell it that your object had this physics representation, it told you that I've got your physics right here, you can add your object to that. You shouldn't be forced to structure your code to suit a library, but that's often the way it goes.
  6. The library will be bloated. So maybe the library has all the features you need, and then some. I wanted to use OGRE graphics library at some point, but turns out the library would have taken ten times the space my code did. The space is less of a problem these days, but you'll have to think forward to the day you need to debug the library. Can you find the code paths you're using in the mess of code? Can you add the feature you need if you can't understand what the thousands of source files do?
  7. The library maintainer will abandon the project. You find a huge bug in the library, what do you do? Fix it? No, you point it out to the library maintainer. Maybe he's lost his interest, got fired, or maybe the company is bankrupt even though you've got paid support.  So what do you do? If you're lucky you've got the code so you can fix it yourself, which brings me to the next point.
  8. You will not be able to fix any of the bugs in the library. Chances are the maintainer isn't interested in your bug reports, and  you're the only person on the planet still using the library - you'll have to fix the bugs yourself. But you can't understand advanced physics/networking/graphics, that's the whole reason you used the library in the first place!
So I say, do it yourself. Reinvent the wheel! Make your own code. You'll have to learn the topic, you'll have to make and debug the code. But it will fit your needs, you can keep it updated and you understand the code and know how to use it.

blog comments powered by Disqus