Kdo si J2ME, nezlobí – úvod pro každého

V následujících článcích vytvoříme jednoduchou hru. Pro začátek si hlavně rozebereme vše, na co by měl člověk myslet dříve, než se skutečně pustí do psaní. I když nejste přímo programátoři, směle se do článku pusťte, protože neobsahuje žádný kód…

Z čeho se hra skládá

Každá hra se obvykle skládá z několika komponent:

• Úvodní obrazovka (splashscreen) – obrázek (může to být i animace nebo několik obrázků za sebou), který se zobrazí při spuštění aplikace. Obsahuje obvykle název hry a logo výrobce, může zobrazovat průběh nahrávání hry.
• Menu – obsahuje obvykle standardní položky, jako například hrát, nastavení, nápověda, skóre, o aplikaci a konec.
• Vlastní hra – i když hry mohou být diametrálně odlišné, existuje několik kritérií, která by měly splňovat. Při odstranění vlastní hry z displeje by měl být běh hry pozastaven a při jejím zobrazení opět spuštěn. Je-li aplikace určena na více cílových zařízení, je vhodné, je-li logika hry oddělena od třídy, která hru zobrazuje, protože logika hry zůstává stále stejná, i když je nutné psát zobrazování hry pro různá zařízení zvlášť.
• Skóre – seznam nejvyššího dosaženého skóre. Skóre může být odesílatelné na server, aby se mohli hráči porovnávat mezi sebou. V tom případě musí hra obsahovat i formulář pro registraci uživatele na server, má-li jméno jednoznačně identifikovat uživatele.
• Nastavení – hra obvykle mívá nějaké nastavitelné parametry, jako je například úroveň obtížnosti, rozměry herního plánu a podobně. Většinou stačí nastavení parametrů aplikace implementovat jako jednoduchý formulář.

Následující moduly sice nejsou „vidět“, přesto na ně nesmíme zapomenout:

• Perzistentní data – ukládat si data do trvalé paměti může chtít více nezávislých modulů aplikace. Bylo by neefektivní (vzhledem k omezené velikosti aplikace), kdyby si přístup k těmto datům zajišťoval každý modul sám.
• HTTP modul – zde platí to samé jako u perzistentních dat. Komunikovat po síti může úvodní obrazovka (stažení aktuálních informací), vlastní hra (je-li síťová) i seznam nejlepších skóre.

Pohled na aplikaci jako na spojení několika modulů přes nějaké vlastní, jasně definované rozhraní, je výhodný ze dvou důvodů. Prvním z nich je znovuvyužitelnost komponent. Některé komponenty jsou u většiny aplikací stejné (úvodní obrazovka, skóre), takže je stačí napsat jednou u první aplikace a u dalších aplikací je můžeme použít tak, jak jsou, pouze s výměnou obrázku.

Druhým důvodem je jednoduchá nahraditelnost komponent. Vezměme si jako příklad třeba menu aplikace. Pro telefony s malým displejem je menu tvořené pouze obyčejným seznamem položek (třída javax.microedition.lcdui.List) zcela dostačující. Ovšem u větších telefonů, které se velikostí blíží k PDA, vypadá takové menu dost neesteticky a není od věci nahradit tuto komponentu novou verzí, která kreslí menu s použitím nízkoúrovňového rozhraní (javax.microedition.lcdui.Canvas nebo v MIDP 2.0 položky typu javax.microedition.lcdui.CustomItem vložené do formuláře javax.microedition.lcdui.Form).

Než začneme programovat

Než se pustíme do programování, je čas na několik úvah.

Popis hry

Prvním krokem je přesně popsat, jak se má hra chovat. I pak se sice může mnohé v průběhu programování změnit, ale rozhodně bude kód přehlednější, než když začneme rovnou živelně psát.

Náš scénář bude vypadat takto:

Hře říkejme třeba Blabouch. Pod mostem plave loď. Uživatel ovládá loď stiskem šipky doleva nebo doprava. Dokud uživatel šipku drží, loď se pohybuje, když šipku pustí, loď se zastaví. Pravý a levý okraj displeje jsou pro loď neprůchozí, zarazí se o ně. Z mostu padají mince různé hodnoty a bomby. Cílem hry je chytit lodí co nejvíce mincí, jejichž hodnoty se sčítají do celkového skóre. Dotkne-li se lodi bomba, loď exploduje a hra končí.

Popis cílové platformy

Dále je třeba rozmyslet, na jaká všechna zařízení je hra určena a jak se vypořádáme s jejich různými vlastnostmi – velikost displeje, počet barev displeje, ovládání klávesnicí nebo stylusem, maximální velikost aplikace, různá implementovaná proprietární a rozšiřující rozhraní a podobně.

Ovládání klávesnicí nebo stylusem lze implementovat najednou, není-li aplikace nabitá k prasknutí a nebojujeme-li tedy o každý bajt velikosti.

Jak je poznat už ze scénáře, ovládání stylusem nebudeme řešit, jinak by bylo potřeba i způsob tohoto ovládání naplánovat dopředu.

Horší je to s různými displeji. Zde mohou nastat v zásadě tři varianty:

1. Hra bude beze změny běhat na všech možných rozlišeních displeje. Příkladem této varianty může být hra na šachovnici, ve které vše kreslíme pomocí nízkoúrovňové grafiky, rozměry vypočteme podle velikosti displeje a nepoužíváme hotové obrázky. Tento stav by byl asi ideální, ale obvykle se bez hotových obrázků neobejdeme.
2. Pro různá rozlišení displeje je potřeba vytvořit různé obrázky. Této variantě odpovídá většina her. Do verze pro telefony s větším displejem se prostě dají stejné obrázky, jako pro telefony s menším displejem, jen budou mít větší velikost. Mezi obrázky musíme počítat i ikony v menu tvořeném seznamem položek a ikony před jménem hry v seznamu aplikací. A zde trochu komplikuje život, že nejprve člověk musí zjistit velikosti těchto ikon metodou pokus-omyl, protože specifikace telefonů tyto údaje obvykle neuvádí, a pak zjistí, že i telefony s velmi podobnou velikostí displeje mají velikosti ikon často dost odlišné.
3. Pro různá rozlišení je potřeba nastavit některé parametry odlišně či dokonce přepsat zdrojový kód. Tato situace nastane, pokud se aplikace šije na míru displeji a je potřeba zachovat proporce a přesnost na pixel (třeba u fotbalu musí aplikace znát přesně pozice branky, aby nehlásila gól, ačkoli by šel míč mimo branku).

V našem případě bude platit druhá varianta. Pro začátek se hodí zvolit si jeden telefon, na který se aplikace vyvíjí, a přenos na ostatní telefony řešit eventuálně až na závěr, kdy je hra prakticky hotová.

Mezi další úkoly, které je potřeba předem zvážit, patří také řešení vícejazyčnosti aplikace a způsob organizace projektu (obrázků, textů, modulů, sestavování cílových aplikací a podobně). Při takové variabilitě zařízení, jaká panuje, je tento úkol velmi důležitý. Plánujeme-li psát aplikace nejen pro vlastní potěšení, je potřeba co nejvíce úkonů automatizovat, aby se zabránilo chybě lidského faktoru při ručním kopírování tam a zase zpátky a také aby se lidský faktor z toho všeho nezbláznil. Jelikož zatím budeme psát zcela jednoduchou aplikaci v jednom jazyce a na jedno zařízení, necháme si komplikovanější organizaci projektu až na později.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.