The biggest single hurdle is that you would need source code for the game. Then you need to identify separable units of work which could be delegated to the Pi array. For example in a scene with many moving parts (such as projectiles) you might be able to delegate trajectory and lighting calculations for each object to a different Pi. Perhaps a scene could be broken into tiles, with each delegated to a processor. These are just examples. Another way to look at is that tasks which could be separate threads on a single processor are good candidates for moving to other processors.
There are lots of reasons this is hard, and potentially slow:
■If the code isn't organized for parallel processing, modifying it could be almost as hard as writing a game from scratch.
■You would be communicating with each Pi on its 100 mbit ethernet port. No matter how fast the processors are, you still have to move all the data out to them, and move the results back.
■The separate tasks are only valid as long as they don't have to interact. Back to the projectile example - what if the projectile on processor 7 hits the target on processor 42? First of all, how do you know they even made contact? How long does it take to update the physics information for each object when they are on different processors? Does 7 know that it must send information to 42, or do they both have to check in with the laptop? How coarsely can you chop time slices before the results look jerky?
■Now, what about specialized hardware? A Raspberry Pi can do any calculation your CPU or graphics card can. Can the Pi do a lighting calculation within a factor of 10 (or even 100) of the speed of the specialized hardware on a graphics card? Probably not.
Short answer: no. Long answer: do some speed and bandwidth calculations and tests before you even think about an actual application.