Why write your game engine?

Last December, at the Games Gathering 2017 conference, we made a report in which we talked about whether companies working in the gaming industry should write their own engines.

Unity in a variety of game engines

Why in the modern world in which there are such giants as Unity, to do something different, to write your own game engines?

Here is a slide with the data of Unity Technologies on the use of various game engines in 2017. Next year, as you understand, the situation will change. We are interested in what 41% is assigned here, that is, the engines of our own design. If you look at the 5 largest companies represented at the conference, then each of them will have its own engine. It turns out that most of the companies representing the gaming industry use some kind of internal development. Not always this is the most reasonable decision in the world, but it is so.
')
What basic technologies can companies choose to think about developing a game project?

Army of seven nations

The pyramid that you see on the slide can be continued up and down. She absolutely limits you. Below - the operating system, even lower - some basic technologies. Above - the add-ons above the engines, ready-made tools, which are supplied with games, like tools Neverwinter Nights. Whatever you do, you somehow find yourself inside this thing.

Suppose I want to be on the second level of this pyramid below. However, all the paths eventually lead to the upper part of the pyramid. We will use something from the existing one, but it is also very important that you can see in the upper left corner of the top level of the pyramid, that is, the engines of our own design.

Now let's analyze the time, effort and money needed to develop the game.

Back to basics

If the entire pie chart shown on the slide is a game, the engine is its blue sector. In a perfect world, while developing a game, you can take out this blue sector and put red, or yellow, or green there. You can change one big “U” for another big “U”, or take some small “x”, and what you have chosen will work there. In reality, this is not the case, but we must strive towards this. A similar picture, if we are talking about real projects, is observed in the gaming industry all the time. It also happens that the whole diagram is occupied by the engine, but this is true only for some demonstration products.

In this case, money, time and everything else is distributed in this way. Whatever you do, you will have to deal with everything else that falls into the green area of ​​the diagram. It does not change from engine to engine. As a result, if you have enough resources to support the entire process of working on a game project, the development of the engine will not be so expensive. However, if someone in the company starts talking about developing their own engine, they will most likely encounter a certain set of objections. Consider them.

Mythical man-month

Suppose you decide to create your own engine and report this to the decision maker. In response, you will hear about the same thing that can be seen on the slide: "You will do this for a long time, it is very risky, it is irrational, it will not help us to achieve our goals." What can be answered to this? The point here is that all these objections, except the last, do not stand up to scrutiny.

Long engine development? But if the development with its own engine goes faster, then this is not an argument. Perhaps, nobody knows about what is “rational”. Therefore, all these objections are very subjective.

The last point as to whether your engine contributes to achieving goals is very important. If your goal is to earn money by receiving a grant from Unreal 4, then you probably don’t need to do your own engine, because it does not lead to this goal. If you have a goal, within the framework of which you need to do something on certain technologies, then you do not need to write your own engine - you need to take what is. But effectively using ready-made engines is not always possible. Why, all the same, to write your own engine?

13 reasons why

When you may need your own engine? Let's sort this slide by points:

• Time to Market - time to market a product. This is really serious. Half of those engines that are now used in large companies are designed precisely because at that moment when this company had to quickly quickly occupy a niche, it was faster to develop one’s own than to take something else and master it.
  

Here is the story. In one company, the site had a task for programmers that looked like this: “Guys, if you want to work with us, please write“ Asteroids ”, which should be launched on the Android platform without using external libraries. We believe that 8 hours is enough for you. Time has gone. ” Then the time was increased to 12 hours. Maybe it looks funny. At first I watched it outside, then I looked into this company and asked to tell me about what they had sent in the form of a response to this task. As it turned out, more than two hundred programs underwent selection, that is, these programs were launched and worked. This means that if you suddenly want to publish Asteroids for Android, then there will be at least 200 people who can do it in 8 hours. I do not say that it can be sold. But I told this story to the fact that very often, in fact, the engine - this is Time to Market. Let's say, simply because you have such small needs that you will study the documentation for the same Unreal longer than simply take and make your own.

