I'm on the planning stages for an internal game engine I am about to start creating, which will be used for all my games going forward. But I'm struggling a bit with how it should be built.

The choices come down to: framework or library.

My basic objective is to hide engine details as much as possible to keep high level game development on scripts and config files as much as possible. But also to reuse the core engine for any tools we might develop in the future.

Frameworks can make things nice and easy for development, but then you're locked in. Libraries are good if you're only interested in a specific subsystem. But we need to glue everything together in a game by game basis.

Well there is also another, building the engine as a standalone exe that handles all game resources, and all the subsystems. Game logic (and other per game dynamic stuff) is done exclusively on scripts with config files to configure each internal engine subsystem.

Which one will give me more flexibility in the future.


Edit: Thanks everybody, guess I was looking at this in the wrong perspective. We can't really plan something like this without a priori knowledge of what the games need, guess this is why there is no such thing as a general engine for all genres.

I'll focus first on the game proper then iteratively analyze at the end of each game how to make decent abstractions for libraries or frameworks depending on my work-flow (or possibly that of a future team).

  • 3
    \$\begingroup\$ Neither. You should build the game, not the engine. \$\endgroup\$
    – 5ound
    Commented Aug 2, 2010 at 15:58
  • \$\begingroup\$ I agree. 'Frameworks can make things nice and easy for development, but then you're locked in.' I think you're actually locking yourself out. :) Build games, not engines. Engines will follow, later - much later. It grows out several projects. \$\endgroup\$
    – jacmoe
    Commented Aug 2, 2010 at 16:15
  • \$\begingroup\$ @Jacmoe: Either that or you try to build your next game on your previous game and the source is filled with unstructured code that is incredibly difficult to work with. Over time you might build up a huge technical debt which eventually will lead to a certain point where you can't develop anything at all with that said code. I'm not saying it WILL happen, but it might :) \$\endgroup\$
    – Simon
    Commented Aug 11, 2010 at 7:09
  • \$\begingroup\$ I didn't recommend that you should create unstructured code. :) Creating a game instead of an engine is not synonymous with creating a mess - not always.. \$\endgroup\$
    – jacmoe
    Commented Aug 11, 2010 at 13:43

6 Answers 6


Don't worry about the future quite yet. Worry about your current game, now. Otherwise you are not going to get anywhere because you are fretting on the details.

You should concentrate on building the game first and then later, if the game was successful enough, you can extract it out into something reusable for your next game. This will keep you from being locked in to something else and give you full control over your project.


Build a framework.

I have experience with building both. I prefer to use libraries over frameworks. Frameworks feel very restrictive and "bossy". So when I built my first game I wanted to build an engine that was composed of many libraries that could be easily reused in other projects.

It was a disaster. It spent half my time writing glue code between my various libraries. My libraries also tended to be bloated with extra abstractions, so that it became a huge chore to add features to the libraries/components.

Now, however my engines are built with the game I'm writing in mind. I still keep my eyes open for abstractions that will allow me to reuse it or the new features I'm adding in later games. I'm much more happy and productive.

For me the turning point was to decide to not publish my engine. I may still publish it, but for now knowing I don't need to justify my game specific hacks to other users has let me build an engine better suited to my games.

  • 5
    \$\begingroup\$ +1 on that. In fact, I think one should concentrate on writing your game, rather than an engine to write a game. An engine will emerge after several succesfully completed games. Read this: scientificninja.com/blog/write-games-not-engines Too many projects die early because they tried to write a generic mother of all engines.. \$\endgroup\$
    – jacmoe
    Commented Aug 2, 2010 at 15:51

I see this way too often.
Why build an engine, to use in future games, when you don't know what games need?
Why not build the game first, and then another, and another, reusing as often as you can.
Then you have a library of code, probably unorganised, but all shown to be useful.
Then you can go about organising it.

And for 'framework vs library', I would base it off of how tired you get of writing a game loop over and over again and stuff. ;)

A framework doesn't necessarily need to lock you in. Look at XNA.

  • \$\begingroup\$ Do you mean to say XNA does not lock you in? That's pretty much exactly what it does. \$\endgroup\$
    – jsimmons
    Commented Aug 3, 2010 at 4:19
  • \$\begingroup\$ I can't see how it really locks you in. Care to explain? \$\endgroup\$ Commented Aug 3, 2010 at 15:26

