Star Citizen har stora problem efter massiv patch

Du har inte motiverat någonting, du har pratat om "enklare system" gentemot "avancerade varianter", vem som helst kan ge vaga beskrivningar på det viset.
Exakt, blir ingen vettig diskussion när man jämför ett system som fungerar med ett obeprövat koncept. Jag kan också hitta på en massa avancerat utan att faktiskt göra det, är rätt enkelt. Och faktum är att Star Citizens Server Meshing finns inte än, det funkar inte, ingen utanför utvecklarna har tagit del av det, allt du går på är presentationer om hur det borde fungera. Förklara gärna hur man kan vara pionjär utan att göra något? Fan, Sergey Titov är den största pionjären någonsin om man går på den definitionen.

Jag har låtit bli att gå in på tekniska detaljer eftersom det inte är någon idé ifall alla inblandade parter inte är insatta i de tekniska termerna och detaljerna — då är risken stor att det bara är slöseri med tid.

Men visst, jag kan skriva vad jag vet eftersom du verkar genuint nyfiken. Kan försöka att inte göra alltför teknisk beskrivning.

I Star Citizen utgörs Server Meshing-lösningen av ett replikeringslager, flera lager med shards, en grafdatabas samt spelklienterna, men innan jag går in på de sakerna så kan jag först nämna något om några andra saker som också är intressanta i det hela.

Allt i Star Citizen är object containers. Dels finns det statisk hierarki med object containers, t ex solsystem med sol, planeter och månar med rymdstationer som alla är egna object containers som innehåller ytterligare object containers. Sedan finns det dynamiska entiteter som spelare och NPC:er, rymdskepp, fordon, olika maskiner och så vidare.

De dynamiska entiteterna är också hierarkier av object, till exempel spelkaraktär har en kropp och på huvudet en hjälm, skydd på olika kroppsdelar samt utrustning. Allt detta utgör en shard entity hos spelkaraktären. Sedan finns det så kallade streaming groups. Om vi tar ett rymdskepp till exempel så kan det innehålla ett antal vapen, spelare med utrustning, stolar, bord och mängder med andra saker. Rymdskeppet och allt som ingår utgör en streaming group.

Just det här med hierarkier av objekt och streaming groups blir särskilt intressant när man tittar på hur allting lagras och replikeras vilket görs i form av grafer vilket är intressant och en viktig del i lösningen som CIG tagit fram.

Om vi tittar på Server Meshing-lösningen så handlar det bland annat om att istället för att ha en enda shard, vilket är en grupp av spelservrar där spelvärlden simuleras, så separeras replikering och simulering med hjälp av särskilt replikeringslager. Dessutom körs simuleringen inte i en enda shard utan flera lager av shards vilket gör det möjligt att skala ut effektivt.

En sak till som är viktig är så kallad streaming-bubbla (Streaming Bubble). När en spelare loggar på spelet så skapas en streaming-bubbla runt spelaren. Allt som är synligt ur spelarens synvinkel existerar inuti bubblan och alla object containers samt streaming groups som är inuti bubblan streamas in i replikeringslagret och replikeras sedan till klienten.

Vad är det då som ingår i streaming-bubblan? Det beror på hur stora objekten är och vad spelaren kan se. Exempelvis en måne som är långt borta men som är synlig för spelaren ingår i bubblan, medan ett mindre rymdskepp som befinner sig mellan spelaren och månen men som spelaren inte kan se ingår inte i bubblan.

När spelaren rör sig genom spelvärlden och får syn på nya saker så inkluderas de också i bubblan, medan saker som spelaren inte längre ser exkluderas ur bubblan. Replikeringslagret ser hela tiden till att objekt streamas in eller laddas ur på klienten beroende på vad som sker i bubblan. Detta kallas för Entity Bind Culling.

Objekt som har laddats ur och som inte längre ingår i streaming-bubblan hos någon spelare blir inaktiva och simuleras inte längre om det inte finns någon anledning att göra det.

Det här med streaming-bubblan är väldigt viktigt för prestandan eftersom det påverkar vad som replikeras mellan klienterna och servrarna.

Om vi tittar på replikeringslagret så består det av servrar som sköter replikeringen och drivs som sagt av streaming-bubblor på klienterna. Algoritmen som används för att hantera det hela heter Network Bind Culling algorithm. Varje server i replikeringslagret har ansvar för ett antal streaming-bubblor vardera och hanterar streamingen till och från klienten.

Replikeringen går även åt motsatta hållet, dvs klienter replikerar status till replikeringslagret. Replikeringslagret replikerar sedan subset av data från klienterna till spelservrarna beroende på vad som ska replikeras till olika servrar.

