Which engine is made by World of Tanks. Test a new engine. New gaming engine
It's time to buy new video cards or announces of the new WOT engine.
The WG Fest announced the exit of completely new tanks. In fact, it is already a completely different game, as the new engine, sounds, HD cards. Despite visual improvements, the developers promise that performance does not fall. If you are playing with 30 FPS now, then the new engine will be the same.
While only one trailer is available:
What is known at the moment?
- The update will be released in March 2018.
- New engine called Core. (Current WOT engine) Neegen goes into the past.
- From the existing engines, no one could satisfy the developers, so it was decided to do everything from scratch.
- On the development took 4 years: 3 years on the engine itself and another year to create content (cards).
- To estimate the performance, you can already download a special software ENCORE, which will spend a test, based on the results of which you can evaluate how suitable for your PC is suitable for a new game.
- encore can be launched in three modes Graphs: minimum, medium and ultra.
- The test goes three minutes, shows the replay of the stage with the demonstration of new graphic capabilities and effects.
ENCORE WORLD OF TANKS test result.
- HD cards - all locations are redested under high clarity. And this applies to all aspects: landscape, textures, lighting, sounds, effects, environment, etc.
Full list converted to HD cards.
- Fully rewritten soundtrack. Each card will now have their own music that transmits the unique atmosphere of location.
- They promise that work on optimization is done good and strong loss of FPS should not be.
BigWorld Engine is the most advanced 3D engine to create MMO games. On it are made such games as "World of Tanks", "PEALM OF THE TITANS" from wargaming.net and other games of other world-class game developers. There are more than 15 MMO games on this engine. He is being developed by Bigworld Technology.
Engine optimization allows you to create low-consuming games with stunning graphics. The engine allows you to port games on iOS. Written in the C ++ programming language, the implementation of the game logic in it is performed on a convenient script Python. There are powerful tools and a client-server engine. For sound, the FMOD library is supported, and any other libraries are connected through a plug-in system. Works with XML and MySQL bases. The toolkit has powerful World Editor, Model Editor and Particle Editor.
It is very accessible in price. Build BigWorld: Indie Edition costs only $ 299; BigWorld: Indie Source Edition - $ 2,9999; BigWorld: Commercial Edition - negotiated individually.
This advanced engine is not inferior in the possibilities of other world engines of their type. The engine is available in Russian, Korean, American and Japanese. There is documentation, can work on browsers. In general, you can proceed to work if there is knowledge and diligence.
Already not available for third-party licensing, because Wargaming decided to abandon the spread of his engine.
Official site: http://www.bigworldtech.com.
The Bigworld Technology Tool Chain Provides A Complete, End-to-End Mmog Content Creation System That Will Enhance The Quality and Timeliness of Your Game. All Tools Are Designed for Cooperative Production of Game Assets in A Large Team Environment, Ensuring Effective Use Of Resources and A Smooth Content Pipeline.
From October 2 to October 8, representatives of communities and bloggers from various regions were in the Minsk Development Center. Polish DOM1N portal publishes a greater exposure that Matchyhk (Asian Community Contributor). In the answers there may be minor inaccuracies, for the original was translated 2 times: English - Polish - Russian.
Alexey (inaki) Ilin was responsible for questions - the global producer of the World of Tanks project, as well as other developers. Huge and detailed selection. Part 2.
Chapter 4. Economy and game mechanics:
* Some players really do not like the "Clown camouflage" (for example. Patriot or Liberte). What is the opinion of developers about this?
- This is a very good question! We are working on new system Customization where players will be able to customize their cars in detail.
We want to make this system very good, so that we can not immediately call you the timing of the exit and we are not in a rush to enter it. But with its help, we will be able to give players a lot of textures and customization of tanks.
// Interesting story:
When we entered Skorpion G, we actually created 3 visual models. There was an ordinary skorpion (in German gray) and Skorpion, which we all know. The third had a very unhistrict / unreal texture and was considered unsuitable for the game.
* What happened to the New Year Iveth with drawers? Wargaming thinks over the system of boxes with skins as in CS: GO or Overwatch?
* Can I enter something similar to the container system in World of Warships?
- We like the idea. But unlike WOT, WOWS a new game. Containers were introduced when the economy reform was held in the game. For us it is more difficult, as it is necessary to take into account the past WOT. It is difficult to introduce anything that makes changes to the in-game economy. If we enter something like that, we need to plan it very carefully. This may entail negative impressions of the players if we reduce their profits to compensate for the innovation, and they will assume that they earn less loans.
* Will there be more variability in random? For example, night battles or weather?
- If we introduce night battles or weather, then we need to decide whether these changes will only cosmetic or also affect the gameplay, for example. Reduce viewing range at night or during a sandy storm.
* Do you think "ban" XVM?
- We know that MOD XVM entails indignation in the game, in addition to focus on XVM. But we can not just withdraw XVM from the game. XVM also gives many other functions, in addition to displaying statistics. We work closely with XVM developers. Some players use XVM planning a battle strategy (for example, ride allied purple players, or focus fire on enemy - unfortunately).
2 years ago we collected statistics on XVM and realized that more than 50% of people use XVM without the function of statistics. Therefore, we work on the introduction of these functions into the game client, thus making XVM unnecessary. Recently, we introduced our own rating system, because We think we can make a more accurate measurement system. This will give the players a more accurate assessment and comparison system.
At the same time, the company conducted a study by the possibility of prohibiting foreign services to receive data from the Wargaming API. This leads to problems with data analysis for many important services. We are working on it.
* Can I hide players in battle?
- Unfortunately, we do not think that this is a good idea. Some may calculate that they are playing against bots. It also makes it difficult for social relationships in the game. It is impossible to know if the player is in the clan, and it would be difficult for clans to look for new players.
* How are things with the "general battle"?
- General Battle - Successfully and players like, and the card is well balanced from the point of view of statistics. But in Asia and America, due to the lack of a large number of players on 10 LVL and the parallel launch of rank battles, a very small amount of GS is collected. We are the rules and customize at the moment.
* Artillery annoys, you will remove or remake it yet?
- We will not remove artillery. This class is for people who love to predict the behavior of other players. There is a proportion of people who really like this class, and some people play only artillery. Now you can survive under fire more, and not to die from Vanzota.
Chapter 5. Gaming Engine:
* Will it be removed the current limit of the gaming engine in 127 FPS with the introduction of HD cards?
- We know about the growing use of high-quality monitors (144 and 165 Hz). Restriction of 127 FPS is not because of the client itself, but due to the old server part of BigWorld. As we have already spoken, the client part has been practically rewritten again. Similarly, the server component is now rewritten, and the FPS limit will not be needed. We think to remove or replace it, it is tested, but may not be added in the sandbox.
Yesterday everything went out without block.
* Locking guns / strange camera behavior (eg when you go from a sniper mode to normal or on the contrary if you have any obstacles) is very annoying not only on HD cards, but also on a common server. Will it be fixed?
- We know about this problem. Unfortunately, we have no explicit solutions at the moment. However, from the moment of entering the promsion map, we corrected the logic of the camera's behavior. This improved the situation, but not perfect. The behavior of the camera in WOT is much more difficult than a conventional shooter (in WOT it is necessary to take into account many factors, for example, the speed of rotation of the tower and the case.) No simple solution This problem, but with new technologies we hope to resolve this problem.
Chapter 6. Miscellaneous:
Some players suggested entering digital parameters in sensitivity settings. It was taken note and will be taken into account later. But according to statistics, very few players change control settings.
- The fate of ChiefTain MK. 6 - Unfortunately, it is unlikely to be entered into the game. As if we did not want to introduce it, we would not want it to explore with Conqueror. If we find suitable candidates for lower levels with a similar gameplay, we will think about entering chieftain in the game.
* WG thinks over the introduction of the Romanian branch?
- Unfortunately, we do not think that Romania has enough tanks to draw up their own branch.
* When will Polish tanks?
- Still working on the Polish branch, but we have already found all the cars for her. Therefore, we will try to introduce these tanks as quickly as possible. But it's too early to annon specific dates!
* Where is Serb (Serb)? What does he do? Does he work on his project of lunar base?)
- Serb works with us. It does not work on the project of the lunar base. He is now working on other Vargeiming projects.
Initially, it seemed to everyone that there would be a very good idea to make several small games that would attract new users in large "tanks". After a number of experiments it turned out that it did not work. Despite excellent conversion in mobile applications, transfer from mobile phone PC turned out to be a precipice for users.
Then in development we had several games. One of them wore the operating name "Sniper". The main gameplay idea was shooting in sniper mode from a tank standing in defense, according to other tanks that AI managed and which could attack in response.
At some point it seemed to us that the standing tank was very boring, and in a week we made a multiplayer prototype, where the tanks could already ride and attack each other.
Since this all started!
When we started the development of a "sniper", we considered technologies that were then available for mobile platforms. At that time, Unity was still at the fairly early stage of its development: in fact, there were no technologies necessary for us yet.
The main thing that we lacked was a landscape rendering with dynamic detail, which is vital to create a game with open spaces. There were several third-party libraries for Unity, but their quality left much to be desired.
We also understood that on C # we will not be able to squeeze the maximum of the devices, which we develop, and always be limited.
Unreal Engine 3 also did not fit on a number of similar causes.
As a result, we decided to refine our engine!
He was already used at that time in our previous casual projects. The engine had a fairly well written low level of work with platforms and supported iOS, PC, Mac, plus work on Android was started. A lot of functionality has been written to create 2D games. That is, there was a good UI and a lot of everything to work with 2D. It had the first steps in the 3D part, as one of our games was completely three-dimensional.
What we had in the 3D part of the engine:
- The simplest graph scene.
- The ability to draw static meshes.
- The ability to draw animated mesh with skeletal animation.
- Export objects and animations from the collada format.
Beginning of work
It all started with the proof of the ability to draw the landscape on mobile devices: Then it was iPhone 4 and iPad 1.After several days of work, we received a completely functional dynamic landscape, which worked rather well, demanded some of the 8MB of memory and gave 60fps on these devices. After that, we started a full-fledged game development.
About six months passed, and the small mini-project turned into what Blitz is now. There were completely new requirements: MMO, AAA-quality and other requirements that the engine in its original form at that time could no longer provide. But the work was boiling in full swing. The game worked and worked well. However, the performance was medium, objects on the maps was little, and, in fact, there were many other restrictions.
At this stage, we began to understand that the foundation we laid in the engine will not withstand the press of the real project.
How everything worked at that time
All scene drawing was based on a simple concept of Scene Graph.The main concept was two classes:
- SCENE - Scene container, inside which all actions took place
- above the scene.
- Scenenode - the basic class of the scene node, from which all classes were inherited, which were in the scene:
- MeshinstanceNode - class for drawing a mesh.
- LODNODE - class for switching of boats.
- Switchnode - class to switch the switch objects.
- about 15 classes of Scenenode heirs.
The main functions that could be override is:
- Update - a function that was called for each node in order to make update scenes.
- Draw - a function that was called for each node in order to draw this node.
First, performance:
- When the number of nodes reached 5000, it turned out that simply go through all empty Update functions, takes about 3ms.
- Similar time went to empty nodes that did not need DRAW.
- A huge amount of cache Miss, as the work has always been done with different ways.
- The inability to parallery work into several cores.
- Changing the code in the basic classes influenced the entire system of the entire system, that is, each change of Scenenode :: Update could break anything and anywhere. Dependencies became more complicated and more complicated, and each change in the engine inside the engine is almost guaranteed to test the entire associated functionality.
- It was impossible to make a local change, for example, in transformation so as not to hurt the rest of the scene. Very often the slightest changes in Lodnode (knot for switching shods), broke something in the game.
First steps to improve the situation
To begin with, we decided to treat problems with productivity and make it quickly.Actually, we did it by entering the additional NEED_UPDATE flag in each node. It determined whether such a node is necessary to call Update. It really increased productivity, but created a whole memory of the problems. In fact, the Update function code looked like this:
Void Scenenode :: Update (IF (Flags & Need_Update)) Return; // The Rest Of the Update. FUNCTION // PROCESS CHILDREN)
It returned to us part of the performance, but many logical problems began where they were not waiting.
Lodnode, and Switchnode - nodes that answer, respectively, for switching the lodges (by distance) and switching objects (for example, destroyed and non-destructive) - began to break regularly.
Periodically, the one who tried to correct the breakdowns did the following: Disable Need_Update in the base class (after all, it was a simple solution), and completely unnoticed FPS again fell.
When the code checking the NEED_UPDATE flag has been commented three times, we decided to radical changes. We understood that we could not do everything at once, so we decided to act in stages.
The very first step was to lay an architecture that will allow us to solve all problems that arise from us.
Goal
- Minimize the dependence between independent subsystems.
- Changes in transformations should not break the system of logs, and vice versa
- The ability to put the code for multi-core.
- So that there are no Update functions or similar, in which heterogeneous independent code was performed. Easy expansion of the system with a new functionality without complete adhesiveness of the old. Changes in some subsystems do not affect others. Maximum independence subsystems.
- The ability to arrange data linearly in memory for maximum performance.
Combining component and Data-Driven approach
The solution to this problem was a component approach combined with a Data-Driven approach. Further in the text I will use a data-driven approach, since I did not find a successful translation.In general, the understanding of the component approach in many people is the most different. The same - and with Data-Driven.
In my understanding, component approach - This is when some necessary functionality is based on independent components. The easiest example is electronics. There are chips, each chip has inputs and outputs. If the chips come to each other, they can be connected. On the basis of this approach, the entire electronics industry was built. There are thousands different components: Connecting them with each other, you can get completely different things.
The main advantages of this approach are that each component is insulated, and more independent. I do not take into account the fact that the component can use incorrect data, and the fee is burning. The advantages of this approach are obvious. Today you can take a huge number of ready-made chips and collect a new device.
What is data-Driven.. In my understanding, this is an approach to design softwareWhen the program is taken as the basis of the program, and not logic.
In our example, imagine the following hierarchy of classes:
Class Scenenode (// data responsible for hierarchical transformations Matrix4 Localtransform; Matrix4 Worldtransform; Virtual Void Update (); Virtual Void Draw (); Vector
The code for bypassing this hierarchy hierarchically looks like this:
Main Loop: Rootnode-\u003e Update (); rootnode-\u003e draw ();
In this hierarchy C ++ inheritance, we have three different independent data streams:
- Transformation
Let's imagine how it should look like in a Data-Driven approach. I will write on the pseudocode to be clear the idea:
// Transform Data Loop: for (each localTransform in localTransformArray) (worldTransform \u003d parent-\u003e worldTransform * localTransform;) // Lod Data Loop: for (each lod in lodArray) (// calculate lod distance and find nearest lod nearestRenderObject \u003d GetNearestRenderObject (LOD); RenderObjectIndex \u003d GetLodObjectRenderObjectIndex (LOD); RenderObjectarRay \u003d RenderObject;) // Mesh Render Data Loop: For (RenderMesh (RenderObject);)
In fact, we have deployed the cycles of the program, making it in such a way that everything is repelled from the data.
Data in the Data-Driven approach is a key element of the program. Logic - only data processing mechanisms.
New architecture
At some point it became clear that we need to go to the Entity-based approach to the organization of the scene, where Entity was an essence consisting of many independent components. I wanted the components to be completely arbitrary and easily combined with each other.Reading information on this topic, I came across the T-Machine blog.
He gave me many answers, my questions, but the main answer was the following:
Entity does not contain any logic, it's just id (or pointer).
Entity knows only the ID components that belong to it (or pointer).
The component is only data, that is. The component does not contain any logic.
The system is a code that can process a specific data set and extrude another set of data at the output.
If you are developing on Java, I really recommend looking at it. Very simple and conceptually correct Framework. To date, he is alive on a bunch of languages.
What Artemis is, today is called ECS (Entity Component System). Options for organizing a scene based on Entity, Components and Data-Driven are quite a lot, however, we came to the ECS architecture. It is difficult to say how common is the generally accepted term, however, ECS means that there are the following entities: Entity, Component, System.
The most important difference from other approaches is: Mandatory lack of logic behavior in components, and separation of code in the system.
This item is very important in the "Orthodox" component approach. If you break the first principle, a lot of temptations will appear. One of the first to make the inheritance of the components.
Despite flexibility, ends usually with pasta.
Initially, it seems that with this approach you can make a lot of components that behave in a similar way, but a little bit differently. General components interfaces. In general, you can again fall into the trap of inheritance. Yes, it will be a little better than classical inheritance, but try not to get into this trap.
ECS is a cleaner approach, and decides more problems.
To view the example, how it works in Artemis, you can look.
I'll show you on the example how it works for us.
The main class container is Entity. This is a class that contains an array of components.
The second class is Component. In our case, it is just data.
Here is the list of components used in our engine, today:
Enum eType (TRANSFORM_COMPONENT \u003d 0, RENDER_COMPONENT, LOD_COMPONENT, DEBUG_RENDER_COMPONENT, SWITCH_COMPONENT, CAMERA_COMPONENT, LIGHT_COMPONENT, PARTICLE_EFFECT_COMPONENT, BULLET_COMPONENT, UPDATABLE_COMPONENT, ANIMATION_COMPONENT, COLLISION_COMPONENT, // multiple instances PHYSICS_COMPONENT, ACTION_COMPONENT, // actions, something simplier than scripts that can influence logic, can be multiple SCRIPT_COMPONENT, // multiple instances, not now, it will happen much later. USER_COMPONENT, SOUND_COMPONENT, CUSTOM_PROPERTIES_COMPONENT, STATIC_OCCLUSION_COMPONENT, STATIC_OCCLUSION_DATA_COMPONENT, QUALITY_SETTINGS_COMPONENT, // type as fastname for detecting type of model SPEEDTREE_COMPONENT, WIND_COMPONENT, WAVE_COMPONENT, SKELETON_COMPONENT, / / Debug Components - Note That Everything BELOW WON "T BE Serialized Debug_Components, Static_Oclusion_debug_Draw_Component, Component_Count);
Threatest class is scenesystem:
/ ** \\ Brief This Function Is Called WHEN Any Entity Registered To Scene. IT Sorts Out Is Entity Has All Need to Call Addentity. \\ Param Entity Entity We "Ve Just Added * / Virtual Void Regisertity (Entity * Entity); / ** \\ Brief This Function Is Called WHEN Any Entity Unregistered from Scene. IT Sorts Out Is Entity Has All Necessary Components and We Need to Call Removeentity. \\ Param Entity Entity We "VE Just Removed * / Virtual Void Unregisterentity (Entity * Entity);
Registertity functions, unregistertity are called for all systems in the scene when we add or delete Entity from the scene.
/ ** \\ Brief This Function Is Called WHEN Any Component Is Registered to Scene. IT Sorts Out Is Entity Has All Need to Call Addentity. \\ Param Entity Entity We Added Component To. \\ Param Component Component We "VE Just Added to Entity. * / Virtual Voidity, Component * Component); / ** \\ Brief This Function Is Called WHEN Any Component Is Unregistered From Scene. IT Sorts Out Is Entity Has All Necesary Components and We Need to Call Removentity. \\ Param Entity Entity We Removed Component From. \\ Param Component Component WE "VE Just Removed from Entity. * / Virtual Void UnregisterComponent (Entity * Entity, Component * Component);
RegisterComponent, UnregisterComponent are called for all systems in the scene, when we add or delete Component in Entity in the scene.
Also for convenience there are two more functions:
/ ** \\ Brief This Function Is Called Only When Entity Has All Required Components. \\ Param Entity Entity We Want To Add. * / Virtual Void Addenity (Entity * Entity); / ** \\ Brief This Function Is Called Only When Entity Had All Required Components, and Don "T Have the Anymore. \\ Param Entity Entity We Want to Removeentity (Entity * Entity);
These functions are called when the ordered set of components has already been created using the setrequiredcomponents feature.
For example, we can order obtaining only those entities that have Action_Component and Sound_Component. I transfer it to the setrequiredcomponents and - voila.
To understand how it works, I will write on the examples, what systems we have:
- TransformSystem - a system that is responsible for the hierarchy of transformations.
- SwitchSystem is a system that is responsible for switching objects that can be in several states, such as destroyed and unusual.
- LodSystem is a system that is responsible for switching the lodes in the distance.
- Particleeffectsystem is a system that updates particle effects.
- RenderUpdatesystem - a system that updates render objects from the scene count.
- LightupDateSystem is a system that updates light sources from the scene count.
- ActionUpDateSystem is a system that updates the Actions (actions).
- SoundUpdateSystem is a system that updates sounds, their position and orientation.
- UpdateSystem - a system that causes custom custom updates.
- StaticOcClusionSystem - Static occlusion system.
- StaticOcClusionBuildsystem - Static occlusion construction system.
- SpeedTreeUpdateSystem - Speed \u200b\u200bTree trees update system.
- Windsystem - Wind calculation system.
- WaveSystem is the system of calculating the oscillations from the charges.
- FolliageSystem is a system for calculating vegetation over the landscape.
In almost any system, the code looks like this:
For (a certain set of objects) (// Get necessary components // Perform actions on these objects // Write data into components)
Systems can be classified as they handle objects:
- Requires the processing of all objects that are in the system:
- Physics
- Collisia
- Requires only marked objects:
- Transformation system
- ACTIONS system (actions)
- Sound processing system
- Particle processing system
- Work with its specially optimized data structure:
- Static Occlusion System
Outcome
- We greatly raised the FPS, since with the component approach, things have become more independent and we were able to unleash them separately and optimize.
- Architecture has become simpler and understandable.
- It became easy to expand the engine, almost without breaking the neighboring systems.
- It became less than bugs from the series "Having done something with logs, broke switches", and vice versa
- There was an opportunity to all parallel into several nuclei.
- Currently, we are already working on all systems to run on all available kernels.