• Lord of the Platform - the lord of the platform. There are platforms for which there are no ready-made tools. For example, STB, set-top box (digital television receiver) - a box for cable television, which is on the table for every third American.
  

Warner has 120 million users of this service. If you write software there, including games, then you have a dollar from the box. This is 120 million dollars a year. At the same time, except for you, no one else can write for this thing. Because there is no DirectX, there is nothing at all. If you know how to write programs for STB, then you are the lord of the platform, you have these one hundred twenty million dollars a year. What is not a reason to write your own engine?

It is clear that we are now talking more about something like console toys, but, nevertheless, in some situations it may be necessary. Here, for example, slot machines. Of course, there are now mostly computers. But we have a separate iron device and a huge market for which it is possible to write something of your own.

We can say that we are interested in phones, but we are talking about millions of dollars. Why not write for other devices? As a result, there are absolutely clear reasons to do this.
Or, for example, we have the latest smart watches. The SDK has not yet come out to them, no one understands what to do with them, and if you can, on your own, write a quality product for them, then you, say, earn a dollar from each such device. If they are sold two million - then you will get two million dollars. It's easy to write, but for this you need to make your own engine, because there are no strangers, and the manufacturers of such devices will not make publicly available engines for development for them.

• Weak but proud devices are small but proud devices. If you make games for mobile phones, collect at least some statistics, then you know that everything is more or less normal with the hardware of Apple devices, but with the Android platform it’s just a disaster.
  

Half of the devices on the market are based on the ARM Mali-400 chipset, any budget phone is the Mali-400. And if you are paid for the fact that you are engaged in telephone applications, then you should write for these small but proud devices that are not going to leave the market and will leave it very soon.

In the case of the iPhone, you can make at least some bets on progress. For example, it is expected that Unreal will work under the iPhone 10, although until all this is brought to mind, there will already be some iPhone 12, 15 or 17. But in the case of the world in general in the short term, it is harder to put progress on it. Because the device upgrade is very slow.

If you want a competitive picture, and if it is very important, you are not going to low-power devices. But you must bear in mind that all modern engines do not scale down. If you do not want a competitive picture, then, accordingly, consider the possibility of weak phones. Therefore, if you are in a situation where you are not interested in the fastest devices, for example, you are the only distributor somewhere in Portugal or in Brazil, then you will have to think about it.

• Own language for own ideas - own languages ​​for own ideas. When you make the engine yourself - you can use this concept. The fact is that the main problem of our industry is that the domain of game designer is philology. He thinks in ordinary language. He does not know anything else. A programmer thinks in the programming domain and the gulf between them. As a result, some kind of iteration, which has to be repeated continuously, is worth, for example, two dollars. And you constantly spend this money.
  

Standard engines are trying to reach everyone. In fact, we see how they are trying to make natural domain transformations from language to language and from space to space. But for all. And you have your own ideas, and you can implement them directly, making your own set of tools. It is clear that all this, in the form of plug-ins, can be done on top of existing engines, but your own engine opens up completely different possibilities.

• Unique Mechanics = Unique engines - unique mechanics = unique engines. My friends wrote Minecraft in the fifteenth year using Unity. Was there any point in doing all this - an open question. But they chose the engine and got to work. However, the engine is obviously impeded by it. It was hard for them. They had very long iterations. After we consulted them, they wrote their own render in just three days. And the rest of the code responsible for, say, building the world, naturally, has not gone away. Simply all this ceased to be in C #, ceased to be in Unity. And the work began to boil. I don’t know if they managed to make money on it, but the main conclusion from this story is that they didn’t have to use Unity from the beginning.
  

That is, there are a large number of mechanics for whom standard, large, universal engines are not suitable simply because they are designed for everything. Therefore, if tomorrow you come up with something special, some complicated voxel mechanisms, then you will be inconvenient to work with standard engines. That is, there are mechanics for which the standard engines are not suitable, and which are quite simple to implement independently.

