Massiv (systém pro tvorbu online her)

Cíl projektu

Cílem projektu Massiv bylo naprogramovat distribuovaný systém založený na architektuře klient-server, který by umožňoval herním vývojářům vytvářet tzv. "online (internetové) hry".

Společným znakem takovýchto her (označovaných jako MMO - massively multiplayer online hry) je perzistentní svět, ve kterém se pohybuje větší množství aktivně připojených hráčů, jejichž počet může jít řádově do tisíců. Svět je simulován 24 hodin denně na jednom nebo více serverech, hráči se k nim mohou kdykoliv připojit. Po odpojení hráče se jeho postava většinou dění ve světě neúčastní, ale zachovává si svoje vlastnosti a majetek.

Massiv systém poskytuje programové prostředky pro vytváření MMO her a objektový model pro distribuovanou simulaci odpovídajících světů.

Proč má Massiv smysl

MMO hry zažívají v posledních letech velký rozmach a objevuje se mnoho nových online her. Vývoj MMO hry je však velice náročný, protože dříve, než je možno vytvářet vlastní hru, je nutno naprogramovat základní jádro systému. Z charakteristik a požadavků MMO her však takový systém musí poskytovat velkou škálu služeb a pokrývat mnoho programových oblastí, a proto je vývoj takového systému náročný jak na vynaložené prostředky, tak na čas. Z těchto důvodů je vývoj MMO her velice složitý pro nezávislé či nevýdělečné vývojové týmy. Našim cílem bylo vytvořit systém pro tvorbu MMO her, který by byl dostupný pro obecnou komunitu vývojářů a byl by dostatečně obecný pro co nejvíce žánrů her.

Od začátku vývoje byl Massiv koncipován jako objektově orientovaný systém. Objekty se jeví jako vhodné řešení dané problematiky a téměř každý programátor je s objektovým přístupem dobře obeznámen.

Zde je uveden základní přehled charakteristik a služeb, které musí takový system splňovat a poskytovat. Jedná se současně o oblasti, které jsou pokryty systémem Massiv:

Komu je Massiv určen

V oblasti MMO her je velice častá situace, kdy nezávislí vývojáři spravují určitou hru jen pro vlastní zábavu a tudíž bez jakýchkoli finančních prostředků. Pro takovéto vývojáře samozřejmě kompletní vývoj MMO hry pro svou složitost nepřipadá úvahu a proto většinou upravují již existující MMO hry. Projektem Massiv jsme se snažili poskytnout těmto vývojářům systém, který by splňoval výše uvedené požadavky.

Při navrhování Massivu jsme se zaměřili převážně na takovouto cílovou skupinu nezávislých vývojářů s vědomím, že pokud nějaká firma bude vytvářet MMO hru, dá spíše přednost vývoji vlastního systému, který si sama zaplatí, např. proto, aby měla nad výsledkem větší kontrolu.

Jelikož nezávislí vývojáři většinou nemají možnost provozovat simulaci světa na množině serverů běžících v privátní lokální síti, která by byla oddělena od internetu a umožňovala připojení k serverům jako k celku, rozhodli jsme se, že budeme přepokládat, že simulace poběží na serverech, které budou rozmístěny v různých částech internetu. To vyžadovalo rozšíření o níže uvedené požadavky na servery a tyto požadavky jsou současně jednou z hlavních oblastí, ve které se Massiv liší od jiných podobných systémů:

Asi nejdůležitějším důsledkem je to, že se Massiv nesnaží za každou cenu distribuovanost před programátorem skrývat. Naopak, k optimálnímu využití systému Massiv by programátor měl plně využít ty vlastnosti Massivu, které mu umožňují provádět operace lokálně s minimální režií v porovnáním s běžnou aplikací běžící na jednom počítači. Mezi takové vlastnosti Massivu patří replikace (možnost pracovat s read-only kopiemi nelokálních objektů) a migrační resp. replikační skupiny (pomocí speciálních atributů ukazatelů lze zajistit, že odkazovaný objekt bude vždy lokální a lze s ním pracovat přímo).

Co je součástí Massivu

Massiv lze rozdělit na dvě hlavní části, které získá vývojář, pokud se rozhodne tento systém využít:

Vývoj jádra a jeho vlastností - proč a jak

V této kapitole je uvedeno, jak se vyvíjel návrh hlavních oblastí pokrytých jádrem Massivu, jak se měnil v průběhu projektu a případně proč bylo nutné provést některé změny od původní specifikace.

Demo

Demo je ukázková aplikace vytvořená nad jádrem Massivu. Demo využívá všechny prostředky, které jádro Massivu poskytuje, a pomocí nich implementuje a ukazuje řešení základních situací a problémů, které musí vývojář při psaní distribuované hry řešit. Hlavním účelem dema je poskytnout potencionálním vývojářům základní odrazový můstek, kde mohou začít s vývojem vlastní hry, a prezentovat všechny jádrem nabízené funkce a možnosti, jak je využít ve svůj prospěch.

Původní idea byla, že demo bude malá a jednoduchá ukázková RPG hra. Tato idea se ale ukázala hodně nadsazená. Ať je hra jednoduchá či složitá, množství věcí, které se musí naprogramovat, je velmi velké, a zvláště v případě, když se jedná o distribuovanou hru. Původní cíl, tedy napsat základ konkrétní hry ve stylu RPG, ve kterém by případně šlo po dokončení projektu pokračovat a vytvořit z něj hru se vším všudy, jsme brzy opustili.

Při psaní dema jsme se proto soustředili na dvě věci: Naimplementovat ty části MMO systému, které se pravděpodobně objeví v každé hře tohoto typu a nad tím vystavět jednoduchou pseudohru. S postupem prací vznikla z dema určitá ukázková aplikace, takový balík poznatků, principů a řešení problémů, které se pravděpodobně objeví, pokud by se někdo pokoušel vytvořit vlastní MMO hru; nikoliv hra samotná. Ač se jádro Massivu pokouší maximálně zjednodušit práci v distribuovaném prostředím, přeci jen je některé věci nutno řešit trochu jinak, než by se řešily v nedistribuovanén případě.

Všeobecně použitelná část dema mj. zahrnuje:

Ukázková hra implementuje:

Dále klient implementuje spoustu věcí, které nedemonstrují vlastní použití Massivu, ale jsou nutné pro jeho funkčnost. Sem patří mimo jiné poměrně mocný renderer používající OpenGL (i když samotná hra moc efektně nevypadá), GUI a podobně. Všechna data klienta (především textury a modely) jsou implementována jako datový objekt spravovaný data managerem. Díky tomu může být klient spuštěn s minimalními základními daty a vše potřebné se za běhu stáhne automaticky.

Hardwarové a softwarové požadavky

Jádro massivu lze zkompilovat a provozovat pod systémy Linux a Windows (předpokládají se ovšem alespoň Windows98). Na těchto platformách bylo také otestováno.

Přenos na jiné systémy by neměl být problém, všechny části kódu závislé na operačním systému jsou speciálně odlišeny od ostatního kódu a jejich úprava pro jiný systém, pakliže je možná, by měla být přímočará.

Dále je Massiv konstruován tak, aby jen s minimálními obtížemi mohl být zprovozněn na počítačích typu big endian (zjednodušeně - "nižší" byty vícebytových slov jsou uložena v paměti na vyšších adresách). Bez zásahů do kódu ovšem pravděpodobně na těchto systémech v současnosti fungovat nebude, protože jsme neměli možnost jej na nich testovat. Podporovány jsou tudíž pouze little endian systémy (tj. "nižší" byty vícebytových slov jsou uložena v paměti na nižších adresách), testována však byla pouze platforma x86.

Vlastní demo také funguje jak pod Linuxem tak pod Windows (s omezeními uvedenými výše).

Hardwarové požadavky shrnuje následující přehled:

Minimální hardwarová konfigurace:

Simulační server:
procesor Pentium II, Duron, Athlon nebo jiný kompatibilní procesor (alespoň 400Mhz)
32MB RAM
síťová karta

Klient:
procesor Pentium II, Duron, Athlon nebo jiný kompatibilní procesor (alespoň 400Mhz)
32MB RAM
grafická karta 2MB podporující 16 bitové barvy
síťová karta

