Vývoj a řízení projektu síťové počítačové hry Aleš Keprt Katedra informatiky, Fakulta elektrotechniky a informatiky VŠB – Technická Univerzita Ostrava 17. listopadu 15, 708 33, Ostrava-Poruba, Česká Republika
[email protected] [email protected]
Abstrakt. Síťové počítačové hry jsou tak běžným typem softwaru, že by člověka ani nenapadlo, jak velké množství obtíží může nastat při jejich tvorbě. . .
Klíčová slova: síťové počítačové hry, multiplayer, objektově orientovaný design, řízení projektu, klient–server
Motto: „Na designování nemáme čas, musíme to rychle naprogramovat.ÿ
1
Úvod
Před několika lety jsem se dostal k úkolu vytvořit multiplayerovou počítačovou hru. Pojmy „multiplayerÿ a „multiplayerová hraÿ se do češtiny obvykle nepřekládají a značí případ, kdy se hry zúčastňuje několik hráčů, kteří hrají na samostatných počítačích propojených v síti (obvykle s využitím internetu, LAN, modemu nebo spojení sériovým kabelem). Tomuto popisu odpovídá drtivá většina v současnosti vyvíjených her, bez ohledu na použitý hardware nebo operační systém, neboť je známým faktem, že nepřítomnost multiplayeru zásadním způsobem limituje komerční úspěch počítačové hry. Opak multiplayeru je označován slovem „singleplayerÿ. Slovo singleplayer vzniklo sloučením termínu „single playerÿ, v překladu znamená „hra jednoho hráčeÿ. Podobně slovo multiplayer vzniklo z termínu „multiple playersÿ. Přestože tyto termíny nezní příliš česky, používají se zcela běžně v české odborné literatuře o počítačových hrách, proto se jich budeme držet i v tomto textu. S ohledem na výše uvedené skutečnosti jistě nepřekvapí, že obsahem dnešních her většinou bývá nějaké ovládání postavy, která soupeří (výjimečně i spolupracuje) s jinými postavami ovládanými ostatními hráči nebo i počítačem (umělou inteligencí). Hra Hidden & Dangerous 2 (viz [4], [5]), na jejíž realizaci jsem se podílel, se týkala bojových operací ve 2. světové válce – hráč měl za úkol plnit různé mise bojové i strategické povahy. Hra je koncipována tak, že pro úspěšné splnění úkolů je dobré postupovat společně v týmu, proto je zde síťová (multiplayerová) část velmi důležitá.
Obr. 1. Logo Hidden & Dangerous 2.
2
Návrh programu s podporou síťové hry
Přestože naše hra byla od začátku tvořena objektově orientovaným způsobem, ukázalo se, že realizace multiplayerové hry není vůbec snadná. Při práci se vyskytla celá řada problémů jak softwarové, tak obchodní povahy, často proti sobě stály názory lidí odpovědných za management na jedné straně a vývoj softwaru na straně druhé, nebo dokonce i názory různých členů týmu programátorů. Dále v textu bude řeč obecně o počítačových hrách moderního typu. Samotný fakt, že různé hry se od sebe mohou po herní stránce hodně lišit, nemá nijak závažný vliv na jejich rozdílnost po stránce vývoje multiplayeru, implementaci síťové komunikace, návrh souvisejících tříd, apod. Vlastnosti počítačových her důležité pro síťovou hru jsou totiž z mnoha důvodů stále víceméně stejné. Odborná literatura uvádí, že z pohledu designu (návrhu) softwaru existují v zásadě dva hlavní přístupy k řešení multiplayeru: 1. S→M (naivní přístup) = nejprve udělat singleplayer, potom přidat multiplayer 2. M-only (systematický přístup) = od začátku se zaměřit na multiplayer a singleplayer chápat jako jeho podmnožinu V případě, že už máme hotovou singleplayerovou hru a pouze chceme doplnit podporu pro multiplayer, je rozhodování jednoduché. Pokud však hru teprve připravujeme, můžeme se vydat oběma cestami. Speciální situací je plánování, když je hra již rozpracovaná v singleplayeru, ale ještě není zcela hotová. Posledně jmenovaná situace by teoreticky při správném řízení projektu a designu ani neměla nastat, v praxi je však běžná. Projekt tvorby počítačové hry má často jen velmi obrysový návrh, a to z několika důvodů: 2
– Převážná část projektu se obvykle týká něčeho, co nikdo z týmu ještě nedělal. V České Republice je obecně nulová zkušenost v oboru vývoje her, takže ani není možno člověka s takovou zkušeností do týmu najmout. – I ten sebelepší návrh je obvykle nutno doplňovat a rozšiřovat doslova za pochodu. Je to důsledek překotného tempa vývoje, jelikož trhem počítačových her sice každoročně proteče obrovské množství financí, dokonce ještě více než např. v televizním nebo filmovém průmyslu, je to však vykoupenou obrovskou konkurencí rychlostí inovací. – Zanedbání příprav projektu z důvodu nedostatečných znalostí objektově orientovaných technologií, obvykle s výmluvou, že vzhledem ke dvěma výše uvedeným bodům by objektově orientované technologie stejně nic nevyřešily. . . – Tým je složen z větší části ze středoškoláků, kteří se již od mládí dlouhodobě zabývali programováním v oblasti her, ale nevědí nic o analýze, designu nebo dokonce řízení projektů. Názory členů týmu na průběžné dokumentování práce jsou často velmi negativní, protože dokumentování jim zdánlivě brzdí práci. (Není návrh, takže se dělá více verzí řešení dílčích problémů, které se nijak zvlášť nedokumentují, protože nikdy nevíte, jestli to celé pak nepůjde do koše. Navíc hra se po dokončení již nemusí nadále udržovat a spravovat jako běžný informační systém.). Tyto metody tvorby počítačových her jsou také obvykle prosazovány manažerem, který se samozřejmě hodně zaměřuje na komerční stránku projektu a zastává názor, že dokumentaci kódu, který ještě ani není vcelku dokončen, nelze nikomu prodat, takže její vytváření je zbytečné. . .
3
S→M přístup
S→M je klasický naivní přístup tvorby multiplayeru, spočívá ve dvou krocích: 1. Vytvoříme kompletní singleplayerovou hru. 2. Do existujícího kódu doplníme podporu multiplayeru. Tento přístup má už na první pohled mnohé kladné rysy. To je pochopitelné, jelikož naivní postupy obecně vykazují kladné rysy „na první pohledÿ a teprve po dlouhodobé práci se mění v noční můry všech programátorů. Pejorativní podtext slova „naivníÿ přitom není na místě, jelikož jednoduché problémy je vždy lepší řešit naivní cestou. (Potřebujeme-li například koupit dva rohlíky, tak jednoduše zajdeme do obchodu. Neděláme k tomu žádné písemné návrhy, dokumentaci, nepotřebujeme ani období prototypů nebo dolaďování řešení. Problém je tedy v určení složitosti úkolu před jeho řešením, abychom zjistili, zda je naivní postup ten pravý.). 3.1
Z čeho vycházíme
Před zahájením prací stylem S→M máme obvykle tuto výchozí pozici: 3
1. Velké úkoly se vždy dělí na menší, aby se tak usnadnilo jejich řešení. Navíc multiplayerová část hry vyžaduje celou řadu specifických prvků, které se v singleplayeru nevyskytují.Proto se nám líbí, že řešení některých problémů se jednoduše odsune na později. 2. Nikdo přesně neví, jak se má multiplayer dělat, a při rychlém rozvoji síťových komunikačních technologií ani nikdo nemá přesný přehled o tom, na čem by se mělo stavět. Během několikaleté práce na projektu se síťové technologie také mohou dosti změnit. 3. Vedení firmy chce mít co nejdříve „hmatatelnéÿ výsledky. Vychází z klasického naivního předpokladu, že když něco máme, je to vždy lepší, než mít pouhé přesvědčení, že existuje nějaké lepší řešení a že je třeba věnovat víc času designu, abychom to lepší řešení našli. 3.2
Jak postupují práce
Naivní S→M přístup vede ke stejně naivnímu používání nevhodných návrhových vzorů. Praxe ukázala, že nejčastějším případem je nepoužívání vůbec žádného návrhového vzoru – původní singleplayerový kód se rozšiřuje pomocí vpisování nových bloků s použitím příkazu if(multiplayermode) {...} a výsledkem je tak kód doslova prošpikovaný různými přívěšky zajišťujícími funkčnost multiplayeru. Tento kód je samozřejmě velmi nepřehledný a náchylný k výskytu chyb. Vývojáři počítačových her jsou totiž experti na DirectX nebo psaní kódu optimalizovaného pro rychlost, méně už na návrhové vzory. Celý tým programátorů se nejprve soustředí na singleplayerovou hru. Po dokončení stěžejních částí projektu (období betaverze), kdy už se programátoři soustředí na kontrolu a odstraňování chyb, mohou začít práce na multiplayeru. Manažer je v zásadě spokojený, protože dostal „brzoÿ svou první funkční verzi hry. Problém nastane v okamžiku, kdy si vedení firmy uvědomí, že vlastně polovina nebo i víc práce je ještě před námi, jelikož nyní se musí všichni vrhnout do vytváření multiplayerové hry. Zde nastávají dvě možné cesty, obě jsou bohužel velmi kamenité. 1. Na multiplayeru se skutečně pracuje až po dokončení singleplayeru. Základní možnou optimalizací je vyčlenění jednoho programátora, který během práce na singleplayeru připraví podklady a obecné podpůrné knihovny pro multiplayer. Tyto knihovny se starají o síťovou komunikaci, ale bohužel nemohou být příliš specifické pro danou hru, protože ta během vytváření těchto knihoven ještě neexistuje. Kritickým bodem této varianty je manažer, kterému budete těžko vysvětlovat, že hra, která v jeho očích již vypadá hotová, je vlastně na začátku práce. Další problém (ale ne větší, protože nic není horší než nepochopení ze stany vedení) je v tom, že ani samotní programátoři si neuvědomují všechny souvislosti. Jsou-li programátoři ponecháni „bez dozoruÿ, inklinují během práce na singleplayeru k takovým řešením dílčích problémů, které jsou pro ně v daný okamžik nejschůdnější, což ovšem prakticky znemožňuje použití 4
daného „kusu kóduÿ v multiplayeru. Nastupují buď všelijaké záplaty a „objížďkyÿ v kódu, které do něj vnášejí opravdový chaos, anebo se pro multiplayer některé pasáže programují znovu a existují pak ve dvou exemplářích. Tyto dvě metody „řešení problémuÿ dílčího algoritmu se pak v projektu prolínají na mnoha místech a často vlastně ani nemůžeme stanovit přesnou hranici mezi nimi (což by samo o sobě stejně nic nevyřešilo). 2. Vyčleněný programátor (M) začne na multiplayeru pracovat ještě před dokončením singleplayeru, v extrémním případě hned od začátku. Tato metoda je vysoce propagována manažerem, protože ten žije v představě, že takto výrazně zkrátí celkový čas prací na projektu, jelikož se bude pracovat paralelně.1 Jakkoli toto na začátku vypadá slibně, v praxi obvykle nastává těžký kolaps. Zatímco tým programátorů pracující na singleplayeru (S) stěží zvládá vlastní termíny, M je neustále nutí k různým úpravám kódu pro multiplayer. Zatímco se totiž M snaží rozšířit multiplayer o nové prvky ze singleplayeru, S tento kód několikrát změní („optimalizujeÿ) a M může začít odznova. Zde samozřejmě nastává otázka, proč M nepočká, až S daný „kus kóduÿ dokončí. Bohužel hry nejsou databáze a tak nikdo nemůže zaručit, že nějaká verze řešení dílčího problému je konečná. Často se musí sáhnout k přepracování i poměrně rozsáhlých dobře napsaných částí programu jen proto, že se na trhu objevila nová kvalitní hra, a požadavky na kvalitu se tak posunuly opět o kus dále. Zde samozřejmě pomáhá vypracování kvalitního návrhu řešení celého programu, ovšem to se zase vůbec neslučuje s naivním přístupem, protože to zdánlivě oddaluje dokončení první hratelné verze i celého projektu. Pokud by měl M čekat až S dokončí singleplayer, tak se dostáváme zpět k bodu 1 a delším lhůtám, kterým jsme se touto druhou variantou chtěli vyhnout.
3.3
Lokální optimalizace
Optimalizací práce na lokální úrovni můžeme dosáhnout toho, že dílčí problémy jsou řešeny jen jednou, čili společně pro singleplayer i multiplayer. Důležitá je zde vůle jednotlivých členů týmu S spolupracovat s M (a obráceně, protože programátoři často rádi věci, kterým rozumějí, píší celé znovu, přestože by mohli použít už hotovou práci svých kolegů). Tímto postupem se ovšem vzdalujeme od původní představy naivního řešení, protože buď postupně vyhazujeme hotový singleplayerový kód a nahrazujeme jej nově vytvářeným tzv. „obojživelným kódemÿ, anebo během tvorby singleplayeru zatěžujeme všechny programátory problematikou multiplayeru a někdy i nekonečnými debatami na toto téma. 1
Chceme-li dostat výpověď, můžeme manažerovi jeho vizi přirovnat k představě, že „Dvacetipatrovou budovu postavíme stejně rychle jako přízemní, když na ni nasadíme 20 týmů, aby každý stavěl jedno patro.ÿ.
5
3.4
Výhody S→M přístupu
Naivní přístup má tyto výhody: 1. První hratelná verze je hotova dříve. To má významný dopad na marketing. Význam hratelných verzí je v herním průmyslu tak vysoký, že často se přistupuje i k tomu, že první hratelná verze je vytvářena zcela nezávisle na tom, jak bude vypadat kód finálního produktu. Cílem je vždy především co nejdříve předložit nějakou hratelnou verzi hry, která je pak základním nástrojem marketingu. 2. Singleplayerová hra je optimalizována sama o sobě, čili hru nezpomaluje vykonávání kódu, který patří jen do multiplayeru. To samozřejmě platí jen při dodržení původního naivního postupu a je to hodně důležité, protože hry vždy doslova bojují s rychlostí hardwaru. 3. Vývoj je jednodušší z toho hlediska, že řešíme singleplayer jako menší problém a na něj teprve nabalujeme multiplayer. Je velmi pravděpodobné, že i kdyby se nám nepodařilo doladit všechny detaily multiplayeru, tak singleplayerová část hry bude mít kvalitu vyšší. 3.5
Nevýhody S→M přístupu
Shrňme si také nevýhody: 1. Celková délka projektu se natahuje. Především při konečné fázi ladění nastává problém vzniklý existencí dvojího kódu. Singleplayer i multiplayer je nutno ladit odděleně. Hry fungují v reálném čase a jejich kód je natolik komplikovaný, že odladění dílčích částí kódu nedává žádnou záruku, že celý produkt bude fungovat tak, jak má. Navíc ladění některých specifických prvků, jako je umělá inteligence, přináší i v singleplayeru nemálo obtíží, v multiplayeru, který je napsán samostatně, to pak stojí ještě o to větší množství času. 2. Mnohé části kódu se dělají dva i vícekrát. Údržba takového kódu je komplikovaná. 3. Vývoj je složitý z toho hlediska, že multiplayer se napojuje na existující singleplayerový kód a není jednoduché rozkrýt všechny jeho skryté vlastnosti, které jeho autoři nezdokumentovali, tak, aby se multiplayer choval vždy korektně. 3.6
„Naivní shrnutíÿ
Je možné, že během práce na projektu začne M inklinovat k „systematickému řešeníÿ, čili začne se snažit nahrazovat dvojitý kód společným. To se samozřejmě nelíbí týmu S, protože jim to komplikuje jejich jinak snadný život. Z vlastní zkušenosti mohu potvrdit, že hlavně v situaci, kdy M je jediný programátor, dochází k častým pracovním i osobním rozporům mezi M a zbytkem týmu. Toto je možné částečně řešit tím, že M dostane vyšší pravomoci, ovšem tím jen naroste 6
problém vyčleňování M z týmu spolupracovníků. M by tedy měl být současně šéfprogramátorem, který je tak jako tak vyčleněn a má vždy rozhodující slovo. Pokud se však šéfprogramátor soustředí na tvorbu multiplayeru, nemůže se již soustředit na jinou důležitou práci. Čili z toho vyplývá, že M by spíš měl tvořit samostatný tým programátorů. Pak je samozřejmě otázkou počet členů takového týmu. Další variantou je pouhé rozdělení původního týmu na dva podtýmy.
4
M-only přístup
M-only je alternativní přístup, při kterém se primárně vytváří jen multiplayerová verze hry. Singleplayerová hra je pak dodatečně vytvořena v podobě „multiplayeru jednoho hráčeÿ, což lze udělat jednoduchým omezením počtu hráčů na jednoho. Singleplayer tedy chápeme jako jistou podmnožinu multiplayeru. K tomuto principu zřejmě sáhne tým, který už nechce znovu projít chaosem při aplikování naivní metody, nebo tým tvořící primárně multiplayerovou hru, kde singleplayer buď není vůbec, nebo je jeho role nepodstatná (např. Quake III). Praxe ukázala, že M-only princip používají především hry, jejichž autoři mají již za sebou dřívější singleplayerové hry. Ti zřejmě nejlépe vědí, jak obtížné může být doplňování multiplayeru do hry, která na něj není od začátku stavěna. Poučení od zkušenějších může posloužit jako pomůcka při volbě strategie vývoje vlastní hry, ale všechny hry skutečně nejsou stejné, takže pouhé poučení k optimálnímu výsledku vždy vést nemusí. Je pochopitelné, že pokud už je hra hotová, její předělávání „od podlahyÿ by bylo nesmyslné. Avšak pokud se hru teprve chystáme dělat, M-only přístup má mnohé kladné rysy. 4.1
Z čeho vycházíme
1. Singleplayer lze téměř vždy realizovat jako multiplayer jednoho hráče. 2. Dekompozice projektu nyní spočívá v oddělení klienta a serveru, čili problém opět rozdělíme na podproblémy, ovšem tentokrát spíše horizontálně. 3. Počítáme s tím, že kvalita multiplayerové hry je natolik důležitá, že nebude vadit ani případný lehký dopad našeho zaměření na výsledek singleplayerové hry2 . 4. Máme ve firmě šamana3 , který přesvědčí manažera, že tento postup je správný, i když první hratelnou verzi brzo určitě nedostane. Problém první hratelné verze však může vážně ohrozit samotnou realizaci projektu zvláště v případech, kdy je financování svázáno právě s hratelnými verzemi (což je navíc obvyklá situace). 2
3
Zde to vypadá na snahu o ospravedlnění horší kvality programu. Ve skutečnosti ovšem jde o důsledek známého faktu, že pokud chceme, aby se vlk nažral a nechceme mu obětovat kozu, musíme mu dát něco jiného. Anglicky by se řeklo wizard.
7
4.2
Postup prací
Na začátku je třeba si uvědomit, že nás čeká práce na dvou samostatných jednotkách – klientu a serveru. I v případě, že se z praktických důvodů rozhodneme pro sloučení obou částí do jednoho programu, je třeba nahlížet na celý kód odděleně, tedy nikdy nepropojovat klient a server uvnitř programu. Z hlediska vývoje je vhodnější vytvářet dva samostatné programy, neboť je to jediný nástroj, který udrží programátory od snahy „optimalizovatÿ kód spojováním nepatřičných částí dohromady tak, aby přestal fungovat. Konečný produkt však z hlediska využití paměti a dalších zdrojů spíše vyžaduje pracovat tak, aby klient i server fungovaly v rámci jednoho procesu, kde lze řadu důležitých zdrojů sdílet (je možno lépe hospodařit s procesorovým časem, nezdvojovat v paměti data apod.). Z hlediska designu je vhodné, aby byl kód serveru natolik nezávislý, aby bylo možno vytvořit i plně dedikovanou serverovou aplikaci. Tento dedikovaný server zřejmě nebude kromě síťové komunikace potřebovat žádné systémově specifické zdroje (jako je DirectX), bude tedy možné jej poměrně snadno převést z Windows na Linux apod. Zatímco pro hry samotné je Windows téměř výlučnou doménou, herní serverové aplikace jsou často provozovány právě na Linuxu. Prvotní fáze M-only projektu mohou být psychicky náročné jak pro manažera (který pochopitelně nevidí žádný výsledek), tak pro samotné programátory, kteří hned z kraje začnou narážet na místa, kde by singleplayerový kód měl 3 řádky, zatímco multiplayerový jich bude mít 200. Zvláště programátory, kteří ještě nemají za sebou několik multiplayerových projektů, zde může být poměrně lákavá vidina napsat jen ty tři řádky a o další se nestarat. . . Jak práce postupují, začne „práce navícÿ ubývat a především vše dostane pevný řád (díky rozdělení klient–server). V krizových situacích, které jistě nastanou, je třeba si uvědomit, že dělat jednou složitý kód je vždy lepší, než ho udělat jednoduše (singleplayer) a potom to celé dělat znovu, a tentokrát složitě (multiplayer). 4.3
Peer–peer, klient–server, distribuovaně nebo centrálně
Doposud jsme předpokládali použití klient–server modelu. Ve skutečnosti jsou ale nejméně tři možnosti, jak lze otázku síťové komunikace a hierarchie řešit. Centralizovaný klient–server Klasickým modelem síťového softwaru je centralizovaný klient–server. Figuruje zde jeden server a řada klientů, čili hráčů zapojených do hry. Při singleplayerové hře běží server i klient na jednom počítači, právě proto je velmi výhodné oba moduly umístit do společného procesu a mít tak vyšší kontrolu nad využíváním často velmi omezených systémových zdrojů. V obecných situacích lze počítat i s možným využitím dvou mikroprocesorů, ale v praxi to nemá velký význam, neboť víceprocesorové počítače jsou obvykle už samy o sobě dostatečně rychlé4 . 4
Tento předpoklad se však může v dohledné budoucnosti změnit, tj. až i pomalejší z běžných počítačů budou obsahovat alespoň dvě procesorová jádra, bude mít smysl toho ve hrách cíleně využívat.
8
Obr. 2. Počítačové hry často podporují i lidskou tvořivost. c Peter Helcmanovský „HD2 Secret marketing trick with Microsoftÿ
Problémem tohoto řešení je latence, čili zpožďování dění na klientech. To může být při hraní velmi nepříjemné. Proto se v praxi tato plně centralizovaná varianta příliš nepoužívá. Distribuovaný klient–server Distribucí mezi jednotlivé uzly můžeme získat mnohé výhody. Pokud jsme ochotni zaplatit za ně složitějším kódem (což však má za následek i delší lhůty vývoje programu), můžeme získat vyšší rychlost výsledné hry. Jednak ušetříme výpočetní výkon centrálního uzlu (serveru) tím, že část zátěže přesuneme na další uzly (klienty), navíc se výrazně sníží latence v případě, že se uzly budou starat především „samy o své věciÿ. Nevýhodou je naopak zvýšení latence na klientech při jejich vzájemné komunikaci, protože některé věci, které by se původně řešily na serveru, se nyní přesouvají na klienty. Je zde tedy nutnost přenosu většího množství dat po síti, navíc je větší nebezpečí napadení systému záškodníkem (což je u počítačových her bohužel velmi častý jev). S ohledem na bezpečnost je třeba s distribuováním dat raději šetřit. Např. znalost celé mapy hry může urychlit proces zobrazení nepřítele při přiblížení na hranici dohlednosti, ovšem při napadení klientské aplikace hráčem může být výsledkem to, že hráč vidí všechny protivníky a má výrazně usnadněnou hru. Celá problematika bezpečnosti multiplayerových her je nad rámec tohoto textu. Hráči jsou na internetu obvykle za firewallem či překladem adres, jejichž nastavení nemohou nijak ovlivnit, takže vzájemná komunikace mezi uzly často není možná. Každý klient tedy může komunikovat jen se serverem (který po9
chopitelně nemůže být za firewallem), což zhoršuje efektivitu distribuovaného řešení. Přestože toto je přímý důsledek architektury klient–server, o skutečné efektivitě rozhoduje především fyzická topologie. I přes (nekonečné) komplikace při realizaci distribuovaného řešení, se mi jeví jako nejlepší. Je pouze třeba najít správnou mez mezi tím, co budeme řešit výhradně na serveru, a tím, co budeme řešit distribuovaně. Právě kombinovaný přístup obvykle dává nejlepší výsledky. Distribuovaný peer–peer Peer–peer řešení je vhodné pouze pro lokální sítě. Na internetu, jak už bylo řečeno, narážíme na firewally a překlady adres, které vzájemnou komunikaci mezi počítači znemožňují. Naopak v situacích, kdy jsou některé uzly na společné lokální síti, zatímco herní server je vzdálený, by mohlo peer–peer nebo kombinované řešení přinést jisté ovoce. Jelikož klient–server řešení je použitelné i na lokální síti, peer–peer se obvykle vůbec nepoužívá. Distribuované peer–peer řešení je podobné distribuovanému klient–server řešení, avšak díky přímé komunikaci mezi uzly je dosaženo nižší latence. Z těchto poznatků lze vyvodit, že peer–peer řešení je vhodné především pro pomalé lokálních sítě. To je však poněkud teoretická kombinace, neboť hra schopná fungovat v prostředí (pomalého) internetu, je na lokální síti vždy dostatečně rychlá. S ohledem na průzkumy trhu je jasné, že multiplayerová hra omezená jen na peer–peer a tedy jen na lokální síť, nemá moc šancí na úspěch. 4.4
Optimalizace singleplayeru
Optimalizací určitých částí síťové knihovny lze dosáhnout zrychlení programu v situaci, kdy server i klient běží na jednom počítači. Pokud navíc máme celý kód v jednom programu (procesu), můžeme v rámci optimalizace rychlosti přistoupit až k výjimečným řešením, kdy klient sahá přímo do dat serveru apod. Toto je samozřejmě již velmi specifická optimalizace. Takový přístup může vést k implementaci určitých funkcí či vlastností, které by multiplayerová hra kvůli hardwarovým omezením mít nemohla, zatímco v singleplayeru na lokálním počítači je realizace možná. Jedná se například o realistické modelování pohybu kostí/svalů u postav, které přes síť posílat nestihneme a lokální řešení je i mnohem jednodušší. 4.5
Výhody M-only
Shrňme tedy výhody M-only přístupu: 1. Vytváříme jen jeden program, čili po dokončení multiplayeru je hra hotová a singleplayer nevyžaduje žádný další pracovní čas. 2. Horizontální dělení projektu mezi klient a server je logičtější a je ze svého principu striktní, takže dojde k úplnému rozdělení práce na menší části. 3. Konstrukce programu není tolik náchylná na chyby způsobené opomenutím člověka, protože jednotlivé části programu jsou na sobě navzájem nezávislé. Ačkoliv tohoto lze teoreticky dosáhnout správným designem při jakémkoliv typu řešení, praxe již mnohokrát ukázala opak. 10
4.6
Nevýhody M-only
M-only je zde prezentováno spíše pozitivně, má však také některá negativa: 1. Zásadní nevýhodou je nutnost chápat každou část programu v širších souvislostech. 2. Horizontální dělení mezi klient a server je pro člověka často méně intuitivní než vertikální rozdělení projektu. 3. Manažer nemusí být (a ani není) vždy přesvědčen o tom, že čím méně je to ze začátku vidět, tím lepší bude výsledek.
5
Shrnutí
Zkušenosti mé vlastní i ty, o kterých se můžeme dočíst v dostupných zdrojích, hovoří ve prospěch metody označované jako M-only. Je však nutno cynicky dodat, že zákazník obvykle chápe věci jinak a kam sám nemůže, nastrčí aspoň manažera. Praxe ukazuje, že k zavedení určitých správných postupů je obvykle potřeba, aby programátor, tým či firma prošli nejprve alespoň jedním projektem plným komplikací. Nasazení správné metodiky vývoje síťové hry často komplikuje také vnitřní přesvědčení programátorů her i jejich manažerů, že tvorba her je natolik specifickou a obtížnou činností, že na ni nelze běžné zásady vývoje softwaru aplikovat. Praxe však opakovaně dokazuje, že používání metodik vývoje, stejně jako používání úplně klasických návrhových vzorů, je pro vývoj her stejně vhodné, jako pro každý jiný typ objektově-orientovaného softwaru.
Reference 1. Gamasutra – server publikující odborné články zabývající se touto tématikou http://www.Gamasutra.com/ 2. GameDev.Net – server publikující odborné články zabývající se touto tématikou http://www.GameDev.net/ 3. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns – Elements of Reusable Object-oriented Software. Addison-Wesley Professional, 1995. ISBN 0-201-63361-2. Český překlad: Návrh programů pomocí vzorů: stavební kameny objektově orientovaných programů. Grada, Praha, 2003. ISBN 80-247-0302-5. 4. Hidden & Dangerous 2 – server počítačové hry http://www.hidden-and-dangerous.cz/ 5. Illusion Softworks – server předního českého výrobce počítačových her http://www.illusionsoftworks.cz/ 6. Jaroslav Král, Jiří Demner: Softwarové inženýrství. Academia Praha, Praha, 1992. ISBN 80-200-0086-0.
Annotation: Design & Project Management of a Multiplayer Computer Game Computer games are so common kind of software, that one could hardly expect so strange problems arising during their development. . . 11
