Or how to save 15% or more of the development budget

I have been working professionally with the Unreal Engine for over 9 years. During this time I have mastered many specialties and held various positions in the development of games: from the “infantry” developer to the manager of large teams of game developers and even advised investors to gaming companies.

Recently, I have been working for myself, but from time to time I offer emergency services of “extinguishing fires” to my clients, who found me on word of mouth. It is difficult to explain what exactly these services are, but most of all they resemble the work of an emergency plumber. You definitely do not want to be in such a situation when you have to call it.

If a gaming company in Los Angeles has a problem with Unreal Engine 4 that no one can solve, call me at the end. I am writing this article to explain why they are calling me, how to avoid the need for such calls, and what I usually do when I receive such a call.
')
Most of the problems of game development are well understood by those who are “in the trenches”, but these problems fly over the heads of managers and managers. In addition, it seems that only people from trenches on the front line read such articles, and not those who really need them.

Most likely, this article does not apply to you, if you work in a close small indie team. Most cases are life stories, so they may not always be applicable to you. Because of the very nature of my work, I am rarely mentioned “in credits”: the fact that I participated in the correction of team errors remains confidential. It is for this reason that information about me is transmitted orally by clients, so there is no public evidence that I have the necessary experience to write on such topics. I write this article and it doesn’t matter whether they believe me or not, because people who need to know this information will not read it until it is too late ... In short, this is the problem I’m writing about.

Stop burnout, start growing

In Los Angeles, there is a constant and insatiable need for developers of high-level games specializing in the Unreal Engine 4. Incredibly often, I saw teams hiring one or more entry-level / intermediate-level developers, and then immediately trying to hang seniors / more high levels, not giving them the opportunity to grow and the right to make mistakes. This is due to the fact that teams usually decide to release a product without the means to create such a product.

I believe that this leads to rapid turnover and excessive burnout: this is a cycle of negative feedback that destroys the potential of high-level local talent, thus creating an even more serious demand for them. If you find yourself in Greater Los Angeles, then I recommend that you visit a local rally of the creators of games that have a lot of alcohol, and find developers there; if you treat them, they will share with a lot of terrible and thought-provoking information on this topic.

Developer overloading is a sure way to come up with a difficult project to support. If you are not developing a prototype "to throw", then difficult to support the project - one of the fastest ways to cause developer fatigue. If your developers eat and cook blueprint spaghetti for breakfast, lunch and dinner, then they are not happy that the office has a Nintendo 64 connected to a 300-inch monitor.

The most important reason for the emergence of a difficult project to support arises when someone creates a gameplay system design that has development skills that are too underdeveloped by the standards of this system. As a result, the resulting systems are kept on scotch and chewing gum. For games, you need to work together many systems; if you don't have someone with experience building systems or the entire ecosystem of a game engine, then the interaction between them suffers. This leads to situations where only the one who created this system or connection can maintain the system and make corrections to it; at the same time, this developer is assigned permanent responsibility, which does not allow him to be released for other tasks. Sooner or later, the developer is charged more tasks than he can handle, and the development process begins to suffer from fatigue or worse, the dismissal of this person. Neither the developer nor the team can grow in this case, because the implementation of new functions or changes becomes more resource-intensive.

Often this problem is discovered too late, because the team does not have a high level developer capable of recognizing it. Therefore, the problem is detected at a critical moment, when the systems are connected by a narrow and long wooden bridge, which is also covered by a flame. Then you need an emergency developer who can save everyone.

If you have to hire developers with lower skill levels than necessary, then this problem can still be avoided. Instead of forcing these engineers to create what is above the level of their skills, break the project into several smaller systems, possibly removing some features in the process. Take one or two additional developers to evenly distribute the work on the team. Let the development team perform isolated testing of their systems and isolated testing of individual combinations of systems. This will not only help the testing department, but also allow each developer to determine the sources of the problem, even if they relate to the system that someone else was developing. The creation of isolated tests of individual combinations of systems will help developers to improve their skills in designing systems, to develop confidence in their fellow developers and the ability to work on the code base as a team, rather than individuals. Break projects into small systems and make the developers work with each other. Creating such combined tests also allows several developers to get acquainted with the system, which reduces the burden on one developer to support a separate system. This frees developers from binding to specific responsibilities, allowing them to grow and work more efficiently. If you lose a developer, then you should not lose all development opportunities.

