Vývojová platforma je OS Linux 2.x. Program bude možné přeložit kompilátorem GNU C++ verze 2.7.2 a vyšší (jiný dobrý kompilátor pro Linux neexistuje). Při velkém úspěchu programu je možné jej přeportovat pro DOS pro DJGPP. Program bude používat pravdepodobně tyto knihovny: pro grafiku - Xlib, svgalib, ggilib, pro síťovou komunikaci socket++.
Hra bude primárně vyvíjena pro Linux, protože na rozdíl od jiných OS, které mohu na svém PC provozovat, jsem si skoro na 100% jistý, že mi celý systém v průbehu práce bez varování nespadne. Na druhou stranu je možné, že Wormz půjdou přeložit pod IRIXem nebo SunOS.
Program půjde zkompilovat pod GNU GCC, protože neznám žádný lepší volně šiřitelný kompilátor, který by zvládal výjimky a šablony (knihovna socket++ používá oboje) překládat pro něco jiného než Win32.
Splněno: Program lze přeložit na (takřka) libovolném UNIXu s systémem X11R6 (nebo X11R5; možná i X11R4, ale to jsem nezkoušel).
Změna (nesplněno): Port pro DOS a kompilátor DJGPP, protože počítač s DOSem jsem neměl k dispozici (DOS: malý otravný boot virus, zpúsobující náhodné spontální spadnutí systému, obvykle těsně před uložením velkého projektu. Jednoduše léčitelný UNIXem).
Vzhledem k tomu, že hra Wormz bude plně grafická (možnou portaci pro ncurses zatím dělat nehodlám), vyžaduje použití některé grafické knihovny. Zatím hlavní je knihovna Xlib, s rozšířeními MIT SHM (sdílená pamět) a XFree DGA (Direct Graphic Access). Vzhledem k mé práci na projektu GGI (dělám driver pro grafickou kartu) bude podporována taky (alfa) verze knihovny ggilib (pro Linux). Protože tato knihovna je zatím ve vývoji, nezaručuji plnou funkčnost (chyby a nové funkce v ggilib budou přibývat zároveň s vývojem Wormz). Knihovna svgalib bude možná podporována (myslím, že je to zbytečné, ggilib je nástupcem svgalib a navíc svgalib nepodporuje např. moji 128-bitovou grafickou kartu). Pokud vznikne port hry pro DOS, bude používat knihovnu Allegro. Pro znakové terminály je port sice možný, ale asi v první verzi nebude (pokud nevěříte, že něco takového je možné, napište si Honzovi Hubičkovi o přehrávač animací FLI na terminálu; podporuje i gama korekci). Jednoduchá "vyšší" knihovna pro GUI (menu) bude vlastní (protože nebudu portovat Tcl/Tk pro libggi a protože si myslím, že hra by měla mít trochu jiné GUI než třeba textový editor). O možnosti použítí knihovny socket++ mám zatím trochu pochybnosti, protože používá pro tak rychlou hru (předpokládám minimálně 25 snímků/zpráv za sekundu) je pomalá, takže budu muset asi použít UDP spojení s vlastní knihovnou funkcí.
Změna: Knihovna Xlib je podporována jako taková, bez rozšíření MIT SHM, tím je možné hrát Wormz i na vzdáleném X serveru, tak (pro větší) rychlost s rozšířením MIT SHM. Program umí sám detekovat rozšíření MIT SHM. XFree DGA není podporováno, protože k němu neexistuje žádná dokumentace! (K MIT SHM také ne, ale alespoň jsou k dispozici zdrojové kódy programů, které MIT SHM používají. Při spouštění na Irixu ze vzdáleného počítače SHM nefunguje, což je v pořádku, ale funkce, která vrací, zda server podporuje SHM, nahlásí, že to půjde a program uvěří. Proto byl přidán parametr -noshm.)
Změna (nesplněno): Používá jen Xlib, nepoužívá svgalib, ani ggilib. Svgalib z toho důvodu, že je to zastaralá grafická knihovna, k spuštění programu využívající svgalib jsou zapotřebí rootovská práva a také není vyloučen pád celého systému. Navíc moje 128-bitová grafická karta není podporována, jen v režimu kompatibility VGA, což znamená nejlepší rozlišení 320x400 v 256 barvách, které je pro Wormz nepoužitelné. Ggilib není podporována, protože ještě nemám plně funkční driver pro moji grafickou kartu. Na druhou stranu, rozhraní programu pro práci s grafikou je natolik jednoduché (zdrojové kódy rozhraní Xlib mají nezpakované 18KB, a z toho nejvíce zabírá ne grafické rozhraní, ale přemapování klávesnice), že přidání rozhraní pro ggilib (hra se tak stan 1. hrou, podporující ggilib a až bude v ggilib doděláno rozhraní pro textový terminál, poběží i na každém kvalitnějším VT100) by mělo zabrat maximálně týden.
Splněno: Vyšší knihovna pro GUI je funkční, bohužel vyhledem k automatickému rozmisťování objektů na obrazovce (při vytváření objektů se nezadává vůbec jeho umístění na obrazovce, místo toho se vloží do objektu Group, který už jej sám umístí podle potřeb) je také docela pomalá. Obsahuje tyto objekty: StaticText, InputLine, InputNumber, CheckBox, PictureSelector, Group a jejich další modifikace.
Změna: Kvůli pomalosti se nepoužívá se knihovna socket++, místo toho je vlastními silami řešeno rozesílání paketů po síti přes UDP přes vlastní protokol.
Hra může běžet na několika počítačích zároveň, na každém počítači může hrát více lidí a/nebo být řízeno víc červů počítačem. Pro start hry je nutné spustit jednu kopii programu jako server, a ostatní k němu připojit jako klienty.
Splněno. Na druhou stranu, očekával jsem, že to bude rychlejší.
Grafické funkce na nejnižším stupni budou (inline) funkce, mapující univerzální funkce typu void lgf::putImg(int x, int y, Img* img) na konkrétní funkce použité grafické knihovny (např. pro Xlib je to PutBitmap). Kvůli problémům s alokací barevné palety v X Window System je možné, že minimum bude 16 bitová barevná hloubka (65536 barev). Tyto funkce by se také měly vyrovnat s ovládáním kurzoru myši.
Splněno. Navíc je podporována 8, 24 a 32 bitová barevná hlouba, 8 bitová s vlastní (private) paletou 3:3:2, 24 a 32 zatím funguje jen na XFree serverech, protože SGI má trochu jinak řešen X server (zvládá 8 a 24 bitů současně) a program to mate a použije 8 bitů. Podporována je libovolné (rozumné) grafické rozlišení, ovšem při síťové hře je nutné, aby všichni klienti měli stejné (barevná hloubka může být jiná). Rozlišení takřka nemá vliv na rychlost hry, jen na velikost zabrané paměti.
Řízení přístupu ke klávesnici musí být také vyřešeno nízkoúrovňově, protože hra vyžaduje (pro hru více hráčů na jednom počítači nebo jedné klávesnici) kontrolu stisku více kláves zároveň (bohužel toto je omezeno špatným návrhem PC klávesnice, která neumožní např. zaznamenat stisk kláves QWERTY zároveň, snad se to změní s novými USB klávesnicemi). Proto bude možná nutné použít pro Linuxovou konzoli navíc knihovnu rawkey. Stav klávesnice (pro každou klávesu stisknutá nebo uvolněná) bude udžován v poli, které bude přístupné pro ostatní části programu.
Splněno. Xlib přímo posílá události typu klávesa stisknuta, klávesa uvolněna, takže to nebyl problém. Program nedokáže určit (záleží to na typu klávesnice, čím novější, tím lepší), zda se některé klávesy nevylučují. Jde zjistit přes program xev.
Pokusím se dosáhnout toho, aby se hra dala hrát na čtyřech počítačích zároveň. Samozřejmě, že na každém počítači může (s jedním programem/oknem) hrát více lidí (prozatím maximum, co se vleze na jednu klávesnici, je 10 lidí). Pro přenos paketů se bude používat architektura Client/Server. Tzn. klienti pošlou data na server a ten, až je dostane ode všech, pošle každému klientu zpátky jeden větší datagram, složený z datagramů, které přijal. Výhoda bude v snížení provozu na síti, pro n počítačů (včetně serveru) je to: (n-1)*2 datagramů, oproti n*(n-1) při peer-to-peer komunikaci. Velikost zpráv bude malá, jen několik bajtů, ale pro každý datagram musíme počítat ještě velikost hlavičky (40 bajtů). Pokud budou počítače na jednom segmentu, bude možné spustit multicastové rozesílání zpráv, což se projeví velkým zrychlením!
Spíše nesplněno: Počet hráčů záleží jen na průchodnosti sítě, menším podfukem (snížením počtu zpráv za sekundu na třetinu tím, že se data o pohybu červů posílají sice každý snímek, ale červ se za jeden snímek posune o 3 kroky místo o jeden) je možné zvýšit rychlst hry. Počet snímků za sekundu se dynamicky opravuje pomocí jednoduchého plánovače (schleduleru), který si vždy na konci snímku zjistí, kolik předpokládal, že bude snímek trvat a kolik skutečně trval, a opraví podle toho snímkovou frekvenci. Bohužel pro plynulou hru po potřeba poslat a přijmout (u každého klienta) asi 50 paketů za sekundu, což síť (alespoň tady na MS) nestíhá.
Protože je nutná rychlá odezva na síťové zprávy, poběží odpovídač ve vlastním threadu.
Změna: odpovídač neběží ve vlastním threadu, protože na Linuxu s libc 5 není možné použít threadovou knihovnu Xlib. Místo toho se používá multiplexing pomocí volání select(2).
Pokud se osvědčí knihovna socket++, bude použita, protože zajišťuje jednoduché objektově orientované rozhraní k přenosům po síti. Jestliže ale bude komunikace pomocí této knihovny příliš pomalá, je možné všechny funkce přepsat tak, aby používaly výhradně UDP spojení.
Změna (používá se přímo UDP). Viz výše.
Ovládání zvukové karty bude řešeno jako tak, aby se dalo použít jak OSS/Lite (Linux), tak NAS nebo rplay (Unix všeobecně). Na vyšší úrovni je možné např. přehrávat XM modul pomocí externího programu (upravený mikmod).
Vzhledem k problému se synchronizací je nutné, aby tato jednotka bežela ve zvláštním threadu.
Nesplněno. Moc jsem optimalizoval síťovou komunikaci a grafiku, až mi na zvuk nezbyl vůbec čas.
GUI bude (narozdíl od předchozích) psáno celé objektově, s funkčností na úrovni knihoven TurboVision (tzn. velmi jednoduché - dialogové boxy, editační pole, menu, události posílány přes metody). Navrhovaná podoba je zde (640x480, 164kB).
Splněno. Viz výše. Grafická podoba se oproti obrázku trochu změnila.
Grafika bude mít několik rovin přes sebe, které se budou kopírovat do framebufferu (nebo přímo do videopaměti). Každá rovina bude mít vlastní buffer (zabere HODNĚ paměti), na druhou stranu by se překreslování mělo trochu zrychlit. Pokud ani toto nepomůže, je možné, že GUI bude používat metodu backing-store (před vykreslením např. tlačítka si uloží, co bylo nakresleno pod ním), ale pak by se nedalo např. spustit demo při výběru z menu (viz Doom). Metoda backing-store běžela v dobré rychlosti i na počítači 386SX/25.
Splněno. Používají se 3 roviny (hrací plocha, panel skóre a menu) s nastavitelnou průhledností. Nepoužívá se backing store.
Barevná paleta v osmibitové hloubce musí být zvolena tak, aby umožňovala jednoduché (a rychlé) počítání průhlednosti (např. fixní 3-3-2).
Nezměněno. Při 8 bitové barevné hloubce se alokuje privátní paleta a barvy se nastaví na fixní 3-3-2.
Poloha | Název | Popis | Průhlednost |
1. - nejvyšší | Menu - text | Používá GUI knihovna. Zde budou textové nápisy menu. | 100% |
2. | Menu - pozadí | Používá GUI knihovna. Podsvícené (vybrané) položky menu, pozadí menu atd. | 50% |
3. | Nápisy pro hru | Používá GUI knihovna. Jednoduché nápisy (kdo je kdo, bonusy). | 50% |
4. | Hrací pole | Zde se budou zobrazovat těla červů, bomby, mosty a pod. | 100% |
5. - nejnižší | Pozadí | Bude jednoduchá textura (pokud to počítač zvládne, klidně animovaná) nebo obrázek. | - |
Změna: 5 rovin zabírá moc paměti (je nutné počítat s X*Y*bpp/8, tj. pro 1024x768/16bpp při pěti rovinách asi 8MB paměti), proto byl jejich počet zredukován na 3:
Poloha | Název | Popis | Průhlednost |
1. - nejvyšší | Menu | Používá GUI knihovna pro všechny své objekty. | 80% |
2. | Panel skóre | Používá se pro zobrazení skóre během hry a oznámeních o začátku a konci hry. | 50% |
3. - nejnižší | Pozadí a hrací pole | Těla červů a tapeta pozadí. | - |
Bude použita jednoduchá dědičnost, hlavní (rodičovská) třída Worm bude mít několik virtuálních metod, jako Worm::playStep() nebo Worm::kill(). Z ní se zdědí třídy Local (na lokálním počítači) a Remote (ovládá jiný počítač nebo hráč na jiném počítači, resp. programu - může běžet více kopií programu na jednom počítači). Třída Local se bude dále dědit na AI (Artifical intelelignce - ovládá lokální počítač) a Human, třída Human se bude dědit dále na HumanKeyboard, HumanMouse, HumanJoystick atd. Tím, že třída Remote se bude chovat stejně jako ostatní, není nutné příliš rozlišovat mezi hrou na jednom a na více počítačích - Remote se jednoduše připojí na server (resp. bude používat funkce, které ji budou dodávat informace) a naopak, pro každý Local objekt je nutné upravit např. metodu Worm::goStep(), tak aby posílal data o pohybu na server.
Změna: Byla vypuštěna třída Local, třída Human se dále nedělí, protože se tlačítka myši mapují jakoby na stisky kláves. Rozhodování o tom, co se má posílat při síťové hře na server, se přeneslo na třídu Players.
Na rozdíl od starší verze (v Turbo Pascalu, pro DOS), kde se pro každý krok počítala kompletně znova celá mapa okolí červa (tak, že se okolí červa rozdělilo na 8 částí, v těch se spočítalo počet obsazených bodů a tam kde bylo nejmíň, se červ s určitou pravděpodobností začal natáčet), bude si nyní každý červ pamatovat informace o okolí z předchozích pohybů a jen je opravovat. Pokusím se dosáhnout toho, aby při hře jen 20 počítačů proti sobě netrvalo každé kolo jen 3 sekundy, jak tomu bylo v předchozí verzi. To bude snadné se zvyšením výkonu (předtím to muselo plynule běžet na 386SX/25) a možností rozdistribuovat AI na počítače v síti. Na druhou stranu, nedá se očekávat, že počítač v souboji s červem ovládaným člověkem někdy vyhraje.
Splněno: Jednoduchou úpravou původního algoritmu se inteligence AI prudce zvýšila. Každý třetí až pátý snímek (číslo se volí částečně náhodně, aby nedocházelo k tomu, že 4 snímky se nepočítá nic a další snímek přepočítávají všechny AI, místo toho se výpočty rozhodí) se vypočítá počet bodů ve dvou výsečích ve směru dalšího pohybu červa a podle toho, kde je méně bodů, se červ do dalšího přepočítávání otáčí.
Změna: Počítač dokáže vyhrát. Tedy, pokud hraje několik AI a jeden člověk, většinou vyhraje AI, protože dokáže přesněji vést červa i v úzkých uličkách mezi ostatními červy.