Think twice before using game engines
Holivar about whether to use engines to create games began immediately after the first game engines appeared. This post on reddit is not an ideal example of reasonable counterarguments against the constant use of engines, but I believe that the irresistible desire to use them gives a little fanaticism.
I believe that there is no ready-made answer to the question whether the developer should use the engine. A wise developer, before choosing a technology, evaluates all possible options.
Do you have enough skills to effectively use the selected option? If you have zero experience in programming, you will have to learn a lot before you are ready to create a game from a set of disparate libraries.
If you have neither technical skills nor interest in learning them, then there really are no options - you have to work with the engine (or convince someone to do the technical part for you; good luck with that!).
There is an intermediate state between a complete lack of skills and a professional level. It is mainly located in the country of scripting languages: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D, etc. All of them are for those who wish to obtain a certain level of technical knowledge in order to quickly achieve results.
If you are an experienced / professional programmer who is able to confidently master third-party software, then you can use this skill and decide how minimalist / maximalist your approach will be (whether it is an exclusively minimal SDL or a fully equipped Unreal Engine).
What are your goals in this project? Technologies should maximize their achievement:
If you work more (or plan to work) with developers than alone, then you need to evaluate how other people are interested in technology. If you work with an old engine / framework that everyone hates, then it will be difficult for you to find motivated developers for your project.
Also consider how artists and designers will interact with technology. Do you want to create tools to catch up on Unreal functionality? They will inevitably compare the capabilities of the engine and their own. I heard that even AAA studios have a problem with artists requiring Unreal features that are not yet implemented in the current fork of Unreal studio.
If you work alone, then you need to maintain a strong passion for projects. If you hate the technology with which you work, then most likely give up work. If you give up, then all your efforts will go to dust (with the exception of invaluable experience).
Jonathan Blow has an amazingly wise video about what game engines actually give . They solve “simple” problems for you, but then get in the way when they try to solve a difficult problem, which make up exciting games.
Yes, of course, you get a great editor, professional-level tools and an engine that has come to thousands of developers, but you pay for it with many other aspects:
You need to ask the question: “What do I really need?” Get rid of all that is superfluous. Every unnecessary system is wasted resources and time.
Technology should be managed by your project, unless it is a technology demo. If you are creating a game, then you need to work only with those technologies that influence the game - only with the most necessary to convey your vision. If the engine provides you with the fastest way to release your game, then this is a good choice. But this will not always be!
There are successful games that would serve the poor service of any of the available engines:
When using any technology, it is worth thinking about closure . Joel Spolsky has a series of articles on a business strategy for software development, in which he reflects on the closure on the product . In short, his idea is that companies are interested in holding you to use their product, because if you do not use the product, they do not make money. Masters in capturing entire industries are Apple, Microsoft, Adobe and Autodesk, they create the feeling that there are no other alternatives besides their software.
Closing affects even hobby / solo developers. I have a friend who is constantly struggling with Unity (compatibility-breaking updates, prototyping system, adware, poor 2D support ...). He wants to get away from Unity, but is strongly locked into this engine because most of his code (and data) relies on the Unity API.
Unreal and Unity are driven by market requirements. Their AAA-level customers, with the help of multi-million contracts, determine the course of further development of the engines. If you are working on a game whose structure does not coincide with the goals of these AAA players, then the developers of the engines will not serve you as faithfully. For example, two-dimensional, procedural, experimental, voxel games and games with large amounts of data almost always have to look for something of their own.
The brighter the functions seem, the more the management of companies (which is most often not techies) seeks to use engines. Features such as the Unreal engine’s Blueprints are very popular with artists and designers, but create a lot of problems for programmers. (This is typical of any scripting language; if you allow people who have not studied programming to program, the result will be poor, similar to how bad the graphics drawn by programmers are bad).
Do new features really make it easier to complete your game? Do they really add value to the final product?
Each time one of the studios switches from its own engine to Unreal or Unity, Epic and Unity companies gain even more power in the gaming industry. At first, such centralization may seem profitable (after all, they have 500 engineers working on the engine, excellent!), But in a couple of decades this will become a real problem. Google comes to mind: this company has captured the vast majority of the functions that people use on the Internet, and it cost them the loss of a large share of privacy.
Even at the hobby level, abandoning research in favor of Unreal or Unity harms future generations of engines. This can hurt even Unreal itself: if everyone uses Unreal, Epic will not be able to hire anyone else to create a new generation of the engine, because no one will know how game engines are written!
If we, as an industry, want to grow, creating ever better products, then we need to share more, not less, to share technologies.
I think the industry is moving in this direction, albeit extremely slowly. This is especially true of AAA-level gaming studios, which still hide the code of their engines to gain a (imaginary?) Competitive advantage.
Jonathan Blow and Casey Muratori are ardent critics of modern software writing practices. Their point is that we create add-ons over layers of abstractions for so long that we get huge fragile layers of unnecessary trash, and this does not allow us to write better products.
Perhaps their philosophy is closer to idealism than pragmatism (which usually leads to a delay in the release of games), but if it is close to you, then you should not ignore it.
Do you care about the speed, quality and elegance of your technology? Many people are quite happy with the negative answer, but some want to create programs in a more “clean” way.
Instead of using the engine, you are just writing a game.
Beginners often think that they need an engine to create a game. With a high degree of probability, they should reject this point of view. Beginners will waste time on implementing useless engine functions, rather than letting the game decide for itself what it absolutely needs. Only the game should control what is needed from the engine (of course, Unity can be taken as a counterexample, as an example of the “engine first” approach; Unreal Engine 4 has Paragon, Fortnite and Unreal Tournament to support this concept, not to mention dozens of years of experience releasing an infinite number of games in previous versions of engines).
Starting from scratch only makes sense if you have the skill and plan to create innovation in a particular component (or have limitations). In all other cases, there are many libraries for integration. This is especially good when you know that, for example, the standard physics system is completely suitable for the requirements of your project (this is especially important because to implement your own physics you need a lot of knowledge in this area).
Here are a few libraries that can fill the gap between working from scratch and using a fully finished engine:
This is only a very small fraction of existing libraries.
A big plus in using libraries is that it gives you the greatest flexibility among all the options. If you write all the code in one engine, then you will have to make huge efforts to port it. If you write a game as a collection of libraries, you have great mobility and can replace entire subsystems. If the library does not meet your requirements, then you can try another one or even write your own replacement.
In addition, both Unreal and Unity support the import of dynamically linked libraries. This means that you can start working with libraries, and then switch to Unreal without having to rewrite all the basic code of the gameplay, because it is in the library. For the code to be flexible enough for such huge changes, serious thoughtfulness is required, but I think that it is worth it for an average or long-term project.
I presented several points of view under which technologies can be considered when choosing them. Spend a couple of weeks on a detailed study, and this can save you several months of porting work or even years of inconvenience in the future.
In the end, your main task is to complete the project. You should make every effort to find the shortest path to solving this problem. It may be quite unexpected for you!
Let's reason wisely
I believe that there is no ready-made answer to the question whether the developer should use the engine. A wise developer, before choosing a technology, evaluates all possible options.
Skill level
Do you have enough skills to effectively use the selected option? If you have zero experience in programming, you will have to learn a lot before you are ready to create a game from a set of disparate libraries.
If you have neither technical skills nor interest in learning them, then there really are no options - you have to work with the engine (or convince someone to do the technical part for you; good luck with that!).
There is an intermediate state between a complete lack of skills and a professional level. It is mainly located in the country of scripting languages: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D, etc. All of them are for those who wish to obtain a certain level of technical knowledge in order to quickly achieve results.
If you are an experienced / professional programmer who is able to confidently master third-party software, then you can use this skill and decide how minimalist / maximalist your approach will be (whether it is an exclusively minimal SDL or a fully equipped Unreal Engine).
Development goals
What are your goals in this project? Technologies should maximize their achievement:
- This is a hobby for you and most of all you want to grow as a developer? Perhaps you should stay away from Unity and Unreal and look towards developing games based on lower-level libraries.
- Is this a business for you? At this level, things get a lot more complicated. Options should be evaluated based on many factors: can you hire people familiar with the technology? Do these people want to use technology? Does it fit your time frame? Do you have the skills to use it effectively? Do your artists / designers like technology?
Interest
If you work more (or plan to work) with developers than alone, then you need to evaluate how other people are interested in technology. If you work with an old engine / framework that everyone hates, then it will be difficult for you to find motivated developers for your project.
Also consider how artists and designers will interact with technology. Do you want to create tools to catch up on Unreal functionality? They will inevitably compare the capabilities of the engine and their own. I heard that even AAA studios have a problem with artists requiring Unreal features that are not yet implemented in the current fork of Unreal studio.
If you work alone, then you need to maintain a strong passion for projects. If you hate the technology with which you work, then most likely give up work. If you give up, then all your efforts will go to dust (with the exception of invaluable experience).
What do they really give you?
Jonathan Blow has an amazingly wise video about what game engines actually give . They solve “simple” problems for you, but then get in the way when they try to solve a difficult problem, which make up exciting games.
Yes, of course, you get a great editor, professional-level tools and an engine that has come to thousands of developers, but you pay for it with many other aspects:
- Sometimes the solutions used in it are too generalized: perhaps in your game gravity is applied in a completely new way, but then you have to fight with the rigidly defined Unreal gravity system. Perhaps you are creating a project with a complex network model, and then you have to completely get rid of the Unreal server architecture.
- Sometimes solutions are too specialized: if you ever delved into the guts of the Unreal Engine, you saw that the entire engine is riddled with a first-person shooter code. If you create a game of this genre, then fine. If not, it will only be confusing.
- Sometimes there are too many things in the engine: this puts a strain on both the brain and the computer. Performing a complete simulation of solid-state physics, a 3D pipeline with skeletal animation, and three frameworks is an absolute bust for a 2D game. You’ll have to figure out how to disable all of these Unreal features, good luck with that. Personally, I find that Unreal's performance is disappointing even in test worlds with few objects.
You need to ask the question: “What do I really need?” Get rid of all that is superfluous. Every unnecessary system is wasted resources and time.
What is needed for your project?
Technology should be managed by your project, unless it is a technology demo. If you are creating a game, then you need to work only with those technologies that influence the game - only with the most necessary to convey your vision. If the engine provides you with the fastest way to release your game, then this is a good choice. But this will not always be!
There are successful games that would serve the poor service of any of the available engines:
- For Dreams , a custom renderer was written that simplifies and speeds up the intuitive creation of 3D assets.
- No Man's Sky is actively using completely new methods of procedural generation. When implementing such things in the engine, you would have to constantly deal with it.
- In Minecraft , only a few of the features of standard engines could be used.
The future of your (and our) industry
When using any technology, it is worth thinking about closure . Joel Spolsky has a series of articles on a business strategy for software development, in which he reflects on the closure on the product . In short, his idea is that companies are interested in holding you to use their product, because if you do not use the product, they do not make money. Masters in capturing entire industries are Apple, Microsoft, Adobe and Autodesk, they create the feeling that there are no other alternatives besides their software.
Closing affects even hobby / solo developers. I have a friend who is constantly struggling with Unity (compatibility-breaking updates, prototyping system, adware, poor 2D support ...). He wants to get away from Unity, but is strongly locked into this engine because most of his code (and data) relies on the Unity API.
Why do engines buy?
Unreal and Unity are driven by market requirements. Their AAA-level customers, with the help of multi-million contracts, determine the course of further development of the engines. If you are working on a game whose structure does not coincide with the goals of these AAA players, then the developers of the engines will not serve you as faithfully. For example, two-dimensional, procedural, experimental, voxel games and games with large amounts of data almost always have to look for something of their own.
The brighter the functions seem, the more the management of companies (which is most often not techies) seeks to use engines. Features such as the Unreal engine’s Blueprints are very popular with artists and designers, but create a lot of problems for programmers. (This is typical of any scripting language; if you allow people who have not studied programming to program, the result will be poor, similar to how bad the graphics drawn by programmers are bad).
Do new features really make it easier to complete your game? Do they really add value to the final product?
Fight Centralization
Each time one of the studios switches from its own engine to Unreal or Unity, Epic and Unity companies gain even more power in the gaming industry. At first, such centralization may seem profitable (after all, they have 500 engineers working on the engine, excellent!), But in a couple of decades this will become a real problem. Google comes to mind: this company has captured the vast majority of the functions that people use on the Internet, and it cost them the loss of a large share of privacy.
Even at the hobby level, abandoning research in favor of Unreal or Unity harms future generations of engines. This can hurt even Unreal itself: if everyone uses Unreal, Epic will not be able to hire anyone else to create a new generation of the engine, because no one will know how game engines are written!
The future may be open source
If we, as an industry, want to grow, creating ever better products, then we need to share more, not less, to share technologies.
I think the industry is moving in this direction, albeit extremely slowly. This is especially true of AAA-level gaming studios, which still hide the code of their engines to gain a (imaginary?) Competitive advantage.
- Microsoft has taken huge steps in this direction. If even they change, then I’m sure that others can.
- The Unreal license agreement contains a clause that allows you to rely on its code when working on its own (proprietary or free) engine. I think this is a big progress.
- Due to its full openness and free access, Godot is gaining great popularity, and I hope that if he is given enough time and support, he will become a competitor to Unity (and eventually Unreal).
- id Software (in the era of John Carmack) released the full source code from Doom to Doom 3 . Carmack had many reasons to advance such a decision. The most convincing of these for companies is that it does not harm sales. The shareware model used by Doom - the developer gives the engine and sells data - can be an effective strategy today. If your business is worried that competitors will “steal” your technology, you can publish your code after a newer game is released after it (as id did). After Carmack's departure, id seems to have lost interest in publishing code.
Software quality
Jonathan Blow and Casey Muratori are ardent critics of modern software writing practices. Their point is that we create add-ons over layers of abstractions for so long that we get huge fragile layers of unnecessary trash, and this does not allow us to write better products.
Perhaps their philosophy is closer to idealism than pragmatism (which usually leads to a delay in the release of games), but if it is close to you, then you should not ignore it.
Do you care about the speed, quality and elegance of your technology? Many people are quite happy with the negative answer, but some want to create programs in a more “clean” way.
What are the alternatives?
Instead of using the engine, you are just writing a game.
Beginners often think that they need an engine to create a game. With a high degree of probability, they should reject this point of view. Beginners will waste time on implementing useless engine functions, rather than letting the game decide for itself what it absolutely needs. Only the game should control what is needed from the engine (of course, Unity can be taken as a counterexample, as an example of the “engine first” approach; Unreal Engine 4 has Paragon, Fortnite and Unreal Tournament to support this concept, not to mention dozens of years of experience releasing an infinite number of games in previous versions of engines).
Using libraries
Starting from scratch only makes sense if you have the skill and plan to create innovation in a particular component (or have limitations). In all other cases, there are many libraries for integration. This is especially good when you know that, for example, the standard physics system is completely suitable for the requirements of your project (this is especially important because to implement your own physics you need a lot of knowledge in this area).
Here are a few libraries that can fill the gap between working from scratch and using a fully finished engine:
- Graphics: SDL, SFML, Ogre
- Physics: Bullet, PhysX (which recently became open source - a huge victory!)
- Sound: SDL, SFML
This is only a very small fraction of existing libraries.
A big plus in using libraries is that it gives you the greatest flexibility among all the options. If you write all the code in one engine, then you will have to make huge efforts to port it. If you write a game as a collection of libraries, you have great mobility and can replace entire subsystems. If the library does not meet your requirements, then you can try another one or even write your own replacement.
In addition, both Unreal and Unity support the import of dynamically linked libraries. This means that you can start working with libraries, and then switch to Unreal without having to rewrite all the basic code of the gameplay, because it is in the library. For the code to be flexible enough for such huge changes, serious thoughtfulness is required, but I think that it is worth it for an average or long-term project.
Finally
I presented several points of view under which technologies can be considered when choosing them. Spend a couple of weeks on a detailed study, and this can save you several months of porting work or even years of inconvenience in the future.
In the end, your main task is to complete the project. You should make every effort to find the shortest path to solving this problem. It may be quite unexpected for you!
All Articles