So my main question is that why alot of you use API/libraries like directx/opengl/sfml/allegro/sdl/xna and etc to make games rather than use an engine like unity/udk/troque? Doest using an engine make game dev a lot more streamlined and easier than using an api? What are your reasons?

Well made point, Eddie. Its the same reason im using allegro rather than an engine. Keep posting your reasons people!

NIH

I'm super angry that I have to use stuff like DirectX and FMOD. I'd prefer ASSUMING DIRECT CONTROL.

lol

No, my reasoning is pretty much identical to JD557's.

I thought programming was a game!

. . . but seriously: I never use a game engine. Following is why.

Game engines get in the way of what I want to do more often than they save me work, and they consistently still somehow fail to do things I need them to do. "I don't care that there's a material for a bloom shader; I want the FBOs you used to do it!" When I want to try a new algorithm, or do something no one thought of before, I don't want to be trapped in the framework some programmer thought would be all I'd ever need. No one can anticipate what anyone else will eventually want to write, so modern game engines, invariably never playing gracefully with outside code, hurt me.

Game engines, particularly proprietary ones--though open-source too due to the nature of the number of people working on them--almost always aren't up to my specifications of intuition. I am a perfectionist, and by nature I constantly tweak things down to the point where I spend an afternoon rewriting something just because its design isn't completely bulletproof and intuitive. I like my APIs to be obvious to use, robust, and powerful.

First, there should be at most one built-in way to do something, and it should be the best way--not different ways for different cases, different ways depending on context, hidden ways, and so on. I don't need four different ways to do something simple. It should be obvious, just by guessing, what the API does, and there should be one way it does it, if it does it at all.

Similarly, there's a point where the benefits of abstraction are overwhelmed by the cost of understanding it. I don't want to have to read pages and pages of documentation just to do something simple. In the best projects, documentation serves as a clarification and shortcut guide for advanced users--not an indispensable prerequisite for newbies.

Second, any internal software development is an exercise in balancing abstraction with power. Game engines fall far too heavily in the former for me. I can never do things the most efficient (or even reasonably efficient) way.

On a related topic, game engines tend to be bloated and hard to understand. Take the Bullet Physics Engine (which is actually a library). It's great: it works well, it's fast, and it is the de facto standard for physics engines—open source and proprietary. It's also horrific to read. As a newcomer, try reverse engineering some of the examples. It's next to impossible to just jump right in and start using it. I know that Physics simulation is not easy, but 4 megs of source is only justified if it's easy to understand and easy to use. Bullet is neither.

Analogously, this is in fact one of the things I personally oppose in the software industry: Parkinson's Law of Data, and a general lack of concern for system resources. Modern games ship with gigabytes of data, much of it never used. Why? Part of it is just that games are getting better, but a lot of it is due to wasteful game engines and content production pipelines. True, it's very easy to add new assets, but you lose a lot of value when you need a custom IDE or content management system to make sense of it all.

Game engines are often expensive or impose licensing restrictions. The last thing I want is to write something and then find out that 10% of my income from it goes to the game engine, or that I have to release my code under the BSD Revised Unported Attribution Commercial Software License rev.238b or suffer the consequences. Libraries have the same issue, but less so.

Perhaps the best argument, though, is the joke I opened with: programming is a game, and I for one find it amusing to write more powerful software with less code. Someone else might need a $500 license to use a game engine, but I derive joy from writing something faster and more elegant from scratch, even if it means I have to remake some wheels.

As an important clarification to my above points, I remind you that game engines and libraries are distinct. While I never use game engines, I almost ALWAYS use libraries. I can't get around the cruft of things like OpenGL (and the greater cruft of Direct3D) without doing drastic things like writing drivers for every graphics card ever. Similarly, there's sense in using things like SDL, wx, or QT, because no one wants to write a cross-platform windowing toolkit/system (except those guys, apparently).

But, in keeping with the above points, I try to choose libraries that are small, fast, and extensible--and when that's not an option, I almost always end up using a very small subset of the function calls available. Finally, when all else fails, I write a pretty API that exposes all the power of a library with the cleanliness I expect--doing this is only possible with lower-level libraries, and in fact I do, it seems, gravitate toward those.

