Zdravím všechny!

Všem, kteří nám pomohli se zátěžovým testem, chci osobně poděkovat. Na test dohlížel celý WoW Classic team a vážně jsme si užili spolupráci s vámi.

Zde je pár detailů ohledně testu.

Co jsme viděli

Mnoho lidí se ptalo, zda bude výkon hry stejně špatný i na live serverech. Někteří si dělali srandu, že AQ je připravené a že to můžeme vydat. Nebo si nedělali srandu? Koneckonců, výsledek zátěžového testu byl velmi podobný otevírání AQ v původním WoW v roce 2006. Měli jsme spoustu lagů, několik pádů serveru, a když to hráči postupně vzdávali a populace na serveru se zmenšila, event nakonec doběhl do zdárného konce. Na live serverech plánujeme, že vše bude v lepším stavu, ale již teď víme, že lagy se nám nepodaří zcela eliminovat.

Speciálně chci poděkovat všem, kteří zůstali zaseknutí při přistávání lítáka. Našli jsme příčinu a opravili jsme ji. Stejně tomu bylo i u dalších problémů, a když jsme našli příčinu, bylo snadné ji opravit. Nakonec se ukázalo, že se problémy řetězily, oprava jednoho vyřešila další. Všem, kteří viděli geometrický salát při přistávání: děkujeme! Všem jste vylepšili zážitek ze hry.

Pokud jste vydrželi až do 17:00 PDT (02:00 CEST), tak jste si mohli všimnout, že testovací podmínky došly do bodu, který očekáváme v live verzi hry. Nemáme na výběr, musíme se rozhodnout mezi lagy, nebo hustotou hráčů. Čím více hráčů, tím větší jsou lagy. Když už je hráčů příliš, jsou lagy tak veliké, že si servery myslí, že jsou přetížené, a samy se restartují.

Restart, protože si server myslí, že je přetížen, je pádem, který představuje speciální výzvu. Pády nastanou, pokud se program snaží udělat něco vážně špatného, takže jsme našli onu špatnou věc a opravili ji. Přetížení jsou výzvou, jelikož ve skutečnosti na pozadí není žádný problém, jen se vykonává více a více instrukcí. V tomto směru máme ještě spoustu prostoru ke zlepšení.

Hustota hráčů

Náš hlavní problém je exponenciální škálování. Představte si, že Blizzard zasáhne 10 hráčů. Každý z nich dostane speciální auru zpomalující pohyb (máte vytalentovaný Improved Blizzard kvůli lepšímu zpomalení, že?). Za každého zpomaleného hráče pošle server zprávu všem hráčům poblíž. Zpráva obsahuje notifikace o aplikované auře. To znamená 100 zpráv. 10 hráčů si mezi sebou pošle 10 zpráv. Od každého jednoho hráče jde jedna zpráva k tomu, kdo seslal Blizzard, a jedna zpráva ke každému, kdo je Blizzardem postižen.

Pokud by Blizzard zasáhl 20 hráčů, bylo by to 4x více zpráv. Pokud by zasáhl 40 hráčů, znamenalo by to 1 600 zpráv. Dvojnásobek hráčů znamená 4násobně více práce pro server. Zvýšit počet hráčů z 10 na 100 znamená nárůst zpráv ze 100 na 10 000, a to jen kvůli jednomu kouzlu. Máme výkonný hardware, takže musíme zjistit, kolik hráčů může být na jednom místě bez toho, aby byl server přetížený, což bylo hlavním cílem zátěžového testu. Máme z toho velmi dobrá data, jelikož se připojilo velmi mnoho hráčů.

Optimalizace kódu

Kód optimalizujeme už od roku 2004, v poslední době děláme optimalizace jen kvůli jedinému eventu. Zde je pár příkladů z poslední doby.

Nejprve zpomalující aura. Co kdybychom neposílali všechny zprávy ihned? Pokud zasáhnete 100 hráčů jedním Blizzardem, musíte každou sekundu vědět, že každý z těch 100 hráčů má zpomalující auru? Server to ví hned, že aura funguje, a zpomalí pohyb hráčů, ale co kdybyste neviděli auru sekundu či dvě po jejím aplikování, bylo by to OK? Pokud by to mělo znamenat, že server nespadne, je naše odpověď "ano", takže jsme nastavili odložené odesílání zpráv o aurách. Mělo to další plus: než se odešle zpráva o auře a mezitím hráč dostane další, můžeme obě poslat v jedné zprávě, čímž se sníží počet odeslaných zpráv. V konečném důsledku se odesílá méně packetů po síti a server vykonává méně práce.

Další věc, kterou jsme testovali, je facing, tedy směr, kterým se hráč dívá. Co kdybychom zpomalili, nebo zcela zastavili facing zprávy, když populacee na serveru dosáhne určité hodnoty? Cena za tuto optimalizaci je velmi malá: vypadá to, jako by hráči poskakovali, když se pohybují. Když je daná oblast přelidněná, tak jako tak hráči poskakují, takže to pro nás znamená obrovský nárůst výkonu bez žádného vizuálního efektu. Myslím si, že s touto optimalizací hráči méně poskakovali, než kdyby tato optimalizace byla vypnutá.

Taktéž jsme vylepšili optimalizaci při rozhodování, komu odeslat zprávy. Když je v jedné oblasti několik tisíc hráčů, pouhopouhé rozhodování o tom, kdo musí vědět o vašich aurách a kam se hýbete, je spousta serverové práce, takže jsme vylepšili i toto.

Pohyb hráčů

Když se nám povedlo vyřešit přecházející problémy, museli jsme rozhodnout o pohybu hráčů. Když se otevíralo AQ v roce 2006, museli Game Masteři ručně teleportovat hráče pryč ze zóny, aby mohl event pokračovat. Později byl tento proces automatizován. Dnes máme velmi dobře fungující automatické teleporty. Využíváme je, abychom kontrolovali populaci zóny na určité úrovni a hra byla podle hráčů i nadále hratelná. Silithus bude stoprocentně zalagovaný, ale radši budeme teleportovat hráče pryč, než mít spadlé servery.

Tento event se odehrává na jižní části Kalimdoru, takže pokud se nedostanete do Silithusu, ještě to neznamená, že vám event utekl. Deset hodin po zaznění gongu budete moci zabíjet Anubisathy a Silithidy v Tanarisu, Thousand Needles, Feralasu a Barrens.

Ještě jednou

Test nám dal docela jasnou představu o tom, jaké máme mít nastavené limity, jak obnovit servery po pádu, ale i přesto bychom chtěli vědět víc. Proto chystáme další test na čtvrtek 25. června v 3:00 PN PDT (půlnoc na 26. června našeho času, pozn. red.). Tentokrát bychom chtěli test ukončit rychleji, jelikož předpokládáme méně prošetřování a méně narušení stability.

Doufám, že vás tam uvidíme všechny.

P.S.: Lethon si dal vaše duše s houbama.