Keep it simple.

If you're not sure which way to go - just do whatever your game requires. Try to write small, basic libraries for stuff that you feel might be usable in the future. Look into data-driven software development. I suggest looking into component-based entity systems. Don't base the code around things that are unique such as a player. A player is just another object, just like anything else. An entity has components, perhaps a list of components.

By writing small, contained libraries that interact with each other, you can go ahead and determine which ones to re-use for your next game. Personally I have things like a "container" library for data-storage types. I have a math-library for such things. There are several things like these that you can sort out and write as modules. Camera, effects, input, entity, movement, physics, rendering, resource-handling, threading, the list goes on.

Writing small stand-alone components often increases readability and debugging possibilities of your code.

Mike Acton and insomniac games (www.insomniacgames.com) have written a lot of topics and discussions regarding game development, in particular data-driven. Look them up and see what kind of information that is too complex and which you find interesting and understandable. They're great developers with a ton of experience.

  • \$\begingroup\$ Yay Insomniac Games! One of their offices is near me, in Durham, NC and some employees gave GREAT talks at the Triangle Game Conference this past Spring. \$\endgroup\$
    – Ricket
    Commented Aug 10, 2010 at 15:48
  • \$\begingroup\$ I've been looking a bit at data driven development and is certainly something I will use. As for components I'll check it out, especially because I'm not quite happy with the "functional" approach I'm doing right now. \$\endgroup\$ Commented Aug 10, 2010 at 18:11
  • \$\begingroup\$ @Daemoniorum: Sounds good, just throw me another comment if you have any further questions or if you want some help / ideas for implementations. \$\endgroup\$
    – Simon
    Commented Aug 10, 2010 at 19:23

I think you're doing premature generalization. Don't get stuck too much on future-use questions right now. Pick an answer and run with it, learn from it. Flip a coin if you don't have a preference.

Start by building a game. When you build your second game you'll have a better idea what parts are re-usable and can be turned into robust library functions. When you build your third game you'll have a better idea what structure is re-usable and can be turned into a robust framework.


In terms of flexibility, I think you answered your own question: "Frameworks can make things nice and easy for development, but then you're locked in." This doesn't mean frameworks have to be inflexible; every game, for example, has a game loop. Microsoft's XNA framework is 99% library, but your game extends the Game class which just provides a few blank functions for the things which are guaranteed to be in every game: LoadContent, Update, Draw. It's a prime example of a nonrestrictive framework.

One might say a framework is nothing more than a library combined with a template class(es) that are hooked into the library, at least this has been my experience.

I tend to prefer libraries over frameworks. jMonkeyEngine, for example, is great but it's a framework and as a result I've noticed it receives tons of flak. SDL, on the other hand, is amazingly popular; it's just a library. It provides what you need but gets out of your way to do whatever you want with it.

With a library, there's not necessarily a lot of gluing to be done on a game-by-game basis -- especially if you write parts of your library to support each piece of the game loop; a Frames-Per-Second timer/counter, for example, would prevent that commonly-rewritten part from needing to be reinvented with every game.

Also, libraries can be as general or specific as you want to make them. If you're making a racing game and you want your library to have racing-specific features, that's fine. It's your creation and you get to choose exactly how flexible you want it. This would be very feasible in a situation where you're in a long-term contract with Nascar to develop numerous racing games, for example. You wouldn't necessarily want a framework to potentially tie you into a classic racing-in-a-circle game when Nascar comes up and asks for an offroad game, but you would want a racing-game-specific library since you know Nascar isn't going to ask for a shooter.

Here's a tip for development, too: if you write the library alongside a game, you will inevitably end up accidentally coupling the library to the game, or making it too inflexible, no matter how much planning you do. You'll figure it out as soon as you try to make a different game with it, and you'll spend time separating it; this isn't necessarily a bad thing and you might consciously decide to do this, since you'll have more free time after your first game is released. But if you're aiming for a stellar library from the get-go, try making two totally different games at the same time, and extract the similar pieces into your library. You'll get a LOT less coupling, it will be a lot more flexible, and your third game will probably still expose some weaknesses but your library will be much better in the end. It is, however, obviously much harder and more time-consuming to do.


Not the answer you're looking for? Browse other questions tagged .