• The game is not everything - the game is not a render, the game is everything else. We have already talked about this. If you have a problem only in drawing something, or, say, using sound, making a multiplatform game, then you could see similar stories in the previously considered pyramid. If you say: “I want to play the sound on three platforms,” then you do not need a big “U” for this - a small “c” will be quite enough.
  

The reasons for developing our own engine, we have considered. Let us now dwell on the advantages that a company has in developing its own engine.

The benefits of developing your own engine

Consider the benefits of developing your own engine, based on the main ideas put forward on the slide:

• Buying is often better than mortgage - buying is often preferable to a mortgage. Game development is money anyway. There are ways to monetize, when using which buying is not just better than a mortgage, and this is simply the only possible option.
  

If someone worked on mobile technologies, then you understand everything. If the engine box says: “10 percent of royalties”, then it is absolutely unacceptable, you will not earn that much. You may have a profit of one hundred percent, but you work out of two. That is, if you have royalties, then this is a purely economic reason for abandoning the engine. And I must say that three, more precisely - two of the most popular engines at the time - this is just a matter of deductions. That is, this option immediately disappears.

• Specificity is better than universality in the long term - specialized tools are always better than universal ones in the long run. It is obvious that universality is always slower, it is less productive and less specific than specialized things. The engine, written for a specific task, will cope with it better and faster than a universal tool. In the long run, special tools are much more profitable than universal ones.
  
• Tools and pipelines are developed within - pipelines and development tools created internally. Any engine, invented by people outside your company, focuses on several things. The first is the best practices. That is, the engine of another company is oriented not on how your artist paints, but on how artists paint, ideal from their point of view. It is possible that your artists paint differently. They have their own pipeline and they do it.
  

You have 2 options: either retrain them as it should be from the point of view of best practices, or use your own. There are simple examples. Suppose you say: "We import 3D models." You do not know - what is there from that side. Therefore, you need an intermediate format. The intermediate format let it be FBX. FBX flaws everyone who does it knows. And you have nowhere to go, because you do not know what will be done there, you will not write plug-ins for 450 3D-modeling tools.

When you work within your company, you can realize the same pipeline that you already have and put what you are doing on top of it. In fact, it is very important. The fact is that all this is related to the time of development and, as a result, to the cost. Therefore, when you develop at home, you can dispose of the pipeline that already exists. Otherwise, you have a document called “The rule for uploading 3D models and creating materials for artists” will be more than a design document, and this is wrong.

• Reaction time - reaction time. We are talking about the reaction time of the engine manufacturer to your requests, the possibility of equipping the engine with new functionality, and the operational research of new technologies.
  

Say, in the next office there are people who make the engine. Anyone who tried to fix a bug in the universal engine, that is, write Unity or Epic in bugtracker, knows that it is better not to even begin. And if the developers are sitting in the next office, then you can contact them and resolve the issue in 15 minutes.

The same applies to the proposal of the new functionality, if you have the right to do so. The study of new technologies is also simplified when using its own engines.
Suppose your programmer went to a conference, listened to a lecture there about something new. He immediately tried it, you got an idea about this new one and you know if you need it or not. You can really try to reactivate something interesting from the world of science. And this, by the way, means that the company may have a person who will be called a “researcher”. In this study, you can do on the same Unreal, because it comes in the source code.

• Performance - performance. The gaming industry is always performance. The first approach to achieving high performance is to use special solutions. The more specific solutions - the more productive they are. The second approach is also, by the way, dear, this is the optimization of the finished engines. Exactly how it will look - strongly depends on these engines.
  

Developing your own engine is not only an advantage. It is also a risk. Consider them.

Risks associated with the development of its engine

Consider the risks accompanying the development and use of your own engines:

• Development time - development time. This concept overlaps with what we have said about the time to market. The development of the engine can be very long and fast enough. But the development time of the engine, in any case, contributes to the overall development time of the project. Therefore, it is also a risk. For example, I know teams in which the development time of the engine tends to infinity.
  
• Terminal cases of vendor-lock - terminal cases of binding to the supplier. This applies not only to large companies, but also to small ones. Let's say you hired Vasya, he wrote the engine, then fell in love, quit your job, and no one understands what he wrote. As a result, you have vendor-lock worse than Google. Because you can still write a letter to Google, although they will not respond, but here, with the departure of the programmer, it was all over. The result is lost development time and other unpleasant consequences. We must be able to avoid these risks.
  
• Reinvent the wheel - the invention of the wheel. The point is that we live in a world in which you are still inventing bicycles. When developing the engine, it turns out the transfer of the bicycle factory from the game code to the engine code, although there is no place for them.
  
• Closed ecosystem - a closed ecosystem. Everything that is done within the company belongs to this company. I know a bunch of companies that have something like their own scripting language. This may be some kind of XScript that works only within the framework of their solution.
  

Programmers who know this technology, in fact, do not know anything else. This can be considered as one of the factors helping to retain employees. Therefore, the answer to the question of whether it is good or bad, whether the use of own technologies is a risk depends on the specific situation. For example, we try not to use the concepts of our own invention. For example, I know of one company that has a strongly typed Lua, with Pascal syntax. This can be mastered, but this knowledge is dead, like Greek. We try not to do that.

The main question of life, the universe and all that

Consider a very important question. What resource is required first of all to develop your own engine? Resource, without which it is meaningless to think about whether it is necessary or not necessary to make your own engine. The answer to it, of course, is not 42. The question is what is generally needed in order to just at least be able to say: “Yes, we have at least something, we can start doing something.” The answer to this question is that you need programmers to develop your own engine.

Programmers

In order to create your own engine, you need programmers. If you do not know - google the difference between the words "developer" (developer) and "programmer" (programmer). It is very important. Developers are the main group. The game industry is so structured that most people in it cannot be called programmers. Sorry, but they are developers. Developers are not able to competently make the engine. Again, if you look at the difference between the first and second, the developers make the games, and the programmers make the tools. Developers make a product, the company earns at the expense of the product, but the tools must be made by programmers, otherwise they simply will not work.

On the one hand, it is a very open world. For example, I know the code Unreal 4 and CryEngine, it is open. Anyone who wants to know can learn the Unity code, there is a huge amount of relevant materials. This means that those who are programmers and read in English are capable of doing this. There is no rocket science. But on the other hand, as it turned out, programmers who read in English are very difficult to find. Therefore, you should know where they are found, should be able to recruit, use and encourage them. If you can do it, then you can already think about your engine. If you do not have such people, then you still will not succeed. Examples of this - the darkness. The point is not that there are bad and good decisions. Just there are things that can not work initially.

Programmers need to be able to hire. Know how to hire - you can make the engine. Do not know how to hire - then you have to take something ready. Moreover, the funny thing is that when you take something ready, then you, if you are a big company, you still need two people from among these programmers who read in English.

If programmers are needed to develop the engine, then we immediately have several questions. Where to find programmers? How to organize their work? What you should pay attention, thinking about the development of gaming companies?

Technical epidemic

Now it is appropriate to recall another aspect of the search for employees, which concerns mainly large companies. These companies have several approaches to recruitment.

First, you can recruit people, joons, arranging internships, and, teaching them within the company, somehow grow to the desired level. This is a normal approach. At the same time, many technological problems are solved, because it is easier to find a common language with a person who initially perceives corporate culture and studies certain technologies.

