Vita:Star Wars Galactic Battlegrounds szkriptek

Az oldal más nyelven nem érhető el.
A Wikikönyvekből, a szabad elektronikus könyvtárból.

Tudálékoskodás[szerkesztés]

A Genie szkriptekről általában[szerkesztés]

A szkriptfuttatási folyamat háromtényezős modellje[szerkesztés]

A szkriptnyelv, ill. elemeinek részletesebb jellemzéséhez a következőket kell végiggondolni. A játék minden egyes futtatásakor egy olyan folyamat játszódik le, amely a szkriptírás mibenlétének szkriptíráshoz elegendő mélységű megértése szempontjából mindössze három fontos tényezőre különíthető el:

  1. A Szkriptíró (Szkripter).
  2. Maga a Szkript, mint fájl ( _ _ _.txt, azaz _ _ _ .AI).
  3. A számítógép - értve ezen egyszerre a hardwereket, az operációs rendszert és az ezek által irányított futású battlegrounds.exe alkalmazást és kiegészítőit - mindezen elemeket többé-kevésbé egységnek gondolhatjuk, pusztán a következő szétbontás szükséges:
    1. ennek az egységnek a szkript irányította része, a CP-t (computer player)
    2. a számítógép által a játékkal kapcsolatban futtatott folyamatok összes többi része, amelyet a CP Játékkörnyezetének (JK) vagy alkalmazáskörnyezetének (stb.) nevezhetünk.

Szkripter <=> Szkript <=> JK <=> Szkripter

Az útmutató-írók többsége azonosítja Szkriptet mint fájlt a CP-vel. Ez azonban túlegyszerűsítés: sokszor érdemes a CP-ről mint egy konkrét játékfuttatás (játszma) egyik eleméről beszélni (konkrét CP), különösen, ha akciók végrehajtásáról van szó; azonban egy Szkript valójában potenciálisan végtelen sok játszma részeként is lefuthat, sokszor egészen más eredményt adva, az utóbbi, a Szkripthez kötődő CP-fogalom absztraktabb.

A szkriptfuttatás mint kommunikációs folyamat[szerkesztés]

Ezekre az egységekre lebontva a folyamatot, nem kétséges, és nem is meglepő, hogy az egyes egységek között adatcsere vagy információcsere, azaz kommunikáció történik. Nem meglepő, lévén a számítógép nem más, mint egy sokfunkciós adatfeldolgozó gép, amelynek részei között, az adatfeldolgozó mibenlétből következően, az adatcsere, -áramlás nemcsak szükség-, hanem rendeltetésszerű.

Kevéssé lényeges, de Szkripter mint adó és Szkript mint vevő közti oda jellegű kommunikáció lényegében offline (azaz nem runtime) jellegűnek tekintendő. Ha Szkripter adatokat akar közölni Szkripttel, vagyis szerkeszteni akarja az AI fájlt, akkor a játék futását legalább időlegesen meg kell szakítania; Szkript futását mindenképpen. A Szkript a játék-környezeten, elsősorban az output-perifériákon át azonban online is vissza kommunikálhat Szkriptíróval, ám ez lényegében közvetett kommunikáció, hiszen a játék-környezeten keresztül történik.

A Szkript viszont runtime módon kommunikál a játék-környezetével, és viszont. Szkript mint adó és JK mint vevő között az oda kommunkáció elsősorban az akciók vezérlésre, végrehajtásra átadását jelenti, míg a vissza irányú kommunikáció azt, hogy a Szkript megpróbálja ellenőrizni azokat a tényeket, melyek benne mint szövegben listázva vannak.

Adatosztályok: deskriptív és imperatív adatok[szerkesztés]

A kommunikáció lényege az adatcsere, adatáramlás. Azonban a ma legelterjedtebb Neumann-architektúra, Neumann-modell vagy Neumann-paradigma szerint felépülő számítógépekben az adatok kétféle funkciót is elláthatnak. Adatok tárolják az információkat, amelyeket a számítógép feldolgoz. Másrészt az ilyen jellegű adatokkal azonos formátumban kell tárolni (Neumann "negyedik" posztulátuma) az adatokat feldolgozó tevékenységek irányítókódjait, a parancsokat vagy utasításokat is. A legtöbb Neumann-modell szerint felépülő programnyelvben, így a Genie szkriptekben is, ez a kétféle adattípus, noha jól elkülöníthető, ám ugyanakkor végső soron azonos formátumú. Az informatikai értelemben adatnak vagy információknak nevezhető jelsorozatok két nagy osztályra oszlanak: a deskriptív jellegű vagy input-output adatokon végzi a program azok átalakítását, míg az átalakítást vezérlő folyamat leírása, a folyamat vezérlése az imperatív avagy vezérlő jellegű adatok dolga.

Másféle számítógépépítési paradigmák is léteznek, pl. a Harvard-modell szerint követelmény a vezérlési és az input-output adatok egyértelmű elkülönítése és más-más formában való közlése és tárolása (ez nagyon megnehezíti pl. a vírusok készítését). Ám a személyi számítógépek a Neumann-architektúra szerint épülnek fel jelenleg. Ennek előnye a többfeladatúság, a gép rugalmas használhatósága, programozhatósága anélkül, hogy ez jelentősebb mérnöki, hardwer-építési szakértelmet igényelne.

Mint minden számítógépes program, mint minden fájl, a Genie Szkript is természetesen Adatok halmaza. Tágabb értelemben adaton bitek/bájtok olyan legkisebb halmazát értjük, melyek együtt képesek a JK-et adott programállapotból hibaüzenet nélkül egy különböző programállapotba juttatni. (?)

A deskriptív adatrendszer a Genie szkriptnyelvében[szerkesztés]

A Genie adatainak alapvetően numerikus jellege[szerkesztés]

A Genie szkriptnyelvének nem-felhasználóbarát alapformája szerint a deskriptív adatok mindegyike egész szám. A szűkebb értelemben vett, deskriptív adatok e szkriptnyelvben felhasználói szinten valójában mind numerikus jellegűek ... illetve azok lennének, ha a nyelvben nem lenne lehetőség a konstansdefiniálásra, és nem létezne a gamedata.drs fájl, aminek egy komoly része egy "felhasználóidegen szám-azonosító" -> "felhasználóbarát szöveg-azonosító" szótárat alkotó defconst parancsokból áll. A konstansok mögött - feltételezem - azonban egy numerikus rendszer áll.

Játékelemek[szerkesztés]

Azokat a konkrét virtuális tárgyakat, illetve az ezekhez rendelt bizonyos tulajdonságokat és viszonyfogalmakat, amik segítségével a játék leírható, és amelyek valamilyen szinten és módon megjelenítődnek a játékkörnyezet által vezérelt output perifériákon, játékelemeknek nevezzük. Játékelemek elsősorban, de egyáltalán nem kizárólag, az aktorok, azaz az épületek (egy konkrét épület a képernyőn), az egységek (egy konkrét egység a képernyőn) és a technológiák. Játékelemeknek számíthatóak még az aktorok bizonyos absztraktabb típusai vagy osztályai (pl. irányítóközpont, mint épülettípus), és egyes attribútumai, mint pl. a számuk (azaz hogy hány van belőlük egy adott pillanatban) vagy bizonyos absztrakt, a játékba épített feltételek (hány építhető belőlük összesen).

Itt egy iskolás jellegű definíciót természetesen nagyon nehéz adni. Játékelemek, röviden, a játék elemei és azok olyan tulajdonságai, melyeknek a játék lefolyásában, s ezáltal a szkripttervezésben stratégiai jelentőségük van.

Játékelem-lista[szerkesztés]

Az elérhető játékelemek - minden bizonnyal - akár listába is szedhetőek, ha végigfutjuk a Genie nyelv beépített szimbólumait és kigyűjtjük, mikre vonatkoznak. Ez tekinthető újabb definíciós kísérletnek. Az elérhető játékelemek a Star Wars Galactic Battlegrounds-ban tehát a következők:

