Contacte
principalul / Performanță

Care motor este realizat de lumea tancurilor. Testați un nou motor. Motorul de jocuri noi

Este timpul să cumpărați noi carduri video sau să anunțați noul motor WOT.

WG Fest a anunțat ieșirea din rezervoare complet noi. De fapt, este deja un joc complet diferit, ca noul motor, sunete, carduri HD. În ciuda îmbunătățirilor vizuale, dezvoltatorii promite că performanța nu se încadrează. Dacă jucați acum cu 30 fps, atunci noul motor va fi același.

În timp ce o singură remorcă este disponibilă:

Ce este cunoscut în acest moment?

  • Actualizarea va fi lansată în martie 2018.

  • Noul motor numit Miez. (Motor curentă Wot) Neegen merge în trecut.
    • Din motoarele existente, nimeni nu ar putea satisface dezvoltatorii, așa că sa decis să facă totul de la zero.
    • Despre Dezvoltare a durat 4 ani: 3 ani pe motorul în sine și un alt an pentru a crea conținut (carduri).
  • Pentru a estima performanța, puteți descărca deja un software special, care va cheltui un test, pe baza rezultatelor căruia puteți evalua cât de potrivit pentru PC-ul dvs. este potrivit pentru un nou joc.
    • encore poate fi lansată în trei moduri Grafice: minim, mediu și ultra.
    • Testul merge la trei minute, arată reluarea etapei cu demonstrarea noilor capabilități și efecte grafice.


Encore lumea Rezultatul testului rezervoarelor.

  • Carduri HD - Toate locațiile sunt reluate sub claritate ridicată. Și acest lucru se aplică tuturor aspectelor: peisaj, texturi, iluminat, sunete, efecte, mediu etc.


