Vilken motor är gjord av tankar. Testa en ny motor. Ny spelmotor
Det är dags att köpa nya videokort eller meddelar den nya WOT-motorn.
WG Fest meddelade utgången av helt nya tankar. Faktum är att det redan är ett helt annat spel, som den nya motorn, ljud, HD-kort. Trots visuella förbättringar lovar utvecklarna att prestanda inte faller. Om du spelar med 30 fps nu, kommer den nya motorn att vara densamma.
Medan endast en släpvagn är tillgänglig:
Vad är känt för tillfället?
- Uppdateringen kommer att släppas i mars 2018.
- Ny motor som heter Kärna. (Aktuell wot motor) neeGen går in i det förflutna.
- Från de befintliga motorerna kunde ingen tillfredsställa utvecklarna, så det bestämdes att göra allt från början.
- På utvecklingen tog 4 år: 3 år på själva motorn och ett annat år att skapa innehåll (kort).
- För att uppskatta prestanda kan du redan ladda ner en speciell programvaruuppkoppling, som kommer att tillbringa ett test, baserat på vilka resultat du kan utvärdera hur lämplig för din dator är lämplig för ett nytt spel.
- encore kan lanseras i tre lägen Grafer: Minsta, Medium och Ultra.
- Testet går tre minuter, visar scenens uppspelning med demonstrationen av nya grafiska kapaciteter och effekter.
Encore World of Tanks Test Resultat.
- HD-kort - Alla platser redovisas under hög klarhet. Och det gäller alla aspekter: landskap, texturer, belysning, ljud, effekter, miljö, etc.
Hela listan konverteras till HD-kort.
- Helt omskrivna soundtrack. Varje kort kommer nu att ha sin egen musik som överför den unika atmosfären av platsen.
- De lovar att arbetet med optimering görs bra och stark förlust av FPS bör inte vara.
BigWorld Engine är den mest avancerade 3D-motorn för att skapa MMO-spel. På det görs sådana spel som "Tanks värld", "Titans" Pealm "från Wargaming.net och andra spel av andra världsklass spelutvecklare. Det finns mer än 15 mmospel på den här motorn. Han utvecklas av BigWorld Technology.
Motoroptimering gör att du kan skapa lågkrävande spel med fantastisk grafik. Motorn gör att du kan hämta spel på iOS. Skriven i C ++ -programmeringsspråket, genomförandet av spellogiken i den utförs på ett bekvämt skript python. Det finns kraftfulla verktyg och en klient-servermotor. För ljud stöds FMOD-biblioteket, och alla andra bibliotek är anslutna via ett plug-in-system. Fungerar med XML och MySQL baser. Toolkit har kraftfullt världsredaktör, modellredigerare och partikelredigerare.
Det är mycket tillgängligt i pris. Bygg BigWorld: Indie Edition kostar bara $ 299; BigWorld: Indie Source Edition - $ 2.9999; BigWorld: Commercial Edition - förhandlat individuellt.
Den här avancerade motorn är inte sämre i möjligheterna till andra världsmotorer av deras typ. Motorn är tillgänglig på ryska, koreanska, amerikanska och japanska. Det finns dokumentation, kan fungera på webbläsare. I allmänhet kan du gå vidare till jobbet om det finns kunskap och flitighet.
Redan inte tillgänglig för tredjepartslicensiering, eftersom Wargaming bestämde sig för att överge spridningen av sin motor.
Officiell webbplats: http://www.bigworldtech.com.
BigWorld Technology Tool Chain ger ett komplett, end-to-end MMOG-innehållsskapande system som förbättrar kvaliteten och aktualiteten i ditt spel. Alla verktyg är utformade för kooperativ produktion av speltillgångar i en stor lagmiljö, vilket garanterar effektiv resursanvändning och en smidig innehållsledning.
Från 2 oktober till 8 oktober var företrädare för samhällen och bloggare från olika regioner i Minsk Development Center. Polish Dom1n Portal publicerar en större exponering som MatchyHK (Asian Community Bidragsgivare). I svaren kan det finnas mindre felaktigheter, för originalet omsattes 2 gånger: Engelska - Polska - Ryska.
Alexey (Inaki) ILIN ansvarade för frågor - den globala producenten av Tanks-projektet, liksom andra utvecklare. Stort och detaljerat urval. Del 2.
Kapitel 4. Ekonomi och spelmekanik:
* Vissa spelare gillar verkligen inte "clown camouflage" (till exempel. Patriot eller Liberte). Vad är utvecklingen av utvecklare om detta?
- Det här är en mycket bra fråga! Vi arbetar på nytt system Anpassning där spelare kommer att kunna anpassa sina bilar i detalj.
Vi vill göra det här systemet mycket bra, så att vi inte omedelbart kan ringa dig tidpunkten för utgången och vi är inte i en rush att komma in. Men med hjälp kan vi ge spelarna många texturer och anpassning av tankar.
// Intressant historia:
När vi kom in i Skorpion G, skapade vi faktiskt 3 visuella modeller. Det var en vanlig Skorpion (i tyska grå) och Skorpion, som vi alla vet. Den tredje hade en mycket unhistrict / orealistisk konsistens och ansågs vara olämplig för spelet.
* Vad hände med det nya året IVETH med lådor? Wargaming tänker över lådans system med skinn som i CS: Gå eller Overwatch?
* Kan jag skriva in något som liknar behållarsystemet i World of Warships?
- Vi gillar idén. Men till skillnad från wot, wows ett nytt spel. Behållare introducerades när ekonomins reform hölls i spelet. För oss är det svårare, eftersom det är nödvändigt att ta hänsyn till det förflutna wot. Det är svårt att introducera allt som gör förändringar i spelets ekonomi. Om vi \u200b\u200bgår in på något liknande, måste vi planera det mycket noggrant. Detta kan medföra negativa intryck av spelarna om vi minskar vinsterna för att kompensera för innovationen, och de kommer att anta att de tjänar mindre lån.
* Kommer det att finnas mer variation i slumpmässig? Till exempel, natt slag eller väder?
- Om vi \u200b\u200bintroducerar nattkämpar eller väder, måste vi bestämma om dessa ändringar endast kommer att kosmetiska eller påverka spelet, till exempel. Minska visningsområdet på natten eller under en sandig storm.
* Tror du "förbud" xvm?
- Vi vet att Mod XVM medför ilska i spelet, förutom att fokusera på XVM. Men vi kan inte bara dra ut xvm från spelet. XVM ger också många andra funktioner, förutom att visa statistik. Vi arbetar nära med XVM-utvecklare. Vissa spelare använder XVM-planering av en stridsstrategi (till exempel, rida allierade lila spelare, eller fokusera eld på fiende - tyvärr).
För 2 år sedan samlade vi statistik om XVM och insåg att mer än 50% av befolkningen använder XVM utan statistikens funktion. Därför arbetar vi med införandet av dessa funktioner i spelklienten, vilket gör XVM onödigt. Nyligen introducerade vi vårt eget betygssystem, för Vi tror att vi kan göra ett mer exakt mätsystem. Detta ger spelarna en mer exakt bedömning och jämförelse system.
Samtidigt genomförde företaget en studie med möjligheten att förbjuda utländska tjänster att få data från Wargaming API. Detta leder till problem med dataanalys för många viktiga tjänster. Vi jobbar på det.
* Kan jag gömma spelare i strid?
- Tyvärr tror vi inte att det här är en bra idé. Vissa kan beräkna att de spelar mot bots. Det gör det också svårt för sociala relationer i spelet. Det är omöjligt att veta om spelaren är i klanen, och det skulle vara svårt för klaner att leta efter nya spelare.
* Hur är det med "General Battle"?
- Allmän kamp - framgångsrikt och spelare som, och kortet är välbalanserat ur statistikens synvinkel. Men i Asien och Amerika, på grund av bristen på ett stort antal spelare på 10 lvl och den parallella lanseringen av rangstramar, samlas en mycket liten mängd GS. Vi är reglerna och anpassa just nu.
* Artilleri irriterar, du tar bort eller tar bort det än?
- Vi tar inte bort artilleri. Den här klassen är för personer som älskar att förutsäga andras beteende. Det finns en andel av människor som verkligen gillar den här klassen, och vissa människor spelar bara artilleri. Nu kan du överleva under eld mer, och inte dö från vanzota.
Kapitel 5. Gamingmotor:
* Kommer det att tas bort den aktuella gränsen för spelmotorn i 127 fps med introduktionen av HD-kort?
- Vi vet om den växande användningen av högkvalitativa bildskärmar (144 och 165 Hz). Begränsning av 127 fps är inte på grund av själva klienten, men på grund av den gamla serverns del av BigWorld. Som vi redan har talat har klientdelen praktiskt tagits om igen. På samma sätt skrivs serverns komponent nu, och FPS-gränsen behövs inte. Vi tänker ta bort eller byta ut det, det testas, men får inte läggas till i sandlådan.
Igår gick allt ut utan block.
* Låspistoler / konstigt kamerabeteende (t.ex. när du går från ett sniperläge till normalt eller tvärtom om du har några hinder) är mycket irriterande inte bara på HD-kort, men också på en gemensam server. Kommer det att fixas?
- Vi vet om detta problem. Tyvärr har vi inga uttryckliga lösningar för tillfället. Men från ögonblicket att komma in i PromSion-kartan, korrigerade vi logiken för kamerans beteende. Detta förbättrade situationen, men inte perfekt. Kamerans beteende i wot är mycket svårare än en konventionell skytt (i punkt är det nödvändigt att ta hänsyn till många faktorer, till exempel rotationshastigheten för tornet och fallet.) Nej enkel lösning Detta problem, men med ny teknik hoppas vi lösa detta problem.
Kapitel 6. Övrigt:
Vissa spelare föreslog att ange digitala parametrar i känslighetsinställningar. Det noterades och kommer att beaktas senare. Men enligt statistik ändrar mycket få spelare kontrollinställningar.
- Chieftain öde. 6 - Tyvärr är det osannolikt att det går in i spelet. Som om vi inte ville presentera det, skulle vi inte vilja att det skulle utforska med erövror. Om vi \u200b\u200bhittar lämpliga kandidater för lägre nivåer med en liknande gameplay, kommer vi att tänka på att komma in i hövdingen i spelet.
* WG tänker över införandet av den rumänska filialen?
- Tyvärr tror vi inte att Rumänien har tillräckligt med tankar för att utarbeta sin egen filial.
* När kommer polska tankar?
- Fortfarande arbetar på den polska filialen, men vi har redan hittat alla bilar för henne. Därför kommer vi att försöka introducera dessa tankar så fort som möjligt. Men det är för tidigt att Annon-specifika datum!
* Var är serb (serb)? Vad gör han? Arbetar han på sitt projekt av Lunar Base?)
- Serb arbetar med oss. Det fungerar inte på projektet av Lunar Base. Han arbetar nu med andra vargprojekt.
Ursprungligen verkade det för alla att det skulle finnas en mycket bra idé att göra flera små spel som skulle locka nya användare i stora "tankar". Efter ett antal experiment visade det sig att det inte fungerar. Trots utmärkt konvertering i mobila applikationer, överföra från mobiltelefon PC visade sig vara en nederbörd för användare.
Därefter hade vi flera spel. En av dem hade arbetsnamnet "Sniper". Den viktigaste spelidén skjuter i sniperläge från en tank som stod i försvar, enligt andra tankar som AI hanterade och som kunde attackera som svar.
Vid något tillfälle tycktes vi att den stående tanken var mycket tråkig, och i en vecka gjorde vi en multiplayer prototyp, där tankarna redan kunde åka och attackera varandra.
Sedan allt började!
När vi började utveckla en "sniper" ansåg vi tekniker som då var tillgängliga för mobila plattformar. Vid den tiden var enighet fortfarande på det ganska tidiga skedet av sin utveckling: Det fanns faktiskt ingen teknik för oss ännu.
Det viktigaste som vi saknade var ett landskapsavgivning med dynamisk detalj, vilket är viktigt för att skapa ett spel med öppna utrymmen. Det fanns flera tredjepartsbibliotek för enhet, men deras kvalitet lämnade mycket att önska.
Vi förstod också att vi inte kommer att kunna klämma på maximalt enheter, som vi utvecklar och alltid är begränsade.
Unreal motor 3 passade också inte på ett antal liknande orsaker.
Som ett resultat bestämde vi oss för att förfina vår motor!
Han användes redan vid den tiden i våra tidigare lediga projekt. Motorn hade en ganska välskriven låg arbetsnivå med plattformar och stödd IOS, PC, Mac, plus arbete på Android startades. Mycket funktionalitet har skrivits för att skapa 2D-spel. Det var, det var en bra UI och mycket av allt att arbeta med 2D. Det hade de första stegen i 3D-delen, som ett av våra spel var helt tredimensionell.
Vad vi hade i 3D-delen av motorn:
- Den enklaste grafsplatsen.
- Förmågan att dra statiska maskor.
- Möjligheten att rita animerat nät med skelettimering.
- Exportera objekt och animationer från Collada-formatet.
Början på jobbet
Allt började med beviset på förmågan att rita landskapet på mobil enheter: Då var det iPhone 4 och iPad 1.Efter flera dagar av arbetet fick vi ett helt funktionellt dynamiskt landskap, som fungerade ganska bra, krävde några av 8 MB minne och gav 60fps på dessa enheter. Därefter började vi en fullfjädrad spelutveckling.
Omkring sex månader passerade, och det lilla mini-projektet blev till vad Blitz nu är. Det fanns helt nya krav: MMO, AAA-kvalitet och andra krav som motorn i sin ursprungliga form vid den tiden inte längre kunde tillhandahålla. Men arbetet kokades i full gång. Spelet fungerade och fungerade bra. Föreställningen var dock medium, objekt på kartorna var lite, och det fanns faktiskt många andra restriktioner.
I detta skede började vi förstå att grunden vi lagt i motorn inte kommer att klara pressen av det verkliga projektet.
Hur allt fungerade vid den tiden
All scenritning baserades på ett enkelt koncept av scengraf.Huvudkonceptet var två klasser:
- Scen - scenbehållare, inuti vilka alla handlingar ägde rum
- ovanför scenen.
- SceneNode - den grundläggande klassen av scennoden, från vilken alla klasser är ärvt, som var i scenen:
- MeshinstanceNode - klass för att dra ett nät.
- Larnode - klass för byte av båtar.
- SwitchNode - klass för att byta omkopplingsobjekt.
- cirka 15 klasser av scenene arvingar.
De viktigaste funktionerna som kan överskridas är:
- Uppdatering - En funktion som krävdes för varje nod för att göra uppdateringscener.
- Rita - en funktion som kallades för varje nod för att dra denna nod.
Urpremiär:
- När antalet noder nådde 5000 visade det sig att det bara går igenom alla tomma uppdateringsfunktioner, tar ungefär 3 ms.
- Liknande tid gick till tomma noder som inte behövde rita.
- En stor mängd cache miss, eftersom arbetet alltid har gjorts med olika sätt.
- Oförmågan att parallery arbetar i flera kärnor.
- Ändra koden i de grundläggande klasserna påverkat hela systemet i hela systemet, det vill säga varje ändring av SceneNode :: Uppdatering kan bryta något och var som helst. Beroende blev mer komplicerade och mer komplicerade, och varje förändring i motorn i motorn är nästan garanterad för att testa hela tillhörande funktionalitet.
- Det var omöjligt att göra en lokal förändring, till exempel, i omvandling för att inte skada resten av scenen. Mycket ofta bröt de minsta förändringarna i Lodnode (knut för att byta skod), något i spelet.
Första steget för att förbättra situationen
Till att börja med bestämde vi oss för att behandla problem med produktivitet och göra det snabbt.Egentligen gjorde vi det genom att komma in i den extra behovet_update flaggan i varje nod. Det bestämde huruvida en sådan nod är nödvändig för att ringa upp uppdatering. Det ökade verkligen produktiviteten, men skapade ett helt minne om problemen. Faktum är att uppdateringsfunktionskoden såg ut så här:
Void sceneode :: uppdatering (om (flaggor och need_update)) returnera; // resten av uppdateringen. Funktion // Process Barn)
Det återvände till oss en del av prestationen, men många logiska problem började var de inte väntade.
Larnode och SwitchNode - noder som svarar, för att byta logerna (med avstånd) och omkopplingsobjekt (till exempel förstörda och icke-destruktiva) - började bryta regelbundet.
Periodiskt, den som försökte korrigera uppdelningarna gjorde följande: Inaktivera behov_Update i basklassen (trots allt var det en enkel lösning), och helt obemärkt FPS föll igen.
När koden kontrollerar NEARK_UPDATE-flaggan har kommenterats tre gånger, bestämde vi oss för radikala förändringar. Vi förstod att vi inte kunde göra allt på en gång, så vi bestämde oss för att agera i etapper.
Det allra första steget var att lägga en arkitektur som gör det möjligt för oss att lösa alla problem som uppstår från oss.
Mål
- Minimera beroendet mellan oberoende delsystem.
- Förändringar i transformationer bör inte bryta systemet med loggar och vice versa
- Förmågan att sätta koden för multikärnan.
- Så att det inte finns några uppdateringsfunktioner eller liknande, där heterogen oberoende kod utfördes. Enkel expansion av systemet med en ny funktionalitet utan fullständig vidhäftning av den gamla. Förändringar i vissa delsystem påverkar inte andra. Maximal oberoende delsystem.
- Möjligheten att ordna data linjärt i minnet för maximal prestanda.
Kombinera komponent och datastyrd tillvägagångssätt
Lösningen på detta problem var ett komponentmetod kombinerat med ett datastyrt tillvägagångssätt. Vidare i texten kommer jag att använda ett datastyrt tillvägagångssätt, eftersom jag inte hittade en framgångsrik översättning.I allmänhet är förståelsen av komponentmetoden hos många människor den mest annorlunda. Samma - och med datadriven.
I min förståelse, komponentmetoden - Det här är när en viss funktionalitet är baserad på oberoende komponenter. Det enklaste exemplet är elektronik. Det finns chips, varje chip har ingångar och utgångar. Om chipsen kommer till varandra kan de anslutas. På grundval av detta tillvägagångssätt byggdes hela elektronikindustrin. Det finns tusentals olika komponenter: Anslut dem med varandra, du kan få helt olika saker.
De viktigaste fördelarna med detta tillvägagångssätt är att varje komponent är isolerad och mer oberoende. Jag tar inte hänsyn till det faktum att komponenten kan använda felaktiga data, och avgiften brinner. Fördelarna med detta tillvägagångssätt är uppenbara. Idag kan du ta ett stort antal färdiga chips och samla en ny enhet.
Vad är data driven.. I min förståelse är detta ett tillvägagångssätt för design programvaraNär programmet tas som grund för programmet, och inte logik.
I vårt exempel, föreställ dig följande hierarki av klasser:
Class SceneNode (// data ansvarig för hierarkiska omvandlingar Matrix4 LocalTransform; Matrix4 WorldTransform; Virtual Void Update (); Virtual Void Draw (); Vector
Koden för att kringgå denna hierarki hierarkiskt ser ut så här:
Huvudslinga: RootNode-\u003e Uppdatering (); RootNode-\u003e Rita ();
I detta hierarki C ++ arv har vi tre olika oberoende dataströmmar:
- Omvandling
Låt oss föreställa mig hur det ska se ut i ett datastyrt tillvägagångssätt. Jag ska skriva på pseudokoden för att vara tydlig idén:
// Transform Data Loop: För (varje LocalTransform i LocalTransFormarray) (WorldTransform \u003d Parent-\u003e WorldTransform * LocalTransform;) // LOD Data Loop: För (varje LOD i Lodarray) (// Beräkna Lod Avstånd och Hitta närmaste LODESTRETRENDEROBject \u003d getnearestrenderobject (LOD); RenderobjectIndex \u003d getLodobjectrenderobjectIndex (LOD); renderobjectarray \u003d renderobject;) // mesh gör datalopling: för (varje renderobject i renderobjectarmesh)
Faktum är att vi har utnyttjat programmets cykler, vilket gör det på ett sådant sätt att allt avvisas från data.
Data i det datastyrda tillvägagångssättet är ett nyckelelement i programmet. Logik - Endast databehandlingsmekanismer.
Ny arkitektur
Vid något tillfälle blev det klart att vi måste gå till det företagsbaserade tillvägagångssättet till scenens organisation, där enheten var en essens bestående av många oberoende komponenter. Jag ville att komponenterna var helt godtyckliga och lätt kombinerade med varandra.Läs information om detta ämne kom jag över T-Machine-bloggen.
Han gav mig många svar, mina frågor, men det viktigaste svaret var följande:
Enhet innehåller ingen logik, det är bara ID (eller pekare).
Entity vet bara de ID-komponenter som hör till det (eller pekaren).
Komponenten är bara data, det vill säga. Komponenten innehåller ingen logik.
Systemet är en kod som kan bearbeta en specifik dataset och extrudera en annan uppsättning data vid utgången.
Om du utvecklar på Java rekommenderar jag verkligen att titta på det. Mycket enkelt och konceptuellt korrekt ram. Hittills lever han på en massa språk.
Vad Artemis är idag kallas ECS (Entity Component System). Alternativ för att organisera en scen baserad på enhet, komponenter och datordrivna är dock ganska mycket, men vi kom till ECS-arkitekturen. Det är svårt att säga hur vanligt är den allmänt accepterade termen, men ECS innebär att det finns följande enheter: Enhet, komponent, system.
Den viktigaste skillnaden från andra tillvägagångssätt är: Obligatorisk brist på logiskt beteende i komponenter och separation av kod i systemet.
Denna vara är mycket viktigt i "ortodoxa" komponentmetoden. Om du bryter den första principen kommer många frestelser att visas. En av de första som gör arvets arv.
Trots flexibilitet slutar slutar vanligtvis med pasta.
Ursprungligen verkar det som om det med detta tillvägagångssätt kan göra många komponenter som beter sig på ett liknande sätt, men lite annorlunda. Allmänna komponenter gränssnitt. I allmänhet kan du återigen falla i arvets fälla. Ja, det blir lite bättre än klassiskt arv, men försök att inte komma in i denna fälla.
ECS är ett renare tillvägagångssätt och beslutar fler problem.
För att se exemplet, hur det fungerar i Artemis, kan du titta.
Jag ska visa dig på exemplet hur det fungerar för oss.
Huvudklassbehållaren är Entity. Det här är en klass som innehåller en rad komponenter.
Den andra klassen är komponent. I vårt fall är det bara data.
Här är listan över komponenter som används i vår motor, idag:
Enum Etype (Transform_Component \u003d 0, Render_Component, Lod_Component, Debug_Render_Component, byte_komponent, camera_component, light_component, partikel_effect_component, animation_component, collision_component, animation_component, collision_component, animation_component, collision_component, // Flera instanser Physics_Component, Action_Component, // Åtgärder, något Enkeltare än skript som kan påverka logik, Kan vara flera script_component, // flera instanser, inte nu, det kommer att hända mycket senare. användar_komponent, sund_component, custom_properties_component, static_cclusion_data_component, kvalitet_settings_component, // typ som fastnamn för detektering av typ av modell SpeedTree_Component, Wind_Component, Wave_Component, Skeleton_Component, / / Debug-komponenter - Observera att allt under vann "t, serialiserade debug_components, static_oclusion_debug_draw_component, component_count);
Threatest Class är scenesystem:
/ ** \\ kort Denna funktion kallas när någon enhet registrerad till scenen. Det sorterar är att enheten har alla behov av att ringa till addentity. \\ Param Entity Entity Vi har just lagt till * / Virtual Void Regisertity (Entity * Entity); / ** \\ Kort den här funktionen kallas när någon enhet oregistreras från scen. Det sorterar ut är Entity har alla nödvändiga komponenter och vi måste ringa REMOVEENTITY. \\ Param Entity Entity Vi har just tagit bort * / virtuell ogiltig oregistrity;
Registretitetsfunktioner, omregistrering krävs för alla system i scenen när vi lägger till eller tar bort enhet från scenen.
/ ** \\ kort Denna funktion kallas när någon komponent är registrerad på scenen. Det sorterar är att enheten har alla behov av att ringa till addentity. \\ Param Entity Entity Vi har lagt till komponent till. \\ Param Component Component Vi har just lagt till entitet. * / Virtuell tomhet, komponent * Komponent); / ** \\ Kort Den här funktionen kallas när någon komponent är oregistrerad från scen. Det sorterar ut är Enhet har alla nödvändiga komponenter och vi Behöver ringa vidarebefordran. \\ Param Entity Entity Vi tog bort komponent från. \\ Param Component Component Vi har precis tagit bort från enheten. * / Virtual Void UnregisterComponent (Entity * Entity, Component * Component);
RegisterComponent, oregistreringskomponent krävs för alla system i scenen, när vi lägger till eller tar bort komponent i enheten i scenen.
Också för bekvämlighet finns det ytterligare två funktioner:
/ ** \\ KORT Denna funktion kallas endast när enheten har alla nödvändiga komponenter. \\ Param Entity Entity Vi vill lägga till. * / Virtual Void Addenity (Entity * Entity); / ** \\ Kort Den här funktionen är endast kallad när enheten hade alla nödvändiga komponenter och har inte längre. \\ Param Entity Entity Vi vill ta bort (Entity * Entity);
Dessa funktioner kallas när den beställda uppsättningen komponenter redan har skapats med hjälp av SetRequiredComponents-funktionen.
Till exempel kan vi beställa att bara få de enheter som har action_component och sound_component. Jag överför den till SetRequiredComponents och - Voila.
För att förstå hur det fungerar ska jag skriva på exemplen, vilka system vi har:
- Transformsystem - ett system som är ansvarigt för omvandlingarnas hierarki.
- Switchsystem är ett system som är ansvarigt för att byta objekt som kan vara i flera stater, såsom förstörda och ovanliga.
- Lodsystem är ett system som är ansvarigt för att byta lodes på avstånd.
- Partikeleffektsystem är ett system som uppdaterar partikeleffekter.
- RenderupdateSystem - ett system som uppdaterar gör objekt från scenräkningen.
- LightUpdateSystem är ett system som uppdaterar ljuskällor från scenräkningen.
- ActionUpdateSystem är ett system som uppdaterar åtgärderna (åtgärder).
- SoundUpdateSystem är ett system som uppdaterar ljud, deras position och orientering.
- UpdateSystem - Ett system som orsakar anpassade anpassade uppdateringar.
- StaticocClusionSystem - statiskt ocklusionssystem.
- StaticocClusionBuildSystem - statiskt ocklusionskonstruktionssystem.
- SpeedTreeUpdatesystem - Speed \u200b\u200bTree Trees Update System.
- Vindsystem - vindberäkningssystem.
- Wavesystem är systemet med att beräkna oscillationerna från avgifterna.
- Folliagesystem är ett system för beräkning av vegetation över landskapet.
I nästan vilket system som helst ser koden så här:
För (en viss uppsättning objekt) (// få nödvändiga komponenter // Utför åtgärder på dessa objekt // Skriv data till komponenter)
System kan klassificeras som de hanterar objekt:
- Kräver behandling av alla objekt som finns i systemet:
- Fysik
- Collisia
- Kräver endast markerade objekt:
- Omvandlingssystem
- Åtgärder System (Åtgärder)
- Ljudbehandlingssystem
- Partikelbehandlingssystem
- Arbeta med sin specialoptimerade datastruktur:
- Statiskt ocklusionssystem
Resultat
- Vi har mycket höjt FPS, eftersom med komponentmetoden har det blivit mer oberoende och vi kunde frigöra dem separat och optimera.
- Arkitekturen har blivit enklare och förståelig.
- Det blev lätt att expandera motorn, nästan utan att bryta de närliggande systemen.
- Det blev mindre än buggar från serien "med gjort något med stockar, bröt switchar" och vice versa
- Det fanns en möjlighet att alla parallellt med flera kärnor.
- För närvarande arbetar vi redan med alla system för att köra på alla tillgängliga kärnor.