Datový server:
procesor Pentium I, Duron, Athlon nebo jiný kompatibilní procesor (alespoň 60Mhz)
32MB RAM
síťová karta

Doporučená hardwarová konfigurace:

Simulační server:
procesor Pentium III, Duron, Athlon nebo jiný kompatibilní procesor (alespoň 1Ghz)
64MB RAM
síťová karta

Klient:
procesor Pentium III, Duron, Athlon nebo jiný kompatibilní procesor (alespoň 1Ghz)
64MB RAM
grafická karta s hardwarovou akcelerací OpenGL
síťová karta

Datový server:
procesor Pentium II, Duron, Athlon nebo jiný kompatibilní procesor (alespoň 300Mhz)
32MB RAM
síťová karta

Co šlo dobře

Abstrakce doručování zpráv.
Objektový model byl navržen tak, aby smazal rozdíl mezi objektem a zprávou. Jakákoli zpráva je současně také objekt a také jakýkoli objekt může být poslán jako zpráva k nějakému jinému objektu. To umožnilo jednotný systém při migracích objektů a doručování zpráv. Současně se tím zjednodušila archivace simulovaného světa (zprávy se jako jiné objekty také normálně archivují).

Asynchronní a synchronní RPC.
Původně se předpokládalo, že veškerá komunikace mezi simulovanými objekty se bude řídit explicitně pomocí doručování jiných objektů, které budou vytvářeny programátorem. Do Massivu jsme ale nakonec přidali automatickou podporu pro asynchronní a dokonce synchronní RPC (vzdálené volání metod). Jak se ukázalo, byl to krok správným směrem a jednoduchost použití RPC nakonec způsobilo, že se RPC využívá skoro všude a není nutno využívat jiných prostředků pro komunikaci. Díky tomu, že je RPC vystavěno nad migrací objektů, nebylo nutno posílání a archivaci RPC požadavků implementovat speciálním způsobem.

Plné využití standardu C++.
Velkým přínosem se ukázalo využití prostředků C++, se kterými měli členové týmu před započetím projektu pouze minimální praktické zkušenosti. Jedná se především o vyjímky, templates, STL (Standard Template Library) pro základní datové struktury a využití iostreamů pro vstup a výstup, včetně implementace vlastních tříd kompatibilních s iostreamy pro práci s archívy. Využití STL knihovny bylo daleko větší, než se původně předpokládalo.

Využití externích knihoven.
Pro implementaci síťové vrstvy, především šifrování, se jako velmi dobrá ukázala knihovna CryptoPP. Portabilitě klienta značně pomohlo použití OpenGL pro 3D grafiku a knihovny SDL.

Jednotná pravidla pro layout zdrojových souborů.
Již od počátku projektu byla stanovena striktní pravidla pro formátování, pojmenovávací konvence a styl psaní zdrojových souborů, což se ukázalo jako dobré rozhodnutí a poskytuje celému systému ucelený vzhled.

Co šlo špatně

Doba vývoje.
Dlouhá doba vývoje byla způsobena několika faktory. Hlavním z nich byly personální problémy s aktivitou některých členů týmu (forma projektu a vztahy mezi členy týmu v rámci školy neumožňuje efektivní řízení celého projektu, narozdíl od klasických postupů, které lze aplikovat na vývoj projektů v rámci nějaké firmy, kde lze definovat vztah nadřízený/podřízený a jsou k dispozici prostředky na ohodnocení výkonů podle splnění či nesplnění zadaných úkolů). Dalším důvodem pro dlouhou dobu vývoje byla příliš nadsazená a obsáhlá specifikace projektu, ve které nebyly zohledněny reálné možnosti vývojářského týmu v daném prostředí.

Nepřesný návrh.
Některé části systému nebyly přesně navrženy již v počátku projektu. Kvůli tomu jejich implementace způsobila, že se musely netriviálně upravovat již existující části kódu a změnily se funkčnosti ostatních částí systému. Jiné části systému pak byly zbytečně předimenzovány a poskytují více funkčnosti, než se reálně využívá.

