Volledig transcript

Dave: Hallo, ik ben Dave Baszucki, oprichter en CEO van Roblox, en u luistert of kijkt naar Tech Talks. Vandaag gaan we het hebben over wat een game-engine van de tweede generatie precies inhoudt, hoe de cloud hierbij een rol speelt en hoe we gebruikers helpen om direct en in hoge resolutie mee te doen. We hebben hier het technische droomteam van Roblox bij ons.

We hebben dus Varun Mani, Sergey Makeev en Tsvetan Tsvetanov, en we gaan dieper in op alles wat met streaming te maken heeft. We gaan het hebben over slim, we hebben het over het transcoderen van assets, alles wat ervoor zorgt dat Roblox uiteindelijk honderdduizend spelers kan ondersteunen. Als we kijken naar de game-industrie van de afgelopen 10 of 20 jaar.

Er is een traditionele manier waarop al deze 3D-content voor je verschijnt en, eh, en, en er zijn wat problemen met deze traditionele manier. Want wat we bij Roblox proberen te doen, is direct meedoen. Eh, we proberen dezelfde ervaringen zowel op een telefoon als op een gigantische pc te laten draaien. Eh, we proberen dit te doen zonder enige vertraging, en als we kijken naar de manier waarop traditionele games werken, is dat niet helemaal hetzelfde, toch?

Ik kan me nog herinneren dat ze in mijn tijd werden gedistribueerd op die dingen die floppy discs heten. Maar zelfs vandaag de dag distribueren we games nog steeds op grote dvd's, denk ik. Klopt dat? 

Varun: Ja. En ik denk dat de sleutel hierin is dat het allemaal in één pakket zit. Ja. Toch? Dus of het nu een dvd is of dat je vandaag een game downloadt, het komt als één groot pakket dat je niet kunt opsplitsen.

Dus je moet wachten tot de volledige 4,7 gig, of in sommige gevallen 10 gig, volledig is gedownload voordat je kunt beginnen. 

Sergey: Ja. En zoals Varun al zei, bij sommige games kan dat wel 20 of 40 gigabytes zijn, en dan moet je heel lang wachten voordat je kunt beginnen met spelen. En dat is een beetje, weet je, dat verpest de flow, toch?

Want je wilt spelen, je hebt misschien een uur of twee uur na je werk, je wilt een game spelen en dan moet je 30, 40 minuten wachten terwijl het wordt bijgewerkt en zo. Dat is eigenlijk zo'n beetje mijn ervaring, het spelen ervan. Zoals 

Dave: is dat niet een beetje vergelijkbaar met wat we hebben gezien bij video's en films?

Ik kan me een tijd herinneren dat films op dvd's werden gedistribueerd en ik kan me bijvoorbeeld ook een tijd herinneren met BitTorrent. Je downloadde het hele ding en uiteindelijk kwamen we bij het punt dat ik naar mijn Amazon of mijn Netflix of mijn Hulu of mijn Tubi ga en ik het meteen kan bekijken. Maar ik denk niet dat dat nog helemaal is gebeurd in de gamemarkt.

Nog niet. Nog niet. Ik denk nog niet. 

Tsvetan: Wij zijn de enigen die ons daarop richten 

Dave: dat. Dus, historisch gezien heeft Roblox altijd zo gewerkt, achter de schermen, eh. De meeste mensen merken het misschien niet, maar als je naar de startpagina van Roblox gaat en op 'play' klikt, kun je direct meedoen. Dit is eigenlijk heel ongebruikelijk, want als ik op sommige zeer geavanceerde, eh, gamingplatforms zit, heb ik wel eens meegemaakt dat er 200 gigabyte moest worden gedownload voordat ik kon spelen.

Dus we doen dit 'instant play' al? Ja. 

Tsvetan: Eh, Roblox is, voor zover ik weet, het enige platform dat dit direct meedoen en spelen toestaat. Oh ja, 

Varun: ja, sorry. En, en het is een beetje zoals toen je het had over videostreaming, toch? Zoals wat je eigenlijk doet als je een videostream doet waarbij ik niet de hele film wil downloaden, ik download alleen net genoeg van de film die voor me ligt en dat noemen we bufferen.

Ik, ik stream de film. Toch? Dus dat klopt, maar dat is slechts in één dimensie. Want daar is alleen een tijdsdimensie. Ja, dat is het belangrijkste verschil hier. Dat is wat het moeilijk maakt om het in Roblox te doen, want het is een volledig interactieve 3D-wereld waar je zowel instances als assets moet streamen, wat eigenlijk de basisbouwstenen zijn van alles in 

Dave: Roblox A a en eh, ik zou zeggen dat dit het nog moeilijker heeft gemaakt, want in de traditionele videogamemarkt

Ik zie vaak verschillende versies van games op bijvoorbeeld een high-end pc en een low-end mobiel. En wat ik, de manier waarop ik dat interpreteer, is dat op high-end pc's, waar ik honderden gigabytes kan downloaden, je die echt grote, complexe assets hebt, en op mobiel is het bijna alsof makers, denk ik, een aparte versie maken 

Sergey: op een bepaald moment.

Eh, ja. Dat is een heel goed punt, want bij traditionele games hebben ze een proces dat 'asset cooking' heet. Ze maken dus een sterk geoptimaliseerde versie, per platform. En als je erover nadenkt vanuit het perspectief van videostreaming, dan is het net als op een dvd.

Eh, de video is maar één keer gecodeerd, toch? Ja. Maar op elk streamingplatform hebben ze meerdere coderingen voor dezelfde video, zodat het automatisch wordt aangepast aan je apparaat. En, eh, bij alle huidige games bereiden ze hun assets als het ware voor en leveren ze heel specifiek aan Triplex hier.

Dus we kunnen per platform een geoptimaliseerde versie van één asset genereren in de cloud. Dat klopt. 

Dave: Houd die gedachte even vast, oké? Want een tijdje geleden hadden we de visie dat als je een jonge maker bent en je maakt je eigen ervaring, die in elke taal kan draaien. We hadden de visie dat het op elk apparaat kan draaien en op verschillende resoluties op elk apparaat.

We gaan er dieper op in. Dus, de traditionele gamingmarkt, je weet wel, verpakt of gedownload. We willen die problemen oplossen: directe toegang, gepubliceerd voor elk apparaat, lage latentie en dat allemaal samen. En dus gaan we het vandaag hebben over iets dat letterlijk 3D en 40 streaming heet.

