Why in 2017 to write your own engine for mobile games?
These days there are a lot of game engines. Two-dimensional, three-dimensional, native and on scripts. At first glance, everything that has been done has already been done and you can just make a game. However, according to statistics, about half of the top 100 mobile games are made on their engines. Why do many large studios do projects exclusively on their technology? What does not suit them in those engines that now have? 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 influences success. Of course, not always. It happens that on weak technologies they make masterpieces, and on high-end engines they make frankly failed projects. But “on average in the hospital”, the choice of instrument rather significantly influences success. To understand how much, you need to understand why and how the games are made.
So why do we make games? Everyone has different goals, someone makes 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 the achievement of this goal. For this, it is necessary to recall the elementary formula of how that very money is obtained, or, more correctly speaking, profit.
Profit = Income - Expense
')
Now we will consider in detail each component and how the engine affects them. And then we will define some metrics by which we will briefly evaluate the existing engines.
Any developers seek to reduce these costs. For small developers, costs can be fatal, and the project won't even see the light. Big developers are also interested in reducing costs, because you can make a project faster, check it out, go to the market before others, or just try a lot more ideas for the same money.
We analyze the development costs in more detail. They include a lot of things, such as marketing, payment for equipment, wages, and so on. In different projects in different ways, but as a rule, wages are one of the largest items of the project budget. How does the engine affect the cost of development? Again a small formula:
Remuneration = (Cost of a specialist 1 + Cost of a specialist 2 + ...) * Development time
It looks easy. Based on the formula, it is clear that there are actually two values ​​that can be influenced: the cost of specialists and the development time. We reduce the cost of a specialist, reduce development time - and our project has fallen in price! But how to make a specialist cheaper? How to make it work faster? The answer is the right choice of technology and the right formulation 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 typesetter makes up, the animator animates, the technical designer adjusts the content, in general, everyone is busy with his own business. However, in reality, it often happens that programmers are busy with everything - layout, animation, setting up resources. And not even because there is no one to do it, but because only he can assemble the interface and zanify it through code. Specific tools are still required for certain works.
Hence the first metric of the engine - the toolkit . Availability of tools allows you to hire the 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 common ones that are necessary for everyone: resource tuners, animations, effects, graphics, physics, sound, and interfaces. All this can be done by code, but, as practice shows, it is rather inefficient.
In addition to general tools, almost every game has some specific features that require special tools, such as a level editor or a configuration editor for game objects. Here you can highlight this metric as the engine's flexibility - it is an opportunity to tailor it to your specific needs with minimal cost.
Next, the 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 there is an opportunity 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 the development will take place. And this is the next metric - the convenience of the toolkit or usiability , as it is often called. Here many may notice that in many indie teams there are no specialized people and still the programmer does everything. Which is more convenient to write code. The topic is quite controversial, but I have seen a bunch of examples where the same programmers make content much better and faster in special editors than with the help of code.
Naturally, even if you remove the maximum 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 without much concern for performance. Dialogues, client-server interactions, scripts and stuff like that. Here you can highlight another metric - the complexity of the development of game logic . It describes how complex the development of most of the code will be, those same 80% of the routine. Usually scripts are best suited for this. And the remaining 20% ​​are precisely those bottlenecks that require flexible optimization and tuning. What, in fact, also applies to the metric of flexibility .
The price of a specialist is also influenced by the input threshold of engine complexity. The easier it is to use it, the more specialists, the cheaper and easier to find them. However, too low a threshold often means that the engine is limited.
Also by the time of development can be attributed to such a metric as portability - the ability to apply the same solution on different platforms, instead of implementing on each separately. If you make a game on several platforms at once, time costs are reduced in proportion to the number of platforms covered.
Everything here is not as obvious as with expenses. For a start, let's look at what is the income from the game. And again the formula, very simplified, but to a greater extent reflects the result:
Revenue = Average User Revenue * Number of Users
Again, two quantities that can be influenced. So, how does the engine affect the average revenue per user? There is a rather indirect connection, and often there is none at all. But we are considering the "hospital average", so we will not reject.
There are many factors that make up this income: the involvement of the player, the interest of the game, the need to pay for the promotion, the ability to pay, the time spent in the game and so on. There are a lot of factors, they are always different, at least to say something about the amount of income is very difficult and very few people know how to do it well.
One of the factors affecting the success and profitability of the game is its quality. Beautiful art, smooth animations, good effects, interesting gameplay - all this influences 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 toolkit is necessary for effective development, but it is also necessary for developing high-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, on which it is quite difficult to go somewhere. However, quite often developers ride such bicycles: the programmer makes awkward animations on his favorite sines and cosines, the designer imposes a level in a text file, and so on. All this does not lead to quality results. Therefore, the toolbox is important.
In addition to tools, quality is affected by engine performance . Let the game have great content, beautiful art and great effects, but all this disappears when the game starts to slow down. The player is not comfortable to play, the interface becomes non-responsive, animations do not produce the proper effect. Performance also affects how rich the game will be. With a non-optimal approach, we can show N sprites and X animations, and with an optimized engine we can show more. It does not always produce the desired effect and sometimes unnecessarily, but it gives more freedom of action, more opportunities to realize your ideas.
Performance also affects player retention. On average, a new player installs the game and decides on its removal within 20-30 seconds. Making it wait for the game to load at this time is not a good decision. Also the size of the game affects the threshold of entry. Few people want to download the game size of 200MB on the mobile Internet. Energy costs in the game also affect. Many players run the game on the phone on the way home, and if the battery level is low and your game spends it much, the player would rather stay connected than play your game. Actually, the time that he chooses to spend in the game will decrease if he knows that the device battery will inevitably sit down. The conclusion from this one - you need to try to save resources.
Let's move on to the next part of the formula - audience reach. Here the metrics are quite understandable. This is performance and portability . The more platforms, the more devices are covered, and accordingly users. The better the performance, the weaker the devices support the game and more players can play your game. You can hope that your players have a new Apple product in their pockets, but statistics show that there are few new devices, everyone goes with the outdated “middling”. Approximately the same situation on Android.
Now we have a rough idea of ​​what metrics engines have and how they affect the success of the game:
Based on this list, we estimate the existing engines. I propose to consider only the most significant, based on the statistics collected by Unity3D, with a few of my additions.
The opinion below should not be considered as 100% true, it is compiled by me and may not fully reflect reality
Perhaps so far, few people have tasted this engine, but it is developing and getting better. It has a good all-in-one editor in which you will find everything you need. The 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 for the editor.
Internal corporate engine from King, which they decided to bring to the light. Appeared in the public domain relatively recently, the community is developing rapidly. Under the hood, he, 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.
Professional game engine at the height of technology. Excellent picture, performance, tool for real professionals. However, it is difficult to use it in mobile development. Yet it is more designed for three-dimensional AAA games. Doing mobile 2D games on it is like a cannon on sparrows.
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 on it are released, a distinctive feature of these projects is a good optimization. However, upon closer examination, the editor is not as convenient as it seems at first glance, there are a lot of shortcomings in the source code and you have to finish a lot of things.
The engines of this kind were created so that anyone could make their own game, without any knowledge of the development. Everything is as simple and straightforward as possible, these engines do great with this. However, for large or even medium-sized projects, they are poorly suited.
The most common in our days engine. And this is the reason - it is very convenient. Great editor, almost unlimited possibilities, 2D, 3D graphics, anything you want. And of course, C #, with which development is pretty easy. However, he also has skeletons in the closet. Often productivity leaves much to be desired. I agree, if you make an effort, you can do a lot, but the price is high. In addition, sometimes incomprehensible plans for the development of developers engine. The most necessary things remain at the bottom of the roadmap, but in new and new versions there appears something that sounds great on the selling page, but not everyone needs to be developed.
The choice of either large studios or madmen. For this, we need cool specialists, but they are few and costly. And as a result, Frankinstein from technology is obtained, which is constantly falling apart. It turns out a very wrong development, most often it is those expensive programmers who do everything. But it turns out the most ideal product. All that the designers want is implemented, works as smoothly as possible and runs on ancient devices. But the price for such technology is high.
According to a brief description of those above, it becomes clear that there is no solution that will satisfy all needs. Each of them has some disadvantages, be it convenience or performance. Let's try to imagine the very ideal that will satisfy all our needs, it will turn out to be the very “silver bullet”.
Obviously, he must 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 top-level things like an editor and scripts. That is, the upper level provides convenience and is designed for most tasks, and you can resort to the lower one in search of more efficient solutions.
Moreover, the low level should be really low, and not just provide a good API. Here everything should be as transparent as possible for the developer.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 this, in my opinion, is open source.
The top level should be well thought out enough to perform its function well. Many developers of In-house engines here make the same mistake; they put 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 animation, problems begin. Particles are not played in the animation editor 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, superimpose sound, effects, and all at once, in one place.
However, the ideal can be described in colors for a long time, so let's return to the specifics and analyze in order according to our metrics:
In the end, there may still be a better engine nowadays. But this is only one opinion, 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 opinion of others on this matter. I think it will be interesting to many if someone else in the comments writes his opinion on some kind of engine. It may even be useful to those who still choose the engine on which they want to make the game.
The game engine for the developer is a tool. Like a hammer for a carpenter or a racing car for a pilot, the tool influences success. Of course, not always. It happens that on weak technologies they make masterpieces, and on high-end engines they make frankly failed projects. But “on average in the hospital”, the choice of instrument rather significantly influences success. To understand how much, you need to understand why and how the games are made.
Big goal
So why do we make games? Everyone has different goals, someone makes 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 the achievement of this goal. For this, it is necessary to recall the elementary formula of how that very money is obtained, or, more correctly speaking, profit.
Profit = Income - Expense
')
Now we will consider in detail each component and how the engine affects them. And then we will define some metrics by which we will briefly evaluate the existing engines.
Costs
Any developers seek to reduce these costs. For small developers, costs can be fatal, and the project won't even see the light. Big developers are also interested in reducing costs, because you can make a project faster, check it out, go to the market before others, or just try a lot more ideas for the same money.
We analyze the development costs in more detail. They include a lot of things, such as marketing, payment for equipment, wages, and so on. In different projects in different ways, but as a rule, wages are one of the largest items of the project budget. How does the engine affect the cost of development? Again a small formula:
Remuneration = (Cost of a specialist 1 + Cost of a specialist 2 + ...) * Development time
It looks easy. Based on the formula, it is clear that there are actually two values ​​that can be influenced: the cost of specialists and the development time. We reduce the cost of a specialist, reduce development time - and our project has fallen in price! But how to make a specialist cheaper? How to make it work faster? The answer is the right choice of technology and the right formulation 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 typesetter makes up, the animator animates, the technical designer adjusts the content, in general, everyone is busy with his own business. However, in reality, it often happens that programmers are busy with everything - layout, animation, setting up resources. And not even because there is no one to do it, but because only he can assemble the interface and zanify it through code. Specific tools are still required for certain works.
Hence the first metric of the engine - the toolkit . Availability of tools allows you to hire the 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 common ones that are necessary for everyone: resource tuners, animations, effects, graphics, physics, sound, and interfaces. All this can be done by code, but, as practice shows, it is rather inefficient.
In addition to general tools, almost every game has some specific features that require special tools, such as a level editor or a configuration editor for game objects. Here you can highlight this metric as the engine's flexibility - it is an opportunity to tailor it to your specific needs with minimal cost.
Next, the 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 there is an opportunity 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 the development will take place. And this is the next metric - the convenience of the toolkit or usiability , as it is often called. Here many may notice that in many indie teams there are no specialized people and still the programmer does everything. Which is more convenient to write code. The topic is quite controversial, but I have seen a bunch of examples where the same programmers make content much better and faster in special editors than with the help of code.
Naturally, even if you remove the maximum 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 without much concern for performance. Dialogues, client-server interactions, scripts and stuff like that. Here you can highlight another metric - the complexity of the development of game logic . It describes how complex the development of most of the code will be, those same 80% of the routine. Usually scripts are best suited for this. And the remaining 20% ​​are precisely those bottlenecks that require flexible optimization and tuning. What, in fact, also applies to the metric of flexibility .
The price of a specialist is also influenced by the input threshold of engine complexity. The easier it is to use it, the more specialists, the cheaper and easier to find them. However, too low a threshold often means that the engine is limited.
Also by the time of development can be attributed to such a metric as portability - the ability to apply the same solution on different platforms, instead of implementing on 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 as obvious as with expenses. For a start, let's look at what is the income from the game. And again the formula, very simplified, but to a greater extent reflects the result:
Revenue = Average User Revenue * Number of Users
Again, two quantities that can be influenced. So, how does the engine affect the average revenue per user? There is a rather indirect connection, and often there is none at all. But we are considering the "hospital average", so we will not reject.
There are many factors that make up this income: the involvement of the player, the interest of the game, the need to pay for the promotion, the ability to pay, the time spent in the game and so on. There are a lot of factors, they are always different, at least to say something about the amount of income is very difficult and very few people know how to do it well.
One of the factors affecting the success and profitability of the game is its quality. Beautiful art, smooth animations, good effects, interesting gameplay - all this influences 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 toolkit is necessary for effective development, but it is also necessary for developing high-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, on which it is quite difficult to go somewhere. However, quite often developers ride such bicycles: the programmer makes awkward animations on his favorite sines and cosines, the designer imposes a level in a text file, and so on. All this does not lead to quality results. Therefore, the toolbox is important.
In addition to tools, quality is affected by engine performance . Let the game have great content, beautiful art and great effects, but all this disappears when the game starts to slow down. The player is not comfortable to play, the interface becomes non-responsive, animations do not produce the proper effect. Performance also affects how rich the game will be. With a non-optimal approach, we can show N sprites and X animations, and with an optimized engine we can show more. It does not always produce the desired effect and sometimes unnecessarily, but it gives more freedom of action, more opportunities to realize your ideas.
Performance also affects player retention. On average, a new player installs the game and decides on its removal within 20-30 seconds. Making it wait for the game to load at this time is not a good decision. Also the size of the game affects the threshold of entry. Few people want to download the game size of 200MB on the mobile Internet. Energy costs in the game also affect. Many players run the game on the phone on the way home, and if the battery level is low and your game spends it much, the player would rather stay connected than play your game. Actually, the time that he chooses to spend in the game will decrease if he knows that the device battery will inevitably sit down. The conclusion from this one - you need to try to save resources.
Let's move on to the next part of the formula - audience reach. Here the metrics are quite understandable. This is performance and portability . The more platforms, the more devices are covered, and accordingly users. The better the performance, the weaker the devices support the game and more players can play your game. You can hope that your players have a new Apple product in their pockets, but statistics show that there are few new devices, everyone goes with the outdated “middling”. Approximately the same situation on Android.
Preliminary result
Now we have a rough idea of ​​what metrics engines have and how they affect the success of the game:
- Input threshold
- Tools
- Usability
- The complexity of the development of game logic
- Flexibility
- Portability
- Performance
Based on this list, we estimate the existing engines. I propose to consider only the most significant, based on the statistics collected by Unity3D, with a few of my additions.
The opinion below should not be considered as 100% true, it is compiled by me and may not fully reflect reality
Perhaps so far, few people have tasted this engine, but it is developing and getting better. It has a good all-in-one editor in which you will find everything you need. The 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 for the editor.
- Input threshold
despite the simplicity of the engine, it is quite high. Firstly, it has its own scripting engine. Secondly there is little documentation and examples. - Tools
there is everything you need, as well as you can do your - Usability
there is also bad documentation and a small number of examples. But in general, the toolkit leaves the impression of lack of thought and inconvenience. - The complexity of the development of game logic
scripts are similar to Python, which means it is easy to write them, but nevertheless, it’s your own language, so it’s unlikely that you can simply find a solution - Flexibility
game logic is written in scripts, the original native code is open. In theory, you can do anything, but in practice, as far as I heard, they are difficult to combine - Portability
ported to all necessary platforms - Performance
considering the scripts, you should not expect high performance
Internal corporate engine from King, which they decided to bring to the light. Appeared in the public domain relatively recently, the community is developing rapidly. Under the hood, he, 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.
- Input threshold
quite low due to LUA scripts and fast-developing community - Tools
there 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 for King Studio, so it was not originally aimed at a wide audience. Therefore, the tools are somewhat specific and limited. - The complexity of the development of game logic
LUA is one of the best scripting languages, is very common and easy to learn. However, in my experience, it is difficult to write large projects on pure LUA scripts. - Flexibility
the engine is rather limited to the paradigms given by the creators. One of them - the game logic is written in LUA. Although there is an opportunity to include native code, the emphasis is precisely on the fact that the game is written in LUA, but this language does not allow making truly quick decisions. Another paradigm is eternal full backward compatibility. Certainly it is good that the project on the first version of the engine will work without problems on the latter. However, in this way it is necessary to support old solutions, which slows down the introduction of new ones and, accordingly, slows down - Portability
Perfectly ported to all platforms. And even on the Web - Performance
LUA is a very fast scripting language, but, nevertheless, remains a scripting language, which directly affects the performance of the game code. However, the other components of the engine, according to the creators, are made as efficiently as possible.
Professional game engine at the height of technology. Excellent picture, performance, tool for real professionals. However, it is difficult to use it in mobile development. Yet it is more designed for three-dimensional AAA games. Doing mobile 2D games on it is like a cannon on sparrows.
- Input threshold
very tall. You need real experts in your business, both from the gaming content and from the programmers - Tools
the set of tools is truly impressive, from the particle editor to the animation of the characters - Usability
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 the development of game logic
in Unreal, game logic is written either in C ++ or Blueprints. In fact, you can't write the whole game on BluePrints, it’s really very voluminous and tangled, but I think you shouldn’t tell about C ++. According to the developers, everything works like this: C ++ programmers write the core and “blocks” for Blueprints, and the designers of these blocks make up game mechanics. I'm 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 ++ provide endless possibilities in development, but again, the bias in three-dimensional projects. 2D games for creators have never been a priority - Portability
Unreal now runs on all mobile platforms, but there are many rumors about numerous problems, such as application size. - Performance
Some of the best engineers in the gaming industry have developed a native engine, all of which suggests that you can squeeze every last bit out of iron.
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 on it are released, a distinctive feature of these projects is a good optimization. However, upon closer examination, the editor is not as convenient as it seems at first glance, there are a lot of shortcomings in the source code and you have to finish a lot of things.
- Input threshold
quite high, because for high-quality development you need knowledge of C ++ and a fairly good understanding of how games are made - Tools
there is almost everything you need - Usability
very doubtful in my opinion. Much copied from other technologies, but without much thought why and why. In the end, it is very specific and a bit divorced from real tasks. A bunch of console utilities are also not associated with convenience. - The complexity of the development of game logic
C ++ is mainly used, but it is also possible to use JavaScript. However, using them together is somewhat difficult. - Flexibility
open source and C ++ allow you to do anything - Portability
all mobile platforms - Performance
because of its simplicity and flexibility it allows to achieve very good results
Game maker / Construct and related
The engines of this kind were created so that anyone could make their own game, without any knowledge of the development. Everything is as simple and straightforward as possible, these engines do great with this. However, for large or even medium-sized projects, they are poorly suited.
- Input threshold
minimal - Tools
has everything you need to create small or simple games. The most convenient way for them to do games in the style of pixel-art. - Usability
worth watching Game Maker 2 editor! Perhaps the best solution for the engine in this category. Very thoughtful and designed for the target audience - The complexity of the development of game logic
either an elementary script, or no scripts at all. Instead of scripts, a reaction-action system is used in which all game interaction is described. - Flexibility
very limited functionality, but enough for simple games - Portability
all mobile platforms - Performance
naturally, the paradigm of developing such simple projects requires a lot of additional resources. As a rule, developers leave such engines to lower levels precisely when faced with poor performance.
The most common in our days engine. And this is the reason - it is very convenient. Great editor, almost unlimited possibilities, 2D, 3D graphics, anything you want. And of course, C #, with which development is pretty easy. However, he also has skeletons in the closet. Often productivity leaves much to be desired. I agree, if you make an effort, you can do a lot, but the price is high. In addition, sometimes incomprehensible plans for the development of developers engine. The most necessary things remain at the bottom of the roadmap, but in new and new versions there appears something that sounds great on the selling page, but not everyone needs to be developed.
- Input threshold
very low. You will make your first game in a couple of tutorials. Huge community, lots of available solutions. - Tools
there is absolutely everything, some even too much on most projects. And if you don’t need it in the engine, you’ll probably find it in the store. - Usability
This is the biggest plus engine. Excellent tools speed development at times. However, with deeper use, flaws come up, for example: in some places there is no obvious logic of the UI, not very well-designed animations. Some things people ask for a very long time, but the developers still can’t do it. In general, for the development of mobile games - the best that can be found - The complexity of the development of game logic
C #, although somewhat specific in 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 developing in C # is several times faster than in C ++ - Flexibility
very flexible tools and architecture of the engine as a whole. However, in many things it remains unavailable for change. Closed code gives a black box effect that is often impossible to influence. There is freedom for optimizations, but subtle optimizations cannot be done as a result of their secrecy. - Portability
ported to all that is possible, rumor is coming soon on vacuum cleaners can be run - 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 tight. Sometimes you think about C # code much more about its performance than you do C ++. And as a rule in the game there is a place where the performance sags. In such cases, a lot of resources are spent on optimization. Similarly, performance problems associated with UI almost always occur. Difficult dialogues, long lists without optimizations load the system quite heavily.
Own engines, C ++
The choice of either large studios or madmen. For this, we need cool specialists, but they are few and costly. And as a result, Frankinstein from technology is obtained, which is constantly falling apart. It turns out a very wrong development, most often it is those expensive programmers who do everything. But it turns out the most ideal product. All that the designers want is implemented, works as smoothly as possible and runs on ancient devices. But the price for such technology is high.
- Input threshold
very high, no documentation, the only way to find out how everything works through colleagues - Tools
as a rule, there are either no tools in such engines, or there are elementary editors that satisfy some specific needs. It is on these engines, as a rule, programmers do everything. After all, an ordinary designer is extremely difficult to understand all these technical jungle. - Usability
even if there are tools, they work outright badly. It is understandable, because such engines are written to make the game, and the game needs to be done quickly, hence the poor quality of the tools, a lot of bugs, console utilities and all of this. But even if there are some tools, they are written by programmers without taking into account that they will not be used by programmers, as a result, the effect editor turns into a space shuttle launch panel, and not into a beautiful interface with three buttons. - The complexity of the development of game logic
starting with such engines is very difficult, because first you need to understand his device, all his hacks and rakes. But then it plays only on hand. As a rule, these 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 any scripting language is bolted. - Flexibility
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 waste time on supporting the platform, if you do not plan to release the game on it. However, with experience, I have noticed that in such engines operations with platforms are very slow, assemblies are very complex and long - Performance
obviously, those who are able to write their own engine are pretty well versed in their subject. However, there are no restrictions. Accordingly, you can do anything for the sake of performance and achieve the perfect result.
So still, why do we need another one?
According to a brief description of those above, it becomes clear that there is no solution that will satisfy all needs. Each of them has some disadvantages, be it convenience or performance. Let's try to imagine the very ideal that will satisfy all our needs, it will turn out to be the very “silver bullet”.
Obviously, he must 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 top-level things like an editor and scripts. That is, the upper level provides convenience and is designed for most tasks, and you can resort to the lower one in search of more efficient solutions.
Moreover, the low level should be really low, and not just provide a good API. Here everything should be as transparent as possible for the developer.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 this, in my opinion, is open source.
The top level should be well thought out enough to perform its function well. Many developers of In-house engines here make the same mistake; they put 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 animation, problems begin. Particles are not played in the animation editor 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, superimpose sound, effects, and all at once, in one place.
However, the ideal can be described in colors for a long time, so let's return to the specifics and analyze in order according to our metrics:
- Entry threshold
as low as possible. The system, where the “upper” level is kept on the “lower” level, makes it possible to completely lower the input threshold, while not limiting in flexibility - Tools
there must be everything you need: work with resources, graphics, animations, interfaces, effects, physics, competent layout of the scene. Ideally, all this should be in the same system so that each of the components ideally fits together. - Usability of
each tool should be thought out from the side of real use. It is not enough just to make a particle editor, interface or animation. All this should be clear and convenient to those who specialize in this.
, . , , 20% . 80% , , .
. — API
, . web-. WebAssembly- Performance
— , , . - . ,
Total
In the end, there may still be a better engine nowadays. But this is only one opinion, 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 opinion of others on this matter. I think it will be interesting to many if someone else in the comments writes his opinion on some kind of engine. It may even be useful to those who still choose the engine on which they want to make the game.
Source: https://habr.com/ru/post/338214/
All Articles