Metrospective: 4A Games vs. Digital Foundry

Unreal Engine has defined the technological standards of high-definition console shooters, but Gears of War apart it seems as if it is down to proprietary engines to exceed them: Infinity Ward, Bungie and Guerrilla Games have produced the most critically well-received FPS titles on console, and all of them are using their own in-house technology.

Coming from the technological architects of GSC's S.T.A.L.K.E.R., the new 4A engine powering Metro 2033 from THQ is another proprietary codebase that looks capable of producing pretty astonishing visuals. Thus far, most of THQ's marketing efforts have concentrated on the visually superb PC build, though Eurogamer got hands on with both versions last month. Digital Foundry has had extensive access to a preview Xbox 360 build, and what we've seen has been impressive.

To give you some idea of what has caught our eye, here's a video of the game running on the Microsoft console, captured and edited by us with a view to showcasing the unique visual look of this new technology, and how it translates into the gameplay.

We wanted to know more, so arranged an interview with 4A Games' chief technical officer Oles Shishkovtsov. Having previously worked with GSC as an instrumental guiding force behind the technologically impressive S.T.A.L.K.E.R., there has been controversy that the 4A engine is an offshoot of proprietary GSC IP, but Shishkovtsov disagrees, saying that the new tech was started as a pet project borne out of the frustrations in dealing with his older engine.

"The major obstacles to the future of S.T.A.L.K.E.R. engine was its inherent inability to be multi-threaded, the weak and error-prone networking model, and simply awful resource and memory management which prohibited any kind of streaming or simply keeping the working set small enough for 'next-gen' consoles," explains Shishkovtsov.

"Another thing which really worried me was the text-based scripting. S.T.A.L.K.E.R. was purely LUA-scripted," he continues. "Working on S.T.A.L.K.E.R. it became clear that designers/scriptwriters want more and more control and when they got it, they were lost and needed to think like programmers, but they weren't programmers! That contributed a lot to the original delays with S.T.A.L.K.E.R."

It was these problems and issues that left Shishkovtsov looking for an entirely new direction for the next engine.

"I started a personal project to establish the future architecture and to explore the possibilities of the design," he says. "The project evolved quite well and although it wasn't functional as a game (not even as a demo: for example it didn't have any rendering engine back then) it provided me with clear vision on what to do next."

Shishkovstov and his colleague Aleksandr Maksimchuk left GSC a full year before S.T.A.L.K.E.R. eventually shipped, and the 4A engine, with its emphasis on a hugely efficient implementation of multi-threading good for both PC and console, took shape. Shishkovtsov claims that the 4A engine has no relationship with the S.T.A.L.K.E.R. X-Ray tech because a port would be "extremely difficult".

"A straight port will not fit into memory even without all the textures, all the sounds and all the geometry," he reckons. "And then it will work at around 1-3 frames per second. But that doesn't matter because without textures and geometry, you cannot see those frames! That's my personal opinion, but it would probably be wise for GSC to wait for another generation of consoles."

According to Shishkovtsov, the philosophy of parallelising the code is different to many games, but akin to the techniques employed by Criterion Games for Burnout Paradise: processing tasks are allocated to whatever processors are available at the time.

"We don't have dedicated threads for processing specific tasks in-game with the exception of a PhysX thread," explains Shishkovtsov. "All our threads are basic workers. We use task-model but without any pre-conditioning or pre/post-synchronising. Basically all tasks can execute in parallel without any locks from the point when they are spawned. There are no inter-dependencies for tasks.

It looks like a tree of tasks, which start from more heavyweight ones at the beginning of the frame (to make the system self-balanced). The last time I measured the statistics, we were running approximately 3,000 tasks per 30ms frame on Xbox 360 on CPU-intensive scenes with all hardware threads at 100 per cent load."

And again, similar to Criterion's multi-threading work, 4A Games has found that a similar implementation works on the Sony console too.

"The PS3 is not that different... We use 'fibres' to 'emulate' a six-thread CPU, and then each task can spawn a SPURS (SPU) job and switch to another fibre. This is a kind of PPU off-loading, which is transparent to the system. The end result of this beautiful (apart from somewhat restricting) model is that we have perfectly linear scaling up to the hardware deficiency limits."

While the engine is described as a complete cross-platform development environment, there is to be no PlayStation 3 SKU of Metro 2033. The game will launch on PC and Xbox 360 only. However, the Sony console played a big part in the development work for the core tech.

"From the start we selected the most 'difficult' platform to run on. A lot of decisions were made explicitly knowing the limits and quirks we'll face in the future," explains Shishkovtsov.

"For me personally, the PS3 GPU (they like to call it RSX for some reason) was the safe choice because I was involved in the early design stages of NV40 and it's like a homeland: RSX is a direct derivative of that architecture. Reading Sony's docs it was like, 'Ha! They don't understand where those cycles are lost! They coded sub-optimal code-path in GCM for that thing!' All of that kind of stuff..."