We gaan het hebben over, eh, content in de cloud. We gaan het hebben over iets dat 'slim' heet, waar iedereen volgens mij heel enthousiast van zal worden. Dus misschien, eh, om erin te duiken, Varun, eerst een korte visie op wat 'slim' is en wat. Eh, we noemen het Cloud Transco. Ja. En wat betekent dat allemaal? 

Varun: Dus, als we even een stapje terug doen, als je nadenkt over onze algemene visie, dan is die dat we proberen 10% van de gamingmarkt te veroveren.

Ja. De manier waarop we dat doen, is door makers volledige vrijheid te geven over wat ze bouwen. Eh, en als je nadenkt over hoe we groeien, zijn er eigenlijk twee dimensies. Je kunt ofwel platformuitbreiding doen, of we kunnen genre-uitbreiding doen. Platformuitbreiding is: hoe zorgen we ervoor dat dezelfde content op elk platform werkt?

Je maakt het dus één keer. Roblox, zorg ervoor dat het overal werkt. En bij genre-uitbreidingen. We willen dat je steeds indrukwekkendere dingen maakt en steeds gekkere dingen. 

Dave: En als je zegt 'overal draaien', letterlijk, stel je dan iets heel groots, geks en leuks voor. Grand Theft Auto, Red Dead Redemption, high-end consoles.

Draait op een Android-telefoon met twee gigabyte en alles daartussenin. Dat klopt. Van 

Varun: Van pc tot een Android-telefoon met 2 GB, het zou gewoon moeten werken zonder dat de maker extra werk hoeft te doen. Dat is dus de visie. Precies. Cloud, transcodering en Slim zijn slechts twee van de eerste stappen die we op die weg zijn begonnen te zetten.

Dave: Oké, dat is een kleine teaser. We gaan uitleggen wat Slim is en we gaan uitleggen, ik denk dat jij waarschijnlijk gaat uitleggen wat transcodering is, maar laten we eerst even iedereen voorstellen. Dus Sergey, eh, je bent er weer, kun je iets vertellen over je achtergrond in engine-optimalisatie? Een van de leukste dingen ter wereld, toch?

C++ en assemblagetaal zoals CmD, kun je iets vertellen over waar je aan hebt gewerkt? 

Sergey: Eh, ja, zoals je al zei, dus ja, ik heb eigenlijk mijn hele leven al aan games gewerkt en ik doe al die optimalisaties, beginnend bij de regionale Xbox en zo.

Eh, en. Weet je, toen ik voor het eerst hoorde over Roblox, was ik gewoon helemaal onder de indruk van het idee van een game die maar één keer gemaakt hoeft te worden, of eigenlijk, niet eens een game. Misschien meer een ervaring die maar één keer gemaakt hoeft te worden, en die vervolgens overal draait, op elk platform, op elk apparaat, zonder dat er extra gebruikersinvoer nodig is.

En dat is een enorm uitdagend technisch probleem. Eh, zoals, eh, zoals iedereen zich kan voorstellen, toch? Dus, eh, en dat vereist veel, eh, je weet wel, traditionele optimalisaties, zoals CMD, zoals multi-threading, zoals heel zorgvuldige GPU-planning, dat allemaal. Maar tegelijkertijd, weet je, is er een soort limiet, eh, aan hoeveel we kunnen opschalen op, op een enkel apparaat.

Gelukkig voor ons hebben we altijd onze cloud, toch? Dus we kunnen een deel van dit werk uploaden naar onze cloud en die apparaten helpen om efficiënter te renderen, zodat ze grotere muren kunnen weergeven. Tot op zekere hoogte, weet je, bijvoorbeeld wanneer we muren kunnen renderen die niet eens in het geheugen van een fysiek apparaat passen, omdat ze ook op de server bestaan en de server alle clients helpt om ze efficiënt weer te geven.

Dave: Ja. En dus, even als hoogtepunt, ik denk dat een deel van de hint die we hieronder gaan delen is dat traditionele game-engines meestal in C++ zijn geschreven, en je alle assets downloadt. Maar stel dat een game die je wilde spelen de hele wereld was, bijvoorbeeld, niemand kan de hele wereld op een dvd zetten.

En dus waar je eigenlijk op doelt, en we zien het al bij Google Maps en dat soort dingen. Het is onmogelijk om dat allemaal op één plek te zetten. En dus is een deel van wat we gaan bespreken als we het over streaming hebben, datzelfde voor games en dan enton. Kun je een beetje vertellen hoe je bij Roblox terecht bent gekomen, wat je achtergrond is en misschien een kleine hint geven over wat cloudtranscodering is?

Dus, 

Tsvetan: eh, voordat ik bij Roblox kwam, heb ik, eh, mijn, eh, professionele ervaring opgedaan in twee domeinen. Het ene is, eh, 3D-ontwerp- en simulatiesoftware voor architectuur, bouw en werktuigbouwkunde. En het tweede was grootschalige gedistribueerde computing, wat. Ik kan mijn kennis uit beide, eh, domeinen toepassen bij Roblox, want dat is eigenlijk wat Roblox is.

Dave: Ja. Laten we het even hebben over streaming op Roblox. We weten wat videostreaming is. Het streamen van een video is een soort lineair proces, toch? Je hebt gewoon een frame nodig. Na een frame sturen we ze de een na de ander. Kun je uitleggen wat streaming in 3D in realtime inhoudt? 

Varun: Als je kijkt naar wat, eh, bijna alles in een Roblox-game tegenwoordig bestaat uit instances of assets, toch?

Instances, dat is als het ware de structuur van de wereld. En dan is een asset het ding dat die instance daadwerkelijk aanstuurt voor de daadwerkelijke content. Eh, als je aan streaming denkt, gaat het om het streamen van instances en ook het streamen van die assets. Dat moet je doen. Dus als je in een videostream maar één asset hebt, dan is dat de video.

In Roblox doen we dat duizenden, 10.000 keer, eh, keer op keer. Dus als je het over instant streaming hebt, probeer je gewoon genoeg van de wereld om je heen te streamen en weet je niet wat de speler gaat doen. De speler loopt misschien deze kant op, de speler loopt misschien die kant op. Je wilt precies genoeg van de wereld streamen of bufferen.

En dan wil je in die wereld die je hebt gebufferd, de assets in precies de juiste kwaliteit bufferen. Zoals Sergei al zei, heb je verschillende kwaliteitsniveaus voor video. We hebben hetzelfde voor meshes en hetzelfde voor afbeeldingen. 