Replikeringslagret håller reda på varje entitet i spelet vilket replikeras av spelservrarna där spelvärlden simuleras. Endast ett subset av entiteter skickas från varje spelserver till replikeringslagret beroende på vad som ska streamas till klienterna. Replikeringslagret replikerar sedan entiteter till varje klient beroende på vad som ingår i klienternas streaming-bubblor.

I spelservrarna görs en hel del beräkningar som inte sker på klienten, till exempel kontroll av AI, beräkning av skador orsakade av brand, explosioner och så vidare. All sådan data replikeras sedan från spelservrarna till replikeringslagret och vidare till klienterna och andra servrar.

Streaming-bubblor kan överlappa förstås vilket resulterar i att samma entiteter replikeras till flera servrar i replikeringslagret samt till klienterna.

Även om flera spelservrar simulerar samma entiteter så är det bara en av servrarna som har auktoritet, dvs "äger" entiteten, och som har rätt att replikera data till replikeringslagret för entiteten ifråga. Så i princip kan man säga att en spelserver fungerar på samma sätt som en spelklient där lokal simulering av spelvärlden replikeras till replikeringslagret.

Det kan även ske auktoritetsbyte av en entitet, ifall entiteten ifråga lämnar en streaming-bubbla och flyttar till en annan bubbla som simuleras i en annan spelserver så får den servern aktoritet över entiteten. Varför tar jag upp det här med auktoritetsbyte? Jo, för att auktoritetsbyte kan även ske på grund av lastbalansering för att få jämnare antal entiteter på varje spelserver vilket i sin tur är positivt för prestandan.

Tillstånd och persistent data för alla entiteter i spelvärlden lagras i form av entitetsgrafer i en databas som är optimerad för hantering av grafer som heter EntityGraph och replikeringslagret ansvarar för att replikera data till och från databasen. I och med att allting lagras som grafer så är det väldigt effektivt att hämta hierarkier av entiteter vilket också passar utmärkt att hantera som object containers i simuleringar i shards.

Detta gör det även möjligt att hantera stora rymdskepp i spelservrarna där spelare eller NPC:er parkerat sina mindre skepp i hangaren, där varje skepp har egna saker inuti skeppen inklusive beväpning, kanontorn, sköldar och så vidare. Även skador och förslitningar av olika komponenter ingår i hierarkin.

Ytterligare en fördel med grafer är att när ett föremål flyttas ut ur ett skepp så kapas den grenen i skeppets graf och blir en egen graf vilket är väldigt effektivt att göra. När sedan föremålet släpps ned någonstans så läggs föremålets graf till som en gren i aktuella grafen som gäller just där, till exempel en rymdstation. Såna här grafrelaterade saker är väldigt smidiga att hantera och lagra i grafdatabasen.

Ändringar som påverkar graferna kallas för mutationer. När mutationer sparas i databasen så sparas alltid varje relaterad mutation samtidigt. Om någon av mutationerna inte går att spara så sparas ingen av mutationerna. Det garanterar att allting sparas på rätt sätt. Grafer och annan data streamas hela tiden från databasen och för att se till att inget tappas bort på vägen så mellanlagras allting i en kö. Varför tar jag upp mutationer? Därför att det är viktigt med stabil och effektiv lösning för persistence.

Det var kort sammanfattning om hur det hela funkar. Allt jag skrivit går enkelt att googla och verifiera, och man kan börja här till exempel.

Om vi tittar på Dual Universe som du tog upp så verkar de inte vara lika transparenta som CIG. Jag har inte hittat information om exakt hur de gör där rent tekniskt i sin lösning, men enligt den här tråden så verkar det inte fungera helt optimalt i det spelet. Spelarna där klagar nämligen över att spelet laggar mycket och de hävdar dessutom att Dual Universe renderar saker som inte ens syns på skärmen. Om det stämmer så är det ett riktigt illa eftersom det i så fall innebär problem på två olika sätt — dels så blir renderingen tung på klienten och dels så skickas det väldigt mycket onödig information mellan klienten och servrarna som tynger ned.

Om de som står i tråden stämmer så betyder det att Dual Universe saknar en effektiv lösning för att filtrera bland entiteter i stil med streaming-bubblan i Star Citizen. Jag har inte hittat någon information om ett replikeringslager heller, vilket också är viktigt för prestandan, så tills vidare får jag anta att Dual Universe inte har det heller. Om någon vet mer om detta så får ni gärna rätta mig.

Star Citizen är som sagt pionjär när det gäller Server Meshing-lösningen ovan som innebär replikeringslager som replikerar med flera lager av shards samt klienter i ett spel i den skalan. Lösningen är dock tekniskt sett utmanande att fixa vilket gör att det kan bli knas ibland, men utvecklingen fortsätter som bekant.

