Why use a Graphics Library instead of an Engine? (Ex: OpenGL vs Unity)

Started by
4 comments, last by Vincent_M 10 years, 5 months ago

[Removed]

Advertisement

Unity and other game engines make it easier to create games but there's two big trade-offs:

-You might want to implement a feature/effect that simply isn't possible in the architecture of the game engine that you're using. For example, is it possible to implement Forward+ in Unity? What about a custom GI technique? Or some game specific logic?

-Since game engines like Unity, UDK, are designed to support multiple types of games there's some optimizations that can't be made because it would reduce the engine flexibility.

Even the most flexible game engine will most likely have some kind limitation that will make it impossible to implement some feature or require some weird hacks to implement.

Some of the most complicated games on the App Store are probably created using proprietary engines that run on OpenGL. Most graphics/engine programmers will write a wrapper to hide the low level OpenGL details and improve their productivity while still enabling them to do whatever effect they want because they don't have to deal with the restrictions that other game engines have.

Basically:

If you feel like you can work within Unity restrictions and you don't have any interest in writing your own engine, then use Unity.

If you want to create custom effects, that Unity won't allow, and optimize the code for the needs of your project then you should write your own engine.

Why weren't GTA V and other AAA-games written in Unity, UDK, etc? Those engines don't allow the flexibility and optimization required for projects like that.

For indie games though, those engines are probably powerful enough.

You don't use a Graphics Library instead of an Engine, you use a Graphics Library to build an Engine cool.png laugh.png

Unity and other game engines make it easier to create games but there's two big trade-offs:

-You might want to implement a feature/effect that simply isn't possible in the architecture of the game engine that you're using. For example, is it possible to implement Forward+ in Unity? What about a custom GI technique? Or some game specific logic?

-Since game engines like Unity, UDK, are designed to support multiple types of games there's some optimizations that can't be made because it would reduce the engine flexibility.

Thanks for the perspective. I personally would still at least try to work within a prebuilt engine, or modify an open source engine that already does 50-60% of what I need, but at least now I understand why on earth someone wouldn't.

Sometimes people just roll off their own thing because they like to do that.

Or sometimes a full fledged engine is just way too much for what you're trying to do. You get layers of layers of systems and sub systems and everyone has to be configured so it does what you want to do and loads what you want to load. You might not want to learn all of that but just implement the subset of things that you need.

The complexity of learning to work with a big engine might outweigh the complexity of implementing your own sprite rendering system for example.

"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

My journals: dustArtemis ECS framework and Making a Terrain Generator

I started learning OpenGL ES a few days ago (I'm exclusively an Android developer), and I stopped when I suddenly realized that there's no way the most complicated games on the App Store are done 100% by hand like this. There's way too much going on, even if you have a team of 5 people.

I did:

All by myself too smile.png There's a lot of other engines written by students computer science students in a semester that does more than mine.

I think I released an NDK build of that entire engine on OUYA's forums a while back. Porting it was a pain until I started to figure out the environment. Unity's great for those who want to get something up and running very quickly. It can be a pain, however, and I have my own hang-ups about it. Even though a lot of underlying functionality is there, Unity seems to pride itself on how extensible it is. You can write plugins/adaptors to native stuff you've written to the platform you like, and it's spawned quite a marketplace for it on Unity's website. That being said, there are a lot of things Unity doesn't do out-of-the-box, yet I'd expect:

-Splines: you can either write a script using a bunch of empty game objects which is heavy on memory, or download a plugin to do the same thing

-2D things for something like HUDs/2D games, etc (Toolkit 2D's and NGUI seem to be good at it)

-Slower code execution (you write 'scripts', and a virtual machine interprets it on-the-fly which is cool, but not as fast as native code)

-3rd party ilbraries: using others' libraries is a pain (such as ads, IAPs, etc), especially if they don't provide a plugin, you'd have to write your own native wrappers

EDIT: I forgot my reason.

I write all my stuff in OpenGL because then I have a more thorough understanding of how things are working than I would if I was using some one else's closed-source approach. I'm not saying Unity's going to write code slower than mine as it's built to run off of OpenGL ES for iOS/Android, but it's still possible depending on your needs. I released my stuff I've been working on open-source so others can learn, and play around with it. Also, keep in mind that larger companies are either writing them own stuff from scratch, or using an engine that provides source, albeit expensively. The Batman: Arkham games were built off of a modified engine of Unreal Engine 3 since they had the source available. That probably came at a pretty steep cost, however. If I ever want to get a job working for companies like that, or start my own company making big-budget games one day, I'd have to really know my stuff if my role is programming.

Now, for you, I think it's a matter of how much you enjoy programming, and how much skill you currently have to meet the project's requirements. Honestly though, I'd probably build something in Unity just to get a game out the door for the experience, then move to OpenGL once I'm comfortable with that. Looking back at it, that's actually what is did... lol

This topic is closed to new replies.

Advertisement