These days there are many game engines. Two-dimensional, three-dimensional, native and scripted. At first glance, everything that has been done is already done and you can just make the game. However, according to statistics, about half of the top 100 mobile games are made on their own engines. Why do many large studios make projects exclusively on their technologies? What does not suit them in those engines that are now? To answer this question you need to understand why you need an engine, what they generally are and how they differ.

The game engine for the developer is a tool. Like a hammer for a carpenter or a racing car for a pilot, the tool affects success. Of course, not always. It happens that masterpieces are made on weak technologies, and frankly failed projects are made on hight-end engines. But “on average over the hospital,” the choice of tool pretty much affects success. To understand how much, you need to understand why and how games are made.

Big goal

So why are we making games? Everyone has different goals, someone does just for fun, someone to make a lot of money. But still in most cases they want to make money on the game. Consider exactly how the engine affects this goal. For this, it is necessary to recall the elementary formula of how the very money is obtained, or, more correctly expressed, profit.

Profit = Income - Expense

Now we will consider in detail each component and how the engine affects them. And then we define some metrics by which we briefly evaluate the existing engines.

Costs

Any developers strive to reduce these costs. For small developers, costs can become fatal, and the project will not even see the light of day. Big developers are also interested in reducing costs, because you can make a project faster, check it out, enter the market earlier than others, or just try a lot more ideas for the same money.

We analyze the development costs in more detail. They include many things, such as marketing, payment for equipment, remuneration of labor and so on. In different projects, in different ways, but as a rule, remuneration is one of the largest items in the project budget. How does the engine affect development costs? Again a small formula:

Remuneration = (Cost of a specialist 1 + Cost of a specialist 2 + ...) * Development time

It looks simple. Based on the formula, it can be seen that there are actually two values ​​that can be affected: the cost of specialists and the development time. We reduce the cost of a specialist, reduce the development time - and our project has become cheaper! But how to make a specialist cheaper? How to make it work faster? The answer is the right choice of technology and the correct setting of work.

The right set of tools allows you to find the right specialist for a particular job. Ideally, the artist draws, the programmer writes the code, the layout designer typeset, the animator animates, the technical designer adjusts the content, in general, everyone is busy with his own business. However, in reality it very often happens that programmers are busy with everything - layout, animation, resource tuning. And not even because there is nobody to do it, but because only he can assemble the interface and animate it through the code. For certain jobs, specific tools are still needed.

Hence the first metric of the engine is the toolkit. The availability of tools allows you to hire an appropriate specialist who will be better and faster to cope with their work. Naturally, completely different tools are needed for different games, but there are general ones that are necessary for everyone: resource adjusters, animations, effects, graphics, physics, sound, interfaces. All this can be done with code, but, as practice shows, this is rather inefficient.

In addition to common tools, almost every game has some specifics that require special tools, for example, a level editor or a configuration editor for game objects. Here you can highlight such a metric as the flexibility of the engine - this is the opportunity to adapt it to your specific needs with minimal cost.

Next, development time. I propose to decompose it into two components: the time of the operation and the number of repetitions. Consider the example of interfaces. If you have a special interface editor, then the layout in it will be much faster than in a text file or in code. Accordingly, the time for the layout operation will be less. If it is possible to work with templates, then the number of operations of the same type will be less. Simply put, the simpler, more convenient and thoughtful the tool, the faster development will take place. And this is the next metric - the convenience of tools or usiabilityas they call it more often. Here, many may notice that in many indie teams there are no specialized people and anyway the programmer does everything. Which is more convenient to write code. The topic is quite controversial, but I saw a bunch of examples where the same programmers make content much better and faster in special editors than with code.

Naturally, even if you remove the maximum of unnecessary tasks from the programmer, he still needs to write code. From the experience of game development, I can say that 80% of all time is a boring routine that needs to be done quickly and not particularly caring about performance. Dialogs, client-server interactions, scripts and stuff like that. Here you can highlight another metric - the complexity of developing game logic. It describes how difficult it will be to develop most of the code, those same 80% of the routine. Usually scripts are best suited for this. And the remaining 20% ​​are just those bottlenecks that require flexible optimization and tuning. Which, in fact, also refers to the metric of flexibility .

The input threshold of engine complexity also affects the price of a specialist . The easier it is to use it, the more specialists, the cheaper and easier to find them. However, too low a threshold very often means limited engine.

Also, at the time of development, such a metric as portability can be attributed.- the ability to apply the same solution on different platforms, instead of implementing each separately. If you make a game on several platforms at once, time costs are reduced in proportion to the number of platforms covered.

Income

Everything here is not so obvious as with the costs. To begin, consider what the income from the game is made up of. And again, the formula is very simplified, but to a greater extent reflects the result:

Income = Average income per user * Number of users

Again, there are two values ​​that can be influenced. So, how does the engine affect average user revenue? Here is a rather indirect connection, and often it is not at all. But we are considering the "average for the hospital", so we will not discard it.

There are many factors that make up this income: player involvement, game interest, the need to pay for promotion, the ability to pay, time spent in the game, and so on. There are a lot of factors, they are always different, at least it’s very difficult to say about the amount of income and few people can do it well.

One of the factors affecting the success and profitability of a game is its quality. Beautiful art, smooth animations, good effects, interesting gameplay - all this affects the player’s opinion, his desire to stay in the game. And this is directly affected by the engine. We have already considered that the toolkitnecessary for effective development, but also necessary for the development of quality content. Beautiful animations, interfaces, effects, scenes: all this is difficult to do without good tools. A bad tool is like a bicycle with oval wheels, which is quite difficult to drive away. However, quite often, developers ride such bikes: the programmer sculpts awkward animations on his favorite sines and cosines, the designer typeset the level in a text file, and so on. All this does not lead to a qualitative result. Therefore, tools are important.

In addition to tools, performance also affects quality .engine. The game may have great content, beautiful art and cool effects, but it all disappears when the game starts to slow down. The player is not comfortable playing, the interface becomes unresponsive, animations do not produce the desired effect. Also, performance affects how rich the content in the game will be. With an unsuitable approach, we can show N sprites and X animations, and with an optimized engine we can show more. This does not always produce the desired effect and is sometimes unnecessary, but it gives greater freedom of action, more opportunities to realize your ideas.

Also, performance affects player retention. On average, a new player installs a game and decides to remove it within 20-30 seconds. Making him wait for the game to load at this time is not a good solution. Also, the size of the game affects the entry threshold. Few people want to download a 200MB game on the mobile Internet. Energy costs in the game also affect. Many players start the game on the phone on the way home, and if the battery level is low and your game is spending a lot, the player would rather stay in touch than play your game. Actually, the time that he prefers to spend in the game will decrease if he knows that the battery of the device will inevitably run out. There is only one conclusion from this - we must try to save resources.

Let's move on to the next part of the formula - audience coverage. Here the metrics are understandable. It is performance and portability . The more platforms, the more devices are covered, and accordingly the users. The better the performance, the weaker the devices support the game and more players can run your game. You can hope that your players have a brand new Apple product in their pockets, but statistics show that there are few new devices, everyone comes with outdated "middle peasants". About the same situation on Android.

Preliminary result

Now we have a rough idea of ​​what metrics the engines have and how they affect the success of the game:

• Entry threshold
• Tools
• Usability
• The difficulty of developing game logic
• Flexibility
• Portability
• Performance

Based on this list, we evaluate the existing engines. I propose to consider only the most significant, based on statistics compiled by Unity3D, with a few of my additions.


The opinion below should not be considered as 100% truth, it is compiled by me and may not fully reflect reality.


Perhaps so far few people have tried this engine, but it is developing and getting better. It has a good all-in-one editor where you can find everything you need. Game code is written in an internal scripting language similar to Python. The developers claim that it is possible to optimize parts of the game in C ++, or to make additions to the editor.

• The input threshold,
  despite the simplicity of the engine, is quite high. Firstly, it has its own scripting engine. Secondly, few documentation and examples.
• The toolkit
  is all that is needed, and you can also make your own
• Usability
  is also affected by poor documentation and a small number of examples. But in general, the toolkit leaves an impression of thoughtlessness and inconvenience