The largest library I use is the code that I personally have written over the years. My OpenGL library can do everything the graphics component of a professional 3D game engine can do (or can, with a bit of code; it's designed to be more like a series of foundation classes than a plug-and-play sort of game-making-algorithm), yet it's comparatively tiny.

I'll concede that my strategy of making better wheels where bad ones already exist doesn't work to churn out games. I've noticed that I find place(s) for at least minor improvement whenever I try to use any library, and I spend more time than I should improving the library instead of actually making the application based off it. But, maybe this just tells me that I'm more of a researcher than a developer. I don't know.

On the opposite spectrum, I recently successfully released a number of small Python/PyGame games by just rewriting everything from scratch each time, and refusing to use any base code. Naturally, this doesn't scale past small applications like that.

So personally, for me:

• Libraries that you occasionally call into are good, but only if they are well-designed. Otherwise, try not to use them, acknowledging however that sometimes using a bad library is a necessary evil.
• Avoid game engines like the plague.

I enjoy coding. It's fun and a passion. I understand you still must code when using a game engine, however it's generally very high level and a lot more simple than code I would write when I'm developing without an engine.

If I start making Three-Dimensional games and I need to push out a large product quickly with a team, of course I will use Unity, however I work alone (As of now) and am making Two-Dimensional Games. As I've detailed in other posts of mine, I actually use Construct Two for prototyping. It's easy to drag and drop some placeholder art, write some quick HTML5 / JavaScript, and make a small prototype for a game Mechanic. If it's fun, I'll try to go ahead and program the game myself.

Learning how to program using a Game Engine doesn't seem very good to me (Unless you're an artist). Many programmers I've seen who learned to code with an engine write painfully slow and pointless code. I learned how to use C++, and waited a year before jumping into Graphics. I'm still learning different quirks surrounding the language and exploring C++11, however the experience I gained from learning a language and not an API / Engine is helpful and an underlying reason why I enjoy programming. I understand peoples code, and it's an amazing feeling. Actually being a coder makes me feel accomplished, and every time I spend a few days working on a problem / fixing a problem, I get an amazing sense of accomplishment.

The community for many Game Engines reflects many of my points. On the Unity forums, far too many (Even the well respected) of the programmers learned with Unity, and as a result, are not as helpful had it been a low-level programmer who had joined one of the teams on the forums. They don't normally write efficient code, and don't understand what their code does besides what they know from Unity. This isn't helped by the fact that the forums are barraged with teenagers trying to recruit actual game developers for their new "Zombie-MMO-DayZ however Better-FPS". I'd say about half of the community is twelve year old's. I should link you to a post (Albeit old) from a group of twelve year old's who had promised their school they would make an MMO (bigger than World-Of-Warcraft) and were looking for a team to make the MMO for them.

I respect the developers on the Unity Asset Store however. They are some of the most hard-working programmers I've seen and they make amazing software. It's no wonder that many of them work as programmers at larger studios (I've seen some from the likes of Electronic-Arts) or use lower-level API's.

I believe using an Engine is smart if you understand how the Engine works. This is the main reason why I'm learning OpenGL. I want to understand. I constantly read about Security (Security+), New programming languages, design patterns, practices, Books on new languages (and current languages). Understanding is important to me. I felt a feeling of "This is all to big for me to understand" when I started. There's just so much, it's hard to sort through it all.

Wow, that was a rant ! Cheers :)!

couple of years ago , at the beginning of our current project we did experiment with Unity. At the beginning we were all happy, the artists were happy because they had their nice environment to work with shaders, illumination and what not, I was happy looking forward to a relaxing development year full with lots of vacations and no graphics programming involved.

After a couple of months, the pretty picture started to fall apart.. loading time went biblical (>60 seconds), shadow quality wasn't good enough and untweakable for our needs, the entire working pipeline was VERY different (I wouldn't say bad.. but way different) from what we were used to, motion blur was more like LSD-acid effect. Luckily I had a DX11 pet engine that I was working on for fun and one sunday, for fun I imported the track and car we were developing as example in, and got the thing loaded in 7 seconds with the shadows just as I needed... after a couple of meeting with the entire team, Unity was out of the window, and my holidays were canceled

I look forward to the day I will be able to pick up an engine and be able to use it for my work.. it is the proper, sane and smart thing to do. Sadly, for the moment, we're not there yet for the kind of projects I do. But, if I were to start a new project tomorrow, my first move would be to check out a 3rd party engine first and evaluate if that could be of any use.

I use directx on top of win32 and that is because I just want to learn things. So I'm making my own engine atm. But if I would in the situation, that I just want to ship some "little" game for mobile or tablet to market, I think I would use an engine. Would save a lot of time.

Awhile ago I read a little column, that many of finnish game companies are using Unity at the moment because they can concentrate more on developing contents of the game rather than adjusting the engine. And they are choosing Unity because it's quite easy to use. I also used Unity engine when we made networking game project in our school and it's really easy to use. Quite many finnish game companies, which are perhaps start-up companies or beginning companies have some nice idea so they just want that idea as fast as possible to market. Developing an engine would cost money and they couldn't concentrate on the original idea hence they have to develope the engine for it. But that's not what everybody does, but it seems that majority though.