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.

  • 12
    \$\begingroup\$ This depends on your target market \$\endgroup\$ Feb 19, 2015 at 2:03
  • 1
    \$\begingroup\$ You should also think about weak, yet new, hardware aside of old one: tablets/netbooks. Low quality mode can target both groups and possibly be ported to phones as well. And remember than even low-poly games can be slow if code is slow (PC Minecraft for example). Code is never too fast ;) \$\endgroup\$
    – PTwr
    Feb 19, 2015 at 7:59
  • \$\begingroup\$ @PTwr Remember the games for PC-AT and similar with no timing? Those got pretty fast on newer hardware :D \$\endgroup\$
    – Luaan
    Feb 19, 2015 at 9:19
  • 1
    \$\begingroup\$ My PC is 8 years old. The only upgrade that it has seen was by adding a 40GB SSD 4 years ago. I still play WoW just fine. DayZ runs at 1080p with most settings turned up. I have a few graphics mods for Skyrim and it still runs ~40-50 FPS at 1080p. Really all that means by this point is that your indie game shouldn't be performing worse than modern AAA games. \$\endgroup\$
    – user39686
    Feb 19, 2015 at 20:36
  • 1
    \$\begingroup\$ I suspect that "most people that play indie games have old hardware" is the most easily disprovable assertion made by your colleague. Either way, though, this is a business decision for the developer, and nothing more: coding for older/slower hardware is often more difficult and so will cost more to deliver. I'd say that your colleague's statement is in the same category as "all websites should work on IE6." It's a nice idea, but not often practical and often costly to deliver on. \$\endgroup\$
    – Dan Puzey
    Feb 20, 2015 at 10:29

3 Answers 3


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


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.


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.

  • 4
    \$\begingroup\$ However, note that the target demographic which buys high-end videocards like the GTX280 is wealthy enough to have bought a new card since. The people who today still use a 2009 era videocard probably bought a budget model back then. \$\endgroup\$
    – MSalters
    Feb 19, 2015 at 7:54
  • 3
    \$\begingroup\$ Also don't forget that your graphic intense indie game might not be due for a year or two so you can target even less old hardware. \$\endgroup\$
    – Valmond
    Feb 19, 2015 at 14:51

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.

  • 3
    \$\begingroup\$ I made an account here just to comment: Doesn't Steam release this information freely to everyone? \$\endgroup\$
    – Regret
    Feb 19, 2015 at 10:16
  • \$\begingroup\$ @Regret jzx is presumably referring to a more targeted, and therefore narrow, demographic. The raw stats are presumably skewed by secondary systems, indie games, etc. Steam presumably sells info packages to developers that want to check the hardware of their target demo. \$\endgroup\$
    – Lilienthal
    Feb 19, 2015 at 10:36
  • \$\begingroup\$ I'd imagine they'd provide it for free if you're on the Steamworks platform. So you'd have access to this data if you're releasing a game via Greenlight. \$\endgroup\$ Feb 20, 2015 at 20:20

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


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .