A reprint from the March 2013 issue of Gamaustra's sister publication Game Developer magazine, this article finds is a brand new interview with Epic Games founder Tim Sweeney.

You can subscribe to the print or digital edition at GDMag's subscription page, download the Game Developer iOS app to subscribe or buy individual issues from your iOS device, or purchase individual digital issues from our store.

Sometimes we reach greatness by standing on the shoulders of giants -- and anyone who has ever made a game with the Unreal Engine knows that Tim Sweeney is just such a behemoth. He wrote a quarter-million lines of code in the original Unreal Engine, and though he's founder and CTO of Epic Games, he still actively codes every day.

It's a curious exercise to think about where the industry would be today if not for the Tim Sweeneys and John Carmacks of the world. Luckily, we work in an industry where most of our legends are living, working, and still pushing us forward. Many of them are shuttered away from the world, either working diligently on their next project, or shielded from the press by concerned public relations staff.

As luck would have it, I caught Sweeney in Taiwan after giving a talk, unencumbered by handlers or hangers-on, and was able to have a candid discussion with him about the future of game consoles, code, and, as it happens, John Carmack.

What does it take to be five years ahead of the game industry, so you can have tools ready when developers need them? What problems do we still have to solve? Who will be the guardians of triple-A games, as much of the world moves to web and mobile? Sweeney doesn't have all the answers -- but whom better to ask?

Let's start off with a big sandbox question. What do you see as the next big thing the industry needs to tackle graphics-wise and computationally in games?

Tim Sweeney: Oh, wow. The industry's advancing on a bunch of fronts simultaneously. One is just advancing the state of the art of lighting technology. We've really added to that with sparse voxel octree global illumination stuff -- basically, technology for real-time indirect lighting and glossy reflections.

That's really cool stuff, but it's also very expensive and only suited for the highest-end GPUs available, so having a family of solutions for that that scales all the way down to iPhone with static lighting is a big priority for Epic -- the ability to go to a game that scales in a dramatic factor from low-end to high-end.

We're really concerned -- I think it's our number-one priority, really -- with productivity throughout the whole game development pipeline, because we're looking at companies like Activision spending $100 million developing each new version of Call of Duty, and that's insane!

We can't afford that sort of budget, so we have to create games with fewer resources. Any way we can tweak the artwork pipeline and the game scripting pipeline to be able to build core games more quickly with less overhead is better. We put a lot of effort into visual scripting technology to greatly improve the workflow.

It does look a lot more intuitive for a less tech-savvy person.

TS: With Unreal Engine 4, we really want to be able to build an entire small game on the scale of Angry Birds without any programming whatsoever, just mapping user input into the actions using a visual toolkit. This technology will be really valuable. We're also expanding the visual toolkit for everything: for building materials, for building animations, for managing content when we have a huge amount of game assets. We're just greatly simplifying the interface so that it's basically as easy to use as Unity.

On one hand, you have the Unreal Engine having by far the largest and most complete feature set of any engine, but also with Unreal Engine 3 it was a big, complicated user interface. With Unreal Engine 4, the effort is to expose at the base level everything in a very simple, easy-to-use, and discoverable way and to build complexity on it so that the user can learn as they go without being terrified by it in the form of a huge, complicated user interface.

That's a problem all applications have to deal with nowadays. If you look at an iPad app that does 90 percent of what the world needs really easily, versus a Windows version of the app for something like Photoshop -- I spent an hour and couldn't even figure out how to draw a picture in Photoshop; it's that bad. (laughs) There is a lot to do there and a lot to learn from.

Epic Citadel

Going back to voxels, I've always been kind of fascinated by them because they're less expensive with higher fidelity potential, but you can't texture them and you can't really animate them well. Do you ever foresee a future in which that might be possible? It would be a total industry shift away from triangles, but...

TS: It's clear now that voxels play a big role in the future.

Certainly for lighting, right?

TS: Well, that's just one way we've been finding to use them effectively. [John] Carmack did a big write-up about voxels and the virtues of sparser representations of the world. It seemed crazy to me at the time, but now it's becoming clearer that he had a lot of far-ranging insight there.

The thing about voxels is they are a very simple, highly structured way of sorting data that's easy to traverse, whereas any other form of data, like a character stored as a skinned skeletal mesh, any time you want to traverse it, you have to do a gigantic amount of processing work to transform it into the right space. You need to figure out what falls where and rasterize it or whatever, but voxels are just efficiently traversable. I feel like there's a big gap.

The data representation you want to use for rendering your scene differs greatly from the representation you want to use for manipulating your scene and basically moving objects around and choosing how they interact. It's not clear which representation wins. In the sparse voxel-oriented approach, one neat thing is we can update it dynamically; as objects move around, we can just incrementally change those parts of the voxel octree that are relevant. You can figure out the extreme edge case of the algorithm, so that instead of the voxel octree being fixed with its orientation to space, all you have to do is align it to screen and arrange it objectively so you're seeing a 2D view of this voxel octree, whereas the other dimension is your z dimension.

You basically have this projective voxel octree, stick everything in the entire scene into it, every frame, and then that unifies all of these screen space techniques like screen space ambient occlusion with the large-scale world effects that we're using with the sparse voxel octrees. Imagine rasterizing your entire scene directly into a representation like that -- using that for real-time lighting and shadowing and then rendering that result out the frame buffer. It's hard to say whether that has merit; that's an algorithm where you need 20 or 30 teraflops as opposed to one or two.