How can I check if my computer's powerful enough to run a certain game?

Demos, though increasingly rare (and massive) can be a good way to verify compatibility. Just remember that a prerelease demo may be poorly optimized compared to the final game.

Most modern PC games will publish the recommended at minimum system requirements at some point in time before the game is released. For example, the game Witcher 3, released in North America on May 19th, 2015, released their system requirements in early January of 2015.

The System Requirements Lab linked by John Gietzen is an excellent resource, but if you are unable or unwilling to run that applet, the publishers' minimum requirements will be a good place to start.

On the internet, you should find minimum system requirements for almost every game there is. If you can't find them, you can still contact the game developer. And if not any of these methods give you an answer and if the game is for free, you can simply test it on your computer.

Can I run it? vs. Is it playable?

There is a significant difference between these two questions, even though they are often conflated. Here are some specific reasons why a computer might not be able to run a game. Even when you don't run into these, a game might still not be playable. For example, you could clock the chip in your modern pc down to 500 MHz and still technically run any game program, but not at any reasonably playable speed for most recently published titles.

Rapid development of hardware means that on an older machine typically the hardware won't support all the functions the game demands of it. With increasing complexity of modern hardware and an increasing amount of pc configurations out there, it can be difficult for a developer to properly check for the availability of functionality and provide useful error messages. In particular older and lower budget titles are more likely to simply crash when encountering an internal error; assuming that calls to the game engine, graphics libraries or the OS simply succeed.

• Insufficient hard drive space.

If there isn't enough space to store the game, it can't be run.

• Out of memory.

Games typically just assume that they will receive whatever memory requested from the OS. Once the OS says 'no', because it ran out of both memory and swap file space, the game usually unceremoniously crashes. Or, on linux, some other process might request memory leading to the OOMkiller terminating the game before it can crash itself.

This is more complicated when it comes to games where the player 'creates' things, like tycoon games. Some of these can be potentially unlimited in scope, in which case the game eventually won't run on any machine, or the size of the map that can be run depends on the available memory.

• Unsupported CPU instructions.

The X86 instruction set is not the same it was in the 1980s. Newer models of chips keep adding more instructions to it. Thus, a game executable might crash if ran on a cpu that is too old. Typically games are compiled with alternate instruction paths if stuff such as vectorization extensions are unable, so this is a rarity.

• Unsupported DirectX/OpenGL/Vulkan feature set.

When a graphics library call results in an error, it usually causes a game to not run at all and crash. Games are usually shipped with a particular edition of DirectX/OpenGL, and the maximum feature level for a graphics card is also easy to find.

Vulkan is as-of-now too new for this to be common (to have a computer that supports vulkan but not a specific vulkan function wanted by a game). It's likely to provide much more of a headache than DirectX/OpenGL though: Vulkan has no concept of feature levels and instead has a large amount of constants specifying the hardware limits explicitly, which means explicit work on the part of the developer to make sure they check these limits and stay below the reported values.

• Incompatible sound/video system.

A typical problem when trying to run DOS games, which tend to directly access the hardware. This is usually solved by running them through an emulation layer.

• Too much power.

This can be a thing too. A game could manually do I/O, memory, or scheduling operations, and use a variable that's too small for the number of cpu cores or available memory on the system, even though it could technically utilize all resources, once the OS allocates resources beyond the size of the index, the game will crash.