This article, entitled "Defining Game Mechanics" (2008), does what it says on the tin: it develops a definition of the term 'mechanics' for use in game analysis.
Although it's important to identify things in order to analyse them, I've already seen that it's easy to get hung up on terminology and definitions. Therefore -- so far -- I've been looking predominantly to gain an overview of the major aspects of design rather than get bogged-down in detail.
However, something about the article caught my eye and I though it worth taking a closer look.
Sicart begins by examining previous studies of mechanics. He shows that many academics define mechanics as a sub-set of the rules of a game, with copious debate over how much these rules affect a player. He goes on to examine other viewpoints, including the focus on the use of verbs (such as "take cover" or "repel") to describe these mechanics. He concludes by arguing that some games (specifically god simulators or sandbox games) do not fit this definition, and sets out to form a better one.
This is where it gets interesting: Sicart connects the mechanics directly to objects and actions; specifically, he equates actions with an object's methods (i.e. the things you can ask an object to do).These aspects were all mentioned in part 4 of my post on the Art of Game Design book, and validate my comments about actions & methods.
Why is this important? Well, it means that mechanics can be specified in a manner which is immediately compatible with (object-based) game engines. This improves communication between designers and programmers.
It also explains why it is important that game designers, who are not usually versed in computer programming, should be introduced to the object-oriented paradigm.
I wonder how far this should go? Do most game designers need to understand other OOP principles such as inheritance and polymorphism? I suspect that it can be an advantage, and will keep an eye out for this in the future.