Load-if használta játékelem-azonosítók[szerkesztés]
  1. Térkép-és játszmabeállítások
    1. Játékos és civilizációs azonosítók (GAIA, REBEL, stb.)
    2. Játszmatípus-azonosítók (DEATHMATCH, TERMINATE, KING-OF-THE_HILL, MONUMENT_RACE, DEFEND-MONUMENT)
    3. Erőforráskonfiguráció-azonosítók (LOW-, MEDIUM-, és HIGH-RESOURCES-START)
    4. Térképméret-azonosítók (TINY-MAP, SMALL-MAP, MEDIUM-MAP, NORMAL-MAP, LARGE_MAP, GIANT-MAP)
    5. Térképtípus-azonosítók (48 db., pl. MOTHERLODE-MAP)
    6. Győzelmifeltétel-azonosítók
    7. Nehézségifokozat-azonosítók
    8. Népességhatár-azonosítók
    9. Játéksebességbeállítás-azonosítók (GAME-SPEED-LOCKED)
    10. Egyéb játszmabeállítás-azonosítók (TEAMS-LOCKED), gyaníthatóan nem elérhető a "reveal-map" és az "all techs" állapotok azonosítója.
Tényekben használható azonosítók[szerkesztés]

Konkrétak, statikusak, konstansok

  1. Játékosazonosító konstansok (GAIA, 0, 1,2,3,4,5,6,7,8)
  2. civilizációazonosító konstansok (rebel, gungans, wookies, naboo, empire, federation)
  3. játszmabeállítás-leíró igazságérték-konstansok (0,1 - death-match-game és cheats-enabled paramétere)
  4. győzelmifeltétel-azonosítók
  5. aktor azonosítók
    1. épülettípus-azonosítók
    2. összevont épülettípus-azonosítók
    3. egységtípus-azonosítók
    4. összevont egységtípus-azonosítók
    5. technológia-azonosítók
      1. speciális: korszakazonosítók
    6. faltípus azonosítók (can-build-wall paraméter)
  6. erőforrásnevek (metal/ore, nova, food, carbon)

A játékelemek osztályzása[szerkesztés]

Összefoglalva a fenti lista tanulságait, megállapítható, hogy a játékelemek a következőképp osztályozhatóak:

  1. Objektum típusú elemek
    1. Aktor típusú elemek
      1. Konkrét aktor-típusú elemek
        1. Épületek
        2. Egységek
        3. Technológiák
      2. Absztrakt aktor-típusú elemek
        1. Épülettípusok
        2. Egységtípusok
        3. Technológia-típusok
    2. GAIA típusú elemek
      1. Talajok
      2. Talajelemek (sziklák stb)
      3. Erőforrások (szénsziklák, fák stb.)
        1. Passzív erőforrások
        2. Támadóképes erőforrások (ehető vadállatok)
      4. Akadályok (ehetetlen vadak és banditák, esetleges gaia katonák stb.)
      5. Szerzemények (holokron, elfoglalható emlékművek, gaia épületek)
  2. Attribútum típusú elemek
    1. Aktor-típusokat leírók
      1. Aktortípusok száma a térképen
    2. Erőforrásokat leírók
  3. Esemény típusú elemek
    1. Játékidő típusú elemek
    2. Észlelés típusú elemek (?)
      1. Erőforrás észlelése
      2. Aktorok észlelése
      3. Támadás észlelése
      4. Képesség fennállása
        1. Építés
        2. Egységgyártás
        3. Kutatás
        4. Speciális parancsok végrehajtása (pl. can-spy)

A játékelemek input-elérhetősége a parancsok által[szerkesztés]

A játékelemek egy része elérhető, szabályozható a szkriptnyelv által, más részük közvetlenül nem irányítható, nem elérhető, horizonton kívüli. Ilyen példákat könyvünk bevezetésében említettünk: nem elérhető játékelemek pl. a térkép térbeli irányai: észak-dél-kelet stb., illetve az épületek szomszédsági viszonyai bizonyos esetekben stb. A dolgot bonyolítja, hogy egyes játékelemek input jelleggel elérhetőek, míg output jelleggel nem; - pl. vadállatokra a konstansok útján lehet bemenő adatfeltételként hivatkozni, ámde nincs olyan akciótípus, ami közvetlenül egy vadállatot irányítana. A vadállat fajta objektum tehát inputnyílt, de output-zárt, fontos ilyen példa trovábbá az épületek és egységek kezdeti, játszma eleji konfigurációja, összetétele. Inputzárt, outputnyílt elem nem jut eszembe, de meglepődnék, ha nem lenne.