Lista completă convertită în carduri HD.

  • Soundtrack complet rescris. Fiecare carte va avea acum muzica proprie care transmite atmosfera unică a locației.
  • Ei promite că munca la optimizare se face o pierdere bună și puternică de FPS nu ar trebui să fie.
  • Gen orientare: 3D mmo de orice gen;
  • Platformă: PC, PS3, Xbox 360, iOS (iPad), Web;
  • Limbaj de programare: C ++, Python;
  • Licență: Indie și comercială;
  • Codul sursă open: Nu sunt furnizate sau furnizate pentru o plată sporită;
  • Multiplayer: client server;
  • Avantaje: Puternic, sprijin pentru toate cele mai moderne tehnologii, optimizate, iOS Support, ieftine pentru astfel de oportunități;
  • Dezavantaje: nu este furnizat gratuit;
  • Dezvoltatorii motorului: BigWorld Tech, Inc.

    Motorul BigWorld este cel mai avansat motor 3D pentru a crea jocuri MMO. Pe aceasta sunt făcute astfel de jocuri ca "World of Tanks", "PEALMUL TITANII" DE LA WARGAMING.NET și alte jocuri ale altor dezvoltatori de jocuri din clasa mondială. Există mai mult de 15 jocuri MMO pe acest motor. El este dezvoltat de tehnologia BigWorld.

    Optimizarea motorului vă permite să creați jocuri cu consum redus cu grafică uimitoare. Motorul vă permite să jucați jocuri pe iOS. Scrisă în limba de programare C ++, implementarea logicii jocului este efectuată pe un script convenabil Python. Există instrumente puternice și un motor de server client. Pentru sunet, biblioteca FMOD este acceptată și orice alte biblioteci sunt conectate printr-un sistem plug-in. Funcționează cu baze XML și MySQL. Setul de instrumente are un editor mondial puternic, editor de model și editor de particule.

    Este foarte accesibil în preț. Build BigWorld: Ediția indie costă doar 299 USD; BigWorld: ediția sursă indie - $ 2.9999; BigWorld: Ediția comercială - negociată individual.

    Acest motor avansat nu este inferior în posibilitățile altor motoare mondiale de tipul lor. Motorul este disponibil în limba rusă, coreeană, americană și japoneză. Există documentație, poate funcționa pe browsere. În general, puteți continua să lucrați dacă există cunoștințe și diligență.

    Deja nu sunt disponibile pentru licențierea terță parte, pentru că Wargaming a decis să abandoneze răspândirea motorului său.

    Site-ul oficial: http://www.bigworldtech.com.





    Lanțul BigWorld Technology Tool oferă un sistem complet de creare a conținutului MMOG, care va spori calitatea și actualitatea jocului dvs. Toate instrumentele sunt proiectate pentru producția de cooperare a bunurilor de joc într-un mediu mare de echipă, asigurând o utilizare eficientă a resurselor și o conductă de conținut netedă.

    • Începând cu data de 2 octombrie până la 8 octombrie, reprezentanții comunităților și bloggerilor din diferite regiuni au fost în centrul de dezvoltare Minsk. Portalul polonez Dom1N publică o expunere mai mare pe care Matchyhk (contribuabilul comunității din Asia). În răspunsurile pot exista inexactități minore, pentru originalul a fost tradus de 2 ori: engleză - poloneză - rusă.

    Alexey (Inaki) Ilin a fost responsabil pentru întrebări - producătorul global al proiectului World of Tanks, precum și alți dezvoltatori. O selecție imensă și detaliată. Partea 2.

    Capitolul 4. Economia și mecanica jocului:

    * Unii jucători nu-i plac cu adevărat "camuflajul clovnului" (de exemplu, patriot sau liberte). Care este opinia dezvoltatorilor despre asta?
    - Aceasta este o întrebare foarte bună! Lucrăm la sistem nou Personalizarea unde jucătorii își vor putea personaliza în detaliu mașinile.
    Vrem să facem acest sistem foarte bun, astfel încât să nu vă putem numi imediat momentul de ieșire și nu suntem într-o grămadă de a intra. Dar, cu ajutorul său, vom putea da jucătorilor o mulțime de texturi și personalizare a rezervoarelor.

    // Interesanta poveste:
    Când am intrat în Skorpion G, am creat de fapt 3 modele vizuale. A existat un Skorpion obișnuit (în gri german) și Skorpion, pe care toți știm cu toții. Cea de-a treia a avut o textura foarte unistrial / ireal și a fost considerată nepotrivită pentru joc.
    * Ce sa întâmplat cu Anul Nou cu sertare? Wargaming crede asupra sistemului de cutii cu piei ca în CS: Go sau Overwatch?
    * Pot introduce ceva similar cu sistemul de containere din lumea de război?
    - Ne place ideea. Dar spre deosebire de wot, wows un nou joc. Containerele au fost introduse atunci când reforma economiei a avut loc în joc. Pentru noi, este mai dificil, deoarece este necesar să luăm în considerare WOT-ul trecut. Este dificil să introduceți nimic care face schimbări în economia în joc. Dacă intrăm așa ceva, trebuie să o planificăm foarte atent. Acest lucru poate implica impresii negative ale jucătorilor dacă reducem profiturile lor pentru a compensa inovația și ei vor presupune că câștigă mai puține împrumuturi.
    * Va exista mai multă variabilitate în întâmplare? De exemplu, bătăliile sau vremea de noapte?
    - Dacă introducem bătălii de noapte sau vreme, atunci trebuie să decidem dacă aceste schimbări vor fi doar cosmetice sau, de asemenea, afectează gameplay-ul, de exemplu. Reduceți intervalul de vizualizare pe timp de noapte sau în timpul unei furtuni de nisip.
    * Credeți că "interzice" xvm?
    - Știm că MOD XVM implică indignarea în joc, în plus față de concentrarea pe XVM. Dar nu putem renunța doar la XVM din joc. XVM oferă, de asemenea, multe alte funcții, în plus față de afișarea statisticilor. Lucrăm îndeaproape cu dezvoltatorii XVM. Unii jucători folosesc XVM Planificarea unei strategii de luptă (de exemplu, jucătorii Purple Allied Allied sau focalizați focul asupra inamicului - din păcate).
    Acum 2 ani am colectat statistici pe XVM și am realizat că mai mult de 50% dintre oameni utilizează XVM fără funcția de statistici. Prin urmare, lucrăm la introducerea acestor funcții în clientul de joc, făcând astfel XVM inutil. Recent, am introdus propriul nostru sistem de rating, pentru că Credem că putem face un sistem mai precis de măsurare. Acest lucru va oferi jucătorilor un sistem mai precis de evaluare și comparație.
    În același timp, compania a efectuat un studiu prin posibilitatea de a interzice serviciile externe să primească date din API de război. Acest lucru duce la probleme cu analiza datelor pentru multe servicii importante. Lucrăm la asta.
    * Pot să ascund jucătorii în luptă?
    - Din păcate, nu credem că aceasta este o idee bună. Unii pot calcula că se joacă împotriva roboților. De asemenea, este dificil pentru relațiile sociale din joc. Este imposibil să știți dacă jucătorul este în clan și ar fi dificil pentru clanurile să caute noi jucători.
    * Cum sunt lucrurile cu "Bătălia generală"?
    - Bătălia generală - cu succes și jucători precum și cardul este bine echilibrat din punctul de vedere al statisticilor. Dar în Asia și America, din cauza lipsei unui număr mare de jucători pe 10 LVL și lansarea paralelă a bătălilor de rang, se colectează o cantitate foarte mică de GS. Suntem regulile și personalizați în acest moment.
    * Annicii de artilerie, veți elimina sau remake-o încă?
    - Nu vom elimina artileria. Această clasă este pentru persoanele care iubesc să prezică comportamentul altor jucători. Există o proporție de oameni care doresc cu adevărat această clasă, iar unii oameni joacă doar artilerie. Acum poți supraviețui sub foc mai mult și să nu mori de la Vanzota.

    Capitolul 5. Motorul de jocuri:

    * Va fi eliminat limita de curent a motorului de jocuri în 127 FPS cu introducerea cardurilor HD?
    - Știm despre utilizarea tot mai mare a monitoarelor de înaltă calitate (144 și 165 Hz). Restricționarea a 127 FPS nu este din cauza clientului în sine, dar din cauza vechii părți a serverului BigWorld. După cum am vorbit deja, partea clientului a fost practic rescrisă din nou. În mod similar, componenta serverului este acum rescrisă, iar limita FPS nu va fi necesară. Credem că eliminați sau înlocuiți-o, este testată, dar nu poate fi adăugată în nisip.
    Ieri totul a ieșit fără bloc.

    * Pistoale de blocare / comportament ciudat al camerei (de exemplu, când mergeți dintr-un mod de lunetist la normal sau dimpotrivă dacă aveți obstacole), este foarte enervant nu numai pe carduri HD, ci și pe un server comun. Va fi rezolvată?
    - Știm despre această problemă. Din păcate, nu avem soluții explicite în acest moment. Cu toate acestea, din momentul introducerii hărții promsirii, am corectat logica comportamentului camerei. Acest lucru a îmbunătățit situația, dar nu perfectă. Comportamentul camerei în Wot este mult mai dificil decât un shooter convențional (în Wot este necesar să se țină seama de mulți factori, de exemplu, viteza de rotație a turnului și a cazului.) Nu soluție simplă Această problemă, dar cu tehnologii noi sperăm să rezolvăm această problemă.

    Capitolul 6. Diverse:

    Unii jucători au sugerat introducerea parametrilor digitali în setările de sensibilitate. A fost luată în considerare și va fi luată în considerare mai târziu. Dar, potrivit statisticilor, foarte puțini jucători schimbă setările de control.
    - Soarta lui Chieftain Mk. 6 - Din păcate, este puțin probabil să fie introdus în joc. Ca și cum nu am vrut să o prezentăm, nu am dori să explorați cu Conqueror. Dacă găsim candidați potriviți pentru niveluri mai mici, cu un joc similar, ne vom gândi să intrați în chieftain în joc.
    * WG se gândește la introducerea sucursalei românești?
    - Din păcate, nu credem că România are suficiente tancuri pentru a-și întîlui ramura proprie.

    * Când va tancurile poloneze?
    - Încă lucrați la filiala poloneză, dar am găsit deja toate mașinile pentru ea. Prin urmare, vom încerca să introducem aceste tancuri cât mai repede posibil. Dar este prea devreme pentru a annon anumite date!

    * Unde este sârb (sârb)? Ce face el? Lucrează la proiectul său de bază lunară?)
    - Sârbul funcționează cu noi. Nu funcționează pe proiectul bazei lunare. Acum lucrează la alte proiecte Vargeiming.

    Această poveste a început cu mai mult de trei ani în urmă. Compania noastră mică Dava a devenit parte a războinicului și am început să ne gândim la ce proiecte fac următorul. Pentru a reaminti ceea ce a fost Mobail cu trei ani în urmă, voi spune că atunci nu a existat nici o ciocnire a clanurilor, nici puzzle și dragoni, nici multe proiecte foarte bine cunoscute. Mid-miez apoi a început. Piața a fost de mai multe ori mai mică decât azi.

    Inițial, părea că ar fi o idee foarte bună de a face mai multe jocuri mici care ar atrage noi utilizatori în "tancuri" mari. După o serie de experimente sa dovedit că nu funcționează. În ciuda conversiei excelente în aplicatii mobile, transfer de la telefon mobil PC sa dovedit a fi o precipiozitate pentru utilizatori.

    Apoi, în dezvoltare am avut mai multe jocuri. Unul dintre ei purta numele de funcționare "lunetist". Ideea principală de gameplay a fost fotografia în modul Sniper dintr-un rezervor în picioare în apărare, în conformitate cu alte tancuri pe care AI a gestionat și care ar putea ataca ca răspuns.

    La un moment dat ne-a părut că rezervorul în picioare era foarte plictisitor, iar într-o săptămână am făcut un prototip multiplayer, unde rezervoarele ar putea călări deja și ataca reciproc.

    Din moment ce totul a început!

    Când am început dezvoltarea unui "lunetist", am considerat tehnologii care au fost disponibile apoi platforme mobile. În acel moment, unitatea era încă în stadiul destul de timpuriu al dezvoltării sale: de fapt, nu au fost necesare tehnologii necesare pentru noi.

    Principalul lucru pe care l-am lipsit a fost un peisaj de redarea cu detalii dinamice, care este vital pentru a crea un joc cu spații deschise. Au existat mai multe biblioteci terțe pentru unitate, dar calitatea lor a lăsat mult de dorit.

    Am înțeles, de asemenea, că pe C # nu vom putea stoarce maximul dispozitivelor, pe care le dezvoltăm și întotdeauna să fie limitat.
    Motorul ireal 3 nu se potrivește, de asemenea, pe o serie de cauze similare.

    Ca rezultat, am decis să ne perfecționăm motorul!

    El a fost deja folosit la acel moment în proiectele noastre ocazionale anterioare. Motorul a avut un nivel destul de bine scris de lucru cu platforme și IOS acceptate, PC, Mac, plus lucrul pe Android a început. O mulțime de funcționalitate a fost scrisă pentru a crea jocuri 2D. Asta este, a existat un UI bun și multe lucruri de lucru cu 2D. A avut primii pași în partea 3D, deoarece unul dintre jocurile noastre a fost complet tridimensional.

    Ceea ce am avut în partea 3D a motorului:

    • Cea mai simplă scenă grafică.
    • Abilitatea de a desena ochiuri statice.
    • Abilitatea de a desena ochiuri animate cu animație scheletică.
    • Exportați obiecte și animații din formatul Colladei.
    În general, dacă vorbim despre funcționalitatea unui motor modern serios, a fost foarte mic.

    Începutul muncii

    Totul a început cu dovada capacității de a atrage peisajul dispozitive mobile: Apoi a fost iPhone 4 și iPad 1.

    După câteva zile de lucru, am primit un peisaj dinamic complet funcțional, care a funcționat destul de bine, a cerut o parte din memoria 8MB și a dat 60 de picioare pe aceste dispozitive. După aceea, am început o dezvoltare de jocuri complete.

    Aproximativ șase luni au trecut, iar micul mini-proiect sa transformat în ce blitz este acum. Au existat cerințe complet noi: MMO, calitate AAA și alte cerințe pe care motorul din forma sa originală nu mai poate furniza. Dar lucrarea se fierbe în plină desfășurare. Jocul a lucrat și a funcționat bine. Cu toate acestea, performanța a fost medie, obiectele de pe hărți au fost puțin, și, de fapt, au existat multe alte restricții.

    În acest stadiu, am început să înțelegem că fundația pe care am pus-o în motor nu va rezista la presa proiectului real.

    Cum totul a funcționat la acel moment
    Toate desenul scenei sa bazat pe un simplu concept de grafic de scenă.

    Conceptul principal a fost două clase:

    • Scena - container de scenă, în interiorul cărora au avut loc toate acțiunile
    • deasupra scenei.
    • SceneNode - clasa de bază a nodului scenei, din care au fost moștenite toate clasele, care erau în scenă:
    • MeshinstanceNode - clasă pentru a desena o plasă.
    • Lodnode - clasa pentru comutarea bărcilor.
    • Switchnod - clasa pentru a comuta obiectele comutatorului.
    • aproximativ 15 clase de moștenitori de scenă.
    Clasa SceneNode a permis să suprascrie un set metode virtuale, Pentru a implementa unele funcționalități personalizate:
    Funcțiile principale care ar putea fi suprascriere sunt:
    • Actualizare - O funcție care a fost apelată pentru fiecare nod pentru a face scene de actualizare.
    • Desenați - o funcție care a fost apelată pentru fiecare nod pentru a desena acest nod.
    Principalele probleme pe care le-am întâlnit.

    În primul rând, performanță:

    • Când numărul de noduri a ajuns la 5000, sa dovedit că trece pur și simplu prin toate funcțiile de actualizare goale, durează aproximativ 3ms.
    • Timpul similar a mers la nodurile goale care nu au avut nevoie de remiză.
    • O cantitate imensă de cache miss, deoarece lucrarea a fost făcută întotdeauna cu moduri diferite.
    • Incapacitatea față de parallery lucrează în mai multe nuclee.
    În al doilea rând, imprevizibilitatea:
    • Schimbarea codului în clasele de bază a influențat întregul sistem al întregului sistem, adică fiecare schimbare a sceneNode :: actualizare ar putea sparge orice și oriunde. Dependențele au devenit mai complicate și mai complicate, iar fiecare schimbare a motorului din interiorul motorului este aproape garantată pentru a testa întreaga funcționalitate asociată.
    • Era imposibil să se facă o schimbare locală, de exemplu, în transformare, pentru a nu răni restul scenei. Foarte adesea cele mai mici schimbări în LodNode (nod pentru comutarea shodes), a rupt ceva în joc.

    Primii pași pentru a îmbunătăți situația

    Pentru a începe, am decis să tratăm problemele cu productivitatea și să o facem repede.

    De fapt, am făcut-o introducând pavilionul suplimentar de nevoie_update în fiecare nod. A determinat dacă un astfel de nod este necesar pentru a apela actualizarea. A crescut cu adevărat productivitatea, dar a creat o întreagă memorie a problemelor. De fapt, codul funcției de actualizare a arătat astfel:

    VOID SCELENODE :: Actualizare (dacă (Flags & Need_update)) Returnați; // restul actualizarea. Funcție // Copii de proces)
    Ne-a revenit la parte din spectacol, dar multe probleme logice au început acolo unde nu așteptau.

    Lodnode și anghinode - noduri care răspund, respectiv, pentru comutarea lojilor (pe distanță) și obiecte de comutare (de exemplu, distruse și nedistructive) - au început să se spargă în mod regulat.

    Periodic, cel care a încercat să corecteze defalcările a făcut următoarele: Dezactivați Need_Update în clasa de bază (la urma urmei, a fost o soluție simplă) și FPS complet neobservate din nou.

    Atunci când codul care verifică pavilionul Need_update a fost comentat de trei ori, am decis schimbarea radicală. Am înțeles că nu am putut face totul imediat, așa că am decis să acționăm în etape.

    Primul pas a fost acela de a pune o arhitectură care ne va permite să rezolvăm toate problemele care apar de la noi.

    Poartă
    • Să minimalizeze dependența dintre subsistemele independente.
    • Schimbările în transformări nu ar trebui să rupă sistemul de bușteni și viceversa
    • Abilitatea de a pune codul pentru multi-core.
    • Astfel încât să nu existe funcții de actualizare sau similare, în care a fost efectuată un cod independent eterogen. Extinderea ușoară a sistemului cu o nouă funcționalitate fără adezivitate completă a celor vechi. Modificările în unele subsisteme nu afectează pe alții. Subsisteme maxime de independență.
    • Abilitatea de a organiza date linear în memorie pentru performanțe maxime.
    Scopul principal din prima etapă a fost ales prin modificarea arhitecturii, astfel încât toate aceste obiective să poată fi efectuate.

    Combinarea componentei și a abordării bazate pe date

    Soluția la această problemă a fost o abordare componentă combinată cu o abordare bazată pe date. Mai mult, în text, voi folosi o abordare bazată pe date, deoarece nu am găsit o traducere reușită.

    În general, înțelegerea abordării componentelor în multe persoane este cea mai diferită. Același lucru - și cu datele conduse de date.

    În înțelegerea mea, abordarea componentelor - Aceasta este atunci când unele funcționalități necesare se bazează pe componente independente. Cel mai simplu exemplu este electronica. Există chips-uri, fiecare cip are intrări și ieșiri. Dacă jetoanele vin unul la celălalt, ele pot fi conectate. Pe baza acestei abordări, întreaga industrie electronică a fost construită. Există mii de oameni componente diferite: Conectarea lor unul cu celălalt, puteți obține lucruri complet diferite.

    Principalele avantaje ale acestei abordări sunt că fiecare componentă este izolată și mai independentă. Nu iau în considerare faptul că componenta poate utiliza date incorecte, iar taxa arde. Avantajele acestei abordări sunt evidente. Astăzi puteți lua un număr foarte mare de chips-uri gata și puteți colecta un dispozitiv nou.

    Ce este datele bazate pe date.. În înțelegerea mea, aceasta este o abordare a designului software.Când programul este luat ca bază a programului și nu logica.

    În exemplul nostru, imaginați următoarea ierarhie a claselor:

    Clasa SCENELODE (// Datele responsabile pentru transformările ierarhice Matrix4 Localtransform, Matrix4 WorldTransform, Virtual Vild Actualizare (); Virtual Void Draw (); Vector Copii; . ); / / Dracizarea numai a jurnalului activ actual); Clasa meshnod (RendMeSh * mesh; tragere virtuală vid (); // trage mese);
    Codul de ocolire a acestei ierarhici pare ierarhic ca acesta:

    Loopul principal: RootNode-\u003e Actualizare (); rootnode-\u003e tragere ();
    În această ierarhie C ++ moștenire, avem trei fluxuri diferite de date independente:

    • Transformare
    Nodurile le combină numai în ierarhie, dar este important să înțelegem că prelucrarea fiecărui flux de date este mai bine să se producă. Nevoia practică de prelucrare a ierarhiei este necesară numai transformărilor.

    Să ne imaginăm cum ar trebui să arate într-o abordare bazată pe date. Voi scrie pe pseudocod pentru a fi clar ideea:

    // Transformare Loop de date: pentru (fiecare localitate locală în localtransformarray) (Worldtransform \u003d părinte-\u003e Worldtransform * Localtransform;) // LOD DATA LOOP: Pentru (fiecare Lod în Lodarray) (// Calculați distanța LoD și găsirea celui mai apropiat Lod LodreRenderObject \u003d GetneareStrenderObject (Lod); RenderBojedex \u003d getloDobjectRenderObjectIndEx (Lod); RenderOBJECTARAY \u003d RenderOfject;) // Mesh Render Loop de date: pentru (RenderMesh (RenderObject);)
    De fapt, am desfășurat ciclurile programului, făcându-l în așa fel încât totul să fie respins din date.

    Datele din abordarea bazată pe date reprezintă un element-cheie al programului. Logică - numai mecanisme de procesare a datelor.

    Noua arhitectură

    La un moment dat, a devenit clar că trebuie să mergem la abordarea entităților la organizarea scenei, unde entitatea a fost o esență formată din multe componente independente. Am vrut ca componentele să fie complet arbitrare și ușor combinate unul cu celălalt.

    Citirea informațiilor pe acest subiect, am venit peste blogul T-Machine.

    Mi-a dat multe răspunsuri, întrebările mele, dar răspunsul principal a fost următorul:

    Entitatea nu conține nicio logică, este doar ID (sau pointer).
    Entitatea știe numai componentele ID care aparțin acestuia (sau pointerului).
    Componenta este doar date, adică. Componenta nu conține nicio logică.
    Sistemul este un cod care poate procesa un set specific specific și extrudat un alt set de date la ieșire.

    Dacă vă dezvoltați pe Java, vă recomandăm cu adevărat să vă uitați la ea. Cadrul foarte simplu și conceptual corect. Până în prezent, el este în viață într-o grămadă de limbi.

    Ce este ARTEMIS, astăzi se numește ECS (Sistemul de componente ale entității). Opțiunile pentru organizarea unei scene bazate pe entitate, componente și date sunt destul de mult, cu toate acestea, am venit la arhitectura ECS. Este dificil de spus cât de comun este termenul general acceptat, cu toate acestea, EC înseamnă că există următoarele entități: entitate, componentă, sistem.

    Cea mai importantă diferență față de alte abordări este: Lipsa obligatorie a comportamentului logic în componente și separarea codului în sistem.

    Acest articol este foarte important în abordarea componentă "ortodoxă". Dacă spargeți primul principiu, vor apărea o mulțime de ispite. Unul dintre primii care fac moștenirea componentelor.

    În ciuda flexibilității, se termină, de obicei, cu pastele.

    Inițial, se pare că, cu această abordare, puteți face o mulțime de componente care se comportă într-un mod similar, dar un pic diferit. Interfețe generale ale componentelor. În general, puteți cădea din nou în capcana moștenirii. Da, va fi puțin mai bună decât moștenirea clasică, dar încercați să nu intrați în această capcană.

    ECS este o abordare mai curată și decide mai multe probleme.

    Pentru a vedea exemplul, cum funcționează în Artemis, puteți arăta.

    Vă voi arăta despre exemplul cum funcționează pentru noi.

    Containerul principal de clasă este entitatea. Aceasta este o clasă care conține o gamă de componente.

    Clasa a doua este componenta. În cazul nostru, este doar date.

    Aici este lista de componente utilizate în motorul nostru, astăzi:

    Enum etype (transformare_component \u003d 0, rand_component, Lod_Component, Debug_Render_Component, Switch_Component, Light_Component, Particle_Component_Component, Bullet_Component, ANIMATION_Component, Colizion_Component, // Mai multe cazuri, Action_Component, // Acțiuni, ceva mai simplificator decât scripturile care pot influența logica, pot fi mai multiple Script_Component, // mai multe cazuri, nu acum, se va întâmpla mult mai târziu. Utilizator_component, Sound_Component, personalizant_proprient_component, static_occlusion_data_component, calitate_settings_component, // Tipul ca FastNaNe pentru detectarea modelului SpeedTree_Component, Wind_Component, Wave_Component, Skeleton_Component, / / Componente de depanare - Rețineți că totul mai jos nu a câștigat serializat Debug_Components, static_oclusion_debug_draw_component, component_count);
    Clasa amenințătoare este scenesystem:

    / ** \\ Scurt Această funcție se numește atunci când orice entitate sa înregistrat la scenă. Sortează faptul că entitatea are nevoie să-i apeleze la adventitate. \\ Param entitate entitate Am adăugat doar * / Virtual Vold Regisertity (entitate * entitate); / ** \\ scurte Această funcție este numită atunci când orice entitate neînregistrată din scenă. Sortează Entitatea are toate componentele necesare și trebuie să sunăm Eliminare. \\ Entitate entitate param "am eliminat doar * / entitate virtuală *;
    Funcțiile de înregistrare, neregistrarea sunt solicitate pentru toate sistemele din scenă atunci când adăugăm sau ștergem entitatea de la scenă.

    / ** \\ Scurt Această funcție este numită atunci când orice componentă este înregistrată la scenă. Sortează faptul că entitatea are nevoie să-i apeleze la adventitate. \\ Param entitate entitate am adăugat componenta la. \\ Componenta componentă PARAM Am adăugat la entitate. * / Virtual Vulity, Component * Component); / ** \\ Scurtă Această funcție este numită atunci când orice componentă nu este înregistrată din scenă. Sortează faptul că entitatea are toate componentele necesare și noi Necesitatea de a numi eliminare * / VIDUL VIRTUAL UnregisterComponent (entitate * entitate, componentă * componentă);
    Registrul Component, UnregisterComponent sunt chemați pentru toate sistemele din scenă, când adăugăm sau ștergem componenta în entitate în scenă.
    De asemenea, pentru comoditate există încă două funcții:

    / ** \\ Scurt Această funcție se numește numai când entitatea are toate componentele necesare. \\ Param entitate entitate Vrem să adăugăm. * / Aderenta vidului virtual (entitate * entitate); .
    Aceste funcții sunt numite atunci când setul comandat de componente a fost deja creat utilizând caracteristica SetRequiredComponens.

    De exemplu, putem ordona obținerea numai a acelor entități care au Action_Component și Sound_Component. Îl transferați la SetRequiredComponents și - Voila.

    Pentru a înțelege cum funcționează, voi scrie pe exemple, ce sisteme avem:

    • Transformistem - un sistem care este responsabil pentru ierarhia transformărilor.
    • Switchsystem este un sistem care este responsabil pentru comutarea obiectelor care pot fi în mai multe state, cum ar fi distruse și neobișnuite.
    • LodSystem este un sistem care este responsabil pentru comutarea lodelor în depărtare.
    • ParticuleffectSystem este un sistem care actualizează efectele particulelor.
    • Renderupdatesystem - un sistem care actualizează obiectele de la numărul scenei.
    • Lightupdatesystem este un sistem care actualizează sursele de lumină din numărul scenei.
    • ActionUpdatesystem este un sistem care actualizează acțiunile (acțiunile).
    • SoundUpdatesystem este un sistem care actualizează sunetele, poziția și orientarea lor.
    • Actualizări sistem - un sistem care cauzează actualizări personalizate personalizate.
    • STATICOCCLISIONSYSTEM - Sistem static de ocluzie.
    • StaticocclusionbuildSystem - sistem de construcție statică de ocluzie.
    • SpeedtreeUpdatesystem - Sistem de actualizare a copacilor de viteză.
    • WindSystem - Sistemul de calcul eolian.
    • Wavesystem este sistemul de calcul al oscilațiilor din taxe.
    • Folliagesystem este un sistem de calcul al vegetației peisajului.
    Cel mai important rezultat pe care am realizat-l este o descompunere mare a codului care este responsabil pentru lucrurile eterogene. Acum, în funcția de procesare :: procesul de proces, întregul cod este clar localizat, care se referă la transformări. Este foarte simplu. Este ușor să se descompună pe mai multe nuclee. Și, cel mai important, este dificil să spargeți ceva într-un alt sistem, făcând o schimbare logică în sistemul de transformare.

    În aproape orice sistem, codul arată astfel:

    Pentru (un anumit set de obiecte) (// primiți componentele necesare // Efectuați acțiuni pe aceste obiecte // Scrieți date în componente)
    Sistemele pot fi clasificate pe măsură ce se ocupă de obiecte:

    • Necesită prelucrarea tuturor obiectelor care sunt în sistem:
      • Fizică
      • Collizia.
    • Necesită doar obiecte marcate numai:
      • Sistem de transformare
      • Sistem de acțiuni (acțiuni)
      • Sistem de procesare a sunetului
      • Sistem de procesare a particulelor
    • Lucrați cu structura sa de date optimizată special:
      • Sistemul de ocluzie statică
    Cu această abordare, în plus, este foarte ușor să se ocupe de obiecte în mai multe nuclee, este foarte ușor să faci asta în paradigma obișnuită a polimorfismului pentru a face destul de dificilă. De exemplu, puteți lua și procesa cu ușurință, nu toate comutarea pe cadru. Dacă obiectele sunt foarte mari în mare lumea deschisăPuteți face acest lucru ca fiecare cadru să fie procesat, de exemplu, o treime din obiecte. În acest caz, acest lucru nu afectează alte sisteme.

    Rezultat

    • Am ridicat foarte mult FPS, deoarece cu abordarea componentelor, lucrurile au devenit mai independente și am reușit să le eliberăm separat și să optimizăm.
    • Arhitectura a devenit mai simplă și de înțeles.
    • A devenit ușor de extins motorul, aproape fără a sparge sistemele învecinate.
    • A devenit mai puțin decât bug-urile din seria ", după ce a făcut ceva cu bușteni, întrerupătoarele de rupt", și viceversa
    • A existat o oportunitate pentru toate paralele în mai multe nuclee.
    • În prezent, lucrăm deja la toate sistemele pentru a rula pe toate kernelurile disponibile.
    Codul motorului nostru este în Open Source. Motorul din forma în care este utilizat în lumea rezervoarelor Blitz,