// gaming · 2026.09.17 Capcom Spotlight TGS 2026: a Monster Hunter Wilds: Ascendance viszi a show-t A Capcom bemutatta a Monster Hunter Wilds: Ascendance kiegészítőt, a Mega Man: Dual Override részleteit és a Dragon's Dogma 2 bővítményét a TGS 2026-on. olvasás →

A Capcom a 2026. október 2-án megrendezett Capcom Open Conference RE:2026 szakmai konferencián ismertette a REX (RE neXt Engine) projekt műszaki felépítését, amely a vállalat belső fejlesztésű RE Engine játékmotorját modulárisan, lépésről lépésre alakítja át mesterséges intelligenciával támogatott kódgenerálásra és automatizált tesztelésre alkalmas fejlesztőkörnyezetté (a prezentáció technikai részleteit a GameBiz helyszíni előadás-jegyzőkönyve, az elsőként megnyitott komponens hivatalos forráskód-tárolója, valamint az Eurogamer szakmai összefoglalója és az IGN beszámolója rögzíti). Isida Szatosi programozó előadása szerint az átalakítás a motor belső adatkezelését, a fejlesztői felületeket, a naplózást, a szkriptelést és a futásidejű memóriakezelést érinti, miközben a cég továbbra is kizárja a generatív MI-vel előállított képi és tartalmi elemek beépítését a játékaiba.

Az RE Engine fejlesztése 2014-ben indult, kereskedelmi forgalomban pedig 2017-ben debütált a Resident Evil 7: Biohazard alatt, és azóta 27 megjelent cím – köztük a kiadó rekordbevételt hozó húzócímei – alapját adta. Több mint nyolc évnyi aktív használat után a mérnökök három konkrét szűk keresztmetszetet azonosítottak: a fotorealisztikus látvány és a megnövekedett adatmennyiség miatt lelassult az apró paraméter-módosítások és az azonnali mozgásellenőrzések iterációs ciklusa; a motort ma már több mint 2000 fejlesztő – köztük egyre több külföldi és más motorokon szocializálódott szakember – használja; emellett a munkafolyamatok gyorsításához szükségessé vált a mesterséges intelligencia közvetlen csővezeték-szintű integrációja.

Moduláris átépítés: RE:Dox, RE:UI és RE:Log

A teljes motor nulláról történő újraírása helyett a mérnökök a fokozatos, komponensenkénti cserét választották RE+X (REX) kódnév alatt. Az előadáson bemutatott architektúra-ábra szerint az RE Engine magja köré nyolc új alrendszer épül: a RE:Runtime, a RE:Dox, a RE:UI, a RE:Log, a RE:Flows, a RE:AssetStream, a RE:Profiler és a RE:Launcher. Isida Szatosi a prezentációban az öt legfontosabb pillér működését részletezte.

A Capcom REX (RE neXt Engine) projektjének moduláris felépítését bemutató előadásdia a RE:Runtime, RE:Dox, RE:UI, RE:Log, RE:Flows, RE:AssetStream, RE:Profiler és RE:Launcher komponensekkel
A REX (RE neXt Engine) projekt fokozatos, moduláris felépítését szemléltető dia Isida Szatosi előadásából a Capcom Open Conference RE:2026 szakmai rendezvényen. Forrás: Capcom / GameBiz

Az első alapkő a RE:Dox, egy .NET környezethez írt, tokenalapú strukturált adatreprezentációs és szerializációs könyvtár, amelyet a vállalat Apache-2.0 licenc alatt nyílt forráskódúvá tett. A modul tízféle formátumot – JSON, JSON5, CBOR, MessagePack, TOML, XML, HTML, CSV, INI és a saját fejlesztésű DOX – képes egységes, JSON-kompatibilis dokumentummodellként (DOM) kezelni. A rendszer 64 bites fix tokentömbökből (1 bit jelző, 7 bit Variant, 28 bit TriviaId és 28 bit ExtendId) és nyers adatokból épít fel könnyűsúlyú memóriastruktúrát: módosításkor a legfelső helyiértékű bitet 1-re állítja, és a változást bővítménytokenként tárolja a teljes fa újraépítése nélkül. A kétmenetes (2-Pass), többmagos feldolgozásra skálázódó motor a mérések szerint a szabványos System.Text.Json könyvtárnál akár 1,8-szor gyorsabb szekvenciális deszerializációt, 2,8-szor gyorsabb automatikus párhuzamos deszerializációt és 1,6-szor gyorsabb szerializációt ér el.

