What should I consider when evaluating libraries, engines and frameworks for making a game?

Question

I'm going to make a game. I've noticed that there are a lot of game engines, libraries, and frameworks available out there, and I'm having a little trouble deciding which one to use.

I'm already pretty good with some programming languages, but there are others which I don't know at all. I'm not against learning new programming languages, if that'll help, but my real goal is just to make my game.

What criteria should I use to compare engines, libraries, and frameworks against each other, so that I can decide which one will allow me to be the most productive to finish my game?

Answer 1

It's sort of like picking a car or a computer. Or pretty much anything that has assorted features, some of which you care about very much, others you don't mind and some you might even not want included.

1. Make a list of the features you're interested in. i.e. 2D/3D support, lighting, physics, uses a language you know well, etc.
2. Rank them based on importance to you, based on your current project.
3. Research your options and for each option, attempt to rank their support features based on how well they align with your project goals.
4. Use the one that best matches with your goals. Alternatively you can select the top few and give them a test drive. Implement some simple feature of your game and see which one you like more.

I think a lot of this boils down to actually knowing what you want. Which means you'll need to have a pretty good idea of the game you're making. Which probably means you're going to need a fairly detailed plan of how to implement your game, and what it's going to include. As a bonus, having all that detailed information will actually help you complete your game. It's far easier to follow a plan and check things off a list than to just have an idea for a game and just start writing code.

Answer 2

First you should have at minimum a rough idea of what your game will be and what it will need. There are the usual questions like whether or not your game will need physics. Then there are the interrelated questions, which are mostly about the environment your game will be developed and run on and how commercial your game is or isn't.

• What platforms will you support? What platform are you developing your game on?
• What programming language(s) do you intend to implement your game in?
  • This is influenced by the platforms you intend to support.
• What kind of graphics, audio, and input will your game have?
• Is your game freeware or open source, or is it commercial?
  • If open source, will you want to go commercial later, either with your game or with another game that uses your first game's engine?

If you're going to be Windows-only then DirectX and C#-based libraries are strong candidates. If you want to be multiplatform then you'd want to look at libraries based on OpenGL and C/C++, or Flash if your game is 2D and you can afford Adobe's tools. Like your platform, your programming language will influence your available libraries. A program written in C++ will have a hard time calling a Java library.

If your game is commercial then you can consider buying an engine like Unity. If your game is freeware or open source you will want to focus on libaries that are also open source, or at least free for non-commercial projects. Open source libraries are useful to commercial projects too of course. When looking at open source libraries make sure to check their license. Some licences require you to make parts of your own software open source depending on how you use a library. Restricting yourself to open source libraries will obviously place another limit on what libraries you can use.

When looking at a library, make sure to check how active its development and community is. I'd trust a library that is well-known and actively maintained more than one that is hosted on someone's university web page that hasn't been updated since 1999.

One final question, especially if this isn't your first game project, is whether or not there aspects your game will need that you know you'll struggle with if you try to do it yourself. Because these aspects in particular are candidates for finding a library. If your game needs collision detection and you know you can't implement collision detection yourself (like I can't), consider picking up a physics engine and leverage the collision detection features in it.

Answer 3

• Does the library do what you need?
• Is it specialized to do what you need? How much clutter is attached to it?
• How is it designed? Do you want to vomit when you see it? If yes, then it's probably not the best choice for both your health and sanity.
• Is it flexible enough for your needs? It's not good noticing that the library doesn't work after you already have written half of your code with it.
• How future proof is the library? Is the developer adding features over time? Is he fixing things? Is he improving things? This can make quite a difference if it will be likely that your game's development is taking a few years. Not so important for small projects you'll have out in a month.
• Is the size appropriate? For small projects it can make a big difference whether the player has to download 20MB or 200MB. Bigger projects are probably big enough that the size of the middleware makes little difference.

Answer 4

In addition to the game-specific features that people have commented on, you should also consider some general questions.

1. support structure - even if game engine is perfect, perhaps support is too expensive, or non existent.
2. how easy is it to learn - you may not want something too big, as time to learn may be prohibitive.
3. does it cover your future plans - you may not want to invest time learning a perfect-for-now engine, only to relearn a brand new engine from scratch for next project. Or maybe you do want that.
4. license - if you're making a closed source game, make sure engine's license doesn't make it opensource.

Answer 5

A short cheat sheet for evaluating libraries, frameworks, engines and SDKs and picking the best

• Libraries, frameworks, engines SDKs and so on are tools which are intended to solve problems for you or assist you to solve problems and meet certain requirements.
• Evaluating means figuring out which one meets the most requirements.

Therefore before you even start evaluating you need to be clear in which scenario you are and which requirements you have/want to have because this are the questions which should be answered by the evaluation.

The scenario defines where the requirements come from (who decides what is an requirement and what isn't).

---

Typical scenarios are:

The hobbiest project scenario

You on your own or together with some friends want to create your (maybe first) game. Perfect, you can decide everything on your own and you are only limited to basic technical desicions and technical requirements (should it be a mobile game, a PC game, a console game, a web game,....). You can decide whatever you want.

Implicit requirements will be that you may want to learn something specific (a language, a specific framework/engine)

The student scenario

Requirements may come from your teacher. Typical requirements I had in that case: the game needs to have some physics elements and multiplayer network support. Or it has to be written in C++. So evaluating becomes easy. You are looking for a game engine which lets you code in c++ and may already include a network and physics engine.

A more evil (real life) requirement: everything has to be written from scratch (but using libraries is allowed). So no editor is allowed (e.g. Unity3D). So you are not looking for engines/sdks but for libraries.

The indie game scenario

You want to make money with the game later on. Therefor you will need to sell it somehow which brings you to check which requiremnts come from the store you want to sell your game on.

Does it allow Java games, HTML5 games,....)

Does it require you to include specific libraries (if yes, in which languages are those libraries available)

The Google Playstore will require you to write your game as Android game, Apple AppStore will require you to write your game as iOS app. Or you have the requirement to pick a multiplatform engine.

The professional scenario

You do not only have a store providing requirements but most likely a publisher or customer having own immaginations of requirements. In this scenario you will also have a bigger team of employed developers. Depending on their skill set new requirements arise (our programmers can only write c++ so we can not use a pure Java/Android game engine without them needing (lot of) time to learn something new).

I do not go into detail for this scenario, once you managed to build up a team of employes and find a customer/publisher you already know what you are looking for on evaluating things.

---

How do I decide what my requiremts are when I am a hobbiest or indi and no one else tells me?

Ask your self questions about your goals and your game?

• What should my game be? mobile, pc, web (html/Js), which controllers will I use (touch screen, gyroscope, game pad)

• What is new in my game and what does other games also have. Those parts other games also have (rendering, audio, input handling) will be done by the most (game engines) tools you can find or it is easy to bundle up libraries having that functionality in your own game or game engine.

• What is the dimension of my project: angry birds or skyrim? Angry Birds can be done in nearly every tool and skyrim would be limited to high performance tools with (assumed) years of additional customization (high performance terrain engines aren't easy)

• Is my only goal just to get a game done? yes? perfect, you can use some highly advanced thing like Unity, Unreal,... having a handy editor and a large community providing you with tutorials and answering your questions. It takes away the burden of handling low level tasks like mesh loading, implementing your own math functions,....

• Is my goal to learn something specific? yes? what do you want to learn?

• Which language should I choose? If the goal is still just to get your game done pick the one you/your team knows best? If you want to learn a specific language you will pick a tool in that language.

• Will tool X have enough performance for my game? Maybe, you will never know. Even in large productions the optimization and polishing phase takes a long time and is a huge affort to get it done. Start caring about performance when you hit performance issues. You do not know how the tool will perform unless to reached its limits. Everything on the web site of the tools developer is just a rough guess. After years of evaluating tools I stoped beliving anything from the developers website.

---

Answering such questions brings you to the requirements. The evaluation is finding a list of tools and TESTING (not just reading the homepage) what the tool can provide or can't.

---

Requirements are not cut into stone but are dynamic. They will come and go during development. If the game needs physics or not for example depends on the design. If the design changes the requirement can change too.

Take the requirements you have and get started. Changing requirements are the daily bread of the suffering, ahm, happy developers independent of project size and experience level.

Answer 6

Go here.

Despite the number of game engines out there, you actually don't have that many choices.

1. license restrictions. Some engines will hamper your ability to release your product without first paying large licensing fees, e.g. Unity, used to charge an additional fee to compile to iOS, for example (this changed in 2016)
2. platforms. Do you care about targeting multiple platforms? Which ones?
3. 2D or 3D? Some engines cater to 2D.
4. Requires physics? Some engines provide physics
5. FPS, RTS? It may be wise to use an engine that is specialized for the game type you're creating.
6. Obviously you'd like to work in your favorite language. Don't like C? Then don't use Allegro!
7. Are you a huge design patterns, OOP fan? Well known OGRE "overuses" patterns
8. Active development? You should consider the tradeoff between availability of bleeding edge features (DX11 / OGL 4) vs the stability of an engine's whose development tapered off a couple of years ago
9. User base? A large user base usually means better forums, so easier to answer your questions