Az Unvanquished 0.54 az első olyan Unvanquished kiadás, amely a 32 bites és 64 bites x86-os platformokon kívül más platformokon is elérhető. Az Unvanquished mostantól játszható 32 bites és 64 bites ARM-on is Linuxon. Néhány ARM-alapú eszközzel ellátott grafikus chip kissé lassú lehet az Unvanquished lejátszásához, de ez a port teljesíti a játékszerver ARM-on való futtatásának igényét is.

Az ARM-támogatás jelenleg csak Linuxon érhető el. A letölthető játékkód virtualizálásához használt NaCl virtuális gép technológia nem érhető el ARM-re Windowson és macOS-en. Ha már a macOS-ről beszélünk, az Unvanquished 64 bites x86-ra nagyon jól fut Rosetta2-n, így egyelőre a Rosetta2 egy nagyon jó megoldás M1-es maceken.

Az ARM még mindig másodlagos platformnak számít; mint ilyen, a frissítő és indító alkalmazás nem elérhető rá. Aki szeretné kipróbálni az Unvanquished-t ARM-on, annak a letöltési oldalon található „univerzális zip”-et kell használnia, és követnie kell a README fájlban található utasításokat.

Még mindig szeretnék a fejlesztők a játék sandbox környezetét Native Clientről WebAssemblyre portolni, de ez még nem készült el. Ennek elkészítése több rendszert és hardvert tesz elérhetővé, de a WebAssemblyre való teljes átállás még mindig túl korai lenne, mivel egyes platformok, mint például a 32 bites x86, még nem támogatottak a virtuális gépekben és az eszközkészletekben sem.

Közben javították a fejlesztők a kódot, hogy többplatformossá tegyék azt, és a motor toolchain most már készen áll arra, hogy sok más platformot is támogasson. Az egyetlen dolog, ami most megakadályozza, hogy több platformot támogassanak, az az általuk használt gamecode sandboxing technológia.

Mellékesen megjegyezzük, hogy az összes bináris minden hardverarchitektúrához és operációs rendszerhez docker konténerekben épült, beleértve a macOS binárisokat is, amelyek egy Linux konténerben épültek a Darling segítségével.

A grafikus felhasználói felület csiszolása

Unvanquished térkép betöltőképernyője.

A térkép betöltési képernyő mostantól a térkép nevét és a térkép szerzőjének (szerzőinek) nevét a térkép metaadatok alapján mutatja, mivel azokat a térképcsomagok biztosítják. Történelmi okokból az emberek ilyen információkat írtak a töltőképernyőre, erre már nincs szükség.

Aki kreatív akar lenni, az továbbra is készíthet összetett töltőképernyőt, de egyébként egy jól kinéző térkép betöltőképernyőhöz a saját térképéhez most már csak egy képet kell készíteni a térképről, írni néhány metaadatot és a játék szépen kiírja az információt. A jövőben talán még azt is lefordítható lesz, ahogyan az információ kiíródik, ami a képbe égetett szöveggel nem volt megoldható.

Példa egy moddolt szerver üdvözlő képernyőjére.

Mostantól lehetőség van arra, hogy a szervertulajdonos megjelenítsen egy üdvözlő képernyőt, amikor a játékosok csatlakoznak a szerverhez, azáltal, hogy egy ilyen üdvözlő képernyőt egy egyéni csomagban biztosít. Ez nagyon praktikus a játékmenet-változások bevezetésekor, hogy bejelentsék, mi az újdonság és mi változott a változásoknak otthont adó szerverhez csatlakozóknak.

Javult a színkódok kezelése a szövegben, és a színkódok használata az olyan mezőkben, mint a felhasználónevek, már nem büntetik annyira a maximálisan megengedett hosszúság számításakor. Egy színkód csak egy betűnek számít, nem pedig a kód megírásához szükséges karakterek számának. A szín mostantól megfelelően visszaáll a felhasználó által megadott karakterláncok után, hogy az egyéni színeket ne kelljen az egész karakterláncra alkalmazni.

Néhány konfigurációs ablakot finomítottunk, például a hozzáadott vagy eltávolított opciókhoz tartozó mezők hozzáadásával vagy eltávolításával. Néhány napló és egyéb szöveges üzenet átdolgozásra került.

A konzol oldalán a "/cvarname value" szintaxis használatával egy érték beállítása egy cvarba már nem jelöli a cvar-t archívumként (állandónak). A cvar archívumként való megjelöléséhez a beállításkor mostantól kifejezetten a "/seta cvarname value" szintaxist kell használni.

A játékmenet finomítása

A lucifer fegyver modellje most ismét egy korábbi modellt használja. Az embereknek jobban tetszett, hogy ez a régebbi sokkal félelmetesebbnek tűnik, ami a legerősebb fegyver esetében ez is fontos.

Nincs többé negatív lendület (azaz a lendület kisebb lesz, mint a játék elején). A Marauder zap-láncokat érintő hibát kijavítottuk. A rakéták többé nem követik a halott játékosokat.

A nézők többé nem tudják megnyitni a jelzőfény menüt, mivel nem játszanak, nincs információjuk, amit adhatnának! Néhány leltár ikont átdolgozott Nanaa, Gireen és Bob Vador. A meditáció energiátlan animációja most már helyes.

Javítottak a „slap” parancson (a sebesség most már független a tömegtől). Az Unvanquished 0.53.0-ban bevezetett „teamstatus” parancs mostantól alapértelmezés szerint engedélyezve van.

A fejlesztők számára mostantól lehetőség van a lendület eltávolítására a játékban a give paranccsal (korábban csak lendületet lehetett hozzáadni). Ha már a játékkódnál tartunk, több átállás történt a GLM matematikai könyvtárra.

A botok fejlesztése

A bot „remegése” mostantól javítva van. Ez egy olyan hiba volt, ami miatt a bot néha úgy tűnt, hogy egy helyben megrekedt, miközben remegett, mintha összezavarták volna saját ellentmondásos döntései. A botok viselkedési fái megfelelő törődést és figyelmet kaptak. Az akadályok elkerülése is javult, és a fejlett dragonyosok most már céloznak, mielőtt kilövik a tüskéjüket. A Dragoon bot mostantól megakadályozza, hogy a szögesdrótot akkor dobja el, ha túl közel van egy ellenséghez, hogy elkerülje a saját sérülését. A bot kompetenciái újra hozzá lettek rendelve a különböző képességszintekhez.

Mostantól a bot hozzáadásakor a bot paranccsal lehet beállítani a képességszintet, egy új listbots parancsot adtunk hozzá, hogy csak a botokat listázzuk, és mostantól lehetőség van a bot kompetenciák granuláris beállítására: fejcélzás, prediktív célzás, medkit használat, páncélhasználat preferencia, menekülés futás, fájdalomérzet, dragoon barb használat... A g_bot_infiniteMomentum cvar mostantól lehetővé teszi az összes idegen forma, fegyver és fejlesztés feloldását a botok számára, függetlenül a csapatuk lendületétől.
Játékban generált navigációs háló és szállított navcons

A botok navigációjához a navigációs háló vagy navmeshes nevű technológiát használjuk. A navigációs hálót korábban a pályaépítéskor készítettük, ugyanakkor előzetesen kiszámítottuk a fénytérképeket és hasonló dolgokat, mielőtt a játékot vagy az egyéni pályákat kiadtuk volna. És ezeket a navigációs hálót a térképpel együtt kellett terjeszteni.

Navmesh-ek generálása a játékban.

Tehát eddig egy külön eszközzel, a daemonmap nevű eszközzel generáltuk a navmesheket, ami mostanra elavulttá vált. Mostantól a játékban generáljuk őket.

Az első hátránya a navmeshek térképkészítéskor történő generálásának az volt, hogy a térképekkel együtt kellett szállítani őket, ebből sok más hátrány származott! Ha a generátor frissül, a meglévő térképek továbbra is a meglévő navmesh-eket szállítják, amelyek nem részesülnek a generátor frissítéséből. Ha a játékkódot frissítették, a meglévő navmesh-ek még mindig az előző verziót céloznák meg. Ha valaki modot akart készíteni, és fajokat akart hozzáadni vagy módosítani, a meglévő navmeshek hiányoznának a hozzáadott fajokhoz, vagy csak rossz fajtulajdonságokat feltételeznének.

A játékban generált navmeshekkel a térképek ezek nélkül is szállíthatóak. A játékkód mindig újratermeli a navmesh-t, ha valami megváltozott: vagy a térkép változott, vagy a játék. Ez azt is jelenti, hogy a generátor javítása automatikusan regenerálná a navmesh-eket, amikor a játék új verzióját terjesztik!

A detour és a Recast alapján a navmesh generálására szolgáló kódot alapvetően a daemonmap-ről portoltuk át a játékkódunkba, és valamilyen mechanizmust implementáltunk, hogy a generálás menet közben, a szerver blokkolása nélkül történhessen.

Néhány navcon fájlt mostantól néhány térképhez mellékelünk, hogy segítsük a botok navigációját. A "navigációs kapcsolat" vagy navcon egy speciális fájl, amely két, látszólag nem összekötött hely közötti egy- vagy kétirányú utakat listáz (a Recast/Detourban az ilyen kapcsolatot "off-mesh kapcsolatnak" nevezik). Ez használható például arra, hogy a botoknak megmondjuk, hogy egy platformról leugorva elérhetnek egy másik útvonalat, és ezt a konkrét útvonalat figyelembe vehetik az útvonal-számításukban. A navcon formátum mostantól szöveg alapú, így a navcon fájlok barátságosabbak a git tárolókkal.
Erőfeszítések a renderelőn és a motoron

A fénystílusok mostantól kikapcsolhatók. A fénystílusok egyfajta előre kiszámított dinamikus világítás statikus térképobjektumokhoz. A térképek összeállításakor generálódnak a lightmaps sütése közben. A funkció úgy működik, hogy dinamikusan több lightmapot keverünk össze ugyanarra a felületre a játékban. Mivel ez a funkció nem túl nagy teljesítményű (már a 2000-es évek elején is létezett, és már a Tremulous térképekben is használták), egyelőre csak a "legalacsonyabb" grafikai előbeállításban van kikapcsolva.

Az opcionális funkciókhoz tartozó további fájlok felesleges betöltését megakadályozzák, ha a kapcsolódó funkciókat letiltják: például a deluxemapok nem töltődnek be többé a lemezről és nem kerülnek a GPU-ra, ha az ezeket használó funkciók le vannak tiltva. Mivel az XreaL (a motor, amiből a Dæmon származik) bizonyos szempontból leginkább egy technikai demó volt, előfordul, hogy néhány kód inkább a funkciók bemutatására koncentrált, mint azok letiltására, és néha a kód erős feltételezésekkel élt ennek vagy annak elérhetőségét illetően! Idővel lépésről lépésre opcionálisabbá tesszük a dolgokat, ami azt is lehetővé teszi, hogy a kódot robusztusabbá tegyük.

A dinamikus fényekkel kapcsolatos néhány komoly problémát megoldottunk. Egy régóta fennálló hiba miatt a jelenetben lévő 4 dinamikus fényből csak 1 került ténylegesen renderelésre. A hiba eddig észrevétlen maradt, mivel a legtöbb dinamikusan megvilágított eszközünk több fényből álló csoportokat használ. Váratlan mellékhatásként a javítás egy még rosszabb (és könnyen észrevehető) hibát is kijavít, amely a saját fejlesztésű Nvidia meghajtó legújabb verzióit érinti, ahol a dinamikus fények sokkal világosabbak, mint kellene. Úgy tűnik, hogy valamilyen kifürkészhetetlen okból a változtatás hatására a GLSL fordítójukban lévő hiba nem lép működésbe.

A motor mostantól képes az EXT_framebuffer_object OpenGL-bővítményt használni, ha az ARB_framebuffer_object nem elérhető. Az EXT funkció az ARB egy részhalmaza, de mi csak ennek a részhalmaznak a funkcióit használjuk, így nincs szükség arra, hogy önkényesen megakadályozzuk, hogy a motor olyan régebbi hardvereken fusson, amelyek még képesek erre.

A navmesh renderelése a navedit parancs használatakor (kicsit) kevésbé bugos. Ez egy fejlesztői parancs, amivel a játékot egy speciális módba lehet kapcsolni a navmesh-ek megjelenítésére és a navcons generálására. Tehát bár a tökéletes vizualizáció nem a legfőbb prioritás (ez nem befolyásolja a játékosokat), a kevésbé hibás megjelenítés mindig üdvözlendő.

