Volt egy ötletem, meg is valósítottam, csak még nem tudom mibe fogom beleépíteni. Egyszerűen arról van szó, hogy nem látjuk a pálya egészét, mint ahogy sok stratégiai játékban sem. Ezzel is nehezítve/izgalmasabbá téve a dolgokat.

Még nem túl kifinomult a módszer, így csak fekete-fehérben működik, de kiterjeszteni színesre már nem olyan nagy dolog. A látható rész színes, minden más fekete-fehér.

Az ötlet maga pofon egyszerű. Egymára rajzoljuk a rétegeket és így az látszik, ami legfelül van. Értelem szerűen a következő sorrendben érdemes felrajzolni a canvasra a rétegeket: fekete háttér, fehér kör (ahol látszanak a dolgok), majd feketével a minták.

Egyelőre még nem vettem hasznát ennek az apró ötletnek, már azon túl persze, hogy megírtam a példaprogit. Amit meg is lehet nézni, sőt ki is lehet próbálni. Appletes cucc, egy újabb kísérlet. Ide wordpressbe nem sikerült beágyazni, nem nagyon hagyta magát, de van link, természetesen. Itt lehet megtalálni a cuccot.

Csak zárójelben mondom, hogy a wordpress szolgáltatása iszonyat lassú (fél perc mire betölti ezt a szerkesztő felületet, pedig nem szar a net itthon). Nem tudom, hogy ez a motor hibája-e, vagy a wordpress.com nem tud normális sebességet produkálni. Nem is érdekel. Lehet, hogy váltok valami jól beváltra. Saját domain nem kell, jó valami ilyen közösségi és ingyenes oldal.

Egyelőre még nem túl nagy a választék, de a fontosabb dolgokat már lefedik az eddig megjelent pluginnek. GMail és GReader figyelő, delicious, adblock, mouse gestures. Az életben maradáshoz szükségesek szerencsére már megbízhatóan működnek.

A pluginnek használatához Chrome 4.0.x verziójú szükséges, ami jelenleg beta állapotú, de nálam megbízhatóan fut már pár napja. Eddig egyszer sem omlott össze, ha a gép ki van nyitva, akkor állandóan fut a böngésző (és sajnos/nem sajnos ez elég sok üzemórát jelent).

Telepíteni és használni gyerekjáték a Chrome pluginneket. A fejlesztésbe eddig még nem kóstoltam bele, de a jövőben ez sem kizárt. A Google erősen épít a felhasználóira és az önkéntes fejlesztőire, szóval kellő segítséget találunk, ha bele akarunk vágni.

További infókat a Chromium blogon és a Google Chrome hivatalos blogján találunk. Ja, és persze a legfontosabb: az extension library.

Az örömünk mégsem teljes, mert a kép furcsán villódzik. Érthető is ez, mert ha csak a másodperc tört részére, de akkor is letöröljük a képernyőt és ezalatt csak a nagy fehérség látszik, aztán megint a kép, amit mutatni szeretnénk. Idegesítő jelenség, de szerencsére a megoldást tálcán nyújtják felénk csak el kell fogadni.

Felveszünk a háttérben egy másik vásznat, ami rejtett a felhasználó előtt. Erre rajzolgatunk, s majd ha kész, akkor kirajzoljuk a látható vászonra is.

Ez így mind szép és jó, de az implementáció tartogat néhány buktatót. Szóval akkor lássuk is. JAVAban természetesen.

Két megoldást is találtam. Az első, ami a “józan paraszti ész” csapásirányát követi és ezáltal a nyelvi lehetőségeket nem annyira használja ki. Létrehozunk egy rejtett vásznat (Image), meg egy Graphics objektumot, amivel tudunk rá rajozlni. A paint() metódusban rajzolgatunk kedvünkre, de ezt a rejtett vászonra tesszük. S majd a legvégén az egész képet egyszerre rajzoljuk ki a látható Canvasra. (Ne felejtsük el letörölni rajzolás előtt a vásznat!)

Példakód:

public class myCanvas extends Canvas {

	Image bufferImage;
	Graphics bufferGraphics;

	public void paint(Graphics g){
		// letöröljük a vásznat
		bufferGraphics.clearRect(0, 0, getWidth(), getHeight());
		// itt rajzolgatunk, amit akarunk,
		// de ezt a rejtett vászonra tegyük pl:
		bufferGraphics.setColor(Color.RED);
		bufferGraphics.drawRoundRect(200, 200, 150, 100, 10, 15);
		...
		// kirajzoljuk a rejtett vásznat
		g.drawImage(bufferImage, 0, 0, null);
	}

	public void update(Graphics g){
		// ez alapból letörli a Canvast,
		// ezután pedig meghívja a paint metódust
		// a letörlést mi végezzük
		// különben is ez okozza a villódzást,
		// ezért most ezt mellőzük
		paint(g);
	}

	// elvégzi a rejtett és a látható vászon összerendelését.
	// ezt csak akkor tehetjük meg, ha már látható a Canvas!!!
	public void setDubleBuffer() {
		bufferImage = createImage(getWidth(), getHeight());
		bufferGraphics = bufferImage.getGraphics();
	}
}

A másik lehetőség jobban kihasználja, hogy már mások is gondoltak erre a megoldásra, ezért jobban integrált nyelvi elemeket is adtak a kezünkbe.

Ebben az esetben nem piszkálunk bele a paint() metóduba, hanem ehelyett a az update() metódust módosítjuk. A duplabuffer kialakítását pedig a Canvas osztály void createBufferStrategy(int bufferlayers) metódusával végezzük, amit a setDubleBuffer metódusunkhoz hasonlóan csak a Canvas megjelenítése után futtathatunk.

Példakód (Canvas osztály update metódusának overloadingja):

    public void update(Graphics g) {
        BufferStrategy b = getBufferStrategy();
        Graphics graph = b.getDrawGraphics();
        graph.clearRect(0, 0, getWidth(), getHeight());
        paint(graph);
        graph.dispose();
        b.show();
    }

A formunkon a következő képpen alakítható ki a duplabuffer:

        // mindenképpen láthatónak kell lennie a Canvasnak!!!
        form.setVisible(true);
        mycanvas.createBufferStrategy(2);

Bármelyik megoldást is választjuk, az eredmény ugyanaz. A megjelenítés nem villódzik, kényelmes a szemnek, és csupa jóság.

Megszenvedtem a wordpress szövegszerkesztőjével, szóval tessék megbecsülni. Meg is ijedtem, hogy ha ilyen szenvedés itt kódot beilleszteni és olvashatóra formázni, akkor virágzó kapcsolatom a wordpress-szel hamar derékba törik…

A tovább után képekkel, jó hosszan.

Hátra volt még a szintlépés és az újrakezdés, valamint a labda sebességének és irányának változtatása, a játék élvezeti-faktorának növelése érdekében. :) Valamint – eddig ugyan elsikkadt, de a játékos tájékoztatása sem volt teljes. Ebből az első kettő maradéktalanul elkészült. Ha elfogyott az életünk, akkor gombnyomásra újraindíthatjuk a játékot az első pályától. Ha leütöttük az összes téglát, akkor természetesen eggyel magasabb szintre jutunk, s ezt egy plusz élettel jutalmazom. :)

Három előre elkészített pálya van, ezután a program magának generál véletlenszerűen új pályákat, így a végtelenségig játszató. Pontgyűjtésre is lehetőség van, minden téglaérintésnél 1 pontot kapunk. Toplista sajnos nem fért bele az időbe. Ennek az egyik oka, hogy a fájlkezelés JAVAban egyáltalán nem olyan kényelmes és hirtelen (egyelőre korlátozott nyelvi készletemmel) nem tudtam összerakni egy már elfogadható toplista mentés és megjelenítést. A toplista kiírása kapcsán pedig a hova? kérdés vetődött volna fel. A pálya már így is teljesen zsúfolt. Ha egyszer lesz időm és megint beletúrok a programba, akkor valami egyszerű XML-s megoldást fogok alkalmazni.

Az idő rövidsége ellenére is kerültek ötletes dolgok a programba. A szintlépésnél egyszerűen csak átdob a következő pályára és nincs semmi animáció (még ezen is lehetne szépíteni, ugye), de hogy mégse legyen ennyire csupasz, van egy elhalványuló “x. szint” felirat. Az egész modellt várakoztatni kell, hogy emberileg felfogható maradjon, ezért minden egyes alkalommal a labda haladása után várunk 10 ms-t. Ezt használtam ki az elhalványodó felirathoz. Az idő elteltével lineárisan növeltem a szín összetevőit, s így szépen kifakul, majd eltűnik.

A sebesség esetében valami véletlenszerű növekedés akartam, hogy legyen valami izgalom is. Sajnos hamar kiderült, hogy a sebesség csak nagyon szűk keretek között változtatható. A pálya 10 ms-ként rajzolódik újra, így 6-7 px-es haladás már elég gyors. Ennél gyorsabb labda már nagyon nehezen követhető.