As an imaginary example, you can take an inexperienced developer working on a system that allows players to select keys for opening doors. Another inexperienced developer will work on a loot system or dropping items caused by the death of an NPC. The most experienced or weapon-specific developer will work to ensure that the player can hold and fire a weapon. All these mechanics can be tested individually, as well as in combined tests, for example, shoot at an enemy in order to take the key from him and open the door. These systems should work without problems and difficulties.

I took this example because I have already seen what happens when an engineer without systems design experience connects all three systems; it results in a chaos in which the killing of an NPC may be required to open each door. If a key is required for a door, and all keys fall out of dead NPCs and the only way to kill a dead NPC is to shoot a weapon, then you tie the game design to the need for a gun shot to indirectly open the door. It sounds funny, but it is. But such ridiculous problems and dependencies arise constantly. The key concept can be implemented in such a way that a simple action that allows a level designer to position a key that can be raised will prove to be incredibly costly to implement a function. Or worse, it will require a separate system that doubles the effort required to implement the key game concept. This is especially true when increasing the scale of the problem: 10-20 + systems work together, and the only one who knows how they work, for some reason, disappeared. Imagine that the team has only three days left until the product is released, and there is no longer a developer responsible for these systems, and lower level developers cannot learn how to support and modify these systems. What are you going to do? Who to call?

No engineer - there is a problem

This should be an obvious problem, but most of my work with clients arises from this fact, sometimes in combination with the previous one. A manager or producer may know that they need a senior or technical manager, but in the end the search ends in nothing, they give up and fall into the trap - they begin to think that they can handle the existing forces. "We can not find anyone, but perhaps our team will cope with the work." If the development team is given a space for growth, then it is likely that someone will be able to take on this responsibility, and the chances of success are higher, but usually this does not happen. Sometimes management can skip the search for an experienced developer altogether and start small, thinking that it will cope with the problem later.

In any case, we find ourselves in a situation where the game development team works without a senior and technical manager. Without such a person who is able to avoid undue burden on developers with low skills, as well as without the ability to predict possible problems in general, the probability of finding a critical problem in the later stages of development significantly increases. The range of such problems is very wide: from the most trivial, to serious comprehensive design problems, threatening to set fire to the whole project.

I can give you a recent example of how a trivial mistake in my client’s avalanche turned into an expensive development nightmare. The client has a problem with the incorrect configuration of the source control version server. In fact, the problem was that temporary and local cache files that should never have been transferred to the command were tracked and distributed unnecessarily. Any high-level developer who sees this would immediately say that these files must remain local and never be transferred to the source control version control system. He would delete these files for standard reasons: so as not to increase the amount of data on the version control server. This action would prevent the emergence of an even more nasty error.

It turned out that when the game engine detected the presence of these cache files, it did not generate the data necessary for correct reproduction of some sounds, because it believed that it had already generated this data, otherwise where would this cache come from? Therefore, the sound worked only on the machines on which it was created. This problem was aggravated by that. that the sound was created by the contractor, and not inside the studio. The client asked the creators of the sounds to fix them, but they said that everything worked as they needed for them. This could lead to increasing errors in communications and unnecessary dramas, when everyone would blame someone else, and create a general atmosphere of hostility; from possible legal claims to the contractor to the prosecution of all the poor developers who themselves did not understand and did not have enough experience to diagnose the problem. They called me to solve this dilemma, just a couple of weeks before the release. Simple cleanup of the version control server and the removal of these unnecessary cache files from version control eliminated this problem with sound that had been poisoning life for months and cost the company a lot of time and money.

