I've noticed a trend of indie developers steering away from frameworks and engines, and moving towards using bare OpenGL, or using it combined with SDL/SFML2. As an indie developer, I can't see what low-level OpenGL can offer over separate engines or frameworks.

Most decent engines and frameworks give the functionality that you need, and never get in your way. They might also open the option to deal with OpenGL directly. Some even offer the functionality to compile cross-platform!

I understand the aspiration to learn what is happening below the hood, but I can't see any upsides that OpenGL might offer to indie developers over engines or frameworks.

Could you explain the reasoning behind building games from scratch using OpenGL?

  • \$\begingroup\$ As a graduate student in game and graphics programming, I can attest to the complexities of learning OpenGL from scratch. If I was making an indy game today, I would absolutely use SDL or some other library. But I also understand much more about graphics today than I did when I started my studies, learning an API helped me quite a bit with understanding how GPUs work in general, and how hardware and software interact. But to make a commercial product, I would absolutely use a 3rd party library at this point. \$\endgroup\$
    – Philip
    Aug 9 '13 at 17:59

This is largely an opinion based question/answer, so it's actually not necessarily ideal for this platform, but anyway:

Why no framework/engine as an indie? Here are my two cents:

  • Lack of budget: This is probably the biggest point for most small/indie developers. Many frameworks or engines won't allow you to publish your product without either buying a more expensive version (assuming there's a cheap or free version available at all) and/or pay royalties, something you'll always have to consider for small projects. Sometimes you even have to pay once per platform as well.
  • Complexity: Most engines or frameworks fall into one of two categories:
    • They're either very limited for one special genre (RPG Maker being a typical example).
    • Or the'yre simply too generic with lots of things you most likely won't use anyway (like Unity).
  • Proprietary code: Most engines aren't open source and to get the actual source you'll have to pay even more (if even available). Without the actual source code porting to other platforms can be hard or even impossiblee (again, RPG Maker would be a perfect example).
  • Clunkyness: This is my personal opinion, but at least to me this is often a rather huge letdown considering premade engines and frameworks, especially when you're building just a small game. Who wants to play a small break game that is like 200 KB in size but brings a 50 MB runtime with it?
  • Choice of language: Some engines and frameworks don't provide libraries to use in your own code. Instead they provide a framework or runtime that will use its own scripting language or some set language (like Javascript or C#). If you're writing your own custom engine, you're free to use whatever language you chose.
  • Protection of your work: If you're using a premade engine or framwork, chances are high others might have a far easier time to change or decompile your code or assets, something you might want to avoid (even if it's just to keep your highscore clean). Custom code and asset handling add a far bigger hurdle to take, especially when compiled into native code.
  • Branding: This might be minor for many, but some engines and frameworks forces you to show their logo or maybe even ads, essentially taking your freedoms to choose who/what to promote. Of course, this is often dependent on the actual license, licensing fees, etc.
  • Incompatibility with licenses: This is something many don't even consider when picking an engine, but depending on what you want to do, this might be a major factor. Even if you buy some engine, you might be restricted from disclosing any sources or related materials. Something like this might make modding impossible, even if you'd like users to be able to. Take Valve's Source engine (Half-Life 2, Team Fortress 2, etc.) as an example: They're allowing modders to use their engine for their own projects. If these games would be based on (for example) Unreal Engine, this wouldn't be possible, due to the limitations implied by the licensing terms.
  • 11
    \$\begingroup\$ plus one more thing: Once you learn openGL, you know it. You don't have to relearn it in each language or learn how a specific framework/engine wants you to implement it for each new framework/engine. This also leads to greater portability \$\endgroup\$
    – wes
    Aug 9 '13 at 12:22
  • \$\begingroup\$ Tough not the most common problem, it is possible that in the engine or framework the idea just not possible to make or would be too complicated to(ex: minecraft) \$\endgroup\$
    – akaltar
    Aug 9 '13 at 15:09
  • \$\begingroup\$ @akaltar: True, but at the same time I'd expect someone to pick an engine that fits the intended goal. E.g. don't use a 3D engine for a 2D game and vice versa. \$\endgroup\$
    – Mario
    Aug 9 '13 at 23:13

Most decent engines and frameworks give the functionality that you need, and never get in your way.

Do they? That rather depends on exactly what it is that you are doing, graphically speaking.

For many kinds of games, there are standard answers for graphical questions. The average 2D game for example can be handled just fine with the 2D prowess of, for example, XNA/MonoGame. It's just sprites, which can come in batches for terrain, can be rotated, and so forth.

But what if your game used to be the average 2D game, then you read about some cool technique, such as using a height map to build an imposter that has the appearance of depth relative to the screen. And you want to do that.

Now you're employing normal mapping and even possibly parallax mapping. All in the same context of "rendering sprites", but requiring more than a lot of pure 2D engines can handle. Specifically, it requires multitextured "sprite blitting", which is not something that many 2D engines can do.

What do you do if your engine can't adapt with you? So that means you have to do multiple passes, one for the color and one for the lighting via normal map. But that doesn't work, because you need the normal map's height field to employ parallax mapping to the color lookup. So... now what? You need the alpha to do transparency, so you can't steal the alpha. And the engine just doesn't support multitextures.

So you must pick one of the following:

  1. Abandon the idea. This means that your game is functionally limited by your engine.
  2. Hack the engine to have multitexture. Assuming you have access to the source code, you are now taking it on yourself to poke at someone else's code. This also means you need to maintain it and not break it with your stumbling around.
  3. Do the best you can, within the limitations of the engine. So you can get parallax on the normal maps, but not on the colors. It may not be exactly what you wanted, but it's better than nothing.

Just as an example, take Geometry Wars. Most 2D engines would suck at these kinds of visuals, since most of them are built around drawing sprites, not lines. That's a game that needs a very specialized kind of renderer.

At the end of the day, you need to take responsibility for the elements of your game that are important to the needs of your game. If your game's visual look is primarily developed by the art style of the images and models you use, rather than specific effects, then using a pre-packaged solution is fine. But if your game's visual style is defined significantly by custom rendering code, odds are good that a standard engine could become a serious limitation if you decide to do things that are outside of the box.

Furthermore, there's a very practical issue: not all game engines are equally portable.

With the recent rise of mobile platforms, the marketplace for games is spread across numerous OS's and user-interface devices. Not all engines work on all devices. And if your engine doesn't work on a platform, you're certainly not going to take the time to make it work on one. After all, that's why you used an engine in the first place, right?

If it's important to you that your game function on a particular platform, then you again need to take responsibility for it. And the "easiest" way to ensure success with this is to do it yourself. To build an engine that can work across multiple platforms, perhaps employing simpler platform-specific frameworks where needed to handle some low-level details. That way, if it breaks, it's your code; you're the best person to be able to fix it.

  • \$\begingroup\$ I like your answer, but I find it very odd that you picked XNA as your example. It doesn't suffer from any of the drawbacks you mention, except possibly portability. \$\endgroup\$ Aug 10 '13 at 4:21

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