Korlátok közé szorítani a növekedést nem volt olyan bonyolult, viszont nem várt bugokat okozott. A sebesség iránya megváltozott és pont olyan szögben haladt a labda, hogy a téglák sarkán képes volt behatolni azok belsejébe. (A sebesség vízszintessel bezárt szöge megegyezett a tégla átlójának vízszintessel bezárt szögével, s ezen a pályán beléphetett a tégla belsejébe, azonnal eltüntetve azt.) Ezen kívül valahogy a pálya szélén is be tudott ragadni, bár ezt csak 2-szer tapasztaltam, s szándékosan nem tudtam előidézni, így az okát sem tudom.

Ezeket a bugokat nem volt időm kijavítani és nem is akartam, ezért a gyorsulás csak előre megadott módon történhet. A szögek úgy vannak beállítva, hogy ne fordulhasson elő az előbb vázolt két eset.

A visszapattanás szögének változtatása és a gyorsítás együtt szinte lehetetlenül nehézzé tette a játékot, ezért végül nem került bele a végleges megoldásba. Ennek ellenére elkészültek részek, s a tervek is készen vannak. Az ütőt 3 részre osztom. A közepéről úgy pattan vissza, ahogy eddig. Az érkezés oldalán a merőlegeshez törik, míg a másik oldalon a merőlegestől elfele. Köztes megoldás volt a koordináták felcserélése, ezzel azt értem el, hogy a beesési szög+kilépési szög = 90°.

A végeredmény így sem rossz, van még vele egy kevés munka, hogy tényleg élvezhető játék váljon belőle és ne csak egy stílusgyakorlat maradjon. Terveim szerint még visszatérek a Pongra és megcsinálom a kimaradt részeket, már csak a saját okulásomra is.

Verzióügyileg még nem teljesen értem, hogy mi alapján megy a számozás, de mondjuk, hogy ez most már public beta. A futtatáshoz 6-os JRE kell. Ahogy ígértem a forrást és a futtatható állományt is elérhetővé teszem:

Forrás fájlok. (van javadoc is csak generálni kell)
Futtatható állomány.

Elsőnek az MVC-t veszem elő, ha már a Pong projekt kapcsán úgyis beleütköztem és használtam. Az MVC feloldása a Model-View-Control. Ez egy tervezési minta, aminek a lényege, hogy három elkülönülő részre bontjuk a programunkat. Modellre, a megjelenítőre és a vezérlőre. Ezen tervezési minta használatának több előnye is van. Az egyes részek fejlesztése teljesen elkülöníthető, csak az interfészek ismerete szükséges. Egy modellhez több egymástól független megjelenítő és vezérlő is kapcsolható és ezek akár különbözhetnek is (pl. konzolos vagy grafikus megjelenítés).

A modell a nevéből adódóan a modellt tartalmazza. Ez a program “lényegi” része, ide pakoljuk bele az üzleti logikát, azaz itt kap értelmet a puszta adat. Az adatokat sokszor adatbázisban tároljuk, az adatelérés is a modellhez tartozik (az MVC nem különböztet meg külön adatelérési réteget). A Pong program esetében ez például a pályát és a rajta lévő egységeket menedzselő rész. Nyilvántartja, hogy mi hol van a pályán, mekkora a sebessége a labdának, vagy éppen azt számolja ki, hogy a labda a következő lépésnél visszapattanjon, vagy haladjon tovább egyenesen.

A view, azaz a megjelenítő az adatok megjelenítéséért felel. Nem kell semmit tudnia a modell működéséről, csak az adatokat kell elkérnie tőle. Innentől már mindent megold maga. A Pong esetében egy Canvas-ra rajzoljuk ki a pályát és a rajta lévő elemeket.

A control, azaz a vezérlő egység interakciót biztosít a felhasználó számára. Jellemzően eseményeket dolgoz fel és válaszol rájuk.

A három rész együttes működését az alábbi ábra mutatja:

Beérkezik egy esemény, amit a vezérlő feldolgoz. Ezután értesíti a modellt és a megjelenítőt a változásokról. A modell elvégzi a saját feladatát, majd értesíti a megjelenítőt, s elküldi neki az új adatokat. A megjelenítő frissíti magát, majd minden kezdődik előröl, mikor egy másik esemény üt be.