A második pillér a RE:UI, amely a belső fejlesztői eszközök felhasználói felületét váltja le. A korábbi, XAML-re és eseményvezérelt MVVM-re épülő megoldások gyakran okoztak fagyásokat, szemétgyűjtési (Garbage Collection) megakadásokat, és kizárólag Windows alatt futottak. A RE:UI elhagyja a XAML-t, tisztán C# kódból építi fel a felületet, és több háttérrendszert (köztük a WPF-et és a MAUI-t) támogat, megnyitva az utat a macOS-kompatibilitás előtt. A memóriaterhelés csökkentése érdekében a rendszer szétválasztja a vizuális megjelenést és az állapotot: száz jelölőnégyzet esetén egyetlen közös megjelenítési objektumot tart fenn, és elemenként csak a logikai állapotot (bejelölt vagy üres) tárolja. A kétirányú eseményértesítéseket egyirányú adatfolyam váltja fel, a nézetvezérelt (view-driven) lekérdezési modell pedig csak tényleges állapotváltozáskor rajzol újra, tétlen ablaknál pedig csökkenti a frissítési gyakoriságot. Mivel a bemenetet és a kirajzolást virtuális eszközre választották le, az eszközök grafikus felület nélkül, automatizált egységtesztekkel és visszajátszással is ellenőrizhetők.

A harmadik elem a szintén nyílt forráskódként közzétett RE:Log, amely a naplózást, a telemetriát és az eszközök közötti RPC-kommunikációt egyesíti közös protokoll alatt. A szöveges hibaüzenetek kiírása helyett a programkód kizárólag rövid azonosítókat (például 001-es kódot) rögzít, a megjelenítő pedig csak a megtekintés pillanatában társítja hozzá a szöveget. Ez egyrészt töredékére csökkenti az adatszerveren tömörítve tárolt naplófájlok méretét, másrészt lehetővé teszi, hogy a külföldi fejlesztők a forráskód módosítása nélkül, automatikus gépi fordítással a saját anyanyelvükön olvassák a hibanaplókat.

RE:Flows, RE:Runtime és a kódgeneráló AI-ágensek szerepe

A negyedik komponens, a RE:Flows a játéktervezők által használt vizuális, blokkalapú szkriptelést reformálja meg. Bár a tervezők továbbra is átlátható folyamatábrákon köthetik össze a logikai csomópontokat, a rendszer a háttérben a világ legelterjedtebb, szabványos programozási nyelveinek szabályai szerint olvasható forráskódot állít elő, elkerülve a bináris vizuális szkripteknél rendszeresen jelentkező verziókezelési ütközéseket és hibakeresési nehézségeket.

Az ötödik alrendszer, a RE:Runtime a futásidejű memóriakezelést és a végrehajtási sebességet alakítja át. Amikor a képernyőn egyszerre több ezer karakter vagy tereptárgy jelenik meg, a motor az egyedi objektumkezelés helyett fix méretű memóriadobozokba rendezi az azonos típusú adatokat, és kötegelve dolgozza fel őket. A fejlesztők által kényelmesen szerkeszthető kódot a rendszer automatikusan fordítja le a vállalat saját, nagy sebességű végrehajtási nyelvére, a RE:C++-ra.

Isida Szatosi előadásának záró szakasza rávilágított, miért épül minden új modul a szabványos programozási konvenciókra és a nyílt forráskódra: a cél egy olyan „AI-generációs játékmotor” kialakítása, amelyben a fejlesztők és a mesterséges intelligencia közösen építik fel a projekteket. Mivel a nagy nyelvi modellek és a kódoló AI-ágensek a nyilvánosan elérhető, elterjedt programnyelveken és könyvtárakon tanulnak, a RE:Dox és a RE:Log forráskódjának megnyitásával, valamint a RE:Flows szabványosított kimenetével a nyelvi modellek közvetlenül képesek értelmezni, írni és módosítani a motor kódját. A virtualizált felületek és az egységes telemetria révén az automatizált AI-ágensek önálló tesztfutásokat hajthatnak végre, kiszűrve a futásidejű hibákat a manuális ellenőrzés előtt.

A technológiai automatizálás mellett a vállalat egyértelmű határt húzott a kreatív tartalomgyártásban: a 2026 tavaszán és nyarán tartott részvényesi tájékoztatókon rögzített irányelvvel összhangban a Capcom nem épít be mesterséges intelligenciával generált képi, hang- vagy egyéb tartalmi elemeket a játékaiba. A belső adatszerkezetek nyílt forráskódú szabványosítása és a szkriptek egységes kóddá fordítása a szerializációs többletterhelés csökkentésén keresztül teremti meg a gépi kódgenerálás és az automatizált regressziós tesztelés műszaki feltételeit, változatlanul hagyva az emberi alkotók által készített művészeti és játéktervezési munkafolyamatot.