The Zombie Stack Exchanges That Just Won't Die
At this point there are tons of flash games and interactives out there. Many of these have become significant works that we are going to want to be able to play well into the future. So, what does it take to preserve a flash game so it can be engaged with in the same way again in the future?
Trevor Owens
The great problem with flash technology is that it is closed technology, controlled by one company. As a rule of the thumb, you should avoid such things if you want to use something for the very long time. Already now there are compatibility issues, for example temporal lack of flash plugin for Linux, low performance of plugin on Windows x64.
But assuming you are already 'in', the best way to be able to use the program in the future is to create snapshot of the operating system with functioning flash plugin (the image of the hard disk). There are already x86 emulators and it is rational to expect that even better versions will be available in the future. You should also note the details of your hardware, it could be necessary to create the hardware emulator to run that disk image.
Yes, it probably makes sense to just save copies of the files of the game. However, the first assumption here is that these Flash games don't rely on any dynamic resource dependencies (as per this related post on Preserving Flash-driven Art) - i.e. that they truly are self-contained. This is difficult to be sure about, unfortunately, short of playing though the whole game with your network connection switched off.
The second assumption is that the Flash game is not coded in any way that critically depends on being embedded in a web browser. This can vary from simple dependence on critical parameters that are only declared in the parent page, through to nasty cross-browser/plugin scripting. Again, it's difficult to be sure about this limitation without manual testing.
Beyond that, the critical information is the publication date so that a contemporary playback environment can be constructed. Having said that, if you expect to provide access, I would also recommend taking copies of the dependent software. I'm a little more skeptical of the long-term stability of specific virtual machine images (which can have subtle dependencies like virtual hardware that may be deprecated), so I would ideally also store the installation software for a suitable browser and Flash plugin so that a suitable VM could be rebuild on top of a reconstructed OS image.
Finally, you could also try a SWF-to-HTML5 migration (e.g. Google's Swiffy or Adobe's solution) as a backup/alternative option. They are both closed-source products, but the migrated versions of the SWF files would be in open formats.
The question seems to make the assumption that preserving a game means preserving the digital bits that make up the game, and/or preserving the experience of playing the game. This may well be the aim of the preservation activity (in which case the other answers provide some great detail on this), but equally, it might perhaps not be. Some have argued that preserving the ability to play games might not actually be the best way to achieve preservation of gaming as we know it.
James Newman and Daniel Ashton have, for example, eloquently made the argument that other approaches may better capture the essence of preserving the experience of playing games. They suggest that player authored documents (such as game walkthroughs) do a great job of capturing the experience of gameplay, and could provide more understanding of that experience to future users/gamers/historians than simply being presented with a running game.