Feature creep.
Přestože specifikace byla již tak dost obsáhlá, nedokázali jsme se ubránit vlastní megalomanii a výsledný produkt obsahuje spoustu kódu, se kterým se zpočátku vůbec nepočítalo. Velká část se ukázala pro výsledek jako velmi užitečná (například synchronní RPC s podporou vyjímek, lokální garbage collector), některé části jsou ale více-méně zbytečné nebo nevyužité (především části dema psané v době, kdy jsme z něj ještě chtěli mít pěknou malou zábavnou hru).

Ladění
Ladění distribuovaného systému se ukázalo jako velice náročné. U takovéhoto systému lze jen ztěží použít klasické debugovací prostředky poskytované kompilátorem. Proto se velmi často ladění programu provádělo přes analýzu debugovacích hlášek a výpisů jednotlivých serverů.

Srovnání s podobnými systémy

Srovnání Massivu s podobnými systémy nelze jednoduše provést. Hlavním důvodem je skutečnost, že jsme nenalezli žádný veřejně přístupný systém, který by poskytoval takové prostředky a byl podobně zaměřen jako Massiv. Existuje několik distribuovaných MMO her, ale jedná se pouze o komerční projekty a tudíž veškeré informace o tom, jak tyto hry interně fungují a nad jakými systémy byly vybudovány, jsou střeženy jako výrobní tajemství. Mimo tyto hry existuje také mnoho jiných her, které se jako MMO označují, ale jsou navrženy pouze pro jeden server a tedy je nelze s Massiv srovnávat.

Nevrax (http://www.nevrax.org)

Při hledání podobného systému jako je Massiv jsme narazili na systém Nevrax, na kterém lze ukázat rozdílnost přístupu k problematice MMO her. Nevrax je opensource projekt, který se prezentuje jako systém pro vytváření MMO aplikací (her).

Zatímco Massiv se zaměřuje primárně na distribuovaný objektový model, kde jednotlivé objekty mohou mezi servery migrovat, Nevrax nahlíží na distribuovanou simulaci jako skupinu procesů (nazývané služby), které jsou rozmístěny na vícero serverů. Např. můžeme mít proces, který se stará simulaci krajiny, jiný proces, který se stará o pohyb entit po krajině, proces pro synchronizaci času, zálohovací proces, atp. Nevrax s migrací těchto procesů nepočítá, místo toho ale může být funkčnost jedné služby duplikována na více serverech a tím také dochází k rozložení zátěže.

Nevrax poskytuje základní komunikační prostředky pro komunikaci mezi procesy založené na posílání zpráv. Podobně jako Massiv poskytuje pro programátora neviditelné vyhledávání objektů, poskytuje Nevrax základní proces pro vyhledávání běžících služeb (naming service), do které se registrují všechny běžící procesy.

Jak již bylo řečeno, Massiv počítá se servery, které mohou být umístěné v různých sítích. Nevrax je vybudován tak, že všechny servery jsou umístěny v jedné lokální síti.

Nevrax neposkytuje žádné prostředky pro replikaci dat. Tyto služby si musí programátor zařídit sám, buď úpravou existujících služeb nebo vytvořením nové replikační služby.

Nevrax podobně jako Massiv zpřístupňuje mnoho pomocných knihoven jako jsou knihovny pro logování, debugování, podpora vláken, knihovnu pro síťovou komunikaci a přenos dat, protokoly na komunikaci mezi servery a klienty a mnoho dalšího.

Zatímco nelze příliš srovnávat princip objektů v Massivu a princip služeb v Nevraxu, lze srovnat jejich vytváření. V Massivu programátor vytvoří objekty jako běžné C++ objekty a jádru Massivu oznamuje strukturu těchto objektů. V Nevraxu se služby implementují pomocí C++ dědičnosti. Nevrax poskytuje základní rozhraní, které musí každý proces splňovat, a programátor pak implementuje metody tohoto rozhraní.


Ostatní

Viz pozadavky komise: jmenny seznam, rozdeleni prace, dokumentace vyvojova a uzivatelska, specifikace platformy (HW, OS), installer, sources, utilities.