Rendes poszt helyett most csak egy rövid dühöngés jön, előre is bocsánat.

Aki regisztrált már .hu domain-t, az tudja, hogy Magyarország az a csodás ország, ahol még az Internet is bürokratikus. Szemben mondjuk egy .com-os címmel, ami fizetés után egy órával már bent van a DNS-ben (vagyis működik), nálunk el kell faxolni egy kézzel aláírt igénylőlapot, fizetni, majd várni 2 hetet, hátha valaki más is igényt tart a domain-re, aki inkább "jogosult" rá.

Két hete foglaltam le az aldebaran.hu-t, amit végül most visszadobott az ISZT. De nem azért, mert ez idő alatt bárki is igényt tartott volna rá, hanem mert valakinek védjegye van az Aldebaran névre. Ezt a tényt éppen közölhették volna már a legelején is, nem csak a két hét elteltével, de hát hova siessen egy gittegylet.

Ezután ellátogattam a Magyar Szabadalmi Hivatal honlapjára, ahol regisztráció, cookie-k és popup-ok engedélyezése után már hozzá is fértem az adatbázishoz. És mi derült ki? 1989-ben egy Gerz nevű olasz nehéz/gépipari ("machines pour travailler les métaux en feuilles") vállalat jegyezte be a nevet. Rákerestem Google-ön, de nem találtam róla semmit. Megtaláltam viszont a védjegyet a WIPO honlapján, ahol nem hogy regisztrálni nem kellett ehhez, hanem még a Google indexében is benne volt.

Szóval ez a talán már nem is létező olasz cég nem rendelkezik a gerz.it-vel (német IT cég oldala), az aldebaran.it-vel (üres oldal), az aldebaran.com-mal (abortuszellenes oldal), az aldebaran.org-gal (üres oldal), és persze általában az Aldebaran névvel sem (ezerpárszáz éves arab név), viszont biztos lehet benne, hogy amíg a védjegye kitart, rajta kívül senkié sem lesz az aldebaran.hu.

Úgyhogy ezzel eldőlt, hogy nem Aldebaran lesz a játék neve. Akinek van jobb ötlete, írja meg vagy szavazzon ezen a jól sikerült névkiválasztó oldalon.

1926-ban Umberto D'Ancona biológus észrevette, hogy az I. világháború idején az Adrián jóval magasabb volt a ragadozók (cápák, ráják) aránya, mint előtte vagy utána. Mivel nem értette, mi lehet az oka, megkérdezte matematikus és szenátor apósát, Vito Volterrát, aki felírt pár egyenletet, és megmagyarázta neki a jelenséget. Innen származik a Lotka-Volterra-modell, ami ha nem is az egyetlen, de az egyik alapvető modell az ökológiában.

A cápa-problémára a magyarázat röviden a következő. A ragadozók és a prédák kölcsönösen hatnak egymásra. Ha több préda van, az pozitívan hat a ragadozókra, hiszen több élelemhez jutnak. Ha több ragadozó van, az viszont negatívan hat a prédákra, hiszen többen eszik őket. Ebből a kölcsönhatásból alakul ki kettejük valamilyen egyensúlyi aránya. A háború alatt leállt a halászat az Adrián, előtte és utána azonban ez is befolyásolta ezt az egyensúlyt. A halászat csökkentette a prédák számát, ami negatívan hatott a ragadozókra, és csökkentette a ragadozók számát is, ami viszont pozitívan hatott a prédákra. Vagyis a halászatnak duplán negatív hatása volt a ragadozókra (kifogták őket és az élelmüket is), és felemás hatása a prédákra (kifogták őket de a pusztítójukat is). Tehát valójában nem is a háború alatt volt magasabb a ragadozók aránya, hanem békeidőben alacsonyabb.

Ez a sztori (és modell) nem csak azért tanulságos, mert megmutatja, hogy hatnak egymásra a különböző fajok (vagyis hogyan "működik" az ökoszféra), hanem azt is, hogy hogyan hat a gazdaság (jelen esetben a halászat) az ökoszférára. És a játékban ezek a hatások is meg fognak jelenni, hogy ne csak a hadi(űr)hajók építése és az ellenség elpusztítása legyen a szórakozás, hanem a fenntartható gazdaság és a környezetvédelem is.

Innentől matek

Bár állítólag minden matematikai képlet felezi az olvasók számát, a korrekt tájékoztatás megköveteli az alábbi kettőt (minthogy ezek a játék motorjában is szerepelnek). Legyen az i-edik faj egyedszáma x_i, fitness-e pedig f_i. A fitness azt adja meg, hogy egy főre hány utód jut. Ekkor az egyedszám változása:

A fitness pedig:

A β_i0 együtthatók adják meg, hogy önmagában hogy szaporodik az i-edik faj. Elsődleges termelőknél (növények, algák) ez pozitív, mert az energiát nem más élőlényekből, hanem pl. a napfényből szerzik. A β_ij együtthatók pedig a fajok kölcsönhatását tükrözik. Versengés esetén két faj kölcsönösen korlátozza egymást (vagy egy faj önmagát), mert valamilyen közös erőforrást (napfény, víz, szabad terület) használnak. Ekkor mind β_ij, mind β_ji negatív.

Ragadozó-zsákmány-kölcsönhatás esetén pedig az egyik együttható pozitív, a másik negatív. A kettő hányadosa a táplálkozás hatékonysága: hány egeret eszik meg egy macska egy kiscica "előállításához". A testtömegben mért hatékonyság (hány kiló egérből lesz egy kiló macska) nagyságrendileg 1/5 és 1/2 között van, a két faj testtömegének aránya mondjuk 1/100 (30g vs. 3kg), így az együtthatók aránya 1/500-1/200. Ezért se nagyon vannak növényevőket evő ragadozókat evő ragadozókat evő ragadozókat evő ragadozók: túl sok növény és állat kéne egyetlen ilyen példány életben maradásához is.

Idáig matek

A játék jelenlegi fázisában egy egyszerű, öt fajból álló ökoszféra működik. Kétféle növény verseng egymással: fű és fa. Két növényevő állat van: a zebrák csak füvet legelnek, a zsiráfok füvet és fát is esznek (mármint a fák lombját). Ragadozónak pedig ott az oroszlán. Az alábbi ábrán az egyes fajok egyedszáma látható az idő függvényében (zöld a fű, barna a fa, sárga a zsiráf, kék a zebra, piros az oroszlán):

Jól látható, ahogy a fák felszaporodása a zsiráfok elterjedéséhez vezet, ami csökkenti a fák számát, ami csökkenti a zsiráfok számát, míg végül be nem áll az egyensúly. Az is látszódik, hogy a zebrák és zsiráfok versengenek egymással: az elején hiába nő a fűmennyiség, a zsiráfok eleszik a növekményt a zebrák elől, így azok nem tudnak elszaporodni. Később a fák és zsiráfok visszaesésével teret kapnak a zebrák is. És azt a tanulságot is levonhatjuk, hogy a természet nem szereti a finnyásokat: kb kétszer annyi zsiráf van, mint zebra.

Tegyük mindenevővé az oroszlánokat, vagyis egyenek füvet és fát is:

Ekkor a "ragadozó" zebrák és zsiráfok aránya lecsökken a "préda" fűhöz és fához képest, vagyis ugyanazt tapasztaljuk, mint D'Ancona a háború után, csak itt nem halászok módosítják az arányokat, hanem mindenevő oroszlánok.

Szinte minden stratégiai játék alapja a gazdaság. A klasszikus Dune II-féle modell roppant egyszerű: bemegy a spice, kijön a tank.

Bár ez így nagyon primitívnek tűnik, a "valóság" vagyis inkább csak egyes közgazdasági modellek sem sokkal bonyolultabbak. Vannak erőforrások (a fenti példában a spice és a tank) meg gyáraink (tankgyár), és egy nagy mátrix, ami megadja, hogy az egyes gyárak az egyes erőforrásokból mennyit használnak fel vagy állítanak elő egységnyi idő alatt.

Ennek az egyszerűségnek több előnye is van. Egyrészt könnyű felfogni. Márpedig ha nem kifejezetten gazdaságszimulátorral játszik valaki, nem biztos, hogy el akar merülni akár a számvitel, akár a derivatívák rejtelmeiben.

Másrészt könnyű megvalósítani. A játék PHP+MySQL+AJAX-alapú, maga a gazdaság MySQL-ben készül. Ez elsőre talán furcsának tűnik, de ha azt nézzük, hogy a játékosok nagy számban egymással párhuzamosan kérdezik le és módosítják (építkezéssel, háborúval) a gazdaság állapotát, akkor máris jól jön egy rendes adatbáziskezelő, ami ezeket gond nélkül elintézi. Szemben egy C-ben barkácsolt modullal, ahol ezeket mind le kell programozni a gazdasági magon kívül.

Tehát

A fenti modellből kiindulva három lényeges táblánk van:

• bolygo_eroforras (bolygo_id, eroforras_id, db): megadja, hogy melyik bolygón melyik erőforrásból hány darab van
• bolygo_gyar (bolygo_id, gyar_id, db): megadja, hogy melyik bolygón melyik gyár(típus)ból hány darab van (vagyis két tankgyár egy bolygón az egy bejegyzés, ahol db=2)
• gyar_eroforras (gyar_id, eroforras_id, io): megadja, hogy melyik gyár(típus) melyik erőforrásból mennyit állít elő vagy használ fel (input/output)

