Beszámoló - Los Angeles
Eric Kieron Davis egy ideig a frankfurti és wilmslowi irodákban dolgozott, de mostanra visszatért Los Angelesbe.
A stúdió rengeteg alkatrész leírásával készült el, ami a 3.0-ás verzióhoz kell majd.
Dolgoznak a 3.0-ás verzió NPC-inek hangcsomagjain, közel 2.800 sornyi szöveget írtak meg és vettek fel, amiket az NPC-k szájából hallhatunk majd.
Elkészítették a Persistent Universe Character Tracking Sheetet, ami minden párbeszéd részleteit rögzíti.
Átnézték a helyszíneket és feljegyezték, hogy hol van szükség további történetekre, magyarázatokra.
Szállítás
Elkészültek a Cargo Grid fejlesztésével, ami lehetővé teszi a rakomány vizuális megjelenítését.
A szállítandó rakomány a megfelelő mennyiségű ládában fog megjelenni a hajó rakterében.
Elhelyezhetünk járműveket és rögzítetlen tárgyakat a raktérben, de ezek lekorlátozzák a rakomány számára rendelkezésre álló területet.
Mérnökök
Befejezték a naprendszer tartalom hierarchikus rendszerének, vagy más néven az object containers rendszerének készítését. Ez lehetővé teszi az elemek szerkesztését, amivel munkát és időt spórolnak meg a fejlesztőknek.
Átdolgozták a járművek belső sérülési állapotának kezelését, így sokkal könnyebb beállítani és a felmerülő hibákat javítani.
A repülésvezérlő rendszer frissítését szakaszonként végzik.
Elkészült az új Kvantum-meghajtó 2.0. Újraszámolták a vezérlőelemket és új lehetőségeket adtak hozzá. Készen áll a design, művészeti és felhasználói felülettel kapcsolatos munkákra.
Hajók
Az RSI Aurora egy végső grafikai vizsgálaton ment keresztül. A designerek készítettek 14 különböző festést a hajóhoz.
Az Anvil Terrapin a greaybox fázis végéhez ért és most a végső grafikai munkákat, valamint a technikai tervezést végzik.
A Tárgy-rendszer 2.0-ra való átállással együtt a weboldal hajó-állapot részét is frissíteni fogják.
Technikai művészek és animációk
Átnézik az azonosítókódok kibocsátását és más dolgokat, amikkel komoly teljesítménynövekedést érhetnek el.
Fejlesztették az animációk rögzítésére használt formátumot, amivel csökkentették a töltési időt.
Elkészítették a női karaktermodell átviteli hálóját, a férfiét pedig frissítették.
Beazonosították és kiiktatták a bugot, ami a karakterek szemhéjánál fura kis négyzetet jelenített meg.
Karakterek
Számtalan öltözékkel készültek el, amiket a Squadron 42-ben és a PU-ban látunk majd.
A női karakter játékbeli felszerelése elkészült és készen áll a textúrázásra.
A törvényen kívüliek páncél alatti öltözete elkészült és a textúrázásra vár.
A Levskire jellemző civilek és bányászok textúrázás alatt vannak, ezt követően felszerelik őket.
Feljavítják a jelenlegi minőségi szintre a korábbi UEE és kalóz testpáncélokat, valamint modulárissá is teszik őket.
A haj- és szemtípusok csoportja készen áll a 3.0-ra.
A férfi tengerészgyalogos harctéri öltözéke, a férfi fedélzeti legénység, a női könnyű tengerészgyalogos páncél és a női felderítő űrruha már elkészült.
AtV Színfalak mögött: Sorosított változók
(Ez nagyon nem az én világom, ha valahol valamit rosszul írtam le, szóljatok | Shed S.)
Clive Johnson, a Foundry 42 angliai stúdiójának vezető hálózati programozója. Amikor megvizsgálta a Star Citizen hálózatát, megrémült, de hamarosan fogta a lehetetlen problémát és kisebb, lehetetlen problémákká osztotta fel azokat.
A játékban szereplő több ezer rész mindengyikét több ezerszer fel lehet használni, be kell illeszteni a kórba mind a Squadron 42-höz, mind a Star Citizenhez.
Bár 60 programozó mérnök és 6 hálózati mérnök dolgozik a cégnél, csak 3 olyan ember van, aki ténylegesen azon dolgozik, hogy a program többjátékos legyen, de el kell érni, hogy minden kód egyénileg működjön a többjátékos környezetben.
Az Application Programmer Interface (API) megkíméli a programozót ettől a problémától úgy, hogy megmondják, hogy pontosan mit szeretnének, de anélkül, hogy azt meg kéne mondaniuk, hogy azt hogy szeretnék.
Mint a vezetéstámogatásnál, az API meggátolja, hogy a programozó olyan hibákat kövessen el, ami később hibát okozna. Az API leegyszerüsíti a programozó munkáját.
A többjátékos játékok a programozók nézőpontjából egyszerűen sok táblából és értékből állnak, amelyek felelősek a különböző dolgok értékeiért. Ezek az táblák segítenek követni a változókat és azt, hogy hogyan változnak az értékek az idővel.
A programozók kódot írnak, amik több táblára hivatkoznak, hogy megalkossák azt, amit a játékos lát a játékban.
A többjátékos programnál szükséges, hogy a szerver lemásolja ezeket az adattáblákat, miután változtak és elküldje az össze kliensnek, hogy mindenki szinkronizálva legyen.
Mivel több száz változó vagy tulajdonság van, amit szinkronizálni kell a hálózaton keresztül, így időközönként minden adat állapota elküldésre kerül, de ez több dolog esetén hálózati problémákba ütközhet.
A mostani változással csak azok az adatok kerülnek megküldésre, amelyek változtak.
A dolgok különböző alkotóelemek összeillesztéséből épülnek fel.
A probléma, hogy az alkotóelemek számának exponenciális növekedésével a hálózati adatközlés is növekszik, mivel az összes típusú dolgot le kell fedniük, és itt jönnek be a sorosított változók.
Most a programozóknak csak le kell írniuk a kódot, mint általában, a változóknek pedig egy extra lépésként meg kell jelölniük azt, amit meg akarnak osztani a hálózaton.
A sorosítás a folyamatot az adat összecsomagolásával kezdi egy olyan formába, ami hatékonyabban kezelhető, jobban alkalmazkodik a hálózaton való átküldéshez, vagy egy file-ba soroláshoz.
A programnak csak meg kell írnia a további sorokat, amelyek kiemeltek és hozzá kell adni az osztályjellemzőket, ez pedig megmutatja a rendszernek, hogy a szerkezet melyik atgját figyelje, vagy frissítse.
Korábban szükségük volt egy különleges funkcióra minden osztályhoz és a programozóknak egyeként kellett utánanézniük a különböző változóknak a sorosításhoz és ezt beírni a folyamatba, ami több munkát és a hiba lehetőségét hordozta magában.
Most a programozók megjelölik, hogy melyik változót akarják sorosítani és az API automatikusan bevezeti azt az egységes rendszerbe, valamint már a csoport dolgokat sem kell felosztani.
Az API érzékeli, amikor valami módosításra kerül és erről értesíti a netkódot, sőt megírja a kódot, ami kezelni tudja a módosítás sorosítását.
A frissítési üzenetek most már annyira optimalizáltak, amennyire az szükséges.
A sorosított változók a sarokkövei a PU építésének, mivel az folyamatos kommunikációt igényel a különféle szerverek között.
Ez azt jelenti, hogy számos szerver figyelhet egy dolgot az aditt időben és azt, hogy melyik szerver kezeli ezt, egy token segítségével döntik el.
A token-t egyszerre egy számítógép viselheti, ami azt jelenti, hogy a sorosított változók összekötésével és a tokenekkel képesek lesznek egy pillanat alatt átadni a felügyeletet az egyik szerverről a másikra.
A eredeti műsor 2017. június 15. napon került adásba.
Nincsenek megjegyzések:
Megjegyzés küldése