Secondly, there is an approach that we, in principle, profess. How does kefir work? He turns everything into himself. You take milk, throw kefir there - and there is no milk, everything turned into kefir. Here it looks like this: “Guys, let's take 5 strong programmers, this will be an internal technology center”. And I’m telling everyone that if you can afford to do the RnD department, if you are a big company, then do it. Let them even do nothing useful in terms of money. If a company has become stronger in the market and the question arises about where to expand, the answer to this question may be the creation of an RnD department. When a company is already rich, for it is not a loss of money, because it is already losing so much money on the efficiency at which our game industry now works, that research costs simply will not notice.

Now consider the approach that the company organizes a team that makes the engine or some other interesting things. This is a job for the future. You can conduct interviews, say that you give money, you have an interesting task, you make the engine. You can choose from applicants, people come to you, and within the company you always have an atmosphere where you can motivate, encourage, and as a result achieve your goals.

I have, say, some modules are developed by grocery companies, because they need it. That is, physics has been ordered, and instead of sawing some of our own pieces, we say: “Let’s go like that. We just come up with common interfaces, a few generalized ones, and you will do that. " And within the framework of standard tasks it is very good. That is, in principle, it is good to distribute technology within the company.

If the company is already so big that it can afford to do something interesting inside of itself, then it pays off even in terms of money. So if you can, try it. It can look like it pleases - say, our Unreal branch is being made, and there we recycle everything the way you want. For example, I, in one of the companies, made a browser that fits into 2.5 megabytes of memory. And he worked. Why - I do not know, but it was infinitely interesting.

Above, we mentioned the problem of gaming companies, which is to organize the effective interaction of programmers and designers. Let us dwell on this problem in more detail.

Two worlds

The time has come to show you the workplace of our game designer. This is a real picture. This shows some kind of demo, the implementation of behavior, a little later we will focus on this in more detail.

In the gaming industry, two worlds are side by side. People are either focused on solving technological problems, or on narrative. And in the middle - some kind of amateurism. That is, there are practically no tools. Words, words, words - bang code. Again the words - and again the code. We believe that the required tools that allow you to connect to what you get as a result of working on the game, game designer, manager, other employees who are not programmers.

On the slide you can see the behavior of the tree, the tree of behavior. In principle, this is a thing, simply taken from Wikipedia, but before us it was taken from there by Unreal. Nothing wrong with that. So, the documentation for this is on the Unreal site, it was easy for us to make a suitable interface compatible with what is being done in Unreal. That is, you can take any example from the Anrilov action site, an example of the behavior itself, since the format is completely the same, rewrite it like this, and it will work. This means that I made my life easier, I do not write documentation. And there are a lot of such things here.

In the example from the slide, something happens, a crab runs, it catches someone, in general, it does not matter. Inside the programmer solves problems that look like "go to ...", "shoot at ...", "calculate the distance" - that's all. All other behavior is written in this editor by a person who has absolutely nothing to do with programming. And it works, unlike translating text into code. Moreover, if we talk about, say, the balance. What is balance? These are 15 factors that can be changed. And here is the behavior, not the coefficients.

That is, for example, the behavior of “patrolling” is described by a game designer, not a programmer. This means that we have taken that step, which most people do not. They simply write in the design document: “patrols”. A programmer can translate this in 50 different ways. What is a general patrol? And here game designer writes exactly what he means. And this is a victory, my friends. That is why you need your own tools. In order to smooth the transition from the verbal definition of your visionary, who sees the game, so to speak, inside the head, to the programmers. Otherwise, they will no longer be programmers, become developers, and will plant weed all their lives.

Results

Let's sum up. We talked about the reasons to write your engine. Say, if you look back on outdated devices, then this is neither good nor bad. That is, you want your games to run on a certain range of devices that are no longer supported by commercial engines. At the same time you want to look modern. How to achieve this? Write your own.

Do you want to own a platform? Do you have a specific project that simply does not require the use of universal solutions? Or do you, on the contrary, have a very large and complex project with a specific picture?In these situations, again, you can think about your engine. At the same time in order to make your engine, you need resources. And resources are programmers.

As a result, if you have reasons to write your own engine, and you have the resources, take and write.