Unix Philosophy
Perhaps the simplest form of early Unix Philosophy is as follows: every program should do one thing, do it well, and simply interface to every other program.
In (early) Unix, only one program handled the printer; any other program sent items to that program if they wanted them printed. Similarly, only one program parsed, formatted, justified, calculated, and so on.
Today's over-bloated software may not appear to have much to do with this philosophy, the core principals actually still guide programmers and operating system designers. In very early versions of Windows, each program handled printing. Windows hasn't done that for a long time.
Do one thing, do it well, and interface simply.
Games
When you think of mechanics that do one thing and do it well, you think of party games, maybe dexterity games and sports. These are ideal games for many, and in fact look at the new mainstream games each year from Mattel and so on.
You also think of Knizia and his 250 or so games. Excepting his meatier games, Knizia's designs (Money, Flinke Pinke, Modern Art, Poison), appear to be to follow this principle. Not surprising, given his background in mathematics. I don't know that it really makes a good game. I think it makes a good mechanic, but all these little games leave me wanting more "game" in my game.
It would be interesting to take little games and interface them together to make a heftier game. On the other hand, better games feel like more than just a collection of disparate mechanics, but a total integration of mechanics. And theme, many would add.
And there's no one perfect way to do an auction or a set collection mechanic, like there is one correct way to send data to the printer.
TED
On the other hand, as the TED talks demonstrate, this is an excellent guiding principle for giving a lecture.
No comments:
Post a Comment