Should independent game developers target older hardware?

Question

A developer I work with tells me that indie developers should target hardware that is around six or more years old (at max settings). I get the idea that one should allow everyone that wants to play their game to play it at a runnable framerate, regardless of how old their hardware is, but should indie developers limit themselves to using a low-poly art style, or make their games with older hardware in mind, mainly because "most people that play indie games have old hardware?"

Is there any reason to allow your game to run at max settings for very old hardware, even though it would lower the graphical possibilities for people with newer hardware?

Are there any statistics that show that games that reach their upper graphical limits easily on older hardware are more successful than games that push their upper graphical limits higher at the expensive of a 'less-than-the-best' experience for players on older hardware?

Any insight on this will be greatly appreciated.

Answer 1

In this era old hardware has become a misnomer. Old hardware is not necessary slow. 6 years old is 2009 and DirectX11 was already existing. We still don't have much newer today.

You need to consider two things:

• features
• power

features

This is the level of instructions that the hardware will support, DirectX9,10,11, or OpenGL something (this depends on the drivers). And the CPU instruction set: SSE4, AVX..

This is the biggest headache usually in developpment, scalability facing those is harder than scalability facing power. DirectX9 had something called technique in the .fx files to fall back, for both points. But for CPU instructions you need multiple executables, or large branching sections in your program. Or don't use them.
Luckily today, even 6 years is a short period and you will have access to about everything you need even on "old" hardware.

power

This is the point that should scale, on todays machine, and not legacies machine. A high end of 2009 potentially features a geForce GTX280, this is very powerful, and much more powerful than your low end AMD A6-3650 APU or something.

One need to understand the gigantic gap of performance between low end, and high end, of today's machine. Because it largely exceeds the gap of performance of your 6 year range machines on the high end scale.

So its not a consideration of market regarding renewal, its a consideration of market regarding original buying budget. And if you need to target today's laptops or low end Desktops, you are going to need to scale anyway, and way more than you think.

Try to care about resolution, pixel fillrate and graphics memory bandwidth. You play on those factors thanks to the number of screen passes, the width of your Gbuffer if you have deferred shading (very costly on low end machines), the resolution of your textures and their quantity present on screen at any given time t... Polygon richness will not be an issue unless you are targeting 2002 hardware. Shader ALU/FPU complexity will not be a problem either, unless you target 2005/2006 hardware.

Answer 2

I can't remember where I first heard it, but that's an old rule of thumb that doesn't hold up to much critical thought. Truly, it comes down to business objectives. If you don't plan on selling the game, it doesn't matter.

The fact is, the more hardware you can support the bigger your potential market is. However, most independent developers aren't going to have the resources to support anywhere near cutting edge hardware anyway, because in order to take advantage of said hardware they're going to have to expend a fair amount on content. Any independent developer that needs to worry about that usually has the resources to find out what system specs they need to target, and that's likely information you can buy. Steam, for example, collects those statistics and likely resells it to developers.

Answer 3

As a general rule, the wider the variety of hardware on which any program will run, the more opportunities you'll have to sell a copy. How much variety you can support depends a lot on the game. A game like Dwarf Fortress can easily be very scalable, both in terms of processing requirements and graphics. An FPS with realistic physics like Amnesia not so much. My suggestion would be to write your game so that it can be run on the widest possible array of hardware and still give a good experience. You don't necessarily have to support it all right away, but being able to reconfigure it for newer/older/just-plain-different hardware easily will pay dividends as your fanbase grows and as technology progresses.

There are two things that will make your life a lot easier when it comes to making your game run on a wide array of devices, and they have little to do with the age of the hardware you target (at least directly):

1) If possible, split the backend from the frontend. If the part that does the math about which pieces are doing what, where has a well-defined interface for passing that information to the part that displays it on the screen and takes user input, then you can more easily adjust one (usually the frontend) to new hardware without having to mess with the other. If written this way, many kinds of games could be given frontends ranging from top-of-the-line 3d graphics, to animated sprites on a webpage, to pure ASCII text characters. At that point, you can choose which to implement based on who you think will buy the game now. And you can expand to new output schemes as people show interest -- without having to mess with the core of the game.

2) As much as possible, write portable code. Depending on the specific behaviour of DirectX 9.3c or whatever may let you get it done faster, but when you realise that you should put out a version for Android, you're going to have to redo a lot of work. Picking libraries and languages that aren't dependent on a single vendor, and that follow open and well-defined standards will seriously reduce your workload in the long run. Remember: writing a program is usually a tiny portion of the work compared to maintaining the program. (Unless you're going for the "planned obsolescence" business model, but that's not likely to get you a big fanbase in the long run.)