Technology stack principles and vision for unified data

Unity Data Oriented Tech Stack based on a set of principles. These principles provide a good background for the goal we are trying to achieve. Some principles clearly reflected in the code. Others just set our own target.

Performance under default

We want to create an efficient machine code for all platforms easy.

We use highly optimized handwritten simd intrinsics to measure the performance of C ++ that can be achieved.

We use compiler technology (Burst), the container (Unity.Collections), data layout component (ECS) is combined to easily write efficient code by default.

  • And iterative data layout - physical components of the system in the form of a block to ensure data layout linear iteration entity by default. This is to provide performance-oriented technology stack unified data key part.
  • C # operating system allows you a simple way to write multithreaded code. It is also very safe. C # Job Debugger can detect any competition.
  • Burst is our C # compiler specifically for the job. Job C # code follows certain patterns that we can use to generate more efficient machine code. Using the SIMD instruction for each target platform compiled and optimized code.

An example of this is the performance of Instantiation. 100,000 instantiated entity having 320 bytes requires memcpy 9ms theoretical limit compared by components of the system entity instantiates these entities needs 10ms. So we are very close to the theoretical limit.

In the Unite Austin, he showed us a demo with 100,000 individual cells in a large battle simulation 60 FPS's. All are running multi-core game code. See ECS performance demonstration [video]

simple

Write high performance code must be simple. We believe we can write fast code as MonoBehaviour.Update as simple.

Note: To properly set expectations, we believe that we are still some ways to achieve this goal.

One way to write code

We want to write code that define the game, a single edit code, assets plumbing code and engine code. We believe this creates a more simple tool for our users, and more able to change the status quo.

Physics is a good example. Currently physics is a black box solution. In practice, many developers want to adjust the simulation code to suit their gaming needs. If you use ECS to the game code written in the same way as physics engine code, you can easily insert your own simulation code between the existing physical simulation phase or full control.

As another example, let's imagine you want to make a large-scale changes can be made in the game.

If we import pipeline as a group ComponentSystems implemented . We have some FBX import pipeline code by default for importing FBX files and post-processing assets in the pipeline. (Mesh using FBX and import code in the editor.)

Then, it is easy to configure the package manager, FBX can use the same post-treatment and the introduction of modifications in the code deployed in the game.

We believe in the basic level, which will allow Unity is more flexible than it is now.

networking

We want to define a simple way to write code for all games. Following this method, you can use one of three gaming network architectures, depending on the type of game that you create.

We focus on providing the best network engine support for hosting the game. Use recently acquired Multiplay.com service, we provide an easy conduit for hosting the game.

  • FPS - simulation on the server
  • RTS - deterministic simulation lockstep
  • Arcade Games - GGPO

Note: To properly set expectations, we have not provided any entity on the network code components of the system. It is in progress.

Uncertainty

We build the pipeline must be deterministic . Users can choose whether all simulation code should be run deterministically.

No matter what device you use, you should use the same input to achieve the same result. This is important for network playback function even advanced debugging tools.

To this end, we will use the Burst compiler to generate an accurate floating-point math operations between different platforms. Imagine running the same floating-point math code linux server and iOS devices. This is useful for many scenarios, especially for the connection of the game, as well as commissioning and replay.

Note: The difference is the floating-point math Unity decided to solve the problem. This problem has been understood for some time, but so far there is not enough need to encourage people to solve it. To solve this problem, including avoiding solve some of the solutions required, please consider reading Bruce Dawson float certainty .

Sandbox

Unity is a sandbox, safe and simple.

When used incorrectly API, we provide a good error message, we will never put their own improper use of position led to the collapse, which is (rather than we can quickly fix errors) on the design.

A good example is our sandbox behavior of C # operating system to ensure that your C # code is not competitive work conditions. We examined a combination of deterministic examine all possible conditions of competition and run through a static code analysis. We will provide information about any error conditions of competition for you immediately. Therefore, you can be confident that your code works correctly and feel safe, even if the game developers to write multi-threaded code will do well the first time.

Minimality

We hope that Unity can be used from <50kb executable file to gigabytes in size all the contents of the game. We hope that Unity small load content in less than one second.

Iteration time

Our goal is the large-scale project folder iteration time of any common actions to maintain 500ms or less.

As an example, we are working to rewrite the C # compiler is a full incremental, objectives are:

When you change a single .cs files in large projects. And compiling the combined thermal overloads should be less than 500 milliseconds.

We provide a complete code of unit test coverage

We believe that from the outset to provide powerful code. We use unit tests to prove that our code works fine in the preparation and submission of developers. Test as part of the package.

evolution

We know we made some very big changes in terms of how to write code. From MonoBehaviour.Update to ComponentSystem and use the job.

We believe that ultimately the only way to convince game developers that try it, and saw their game results .

Therefore, the application ECS method should be easily and quickly in an existing project. Our goal is within 30 minutes, the user can change some code in the large-scale projects from MonoBehaviour.Update to ComponentSystem, and optimizing the game code has successful experience.

package

We hope that most of our engine code is written in C # and deployed in a Package. All Unity Pro customers can use all the source code.

We hope to establish a rapid feedback loop with customers, because we can push the code and quickly get feedback in the package, and will not destabilize other parts.

Most of our engine before the code is written in C ++, how to write code this way with our customers and Unity programmers write code generated out of line. Because Burst compiler technology and ECS, we can use C # than C ++ code to achieve better results, so we can write code in exactly the same way.

Cooperation

We believe that Unity Unity users and developers are in the same team. Our goal is to help all Unity users faster, higher quality and better performance to create the best gaming experience.

We believe that we have developed for each function must develop real scenes and real production feedback as soon as possible. Package Manager to promote this.

For those who would like to contribute engine code user community, our goal is to achieve this goal through a direct deal with the same code repository contributors can submit. Comprehensive test coverage by clear principles and functions of all, we want to maintain a high quality of contributions.

Source code repository will apply to all Unity Pro customers.

transparency

We believe in transparency. We open our feature development, we actively communicate on forums and blog. We reserve the right time, so that each developer can spend time with customers to understand the user's pain points together.

Guess you like

Origin www.cnblogs.com/longsl/p/11323671.html