Då ställer jag den naturliga frågan, vart kan jag se en praktisk demonstration av tekniken du beskrev? För att beskriva hur man TÄNKT att lägga upp systemet gentemot att faktiskt göra det är två helt olika saker, och med tanke på de enorma förseningarna tekniken utsatts för så kan det inte riktigt gått som de tänkt.
Optimering åsido (som kan bero på mycket eller summan av många små, Dual Universe är inte heller klart, likt Star Citizen) så finns tekniken i ett spel redan, dvs. likställt till en praktisk demonstration. Finns absolut inget som pekar för (eller emot) att Star Citizen kommer funka bättre (som också denna nyhet handlar om).

Som jag försökt få fram, du vet inte, jag vet inte, ingen vet. Allt är killgissande kring relativt vaga beskrivningar (om man hade kunnat få in hur hela systemet fungerar på en A4 likt din beskrivning hade det varit klart för längesen). Det är också därför jag gick på din kommentar om att de är pionjärer, de har inte bevisat att de faktiskt har en lösning, delar av en eller en beskrivning är inte belägg för att bli kallad pionjär.
Det är fortfarande precis lika möjligt att deras lösning inte fungerar alls eller blir så bra som de hoppats (mycket samma hur många andra funktioner, har hyllats i förväg och sedan visats inte ha någon vidare magnifik praktisk effekt på spelupplevelsen, sk. "jesus-tech" av folket på internet, typ OCS i Star Citizen och i sin tur SSOCS).

Så igen, det är inte att mörka att det kan bli cool teknik, men tills de har gått över mållinjen så är det ingen framgång eller innovation. Det är allt jag ville framföra då du gick hårt på pionjär-hållet när det i mitt tycke inte är befogat (än).

Du har rätt till din åsikt. Jag håller inte med.

CIGs lösning är definitivt ett pionjärarbete som just nu är under utveckling och ser mycket lovande ut.

Det är ju precis det jag menar, vadå "ser"? Vi har inte sett något alls, ordet du letar efter är "låter". Så vitt jag vet, verkar som jag får svara på min egen fråga, har vi inte fått en praktisk demonstration av systemet. Jag förstår att du tycker det låter tufft och nytt, men det är långt, långt ifrån klart. Faktum är att det finns inga bevis för att systemet ens är påbörjat annat än vad de hävdat, och som sagt, sanningen har flertal gånger inte varit vad de sagt och utfallet av vad de hävdat har sällan varit densamma. Tom. deras egna uttalanden om systemet innehåller en hel "vi hoppas", "vi har tänkt" etc.

Om vi börjar använda pionjärarbete till alla som försöker sig på att göra något så är varenda spelutvecklare på marknaden pionjärer då deras lösning skiljer sig något från konkurrenternas.

Exempel, vart skitmånga som trodde Cyberpunk skulle bli bästa någonsin och de lovade himmelen men när det väl kom till kritan så blev det inte riktigt vad de visat eller hävdat. Och exakt samma gör du nu med en enstaka funktion i ett spel med skyhöga löften och hittills inte levererat en bråkdel av dem trots långt, långt förbi tidsplanen..

Som sagt, du kan tycka precis som du vill och jag kan tycka vad jag vill.

Ha en bra dag!

För all del, vi har säkert nått änden av resonemangen.

Detsamma till dig!

@fiddi du har definitivt en poäng när du säger att dom inte visat någon än. Däremot så ökar sannolikheten att CIG kommer klara av detta allteftersom mer och mer av deras arbete blir klart. 2015-2016 kändes projektet riktigt illa med bytet av motor å grejer. Det var nog många som var rädda att projektet skulle gå åt fanders, men nu visar ändå CIG framgångar inom flera områden vilket iaf får mig personligen övertygad att de faktiskt kommer ro detta i land. Men mer konkret än så kommer du tyvärr inte få innan CIG själva presenterar den färdiga varan är jag rädd.

Oavsett om man är fan av star citizen eller ej, så ligger det i alla gamers intresse att star citizen blir verklighet eftersom tekniken i såna fall skulle kunna appliceras i andra spel oavsett genre. Det skulle kunna rita om hela spelindustrins mmo. Det är väl bra att du har en restiktiv inställning till hur star citizen utvecklas, annars är det lätt att alla här (inklusive mig själv) är ja-sägare och en farlig groupthink breder ut sig 😁

Visst är det så, om de lyckas göra det de hävdar de kan så kommer det bli tufft som attans. Men höga löften ger lika mycket att bevisa. Om det hade varit en investerares pengar de utforskar med så hade det inte varit så farligt, men nu är det ju på bekostnad av slutkunderna genom mikrotransaktioner och stundtals otäck marknadsföring, så det är väl lite där de har mycket mer att bevisa än gemene utvecklare, utöver då att de är en obeprövad studio.

Men ja, den som lever får se... Glad påsk!