Slashdot Mirror
Localizing High-End Games for Low-End Machines
CowboyRobot writes "Intel engineer Dean Macri has an article at ACM Queue listing the challenges in designing PC games that will run on very different processors.
PCs vary widely in their performance, and if game developers design only for the high-end, they limit their market.
The article lists specific tips on how to guarantee that even old slow machine can run new games, such as 'the number of triangles used to create the trunks and branches could vary based on the available processor and graphics hardware performance', 'replace the clothing on characters in a game with actual geometry that separates the clothes from the underlying character model', and for simulating ocean waves, having low-end systems rely on basic sine waves while higher-end machines use more sophisticated methods."
'replace the clothing on characters in a game with actual geometry that separates the clothes from the underlying character model'
.. come to think of it, I might be playing the next Tomb Raider on my Pentium 133. Half a frame a sec is fine if it gives me half a chance to ogle Lara's buttcrack.
This actually sound like a pretty good idea. Hey, I got one too. Perhaps they could just leave out the clothes completely on low end machines?
It's easy to say what you want to do when you have unlimited processor resources. But when you don't, you'd rather your program not crash or totally freeze. Especially in a game environment, throwing the little things overboard first will leave the main gameplay elements in tact and still leave a playable game.
Yeah, it means extra programmer work on the design side because you're going to have to design a "smart version" and a "dumb version" for the effects you want to downgrade. You'll also have to select how you're going to measure system resources, and at what level of resources will the changeover for smart to dumb happen for each element. It's work, but I think it's an investment with a payoff.
The keyword is "graceful degradation". Take away the elements that contribute to the "wow factor" for the power user but the low-power user won't really miss. Background elements are the key thing you should be thinking about, especially ones that'll never have much direct impact on the outcome of game situations.
It's all about raising the spread between your "minimum" and "looks best on" system requirements. You want to get the minimum as close to the floor as possible, while having the high-end features will create great demo installations and really sell your game to the high-end fans. The more people who can enjoy your game, the more copies you'll sell, and therefore the more money you'll make. You remember money, right? It's the whole reason games are written anyway...
PCs vary widely in their performance
This is why I come to slashdot, the deep technological information you can't get anywhere else.
Like the X-Box?
This would require an incredible amount of engineering support for practically no payoff.
Next generation games like Doom 3 and Half-Life 2 will allegedly scale to meet these sort of demands. And as long as the engine and development tools are written with scaleability in mind, the challenge should be far less for the game developer (assuming they can afford the engine!)
Karma: It's all a bunch of tree-huggin' hippy crap!
Why would they bother optimising games for low-end hardware? We all know that software drives sales of hardware.
Hell, look at most of the hot games coming out: they have marketing deals with the graphics card makers.
Does it make you happy you're so strange?
Isn't this stating the obvious? Of course you could do this to speed games up, but all of these factors require longer development time.
With the rushed nature of game development, I don't think game companies are that worried about this. It raises development costs without paying out much- most gamers keep up with the latest video card, processor, etc., and won't benefit from this.
The type of computer user that doesn't upgrade their system very often is the same user that doesn't buy very many games.
If these games were open source projects, these sorts of enhancements could be possible. Since the code is open and shared, some guy with a low-end machine wants better performance, so he writes simpler algorithms to emulate the real ones. When you build your own copy, you just pick which optimization level you want to be at.
Instead of trying to do super-duper processor detection degradation stuff, let the player choose levels of detail and such-like.
That way he can choose whatever's important to him... if he's a big fan of realistic trees, let 'em have it at the cost of slower AI or whatever.
The Army reading list
Valve has been conducting and publishing system specification surveys. It's interesting to see that the majority of their respondents are using GeForce 4 MX cards; I would have thought higher specs.
The most annoying thing about detail controls in games is that it's unclear what you (the end-user) are changing when you tweak the knobs. As a developer of 3d applications, (who's guilty of same), I think I'll approach this in the future by giving users immediate feedback: "Here's what your scene will look like with low shadow detail. Here's how smoothly it'll run, on average."
We're indie. We're working on our 14th game.
and for simulating ocean waves, having low-end systems rely on basic sine waves while higher-end machines use more sophisticated methods.
It looks better if you just use a cosine...
Increasingly I've seen the reliance on a better graphics card to significantly improve frame-rates the most. Take my current box, in the past few months I just upgraded my PIII 450 from '99 to a P4 2.6 800Mhz FSB. RAM went from an initial 128MB to 320 MB SDRAM last year into 512 MB DDR dual-channel now. The overall improvement in gaming has been limited though. Yes, things do run much better than they did in the past. Massive numbers of units and other computationally intensive tasks have obviously seen the most improvment, but the graphics card is holding everything back.
I'm using a GeForce2 GTS from '00 at present and I certainly feel it. Vice City can drop to a crawl at times and other games need the graphics options knocked back quite a bit in some cases. While the $300 I spent on motherboard and processor upgrades are noticed the same amount of money needs to be put into a graphics card to really notice an improvement in frame rate and for almost all intents and purposes, actual improved performance.
The graphics card is increasingly becoming a major (not to mention expensive) bottleneck that needs to be upgraded on a much faster path than the rest of the system to stay competitive. The only advantage here is that in many cases a weak processor can be enormously helped in some cases by a cutting-edge graphics card.
While the article has a lot to say on this topic and it's certainly one of the easiest changes to implement scalability in it can still be a problem in many cases and should perhaps be addressed more seriously. Graphics technology, moreso than any other part of the computer is really what's driving gaming these days and should be watched closely to keep it in check.
One method of making scalable games is to use recursive based algorithms to generate the graphics. Basically, code up a 'for' loop, and vary the number of iterations depending upon the architecture of the machine it's running on. For things like trees, water, snowflakes, clouds, grass, hair, and so forth, this optimises rather well.
For example, refer to Koch's Snowflake
On a low end machine, only two or three iterations would be needed to create a decent snowflake. On a high end machine, you could iterate this function a hundred times with various compounding affects such as rotate, copy, resize, diff, transparency, and so forth. With high end machines, you can do close ups of snowflakes without any resolution loss... And most all of this is using the same algorithm as the lower-end machine would use...
Granted, the fractal algorithms have to be well designed and thought out to achieve this effect. A basic Koch's Snowflake algorithm at high iterations doesn't look too much different from lower iterations... Some transforms would need to be introduced to the algorithm, but those could also be scalable...
Anyhow... $0.02 cents
Okay, so imagine we've got a FPS set on the water (just for kicks, call it Waterworld). You have the sine wave water and I have the sophisticated uberalgorithm water. When you shoot me, your client-side model for water thinks I am in spot A, while my uberalgorithm water thinks I'm in B. You shoot me -- but from my perspective (pun intended!) you couldn't have seen me.
/render/ the smoke.
Sounds like about 10 million "he hacks!" calls waiting to happen.
I remember people turning the smoke off in their Halflife clients because they wanted to see through it. At one point, my graphics card driver wouldn't even
Let's try an alternate approach: let's market the games for the sophisticated gamer and that will get more people to buy better machines. Not everyone is rich, but (see above) It's the Graphics Card, Baby!
[Error 407: No signature found]
I do not think that word means what you think it means.
I remember when games were about gameplay.
I swear this is the biggest fallacy ever.
Have you actually gone back and played those old games recently?
For me games are very much like old comedy shows and jokes, because they're old, I've heard all the jokes before. In games, I've played all those old school games, I've heard the joke done to death and only gain enjoyment from the reminiscence.
Game genres have gone through evolution after evolution, each generation extracting and developing upon succesful ideas until we are at the current state.
Look at Pole Position, compare it to Outrun, and then Burnout, the evolution is obvious. Each game has kept the same gameplay fundamentals and expanded/improved upon them. Of course the increase in hardware performance has helped, but I would say that if the hardware was available at the time of Pole Position was made with none of the history of the racing game, we would have seen Pole Position simply with flashier graphics.
Instead of looking at making a game scalable on a single computer, how about looking at leveraging it off multiple machines instead.
Have a central box that controls the game mechanics, then farm out the rendering engine to multiple servers. Most homes are moving to multiple computers in any number of of applications.
Now, I generally loath the idea of gridcomputing, but rendering is one of the areas it is good at. Have a central box run calibration tests for the graphics flow, then you can add or remove additional processors as needed. A single processor would represent the lowest level.
So, market a generic game rendering standard that can be ported to any sort of processor (including embedded cpu appliances ), then focus on the console box or computer to combine the results.
While the industry specialists are worrying about compatability (which is a valid problem) Microsoft is selling single use machines such as the Xbox at a loss. Maybe it's time to produce similar architectures and even homoginize the processor/chipset platforms into something recognizable as one system. Unfortunately most people get linux for free, don't support open source projects, and then expect the world to cater to their minority preference of alternative environments.
As far as keeping in line with the article I do believe that instead of a diverse platform on which to design games, we are going to instead have more specialized products such as the Xbox and the TiVo that are going to destroy the computer's list of abilities one by one. In the end i see more and more Dell's and HP computers turning into conversation pieces instead of being diverse, which is in direct support of the premise of the article. Diversity in this field currently leads to an inability to produce games that sell well to an uninformed culture, instead you are developing games like GTA which was developed separately for 4 different systems instead of all at once like Sonic Heroes.
and you get:
Quake 2 with nekid Stroggs galore.
Wolfenstein with a nude Adolph Hitler
GTA 2 with realistic squeeky vinyl bucket seat sounds.
Silent Hill's "playdead" of the month.
Warcraft 3 expansion - Frozen Cajones
and Frodo still says "I am naked before the wheel of fire" in LotR, but he's grinning.
Who is John Cabal?
Instead of forcing me to make individual choices about every single optional CPU or GPU taxing feature, try and detect the capabilities of my computer and give me the best picture quality I can get at a smooth framerate.
That way I don't have to study the impact of every single optional feature... if my computer can handle two pixel shader passes, 100 MB of textures, and models which have been decimated to 10000-20000 triangles each, I still won't have to know what a "pixel shader" is before playing.
I dunno...I'd still rather play Pong or Frogger than huge overdone games.
Extremely obvious and predictable appeals to nostalgia seem to be really popular with mods on Slashdot.
You'd rather play Frogger?
Then my question is, for every person who claims they'd rather play Atari or any given classic system than a present day one, how many serious gamers who own both ACTUALLY spend more hours per week playing 1970s/1980s games than post 1990 ones over long periods.
It's often said, but it's an extremely few who can back up their whistful nostalgic ponderings by citing that as the absolute reality of their gaming behaviour. Heck, I'm a serious collector of TI 99/4A parts and games, owning and coveting some virtually non-existent or prototype carts, and even I spend far more time on my newer systems than on the TI 99/4A (although I played Parsec for the TI 99 a bit this afternoon).
I don't play it because it's better than my newer systems. It's not because it can compete. It's nostalgia.
I don't have a problem with nostalgia, but I do contend against the idea that something like Super Monkey Ball 2 or Metroid Prime can be outdone in general by something like my favourite TI 99/4A games. The technology simply did not allow all the things that a new game can allow us to do. And some of those new thing are fun, and immersive. So I refuse to believe that absolutely all new computer/gaming technologies and techniques developed since the 2600 have been completely irrelevant to the advancement of gaming entertainment, and that, Frogger being just as much fun as present day games, we may as well just go back to coding CGA games in BASIC for all it matters.
The first one does not allow you to take advantage of many new techniques. You have one version of everything, and takes advantage of a few 'eye candy' features, if present. The second one, which is what many games already do, is have many performance classes. For example, the machine falls into a bin of "Base Requirements Version (bad graphics, slow CPU)", "Version 1 (3-year old expensive system)", "Version 2 (1-year old expensive system)", and "Version 3 (today's $4000 system)". They then develop between two to four different algorithms, and a *LOT* of glue code so the displays don't look too different. The third option is to have both of the above options, plus global CLOD, procedural and implicit surfaces, and more advanced processing that takes so much math that a 3-year-old CPU can't handle it.
For example, page 6 discusses using high-quality water on faster machines, and low quality water on slower machines. They only touch on why it might be a problem, stating "fluid simulation will have to be either devoted entirely to ambient game effects or simple enough to run on the minimum system specs without any scalability to higher systems. Most likely, the introduction of fluid simulation to actual game-play, not just ambient effects, will require the combination of both, so the visual quality may be scalable but the simulation quality will be fixed."
Let's try to consider what the article REALLY means for this type of case.
First, we'll assume that water is critical to the game, and not just some fancy external thing. Maybe players are all riding around on jet-ski's or moterboats or battleships or something. The developer now has a choice. They can either:
This isn't just an issue of adaptive level of detail or swaping algorithms. Because this represents basic game states, it must be kept in sync on all clients, meaning it's an all-or-nothing decision. Do you want realistic ocean waves in your water game, or do you just want waves?
Let's look at another issue they bring up on page 1 -- Integrated Graphics Cards. (just typing that makes me shudder.)
Many integrated graphics cards don't have dedicated memory. Just looking through a Dell catalog will have little footnotes next to laptop and 'economy' computer memory numbers, system memory will be shared with graphics and audio processing. The board might have a fancy nvidia or ATI processor on it, and the card might be able to do all of the algorithms just fine; but the moment you run some combination of algorithms at the same time, they fight for the same CPU and memory spaces, and grind to a halt. In this case, the system stats themselves could be more than enough for the game, it's the motherboard or some other component that's the bottleneck.
In that case, dynamic algorithm selection is basically required, and is something many games already do.
But how long can we keep it up? Right now we already have to code for:
When is it too much? Already, we have to test dozens of different configurations.
That's what the article was asking. How can we have the third option (infinite scalability) without ignoring all the lower-end 'budget' PCs?
The question is still open.
frob
//TODO: Think of witty sig statement
Games for PS2 render to a 640x240 pixel frame buffer at 60fps. This results in jagged edges. Games for GameCube and Xbox, on the other hand, typically render to a 640x480 pixel frame buffer and try for 60fps. For an interlaced display, they do a simple comb filter on the scanlines. This results in smoother edges.
The problem is that the hardware has gotten faster and now the developers can slack of more on their coding because 'by the time the game is released, there will be faster hardware available'. The progress in game 'speed' has nothing like kept up with the hardware speed. How else do you explain that the likes Descent and Terminal Velocity with their full 3D features ran just fine on a 486/66, and ran perfectly on a Pentium 66 with the full textures and details cranked up? Hardware speed has gone up by a factor of at least 50 (possibly even close to 100) since the first Pentiums were released. How come we now need this new high-end hardware to run all the new games when the technical advances have not been all that great? Original Quake worked just fine in 1024x768 on a Pentium 66. See how far you get with the recent first person shooters on hardware like that. Bottom line - hardware has long become the replacement for the skill of developers. How else do you explain the difference in resource consumption between, say, Windows 98 and Windows XP? Does it really do sufficiently more to justify a 10 fold resource use increase?