Slashdot Mirror
Tim Sweeney Talks Unreal Engine 3
An anonymous reader writes "Following the recent unveiling of Epic's Unreal Engine 3, Beyond3D has interviewed Tim Sweeney of Epic about the next-gen videogame engine. The discussion is mainly about the 3D requirements, but they also touch on other technologies that are used or required: 'Off-the-shelf 32-bit Windows can only tractably access 2GB of user RAM per process. UT2003, which shipped in 2002, installed more than 2GB of data for the game, though at that time it was never all loaded into memory at once. It doesn't exactly take a leap of faith to see scenarios in 2005-2006 where a single game level or visible scene will require >2GB RAM at full detail.'"
I thought that I read the memory addressing in 64bit windows was also set to 32bit addresses. Would this means that current 64bit windows binaries also limit this? It'd be pretty cheasy to have multiple processes with IPC's to fully load the games, or anything into memory.
Bye!
From Planet Unreal,
You probably want to use memstat. While in the game, hit the backquote key (often called the tilde key, ~) to bring down the console. Type in the command, hit enter.
I tend to avoid stat all because it just crowds the screen, but stat fps is useful for determining the effects of display settings as well (for performance)
"That's all nice and well, but who actually makes the content that fills up those 2GB? You'd need a pretty large team and several months or years to make that much stuff..."
2D and 3D artists make the content that fills that space. The thing to remember is that it isn't necessarily a linear relationship between how much arist time is needed and how much RAM is being taken up. Using 2x the texture size, for example, doesn't take twice as long to generate. A lot of time spent on making 3D art is in shrinking things down to meet the requirements.
Check out this image I made here. (Note: That's not a game model.) *All* of the textures were originally generated at 3072^2 resolution. They were too high for my tiny gigabyte of RAM, so I had to knock them down to 2048^2. If I had started at 2048, it wouldn't have been much faster to generate them. The source imagery was big enough in either resolution, so short of the extra processing time it'd have taken, it would have been pretty much the same.
The real time spent will be in making something more ambitious. Twice as long? I doubt it. Maybe one day when the game machine has specs that exceed the artist abilities, but we are generations away from that. The tools we have today are pretty darned cool, and they're only going to get better as each generation goes by.
In short, these companies already have the talent *today* to put 2 gigs worth of content on the screen.
"Derp de derp."
Crystal Space fits the bill in my opinion.
It is being used for a couple of commercial level games from what I understand.
If you're seeing copied and pasted rooms, that's more due to a poor developer than due to a space limitation.
I'm a single-player mapper for Half-Life in my spare time. Stuff I've done has been fairly well received. And I can tell people this - map design for single-player games is difficult. I can spend a week perfecting something that'll last the player ten seconds. A simple room can take days to build, and this in on the original Half-Life where a suitably textured cuboid can be just about anything.
In a modern engine, the workload is increased enormously. You need 3D modellers to create the static meshes (which replace those textured cuboids of the past), texture artists to do the map-specific texturing (high-resolution now, and it can't all be photo-sourced), voice actors for the map-specific dialogue. There's scripting (which needs to be tested for all possible routes and combinations of routes - non-linearity's the thing!), there's map geometry, there's programming, there's playtesting, there's tuning...
And it all has to come together into a cohesive whole - and judging by some of the game demos I've played recently, it often isn't. Copied and pasted rooms imply that the game designers are concentrating on the wrong area of the game - graphics might be lovely, but if the map design stinks, the game's in danger.
Tedious Bloggy Stuff - hooray?
Another good one is Ogre. It's purely a rendering engine, which lets you choose your collision/sound/networking/whatever else libraries, but there are a few engine frameworks springing up around it. It's fast, very clean, and capable of a lot of current generation effects (well, it has full shader support, so I guess it supports most anything you can code a shader for). If C# is your flavor, Ogre has a cousin called Axiom that is just as functional. Axiom is intended to be a game engine, but is very much in its infancy, so there isn't too much besides (rock solid) rendering in place there yet. Still, though, both are very clean and excellently designed, and are both well worth a look.