Falcon 4.0

Ezennel elérkeztünk ahhoz az alkotáshoz, ami miatt az összes eddigi része a cikksorozatnak lényegében ennek felvezetésének fogható fel. Ez a Falcon 4.0. Egyes területeken ez jutott legmesszebb a szimulátorok evolúciójában annak ellenére, hogy még ezt követően volt egy utolsó nagy szimulátor kiadási hullám, ami kb. 2000-ig tartott.

A sorozat összes része a linkre kattintva érhető el.

https://militavia.blog.hu/tags/szimul%C3%A1tor_t%C3%B6rt%C3%A9nelem

A Falcon 4.0 hivatalosan 1998 decemberében 12-én jelent meg több, mint négy év fejlesztést követően. A projekt vezető programozója majdnem 5 évet említ a vele készült interjúban. Akkoriban ez eszementen hosszú fejlesztési időnek számított, a tipikus megaprojektek sem készültek 3-4 évnél tovább (és rendszerint megbuktak) az akkori hardverek gyors fejlődése miatt. Még manapság is csak a legnagyobb és méregdrága játékok készülnek ennyi ideig, 100 millió dolláros nagyságrendű költségvetéssel.

A Falcon 4.0 egy átmeneti időszakban volt fejlesztve, majd jelent meg. Még a 3D gyorsító kártyák megjelenése előtt kezdték fejleszteni, kiadásakor azonban már két éve elérhetőek voltak ezek, sőt már ezek második generációja is létezett a Voodoo 2 képében. Valószínűleg a hardveres környezet változása miatt is húzódhatott el a fejlesztés. A kiadást követően sikerült kiérdemelnie a minden idők (egyik) legbugosabb játéka címet. Ennek több oka is volt, de köszönhette annak is, hogy korának talán legkomplexebb játéka volt.

A Falcon 4.0-ban az F-16C Block 50/52 vadászgépek minél pontosabb modellezése volt a cél, ez volt az egyetlen repülhető típus. Ahogy korábban más játékoknál a ’90-es években, úgy itt is lehetséges volt az avionika és több más területen is a nehézségi szint beállítása. A legkönnyebb szinten szokás szerint kvázi arcade szintű játékká degradálódott le a repülőgép modellezését tekintve, de a környezet – az ikonikus dinamikus hadjárat, lásd majd később – egy egészen más dimenzióba jelentetett belépést. Annyiban sem lett arcade játék, hogy a nagyon egyszerűsített avionikai modellezés és annak kvázi elhagyása esetén is a játékos valóságos mennyiségű fegyverzetet hordozott, tehát semmilyen beállítás mellett nem lett belőle egy mezei lövöldözős játék. A dinamikus hadjárat még ilyen beállítással is teljesen más élményt jelentett, mint korábban bármi mással repülni.

Maximális nehézségű avionikai beállításnál szó szerint sokkolt a játék, elsőre azt sem tudtam, hogy mit csináljak. A F-14 Fleet Defendert leszámítva ilyen mélységű avionikai modellezéssel addig nem találkoztam. Ahhoz képest a Falcon 4.0 több volt, hiszen az F-16C többfeladatos vadászgép, csapásmérő feladatkörben is használatos. Ráadásul ez utóbbi bevetéseken igen széles fegyver választékkal rendelkezett. Akkoriban a Jane’s féle szimulátorokban már volt hasonló mélységű avionikai és repülésfizikai modellezés, de azokat akkor nem ismertem. (Amúgy csak 2001 nyarán jutottam hozzá a Falcon 4.0-hoz, patchek nélkül.) Azokban voltak különleges és egyedi dolgok a Falcon 4.0-hoz képest vagy egymással összevetve, de általánosan nem érték el a Falcon 4.0 szintjét, bár igen közel voltak hozzá szerintem.

A Falcon 4.0-nak a mai napig gyakorlatilag szinte teljesen egyedülálló vonása nem az avionikai modellezése, vagy grafikai megjelenítése, hanem a dinamikus hadjárata. Az több mint egy egyszerű újítás volt, forradalmi volt annak ellenére, hogy nem volt minden előzmény nélküli, lásd például a korábban bemutatott EF2000-et. Viszont a Falcon 4.0 megoldása messze többet valósított meg már 1998-ban az EF2000-hez képest. Az F-22 TAW (lásd a cikksorozat előző részét) dinamikus hadjáratának volt néhány jellemzője, amiben felülmúlta a Falcon 4.0-át, pl. az AWACS vadászirányító része, de a nagy összképet nézve az kevesebbet tudott. A mai napig a dinamikus hadjárat tartja életben a Falcon 4.0 szériát – pontosabban ezért érte meg később továbbfejleszteni. legalábbis ez az általános vélemény. De erről majd később, először ismerjük meg milyen is volt a játék alap kiadása.

A Falcon 4.0-ban a Koreai-félsziget volt az egyetlen helyszín. A modellezés mélységének növelésével egyre ritkább volt az, hogy több helyszín választható lett volna egy szimulátorban, egyszerűen nem volt erőforrás azok modellezésére. Viszont ezt az egy helyszínt három hadjárattal adták ki, és természetesen más játékokhoz hasonlóan lehetőség volt szóló bevetések repülésére is. A játék kiadásakor látszott, hogy hosszabb távra terveztek, mert a helyszínválasztásra alkalmas felület már készen állt, csak éppen Koreán kívül más nem volt ott. A hosszabb távra tervezés és nagyobb tervek dédelgetése egyébként magán az adatbázison is látszott, de erről majd szintén később.

Az eddigiekkel ellentétben először nem a géptípus modellezésének mélységének bemutatásával kezdem, hanem a környezettel, annak forradalmi volta miatt. A környezett alatt nem a grafikáját értjük. Sőt... A játék grafikáját az idő számomra nagyon megszépítette. Win7/10 korszak alatt előszedve és kipróbálva megdöbbenve láttam, hogy egyáltalán nem olyan szép, mint amilyenre emlékeztem, sőt kifejezetten rusnya egyes helyeken még az akkori mérce szerint is.

Bár nem teljesen fair összehasonlítani az egy évvel később kiadott Flanker 2.0-val. A 3D gyorsító kártyák és a hardverek fejlődésénél és ezek képességeinek kihasználásánál egy év igen sokat számított, de grafikai téren egyszerűen ordító az eltérés a kettő között a Flanker 2.0 javára. Ahhoz képest ugyanolyan, ha nem nagyobb volt a Falcon 4.0 hardver követelménye, ha mindent maximumra húzott a játékos. Ezt azonban nem a grafika, hanem a dinamikus hadjárat beállításai és a játék modellezési mélysége okozták.

F-16C Block 52 (bal) és Szu-27. Érdemes a Szu-27 kinézetét összevetni a Flanker 2.0-nál található első képpel. (Lásd lentebb). Hát, izé… Pedig mindössze egy év telt el a két játék kiadása között. Az F-16, a főszereplő jól néz ki, de a Szu-27-nél már kezd remegni a léc még 1998-as szemmel nézve is.

A gyakrabban felbukkanó repülőgépek a kor mércéje szerint éppen csak elfogadható 3D modellel rendelkeztek, de még ebbe a kategóriába esőknél is gyakran látni azt, hogy nemigen törték magukat. Nincs mit ezen szépíteni, helyenként a 3D modellek és skinek kifejezetten ocsmányak voltak. Ez az erőforrás optimalizálás eredménye is lehetett, de az sem kizárt, hogy a kapkodás és a sürgetett kiadás miatt alakult így. Lehetséges, hogy korábban elkészült 3D modellek és skinek maradtak a játékban, még az akkori hardverek korlátainak megfelelők, majd újabbak készítésére már nem maradt idő. A furcsa az, hogy a szárazföldi egységek átlagos kinézetét – szem előtt tartva a szép kinézetet és funkcionalitást egyaránt – valahogy jobban sikerült belőni, mint a repülőgépekét.

A játékban már minden objektum (épületek, hidak, repterek stb.) és jármű (repülőgépek, tankok stb.) textúrázott volt, de egyes hordozott fegyverek (rakéták, bombák stb.) még nem. A textúrák viszont sokszor a már korábbi alkotásoknál említett „mákos tészta” jelleget idézték. Alant néhány kép a gyakrabban előforduló gépekről, érdemes lesz összevetni majd a Flanker 2.0-val. Látható, hogy köszönőviszonyban sincs a két alkotás egymással grafikailag. Az összehasonlításnál meg kell még azt is jegyezni, hogy a Falcon 4.0 kiadásakor legfeljebb 800x600-as felbontást támogatott, míg a Flanker 2.0 emlékeim szerint támogatta már az 1024x768-as megjelenítést is. (Később a játék javításai tették elérhetővé az 1024x768-as felbontást is, de ebben nem vagyok biztos, de ezt egy másik forrás is megerősíti.[1])