Természetesen a jelen szakaszban, ami a deskriptív adatokról szól, az inputnyíltság és inputzártság érdekes, hiszen az output vég már a parancsok, az imperatív adatosztály által vezérelt dolog.

Az inputnyíltság feltétele, hogy kell lennie egy akár egyszerű, akár összetett; és akár beépített, akár felhasználói azonosítónak, ami segítségével a játékelem egyáltalán megnevezhető. Nem meglepő módon ezeket az azonosítókat játékelem-azonosítóknak nevezzük.

Említettük, hogy a játékelem-azonosítók egy része beépített, azaz a nyelvben egyetlen szimbólum segítségével leírható. Az összes többi összetett azonosítót felhasználói azonosítónak kell tekintenünk. A helyzetet azonban bonyolítja, hogy a felhasználói azonosítók is lehetnek egyszerűek.

Pl. a building-type-count BLDG-MAIN egy összetett, tehát felhasználói azonosító, amely egy elvont játékelemet, mégpedig a CP-nek a játszma aktuális állapotában felépítve lévő irányítóközpontjainak számáét adja meg. Maga a BLDG-MAIN egy egyszerű és beépített azonosító, amely egy szintén absztrakt játékelemre, mégpedig az "Irányítóközpont" épülettípusra vonatkozik. Az ennek megfelelő konkrét játékelemek, az irányítóközpontok egyénileg nem igazán input-elérhetőek.

Környezeti elemek[szerkesztés]

A játék bizonyos azon elemeit, amelyek nem jelennek közvetve, vagy csak nagyon közvetve jelennek meg az output-perifériákon, környezeti elemnek nevezem. Hogy egy képzavarral éljek, a környezeti elemek a nem játékelemszerű játékelemek.

A környezeti elemek nem közvetlenül a CP-re hatnak, mint akciók, hanem a CP belső kognitív világához tartoznak, a szkript szerkezetének elemeit képezik. Ilyen speciális elemek:

  1. A goal-ok azonosítói;
  2. A timerek azonosítói
  3. Triggerekkel kapcsolatos azonosítók
  4. ide vehetőek leginkább a true és false tényelemek is.

Nem állítom, hogy eme szétválasztás ne lenne bizonyos értelemben mesterséges, szubjektív. Pl. érvelhetünk amellett, hogy amikor egy CP rendszeres rushingolást hajt végre, akkor a tapasztalt szkripter bizonyára gyanakszik, hogy legalább egy timer működik a háttérben. Tehát a timer hatása, nagyon közvetett módon ugyan, de megjelenik a képernyőn mint output-periférián. Mindenesetre nem lehet ebben biztos, és esetleg más eszközökkel is magyarázhatja a jelenséget.

Az imperatív adatstruktúra a Genie szkriptnyelváben[szerkesztés]

Szkripter-irányú és JK-irányú parancsok[szerkesztés]

A Szkriptben a tények és akciók leírását a defrule parancs fogja össze. A defrule parancs szerepe tehát elsődlegesen az, hogy jelezze, hogy egy szkriptrészt nem a Szkripternek, hanem a JK kell értelmeznie.

Olyan jelző is van, ami azt jelzi a JK-nek, hogy egy adott fájlrész nem neki szól, hanem a Szkripternek. ez a komment-operátor (;).

Az tehát látható, hogy a Genie nyelvben legalább kétfajta parancs létezik: Szkripter-irányú és JK-irányú.

Szkripter-irányú parancsok[szerkesztés]

  1. A kommentelés
  2. defconst?



A szkriptnyelv jellemzésében kis nehézséget okoz, hogy a nyelv két ok miatt is nyílt:

  1. lehetőség van a defconst parancs által új azonosítók felvételére
  2. lehetőség van sztringek (fájlnevek és chat parancsok) beolvasására.

Mindezek miatt nem beszélhetünk a nyelv ábécéjéről, mivel ez potenciálisan végtelen. Az ábécé helyett kénytelen vagyok bevezetni az azonosító fogalmát. Azonosítón egy sztringet vagy egy szimbólumot értek.