This is just one example of literally thousands that can arise without a senior developer or technical manager. Salary costs for this specialist would be less than a solution to this problem only a few weeks before the release, even if the only thing this developer would say was “I believe that these files should not be included in source control.” Even if she escaped the developer, he would at least have enough experience to solve the problem without the need for an emergency consultation. If this error had not been eliminated, they could have mistakenly filed a lawsuit against the contractor, which would have led to the astronomical value of this trivial error. Unfortunately, such situations occur more often than you might think.

Learn from your mistakes

Imagine a company that works with budgets of a million and above, making such mistakes several times. They not only arise, but also do not cease to arise. It became a serious motivator for me to write this article, because it saddens me when this happens. In addition to the incredible waste of this, it often leads to the erroneous dismissal of developers who not only reworked, but also performed duties above their own level. If these developers were given the space to grow instead of being fired, the cause of which boils down to management failure, then these developers could become pillars of the company whose experience could save everyone even in the event of management failure.

I do not want to say that those who do not cope with the responsibilities of the developers should remain on staff. I'm trying to clearly convey that if your company is going to release a product that requires developers, then you need to learn to distinguish a non-coping developer from a developer who has been charged too heavily with respect to his experience level. I hope understanding of the two problems mentioned above will help you to understand.

A high level developer is not only code

A high-level developer often looks beyond the code to diagnose his errors. This is especially true when many moving parts are involved in the development of a project. Of particular importance may be knowledge of the inner workings of all departments.

Over time, you begin to see the patterns of work of companies, and if the company says that contractor X caused the problem Y, and you have already dealt with work X before, then you are one step closer to solving problem Y. Although such information may prove invaluable, Unfortunately, if you didn’t spend enough time on this kind of work, then you will not have a ready-made “catalog” of information that can be sifted. As stated at the beginning of the article, this task can sometimes be solved by simply buying a drink for another developer. Developers do not usually violate the NDA, but finding out the rumors about how a company actually works is much easier than you might think. I can’t count the cases when I managed to solve large-scale problems just by talking with a former developer or friend of an acquaintance of my acquaintance and finding out that company X says one thing, but in fact it was quite another. It is difficult to write about these types of problems, because they are usually associated with very specific people in very specific positions with very specific problems; writing about them would violate the confidentiality of my work. Sometimes internal information can be used to solve a wide range of problems: from where to look for the right animations, to answering the question of what actually happened to the millions of dollars in a company.

Here is one example that will be difficult to identify with altered names, numbers, and specificities.

The publisher "Belka" hired the company "Elk" to create in the two-year period the Games with a budget of $ 1 million. The publisher of "Belka" put a condition that the company "Elk" should attract the contractor "Rabbit" to create concept art and the contractor "Bird" to work on animations. Payment for the services of "Rabbit" and "Birds" should be made from this budget of 1,000,000 dollars. The Elk Company accepted these conditions, even though Bob’s consulting engineer advised her of this, saying that if approached realistically, it would take $ 2,000,000 to develop the Game. The company "Los" took three years and $ 2,500,000 to develop a mediocre and partially unprepared Game. After these three years, I was invited by the company “Elk”, so that I could find out if the Game could be fully completed for the minimum budget, and figured out what had gone wrong. After analyzing the information from all the parties involved, I quite easily proved that the publisher, Belka, has a member of the board of directors Joe, who had a secret share in the income of the contractors Rabbit and Bird. Joe maliciously handed over the specifications to Rabbit and Bird, which required much less work than was actually required, which led to the short delivery. At the same time, he understood that the Los development team had too little experience for her to understand the discrepancy in work volumes. I gathered this information by asking what was happening to the “infantry” developers, and asking for help from Bob’s consulting engineer at an open party at a local gaming company in a bar. Since the company "Elk" took all the work transferred to it by the contractors "Rabbit" and "Bird", from a legal point of view it was the company who was to blame for the fact that she had to pay more for the additional work of "Rabbit" and "Birds", increased income for board member Joe. Bob correctly pointed to this potential danger, but he was only a consultant, and there was no technical manager at Los Company who could confirm his conclusions. If the company had a high-level developer, then it could refuse this transaction or, at least, estimate the insufficient workload of contractors, and discuss this problem with the publisher Belka, taking into account the conditions imposed by the board member Joe. Instead, the publisher of "Squirrel" completely raped the company "Elk", which collapsed as a result. The publisher "Belka" continues to use his vicious practices to this day, only now called the publisher "Garbage Panda."

The news media completely agreed with the publisher and blamed the company Elk, without mentioning either board member Joe or the contractors Rabbit and Bird. The whole truth about such situations is never revealed and the blame is usually completely hung on the developers, regardless of the involvement in the case of other malicious parties.

By the way, all your subordinates lie to you (because you don’t hear them)

I found one interesting thing - when I enter the office as a third-party objective expert, after about two nanoseconds after you leave, your subordinates begin to tell everything about what is wrong with you, with your company and with your development methodologies. The reason is not in my honest face and not in the fact that I promise to improve everything - your employees are concerned about the growth of the company, and, more importantly, their own growth within the company, despite their feeling that no one hears them and does not want to hear. I just find myself a new person who will not judge them for what they say, and even if I started, they are often so tired of the problem that they are not worried about any possible consequences of criticism of the authorities.

Usually, a complex problem or difficulty is already known to your staff, and often they even try to inform you about this problem, but more often than not, their opinion is not appreciated or filtered as white noise in the control chain, in which no one does anything. In the worst case, someone conveys the problem to the most important person in charge, and it either is immediately rejected or ignored.

If reports of problems do not lead to any actions, then this becomes the fastest way to turn employees, especially developers, from the company's enthusiasts into workers who come to work, leave work, and the rest is not my problem. Most employees, especially developers, want to improve the company and themselves ... until they realize that their thoughts are not important to anyone.

I can cite one such example. The development of the project of the company took more time than it should, and they called me to either speed up the development or find out the reason. Immediately after getting into the office, and even before I met the person who hired me, several developers advised me to run away as soon as possible, because the producer, who had absolute power over the development, did not have engineering knowledge, and continued to assign the tickets to the wrong ones developers: network developers were engaged in fixing gameplay, gameplay developers fixed rendering problems, and so on. Because of this confusion, frequent scheduling sessions were created to eliminate this confusion, and most of all, developers hate one thing - frequent scheduling. Each of these developers said they denounced the problem to the producer and senior management, and they showed e-mails without even getting permission to give me access to such information. They were so tired of this situation that they simply gave up and began to close the tickets attached to them. One of the network developers spent three months studying and fixing animation graphs. In this case, the developers have found a way to improve themselves, but, unfortunately, without improving the company. Since I managed to find out this even before the excursion around the company, I immediately laid it all out to top management. They immediately asked who disclosed this information to me and wanted to take harsh measures because of a violation of subordination, instead of trying to solve the problem. For the fact that I did not name the names, they refused to work with me, and my services were no longer required. A month later, 2 developers remained in the team instead of 7, they left the sinking ship. A month later, they called me and said that the company no longer had a development team and asked me for a quote to complete the development. Their proposal was much lower than the budget required for the implementation of the required steps. As a result, they hired a completely new team of even less experienced developers, and the process was repeated anew.

Another company in a similar situation appealed to me, because I worked with one of her close friends. Her reaction was different: everyone gathered in one room, everyone was allowed to talk about their problems, and then actions were taken. After three years, the company has become three times larger and is now working on amazing projects.

If you are a manager, you can understand that a developer is satisfied with his work, if he is free to give feedback to management about his problems. If you are a developer, you can understand that the manager is actively working on your side, if you see that in response to your feedback, at least some actions are taken. When one or the other occurs, management may notice an increase in the number of problems reported during the development process, but it will also see an increase in the number of solutions, and this is better than the fewer problems noticed when critical tasks remain unresolved. A good tool for determining which camp you are in is the task burn charts (Burndown charts). If, with proper use of error tracking software, you see bursts of errors, and the values ​​of the number of open problems weekly do not correspond to the number of solved problems, then your team does not fully use its capabilities. There is a high probability that it is affected by some hidden problems. Get together and listen to them, but more importantly, take action. In many cases, even a wrong action with the right message is better than no action if you really want to admit a mistake. If the trajectory of the combustion tasks is an inclined line (for example, a straight line), then your team most likely works as it should, and you do not need to control it.