A Falcon 4.0 kortársa a Jane’s IAF (1998 végén adták ki) és a szintén egy évvel későbbi, de gyakorlatilag azonos motorral futó Jane’s USAF is annak tekinthető. A főbb repülőgépek klasszisokkal szebben néztek ki mindkét Jane’s féle játékban, csak hát az azokban levő tartalom jellege és minősége más volt, de erre még visszatérünk egy másik epizódban.

F-15C (bal) és F-111. Ezeket is érdemes a Flanker 2.0-hoz mérni. Még az rossz minőségű képen is fényévekkel szebb a Flanker 2.0. Ezen felül az F-111-nél a fegyverfelfüggesztők nem követik a szárny nyilazását. Egészen elképesztő, hogy ebben az állapotban hagyták, még ha csak másodhegedűs típusról van szó. Ennél még az is elfogadhatóbb lett volna, ha inkább nem is jelenítik meg a fegyverzetet a gép alatt.

MiG-21 (bal) és MiG-23. A MIG-21 textúrájára nehéz szavakat találni, a 3D modell szemmel láthatóan igen kevés poligonból áll. Mindkét esetben igaz, hogy gyakorlatilag gépek főbb méretei se stimmelnek. A típusok persze felismerhetők, de közelében sincs a Flanker 2.0 színvonalának, de még a kicsit régebbi Jane’s IAF vagy USAF-tól is elmarad. A MiG-21 kinézete már 3-4 évvel korábban is gyenge lett volna, de 1998 végén erre leginkább az igénytelen jelző használható.

A szárazföldi egységek jól beazonosíthatók, még az azonos alvázra alapuló egységek esetén is. Balra fent AAV-P7/A1, nem egyszerűsítették le a geometriáját, sőt, skint is kapott. Jobbra fent a LAV-25 és annak későbbi speciális változatai, jól látható a különbség. Egészen sajátos kontrasztot mutatnak egy repülőgép szimulátorban, hogy a repülőkhöz képest a szárazföldi egységek sokszor szebben voltak kidolgozva, mint néhány repülőgép.

Az M1 harckocsi, nemcsak jól felismerhető, de a textúra is szép a kor szintjén. Jobbra SA-8B (9K33 OSzA-AKM). Ezek majdnem olyan szépek, mint a későbbi Flanker egységei bár azt hozzá kell tenni, hogy a Falcon 4.0-ban sem a lánctalp, sem a kerék nem forgott, ezek nem voltak animálva. Érdekes, hogy a földi egységek színvonala jobban megfelelt a kor követelményeinek, mint sok repülőeszköznek.

Ezután térjünk át a táj kinézetére. A játék a városokat nagyrészt csak domborzatra illesztett textúrával jelenítette meg, de ezt kombinálta generikus 3D városelemek felhasználásával. Az adatbázis különféle épületeket tartalmazott, ezek variálásával hoztak létre nagyobb objektumokat. Ez lehetett város, katonai bázis, reptér stb. Ezért van az, hogy egyes épületek és támaszpont elemek pl. mindkét oldal repterein és városaiban is megtalálhatóak. Az észak-koreai és orosz repterek, városok stb. a generális elemek miatt „nyugatiasan” néznek ki és nem a Szovjetunió, Varsói Szerződés vagy szovjetbarát országokban megszokottakra hasonlítanak. Ez egyáltalán nem reális, viszont így lehetett spórolni az erőforrássokkal. Na, nem mintha akkoriban ezt a részletességet bárki elérte volna ilyen grandiózus léptékben. A térkép ugyanis kb. ezres (!) nagyságrendű ilyen objektum csoportot tartalmazott.

Szöul környéke. A város többnyire textúra és néhány 3D-s épületből állt.

Szöul környéke. A reptér és az olimpiai létesítmények. A textúrák ismétlődése jól látható.

A fenti szisztémát időnként megfejelték „landmark” típusú objektumokkal. Szöulban pl. az olimpiai létesítmények egyedi 3D modellel bírtak, ahogy egyes repterek megjelenítése (pl. Szöul) is eltért a „típusrepterektől”. Az észak-koreai fővárosban meg megtalálható volt a mára elhíresült presztízsberuházás, az akkor még torzóként álló piramis formájú szálloda.

http://en.wikipedia.org/wiki/Ryugyong_Hotel

A táj textúrája azonban egyes objektumok környékét leszámítva ismétlődően felhasznált elemekből épült fel, és ezzel teremtett részben variálható környezetet. Ezzel is erőforrást és rengeteg manuális szerkesztést lehetett spórolni, sokkal kevesebb számú és méretű textúrával volt lefedhető a teljes térkép. Másrészről viszont természetellenes lett a látvány egy ponton túl, ami sokakat zavart akkoriban, és a későbbi változatokban is. Az más kérdés, hogy pont ez tette lehetővé azt, hogy később más helyszíneket készítsenek hozzá. (Erre majd később visszatérek.) A táj textúrájának felbontása viszont jobbnak tűnt, mint a Flanker 2.0-é, de a különbség elhanyagolható, inkább csak egyéni preferencia kérdése a dolog szerintem. Még ha a más kortárs szimulátorok textúrafelbontása kisebb is volt, azok nem voltak annyira ismétlődőek, az összhatás sokak szemében jobb volt.

V formájú kifutópálya elrendezés a valóságban és a játékban a Szöul közelében levő reptéren. A kép a játékból nem az eredeti kiadás, hanem már a Realism Patch 5 idejéből van. Az F-16C 3D modellje más, de a reptér kinézete még azonos az eredetivel.

Az olimpiai park a játékban és a valóságban. A képen az is látható, hogy a városok hogyan épülnek fel. Néhány 3D modell és textúra. Az egy évvel későbbi Flanker 2.0 ezen a téren is klasszisokkal szebb volt.

A környezetnél még egy tényezőről nem esett szó, az időjárásról. Nem találok sem ilyen képet sem utalást a játék kézikönyvében arra, hogy lett volna időjárás vagy felhők, csak nappal/éjszaka váltás volt a környezetben, a szélirány azonban nem volt állandó, de soha nem volt igazán tényező. Szó se róla, más játékban sem voltak meg ezek akkor emlékeim szerint, legfeljebb a felhők, de komoly vihar, eső, évszak beállításának lehetőségéről szó sem volt.

A környezet másik alapvető része a taktikai környezet modellezése. Ez az rész, ahol a Falcon 4.0 a mai napig lényegében egyedülálló megoldással bír, annak léptéke és jellege miatt is. Csak egy helikopter szimulátorban, az Enemy Engaged 2-ben (ami inkább arcade jellegű volt) találkoztam hasonlóval a 2000-es évek közepén. Ennek első részében is dinamikus hadjárat volt, de ez inkább csak taktai szinten mozgott (amennyire ismerem), stratégiain nem. A Falcon 4.0 dinamikus hadjárata már stratégiai szintű volt. Ezt igen erős absztrakcióval tette amiatt, hogy részben játéktechnikai fogásként kezelte, a maximális realizmus soha nem lehetett cél és nem is volt rá szükség.

Mit is takar a dinamikus hadjárat a Falcon 4.0-ban? Huh, hát ezt nem lesz egyszerű elmagyarázni tömören… A hadjáratmotorral, nagyléptékű hagyományos háború modellezésére vállalkoztak, ennek megfelelően épült fel az egész játék struktúrája, ennek minden előnyével és hátrányával. A táj grafikai megjelenítése is ennek „áldozata” részben.

Már az EF2000 és az F-22 TAW is alkalmazta azt a módszert, csak nem volt annyira feltűnő, hogy nem minden zajlott a „3D” világban. A játékos körül egy adott távolságban léteznek csak a „3D” világban a harceszközök, azon túl a program egyfajta speciális valós időben zajló stratégiai játékként (RTS = real time strategy) módon működik, statisztikai értékekkel írta le az egyes egységeket és a köztük levő interakciót, így spórolva erőforrást. Egy háborúban több ezer harc- és légvédelmi jármű vesz rész, egyszerre százas nagyságrendű repülőeszköz lehet levegőben. Egy ilyen környezet modellezése magával hozza a változatos és részben véletlenszerű taktikai környezetet úgy, hogy a játékosnak ennek élvezetéért semmit sem kell tennie. Csak a hadjáratot kell elindítani, nem kell órákat pepecselni küldetések összerakásával. Ennek megteremtéséhez azonban súlyos kompromisszumok szükségesek. Sejthető, hogy emiatt nem volt szárazföldi csapatok közötti harc az F-22 TAW-ban és csak légvédelmi szárazföldi egységek voltak az EF2000-ben.