Néhány egységtesztet adtunk hozzá a Googletest keretrendszer segítségével. Sok hibát és összeomlást is kijavítottunk, halott kódot takarítottunk ki, a jobb hatékonyság érdekében átírtuk a kódot, több kommentet írtunk, hogy a kódot kicsit jobban dokumentáljuk, stb.
Nincs több Python 2 az Unvanquished toolchainben.

A NaCl SDK-t, az utolsó darabját az eszközláncunknak, ami Python 2-t igényelt a játék építéséhez, átportoltuk Python 3-ra. Ezt a dolgot csak az építéskor használjuk, amikor letölthető játékkódot készítünk, így ez csak a fejlesztők érdeke volt (maga a játék C++-ban íródott, és nem igényel Pythont a futtatásához). A Python 2 elöregedése és egyre növekvő elérhetetlensége a fejlesztők és a modderek számára aggodalomra adott volna okot, ha nem végezzük el ezt a portolást. Viszlát Python 2!
Játsszunk!

A játék februárban lesz 11 éves. Ha még nem olvastad, akkor olvasd el a 10 éves visszatekintésünket!

A játék 2021-ben lépett be a béta ciklusba, jelenleg több mint 300 közösségi pályát játszanak a szervereken (a legtöbbet a Tremulousból portolták). A különböző kód-hozzájárulások mellett Sweet szinte az összes ilyen pályát portolta is...

Terjessze a hírt, töltse le a játékot, csatlakozzunk szerverekhez, és játsszuk az Unvanquished-t!

 

Az Unvanquished egy ingyenes, nyílt forráskódú, első személyű stratégiai lövöldözős játék, amelyben a technológiailag fejlett emberi katonák a rendkívül alkalmazkodóképes idegenek hordái ellen küzdenek. A játékosok bármelyik csapatból választhatnak, ami teljesen más élményt nyújt mindkét oldalon, mivel az emberek a nagy hatótávolságú tűzerőre, míg az idegenek inkább a gyors mozgásra és a lopakodásra támaszkodnak. Minden mérkőzés célja az ellenséges bázis elpusztítása, megakadályozva az ellenfél csapat tagjainak szaporodását. A fejlesztéseket mindkét csapat számára az egyéni teljesítmény és a csapattérkép irányítása kombinációjával lehet megszerezni, így az emberek erősebb fegyverekhez és felszerelésekhez, az idegenek pedig nagyobb, vadabb formákhoz férhetnek hozzá.

Projektünk 2011 nyara óta fejlesztés alatt áll, a legelső alfa kiadásunk 2012. február 29-én készült el. Azóta havonta jelentetünk meg alfa kiadásokat, és minden egyes új kiadás új tartalommal bővült eszközök, térképek, játékmenet vagy motorfunkciók formájában. Fejlesztőcsapatunk képzett hobbistákból és tapasztalt szakemberekből áll a világ minden tájáról, és mindig szívesen fogadunk új csapattagokat, mind a közösségből, mind a közösségen kívülről.

Az Unvanquished a Tremulous forkja, a Dæmon motorral. A Dæmon motor, ami a játékunkat hajtja, végső soron a Quake 3-on alapul, az ETXreaL funkcióival és a saját kódolási erőfeszítéseinkkel együtt. Jelenleg azon vagyunk, hogy a motorunkat átírjuk C++-ra a jobb hosszú távú karbantarthatóság érdekében. Néhány jellemzőnk a következő:

• Egy modern renderelő, amely az OpenGL 3-at és újabbakat célozza meg, kompatibilitási móddal az OpenGL 2.1 számára;
• Speciális effektek, beleértve a bloom, rim lighting, motion blur, heat haze és color grading;
• Fejlett textúrázási technikák, beleértve a többtextúrás terepkeverést, normál és relief leképezést;
• A csillogás, a fényesség, a tükrözés és a fizikai leképezés támogatása;
• Modern RmlUi felhasználói felület, amely támogatja a HTML4+/CSS2+ szabványokat;
• NativeClient VM-támogatás a rendszereken átívelő homokozós játéklogikához;
• Natív dll-támogatás a játéklogika hibakereséséhez és a kutatásbarát prototípusok készítéséhez;
• IQM és MD5 modellek vázanimációval és procedurális animációk keverésével;
• 2D minimapok és valós idejű jelzőrendszer;
• Navmesh-alapú botok, amelyek viselkedési fákat használnak.