In this case, even if you have a sincere developer, every day telling about the problems in the development, it does not always mean that the team is healthy. If the cause of problems in the team is only one developer, and you do not have a technical manager, then usually one of two situations arises. This person actually deserves to become a technical manager and his fellow engineers trust him to make the necessary changes, or this developer is just an asshole. By meeting with the development team and carefully listening to them, you will quickly figure out what situation you are in. Respect for developers and attention to their feedback is usually the best way to recognize a situation.

If my name is to come and deal with engineering problems, I immediately begin to look for people who are dissatisfied with the company or have already been working through the last weeks before being fired and employed at another company. If I manage to find out that they are unhappy with justice, and not just wreak havoc, then I will just tell you what your developers know. And most likely I will take more from you than you would spend on a conversation with your subordinates.

If you don’t listen to this retelling of information and you will still be set on hiring third-party workers to solve your problems, then I will take up the necessary amount of development and shock you by how productive one engineer can be. In fact, this is not because I am a high-level super-genius developer, but because I can use the work of your team correctly, because you are too impenetrable to figure it out in a different way. This brings us back to the “Learn from your mistakes” section.I will give you all the necessary tools and put all my skills to help you avoid the same mistakes. If you don’t want to learn, I’m happy to take extra payment the next time you call me.

It is important to note that I am not trying to take advantage of your problem. If I take more, then I'm tired of the fact that you do not learn the lessons that I teach you. In fact, I reduce my prices and actively agree to work for companies that have proven to learn from their mistakes and adapt. This happens because they may still have a problem or they are in a situation caused by external forces. I just like working with those who understand the meaning of the growth of employees and the company; This is what I strive for. Because of this, I take to work on amazing projects, regardless of the money received. The atmosphere in which your developers are satisfied and do not want to run anywhere, even in the case of offers from other companies, is important to me.

Do not become a military history with GDC

What is this story? The most experienced game developers have their own military stories . And you do not want to be one of them. Believe me, when a company reaches a certain level of hell, everyone will know about it. Everything.And if they still do not know, they will find out very soon.

Some of the points listed below happen too often.

War stories have the following (and also some other) signs:

• In the company there are all kinds of attacks and insults.
• HR openly speaks "on the side of the company"
• Unpaid graphics resource tests are often used during product delivery.
• Business deals are made by strip clubs.
• Interviews take place in strip clubs.
• Parties for employees are held in strip clubs
• , ,
• -
• , -
• , -
• ,
• X Y Y, X , Y «»
• You have a shared restroom with another company, and this company clearly does not follow the rules of conduct in the restroom and you continue to ignore this fact.
• Oral insults to personnel who are obviously overworking and experiencing mental problems, because they are constantly reworking and being verbally abused.
• In your company, without any serious reason, they beat employees, business partners, etc.
• Creating a hierarchical structure based on the skill of playing golf
• You're just an asshole and letting you do nasty things under your guidance.
• You do not give employees access to drinking water, but continue to hire people
• Creating an atmosphere in which two opposite sides of the problem can exist without any compromises on both sides

Maybe we should start the #gamedevwarstory campaign.

Do not be a victim of corporate cultic culture or Kool-aid culture.

If your company has fewer than 50 employees, then you need people who are able to think for themselves, aspiring to their own growth and to contribute to the growth of the company. And you definitely do not need employees to blindly follow you along the potential path of self-destruction, believing that everything in the company is done exactly as it should.

