Uniform Activations

There's this common structure a lot of games have: a list of different abilities the players choose from. Comes in a lot of different shapes - equipment, magic spells, shop purchases, research upgrades, starseeds.. sometimes they're randomly distributed, often there's an opportunity cost such that choices between them are somehow exclusive, whatever. The point is they're a collection of modular parts that do different things; removing one or adding a new one doesn't drastically change the nature of the game. It's a useful structure both for players and designers because independent pieces are easy to think about, can be introduced one at a time, can be replaced individually without much hassle, and the process of gradually understanding how disparate parts fit together can be wonderful.
(Its weakness is that a design composed of replaceable pieces lacks the particular beauty of elegant minimalism, of a pure holistic design that appears to be the only possible way it could be.)

Now, a lot of games that use this structure have these abilities behave in a variety of different ways. Classic roguelikes (just for example; other genres are similar) have collectable items that are consumed once, activated repeatedly consuming a finite number of charges, activated repeatedly consuming an energy resource, exclusively equipped to give a passive effect, non-exclusively equipped to give a passive effect, exclusively or non-exclusively equipped to give an ability that can be activated repeatedly.. as well as similar effects gained by leveling up killing monsters doing quests eating food praying to the gods. And when abilities are activated, they might require input to select a direction or an enemy or a friend or a location, and they might take effect instantly or after a delay or last for a particular duration or until deactivated. It can be a right mess.

More often than not this variety is a crutch for the designer. Pretty much any idea you come up with can be stuck into a game design without putting in any effort to ensure it behaves in a predictable way - but this offloads work onto the players to learn and keep track of the myriad different behaviours; and in a videogame it offloads work onto the programmer to implement interfaces for all these different behaviours. Here's an advantage to being both designer and programmer: if a small amount of extra design work saves you a large amount of programming work you're going to do it, and if you run into an unpleasant and unnecessary programming task you can go back and design with the grain - often making the game better by doing so.

Magic: the Gathering is probably the most egregious example of this. Seven different card types, in five different colours (and multicolour, hybrid, colourless), which depending on their type are played either by spending mana or a limited number of times per turn, and either have a one-off effect (which might target any number of different objects with any number of constraints) or create a permanent object (which might have effects later under any number of different conditions). There are no straightforward consistent rules governing how they behave - any pattern has an exception somewhere.
But there's a reason for this: they're trying to create the illusion of a "Calvinball" game where anything could happen, where every rule can be broken - but at the same time keep it constrained and balanced. (And of course sustain their business model by churning out vast numbers of new cards each year.) They're making a compromise for a particular effect. There are always compromises in design - even if not from external resource constraints there are internal tensions - and this is totally okay. The important thing is to ensure that when you're learning from the good parts that you don't copy the compromises as well if you don't have to - unfortunately when something is successful every part tends to get copied indiscriminately.
(David Sirlin wrote recently of how dropping an awkward timing system his game had inherited from Magic improved it.)

A few examples from things I've made of how I prefer for this to be done:
- All of Zaga-33's items are single-use instant-effect untargeted abilities that take one turn to use. Most of the effects are borrowed from other roguelikes but "fire a beam in a straight line" required some adaptation to avoid needing extra interface to choose a direction: the solution was to select all the directions simultaneously (other methods would have been to pick one at random, or intelligently choose the one with the most/nearest enemies).
- Early on during 86856527's design some of the abilities I wanted to include were passive effects (granting the ability to see invisible things, increasing attack damage) and some were active (blow something up right now). Converting the passive effects to active ones (durations lasting until the end of each sector) not only made things more consistent and elegant, but also made them more interesting: you have the choice each level whether to spend resources maintaining the effect. So I ended up with all abilities being multiple-use instant-effect untargeted, costing resources, not taking a turn to use. Many of these effects target specific enemies or areas but without requiring specific player input - they take a random one, or the nearest, or all of a particular type (and 868-HACK will display more methods).
- Exuberant Struggle and Vertex Dispenser both squeeze something of the base-building and army-constructing of RTS into games where you're directly controlling a single unit and activating abilities with a single key press: abilities that create units or buildings just place them at your current location, and the units go off and act automatically.
- Glitch Tank pushes unification to an extreme, with basic movement actions being shuffled in with weapon and army building cards, all activated instantly by a single button press - unlike these other examples where moving (and sometimes attacking) are a separate type of ability.

Now, there can be good reason to have different interfaces and behaviour types, this isn't a firm rule - just a suggestion. If you gain something worthwhile from this variety then by all means do it: just consider whether this could still be expressed in a cleaner system. I mentioned Magic, where they're partially justified in having a messy design to give the particular impression they want. Sometimes you can convey meaning through different behaviours. Consider Starcraft - the Zerg create units in a completely different way to the other races, rather than training them at dedicated buildings they grow larvae into different types: this reinforces their character as a weird biohorror race that mutates and evolves on the fly. But this actually argues in favour of keeping abilities consistent most of the time: you need to set up a pattern in order to break it. Keep the mundane consistent so that the magical can be magical.