It's hard to argue that the landscape is an integral part of most computer games in open spaces. The traditional method of realizing the change in the relief of the surrounding surface player is the following - take the mesh, which is a plane and for each primitive in this grid, we make a displacement along the normal to this plane by a value specific for this primitive. In simple words, we have a single-channel texture of 256 by 256 pixels and a grid plane. For each primitive from its coordinates on the plane, we take the value from the texture. Now we simply move the coordinates of the primitive along the normal to the plane by the resulting value (Fig. 1)
Pic.1 map of heights + plane = terrain
Why does this work? If we imagine that the player is on the surface of a sphere, and the radius of this sphere is extremely large in relation to the size of the player, then the curvature of the surface can be neglected and a plane can be used. But what if we do not neglect the fact that we are on the sphere? I would like to share my experience of constructing such landscapes with the reader in this article.
In the code id Software sometimes there are unmatched pearls. The most famous is, of course, 0x5f3759df , which even got comics on xkcd . Here we are talking about filling the screen: pixels are colored one at a time in random order, without repetition. How is this done?
On November 23, 2011 id Software supported its own tradition and published the source code of its previous engine.
This time, it's time idTech4 , which was used in Prey, in Quake 4 and, of course, in Doom 3. In just a few hours more than 400 forks of the repository on GitHub were created, people began to explore the internal mechanisms of the game or port it to other platforms. I also decided to participate and created a Intel version for Mac OS X , which John Carmack kindly advertised .
From the point of view of cleanliness and comments, this is the best release of the id Software code since the code base Doom iPhone (which was released later, and therefore commented better). I highly recommend that everyone learn this engine, collect it and experiment.
Here are my notes about what I understood. As usual, I cleaned them, I hope they save someone a couple of hours and encourage someone to study the code to improve their programming skills.
"Something is missing here." I bet you, this idea will come first to your head, if you see my workplace in the office. There is no monitor and mouse. There is only a guy who threshes on the keyboard, looking as if into emptiness.
It's just me, and my colleagues guarantee you that I'm usually not dangerous. I'm a programmer at the Vincit office in Tampere (Finland). And I'm blind. In this article I want to tell you a little about how I work.
One of the most important factors affecting the speed of development and the success of the project launch is the correct decomposition of the product manager idea into tasks for programming directly. How to do it right? Take the script of the new feature from the product and immediately start coding? First, write the acceptance tests, and then code that will provide their passing? And, maybe, shift everything to the shoulders of developers - and let them decide during the spam poker themselves?
Let's think about it and identify the problems that can arise in the process of separation of tasks, and the ways to solve them. In this post, we will discuss the basic principles of decomposition of tasks when working in a team. My name is Ilya Ageyev, I'm the head of QA in Badoo. Today I'll tell you how workflow affects decomposition, how different are testing and laying out tasks that arise as a result of decomposition, and what rules should be followed to ensure that the development process goes smoothly for all participants.
The meeting of the ISO WG21 C ++ Committee, which was held in Toronto from 10 to 15 July, ended today. Soon we will surely be waiting for detailed report from WP21 , and today the respected public is offered a post- "Warming up" with a discussion of the most interesting.
The results of the meeting are as follows: C ++ standard 17 is completed and will be published at the next meeting in November this year; the standard C ++ 20 has already acquired the first serious features - concepts ( concepts ), explicit generic lambda functions (explicit explicit lambdas < / i>) - and this is just the beginning.
The possibilities of the new C ++ standard 17 have been discussed more than once, about innovations written on Habr , conducted reports at conferences , so I will not bring them here again. It's no secret that the key feature of this release of C ++ was carrying the most "delicious" options into an uncertain future. Well, now we can say with certainty that many of the long-awaited "features" have moved to C ++ 20. The course taken for the stdlib extension has not gone away, so a much larger and rich set of functions can be expected from C ++ 20.
Everything should be stated as simply as possible, but not simpler.To make the game entertaining and interesting, it is not necessary to make computer-controlled opponents smarter. In the end, the player must win. However, letting him win only because the manager of the opponents of AI is badly designed, is also unacceptable. Interest in the game can be increased if the mistakes made by the enemy are intentional. Carefully adjusting the mistakes of opponents, making them intentional, but believable, programmers will allow opponents to look smart and at the same time ensure the victory of the player. In addition, by monitoring AI systems and appropriately controlling them, you can turn situations in which opponents look silly into an interesting gameplay.
- Albert Einstein
A common mistake in the development and implementation of AI systems in computer games is in too complex a design. The AI developer can easily get carried away by creating an intelligent game character and losing sight of the ultimate goal, namely, creating an entertaining game. If a player has the illusion that a computer opponent is doing something clever, then it does not matter how the AI (if any) creates this illusion. A sign of a good AI programmer is the ability to resist the temptation to add intelligence to where it is not needed, and to recognize situations in which more "cheap" and simple solutions are enough. Programming AI is often more like art than science. The ability to distinguish between moments in which cheap tricks are enough, and those where more complicated AI is required, is not easy. For example, a programmer, having full access to all structures of game data, can easily cheat by making the NPC omniscient. NPCs can know where the enemies are, where the weapons or ammunition lies, without seeing them. However, players often recognize such cheap stunts. Even if they can not determine the very nature of cheating, they may have a feeling that the behavior of the NPC is not like the natural.
How does the JVM create new objects? What exactly happens when you write a new Object ()?
At conferences, it is periodically told that the allocation of objects uses the thread-local allocation buffer (TLABs): memory areas allocated exclusively to each thread, creating objects in which is very fast due to the lack of synchronization.
But how correctly to choose the size of TLAB'a? What to do if you need to allocate 10% of the size of TLAB'a, but only 9% is free? Can an object be allocated outside TLAB? When (if) is the allocated memory set to zero?
Having asked these questions and did not find all the answers, I decided to write an article to correct the situation.
Before reading it, it's useful to remember how some garbage collector works
The problem of most disputes about the problem of piracy is that in them "value" is estimated only in "monetary" dollars. Therefore, the problem is formulated like this: "When buying a game from us, the user spends money dollars. A pirated copy costs zero money dollars. So most people will pirate the game if they have a choice, so you need to stop them at any cost. "
The dollar is famous for everyone.
This is the error, therefore, at least four currencies, and not one (monetary dollars) should be taken into account here.
I propose the following notation:
($ D) Monetary dollars
($ B) Temporary dollars
($ D) Headache paints [in the original Pain-in-the-butt-dollars]
($ Ч) Honesty Dollars
The player makes the choice to buy or spiratit game based on how much "each" service (and not product! ) costs in these four currencies, and also depending on the value for the player each of them.
Image: TED Conference , CC BY-NC 2.0
In April 2017 published an article Will Gornalla from the University of British Columbia and Ilya Strebulaeva Stanford called "We bring venture business assessments to reality." In it, scientists analyzed the estimates of more than hundreds of world-famous companies (including technological ones) with an estimate of one billion dollars or more (the so-called "unicorns").
It turned out that these estimates do not always correspond to reality and can be repeatedly overstated. We publish the main findings of this study.