A Falcon 4.0 lényegében az EF2000 és a F-22 TAW alkotásokból még hiányzó, szárazföldi háborúval kiegészített, de már megszakítás nélküli, folyamatosan futó, illetve a további elemek miatt sokkal összetettebb dinamikus hadjáratot kapott. A Falcon lényege nem egy gép tűpontos modellezése – bár a kor szintjén itt is kiváló volt – hanem annak az élménynek környezetnek a megteremtése, amit egy F-16 pilóta tapasztalna egy hasonló konfliktusban. Ezt a készítők is megfogalmazták egy interjúban.

Nemhogy akkor, de ma sem létezik olyan asztali számítógép – talán még kisebb számítógépes hálózat sem – ami képes lenne a szükséges számítási kapacitást biztosítani ahhoz, hogy több ezer egységgel operáló hadjárat modellezhető legyen mindenféle megkötés nélkül a „3D” világban. Egy szimulátorban a harcászati avionikai modellezés miatt minden objektum és jármű között távolság és irányszög számítást kell végezni másodpercenként akár többször is, mint bemenet a további avionikai és egyéb számításhoz. Ilyen például a radarok felderítési távolsága, besugárzásjelző érzékenységnek modellezése, MI pilóta vizuális látóterének számítása, aerodinamikai számítások minden gépre stb. Ettől a szükséges erőforrásigény exponenciálisan emelkedik és gyakorlatilag elszáll a végtelenbe egy adott egységszám felett.

Ezért az egységek és objektumok a játékoshoz képest egy bizonyos távolságon belül átkerülnek a „3D” világból a „2D” világba, ahol sokkal kevesebb modellező érték írja le őket. Ez a „2D” világ lényegében egy valós idejű stratégiai játék, ahol a hadjárat motorja csoportokként és nem egyedi járművekként kezeli a harceszközöket. A dinamikus hadjárattal ellentétben a „single mission” részben –  ezt hívja tactical engagementnek – jellemzően sokkal alacsonyabb egységsűrűség mellett nagyobb távolság esetén is játszható képfrissítéssel futott a játék. Igazából ez volt a szűk keresztmetszet nem is annyira a grafikai beállítások. Egy akkori átlagos konfiguráción átlagos beállítással jól futó játéknál ezt a távolságot maximumra állítva simán átment képregénybe a megjelenítés, de még az átlagosnál sokkal erősebb konfigurációt is simán meg tudta izzasztani. Ennek a távolságnak az általános szorzóját állíthatóvá tették a játék grafikai beállításainál, ez volt a „player bubble”.

A másik trükk az volt, hogy a különféle egységek nem azonos távolságnál kerültek át a „3D” világba. Egy csak harckocsi és hasonló harcjárművekből álló csoportnál semmi szükség nincs arra, hogy 30-40 km-es távolságban a játékostól a „3D” világban grasszáljanak, mert ekkora távolságból is használható fegyverrel nem rendelkezett a játékos és az „mesterséges intelligencia” (MI) által irányított járművek sem. (Az más kérdés, hogy ez gátat szab a későbbi fejlesztésnek, ha valaki mégis ilyen fegyvert szeretne betenni a játékba.) A városok, épületek megjelenítésénél is felesleges azokkal foglalkozni, ha eleve olyan messze vannak, hogy amúgy sincsenek látótávolságban vagy bármilyen fegyver indítási zónájában.

Az persze már kérdés, hogy hálózatban levő játéknál a leggyengébb hardverrel bíró játékos határozta meg, hogy milyen beállítás volt lehetséges. Eltérő távolság beállítással nyilvánvaló, hogy az így modellezett világ összeomlana. Ha egy játékosnál egy repülő vagy bármilyen jármű már „3D” világban lenne, a másiknál meg nem az elég vicces lenne, hiszen az egyik játékos képes lenne lelőni azt, a másik meg nem. Ez fordítva is igaz, ha az MI által vezetett gépet nézzük. Ilyen praktikussági elvek szerint történt ennek a távolságnak beállítása. Pl. egy kis híd sokkal kisebb távolságról látszik, mint egy hatalmas reptér, de egy kis hatótávolságú Sz-125/SA-3 légvédelmi rendszer is később transzformálódik át pl. a nagy hatótávolságú Sz-200/SA-5-höz képest.

Persze azért látható, hogy a rendszernek enyhén szólva vannak buktatói, nem is kevés. Ugyebár a játékos köré épül fel a világ egyjátékos módban, de már itt is lehet érdekes helyzetet előidézni. Pl. mi van akkor, ha a játékos körül levő „buborék” szélén – így hívja a program azt, amikor valami a játékos körüli „3D” világban van – van egy MI vezette gép és az egy hozzá közel levő földi egységre pl. AGM-65 rakétát akar indítani, aminek az indítási távolsága már kívül eshet a játékos „buborékján”? Akkor az MI hogyan dolgozik a „3D” világból egy „2D” világban levő egység csoportra? Mi van akkor, ha több játékos egymástól igen nagy távolságra van, akkor ezek a „buborékok” hatalmas területet fednek le?

Számomra ismeretlen módon, de megosztott erőforrásokkal valahogy működőképes marad a játék – legalábbis késői verziói, az alap Falcon 4.0-val soha nem repültem online – ezen felül különféle kivételekkel megoldották a „2D” és „3D” világ közötti átjárhatóságot az MI által irányított gépek számára különleges esetekben. Ez volt az igazán nagy zsuga, annak megalkotása, hogy a rendszer koherens és működőképes legyen. Ami még nagyobb szó annak fényében, hogy az egyetlen ember alkotta meg, igen homályos útmutatások és elvárása alapján. A Falcon 4.0 dinamikus hadjárata lényegben overkill lett. Mert az egyik fejlesztő, Gilman Louie[2] csak annyit fogalmazott meg, hogy a játékban dinamikus bevetés generálás. Ezt valóban megoldotta a hadjárat motor, csak éppen ennél sokkal többet is. Erről és másról bővebben a lenti interjúban esik szó.

A jelenleg még most is aktív közösséggel bíró Falcon BMS4-ben nem ritkák az akár több tucat résztvevővel zajló online repülések úgy, hogy a játékosok által vezetett repülőgépek akár több száz km-re vannak egymástól és mégsem kell szuperszámítógép ahhoz, hogy fusson a játék. Így talán már érthető, hogy mitől volt olyan bugos anno a Falcon 4.0. A játék alapvető megoldása, hogy egyáltalán futtatható legyen a dinamikus hadjárat, számtalan hibára ad lehetőséget a komplexitása miatt. Ezen felül még ott van minden más, ami egy repülőgép szimulátornál hiba forrása lehet. MI, harcászati avionika modellezése stb.

Mit érzékelt ebből a bonyolult rendszerből a játékos? Átlagos esetben szinte semmit hátránya nem származott belőle, csak az előnyeit tapasztalta. A szobapilóta repkedett Korea egén, egyes egységek hol megjelentek, hol eltűntek ebben a „3D” világban, de a játékos látótávolságán kívül vagy a szenzorok felderítési határán túl. Tehát a játékos csak azt látta, hogy jönnek a vadászok, van légvédelem és zajlik odalent a háború, pedig minden csak az ő közelében került át a „3D” világba, ennek ellenére csak ritkán érezhette magát magányosnak. Repülés közben az ezen túlmenő eseményekről amúgy sem szerezhetett tudomást, mert látótávolságon vagy a radar észlelési távolságán túl zajlottak azok. Tehát a játékos „3D” világán kívül levő események is zajlottak, de azok már statisztikai alapon, a „2D” világban, a háttérben futó stratégiai játékban.

Csak a legkisebb „bubble” / „buborék” beállítás esetén volt az, hogy a játékos látta azt, hogy az egységek átkerültek a „2D” világból a „3D” világba vagy azt, hogy megjelennek egységek a „buborékon” belül nagy hirtelen, de erre csak a nagyon gyenge hardverek esetén volt szükség.

