What to consider when evaluating libraries/engines for making a game?

Question

I'm going to make a game, but I've noticed that there are a lot of game engines/libraries/frameworks available out there, and I'm having a little trouble deciding which one I want 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 to make my game.

What criteria should I use to compare engines/libraries/frameworks against each other, so that I can decide which one will allow me to be the most productive, and actually 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

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, you have to pay a specific fee to compile to iOS, for example
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