The game Meritous (available from apt-get) is interesting in several ways.
The player is in a gigantic procedurally-generated maze, like a Nethack level with thousands of rooms. A bit of fun comes in exploring, discovering the different monsters, and collecting $ to raise your stats.
The combat interface is amazingly simple. You hold down the space bar and let go to launch an attack that hits everything in the room. Enemies don't take damage, but they either die or they don't depending on how long you held down the space bar.
Elegant simplicity is repeated in how the game uses colour. It looks monochrome, but the game's one colour changes from blue to black due to how far the player is from a safe area.
There are hidden items in the game, and all of them are passive-effect. Simplicity reigns.
There's more to the game, but it would spoil it if I told you. I will say that right when I thought I'd played it out, adapted to all the monsters and discovered everything interesting, the game decided to double all the monsters' speed, endurance, and fire rate. The core gameplay may be repetitive, but the game has a few ways of making itself interesting.
Patches for a software product flow like this:
(Core developer) --> (Distro) --> (Sub-Distro)
Linux Kernel --> Debian --> Ubuntu --> Mint
The core developer produces a product and incrementally improves it. Each distributor may have its own set of patches to the product. The sub-distributors take the patched product and may patch it further.
There are many, many, many core developers and it can be a lot of work to catalogue them all and keep up to date with their development. Sub-distros are based on the distros that already did this work.
If a sub-distro does not keep up to date with its upstream distro's patches, any value its uniqueness may have added to the Linux world is quickly offset by its obsolescence. Consider "Bob's OS, based on Red Hat 6.2!"
* If distros are lazy, the different software products offered by different distros may all claim core version number "1.2.3". This leads to confusion when the behaviour of "version 1.2.3" is not as documented. The patching vendor should change the version number to be like "1.2.3.rh-6", indicating who the vendor is and how many different patched versions of the product the vendor has released.
* If distros fail to keep up to date with core product releases, sub-distros may go around them and release the later versioned core product themselves. The sub-distro then risks failing to keep up with the parent distro's patches if the parent catches up and continues patching.
* If a distro in the middle of the chain slows development, those further down have to take over their work or suffer the same slowdown.
* A distro may not notice when core development obsoletes its patches.
Patches will also flow backwards from users, by the vendor's development of ideas offered by users and by direct development by users who are also coders.
(Core developer) --> (Distro) --> (Sub-Distro) <-- (Customer complaints and ideas)
The distro may then send the changes upstream. When a patch reaches the core developers, it gets integrated into the main product. Many Linux users are savvy enough to go straight to the core developers themselves.
* Patches produced by distros and independant developers are sometimes not up to the standards of the core developers and are not integrated into the core product.
* Distros have an incentive to keep their patches from their upstream in order to distinguish themselves from their competition. The GPL helps, but it takes work to dig through a distro's source and see if they patched anything.
It is possible for a sub-distro to take patches for different products from two different parent distros. A cause for this occurring would be if the second distro's patches had a good reputation. At this point the product is forked, as that distro has become a second core developer.
Imagine something like Distrowatch with a graphical map of distros and the distros that they are based on, a way to pull up lists of packages that differ between distros and their upstream, and a way to pull up the differences. It would be a visualization of the Linux software ecosystem. I'm not sure how useful it would be, but it would be cool to see.
I once diffed my distro's kernel against the official kernel and there were so many changes that I wondered if anyone was keeping track of them all.