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."
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.
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.
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