Dave: Dus als we het opsplitsen, is het dan juist om te zeggen dat de instances dingen zijn die we wellicht kennen?

Een auto, een boom, een andere persoon, een heuvel, iets in die trant. En dan zijn de assets de technische elementen waaruit die instances bestaan. Zoals de binnenkant van die 3D-objecten. Als we allemaal in een game zitten, hebben we klompen driehoeken, klompen texturen, en dus hebben we het over het kiezen welke daarvan we

Op elk moment echt binnenhalen. 

Varun: Ja. En welke weergave ervan. Dus terwijl je door de wereld loopt, is het alsof het apparaat zegt: oké, ik wil die boom, of ik heb die boom nodig. Die boom bestaat uit een heleboel meshes en een heleboel texturen, en misschien in de toekomst zelfs animaties, audio, enzovoort.

Dus dan beslist het. Oké. Op basis van de positie van die boom, het belang ervan, hoeveel schermruimte het inneemt. Ik wil de textuur in hoge kwaliteit. Ik wil de mesh in gemiddelde kwaliteit. En dan de audio, misschien heb ik de audio nog niet nodig, dus wacht nog even met de audio. Dus het maakt constant die keuzes, 

Dave: dus in zekere zin lijkt dit een beetje op, wanneer ik een kaartprogramma gebruik, ik, ik haal alleen de kleine afbeeldingen binnen, een klein stukje van de kaart.

We hebben het over de 3D-versies daarvan en, je weet wel, ook interactieve 3D-componenten. Oké. En er is hier achter de schermen iets heel essentieels. Ik zou zeggen dat onze visie altijd is geweest: ongeacht welk apparaat of waar je ook bent, we proberen de juiste elementen zo snel mogelijk binnen te halen.

En ik, en soms zeggen we dat we ze zo snel mogelijk willen laden om de menselijke beleving van magie te maximaliseren. Zoals: wauw, de wereld verscheen voor mij. Dus Sergey, hoe kiezen we en hoe sorteren we wat we laden en wat we binnenhalen? 

Sergey: Ja, optimalisatie, bijvoorbeeld voor de waargenomen latentie.

Dat is heel belangrijk, want zoals Varun net al zei, weet je wel. We meten constant, weet je, zoals het schermoppervlak, of hoe belangrijk het object is. Bijvoorbeeld, als je een boom ziet van heel dichtbij, of als je precies dezelfde boom van heel ver ziet, dan kunnen dat twee verschillende bomen lijken, toch?

Dus als je het van een afstand ziet, geef je niet echt om fijne textuurdetails of zo. Dus we kunnen altijd een textuur met lage resolutie gebruiken voor de boom. Eh, je zult geen onderscheid kunnen maken tussen, je weet wel, of het een structuur met een laag risico is, of een met een hoog risico, omdat het gewoon heel klein is op je scherm.

Maar aan de andere kant kunnen we het bijna onmiddellijk laden omdat er op deze manier veel minder data is. Maar als je dichter bij die drie komt, laden we geleidelijk steeds meer data en ziet het er gedetailleerder uit. Je zult de overgang dus niet kunnen zien, je zult het verschil niet kunnen zien, maar je zult het onmiddellijk kunnen zien en ermee kunnen interageren.

Dave: En een deel hiervan is wanneer ik mijn Android-telefoon met 2 GB of mijn gaming-pc gebruik en ik direct ergens aan mee wil doen. Ook al is het internet erg snel, we hebben geen bandbreedte. Het is alsof we de wereld door die pijp proberen te duwen, of je nu 10 megabit per seconde of 100 megabit per seconde hebt, en we moeten een balans vinden in wat we erdoorheen sturen.

En, en ik, een manier waarop ik er soms over nadenk, is één boom die dicht bij me staat. Eh, die kan dezelfde informatie gebruiken als honderd bomen die ver van me af staan, en in wezen kunnen die honderd bomen die ver van me af staan visueel net zo belangrijk zijn als die ene die dichtbij staat, en we halen ze binnen met verschillende resoluties.

Zoals die die dicht bij me staat, is veel natuurgetrouwer dan die welke ver weg staan. 

Sergey: Ja, eh, dat klopt precies. Eh, en, en, eh, het belangrijke punt dat je ook al noemde is dat we niet alleen meten, weet je, hoe belangrijk het object is, maar ook hoeveel, hoeveel computerbronnen, hebben we?

Hoeveel geheugen hebben we? Netwerkbandbreedte, alles. Dus we houden rekening met alles wat de gebruikerservaring beïnvloedt, en dat omvat ook de prestaties. Hoeveel geheugen hebben we, en dat soort dingen. 

Dave: We hebben het dus gehad over instances die als de boom fungeren, en de assets die de mesh of de texturen zijn.

Kun je wat meer vertellen over hoe ze van elkaar verschillen en wat we eigenlijk onder de motorkap doen met assetstreaming? Oké. 

Tsvetan: Ja. Eh, bijvoorbeeld, bij het streamen vanaf de server, de sites, wat is belangrijk? Ja. En op basis van, eh, het belang ervan, eh. G geeft deze informatie door, stuurt deze informatie door naar elke client, en elke client krijgt daar eigenlijk verschillende, eh, instances voor, afhankelijk van.

Is het zichtbaar? Het is niet zichtbaar. Neemt het deel aan het interactieve kwartier of niet? Voor de assetstreaming? Het is de client die daadwerkelijk streamt wat er in de wereld was. Eh, op basis van de kwaliteit die we nastreven, zoals Sergey zei, op basis van de mogelijkheden van het apparaat, richten we ons alleen op die exacte, eh, weergaven op basis van de kwaliteit en op basis van de mogelijkheden van het apparaat.

Zo werken we eigenlijk. Eh, dus 

Dave: die bomen ver in de verte zijn hopelijk heel compact, toch? Een lagere resolutie, die niet veel ruimte innemen. Zodat we meer tijd en rekenkracht kunnen besteden aan een boom die dichterbij is. Bij mij. En dus hebben we dit ding dat de contentpijplijn of die assetpijplijn heet.

Kun je iets vertellen over hoe deze transcoderingpijplijn eruitziet voor een gamemaker? Stel, ik gebruik Roblox Studio en bouw een hele mooie auto. Wat gebeurt er achter 

Tsvetan: de 

Dave: scènes? 

Tsvetan: Vanwege de, eh, verbeteringen in de engine wilden we ook de, eh, artistieke intentie van de ontwerpers en gameontwikkelaars behouden.

Dus kwamen we op het idee van cloudtranscodering, waarmee we de content kunnen importeren vanuit de makers en deze kunnen opslaan. We optimaliseren deze op basis van het ontwikkelingsapparaat en de mogelijkheden die de klant nodig heeft. En deze pipeline is end-to-end. Het werkt 'lazy on demand'. Wat dat betekent is dat wanneer de klant om een specifieke weergave vraagt, we pas dan, als we die weergave niet hebben, een berekening starten.

Zo niet, dan sturen we het terug als het al bestond. We zijn dus zeer efficiënt wat betreft de bandbreedte en de rekenkracht die we aan de klant leveren. Dus 

Dave: als ik, eh, en wij, er is een lange tijd geleden toen we dit niet hadden, of misschien eigenlijk vrij recent, dat we beperkingen moesten stellen aan de getrouwheid van deze assets.

Zoals, ik denk dat we zouden zeggen dat je maar een bepaald aantal driehoeken in je auto mag hebben, en hoe meer driehoeken, hoe nauwkeuriger je auto eruitziet. Of we zouden zeggen dat je maar een bepaald aantal pixels in de grootte van een textuur mag hebben. Wat we nu zeggen is, ik geloof dat je die auto kunt uploaden hoe je hem ook hebt gebouwd, en dan, als je het hebt over transcoderen achter de schermen.

We maken verschillende versies van die auto met steeds minder driehoeken. 

Tsvetan: Ja, dat klopt. Of eigenlijk in de toekomst. Ja. En eh, dus we hebben nu deze mogelijkheid dat we, eh, afhankelijk van de verbeteringen van de engine en eh, de rekenkracht die we hebben, we kunnen, eh, de weergave van het aantal driehoeken of textuur, de kaarten of audio, video, animatie, wat we ook nodig hebben, verbeteren.

Dus, 

Dave: dus dit is on demand, en ik denk dat wat je eerder zei, Sergey, was dat je vroeger iets had dat 'baking' heette, alsof je de high-end versie zou bakken. We zijn in wezen aan het bakken on demand. Veel versies van die auto in verschillende resoluties. Ze staan er allemaal. En dan is de auto die ik ver in de verte zie misschien een van die versies met een lagere resolutie.

En dit is, eh, ik geloof dat we dit transcoderen noemen. Ja. Dus hoe werkt transcoderen? Hoe pak je bijvoorbeeld een miljoen driehoeken en maak je er duizend driehoeken van? Ik bedoel dat, eh. 

Tsvetan: Eh, ingestion. Ja. Dus in de studio nemen we, eh, eigenlijk die, eh, mesh van 1 miljoen driehoeken op. Vervolgens slaan we die op in, eh, ons backend, eh, contentplatform, eh, backend, eh, systeem.

En dan, eh, op verzoek, voeren we eigenlijk, eh, LOD-verwerking uit, 

Dave: wat staat voor level of detail. Level of detail, wat betekent 

Tsvetan: afhankelijk van, we proberen zoveel mogelijk kwaliteit te behouden voor die, eh, beperkte weergave van de mesh. Of textuur. 

Dave: Dus als, eh, misschien Varun, als we nadenken over hoe dit werkt op verschillende apparaten, jij bent, eh, dus jij bent de maker.

Je voegt deze gigantische auto met hoge resolutie toe. Ik zit op een low-end Android-apparaat. Jij zit op een high-end gaming-pc. Hopelijk kunnen we nog steeds hetzelfde spel spelen. Precies. Wat gebeurt er dan voor ons beiden? En, 

Varun: en dus, dus eigenlijk, als mijn client online komt, is het alsof hij zegt: "Hé, ik ben een low-end Android-apparaat. Ik wil dit specifieke, want één ding dat we nog niet hebben genoemd, is dat het niet alleen om het detailniveau gaat, maar ook om een platformspecifieke weergave.

Dus Android, iOS, elk van deze verschillende platforms heeft heel specifieke weergaven waarbij je de texturen kunt comprimeren, je kunt ze eigenlijk zo aanpassen dat het veel optimaler werkt. Dus mijn Android-apparaat komt online en zegt: "Hé, ik wil de Android-versie. Van een low-end textuur voor die boom", en dan gaat de cloud-transcriptie aan de slag en maakt dat voor mij, en het slaat het op in de cache zodat het volgende Android-apparaat online kan komen.

Het hoeft het niet opnieuw te doen, het kan gewoon de versie sturen die ik heb gemaakt. Als je pc online komt, is het alsof hij zegt: 'Hé, ik heb alle middelen van de wereld. Geef me de versie van hoge kwaliteit, geef me de ongecomprimeerde versie. Ik wil gewoon de hoogste getrouwheid.' En dan slaat hij dat op in de cache, wat betekent dat dit oneindig toekomstbestendig is.

Dave: En ook oneindig direct. Ik ben dol op Grand Theft Auto, en ze hebben een nieuwe versie die absoluut verbluffend gaat worden, waar ik erg enthousiast over ben. Als ik een artiest was die, eh, een asset wilde aanpassen. In ons, hopelijk ons toekomstige systeem, zou ik het binnen ongeveer vijf seconden opnieuw uploaden.

Jouw en mijn spel zouden een nieuwe transcodering daarvan activeren. En letterlijk, weet je, op het hoogtepunt van gelijktijdige gebruikers, zoals bij een game als Grow a Garden met 25 miljoen mensen, zou je binnen vijf tot tien seconden al die nieuwe mensen kunnen hebben. Die mogelijk die nieuwe asset krijgen. Daarom denk ik dat het, het is een beetje de toekomst, want ik, ik denk dat een deel van, eh, de schoonheid van Grand Theft Auto is, is dat ze, ze er zoveel kwaliteit in stoppen.

Ze gaan het op een gigantische dvd zetten. Ze moeten ervoor zorgen dat het perfect is en er is geen manier om dat te herhalen. Je moet het daar absoluut perfect krijgen. En, en, en dus dan, ik, ik, ik denk eindelijk. Wat betreft toekomstbestendigheid, naast onmiddellijke veranderingen, is er iets dat goed lijkt aan het opslaan van artistieke intentie, weet je, het opslaan van het originele kunstwerk.

Kun je in zekere zin aangeven hoe dat ons zou kunnen helpen? Eh, 

Sergey: ja. Dus aangezien we proberen om zoveel mogelijk originele artistieke content vast te leggen, en we dit opslaan, slaan we de bronversie op, dat klopt. Van alle assets. En we kunnen dit, zoals je je kunt voorstellen, je weet wel, we kunnen.

Niet alleen door het te downsamplen door eenvoudigere versies van een textuur te genereren, maar ook door het in de toekomst te upscalen, omdat we die semantiek al hebben vastgelegd, dat wil zeggen wat de oorspronkelijke bedoeling was, zodat we dit bestand in de toekomst kunnen opschalen. En dat zonder dat er enige gebruikersinvoer nodig is.

We kunnen het er beter uit laten zien. 

Dave: Dat, en dat wordt een belangrijke hint als we de toekomst ingaan. Eh, dus laten we, eh, laten we een tweede component toevoegen aan waar we het over hebben gehad. Dus we streamen. Voeren onmiddellijke aanpassingen door. Transcoderen in de cloud, leveren elke LOD. En dan, wat we in het begin al lieten doorschemeren, gaan we dat aanvullen met iets dat Slim heet.

Slim is dus geen trainingsprogramma. Het is niet zoals Roblox, het zijn niet de Roblox-snacks die ons hopelijk allemaal echt een goed gevoel geven en ons helder laten denken, eh, wat is slim in de context van de Roblox-engine. 

Sergey: Dus, ja. Eh, dus. Eh, laat me even een stapje terug doen, en, eh, dit voorbeeld nog eens aanhalen, zoals met een boom, oké?

Dus we hebben, eh, je hebt een boom, en zoals ik al zei, als je bijvoorbeeld meerdere bomen hebt, in de verte, eh, dan is Slim wat al die individuele bomen omzet in een bos en optimaliseert, niet meer als individuele bomen, maar als iets groters, dat is aggregatie, van individuele licenties en, eh.

En het is de Slim-technologie. Het optimaliseert altijd die assets, in een specifieke context. Stel dat je een gebouw hebt, oké? En een heleboel, eh. Eh, kamers in dat gebouw. Als je buiten het gebouw staat, geef je niets om de kamers binnenin het gebouw. Slim is zich bewust van deze context en kan heel efficiënt alle interne onderdelen van het gebouw verwijderen, zoals in dat geval, en een zeer optimale versie van die asset voor je genereren.

Dave: Er zijn dus drie use cases waar ik, terwijl jij dit ontwierp, over heb nagedacht. Eén use case is dat mensen steeds complexere avatars bouwen. En historisch gezien zijn we op Roblox altijd heel voorzichtig geweest met hoeveel lagen kleding je kunt dragen? Hoeveel sieraden kan ik dragen, hoeveel spullen.

Maar in de toekomst hebben avatars misschien wel honderd dingen. En ik denk dat onze makers erg goed op de hoogte zijn van prestaties. Ze beperken misschien wel de kwaliteit van avatars omdat ze zo veel prestaties willen. Avatars die complex zijn, ten eerste. Ten tweede, zoals je al zei, staan er misschien wel honderd bomen in de verte en heeft niemand er interactie mee.

En ten derde is er misschien een gebouw met kamers binnenin. Eh, ik denk dat wat we hier gaan proberen te doen, is dat, wat het ook is, een bewegende avatar, een bos bomen of een gebouw, dit exactzelfde systeem in wezen zal worden samengevoegd tot één enkel object, één enkele mesh, één enkele textuur, en dat is absoluut verbijsterend.

Eh, 

Sergey: ja, je hebt helemaal gelijk. Dat is een goede omschrijving. Zoals voor dit, eh, dat systeem genereert dynamisch een soort samengestelde weergave, van meerdere assets, en het bepaalt, weet je, de grenzen van deze compositie, het detailniveau voor die compositie, dynamisch, het werkt altijd in deze wereldcontext.

Dus precies hetzelfde als in twee verschillende ervaringen, die misschien anders geoptimaliseerd zijn op basis van het doelapparaat, of op basis van de context waarin ze worden gebruikt, en. We ondersteunen ook dynamische updates voor die inhoud. Het is dus niet altijd een statische optimalisatie.

Als er iets verandert in de loop van de tijd, wordt dit weerspiegeld in de slanke weergave, omdat we het dynamisch kunnen bijwerken. 

Dave: Het is bijna... een van de redenen waarom ik dit zo leuk vind, is dat het bijna voelt alsof ik een Roblox-ontwikkelaar ben. En ik wilde echt enorme schaalgrootte en bijvoorbeeld heel complexe avatars.

Misschien droom ik hier wel van, dat ik bijvoorbeeld naar iemand toe kan lopen die dichtbij is. Ze kunnen hun hoed afzetten, ze kunnen nieuwe sieraden omdoen, en zo gaat dit systeem werken met objecten die dichtbij zijn, mogelijk met een hoge resolutie. En naarmate die avatar verder weg komt, wordt het samengevoegd tot één enkel object.

En naarmate hij verder weg gaat met LOD. Eh, we maken grapjes dat het ultieme een avatar ver in de verte is, misschien 12 driehoeken en een heel kleine textuur. Dus dit is, dit is bijna wat een ontwikkelaar, denk ik, heeft gedroomd. En dan denk ik dat dit, eh, een van de dingen die dit mogelijk maakt, een grotere wereld is.

Op verschillende apparaten. 

Varun: Absoluut. Ik bedoel, wat Slim in wezen doet, is ons een nieuwe as van schaalbaarheid geven. We hebben het al zo vaak gehad over cloudtranscodering in verschillende detailniveaus. Nu voegen we hier nog een niveau van een andere as toe, namelijk compositie. Toch? En je kunt hier denken aan een 2 bij 2-raster, waarbij elk punt daarop een geldige ervaring is.

Dat klopt. Je kunt dus kiezen voor hoge kwaliteit en lage compositie, of voor hoge kwaliteit en hoge compositie als je een heel eenvoudig apparaat of een ander apparaat gebruikt. En al die punten zijn logisch. Dus als je het hebt over een enorme wereld, kan die hele wereld uit 12 driehoeken bestaan. Ook als je ver genoeg weg bent, of als het geen verschil maakt.

Dave: En dan, als we nadenken over de gebruikerservaring en hoe Slim kan leiden tot een betere gebruikerservaring. Als we aan LOD denken, denken we aan cloudtranscodering. Als we aan Slim denken, denken we aan streaming in vergelijking met Roblox vandaag of een jaar geleden, hoe. Hoe kan dit de gebruikerservaring beïnvloeden? 

Tsvetan: Ja, dus Slim, eh, we hebben Slim gebouwd met het idee dat, eh, we de ontwikkelaars in staat stellen om rijkere en grotere, complexe werelden te creëren die, eh.

Eh, zich gedragen en interactie hebben met de eindgebruiker. Siemens? Eh, ja, heel gemakkelijk. Zonder, eh, en de eindgebruiker, eh, de gebruikerservaring is precies hetzelfde als wanneer je de, eh, krachtigste machine hebt. En, eh, Slim is, eh, dit systeem dat vandaag de dag, eh, statische modellen mogelijk maakt. En we zijn, eh, je weet wel. In de toekomst avatars en dynamische modellen mogelijk maken die, eh, hiërarchisch worden gegenereerd, eh, zodat we, eh, het systeem zo snel mogelijk kunnen maken voor de eindgebruiker, 

Dave: wat voor de eindgebruiker misschien rijkere werelden op goedkopere apparaten betekent.

Misschien op mijn low-end telefoon. Ik kan met jou spelen op jouw gaming-pc. Eh, makers kunnen hogere, eh, zich geen zorgen maken over het aantal lagen kleding op een avatar. Complexere voertuigen, eh, ingewikkeld. Eh, mechanische objecten worden ook gecomprimeerd door Slim, wat echt heel gaaf gaat worden.

En dan. Eh, misschien eens nadenken over hoe ze, hoe ze samenwerken. We hadden het dus over cloudtranscodering, eh, dus het aanbieden van een lagere LOD. Toen hadden we het over Slim, wat echt lichtgewicht modellen zijn. Werken ze samen? 

Varun: Helemaal juist. En dat is wat ik bedoelde met dat toegangsding. Dus alle Slim-modellen doorlopen ook precies dezelfde cloudtranscodering-pijplijn.

Want zodra je ze samenvoegt, en zodra slim is, wordt op basis van de context en op basis van de inhoud bepaald wat de samenstelling zou moeten zijn. Het doorloopt dezelfde transcoderingpijplijn en genereert vervolgens een versie van lage kwaliteit, een versie van hoge kwaliteit, een Android-versie en een iOS-versie voor alles.

Dus het is, het is, het is heel, heel complementair, eh, tussen, 

Dave: en dus is dat voor de maker eigenlijk bijna een dubbele klap, een zeer gecompliceerde avatar op afstand samengevoegd tot een slim-model, en vervolgens getranscodeerd. Die avatar zou, nogmaals, uit 12 driehoeken kunnen bestaan en uit één kleur. En, en wat 

Varun: je zou hopen te zien, of wat ik zou verwachten te zien, is een soort eerste stap.

Alle bestaande ervaringen kunnen gewoon op steeds goedkopere apparaten gaan draaien. 

Dave: Ja. 

Varun: Maar het echt spannende zijn de effecten van de tweede orde, toch? Makers beginnen zich te realiseren: oh, ik kan meer dingen in de wereld plaatsen. Oh, ik kan dingen toevoegen. Nou, je denkt 

Dave: erover na, eh, als ik een video maak. Het is bijna alsof de camera behoorlijk grondig is ontworpen.

Weet je, ik pak mijn 4K-camera en ik maak me nooit zorgen, waar ik de camera ook op richt, of ik een filmpje kan maken zoals ik dat doe. Maar onze makers hebben die camera vandaag de dag niet. Stel dat ze de camera op de verkeerde plek richten. De wereld zou wel eens kunnen ontploffen, toch? Zoals te veel resolutie, bijvoorbeeld als ze de camera op een menigte van 10.000 mensen richten, is het alsof... dus dit is bijna alsof je de meeslepende 3D-camera vrijmaakt, 

Varun: maar het geeft makers vrijheid.

Dus we kunnen platformuitbreiding doen en dan genre. Ja, 

Dave: en, en ik denk echt dat er een moment komt, we weten alleen niet wanneer, dat het een mix is van de wet van Moore, Slim 3D, streaming AI, lokale tech upscaling, wat dan ook. Waarbij deze camera misschien geen beperking meer is, waarbij als je honderdduizend mensen in een gigantisch stadion wilt, fotorealistisch rondhangend met je vrienden, gestreamd op een low-end apparaat met lage latentie, dat gewoon goed voelt.

Dat zal, denk ik, zijn wanneer we zeggen dat de immersieve 40-camera volwassen is; het, eh, goede nieuws of het slechte nieuws is dat er nog veel werk te doen is. Dus dat maakt ons werk best interessant. En ik, ik denk dat ik, in het kader van wat de, hoe snel we op weg zijn naar die ultieme drie- en vierdimensionale camera, eh, Sergei, wat is de volgende stap voor Slim en zo, wat zouden we hierna optimaliseren?

Dus 

Sergey: voor Slim, eh. Er liggen een paar grote stappen voor ons. Dus de allereerste stap is om Slim volledig dynamisch te maken, zodat het avatars, bewegende voertuigen, bewegende mechanismen en al dat soort dingen ondersteunt. Maar de belangrijkere stap daarna is om Slim hiërarchisch te maken, zoals Barron al zei, want Slim genereert vrijwel dezelfde assets als gewone assets.

Ze doorlopen precies dezelfde streaming-pijplijn. We optimaliseren ze omdat elk Slim-model zijn eigen eigenaardigheden heeft, en zo. Maar stel dat we nog een stap verder kunnen gaan, stel dat we meerdere Slims kunnen combineren tot één, zeg maar, een mega-Slim, en dat dan steeds weer op een fractalachtige manier.

Dave: Dit was dus een deel van onze ontwerpvraag. Want toen je, ik stelde slim oorspronkelijk voor, keken we naar avatars en hadden we een apart project. We dachten na over hoe je honderd avatars bij elkaar zou zetten en hoe we honderdduizend mensen in een stadion zouden simuleren. En wat echt fascinerend was, was die dag waarop je zei: weet je wat, we kunnen misschien slanke avatars nemen en er dan honderd in een verzameling van honderd avatars stoppen met precies dezelfde technologie.

En dat is een beetje wat we zeiden. Ben je onder de indruk van die hiërarchische aard? 

Sergey: Eh, ja, eh, dat klopt precies. En als je dit voorbeeld helemaal doorvoert, kun je je voorstellen dat je met onze virtuele camera de hele planeet kunt zien. We zien dus de hele planeet en het is net, weet je, een bol, met de textuur.

