A német PC Games Hardware-nek (PCGH) lehetősége adódott interjút készíteni Richard Baker-rel, a Respawn Entertainment technikai igazgatójával. Ebből a beszélgetésből sok technikai tényre fény derül, például arra, hogy miért van szüksége a Titanfall PC verziójának 48 GB szabad tárhelyre, amikor látvány és fizika téren sok éves lemaradásban van a többi AAA címhez képest, de haladjunk szépen sorban.
Az interjú elején rögtön a játék szívét képező, 2004-ben debütált Source Engine-t veszi célba. Richard elmondta, hogy mielőtt emellett tették le volna a voksukat, a saját, belső technológiákon kívül több konkurens motort is alaposan megvizsgáltak, köztük a CryEngine-t és az Unreal Engine-t is, sőt még a Unity Engine-re is némi figyelmet fordítottak. A vizsgálatok közben kiderült, hogy a dizájnerek a Source Engine-nel tudnak a leggyorsabban jó eredményt elérni, a produktivitás itt érte el a legmagasabb szintet, így a Valve terméke mellett döntöttek. Érdekesség, hogy az Electronic Arts a legtöbb nagy húzócímét a Frostbite 3 motorra építi, addig a Titanfall kimarad ebből a körből. Ennek üzleti okai vannak, de ennél többet sajnos nem árulhatnak el.
A korosodó motorral kapcsolatban az igazgató elmesélt még egy érdekes történetet: A fejlesztés korai szakaszában elég sokat kísérleteztek úgynevezett Tile-Based és Deferred-Rendering technológiákkal. Aztán amikor ezekkel elérték a kívánt vizuális szintet, megdöbbenve tapasztalták, hogy Forward Render-rel is ugyanazt az eredményt kapták azzal a különbséggel, hogy ez utóbbinál statikus fényeket alkalmaztak. Ez szerinte azért érdekes, mert a legtöbb nagy stúdió manapság Deferred-render típusú motorokat alkalmaz. A Titanfall-hoz megálmodott látványhoz nincs is szükség több ezer dinamikus fényforrásra, mindent statikus fényekkel oldottak meg. A Forward-render típusú motornak hála pedig nem kell foglalkozniuk az élsimítást és az átlátszóságot érintő problémákkal.
Az eredetileg DirectX 9-re épülő, 10 éves motort a Respawn úgy módosította, hogy a render-t DirectX 11-re cserélték, továbbá 64 bites OS-t igényel. A játék erősen támaszkodik a compute számításokra, melyekkel nem csak a renderelés lett jóval hatékonyabb, de olyan dolgokat is meg tudtak így valósítani GPU-val, melyeket compute nélkül vagy a CPU-ra támaszkodva, vagy egyáltalán nem lehetett volna berakni a programba.
Ha pedig már eljutottunk a CPU-hoz érdemes megjegyezni, hogy az öregecske Source-on itt is tudtak javítani. Gyakorlatilag a motor most már annyi szálat kezel, amennyit a hardverünk támogat. Ezen a ponton ugyanúgy működik a játék, mint az Xbox One konzolon. Van egy fő feldolgozó-szál (Main-Thread) és van egy render-szál (Render-Thread). A fennmaradó CPU szálak pedig úgynevezett munka-szálakat (Worker-Thread) képeznek, melyek terhet vesznek le a fő feldolgozó szálról. További teljesítménypotenciált látnak a részecske renderelésben, valamint a fizikai számításokban, így ezeken a területeken még várható némi javulás.
Sajnos a játék startjára nem sikerült korrigálni a több GPU-s rendszereket (SLI és Crossfire) érintő hibát. A javítást tartalmazó patch várhatóan a megjelenést követő néhány napban válik majd elérhetővé.
A PCGH ezután a rombolható környezet teljes hiányára kérdezett rá, amit Richard azzal magyarázott, hogy ugyan kísérleteztek ilyen jellegű funkciókkal, de szerintük túlságosan negatív hatással volt a játékmenetre, így inkább a rombolható környezet ötletét kukázták. Erre talán magyarázatot adhat az a tény, hogy a játék ugyanazt a Havok fizikai motort használja, mint a Half-Life 2 2004-ben. A motor ezen részéhez nem igazán nyúltak, mindössze némi optimalizálást alkalmaztak a kódon. Itt azért R. Baker megjegyezte, hogy a jövőben ezen a területen mindenképp váltani akarnak, mert a jelenlegi megoldás túl öreg.
Sok játékos megdöbbenve és néhányan talán bosszankodva kísérte figyelemmel, amikor közölték, hogy a játék 48 GB-nyi szabad helyet fog igényelni telepítést követően (erről már korábban is készült hír). Ez sokak szemében – teljesen jogosan – érthetetlen ha figyelembe vesszük a sok éves technikai lemaradást. Most azonban erre is megjött a magyarázat. A válasz pedig nem más, mint a játék audio része. Itt a program tömörítetlen hanganyagokkal dolgozik, ami rengeteg helyet felemészt. Az igazgató szerint erre azért volt szükség, mert így sok terhet levettek a CPU válláról. Ha tömörített hangokat alkalmaztak volna, akkor a CPU-nak túl sok idejébe került volna őket feldolgozni és ez esetben nem tudták volna tartani a minimális rendszerkövetelményeket.
(A játék nagyon nagy VRAM igényével a Prohardver ezen írása foglalkozik.)
Végezetül pedig az AMD Mantle API-ról is esett pár szó. Az AMD tartott a Respawn-nak egy egyfajta előadást (demonstrációt), de ekkor túl késő volt ahhoz, hogy a startra beépítsék a játékba. A Respawn csapata alaposan meg fogja vizsgálni az új API-t és ha a belső tesztek kellően pozitívak, akkor a jövőbeni játékaik Mantle támogatást is kapnak. Sőt, kellő sebességlöket esetén akár a Titanfall is kaphat később egy Mantle render-t egy patch keretében.
A teljes interjú a forrás linkre kattintva tekinthető meg.