Fontos megjegyezni, hogy a view nem fér hozzá közvetlenül a modellhez, és fordítva. A kapcsolatot a controller tartja fenn.

A teljes elszaparálást nagyon nehéz fentartani, ez megmutatkozott a Pong fejlesztése közben is. Viszont érdemes törekedni rá, mert ha csorbul az egyes részek szuverenitása, utána nehezebb új megjelenítőt vagy vezérlőt csatlakoztatni a modellre.

A téglák színkódolása kész, ezzel együtt az is, hogy mindig olyan színük van, ahányszor meg kell ütni őket. 3 különböző pályát is építettem a programba, de a végtelenségig lehet játszani, mert a 4. szinttől generál magának véletlenszerű pályákat. A téglákat is helyre tettem, így már mindig jól pattan vissza róluk a labda, s nem képes tarolásra.

A mai legfontosabb eredmény mégis a labda beragadásának kiküszöbölése. Az oka elég trükkös és nem két perc ment el vele, míg rájöttem mi és miért történik.

Nem szinkronizációs probléma okozta, de nem is a feltételek voltak rosszak. A probléma gyökere abban keresendő, hogy az érzékelés felbontása túl nagy volt, azaz túl sűrűn mozdult a labda, így egyszerre csak nagyon keveset haladhatott (néhány pixel), hogy még követhető maradjon. Ennek következtében a labda ugyan visszapattant, de nem került elég messze az ütőtől. Az ütő mozdulhatott és mozdult is míg a labda mozgott, és így a labda újra belekerült az ütő hatókörébe. Ekkor megint irányt változtatott a labda, de már rossz irányba (eddig távolodott volna az ütőtől), és ezért indult el az ütő belseje felé.

A fenti ábrán a beérkező állapot látható. Az ütő körül a labda r sugarú környezetét ellenőrizzük. Ha ide belép a labda középpontja, akkor pattan vissza. (Sajnos az ábra nem méretarányos. :)) A lenti ábrán már a kilépés látható, de az ütő mozdulása következtében még mindig a hatókörön belül van. A sebesség megfordul, és így irány az ütő belseje.

A megoldás viszont tényleg nagyon egyszerű. A labda tudja magáról, hogy visszapattant-e az ütőről. Mikor visszapattan a hitByRacket boolean változó igaz lesz, s majd csak akkor válik megint hamissá, ha valami máshoz is hozzáért (fal, tégla, esetleg kiesett a pályáról). A visszapattanás előtt ellenőrizzük, hogy kétszer ne pattanhasson vissza a labda (hitByRacket igaz-e) az ütőről. Ezzel garantáljuk, hogy nem ragad be sohasem.

Feladat: egyszerű faltörő játék. Ennél pontosabb feladatkiírás nem volt, csupán néhány technológiai elvárás a feladattal kapcsolatban, ezért rendes specifikáció nem készült. Bár az “egyszerű faltörő játék” már egészen jól leírja miről is van szó.

A teljesség kedvéért itt most megemlékezek egy vázlatos specifikációval. (Jó lesz ez még a leadásnál is. :))

A pályán egy labda mozog, amit egy ütővel lehet terelgetni, a cél a pályán fellelhető téglák széttörése. A téglákat egy vagy több alkalommal kell megütni, hogy eltűnjenek (ezt színük jelzi). Ha minden tégla elfogyott a következő pályára lépünk, vagy nyerünk, ha az utolsó pályán voltunk. A játék alapból 3 pályát tartalmaz, ezek különböző felépítésűek. A labda sebessége akkor változik, ha megütjük az ütővel.

Java SE-ben írom, természetesen az OO paradigmák szem előtt tartásával. Az MVC tervezési mintát alapul véve. Szálkezelést is emlegettek, de egy ilyen kis programnál nem látom értelmét. Még gyakorlás szinten sem. Egy labda és egy ütő van, így nincs is mit külön szálon futtatni. A soklabdás példaprogramban külön szálon mennek a labdák, de ez szinte csak formaiság, mert lényegében nem változtat semmit azzal szemben, mintha egy szálban lenne az összes labda.

Jelenleg valahol félúton lehetek a már késznek mondható állapothoz képest. A labda már mozog, falakról, ütőről, téglákról visszapattan és a téglákat össze is töri. Egyelőre a visszapattanás a fénytörés törvényének megfelelő, azaz a beesési szög megegyezik a kilépési szöggel. Az ütő esetében ezen változtatni kell, mert így nem túl izgalmas a játék.

Pontszámokat és az életeket is adminisztrálja már. Ha leesik a labda, akkor újat kapunk.

A labda sebességét sem szabályozza még rendesen a program, így mindig ugyanolyan sebességgel halad. Apróság ugyan, de a téglák színkódolása is hátra van még, egyelőre véletlen színeket vesznek fel.

Az üzleti logika (heh milyen szakszavak vannak itt) nagy részét, azaz a visszapattanásokat már nagyjából megoldottam. Van még néhány bug, amit ki kell javítani.

A legsúlyosabb ezek közül, hogy a labda képes beleragadni az ütőbe. Erre két tippem van. Vagy az, hogy a labda mozgása és az ütő mozgatása nincs szinkronban. Így lehet olyat csinálni, hogy a labda úgy érzékeli mintha léphetne arra a koordinátára, mert nincs ott az ütő, de miközben lép odarántjuk az ütőt, ezért a labda belekerül és beleragad, mert a visszapattanási feltételeknek eleget tesz.

A másik lehetőség, hogy nincs gond a szinkronizációval, viszont ha sarok koordinátákon ér a labda az ütőhöz, az nem veszi észre és így képes belépni a belsejébe. Bár elméletileg ez nem lenne lehetséges, mert a feltételek ezt kizárják, de úgy látszik, tévedek.

Egyelőre ennyit a Pongról, még úgyis pörög majd ez a téma, mert valamikor jövő héten kell leadni, és még van vele munka rendesen.

Van nekünk ez a látványos és könnyen érthető videónk és egy weboldalunk is, ahol megtudhatunk ezt-azt:

Ami sokkal érdekesebb felhasználói szempontból, az az UI (user interface). Erre az alábbi videóban láthatunk elgondolásokat.

Lássuk csak mit is kapunk. Gyorsaságot ígérnek. Ez elég csábító, ha azt nézzük, hogy az XP-nek, ami gépemen fut, és elég minimálisra van szabva, minimum egy percre van szüksége, hogy használatra kész legyen. A Chrome OS ezzel szemben valami iszonyatos sebességet ígér, főleg a bootolás terén. Felugrik az op rendszer és már fent is vagyok az interneten.

Nem látom viszont, hogy a saját adataimat hol fogom tárolni, ha egyszer még az op rendszer is a netről jön. Persze biztos lesz valami helyi tár, ahova bepakolhatok cuccokat, de mégsem egy 160 GB-s HDD. Mondhatnánk, hogy így biztonságosabb is, ha nincsenek nálam az adataim, hanem “fent vannak az interneten”, azaz a Google valamelyik szervere mélyén tárolja.

És ez jó is, meg rossz is. Már most is a fél életem a Google szerverein nyugszik, de úgy már nagyjából az egész ott lesz. Ez picit aggasztó, még akkor is ha minden Google-lel kapcsolatos összeesküvés-elméletet elutasítunk.

Mégis a legnagyobb  problémát abban látom a Chrome OS-sel kapcsolatban, hogy mi van ha nincs internet? Akkor talán még lehetőségünk sem lesz, hogy folytassuk a munkát? Pedig sok esetben nem kell az internet, csak könnyebbséget jelent.

Ezt az “interneten van az operációs rendszer” dolgot valahogy úgy képzelem, hogy a lényegi rész a gépen fog csücsülni, és csak a személyes beállítások lesznek egy távoli szerveren, amit a mindenható Google accountommal érhetek el.

Nem néztem bele a projektbe, pedig megtehetném, mert opensource. Ez egy jó pont a fejlesztők részéről. Meggyőződésem, hogy a nyílt forráskódú szoftverek biztonságosabbak és dinamikusabban fejlődnek.

Átlag felhasználói szempontból a Chrome OS nagyon jó. Az interneten keresztül majdnem mindent el tudunk végezni, ami a mindennapi tevékenységünket lefedi. Ebben az esetben a nagy és lomha operációs rendszer csak visszafog a munkámban és csökkenti a hatékonyságot.

Most még csak találgatások vannak, de ha egyszer már tesztelhető állapotba kerül a Chrome OS, akkor én megnézem magamnak közelebbről is.

Tetszik ez a WordPress motor, a szolgáltatás egyetlen hibája, hogy néhány funkcióért fizetni kéne, amihez nincs kedvem és forrásom se. Szóval fapados marad a dizájn például.

Így az elején még sok ötletem van, és még lendületben is vagyok, szóval várható értelmes tartalom is, de ahogy a tagline is mondja, rendszertelen frissülésre lehet készülni. :)