Als de camera dichterbij komt, zie je afzonderlijke continenten, en dan zie je afzonderlijke steden en dan kun je helemaal naar beneden gaan, bijvoorbeeld naar het stadion vol met mensen, omdat we de hele simulatie op de server draaien en de client niet alles hoeft te weten over de hele wereld.

Het is duidelijk, weet je, je kunt deze hele planeet niet in het geheugen van een apparaat kwijt, zelfs niet op een krachtige pc. Maar onze servers zijn erg krachtig en door deze soort sleutelrepresentatie te genereren voor slim, kunnen we van een planetaire schaal helemaal naar beneden gaan naar bijvoorbeeld kamerschaal, of zelfs microwereld.

Dave: Nou, klopt. We kunnen helemaal afdalen naar het horloge dat jij of ik dragen, naar het kleine knopje op het horloge kijken en zelfs nog verder dan dat. En dus, als we hierover nadenken, Satan, hoe zou dit kunnen veranderen wat makers gaan doen? Juist. We gaan, hopelijk, afrekenen met het, oh mijn god, ik moet me zorgen maken over de prestaties van een avatar.

Zijn er nog andere veranderingen die we volgens jou zouden kunnen zien? 

Tsvetan: Dit zal, naar mijn mening, alle beperkingen wegnemen die ze vandaag de dag hebben. Ze hoeven, zoals je al zei, niet na te denken over hoe complex de wereld is die ze creëren. Ze hoeven alleen maar na te denken over wat ze als speldynamiek aan hun spelers willen presenteren.

Niets anders. Al het andere wordt automatisch door ons afgehandeld. 

Dave: Goed dat je daar even op ingaat. Weet je, in het oude, traditionele Roblox hadden we iets dat we een textuuratlas noemden. We hadden eigenlijk een sjabloon voor een textuur, en je moest het zelf uitzoeken. Ik neem aan dat dit met een slim model volledig automatisch gaat.

Zoals het genereren van die textuur op een lagere resolutie. 

Tsvetan: Ja. Dat gebeurt automatisch, net als het bepalen van die, eh, bouwstenen die Sergei uitlegde in de hiërarchische dynamische wereld. 

Dave: Oké, dus nu, eh, nu gaan we echt versteld staan en gaan we het hebben over, eh, het is makkelijk om je voor te stellen dat iets eenvoudiger is, toch?

Het is bijna alsof je een kunstenaar bent, het is heel makkelijk voor te stellen. Het grover maken en iets afvlakken, het is veel moeilijker om je voor te stellen dat iets een hogere resolutie krijgt. En dus wil ik, ik wil een beetje ingaan op, eh, de toekomst van AI en daar wordt op dit moment veel werk verzet op het gebied van AI, zoals hoe we videogames gaan genereren en realtime meeslepende streaming en wereldmodellen en dat alles.

Eh, en ik, ik. Ik heb steeds meer het gevoel dat we zullen ontdekken dat dit geen monolithisch iets is. Dit wordt een stapel van 3, 4, 5 of zes modellen die allemaal samenwerken, inclusief, je weet wel, een commandoregel waar we, als we wat rondhangen, net als bij 4D, gewoon kunnen zeggen: "Verander het Washington Monument in Godzilla", en boem, het gebeurt ter plekke.

Eh, en uiteindelijk objecten of werelden of complete games genereren. Eh, en hopelijk in een multiplayer-context. Dus we lopen samen rond, met z'n vieren, en we zeggen: "Hé, daar, wij vieren willen graag een nieuwe game ontwerpen en die dan op magische wijze laten verschijnen." Er is een secundair aspect. Eh, naast Command Prompt en World Gen en 3D, wat je net zei, eh, is er Upsampling en, en dat, eh, als ik me soms het klassieke Crossroads voorstel, een 20 jaar oude game op Roblox, dan is er eigenlijk genoeg informatie aanwezig.

Als we klassieke Crossroads zouden nemen en Sergey, je zei, maak dit er zo uit te zien. Zoals een fotorealistische, middeleeuwse versie waarbij de gameplay hetzelfde zou kunnen zijn. De, je weet wel, de, al die leuke kleine raketwerper-tools zijn hetzelfde, maar ineens ziet alles er anders uit. Dus hoe zou dit in de context werken?

Ik weet niet wie hierop wil ingaan. Over LOD, want nu moet LOD omhoog in plaats van omlaag. 

Varun: Ik denk dat een van de punten die Sergey eerder maakte, klopt? Het gaat erom zoveel mogelijk van de oorspronkelijke artistieke intentie te bewaren, zodat we dit soort dingen in de toekomst kunnen doen. En, en mijn favoriete voorbeeld, en dit is een willekeurig voorbeeld, maar stel je voor dat ik een textuur gebruik, maar die textuur was eigenlijk een foto die iemand nam, als ik daadwerkelijk het diafragma had opgeslagen.

De grootte, als ik de f-stop had opgeslagen toen die foto werd genomen. Nu heeft mijn Uprising-algoritme zoveel meer context. Ja. Als ik weet waar die textuur wordt gebruikt, als ik weet dat die wordt gebruikt op een kasteel, wordt die dan gebruikt op de vloer? Mijn Uprising-algoritme kan zo veel slimmer zijn in het maken daarvan en het behouden van de oorspronkelijke intentie van de maker, helemaal tot op die high-end pc of een toekomstige pc die nog niet eens is uitgevonden.

Dus 

Dave: we hebben dit laten zien op RDC, ik denk dat we een video van ongeveer 15 seconden hebben laten zien waarin Crossroads werd opgeschaald. Eh, kun je, laten we het hebben over wat er daadwerkelijk zou kunnen gebeuren. De assets staan in de cloud, de 3D-objecten, de texturen. Eh, er wordt een extra prompt naar ons contentsysteem gestuurd die zegt: kijk, al deze assets maken deel uit van, eh, wat een veel fotorealistischer middeleeuwse wereld zou moeten zijn dan men zich kan voorstellen.

Vervolgens worden al die verschillende LED's opnieuw gegenereerd om veel dichter bij de fotorealistische versie te komen door middel van wat we een 3D UPS-sampler of eigenlijk een 3D generatieve creator zouden noemen. Dus, eh, wie wil er dieper ingaan op wat er bijvoorbeeld met het kasteel zou kunnen gebeuren? 

Sergey: Ik, ik, ik denk net als wat Baron net zei, weet je, het lijkt alsof we zoveel meer semantische informatie uit die wereld vastleggen.