Hogyan kell elképzelni a „2D” világban zajló eseményeket? Vannak modellező értékek, amik a „3D” világban leírták egyes fegyverek, rakéták, repülőgépek kinematikai és egyéb jellemzőit, ahogy a harcászai avionika képességeit. Ezen felül a „2D” világban is vannak modellező értékek, csak éppen másmilyenek és összevonva, illetve sokkal kevesebb. A „3D” világban lövöldözhet egymásra pl. két tank és akkor azok életerejével, tűzerejével és lőtávolságával, egyesével számol, a repülőgépek manővereznek, számolja a program a rá ható erőket, a rakétáknál és a gépeknél minden egyes szenzor értéket egyedileg számol fizikai modell vagy azt helyettesítő modell paramétereivel. A harcászati elektronika közvetlenül, fizikán alapuló modellezése kereskedelmi szimulátorban lehetetlen a fizika és a titokvédelem miatt is.

Ezzel szemben a „2D” világban már a szárazföldi egységek egy csoportjának van összesített tűzereje, életereje, lőtávolsága, felderítési távolsága, mozgási sebessége, morálja, az, hogy milyen gyakran indít légiharcrakétát egy kötelék vagy légvédelmi rendszer stb. Ezek mozgás közben találkozhatnak, és adott távolságnál és a „2D” világban használt modellező értékekkel számolja az okozott és elszenvedett veszteséget a csoportok között. A repülőgépek sem egyesével, hanem kötelékenként mozognak. Persze ha lelőnek egy vagy több gépet, akkor a kötelék állhat egyetlen gépből is. Ezzel marad működőképes a rendszer és biztosítja a dinamikusságot és közel végtelen változatosságot. Azonos kezdőpontból indítva is gyakorlatilag nem létezik két azonos hadjárat a bevetések sikerességének és a célpontok generálásának volta miatt.

Mi ennek a rendszernek a hátránya? Az, hogy a „2D” világ absztrakciója statisztikai alapon működik. Lehetetlen olyan környezetet összehozni, ahol minden esetben a „3D” világhoz közeli eseményeket számol ki, a nagy átlagot azonban jól közelítheti. Még ezzel az egyszerűsítéssel is a „2D” világ eléggé összetett. A valószínűtlen események azonban csak statisztikai alapon történetnek meg, míg a „3D” világban a játékos tapasztalata és hibái nagymértékben meghatározhatják egy légiharc vagy csapásmérő bevetés kimenetelét. Ha a játékos vagy a bénázik, akkor egy négygépes MiG-21 kötelék akár le is mészárolhat egy kétgépes F-16 (vagy akár F-15) köteléket, ellenben a „2D” világban erre az esély nagyon csekély. Nincs ilyesfajta hibára lehetőség, pontosabban a játékos hibájából nem következhet be. Viszont a 2D/3D világ módszer nélkül lehetetlen ekkora léptékű dinamikus hadjáratot létrehozni ameddig otthon nincs a játékosoknak szuperszámítógépe és arra írt szoftvere…

Hogyan is zajlik egy hadjárat, hogyan kerül bele a játékos, illetve mit láthat és tapaszthat belőle? A játékban levő három hadjárat hadrendje (order of battle) kezdő állapotban fix, de ezek elérnek egymástól. Az egységek elhelyezkedése, helikopterek és repülők települési helye egy adott hadjáratban adott, de alakulatok/egységek nagysága és erőssége már nem, az függ nehézségi szinttől. Tehát pl. egy tank „zászlóalj” (battalion) vagy repülőszázad mérete eltérő más nehézségi szinten, de azok kezdő pozíciója azonos. Tehát pl. mindkét nehézségi szinten van egy  F-16 század pl. Oszan repterén, de könnyű szinten mondjuk 20 repülőgéppel kezdi a hadjáratot, a legnehezebben meg lehet, hogy csak 12-vel. Szintén a nehézségi szinttől is függ, ahogy a „3D” világban mire képes az MI, de a „2D” világban van is van hatása (elvileg). Az előre beállított nehézségi szinteken az ellenséges MI-t és az erőviszonyokat egyszerre állította a játék, de lehetőség volt az MI szintjét beállítani és a négy alapvető egységtípus – repülőeszközök, szárazföldi erők, légvédelem és hajók – erőviszonyait is külön-külön konfigurálni.

A dinamikus hadjárat lelke a játékos szemszögéből nézve az az air tasking order vagy az ATO volt. Az egész játék felépítésének célja ennek kiszolgálása, aminek egyébként kihatása van még a játék grafikájára is. Az ATO lényegében a folyamatosan automatikusan generált bevetések összességének a neve. Ez nem csak a játékos számára rendelkezése álló századokat takarja, hanem minden repülőeszközt a hadjáratban. A hadjárat mögötti „MI” Számtalan bemeneti paraméter alapján a súlyozással folyamatosan generálja a bevetéseket. A játékos meghatározhatja, hogy a térkép melyik részén legyen több vagy kevesebb bevetés és az egyes bevetéstípusok és célpontok közötti arányt is.

Egy 8 gépes támadó erő, F-16C és F-4E gépekkel. 4 F-4E gép a repteret támadja, 2 F-16C a vadászkíséret és 2 F-4E végül az eredményt lefotózó felderítő bevetést repül. (BDA – bomb damage assessment)

A játékos az F-16C századok bármelyikéhez csatlakozhatott, a program által generált bevetések közül választhatott. A hadjárat során bármikor megadható volt, hogy milyen bevetéseket és milyen súllyal generáljon a mesterséges intelligencia és a térkép mely területeire összpontosítsa az erőket, persze az adott gépek profiljának megfelelően. Tehát a beállítás globálisan hatott nem csak a repülhető F-16C századokra.

A játékos alapvetően befolyásolhatta azt a hadjárat alakulásától függően, hogy mire használja, hogyan és hol a légierőt. Ez a stratégiai léptékű beállítás határozta meg például, hogy mondjuk a vadászgépek inkább járőröztek (BARCAP) vagy inkább nagyobb számban kísérték az ellenséges légtérbe behatoló csapásmérőket (escort) vagy a szimplán szabad vadászatra (sweep) küldött vadászok közti arányt. De pl. azt is, hogy a térkép melyik részére koncentrálta az erőket az mesterséges intelligencia.

A többfeladatú (multirole) gépeknél – pl. a játékos által repült F-16C vadászoknál – ez döntötte el, hogy inkább vadászként operálnak vagy azt, hogy csapásérőként milyen típusú célokra mozdultak rá. Ezen beállításokkal való pepecselést a játékos rábízhatta a mesterséges intelligenciára is, nem volt kötelező ezzel foglalkozni és koncentrálhatott csak a repülésre. A hadjáratban betett egyes századoknak volt beállítva specializáció (air to air / air to ground, general), ami torzíthatta a globális beállításhoz képest a preferenciát, hogy az „MI” milyen bevetéseket generáljon.

Az, hogy a játékos csak F-16C-vel repült, nem jelentette azt, hogy nem találkozik más baráti géppel és nem működik azokkal együtt. Az ATO ugyanis a 2-4 gépes kötelékeket (flight) nagyobb csoportokba (package) rendezte, amik egy közös cél érdekében tevékenykedtek. Tehát, reptér támadás esetén volt mondjuk egy magát a repteret bombázó kötelék (OCA Strike), de volt mellettük vadászkíséret (Escort) és a légvédelmi radarok elleni kötelék (SEAD escort) a csoportban. Ezek nem feltétlenül voltak azonos típusok, a cél távolságától és sok mindentől függően rakta össze ezeket az ATO. Tehát a fenti példában ez lehet egy F-16C bombázó kötelék lézerbombákkal, F-15C vadászkíséret és F-4G SEAD kíséret. De akár az is lehetett, hogy „MI” vezette F-4E-k bombáztak mondjuk egy lőszerraktárt, ahol a játékos volt a SEAD kíséret stb.

Egy 8 gépes támadó erő, F-16C és F-4E gépekkel. 4 F-16C végzi a csapásmérést, 2 F-16C a légvédelem elleni kíséretet adja (SEAD), 2 F-4E végül az eredményt lefotózó felderítő bevetést repül. (BDA – bomb damage assessment)

A kombinációk száma magas volt és ráadásul elvárta a játékostól, hogy tartsa az útvonaltervet, hogy találkozzon a más támaszpontról felszálló gépekel. A légvédelem dolga is egészen más, ha nem 2-4 gép helyett egyszerra akár 8-12 darab repült a célkörzetbe.