Ez alapján roppant egyszerűnek tűnik összedobni egy lekérdezést, ami kiszámolja, hogy melyik bolygón melyik erőforrásból mekkora növekedés vagy csökkenés megy végbe. Csakhogy van egy bökkenő. Ha hiány van egy erőforrásból, mondjuk nincs 5 spice, akkor a tankgyár nem tud termelni, hiszen negatívba egyik erőforrásból sem mehetünk (per pill nincsenek bankok). Oké, akkor várjuk meg, amíg összejön az 5 spice, addig álljon le a gyár. De mi van, ha több gyár is használ egy erőforrást, amiből részleges hiány van? Vagyis van 5 spice-unk, de a tankgyáron kívül egy másik üzem is felhasználna spice-ot. Melyik termeljen? Várjuk meg, amíg mindenki számára elég input összegyűlik, és akkor egyszerre termelhet az összes egy kört?

Először pontosan így volt leprogramozva a dolog. Aztán Arthur bá elküldte a tutit. Ha egy erőforrást több gyár is használ inputnak, akkor osszuk fel köztük olyan arányban, amilyen arányban igénylik. És mindegyik gyár olyan teljesítménnyel üzemeljen, amennyi inputja van a teljes igényéhez képest. Vagyis ha van 4 tankgyár és 2 barakk, amik 3 spice-ból csinálnak egy katonát, akkor a spice 6/26-od része megy a barakkoknak, 20/26-ad része a tankgyáraknak. Így 13 spice esetén 3 spice-ot kapnak a barakkok (és termelnek 1 katonát), 10-et pedig a tankgyárak (és termelnek 2 tankot).

És hogy néz ki ez a gyakorlatban?

1. Előállítunk egy bolygo_gyar_eroforras táblát, ami bolygónként megadja, hogy melyik gyárból hány van, ezek az egyes erőforrásokból mennyit használnak fel, és milyen arányban osztoznak rajta:

   select bgy.bolygo_id,bgy.gyar_id,gye.eroforras_id,bgy.aktiv_db,gye.io,if(gye.io>=0,0,floor(100*bgy.aktiv_db*gye.io/sumiotabla.sumio)) as reszarany
   from (
   	select bgy.bolygo_id,gye.eroforras_id,sum(bgy.aktiv_db*if(gye.io>=0,0,gye.io)) as sumio
   	from bolygo_gyar bgy,gyar_eroforras gye
   	where bgy.gyar_id=gye.gyar_id
   	group by bgy.bolygo_id,gye.eroforras_id
   ) sumiotabla,bolygo_gyar bgy,gyar_eroforras gye
   where bgy.gyar_id=gye.gyar_id and bgy.bolygo_id=sumiotabla.bolygo_id and gye.eroforras_id=sumiotabla.eroforras_id

2. A következő a bgy_eff tábla, ami bolygónként megadja a gyárak effektív számát, vagyis hogy hány működik közülük az adott körben (a fenti példában 4 tankgyárból 2 működik):

   select bgye.bolygo_id,bgye.gyar_id,min(if(bgye.io>=0,bgye.aktiv_db,if(bgye.aktiv_db*bgye.io*100+be.db*bgye.reszarany>=0,bgye.aktiv_db,floor(-be.db*bgye.reszarany/100/bgye.io)))) as effektiv_db
   from bolygo_gyar_eroforras bgye,bolygo_eroforras be
   where bgye.bolygo_id=be.bolygo_id and bgye.eroforras_id=be.eroforras_id
   group by bgye.bolygo_id,bgye.gyar_id

3. Ebből már meghatározható, hogy melyik bolygón melyik erőforrás mennyivel változik (deltatabla):

   select be.bolygo_id,be.eroforras_id,sum(gye.io*bgy_eff.effektiv_db) as delta
   from bgy_eff,bolygo_eroforras be,gyar_eroforras gye
   where be.eroforras_id=gye.eroforras_id and be.bolygo_id=bgy_eff.bolygo_id and bgy_eff.gyar_id=gye.gyar_id
   group by be.bolygo_id,be.eroforras_id

4. És végül update-eljük a bolygo_eroforras táblát:

   update bolygo_eroforras be,deltatabla
   set be.db=be.db+deltatabla.delta
   where be.bolygo_id=deltatabla.bolygo_id and be.eroforras_id=deltatabla.eroforras_id

Megjegyzés: a bolygo_gyar tábla aktiv_db mezője azt adja meg, hogy hány gyárat működtetünk (ennek akkor lehet szerepe, ha valamiért vissza akarjuk fogni a gazdaságunkat gyárrombolás nélkül). A bolygo_gyar_eroforras táblát ténylegesen is előállítjuk, mert ez csak akkor változik, ha épül vagy lerombolódik egy gyár. A többi hármat viszont össze lehet pakolni egyetlen összetett lekérdezésbe.