• The complexity of developing game logic
  scripts are similar to Python, which means they are simple to write, but nevertheless their own language, so it is unlikely to just find some solution on the network
• Flexibility
  game logic is written in scripts, the source code is open source. In theory, you can do anything, but in practice, as I heard, they are difficult to combine
• Portability is
  ported to all necessary platforms.
• Performance
  considering scripts, you should not count on high performance

King’s internal corporate engine, which they decided to bring to light. Has appeared in the public domain relatively recently, the community is developing rapidly. Under the hood, according to the developers, everything is optimized as much as possible. Game logic is written in LUA scripts. There is an all-in-one editor, but rather limited in functionality.

• The entry threshold is
  pretty low due to LUA scripts and a fast-growing community
• The toolkit
  is a single editor, but a lot is missing, for example, animations, a full-fledged component system
• Usability,
  this engine has grown as a corporate engine studio King, respectively, it was not originally aimed at a wide audience. Therefore, the tools are somewhat specific and limited.
• The complexity of developing game logic
  LUA is one of the best scripting languages, it is very common and easy to learn. However, in my experience, large projects using pure LUA scripts are difficult to write.
• The flexibility of the
  engine is quite limited by the paradigms given by the creators. One of them is game logic written in LUA. Although it is possible to include native code, the emphasis is precisely on the fact that the game is written in LUA, and this language does not allow you to make really quick decisions. Another paradigm is eternal full backward compatibility. Of course, it’s good that the project on the first version of the engine will work without problems on the last. However, in this way it is necessary to support old decisions, which slows down the introduction of new ones and, accordingly, slows down the development
• Portability is
  well ported to all platforms. And even on the Web
• 
  LUA performance is a very fast scripting language, but, nevertheless, remains a scripting language, which directly affects the performance of the game code. However, the remaining components of the engine, according to the creators, are made as efficiently as possible.

Professional game engine at the peak of technology. Great picture, performance, a tool for true professionals. However, in mobile development it is difficult to apply. Nevertheless, it is more designed for three-dimensional AAA games. Making mobile 2D games on it is like a cannon sparrow.

• The entry threshold is
  very high. You will need real experts in their field, both from the side of game content and from programmers
• Toolkit The
  toolbox is truly impressive, from the particle editor to character animations.
• Usability is
  sure for professionals it is super optimal. However, in the hands of non-professionals, the result is not very high quality and long
• The complexity of developing game logic
  in Unreal game logic is written in either C ++ or Blueprints. In fact, you can’t write the whole game on Blueprint, it’s very voluminous and confusing, but I think it’s not worth talking about C ++. According to the developers, everything works like this: C ++ programmers write the kernel and “blocks” for Blueprint, and the designers of these blocks are game mechanics. I am sure this is a great approach for a 3D shooter, but it is unlikely to just put a bunch of logic, for example, on interfaces. And sometimes most of the game is interfaces
• Flexibility
  architecture and C ++ give unlimited possibilities in development, however, again a bias in three-dimensional projects. Two-dimensional games for creators have never been a priority
• Portability
  Now Unreal runs on all mobile platforms, but there are rumors of numerous issues such as application size
• Performance
  Some of the best engineers in the gaming industry have developed a native engine, all this suggests that you can squeeze everything from iron to the last drop

Completely free and open source engine. There is an all-in-one editor, documentation and a bunch of examples. Game logic is written in C ++ or in JavaScript. A lot of projects have been released on it, a distinctive feature of these projects is good optimization. However, with a more detailed examination, the editor is not as convenient as it seems at first glance, there are a lot of flaws in the source and there are a lot of things to do.

• The input threshold is
  quite high, because for quality development you need knowledge of C ++ and a pretty good understanding of how games are made
• Toolkit
  is almost everything you need
• Usability is
  very doubtful, in my opinion. A lot has been copied from other technologies, but without much thought, why and why. In the end, it is very specific and a little divorced from real tasks. A bunch of console utilities are also not associated with convenience
• The complexity of developing game logic
  is mainly used by C ++, but it is also possible to use JavaScript. However, using them together is somewhat difficult
