Big Libraries vs Small Libraries – Game Development Workflow

dependenciesgame developmentlibrariesUtilitiesworkflows

Over the course of some months I've created a little framework for game development that I currently include in all of my projects.

The framework depends on SFML, LUA, JSONcpp, and other libraries. It deals with audio, graphics, networking, threading; it has some useful file system utilities and LUA wrapping capabilities. Also, it has many useful "random" utility methods, such as string parsing helpers and math utils.

Most of my projects use all of these features, but not all of them:

  • I have an automatic updater that only makes use of the file system and networking features
  • I have a game with no networking capabilities
  • I have a project that doesn't need JSONcpp
  • I have a project that only needs those string/math utils

This means that I have to include the SFML/LUA/JSON shared libraries in every project, even if they aren't used. The projects (uncompressed) have a minimum of 10MB in size this way, most of which is unused.

The alternative would be splitting the framework in many smaller libraries, which I think would be much more effective and elegant, but would also have the cost of having to maintain more DLL files and projects.

I would have to split my framework in a lot of smaller libraries:

  • Graphics
  • Threading
  • Networking
  • File system
  • Smaller utils
  • JSONcpp utils
  • LUA utils

Is this the best solution?

Best Answer

I'd personally go for many small libraries.

  • Discourages developers from creating dependencies between otherwise unrelated packages.
  • Smaller more manageable libraries that are much more focused.
  • Easier to break up and have separate teams manage each library.
  • Once you have a new requirement that's sufficiently complex, its better to add a new module rather than find an existing library to shove the new code in. Small libraries encourage this pattern.
Related Topic