In very large companies, employees can sometimes adopt this way of thinking, and never get rid of it. It is known that when working in some companies for survival it is necessary to succumb to the corporate culture of Kool-aid . If you hire an employee to work on the game, constantly underpay him and make him want toto actively play this game during lunch and after hours, the atmosphere created is incredibly harmful to everyone. People and companies risk their own growth when they see only their own product or idea.

If you hire someone from such big companies, “Kool-aid drinkers”, then it is important to test candidates for the ability to think independently. What works for your company does not always fit company X, and if the candidate cannot adapt, then you are preparing a potential military history for yourself.

If you are an employee, then it is important to know what is good for the company and what is artificial flavors. He should actively support the path chosen by the company forward, and not passively observe the deterioration of the situation. One day you can wake up with a feeling of disgust that doesn’t drown out anything.

We develop as a developer / let grow our developers

If you are a developer (but this may apply not only to development) or want to grow a developer from someone, then the most important thing for you is to identify the problems and weaknesses. If I could share only one lesson with the readers of this article, it would be like this: if you can discover and solve your problems as a whole team, and not as a separate person, then you will be fine.

If you are a leader, then try to find the weak points of your developers, but do not be too straightforward. You can not just call the developer to the office and ask in the forehead: "What are your weak points?", Sometimes it looks too provocative. Act gradually. Try to call the developer for a long and meaningful conversation. If you are a tenant, manager, producer, etc., then this is the most useful skill in communicating with people, making the team as effective as possible.

I ask the readers who read the article to consider the following: it turned out that my views on this topic cause quite a lot of controversy and many take other points of view, but if you want to understand your developer level, this will be a good starting point. The truth will show only your personal experience and military history.

If you are a developer, then you always have the “weakest point”. Junians, foreign ministers and seniors are usually usually distinguished from each other by their weak points, and not by their strong points. There are exceptions, but usually it happens like this.

For example, you have mastered C ++ and the Unreal Engine 4 well, and you also know how to provide access to gameplay systems so that designers can work with them. But you lack the ability to convey to designers what exactly you have opened them access to. This signals that you are a mid: you can be trusted to work, but to understand the work, there must be other people in the team. If for the organization of meetings and reporting information you need more help from above than from the side, then you are mid.

If you are a guru of gameplay mechanics, but in the mechanics you worked on, you need some special kind of rendering or visual effects, you don’t know how to implement them, and you need help equal to you, not from above and to do the work , you are able to convey this need without holding hundreds of meetings with several departments, then there is a high probability that you are a senior developer.

If it turns out that you constantly argue with equal to you about the implementation details, but you know when to compromiseand you can do it in such a way as to raise morale, rather than lowering it, that is, you are very likely to be a mid-level developer moving toward senior level or becoming a technical manager, but you simply don’t have enough experience to see it. Skill experience will allow you to speak with great authority and to propose implementation ideas that look generally more solid, without the need for unnecessary debate about the correctness of this implementation. The skill experience also allows you to quickly retreat and admit your mistake if you really made a mistake in the implementation details.

To become a senior developer is to be able to understand what is right and the ability to realize it. To be a senior is to improve your skill, to be disciplined and not to repeat mistakes. You become less an engineer, not when you make mistakes, but when you don’t learn from your mistakes.

If you find yourself able to do an incredibly good job as a team, but you lack the skills to become one who finds the “last puzzle piece” or “solving a critical problem,” then most likely you are not moving towards Senior, and you better develop as a lead developer.

I believe that leading developers should not be confused with senior developers. Lida should have good skills and have great powers in the structure, but this does not mean that they automatically need to pay more and trust. The task of the lead developer is to lead. The task of senior-developer is to solve complex problems. Ideally, the lead developer should be a senior developer, but this is not always the case. I can talk for a long time about the differences between the lead and the senior, but the article is not about that. Understanding this is the task of the producer.

Of course, you can find yourself in a situation that is not considered here, and I only briefly described the possible weak points of the developer. But try to determine the type of your weakness on the basis of whose support you need in order to cope with it, and how much this support should be.