Dat is echt heel belangrijk. Neem bijvoorbeeld dit kruispunt, oké? Als je naar het kasteel kijkt. Eh, vanuit mijn perspectief van individuele assets, gewoon, je weet wel, een aantal blokken, zijn het gewoon dozen. En je hebt niet genoeg context, dus je kunt die blokken er niet beter uit laten zien.

En het kasteel is gewoon, eh, het is meer dan alleen maar afzonderlijke blokken. Het is een som daarvan. Eh, en Slim, aangezien Slim in deze context werkt, is Slim zich bewust van dit ding, als geheel. Dus, en nu zal elke assemblage veel meer weten over, je weet wel, het kasteel als geheel, niet over afzonderlijke objecten.

Dus, dus het kan een veel betere versie maken van dat opgeschaalde kasteel, omdat het, het begrijpt gewoon dat 

Dave: en, en, en in zekere zin zou je je kunnen voorstellen dat het kasteel van Crossroads niet eens bestond. En even voor de duidelijkheid: Crossroads is een heel oud, blokkerig ogend Roblox-spel.

Dat kasteel is eigenlijk een heel goed hulpmiddel voor de prompt. Bouw me een kasteel. Dat is een vrij open prompt. We krijgen dan een willekeurig kasteel met een willekeurige vorm. Maar het kasteel in Crossroads, de afmetingen ervan, dat is allemaal goede informatie voor de prompt om te upscalen naar een kasteel van echt hoge kwaliteit.

Sergey: Eh, ja. Eh, dat klopt precies. Dus omdat, eh, dit 3D-gedeelte van het kasteel, ten eerste heel belangrijk is vanuit gameplay-perspectief, toch? Je kunt dus niet zomaar een willekeurig kasteel genereren en het laten werken voor het spel. Eh, omdat. Maar als je alle dimensies kunt vastleggen, zoals alle, je weet wel, semantiek, in alle contexten, zoals in wat, eh, dat is gebruikt, dan kun je het heel efficiënt opschalen.

En je zult je game hierdoor niet kapotmaken. Want dit is nog iets heel belangrijks. Je wilt geen asset upscalen die je game onspeelbaar maakt. 

Dave: Nou, ik denk dat er een toekomstige wereld is waarin je, naast al je 3D-informatie, ofwel je 3D-informatie kunt bewerken, ofwel je prompt.

Ze komen allebei samen om die wereld te genereren, zodat. De update van vijf seconden waar we het over hadden, wat een asset-wijziging in de toekomst is. Het kan een prompt-update van vijf seconden zijn en een beetje meer hint in de prompt. En dan die wereld op aanvraag genereren. En, en dan denk ik dat er nog één laatste, eh, als we nadenken over alle dimensies van hoe AI samen kan komen om deze dingen fotorealistisch te maken, dan zijn we dat niet.

Er is nog een laatste laag, namelijk de 2D-laag. Wat gebeurt er op je gaming-pc? Wat zou er gebeuren in een of ander videoapparaat in de cloud waar nog hogere upsampling kan plaatsvinden? Dus, eh, bijvoorbeeld, perfect haar op mijn hoofd. De beste plek om dat haar te doen is misschien lokaal met een 2D-upsampler. Ik weet dat je aan veel games hebt gewerkt die proberen haar in 3D te doen.

Wat denk je, zal al het haar op een dag met 2D-upsampling worden gedaan of wordt het 3D-haar? 

Sergey: Ja, absoluut. Ik denk dat we die kant opgaan, omdat sommige dingen alleen in de schermruimte kunnen worden gedaan, omdat dat efficiënter is. Laat ik het zo zeggen: het is efficiënter om het in de schermruimte te doen.

Bijvoorbeeld, zoals dit, eh, zoals haar, zoals rendering, toch? Dus, en zoals, of. Veel game-engines werken tegenwoordig met ML-gebaseerde upsampling, zoals, eh, van 1080p naar 4K gaan. Maar je kunt veel meer doen dan dat, toch? Je kunt de schaduw aanpassen, je kunt, eh, het uiterlijk van dingen veranderen.

En als je dit voorbeeld tot het uiterste doorvoert, kan een game-engine gewoon, weet je, bepaalde semantische informatie renderen, zoals voor een ML-algoritme, en dan zal dit ML-algoritme, weet je, mooi haar genereren, of mooie materialen. Zoals in de sprint-ruimte, de richtlijn.

Dave: Supergoed. Eh, dus dan, en dan nu we afronden, misschien voor alle C++-programmeurs daarbuiten, de assemblagetaalprogrammeurs, wat, eh, ik, ik wou dat ik dat was, dat is een van de leukste dingen ter wereld. We doen hier iets heel moeilijks, toch? We proberen, eh, al deze technologieën op alle apparaten te laten draaien.

Vraag over transcodering. De vraag over transcodering is: ik weet dat veel pc's optimalisaties hebben, eh, met SIMD-registers en dat soort dingen om deze dingen sneller te laten draaien. Zijn we al begonnen met het verkennen van SIMD in een van onze transcoders, of is dat een optimalisatie voor de toekomst? 

Tsvetan: Eh, allereerst, trouwens, transcodering kan tegenwoordig ook op de engine draaien.

Oké. Uitstekend. Goed. We maken dus gebruik van CMD-optimalisaties, maar we kijken nog verder dan dat door gebruik te maken van GPU's en, eh, andere, 

Dave: dus transpo Oké. Transcoderen op GPU's komt er mogelijk aan. 

Tsvetan: Nou, ja, we zijn ermee bezig. 

Dave: Oké. Dat is super, super leuk. Oké, dus, eh, geweldige update iedereen, eh, eh, voor degenen die visueel willen, mogelijk RDC, presentatie op het hoofdpodium.

Ik denk dat we dat moeten doen, we hadden hier veel beeldmateriaal van. Alles waar we het over hebben gehad, zit in de pijplijn. Eh, we houden het nauwlettend in de gaten en ik, ik, ik denk echt dat, eh, jullie allemaal en de verschillende teams achter jullie echt bijdragen aan wat ik soms 'game engine 2.0' noem, eh, wat sterk cloudgebaseerd is.

Sterk ondersteund door Transcoders in al deze technologie. Dus bedankt allemaal. Ik denk dat we iedereen vandaag versteld hebben doen staan. Ik waardeer het echt. 

Tsvetan: Bedankt. 

Dave: Oké, hallo, dit is Dave. Eh, nogmaals, tech talks en we kijken ernaar uit om jullie de volgende keer weer te zien. Bedankt namens het hele team. Bedankt.