|

Szimulátor történelem – 6. rész

Játékok a ’90-es évek elejétől az évtized végéig, az aranykor –5. rész

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 Falcon 4.0 1998 decemberében (hivatalosan 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 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 (a dinamikus hadjárat) 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ás.

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.) 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 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 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 tulajdonsága, 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 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, min 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.

A gyakrabban felbukkanó 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 rusnyák 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 összevetni 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 800×600-as felbontást támogatott, míg a Flanker 2.0 emlékeim szerint támogatta már az 1024×768-as megjelenítést is. (Később a játék javításai tették elérhetővé az 1024×768-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 később.

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.

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ó.

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 évvel korábban is gyenge lett volna, de 1998 végén erre leginkább az ocsmány 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 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 néha szebben vannak 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 a repülőgépek.

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 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-é (lásd később ebben az epizódban), 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 egyedülálló megoldással bír, 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 átmerészkedett stratégiai szintre is. 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, ezzel spórolt 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 teljesen megszakítás nélküli, és további más 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, csak, mint bemeneti elem 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 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 play 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 tank és hasonló harcjárművekből álló csoportnál semmi szükség nincs arra, hogy 30-40 km-es távolságnál is 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ú 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ő csapatra? 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. 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.

Ma is létező probléma, hogy multiplayer játékoknál a megjelenítési beállítások változtatásával egyes játékosok előnybe kerülnek a többihez képest, szerintem ez ott sem volt lekorlátozva. (nem, nem omlik össze, az egyik előnybe kerül a másikhoz képest, glitch)

Mindebből a játékos mit érzékelt? Á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.)

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 esetben lehet egy F-16 százaz 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 az 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.

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. a kombinációk száma magas.

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, 2 F-4E végül az eredményt lefotózó felderítő bevetést repül. (BDA – bomb damage assessment)

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.

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, ha csak később jártál arra, 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 ige n 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 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 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. (Lásd a Flanker 2.0 első bevetését.) 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).

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 az, 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 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.

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 mentek 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.

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 roszok 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 marad. 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…

Szintén a stratégiai vonása 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ökken, vagy akár 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. (Ezek a későbbi közösségi fejlesztési időszakában váltak ismertté, lásd később.)

É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 annak ellenére, hogy csak töredékét és helyenként nagyon erős absztrakcióval modellezi a valóságot. Amúgy a teljes realitás nem is biztos, hogy elvárás a játékélmény miatt.

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 elég 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 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áltak 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 állománya é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. Azoknál a küldetés szerkesztővel lehetséges volt az, hogy akár egyesével helyezzen le járműveket a játékos. 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 igen macerás 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 egység 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é. Az 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 jármű érjen győzelmi pontot. Lehetet az, hogy pl. egy letett parancsnoki egység parancsnoki BMP-je legyen a célpont.

 

Ideje akkor már a játék primadonnájával is foglalkozik, 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 megadja 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 igen 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.

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). 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, a Flanker 2.0-hoz képest. 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ókat 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 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 max. 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 nem képes arra a megjelenítésre, amire 2D-s kabinban, ahogy 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 titokvédelmi szempontok miatt, no meg az Internet által nyújtott lehetőségek ma fényévekre vannak az akkori információ szegényes környezetnek.

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 talán 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 megabytenyi 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 az 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 ilyen színes és reális kommunikáció talán még sehol nem volt. 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 2×2 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 kb. be is fejezem, 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 élvezhetetlen 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. Tehát pont a játék gerincét adó rész nem működött. Iszonyatos blama.

A játék igen lassú, 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 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 itthon, nyugaton sem. Az Internet korszak előtt ezeket vagy postai úton igényelhette a felhasználó fizikai adathordozón, de 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.

Szó se róla mára oda eljutott a játékipar, hogy akár még nagy húzónevek esetén is szinte borítékolható, hogy a kiadás után néhány patch-csel vagy akár kb. egy évvel lesz csak élvezhető a játék vagy éri el azt a tartalmat, amit kiadáskor megálmodtak, és/vagy lesz eléggé stabil és bugmentes az élvezetes játékoz. Elég csak a Rome Total War 2-re gondolni vagy az Assassin’sCreed Unityra, de ezen alkotások óta is számtalan AAA játék jelent meg lényegében vállalhatatlan állapotban. Sajnos iparági trend lett ez mára, hogy minősíthetetlen vagy egyenesen befejezetlen és játszhatatlan állapotban adnak ki játékokat.