If you ask for help from people below, near and above you, then you are probably an entry-level developer. If you often need support from above (unless it is the support of the first persons of the company, which, my friends, is a completely new level of hell), then there is a great chance that you are a mid-developer. If you are supported and you support people nearby, then you are most likely a senior or lead.

If you are a manager or producer, this is how you should classify the weaknesses of your team and approach the distribution of the team’s efforts to overcome them. If you find yourself in a situation where top-level developers do not have enough time, because they constantly help people below them, then you need more senior developers. If productivity is high, but you are not using enough seniors, then the decision will be to hire foreign ministers. Seniors will help midam to grow, which in turn will help grow and seniors, or "sideways", for the position of lead, or up to the posts of managers / directors / members of the board.

If you, as a producer or employer, cannot classify the weaknesses of the developers, then contact a developer who can work with you to develop your skills in detecting weaknesses. If no one is able to find any weaknesses anywhere, then you had better go and find another place to grow.

Stupid things that poor developers or developers without developers do to themselves

When it comes to the purely engineering aspect of working as a developer, sometimes being a developer means simply sticking to seemingly simple principles. If I am called to determine a purely engineering problem, then 95% of the time I usually spend on finding the problem, 4% on fixing it, and 1% on telling everyone that the problem has been solved.

Any high level developer specializing in Unreal Engine 4 should know how to use the game stream profiler and GPU profiler. He should be able to create blueprints and / or write C ++ code without creating spaghetti. He should at least at the simplest level understand what is happening in the whole engine and all its systems. The manager of any team should be able to recognize whether the developer is capable of it. You can write a whole article on this topic, so instead I will simply list the most ridiculously standard problems that I encounter every time I am hired to solve the “optimization problem” of the project. I hope that by reading about these problems, you will learn to understand the thought process necessary to recognize the signs that lead to costly and difficult to maintain development.

If you are a beginner or intermediate developer who wants to develop further, then I hope that this list will give you confidence that in order to take a step forward or rise higher, you only need to be able to identify ridiculously simple problems and effectively communicate them. before the rest. This list is by no means exhaustive. These are just my most frequent and recent problems that I solved for clients. Some of them are painfully obvious.

• : ? , ? , . - , - , - ? , .
• , : Perforce 2000 2 « » — . , - , , .
• : , . , 1 9 . . , . , , - . : .
• : , VR , . , 1 VR , Nvidia 960. 960 11 , . - 3 .
• : . , . .
• : , proof of concept , , / . .
• - : , . , , . ? .
• : , , . « » .
• : , , 100 1 , .
• . : «, , ». Not. - . , . , . .
• , : , 2 000 SSD X Y, «», , , , . , 70 - , . SSD, 60 - . , . - , .
• « »: « , », . 90% . , , .
• , , : . , , , .
• 4k : 4k , . .
• 1000 — : . , 3 FPS, - -, 3 FPS.
• 500 : , , 256 . .
• PBR-: ? PBR. 4k.
• 12 : . 12 , - .
• LOD: LOD, LOD .
• , : , , , , . , .
• VR — : , 20 , , , .
• VR — Forward Rendering Deferred Rendering: (deferred) (forward) , VR-, . , , , . : , VR, , , .
• VR — : UE4 VR. , , . - , , .

Sometimes development is the most stubborn and painful thing that can be, but those who love this job like the feeling of solving a problem. They practice the “Just Work” approach . Try not to forget this feeling, especially when you have been beating your head on the keyboard for three weeks, because the “simple” task is not so simple.

You are not alone in your solitude.

If you have not found your personal rubber duck , then continue to look for him.

Author's note after the publication of the article

I was really shocked by the popularity of my article. It has spread much wider than I could have imagined. The many comments and discussions that she caused confirm that the problem is not only related to my fellow developers, but has spread widely to all areas of game development and even more widely - to programming as a whole. It inspires me to take a deeper look at some of the aspects and try to find a solution to many of these widespread problems.

On the other hand, the fact that I almost did not see the comments from managers, producers and managers makes me think that my efforts are meaningless.