1
\$\begingroup\$

I have been looking around the internet finding articles that talk about what you should learn to develop a game engine. Something that I keep hearing in many articles is that you should learn low-level graphics API's such as OpenGL or D3D11 (great article for example: https://www.haroldserrano.com/blog/how-to-become-a-game-engine-developer) for graphics rendering for instance.

NOTE: I will be using graphics rendering as an example for my question since it makes the most sense to me here.

This got me thinking. Is it really necessary to re-invent the wheel by creating your own framework for just rendering graphics? Isn't it sufficient to learn a library like babylon.js for graphics rendering on the web? If the main goal of creating a game engine is to lay a software framework to build video games, then spending time on developing an entire framework for graphics shouldn't be an issue if others have solved the problem for you via their graphics libraries.

\$\endgroup\$
4
  • \$\begingroup\$ I don't sure you are reinventing the wheel by using "low level" OpenGL/D3D calls, you just gain granular control. The first question you must ask when starting a project is if you want to do the game or the engine. If you want the game grab an engine and start to throw assets at it. You can also get the game by collecting available libraries that exist for everything from physics to input handling. The result is something like an engine with the game's specific logic highly mixed into it. Reusable for other projects after some cleaning. \$\endgroup\$ Commented Nov 13, 2019 at 13:23
  • \$\begingroup\$ For the case of the web I will just add the following warning: while 2D canvas API is fast and reliable, 3D is its opposite. Things have improved over the years but I can hardly trust it yet. If it only works in Windows then how can you call it "for the web"? \$\endgroup\$ Commented Nov 13, 2019 at 13:33
  • \$\begingroup\$ @HatoruHansou I was talking with respect to creating a new game engine that supports everything like assets, game scripting, cross platform, etc. The question in hand was that I didn't understand why people suggest making things like physics and graphics from scratch for these engines, when you could just grab libraries for those things and put and engine together with that. \$\endgroup\$ Commented Nov 14, 2019 at 8:35
  • \$\begingroup\$ Yes, I understood that you want to do the engine. My comment was like saying "do you really want to do the engine? Give it a second thought.", I always try that when somebody bring the engine from scratch topic. As you said, I would just collect libraries for everything except when that is not possible or because I want to write that part myself as a learning experience. \$\endgroup\$ Commented Nov 14, 2019 at 14:28

2 Answers 2

Reset to default
0
\$\begingroup\$

Sure, using libraries other people created in your engine can save you a lot of work. But this can also cause a couple problems.

You are now adding another abstraction layer (your engine API) on top of an already existing abstraction layer (the library). And the user of your engine is likely to add another abstraction layer on top of yours.

A common saying in software architecture is "There is no problem which can not be solved by adding another layer of abstraction, except having too many layers of abstraction". Every layer of abstraction hides certain features of the layer below it. Every layer of abstraction also has a performance penalty. So the more layers of abstraction you have between the end-developer and the underlying graphic hardware, the more performance overhead you end up with and the more features get inaccessible.

And then there are the problems you always have when you add 3rd party dependencies to a software projects:

  • Bugs the maintainers don't get around fixing
  • Missing features the maintainers refuse to add
  • Updates which break your code in unexpected ways
  • Missing or incorrect documentation
  • Compatibility issues with other dependencies
  • License issues
  • The whole library being discontinued

So you might really want to consider if it wouldn't be appropriate to have your engine call OpenGL directly.

\$\endgroup\$
3
  • \$\begingroup\$ This actually answers my question precisely. Not saying that Ian Young's answer was bad, as it did help give an understanding of the purpose of a game engine. I will still accept yours as an answer though. Going back on topic, I think your answer could count mostly for large development teams (I could be wrong) that have the resources to create everything from scratch. But, how do you think this affects small teams that want to get an engine done? This is assuming there are no license issues. \$\endgroup\$ Commented Nov 14, 2019 at 15:33
  • \$\begingroup\$ @AlanRostem I think that small teams shouldn't develop engines in the first place. If you want to license the engine to other developers, then you are on a market where you have no chance to compete with big names like Unity or Unreal. If you want to use it in-house, then it is usually not worth the investment. Either your game is generic enough that it is much cheaper to use a stock engine or your game is so special that its engine wouldn't be reusable anyway. The cost/benefit calculation of an inhouse engine is only positive for really large studios, and even there it's questionable. \$\endgroup\$ Commented Nov 14, 2019 at 15:50
  • \$\begingroup\$ Yes I understand. I also agree on the fact that it can be questionable for large studios since it is way more effective plus you already see pre made engines be used a lot in the industry. I guess the only benefit of an in house engine would be for learning the architechture and design patterns. \$\endgroup\$ Commented Nov 14, 2019 at 16:05
1
\$\begingroup\$

You raise an interesting question, for which there is no definite answer.

The idea of designing an engine is for ease of re-use, and to make it easier for others to use to make games quickly.

With that in mind, an easy to use, high level API is desirable.

Think about a power drill: I do not want, or need, to know how it functions. I Only need to know what it can do, and that it does it quickly, and efficiently.

Engine API's are the same. Someone who is not familiar with graphics programming, but is good at designing games, does not care how a thing gets rendered, just that it does. Thus we take a whole load of DX/OpenGL low level code, and hide it behind RenderObject(Object& o), or we abstract the operating/file system, or the scripting system, or any other number of math/tech heavy subsystems, that a user may only have notional knowledge of.

An engine is a set of tools for making games. Each tool has a lot of work gone into it, and it is complex under the hood.

We create a high level API for each tool, in order for the tools to easily and smoothly interact with one another, and for a user to control easily.

As an engine programmer, it is your job to make your client's (anyone using your engine, including yourself) job that much easier and faster.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for your answer! I think this answers mine, and many other questions along with it. As you said, everything is a tool which is complex under the hood but easy to use by a client, and I, the developer, am responsible for that. \$\endgroup\$ Commented Nov 13, 2019 at 13:06
  • \$\begingroup\$ In some cases, @AlanRostem , you ARE the client. For example, using Unity or Unreal to develop a game. Sure, there are ways of digging deep into the underlying structure of the engin to get extra performance, but 99% of devs won't. There's no need for them to and there's no desire to. It works "good enough." Saying someone should write their own game engine is about as informed as saying you should write your own computer's operating system instead of using Windows and low-level format your hard drive instead of trusting the manufacturer. \$\endgroup\$ Commented Nov 14, 2019 at 19:38

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.