• Flexibility,
  open source and C ++ let you do anything
• Portability
  all mobile platforms
• Because
  of its simplicity and flexibility, performance can achieve very good results.

Game maker / Construct and similar

Engines of this kind were created so that anyone could make their own game, without any knowledge of development. Everything is as simple and straightforward as possible, these engines can handle this superbly. However, for large or even medium-sized projects, they are poorly suited.

• Input threshold
  is minimal
• The toolkit
  has everything you need to create small or simple games. It’s most convenient to make pixel-art games on them
• Usability is
  worth a look at the Game Maker 2 editor! Perhaps the best solution for the engine in this category. Very thought out and designed for the target audience
• The complexity of developing game logic is
  either an elementary script, or no scripts at all. Instead of scripts, a reaction-action system is used, which describes all the game interaction
• Flexibility is
  very limited functionality, but for simple games enough
• Portability
  all mobile platforms
• Productivity is
  naturally the paradigm of developing such simple projects requires a lot of additional resources. As a rule, developers go from such engines to lower-level ones when faced with poor performance.

The most common engine these days. And there is a reason for this - it is very convenient. Great editor, almost unlimited possibilities, 2D, 3D graphics, whatever you want. And of course C #, with which development is pretty easy. However, he also has skeletons in the closet. Often, performance is poor. I agree, if you make an effort, you can do a lot, but the price is high. In addition, sometimes the plans of developers for the development of the engine are not clear. The most necessary things remain at the bottom of the roadmap, but in newer and newer versions there appears what sounds great on the selling page, but not everyone needs to be in development.

• The entry threshold is
  very low. You will make your first game in a couple of tutorials. Huge community, lots of affordable solutions
• The toolkit
  is absolutely everything, some are even redundant on most projects. And if you don’t need the engine, you’ll probably find it in the store
• Usability
  is the biggest plus of the engine. Great tools speed up development at times. However, with deeper use, shortcomings emerge, for example: in some places the not obvious logic of the UI, not well-designed animations. Some things users ask for a very long time, but developers can’t do anything. In general, for the development of mobile games - the best you can find
• The complexity of developing game logic
  C #, although somewhat specific to Unity, is a very convenient language. Very often I hear from C ++ programmers the opinion that this is a "breath of fresh air." From personal experience I want to note that development in C # is several times faster than in C ++
• Flexibility
  very flexible tools and the architecture of the engine as a whole. However, in many things it remains unavailable for change. Closed code gives some kind of black box effect, which is often impossible to influence. There is freedom for optimizations, but subtle optimizations cannot be made as a consequence of their closeness.
• Portability is
  ported to everything possible; rumor has it that soon it will be possible to run vacuum cleaners
• Performance
  in general, the engine is very well optimized, and with due diligence, you can make a productive game on it. However, C # is pretty restrictive. Sometimes you think much more about C # code about its performance than over C ++. And usually in the game there is a place where performance sags. In such cases, a lot of resources are spent on optimization. Almost always there are performance problems associated with the UI. Complex dialogs, long lists without optimizations quite heavily load the system.

Own engines, C ++

The choice of either large studios or madmen. To do this, we need cool specialists, but they are few and they are expensive. But in the end, it turns out frankinshtein from technology, which now and then falls apart. It turns out a very incorrectly delivered development, most often it is those dear programmers who do everything. But it turns out the most ideal product. All that the designers wanted was implemented, it works as smoothly as possible and runs on ancient devices. But the price for such technology is high.

• The entry threshold is
  very high, there is no documentation, the only way to find out how everything works through colleagues
• 
  As a rule, toolkit in such tool engines is either not present, or there are elementary editors that satisfy some specific needs. It is on these engines that programmers usually do everything. After all, it is extremely difficult for an ordinary designer to understand all these technical wilds
• Usability,
  even if there are tools, they work frankly poorly. It’s understandable, because such engines are written to make the game, and the game needs to be made faster, hence the low quality of tools, a bunch of bugs, console utilities and all this. But even if there are some tools, they were written by programmers without taking into account the fact that they would not be used by programmers, as a result, the effects editor turns into a space shuttle launch panel, and not into a beautiful interface with three buttons.
