Games have been made for computers since the early years. Playful and non-utilitarian uses are an important aspect of any technology – for example, playing with hunting bows led to the invention of the musical bow and other string instruments.
Computer games are commonly framed as 1) entertainment (rather than e.g. art or life-changing experiences), 2) something produced by an "industry" (in the same way as there is "the film industry"), and 3) something that has high demands on the hardware resources. Many of the common conceptions are at odds with permacomputing. One should therefore look into the "margins" (i.e. "independent" games) for a more diverse view of what computer games can be.
Before siliconization, it was a common idea that any computer is suitable for playing games – and the most limited computers were actually considered unsuitable for anything else. This is something worth returning to in permacomputing: target those platforms that are available to anyone (either directly or via emulation), and especially those that are no longer preferred for utilitarian purposes. Supporting a bedrock platform increases the likelihood that the game can be revisited in an indefinite future.
Maximalist aesthetics is a major driving force for obsolescence and ever higher hardware requirements. It is a better idea to stick to a less demanding style (e.g. pixel art) than to adhere to the mainstream gamer idea of "up-to-date graphics".
In the non-digital world, a "game" is often more like an immaterial idea than a product (think about the variety of games that can be played with playing cards). The same approach can be applied to computer gaming as well: Tetris is not really a specific program/product, but a game that any programmer can implement in a moderate amount of time. If the logic is defined strictly enough, the different implementations can be compatible in regards to scoring, competition and skill acquisition. The games that can be fully described as sets of rules have the longest potential lifespans.
Computer games often blur the distinction between a game and a virtual environment. Game-playing is a goal-oriented activity, but in a virtual environment it is not necessary to reach for anything specific. An important aspect of simulated environments is that their representations of the world can be used to gain insights to the actual world. This is how games can be used to amplify awareness.
Common problems
Game programming is often quite careless, as games are traditionally "allowed" to use all the available resources. Thus, it is common to find things like CPU-hogging busyloops even in turn-based games, or ridiculously high system requirements in modern pixel art games.
Running of games often requires emulation. Cycle-exact emulation may be orders of magnitude more resource-hoggy than "just enough" emulation, so it may be a good idea to support the fast but inaccurate emulators when targeting classic platforms.
Specific games
These games may be interesting from the permacomputing perspective, either technically or otherwise.
Another World
There is very little code in Another World. The original Amiga version was reportedly 6,000 lines of assembly. The PC DOS executable is only 20 KiB. Surprising for such a vast game which shipped on a single 1.44 MiB floppy. That is because most of the business logic is implemented via bytecode. The Another World executable is in fact a virtual machine host which reads and executes byte-sized opcodes.
Adventure games from Infocom, Sierra and Lucasfilm are also based on bytecode virtual machines.
See more: