Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm currently in updating some engine code (which does not work, so it is more like creating a engine).

I've decided to swap over to SFML (instead of my own crappy renderer, window manager, and audio), Box2D (since I need physics, but have none), and some small utilities I've built myself.

The problem is that each of the project mentioned over use different types for things like Vector2, etc.

So to the question: is it a good idea to replace Box2D and SFML vectors with my own vector class (which is one of my better implementations)? My idea then was to have a separate .lib with all my classes that should be shared between all the projects in the solution.

share|improve this question
Depends, is the current type fracturing causing problems? – Justin Skiles Oct 2 '12 at 15:52
up vote 4 down vote accepted

That's a very good question, mismatches in utility classes (vectors, matrices or even containers) between libraries is often an overlooked issue.

I wouldn't try to modify SFML or Box2D:

  • Your own utilities classes might be missing a few features that those libraries rely on;
  • If you need to update your libs to integrate some new features or bugfixes, you'll have do re-do all that work again.

What you should do is wrap those libraries in classes of your own, so that other parts of your engine can manipulate them without "polluting" everything with external dependencies. E.g. if you need to use a function that requires a Box2D::Vector2, don't rewrite it, instead wrap it in a function that requires a hayer::Vector2:

// this is declared by Box2D
void Box2D::DoStuffWithVector2( Box2D::Vector2 foo )

// this is a wrapper function for your engine
void hayer::DoStuffWithVector2( hayer::Vector2 foo )
    Box2D::DoStuffWithVector2( hayer::ConvertToBox2D( foo ) );

You don't have to wrap everything though, just wrap what you need when you need it, iteratively. You won't need everything in the library interface, so that's the best way to limit the code size. I'd say that creating this kind of "glue code" is roughly the same amount of work than rewriting the libs, but it brings much more benefits:

  • Changing libs (e.g. from Box2D to another physics lib) will be easier, as you'll just have to modify this "glue code";
  • You'll be able to integrate new features or bugfixes from your external libs almost instantaneously.

Doing a separate .lib for your utility classes is a good idea, it'll keep a good modularity and can't do any harm. And it'll fit in that model as well.

share|improve this answer
After giving it some more thinkering this is(for me) obviousily the best way since I'm considering chaning out the physics engine, and renderer. – hayer Oct 3 '12 at 8:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.