• It is very difficult
  to start the development of game logic with such engines, because first you need to understand its structure, all its hacks and rakes. But then it only plays into the hands. As a rule, such engines are made with a bias for the game on which they are made, so over time it is easier and easier to write code. Especially if some scripting language is screwed.
• Flexibility is
  actually the most important advantage of such engines. The developer is limited only by himself, he can do anything.
• Portability
  As a rule, such engines are ported only to those platforms on which the game is released. It is understandable why spend time supporting the platform if it is not planned to release a game on it. However, I have noticed with experience that in such engines operations with platforms are very slow, assemblies are very complex and lengthy.
• Performance
  obviously those who are able to write their own engine are pretty well versed in their topic. There are no restrictions. Accordingly, you can do anything for the sake of productivity and achieve the perfect result.

So still, why do you need one more?

From a brief description of those above, it becomes clear that there is no solution that will satisfy all needs. Each of them has some drawbacks, whether it is convenience or performance. Let's try to imagine the very ideal that will satisfy all our needs, it will turn out to be that very “silver bullet”.

Obviously, it should combine qualities that are very difficult to combine. It should be simple, but at the same time flexible. This can be solved by building a system where top-level components are based on low-level ones. For example, there is some very flexible low-level framework, and on top of it are some upper-level things like an editor and scripts. That is, the upper level provides convenience and is designed for most tasks, and the lower level can be resorted to in search of more effective solutions.

Moreover, the low level should be really low, and not just provide a good API. Everything should be as transparent as possible for the developer here. If there is even a small black box effect, the developer will not be able to absolutely control the system, and accordingly achieve the maximum result. The only way to do this, in my opinion, is open source.

The upper level should also be thought out enough to perform its function well. Many developers of In-house engines here make the same mistake, they bring different technologies together and build connections between them. However, as practice shows, this leads to the fact that they interact poorly. A more specific example: importing animations from a third-party editor and particle effects from another. As soon as it becomes necessary to use the effect in the animation, problems begin. In the animation editor, particles are not played and vice versa. Accordingly, the final result is achieved by the designer rather hard. Therefore, everything should be in one system so that the designer can animate, impose sound, effects and all at once, in one place.

However, the ideal can be described in paints for a long time, so let's return to the specifics and analyze in order our metrics:

• The entry threshold is
  as low as possible. The system, where the “upper” level is kept at the “lower” one, completely makes it possible to lower the input threshold, while not limiting the flexibility
• The toolkit
  should be all the most necessary: ​​work with resources, graphics, animations, interfaces, effects, physics, a competent layout of the scene. Ideally, this should all be in one system, so that each of the components fits perfectly together
• Usability of
  each tool should be thought out by the real use. It’s not enough just to make a particle, interface, or animation editor. All this should be clear and convenient for those who specialize in this.
• The complexity of developing game logic,
  as described above, high-level components should be based on low-level ones. For example, all costly and low-level things are done with native code, those same 20% compound percent. The remaining 80% can be transferred to scripts that are much faster to write, but their performance is not critical. Fortunately, there are a lot of embedded scripts these days
• The flexibility of the
  engine must be fully modifiable and complemented. The only right way to do this is with a good API and open source.
• Portability,
  since it is mainly about mobile development, applications on the engine should be easily ported to all mobile platforms. In addition to mobile platforms, the web platform is becoming increasingly attractive. With the development of WebAssembly and graphics in browsers, it is becoming more and more realistic to launch native games in a browser and on mobile platforms
• Performance
  The technology itself should provide the most optimized components - the interface, animations, effects, and so on. So that with the thoughtless filling of the game with content, everything would be more or less acceptable in terms of optimality. But it’s also worth leaving the opportunity for subtle optimization, which will be needed to bring the product to the ideal

Total

Ultimately, an engine that will be better can still appear these days. But this opinion is only one, me. Although the experience of developing on different engines gives me an idea of ​​the tool that I would consider ideal, I would like to know the opinions of others in this regard. I think it will be interesting to many if someone else in the comments writes their opinion on some engine. Perhaps it will even be useful to those who still choose the engine on which they want to make the game.