A játék varázsát az adta, hogy ezeket a bevetéseket a program automatikusan generálta a fordulópontokkal együtt. Ha a játékos követte a repülési tervet, akkor adott helyen és időben találkozott a többi géppel és együtt mentek a cél felé. Na, tessék ezt úgy elképzelni, hogy mondjuk, egyszerre 6-8 ilyen csoport mozog és jelenik meg a játékos körül, ha éppen közel vannak, és közben zajlik minden más is. Emiatt is volt igen ütős a dinamikus hadjárat. A hadjárat nem a játékos körül zajlott, ő csak egy csavar volt egy nagy gépezetben. Ahogy egy igazi F-16 pilóta venne részt egy valódi háborúban.

A hadjárat indulása után folyamatosan zajlottak az események és a hadjárat közben minden egyes cselekedetnek hatása volt a konfliktus kimenetére, ami egészen egyedülálló élményt jelentett. Ha a játkos lebombázott egy repteret, akkor, amíg azt rendbe nem hozták, onnan nem repültek bevetéseket a gépek. Ha leromboltak egy radart, akkor az ellenfél célészlelési képessége csökkent és nehezebben vezette a játékosra az ellenség a vadászokat. Kismagasságon repülve egészen a célig lehetett észrevétlenül is eljutni. Ha meg leamortizáltak egy hidat, akkor ott nem kelt át folyón ugyan senki stb. Persze korlátok itt is voltak grafikai megjelenítésterén. A megsemmisített földi egységek nem jelentek meg a „3D” világban, amikor később visszatért a játékos azokra a helyekre, csak az objektumoknál volt a vizuális megjelentés „öröklődő. Spórolni kellett az erőforrássokkal.

A taktikai/stratégiai következménye is volt a dinamikus hadjáratnak pusztán a játékos szemszögéből nézve is. Ha lelőttek egy gépet, akkor az elveszett és ez az egész hadjáratra kihatással volt. Kevesebb gép = kevesebb bevetés. Ezáltal nagyon meg kellett gondolni, hogy pl. mennyire erőltetett az ember egy nem túl fontos cél elleni támadást a játékos, ha hirtelen nagy ellenállással találta magát szembe. Az sem volt evidens, hogy üldözzön vagy sem egy ellenséges gépet az ember mélyen az ellenséges légtérben, ahol könnyen bajba kerülhetett.

A játékos tehát az olyan szimulátorokkal szemben, ahol a hadjárat csak „single mission” bevetések egymásra épülésével operált egy egészen más élményt kapott. Azokban, ha sikeresen teljesítette a gép által meghatározott feladatot, akkor tovább léphetett, ha nem, akkor újra neki kellett futni missziónak. Ha sikerült, akkor szinte nem számított, hogy közben hány baráti gép veszett oda. Ezzel szemben a Falcon 4.0-ban lehet, hogy sikerült egy repteret megbénítani, csak ha közben mondjuk a 8 támadó gépből odaveszett mondjuk a fele, akkor felmerült a kérdés, hogy ez megérte-e, mert a közeljövőben ennyivel kevesebb repülőgéppel tudott csak az ATO bevetéseket generálni.

De ez fordítva is igaz volt. A csak single mission-ök sorát használó szimulátorban, ha többet teljesített a játékos, mint a kiírt feladat, akkor annak többnyire semmiféle következménye nem volt a következő bevetésre nézve. Az ismételt lerepülése ugyanannak a bevetésnek egy idő után inkább idegesítő volt, mint élvezetes különösen akkor, ha a feladat túl nehéz volt. Ettől a rendszertől csak alig néhány program tért el kisebb-nagyobb mértékben, ezek korábban említve voltak (US Navy Figthers, EF2000, F-22 TAW, F-14 Fleet Defender).

Egy hadjárat kezdete. A program az aktuális helyzetnek és az MI vagy a játékos beállításainak megfelelőn generálja a bevetéseket és a 2D világban zajló eseményekről is beszámol. A térképen különféle szárazföldi alakulatok láthatóak és a bevetés tervezett útvonala.

A fenti rendszer a Falcon 4.0 esetén nem is értelmezhető, mivel a játékos nem egyetlen pilótát személyesít meg. Bármikor beleülhet bármelyik F-16C gépe, kivéve, ha azok már nem rendelkeznek fegyverzettel és/vagy hazafelé tartanak, vagy mert az MI törölte vagy lerepülte a bevetést.

Egyik gépből a másikba az átugrás nem volt lehetséges a „3D” világon belül vissza kellett térni a „2D” világba hozzá. a Jane’s USAF-ban eztrepülésközben is meg lehetett, sőt, meg is kellett tenni. (Ha jólemlékszem...) Ez azért kicsit furcsává tette a bevetések lerepülését, mert a valóságban nem ugrálgat az ember a gépek között.

Nem csak felszálláskor lehetett gépbe ülni, akkor is lehetséges volt, ha már felszállt a kötelék. Az igazi hardcore játékos persze megköthette a saját kezét és játszhatott úgy, hogy ha lelőtték, akkor újrakezdte a hadjáratot, de ennek sok értelme nem volt szerintem. Ha sorozatban repülte a játékos egymás után a bevetéseket az sehogy sem illik abba a képbe, hogy csak egyetlen pilótát személyesít meg a játékos főleg úgy, hogy még a repülőszázadok között is váltogathatott. A valóságban egy pilóta nem néhány perces vagy órás időközökkel repül bevetéseket az idők végezetiéig és nem úgy, hogy egyszer Szöulból száll fel, majd 10 perccel később mondjuk 200 km-re odébb levő támaszpontról...

A Falcon dinamikus hadjáratának stratégiai vonása az eddig felsoroltakon túl az volt, hogy az egyfajta RTS motor háttérben futtatást nyakon öntötte a már azzal a korábban látott módszerrel – lásd EF2000 és F-22 ADF/TAW – hogy a játékos által lerepült bevetések sikeressége is beleszámított a „2D” hadjáratban számolt több esemény menetébe. A szárazföldi csapatok erejét és kezdeményező készségét befolyásolta, hogy a játékos mennyire sikeresen pusztította el az előre kijelölt célokat. Tehát mondjuk hiába vonult vissza egy „forró helyzetben” a játékos és mentett meg gépeket a pusztulástól ez lehet, hogy mégsem volt a nagy összképet nézve olyan jó, mert a „mission rating” alacsony maradt.

Viszont, ha meg a játékos és mondjuk a köteléktársakat is lelőtték, akkor annak hosszabb távon hatása volt, mert az elveszett gép kapacitása kiesett. Azonban lehet, hogy megérte feláldozni/elveszteni egy vagy több gépet is, mert a jó „mission rating” miatt pl. a szárazföldi erők harcértéke megnőtt a „2D” világban vagy a célpont volt olyan fontos, hogy szimplán megérte. A veszteség ellenére a játékos lebéníthatott egy repteret, ahol több tucat gép is lehetett és azok addig nem repültek bevetést vagy pl. bejövő ellenséges vadászokat és csapásmérőket szedett le a saját kulcsfontosságú repteret megvédve. Ennek ellenkezője is lehetséges persze. A játékos folyamatosan öngyilkos csapásmérő bevetéseket repül és folyamatosan lelő azért valamennyi ellenséges gépet és elpusztít légvédelmi egységeket is, de a kijelölt célpont mindig megússza. Ilyenkor a „mission rating” alacsony maradhat, miközben folyamatosan csak gépeket veszít el és a szárazföldi egységek harcértéke folyamatosan csökken.