És hogy mennyire gyors?

A legkorábbi változat egy E6300 Core 2 Duo-n, 5 erőforrással, 5 gyárral és 10ezer bolygóval 3,4s alatt futott le. MEMORY táblákkal (ezek állandóan a memóriában vannak, így nem kell szarakodni az I/O-műveletekkel, viszont ha kifagy a gép, akkor elveszik a tartalma) ugyanez csak 0,8s. A fenti javított verzió pedig 0,5s.

Mivel a játék várhatóan hónapokig fog tartani, nem kell másodpercenként termelnie a gyáraknak, hiszen úgysem ülnek ott a játékosok folyamatosan, hogy reagáljanak. Ezt majd a tesztfázisban lehet rendesen belőni, de nagyságrendileg az 5-10 percenkénti frissítés jónak tűnik. Ez alapján pedig a fél másodperc futási idő teljesen elfogadható.

Röviden: egy massively multiplayer online stratégiai játék blogja a fejlesztés kezdetétől a játék indulásáig, és túl...

És hosszan?

Massively multiplayer, azaz olyan játék, amiben van egy ún. perzisztens világ, és a játékosok számának csak technikai korlátai vannak. Vagyis több százan-ezren játszhatnak vele egyszerre, és ha épp valaki nincs bejelentkezve, tőle függetlenül is történnek az események, termelnek a gyárak, ölnek a katonák, vagy amiről épp a játék szól.

Na de miről szól?

Amikor felmerült, hogy írjunk online játékot, nagyjából semmi nem volt kitalálva. Mondjuk annyi, hogy legyen stratégiai (az RPG-vel vannak problémák). Meg hogy nem lenne rossz, ha a szokásos irtsd ki az ellenségeden kívül valami "pozitív" is lenne benne. Például környezetvédelem vagy együttműködés másokkal vagy ilyesmi. Aztán leültünk agyalni. Ennek eredménye egy rakás szuper ötlet volt, amik persze másnap (a megvalósíthatóság, játszhatóság, részletek fényében) már nem is tűntek olyan szupernek. Végül az űrstratégia lett a befutó.

A részletek még nincsenek teljesen kidolgozva, de az alap az, hogy van egy bolygód, és innen indulva kell meghódítanod a Galaxist (eXplore, eXpand, eXploit, eXterminate). Persze a dolog ennél jóval bonyolultabb. A hódításhoz kell hadsereg, technika, diplomácia. A hadsereghez és a technikához gazdaság. A gazdasághoz emberek és kereskedelem. Az emberekhez élhető bolygó. Itt lép be a zöld-vonal, ugyanis a bolygóknak van ökoszférája, vagyis nem elég agyatlanul építeni a gyárakat, a fenntarthatósággal is törődnöd kell. Ugyanígy a győzelemhez az sem árt, ha barátokat, szövetségeseket szerzel, akikkel kereskedni és kooperálni tudsz. Szóval a cél egy olyan játék, ami kellően komplex ahhoz, hogy sokáig érdekes és élvezetes legyen.

Játék még nincs is, de blog már van?

Pontosan. Méghozzá két okból. Egyrészt így lehetőség van arra, hogy a játék fejlesztése közben minél több ötletet, visszajelzést kapjunk, amiket be lehet építeni, és amik remélhetőleg még jobbá teszik majd a játékot. Linus törvénye szerint "elegendően sok bétateszter és társfejlesztő mellett majdnem minden probléma gyorsan felismerhető, és a javítás is nyilvánvaló valaki számára." Érdemes talán ezt az elvet kiterjeszteni a fejlesztés korai szakaszára.

Másrészt ott a dolog marketing oldala is. Hiszen hiába szuper egy játék, ha a kutya sem használja. Éppen ezért fogunk rendszeresen jelentkezni, újabb részletekkel, feature-ökkel, screenshot-okkal, hogy mire ténylegesen elindul a játék (várhatóan valamikor ősszel), már legyen egy csomó lelkes játékos is.

Miért éppen Aldebaran?

Az Aldebaran egy vörös óriás a Bika csillagképben. Ha az α Centauriról el lehetett nevezni annó játékot, akkor az Aldebaranról miért ne? A név egyébként innen jött (és még nem is végleges):

Aldebarannak szép s takaros
Lányai tettre merészek,
Fess idegennel, hogyha csinos,
Ágyba bebújni is készek.
Megtesznek véle bármit is ott,
Mire áhító szelleme vágy',
De ha szétszedve juthatok el csak oda,
Nem vonz az űrbeli ágy.

(Douglas Adams - Vendéglő a világ végén, ford.: Nagy Sándor)