A Falcon 4.0-ból amennyire emlékszem így is több mint 1 millió példány kelt 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, 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.

A Falcon 4.0 egy remek alap volt, amire lehetett volna tovább építkezni és fejleszteni, azonban a történelem máshogy alakult, legalábbis egy időre. Ezután még készült hozzá fél- vagy nem hivatalosan kiegészítés és javítás, de ezek már a program utóéletéhez tartoznak, ezért ezekkel az új évezred részben foglalkozom. Nem semmi történet lesz. ;)

Befejezésként egy interjú Kevin Klemmick-kel, aki a Falcon 4.0 vezető programozója volt és persze néhány videó szokás szerint. Sajnos alig található videó az eredeti változatról.

Interjú

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

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

Flanker 2.0 és 2.5.

A DOS-os kiadású játék utódja már bőven a Windows és 3D gyorsítókártyák korszakában jelent meg 1999-ben. Ekkor a felállás ugyanaz volt, a fejlesztő az Eagle Dynamics volt, a kiadó az SSI. A Flanker 2.0-val a Falcon 4.0 követően ismerkedtem meg úgy, hogy a játék előzményéről semmit sem tudtam. Akkoriban fénykorát élő fórumokon hallottam erről a szimulátorról. A kiadása után sok évvel fillérekért lehetett hozzájutni, így azon kevés szimulátor közé tartozik, amit eredeti példányban birtokoltam. 2001-ben a 2.5 patch több területen is megtoldotta a 2.0 alap változatot. Azok, akik rendelkeztek az alap kiadással a 2.5 ingyenes frissítés volt, de a 2.5 változat később egyben is megvehető volt

A Flanker 1.1 kipróbálása után számomra nyilvánvalóvá vált, hogy a Flanker 2.0 lényegében egy grafikailag ráncfelvarrt 1.1, nyakon öntve egy kis ezzel és azzal. A modellezett dolgok terén gyakorlatilag nincs változás, legalábbis olyan kevés van, ha fejből nem tudom felsorolni azokat, akkor azok kvázi lényegtelenek.

A grafikai ráncfelvarrás viszont tényleg elképesztően látványos volt. Az előd elavult motorja után egy olyan kinézettel bírt a 2.0, amivel a kor minden játékánál szebb volt. Erőlködés nélkül. Labdába nem rúgott semmi. RPG játékok karakterei nem kaptak olyan poligonszámú modellt és textúrát, mint itt repülőgépek és a táj. A kinézetre és látvány egészen elképesztő volt. A reptereken számtalan parkoló jármű, épület, ami csak szem szájnak kell. Elég csak a lenti Szu-33-as 3D modellre, a felhőkre és a tájra nézni. A Falcon 4.0 ehhez képest a fasorban sem volt kinézet

tekintetében.

Az egyik főszereplője a játéknak egy Flanker változat, a Szu-33. 1999-ben ez brutálisan szép grafikának számított, a 3D modelleken alkalmazott, de még a táj textúrája is vert minden riválist.

A környezet és a járművek kinézete is egyszerűen gyönyörű volt. A táj nem csak uniformizált és repetitív textúra elemekből állt. Bár a városokban az épületek sok azonos épülettípusból tevődtek össze ez nem volt baj vagy zavaró, mert ez is nagy előrelépés volt más játékokhoz képest. A városok elrendezése ugyanis egyedi volt, ami még mai szemmel is nagyon fontos dolog, mert valódi vizuális referencia pontokat jelentenek az objektumok, ahogy a valóságban is. Sűrűségük is olyan volt, hogy alacsonyan repülve megvolt a sebességérzete a szobapilótának, ezen a téren tudomásom szerint akkor nem volt párja.

MiG-29 alacsonyan egy város felett. Jól látszik, hogy hány valódi 3D-s épületből áll össze és nem főleg textúrákból, mint a később bemutatásra kerülő Falcon 4.0-ban.