A „MI” által generált küldetések és a kijelölt célok tehát elsősorban a „mission rating” miatt voltak fontosak, másrészt a többi repülőgép is eszerint tette dolgát a nagyvilágban. Ha pl. az MI által egy nagyobb köteléket (package) rakott össze több kisebből (flight), akkor a kíséret eszerint repült, erre nem volt ráhatása játékosnak. Ha pl. F-16C gépek adtak kíséretet a légvédelem vagy vadászok ellen bármilyen csapásmérő köteléknek, de a játékos a saját feje után menve másfelé repült, megtehette. Csak éppen nem volt bölcs, mert a fontos célt támadó gépeket magára hagyta ezzel. A kíséretet az MI a vártható fenyegetés mértéke szerint próbálta belőni. A játékos hiába nem csatlakozott a többi kötelékhez, azok akkor is lerepülték a bevetést az eredeti célpont felé. Ez fordítva is igaz, a játékos elszakadhatott fordított helyzetben a kísérőktől, annak minden következményével. Ha pl. a köteléktársak segítségével elintézte a kijelölt célt és még maradt energiája, üzemanyaga és fegyverzete, akkor simán meglátogathatott más célt is. Ha pl. SEAD feladatkörben a játékos nem talált a célkörzetig már légvédelmet akkor senki sem gátolta meg, hogy szabad vadászatba kezdjen. Ha talált valamit és elpusztította, akkor természetesen az többi arra kószáló gép későbbi dolgát könnyítette meg, abban a pillanatban vagy akár későbbi bevetésen is. A hadjárat bármelyik résztvevőjének cselekedeteinek hosszútávú hatása is lehetett, ami később mindenki számára fontos lehetett. Ebben rejlett a dinamikus hadjárat szépsége. A lényeg az, hogy semmiféle megkötés nem volt arra, hogy a játékos mit csinál, de minden esetben viselni kellett játékos döntéseinek rövid- és hosszú távú következményeit is.

Szintén a stratégiai rész vonása volt az, hogy a valósághoz hasonlóan volt egyfajta logisztika/utánpótlás (supply), bár ez amennyire látom, gyakorlatilag befejezetlen volt, nem sikerült rendesen kidolgozni és optimalizálni. A repülőszázadok fegyverzete véges mennyiségű volt, bár az csak igen ritkán fordult elő, hogy kifogyott volna bármelyik fontos fegyver. Ez amiatt volt, hogy a játékban generált utánpótlás túl magas volt. A repülőszázadok – és elvileg a földi csapatok is – időnként kaptak utánpótlást/erősítést, az elvesztett gépmennyiséget így pótolhatták. Ezzel azt modellezték, hogy konfliktus esetén máshonnan települnének át gépek, Észak-Korea esetén az orszok illetve Kína adna át gépeket. A valóságban olyan sokáig tart a modern harceszközök gyártása, hogy szó nincs arról, hogy új gépeket építenek. Játéktechnikailag ezen úgy próbáltak segíteni, hogy az utánpótlás mértékétől függött (volna) ennek nagysága. Azonban ez a része bugos/optimalizálatlan/befejezetlen maradt. Hogy melyik a háromból azt én meg nem mondom, csak a végeredményt láttam, Így néha a játékos azzal szembesült, hogy csak irtja az ellenséges gépeket, de azok állandóan csak jönnek, csak jönnek, ha nem rombolta le legalább az ellenséges infrastruktúra egy részét. A dinamikus hadjárat célja nem a 100%-ban valósághű hadjárat modellezés volt, hanem hogy egy hátteret adjon annak, hogy legyen értelme mindenféle célt támadni és a hadjárat ne fix legyen.

Szintén a stratégiai szintű modellezés következménye volt, hogy a kínai és orosz egységek csak akkor léptek be a konfliktusba, ha az ellenséges és baráti erők közötti arány egy bizonyos szint alá csökkent, vagy más kiváltó ok (trigger) hatására. Ezekből is több volt amúgy a játékban megalkotva, mint amit aztán valóban használtak belőle. Itt is tetten érhető volt a befejezetlensége.

Életkép egy hadjárat elejéről. A határ mentén összecsapnak a szárazföldi erők, mindkét oldal repülőgépei beavatkoznak a küzdelembe.

A hadjárat dinamikus volta miatt különböző nehézségi szinten főleg, ha eltérő bevetésarányokkal próbálkozott a játék, akkor ritkán találkozott a játékos két teljesen azonos taktikai helyzettel. A globális szinten fix, de állítható kezdeti feltételű (nehézségi fokozat) és félig véletlen generált környezet elképesztően hitelesen adja vissza a valós taktikai környezet komplexitását és véletlenszerűségét. Amnak ellenére, hogy csak töredékét és helyenként nagyon erős absztrakcióval modellezi a valóságot, de a „100%-os realitás” nem is volt cél, hiszen egy játéknak kellett hátteret biztosítani.

A dinamikus hadjárat játéktechnikai szempontból szinte örökéletűvé tette a Falcon 4.0-át olyan szimulátorokkal szemben, ahol fix bevetések voltak és szinte semmiféle változatosságot nem kínáltak annak ellenére, hogy jónak mondható küldetés szerkesztővel bírtak. Hiába volt lehetséges azokban küldetés szerkesztővel gyártani új helyzeteket a saját magadnak legyártott bevetések meglepetés faktora finomam fogalmazva is alacsony és örülhet a felhasználó, ha ez a része egyáltalán működik a szimulátornak.

A hadjáratok többféle előre definiált eseményig tarthatnak, de ezek jellemzően előre meghatározott objektumok elfoglalását jelentették vagy egy adott időn túl döntetlen lett az eredmény. A játék motorja egyébként elvileg ennél több győzelmi feltétel beállítását is lehetővé tenné, de ezt soha nem használta ki senki később sem, pont a játék bugossága miatt.

Huh, hát nagyon röviden ennyit a hadjáratok működéséről és lehetőségeiről. Ideje még néhány szót ejteni arról, hogy a hadjáraton kívül mire volt még lehetőség. Alapvetően más szimulátorokkal szemben, ahol a játékos egyesével pakol ki szárazföldi egységeket a küldetés szerkesztővel a Falcon 4.0 adatbázisa egy alap „építőkészletet” felhasználva építi fel a térképen található objektumokat és egységeket. Az objektumokról már volt szó pl. a reptereknél, ideje az egységekről is szót ejteni.

Az adatbázisban megtalálható számtalan katonai jármű, repülőgép, helikopter, hajó stb., ezekből épít fel a Falcon 4.0-ban csak „zászlóalj” (battalion) terminológiával kezelt egységet. Minden egységet zászlóaljnak hív attól függetlenül, hogy nem zászlóalj méretűek, ez csak egyfajta terminológia és absztrakció. Ezen egységek összetétele előre definiált az adatbázisban, nem lehetett rajtuk változtatni. Ebből lehetett volna kicsit talán több is, hogy a végeredmény változatosabb legyen.

A hadjáratban a méret és összetételük nagyon ötletesen van kezelve ezen egységeknek. Egy battalion 16 cellából (slot) épül fel. A nehézségi beállításoktól függően a két oldal ebből 8-től 16-ig tartó mennyiséget használ fel.

Egy amerikai páncélos egység és egy észak-koreai SA-2 légvédelmi egység állománya.

Csak ezekkel az előre definiált egységekkel lehet a küldetés szerkesztőben dolgozni más játékokkal ellentétben, ahol egyesével lehetett bármilyen járművet letenni. Azokban lehetséges volt, hogy egy harckocsi ide, egy páncélozott szállítójármű oda stb. és ezekből lehetett csoportokat formálni, jó esetben. (Lásd US Navy Fighers). Ez a többi szimulátorban nagyon részletes szerkesztést tett lehetővé, ellenben nagyon macerás és hosszadalmas volt felépíteni egy olyan léptékű bevetés sorozatot, mint ami egy masszív háborúban van. Sőt, igazából lehetetlen volt, mert adott egységszám felett az FPS beleállt a földbe. Persze az érem másik oldala a sokkal aprólékosabb környezet menedzsment volt, olyan típusú bevetések is összerakhatóak voltak, ahol akár egyetlen teherautó kilövése a cél. Ezáltal lehetséges volt akár olyan küldetés vagy küldetés sorozat felépítése, ami pl. valamiféle fontos célszemély levadászását modellezte. A Falcon 4.0-ban erről csak részben lehetett szó. Ez annak következménye, hogy dinamikus hadjárattal bír a játék, amit egy masszív konvencionális háború modellezését célozták meg és ahhoz szabták a játék szerkezetét. Persze lehetséges lett volna olyan kódot írni, hogy ez ne legyen probléma, de ugyebár említve volt a lehetséges bugok forrása...

Modellezési szemszögből azonban meg kell jegyezni, hogy a valóságban igen ritkán grasszálnak önállóan a játékban szereplő harcjárművek. Egy harckocsi vagy gépesített zászlóalj együtt mozog a csapatlégvédelemmel, megy velük a gépesített gyalogság és a szükséges támogató egységek stb. A Falcon 4.0 küldetés szerkesztőjével igen gyorsan felépíthető volt egy olyan „single mission” – ezeket valójában Tactical Engagement (TE) néven kezeli a Falcon – ahol 20-30 ilyen „battalion” lepakolása azt jelentette, hogy több száz jármű volt a térképen. Tehát még TE keretén belül is a dinamikus hadjárata jellemző méretű és komplexitású környezet megteremtése volt lehetséges, egyfajta mini hadjáratokat lehetett csinálni. A TE-n belül egy pontrendszer és időlimit is felállítható volt. Minden egyes objektumnak vagy egységnek egy értéket lehetett megadni és ezek elpusztításával lehetett besöpörni az érte járó pontokat. Ez a dinamikus hadjárattól eltérő, de egyfajta győzelmi feltételrendszer megalkotását tette lehetővé. A fő eltérés a TE-ben az volt, hogy nem generálódott bevetése automatikusan, csak a játékos által előre létrehozott események zajlottak. De még itt is lehetséges volt, hogy egy „zászlóalj” egységen belül egy kijelölt jármű érjen győzelmi pontot. Lehetet az, hogy pl. egy letett parancsnoki egység parancsnoki BMP-je legyen a célpont.

Ideje már a szimulátor primadonnájával is foglalkozni, az F-16C Block 50/52 típussal. A választott vadászgép modellezése a kor szintjén kicsit talán az átlag felett volt. Ekkorra már kb. megszokott lett a valóságoshoz közeli légiharc radar üzemmódok megjelenése. (RWS, TWS, VS, és közeli légiharc üzemmódok), a Falcon 4.0 meg is kapta ezeket, ahogy illik. Furán is vette volna ki magát, ha máshogy történt volna. A radar felderítési és célkövetési modellezésénél számításba vették a célpont távolságát, a célpontra jellemző „radar keresztmetszetet” (RCS), beaming manőver esetleges hatását, és azt, hogy földháttérben van vagy sem, illetve azt, hogy milyen aktív és passzív ellentevékenységet folytat. Ennél még lehet, hogy többet is, de ez már a kódban van elrejtve az adatbázisból nem derül ki. Ez akkori szemmel elképesztően jó modellezés volt, sőt, még ma is az annak ellenére, hogy a valósághoz képest nagyon erős absztrakciót és egyszerűsítést jelent. Viszont megadta a változatos végkimenetel lehetőségét és az eltérő gépek eltérő képességeinek modellezését.

A játékban a különféle légiharcrakétákat három féle vezérléssel modellezték, a köztük levő különbséget a szenzorok képességei és a rakéták kinematikai jellemzői jelentették. A háromfajta vezérlés, a félaktív radaros (pl. AIM-7M vagy R-27R), aktív radaros (AIM-120C és R-77) és infravörös (pl. AIM-9M és R-73) volt.

Az igazi újdonság a harcászati avionikánál a csapásmérő feladatkörhöz köthető új dolgok. Már korábbi szimulátorokban is volt szintetikus apertúrájú (SAR)* levegő-föld üzemmód (F-15E Strike Eagle III), de az F-16C gépek dopplernyaláb szűkítés (DBS – doppler beam sharpeining) radar üzemmódját olyan szépen és hitelesen modellezték le, ami a fenti kivételtől eltekintve páratlan volt akkoriban. Főleg azt nézve, hogy azt milyen környezetben tették meg. A Falcon dinamikus hadjáratával, domborzatával és környezetével kombinálva ez elképesztő újdonság volt, mert az egyedi objektumok és városok épületeinek elrendezése is látszott rajta, a reptereknél külön-külön megcélozható volt egy hangár vagy a kifutópálya. A lézerbombák számára a lézeres célmegjelölő konténerrel kombinált üzemmód is modellezve volt, valóságos célkijelöléshez hasonlóan működött a lézerbombák használata. A buta bombák nagyon pontos célba juttatása is lehetséges volt ezzel kis magasságon, éjszaka is. Az AN/APG-68 radarnak modellezve volt az álló és mozgó célpontok elleni üzemmódja is.

https://youtu.be/BCq7Rip3emU?t=407

DBS radar üzemmód a valóságban.

 A játékban a következő alapvető csapásmérő fegyvertípusok voltak:

• Buta bombák, ez lehetett hagyományos romboló (pl. Mk-82/84) vagy kazettás- (pl. CBU-87 vagy Mk-20) vagy akár napalm is. A hagyományos bombák között volt az alacsonytámadáshoz használt Mk-82SE vagy BSU-50, ahol modellezték az oldás utáni erős fékeződést a féklapok vagy az fékernyő által. Szintén ide sorolható a speciális, kifutópályák elpusztítására szánt BLU-107 Durandal. Három féle oldási mód volt modellezve, ezek is jellemzőek voltak akkoriban a harcdcore vonalon. (CCRP, CCIP és DTOS) A bombák által okozott pusztítás természetesen függött annak típusától és méretétől.
• Föld-levegő rakéták. Az F-16C-n ez az AGM-65 különféle változatai voltak, de 3D világban ezek között szinte semmi eltérés nem volt. Pedig a kód és az adatbázis lehetőséged adott volna ennek tágabb modellezésére és a 2D-s világban bizony volt eltérés.
• Lézervezérlésű bombák. Használata kismértékben eltért az AGM-65-től a célkijelölés, az oldás a buta bombához hasonlított.
• „Radargyilkos” rakéták, pl. AGM-88 HARM.
• Nem irányított rakéták. A modellezés sajátossága volt, hogy ezek nem voltak egyesével indíthatóak, a függesztőn hordozott blokkból egyszerre indult az összes rakéta. Ez elmaradt a kor modellezési színvonalától, de jobban illet a hadjárat és a függesztmények alapvető modellezésébe. Amúgy ez a fegyver család szerintem felesleges, értelmes célpontja ezeknek nem volt a modellezési korlátok miatt.

A kabin még a régebbi korszakra jellemző kialakítással bír, itt szintén érdemes a nem sokkal később Flanker 2.0-höz mérni. Míg a Flankerben már csak 3D virtuális kabin volt, addig a Falcon 4.0-ban még az EF2000-re jellemző 2D/3D kabin volt, de annál magasabb színvonalú. A 2D kabin rajzolt volt és fix nézetek voltak kialakítva. Ez gyakorlatilag az 1989-es Retaliatorhoz hasonló, csak azért már jóval messzebb mentek a lehetőségek terén. A 2D kabinban lehetőség volt kapcsolók és gombok egy részét egérrel kapcsolgatni fel le, ami sokat dobott a realizmuson és nem kellett ezernyi billentyűzet kombinációt bemagolni. (Bár még a legutolsó MFD gombra is volt billentyűzet kombináció definiálva.)

A 3D kabin részben funkcionális volt, de közel sem azon a szinten, mint a 2D kabin. Az MFD képernyők közül többet csak korlátozottan volt képes megjeleníteni. A Maverick rakéta célkereső fejének képét pl. egyáltalán nem, a radar képernyőn megjelenő céljelek mérete sem volt azonos a 2D-s kabinéval. Az is furcsa, hogy annak ellenére, hogy ez elvileg hardcore szimulátor volt, a kabin bizony eltért az igazitól itt-ott, pedig ekkor ezt a szintet már túlhaladták a játékok. A 3D kabin kinézete akkor egyáltalán nem volt szépnek mondható, a funkcionális szót lehet inkább ráaggatni.

2D kabin alap nézete. Baloldal látható a levegő-föld üzemmódban dolgozó radar, felismerhető rajta a reptér és annak egyes részei. A kabin a kor színvonalán nem volt átlagon felüli szépségű.

2D kabin alap nézete és a lézeres célmegjelölő konténer (TGP) képe. A Falcon 3.0-hoz képes ahol csak wireframe modell volt hatalmas előrelépés, de itt is látható az erőforrással való spórolás, a TGP képe nem textúrázott. A képen egyébként a korábban említett elhíresült észak-koreai Ryugyong szálloda.

3D kabin. Látható, hogy alacsonyabb felbontásúak a textúrák és az analóg műszerek is nehezen vagy egyáltalán nem olvashatóak le. A radar levegő-levegő üzemmódja azonos megjelenítéssel bír a 2D-s kabinhoz képest.

3D kabin, a levegő föld üzemmódban a lézeres célmegjelölő és az AGM-65 Maverick IR/TV kamerának képe egyáltalán nem jelenik meg. Nem volt képes a játék motorja a domborzat/táj tulajdonságaiból származó dolgok megjelenítésére.

