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."
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...
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
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.
Just pick minimum FPS and replace heaviest algorithms with lighter versions whenever FPS drops too drastically. Just look up "Morrowind FPS Optimizer" for example of a program that does similar thing - shortens view distance whenever it causes speed problems. It allows several other hacks too: Remove far, small objects, shorten view distance (better FPS) in battles and much more.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Actually, understood in terms of game mechanics, the depth of Diablo (either release, with or without exapansions) is less than that found in most modern, "completed" roguelikes (many are extended programming exercises that never attain full realization). It's about on par with seminal games of the genre.
The only depth to be found in Diablo that exceeds a typical roguelike is to be found in the plotting of the storyline. Apart from ADOM, there really aren't (m)any roguelikes with a cohesive, multipart plot - apart from "slay foo" or "retrieve bar".
But returning to game mechanics, Diablo is incredibly atrophied compared to the average roguelike. Diablo II compares a bit more favorably, but still misses the mark. Not a bad thing, as more often than not, roguelikes tend to choke on their complexities, leading to woeful imbalance/inconsistency or excessive demand on gamers to grok the system as presented to make any headway at all (NetHack).