A textúrák maguk mögött hagyták a korábban említett „mákostészta” szerűséget, az eltérő álcaminták és kisebb jelvények és felségjelzések is leolvashatók voltak. A 3D modellek részletessége a kor normái felett voltak, sokkal szebb volt az „elsővonalas” gépek kidolgozottsága a Falcon 4.0 vagy bármilyen más szimulátorokban látottakhoz képest.

Persze ennek kinézetnek megvolt az ára is. Konkrét konfigurációval érzékeltetve, a program a maximális felbontáshoz Pentium III processzort, 128 MB RAM-ot ajánlott 1999-ben és persze a legjobb elérhető 3D gyorsító kártyát. Viszonyításképpen, nekem ehhez mérhető konfigurációm kb. 2003 közepén volt. Az a PC konfiguráció, amin az Falcon 4.0 (és annak későbbi leszármazottai) igen jól működtek, azon a Flanker 2.0 lényegében alig élvezhető volt.

A kabin gyönyörű volt, szakítottak a 2D + 3D kabin megjelenítési koncepcióval, csak virtuális 3D kabin volt már. Nem minden volt még 3D-s nagyon sok helyen csak térhatású textúrát használtak a hardverek akkori korlátai miatt, de ezzel lényegében kijelölte a jövőt a Flanker 2.0. Akkoriban szerintem a Flanker bírt a legszebb kabin kinézettel a harci gépeket felvonultató szimulátorok között.

Ami még említést érdemel, hogy a kortársakkal ellentétben a 2.0 változatban a kabinban ülve nem volt lehetőség a zoomolásra (látószög változtatásra), pedig akkor ez már alapkövetelmény volt, de csak a 2.5 változatban tették elérhetővé. A táj alapvető megjelenítése és színvilága is kicsit furcsa volt, legalábbis nekem. Sajnos úgy voltak a színek megválasztva, hogy a rakéták füstcsíkját szinte lehetetlen volt észrevenni, ami pedig alapvető lett volna tekintve az orosz gépeken levő besugárzásjelző rendszer képességeit – pontosabban annak korlátait – nézve, ez komolyan hozzájárult nálam ahhoz, hogy minden más erénye ellenére hanyagoljam. Hogy a táj volt túl világos vagy a rakéta füstcsík színe/mérete nem volt jól belőve az már megint más kérdés.

A főbb szovjet-orosz típusok, a kép alacsony felbontása sajnos elfedi azt, hogy mennyire szépek voltak ezek akkor.

Az amerikai típusok, sajnos ennek a képnek a felbontása sem ideális. A lényeg látszik rajtuk szerintem. A modellek alapvetően már nem aránytalanok, illetve a „mákos tészta” jellegű textúrának nyoma sincs a gépeken.

2K12 / SA-6 rávezetőállomás. Bár skinje nincs a 3D modell felbontása messze a Falcon 4.0 szintje felett van.

T-80UD, a 3D modell felbontása messze a Falcon 4.0 szintje felett van.

Sajnos a játék alapvető pozitívumai kimerülnek a szép grafika, és a Flanker 1.1-ből örökölt repülési modellezés terén. Repülni pont olyan élmény vele, mint az előddel, csak most már a környezet még szebb volt. De alapvetően az egész játék szinte ugyanaz maradt, ugyanazon hibákkal és hiányosságokkal. Előrelépés alig néhány területen történt.

 

A Falcon 4.0 dinamikus hadjáratának megismerése után az, hogy az egyszerű, statikus bevetésekkel operáló hadjárat dögunalmas volt. Ám még ez is lehetne élvezetes, megfelelő körítéssel, ahol láttuk azt az 1994-es Fleet Defenderen vagy akár megfelelő audio-vizuális kiegészítéssel, lásd US Navy Figthers. De még ezt a színvonalat sem sikerült elérni. Nem 1994-ben, hanem 1999-ben. A hadjárat teljesen lineáris, ha nem sikerült, akkor game over és kezdheted elölről. De legalább van save opció ahhoz, de az is pocsék módon működött. Hogy ha rosszul használta a játékos, akkor képes volt kukázni az egész addigi előrehaladást. Ezzel szemben az F-14 Fleet Defender és USNF-ben minden érthető és automatikusan történt.

De az még hagyján, hogy nincs még fél-dinamikus hadjárat sem, de a hadjárat első bevetése úgy kezdődik, hogy a radar meghibásodik a Szu-27 gépen és csak a sokkal korlátozottabb képességgel bíró hőpellengátorral kellett dolgozni. Ezzel aztán lehet kedved csinálni a játékhoz, már az első bevetésem tökönrúg a játék…

Meghibásodás? Bizony, ilyen modellező modult is tettek bele, amivel lehetséges volt egyes rendszerek véletlenszerű vagy előre determinált meghibásodását modellezni. Erről eddig érdekes módon nem is beszéltem semelyik korábbi szimulátor esetén. Miért? Nos azért, mert ez itt volt először, ahol találkoztam vele. Ennek a modellezésnek is meg vannak korlátai, illetve hibái, ezen felül a közösségnek nem is nagyon van erre igénye. Egy modern katonai repülőgép egyszerűen annyira komplex rendszer, hogy az ilyen véletlenszerű vagy pre-determinált hibák generálása már messze túlmutat egy kommersz harci repülőgép szimulátor határain. (Egész egyszerűen nincs hozzá elég bemenet a statisztikai modellezéshez és egyes hibák a valóságban olyan komplex hatásúak, hogy az egy egyszerűsített szimulátor nem képes modellezni.)

A Falcon 4.0 egy leszármazottjának fejlesztője szerint „fighter simulator” és nem „fault szimulátor” fejlesztése a cél alapvetően.

Szóval pozitív, hogy van ilyen lehetőség, de hogy a program így használja…!? Az említett bevetésen ráadásul légvédelmi rakéta is van a célkörzeben, ami szintén igen könnyen lelőtte a játékost. Én úgy jutottam át ezen a bevetésen, hogy a környező egységek lőtték le a célpontot és meg csak a túlélésre játszottam. Ez aztán a játékélmény…

A küldetésszerkesztő is gyakorlatilag azonos az előddel Itt ott áthelyzetek máshova egyes funkciójat, pl. a gépeknél a fegyverzet és targeting az adott csoporthoz tartozó lenyitható füleken van. Minimális előrelépés. Az egységek a 2.0-ban még mindig nem tudnak mozogni, amikor erre már az 1994-es USNF is lehetőséged adott úgy, hogy ott a szárazföldi járművek még egymásra is tüzelhetek. Ezzel szemben a teljes statikus Flanker 1999-ben eléggé alacsony szintű modellezés volt, amikor Falcon 4.0-ban dinamikus hadjáratban ezerszámra mozognak az egységek, hála az 2D/3D hadjárat és világ modellezésnek. A szovjet-orosz radaros légvédelmi egység felépítését ez is tudja, ahogy az elődje. Legalább vissza nem fejlődött…

 

De a fegyverzet modellezésénél is mit lát az ember? Az TV irányítású levegő-föld rakéta még mindig nem rendelkezik stabilizált képpel, ezért földi egységeket támadni vele képtelenség. Még akkor is, ha vízszintesen repül a gép, mert a legkisebb manővertől is iszonyatosan sokat mozog a gép orra és a nagyítás miatt lehetetlen célozni. Mindez úgy, hogy akkor ezt minden szimulátor korrektül modellezte, nem csak a szívszerelmem, a Falcon 4.0. Emiatt csak a mission editorban kijelölt célokra lehet vele dolgozni igazából. Igen, lehetőség volt járműveket előre kijelölni célpontnak. Tetszik érteni? 100% pontos felderítés és álló egység. Ezzel kvázi valódi közeli légi támogatás (CAS) bevetést repülni nem lehet, ahol menet közben kapod meg a célokat, amik mozognak és adott esetben meg kell keresni azokat. De, hogy hogy a MiG-29 és Szu-27 gépen a H-29L lézervezérlésű rakéták számára mi jelölni meg a cél, az is teljes homály. A KOLS lézertávmérője erre nem alkalmas. Mondjuk úgy, ha játék elég komoly hiányosággokkal küzdött. Nem a megfelelő altípusokat modellezte.

A szép grafika ellenére a földi egységek támadása amúgy is nehézkes volt, mert a grafikai motor csak eszementen kis távolságból jelenítette meg azokat a 2.5 patch után is. A zoom/FOV beállítástól függetlenül talán 2 km távolság vagy alatta. Először azt hittem, hogy ezt a Win7/10 szoftveres környezetben futtatása okozza a játéknak. Ezért egy barátomat megkértem, hogy a retro PC-jén, az akkori szoftveres környezetben, akkori hardver elemekkel nézze már meg, hogy mi a helyzet. Döbbenetes, de ott is ez volt az eredmény. A játék 2.5 javított változata is lényegében nem működött. Így harcjárművek felderítése és támadása így közel lehetetlen volt, de minimum élvezhetetlen.

A fegyverek modellezése is érdekes volt, mert egyes típusoknál csak előre kijelölt célok ellen volt lehetséges. Tehát ha a küldetés szerkesztőben nem volt megadva a célpont előre, akkor nem volt támadható a fegyverrel. Ez számomra egyszerűen elfogadhatatlan. Ebből látszik, hogy valódi fegyverzet modellezés nem volt, hanem szktiptek kötötték sokszor össze csak a fegyvert és a célját. Ha ez nem volt előre definiálva, akkor a fegyver nem működött. A Falcon 4.0 ennek pontosan ellentéte volt. Volt egy hatalmas nyílt világ és a játékos az érzékelők segítségével olyan célt keresett és talált meg, amit akart és arra indította, amire csak akarta a fegyver képességein belül. Pont úgy le lehetett lézerbombázni egy mozgó hajót, ahogy egy reptér kifutóját és ehhez nem kellett előre semmit definiálni. Ezzel szemben itt radargyilkos H-31 rakéta is csak arra volt indítható, ami előre (!!) definiált cél. Szerintem erre a környezetre nehéz szavakat találni még a legnagyobb jóindulattal is.

A harcászati avionika terén voltak nagyon arcade vonások, amit az elődből örökölt. A radar és az infravörös kereső pásztázott és ezeknek rendesen modellezve voltak a korlátai kivéve a levegő-föld üzemmódot a radar esetén. A Flanker 2.0 ás 2-5 változatban is benne maradtak a Szu-27 mese nem valós képességei. R-77, irányított levegő-föld rakétafegyverzet és a teljesen irreális levegő-föld radar üzemmód. Az még furcsább, hogy ha radarral talál célt az játékos, az nem párhuzamosítható a levegő-föld rakéta célkijelöléssel. Manuálisan kell újra befogni a cél pl. a H-29T-vel. Külön chaff és flare dobása még a 2.0-ban sincs, csak a 2.5-ben jelent meg, de már legalább nem konstans időközzel dobja azokat a gép. De a korszak színvonalát nézve ez megint az „ezt mégis hogyan…?” kategória.

Levegő-föld radar üzemmód. A szintetikus radar üzemmód nem ilyen képet ad, és a szovjet-orosz gépek nem is rendelkeztek ilyennel. Még csapásmérő Szu-24M sem, nemhogy a Szu-27 vadászgép.

Itt is az lehetett a szemlélet, mint az 1.0 idején, hogy adni akartak a játékosnak potens csapásmérő gépet az orosz oldalon is, ezzel viszont komolyan alávágtak a valósághű képesség modellezésnek.

De a repülőgép fedélzeti rendszereinek üzemmód modellezése is felettébb érdekes volt helyeként. A helyzetjelző (HSI) semmit nem mutat, ha nem a NAV üzemmód az aktív. Ez kb. akkora butaság, mintha az F-16C-n a HSD MFD képernyő és a HSI nem működne, mert mondjuk légiharc üzemmód van kiválasztva. Ez aztán a „szimulátor”…

 

Milyen volt a környezet, amiben a játékos repült? A 2.0 változatban a rádiózás a kor színvonalához képest jelentősen elmaradt, alig pár parancsra volt lehetőség. Ezen csak a 2.5 változtatott, az már megfelelt annak, amit elvárt az ember egy ilyen kaliberű alkotástól. Kicsit olyan érzésem volt, mintha anno kapodva és nem teljesen készen adták volna ki a 2.0-át.

A köteléktárs viselkedése helyenként érdekes volt, az MI által vezetett gép a szuperember kategóriában volt. Közeli formáció esetén tőled alig néhány tucat méterre szinte késlekedés nélkül követte le manővereidet, ami a kb. a mese habbal kategória. Mondjuk a valóságban, harchelyzetben ennyire szoros köteléknek értelme sincs ezért én mindig távolabbra küldtem, csak sajnos kötelék repülőgépei közötti távolságnál nem volt több fokozat. Csak ez az irreálisan közeli vagy több km-es térköz volt beállítható, de a kettő közt semmi.

Meg hiába a szép grafika a rakéták elől kitérni képtelenség. A Kub füstcsíkja még talán látszik, de a többi rakétáé ne, holott a valóságban azok sűrű, sötét füstcsíkot hagynak maguk mögött. A valósághoz képest nevetségesen gyenge a füst, és a színe is hófehér. Úgy, hogy az egész játékban a horizont állandóan párás és hófehér nappal… A légvédelmi rendszerek itt is eléggé felül voltak modellezve, aminek a 2.5 picit változtatott, de nem sokat.

Apropó, ha már ennyit volt emlegetve a 2.5 kiadás. Abban jelent meg a kabinban a FOV/zoom állíthatósága, a Szu-27 kabin szebb lett és repülhető a Szu-33 hajófedélzeti változat, így lehetséges volt az arra fel- és leszállás is. A két új hadjáratban van next phase / következő fázis opció, hogy ha lelőnék a játékost, akkor is lehet tovább menni. A játék a sikeres bevetések számát számolja, ahogy az F-14 Fleet Defender. Hurrá, sikerült 2001-ben elérni egy 1994-es játék színvonalát. A hiba az, hogy ebben a hadjáratban is érdekes bevetések volt. Az egyikben gyakorlatilag felszállás után az ember nyakán volt több ellenséges gép. Még egy gyakorlott játékos számára is nehéz ez, de ez kezdőnek…? A 2.5 változatban egyes MiG-29 típus változatok is repülhetők voltak köszönhető annak, hogy a MiG-29 kabinja szinte teljesen azonos a Szu-27 kabinjával, könnyű volt modellezni azon a szinten, ahogy a program tette.

Az viszont piros pont, hogy narrált oktatóvideók voltak a játékhoz hála a CD formátumnak hála, de hát akkor ez semmi extra, mert a Jane’s játékokban ott instruktor rádiózással modellezték ezt, nem passzív, hanem a kor szintjén interaktív volt. Az oktató beszélt, a játék meg csinálta amit kellett és visszajelzés volt arról, hogy jól vagy rosszul. Tehát ezen a téren is legfeljebb átlagos volt.

Röviden és tömören, formabontóan értékelés számokkal az én szemszögemből.

  • Grafika 8/10. A funkcionalitása miatt -2, meg azért túltolni se kell a szekeret, hogy ne csak erőművön fusson a játék A Flanker 2.0 esetén ellenben tényleg a grafika zabálta az erőforrást, viszont a Falcon 4.0-hoz képes töredék mennyiségű egységgel dolgozott bevetések közben a játék, mert ugyebár dinamikus hadjárattal nem rendelkezett.
  • Repülési modellezés, 9.5/10, tényleg jó minőségi és mennyiségi téren is.
  • Kabin 9/10. Csak a FOV/zoom hiányzott a 2.0 kiadásából. Amit akkor mutatott az alap, már is szép volt. A 2.5 tökéletes és van FOV. Olvasható minden.
  • Avionika 6/10. Az radar ás a KOLSZ IRST légi harc üzemmódjai és a sisakcélzó rész elég jó, kicsit arcade itt-ott. Az csapásmérő üzemmódja irreális, a TV-s fegyverek modellezése borzalmas, sokszor semmire sem jó, vagy arcade szint, ahol előre ki van jelölve a célpont. Fordulj irányba, Tab-bal célbefogás és tűz.
  • A szimulátor légi harc része élvezetes, akár egy 9/10-et is adnék neki.
  • A csapásmérés és levegő föld üzemmódok egy tízfokú skálán nagy jóindulattal egy gyenge kettes érdemelnek. Az, hogy precíziós rakéták számára előre kijelölt, a bevetésszerkesztőben beállított cél kell az egész egyszerűen nevetséges.
  • Hadjárat/játékélményt nézve összességében talán 2/10. Statikus hadjáratok, amik túl nehezek, körítés semmi, nem állítható a nehézség a hadjáratban, továbbhaladás sem volt lehetséges a 2.5 változatig. A Falcon 3.0, 4.0, Tornado és sejthetően a iF-16 és többi után nehéz szavakat találni. Az még elviselné az ember, hogy statikus, de hogy ilyen nehéz és kiegyensúlyozatlan…
  • A mission editor sokat tud, de még mindig körülményes használni. Az egér két gombját és a görgőt nem képes kihasználni még a 2.5 sem. Minimum egy Tornado szerű hadjárat motort kellett volna kapnia, egy körökre osztottat. Igen erős jóindulattal egy 3/10.