A játékban szereplő nyugati repülőgépek fegyverzet konfigurációi többnyire pontosak voltak, de valahogy néhány ordító hiba azért valahogy mégis belekerült, főleg a szovjet-orosz gépeknél. Például a Szu-27 képes volt a csak a MiG-31-en alkalmazott R-33 rakéta hordozására, de a csapásmérő fegyverzet konfigurációknál már ennél azért nagyobb gondok is voltak. A gépeken rendelkezésre álló infracsapdák mennyisége sem volt mindig reális, bár itt az is faktor, hogy a valóságban eltérő méretűek is betárazhatók egyes gépeknél. Figyelembe kell venni azt is, hogy akkor sokkal nehezebb volt megbízható és nagy mennyiségű forrást beszerezni. Az Internet által nyújtott lehetőségek ma fényévekre vannak az akkori információ szegényes környezetnek főleg úgy, hogy azóta számtalan eszköz minősítése fel lett oldva és nem titkosak már.

A Falcon 4.0 repülést leíró fizikai modellje nem volt rossz, nagyon sok dolgot maga a rendszer a kor szintjén nagyon jól tudott modellezni. A repülési magasság és sebességnek hatása volt az üzemanyag fogyasztásra, ahogy valóságban is, nem csak a hajtómű teljesítményének. Természetesen a tolóerő karakterisztika modellezése is magasság és sebesség szerint történt. Ha pontos volt a bemenő adat, akkor a végeredmény is az volt. A Flanker 2.0-hoz képest maga a repülőgép mozgása nem volt annyira hihető egyes helyzetekben. Ez részben arra vezethető vissza, hogy modellezni próbálták a repülőgépnek a vezérlő rendszerét, ami a valóságban is „kisimít” egyes jelenségeket. Viszont ettől még a Falcon 4.0-ban olyan érzése volt a játékosnak, mintha egy zsinóron húznák a gépet, a repülés élménye sterilnek tűnt a Flanker szériához képest. Még trimmelni sem kellett a gépet, csak akkor, ha sérülést szenvedett.

Nem csak a repülőgépeknek, de rakéták is fizikai modellel mozogtak és nem szkriptelve, mint más szimulátorokban. Olyan szinten voltak modellezve, hogy sebességfüggő légellenállás tényezőjük volt, tolóerő karakterisztikával bírtak és a hajtóanyag tömeg fogyása is számításba volt véve a gyorsulás számolása során és sok egyéb más. A játékban levő eszközök modellező értékei text formátumban több megabyte adatot tettek ki. Jól mutatja ez, hogy hová fejlődött a játék. 10 évvel korábbi számítógépek memóriájába alig fér volna be ez a nyers adatmennyiség…

Amiről még szót kell ejteni az a rádiózás. Az EF2000-hez és más szimulátorhoz hasonlóan ez is szótagokból építette fel a rádiózást, de olyen színes és reális kommunikáció talán még sehol nem volt, mint ebben. Stimmelt a zsargon, ezen felül lehetett állítani, hogy milyen csatornákba hallgatott bele a játékos. A saját köteléken túl (flight) hallgathatta az azonos célpont ellen repülő nagyobb csapat (package) rádiózását, de akár a kb. közelben levő gépekét. Nem az összes üzenet volt hallható abból, amit a játékos használt, mint például, amikor az AWACS-től helyzetképet kért, azonban a „maradék” is igen hangulatos volt. A játékos hallhatta, ahogy a kötelékparancsnok adott esetben formáció váltást rendel el, fegyverhasználatot a valóságnak megfelelően jelentették, lelőtt gépnél a köteléktársak jelentését a lelövésről és mentőhelikopter kérését stb. Felszállás és leszállás előtt engedélyt kellett kérni, ha csak úgy simán leszálltál ezek nélkül, akkor a program a mission rating-et rontotta. Ez több volt, mint színjáték, mikor 8-10 gép érkezet vissza akár egy időben, megadta, hogy hányadik vagy a sorban, de vészhelyzet jelentésekor előrébb vitt. (Azt nem büntette, ha indokolatlanul használtad ezt, ez megint a játékos hozzáállásán múlt...) A gépek eközben a valóságnak megfelelően követték a megközelítést, adott térközzel, adott irányból. A leszállási irány függött a széliránytól is. A rádiózás bőven megütötte játéktechnikailag a kor színvonalát, sőt, felette is állt.

A játékos négygépes kötelék esetén a 2x2 gépből álló formációból csak a saját kísérőjének parancsolt közvetlenül, a másik két gép esetén (2nd element) csak annak vezérét utasította, összevonva annak kísérőjével. Ennek az volt a jelentősége, hogy a célpontok számától függően érdemes volt néha csak egy gépet utasítani adott cél támadására, nem kettőt.

Ezzel nagyjából képet kaphat az olvasó, hogy mi is volt anno a Falcon 4.0. Szépnek tűnik az, amit fentiekben olvasható? Szerintem nem is kicsit. „Apró hiba”, hogy a fentiek része elméletnek mondható, úgy kellett volna működnie ideális esetben a játéknak. Ezt el is érte később, sőt messze többet is, de a szomorú valóság viszont az volt, hogy kiadott állapotában a Falcon 4.0 gyakorlatilag egy bughalom volt. Ez annak egyenes következménye, hogy az 1998-as karácsonyi szezonban történő kiadást erőltette a menedzsment, bár egyesek ezt tagadják, hogy ez így lett volna.

Bármi is volt az ok, a vége az lett, hogy a kiadott állapotában a Falcon 4.0 olyan szinten bugos volt, hogy sokszor még a legalapvetőbb funkciók sem működtek megbízhatóan vagy egyáltalán. A dinamikus hadjáratban mentés és visszatöltés után minden objektum sértetlen volt akkor is, ha előtte porig bombázták. (Nekem legalábbis így működött.) Tehát pont a játék gerincét adó rész nem működött. Iszonyatos blama. Ezt persze későbbi patch orvosolta, de hogy így ki merték adni, az egészen elképesztő.

A játék rosszul optimalizált és nagyon instabil volt. A legsúlyosabb problémákat az utolsó hivatalos patch (1.08us) 1999 végén javította, de közel sem mindet. Arra már elmondható, hogy kb. hozta azokat a fő dolgokat relatíve stabilan, amit fent bemutattam. Fontos megjegyezni, hogy 1999-ről beszélünk, amikor egyáltalán nem volt az általános, hogy az átlag felhasználónak Internet kapcsolata lett volna. Nem Magyarországon, még nyugaton sem. Az Internet korszak előtt ezeket vagy postai úton igényelhette a felhasználó fizikai adathordozón, vagy az akkori időkben játékmagazinok CD mellékletén kaptak ezek helyet, de ez sem volt általános. Én 2001 nyarán jutottam hozzá a Falcon 4.0-hoz, de a patch fogalmát akkor nem is ismertem (!). 2003 eleje táján tudtam először a javított változattal játszani. Pedig ekkor már létezett az 1.08us patch-nél lényegesen több is, lásd majd később.

A Falcon 4.0-ból amennyire emlékszem így is több százezer példány ment el, de ennek ellenére tudtommal anyagi bukás volt. Erősen sejthető, hogy a Hasbro döntése, miszerint a Microprose alamedai részlegét be kell zárni ennek következménye volt, aminek Falcon 4.0 fejlesztő csapata is része volt.

Itt most kicsit előreszaladok. Lehet, hogy túlzó és téves kijelentés részemről, de az én véleményem az, hogy talán a Falcon 4.0 körüli mizériák és végül bukása egyenes oka annak, hogy a műfaj kihalás szélének állónak tekinthető. Nem általánosan a repülőgép szimulátor, hanem a modern katonai gépekkel foglalkozó katonai szimulátor. A nem sokkal utána megjelenő játékok még átmentek a menedzseri rostán, valószínűleg már nem érte meg azok fejlesztését leállítani, de akkoriban jött a hír arról, hogy mennyi betervezett szimulátort kaszáltak el.

Befejezésként egy régebbi interjú Kevin Klemmick-kel, aki a Falcon 4.0 vezető programozója volt és persze néhány videó szokás szerint.

Interjú

http://www.mediafire.com/view/imb0zp967i7tfb3/Interview_with_Kevin_Klemmick.pdf

 [1] https://community.pcgamingwiki.com/files/file/814-falcon-40-patch/

[2] https://en.wikipedia.org/wiki/Gilman_Louie

Falcon 4.0 Intro

 Intro remake részemről, egy kis spoiler hova jutott a Falcon 4.0 ;)

Manőverező légiharc, no.1

Manőverező légiharc, no.2

A Patreon csatorna elérhetősége a csatorna támogatásához.

https://www.patreon.com/militavia