A list of some personal rules of thumb I use when devving, partly as a reminder to myself. Will be updating it as I figure out/notice more shit.
This is mostly very specific to me and the types of games I'm making right now. They aren't universal principles and different styles/genres would require me to come up with different stuff. Also they're stuff I wanna remember the most.
[Do Enemy-Side Balancing First]
Whenever a move is overpowered, my first instinct shouldn't be trying to tweak its properties, frame data or hitboxes. Instead I should always think about what kind of behaviors enemies could have to counter this move.
[Natural Balancing > Meters]
Meters, armor and other special states should be a last resort when balancing OP moves or trying to create certain dynamics. They're not 100% forbidden, but if I'm adding them before thinking about more natural ways to balance things, I've fucked up.
[Use Double Edged Design]
Ideally players should be able to take advantage of any threat in the game and turn a disadvantage into an advantage by playing well, contextually anyway. Rarely possible to apply this to everything, but it's always worth trying.
[Create "Cash Out" Moments]
Games should always have some "oh wow I'm a god!" moments. Once a player built a certain amount of advantage, I should let them bask in it. It makes gameplay feel dynamic, as long as the advantage is reset frequently enough and building up to that tipping point is challenging enough. Usually it means creating some risk free advantage building mechanics that requite a lot of pre-requisites.
[Create Reprioritization Moments]
Beat Em Ups struggle with context sensitivity a little, so the plans & rules of thumb players make will tend to stabilize pretty quickly. Reprioritization mechanics/moments throw a wrench in the player's plan, which forces them to change how they act within an established plan. The goal isn't to ruin the player's plans, but to destabilize them to make things feel dynamic. It requires some needle threading, too much reprioritization feels awful. I should always try to create these sorts of mechanics on a micro and macro level.
[Avoid Overwhelming Feedback Loops]
Feedback loops are fantastic when they are highly context dependent and short term. But if advantage doesn't get reset often enough, or if the ways to build advantage aren't context dependent enough, it can end up with really boring repetitive feedback loops.
[Avoid Pre-Requisite Tech]
There are some techniques that are always good to do and have virtually no downsides in most cases, so they become pre-requisites for decent gameplay. Some types of cancels tend to fall into this category. If the mechanics are very difficult, then it's probably alright to keep them in because they have informal risks attached to their use. But if, after a bit of practice, they become second nature to the point where decent players don't even notice them, then I should probably bake them into the mechanics they're leading up to/out of, and maybe flesh them out as their own thing.
[Always Ask "Why Wouldn't The Player Do This?"]
Related to pre-requisite tech. Whenever I make a mechanic or interaction that benefits the player I should ask myself why the players wouldn't want to use it. For mechanics that aren't meant to be Cash Out-type of stuff, the more reasons I can think of, the better since it makes everything more context sensitive.
[Avoid Looping Sequences/Rhythms]
Too much looping of complex inputs (more than 1-2 presses) or the rhythm in which those inputs are performed feels bad. Action games are about creating an enjoyable rhythm, so I should avoid it. This also probably means that my game's context sensitivity is low, so I should look at how to improve it.
[Give Every Action A Cost]
Players should always be losing something. Better players should be losing it at slower rates, ones which allow them to win more consistently.