Hajófedélzeti üzem Szu-33-mal, visszapillantó tükör grafikai elem bekapcsolva. Már a 2.0 változatban is lehetőség volt a haditengerészeti Flanker változattal hordozóról repülni.

 

A legfájóbb a fejlődésképtelensége a szériának. A küldetés szerkesztő részletes volt, csak kicsit körülményes volt a használata, de szóló bevetések összefűzésével hadjáratok összerakását is lehetővé tette. Persze itt jön az örök probléma, hogy ez kit érdekel, mert miféle élmény van a saját magad által összerakott bevetéseket repülni nulla véletlenszerű eseménnyel? Más meg nemigen rakott össze hosszú, komplex vagy élvezhető hadjáratokat és DLC-k akkor még nem voltak, bár ezért pénzt kérni meg adott mennyiségű és minőségű tartalom alatt meg elég muris lenne. A korábban kiadott szimulátorok esetén régebben nem volt ritka, hogy kiadtak külön küldetés lemezeket vagy kiegészítő hadjáratokat, de ekkora már ez is divatjamúlt volt.

Összességében nem lehet azt mondani rá, hogy minden térem rossz volt, csak nekem szimplán nem jött be. Ha ismertem volna a Flanker 1.0-át és a többi régebbi szimulátort, akkor azokhoz mérve hiányzott az előrelépés. Viszont ezek hiányában ráadásul eleve a Falcon 4.0-hoz, és annak dinamikus hadjárataihoz mértem. Egész egyszerű az totálisan elavulttá tették a szememben a Flanker 2.0-át miden szépsége ellenére. Ugyanis az előbbi képes volt megragadni egy katonai repülőgép szimulátor egyik leglényegesebb aspektusát, a változatos taktikai környezetet úgy, hogy ne a játékos dolgozzon meg érte. Egyszerűen nem tudott érdekelni, hogy mennyivel rondább kinézetű nagy átlagban a Falcon 4.0 és mennyivel gyengébb a repülési modell abban, mert egyszerűen az élvezhetőbb volt a dinamikus hadjárat által nyújtott környezet miatt.

A Flanker szériát minden kiválósága ellenére nem kedveltem. Nem az zavart, hogy a legtöbb szimulátorral ellentétben orosz gépeket modellezte nyugatival ellentétben, ez éppenséggel üdítő lehetett volna. A bajom az volt vele, hogy valahogy nem sikerült megtanulni vele játszani, állandóan lelőttek. Vagy azért, mert a modellezése helyenként szólva „érdekes” volt – néhány fegyver messze a valóságot felülmodellező értékekkel bír – vagy csak tényleg én voltam ennyire láma. Más szimulátorral boldogultam szóval én a modellezésre voksolok a magam részéről.

Magyarországon még a szimulátor bajnokságot is rendeztek a Flankerral, ezt használták az utód, a LockOn: Modern Air Combat megjelenéséig. Ez azért elárulja azt, hogy egyáltalán nem annyira rossz alkotásról volt szó, ha csak egy szűk spektrumra koncentráltak a játék használata során.

Galéria

http://www.mobygames.com/game/windows/flanker-20/screenshots

http://www.ign.com/images/games/flanker-20-pc-13461/4fa6c974cdc388ed13e4873c

http://www.neoseeker.com/Games/Products/PC/flanker2/screens.html

 

Flanker 2.0, fel- és leszállás repülőgép hordozóra.

Az oktató videók

Flanker 2.5

https://youtu.be/1tcnZypLWhM

 

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

A szöveg korrektúrázásáért köszönet Hedricknek és Csurgai Istvánnak.

A cikk az online változat mellett elérhető, letölthető PDF formátumban is:

https://www.mediafire.com/folder/awoi5aggmo0hg/HTKA_-_6._resz