The Metroidvania Metroid-like game genre, from a development perspective, is quite complex to master. World and level design, for examples, are core elements of the game along with player abilities and game physics. You cannot plan one without the other. This is because player abilities, powerups and game physics, are the very elements that allow the Player to progress and advance (or backtrack) throughout the levels. This also means that levels must be designed around the player’s abilities, powerups and game physics (among other things).
A well developed metroidvania game should start with a solid planning phase. One of the first things to figure out is the character movement. I’m not talking about physical variables such as speed, friction and acceleration. I’m talking about figuring out what are the movements we want the Player to be able to execute during the game.
Can the character crouch? If so, should it crouch only when standing still? Can the character crouch in mid air or does it simply aim downward? Is it possible to walk while being in the crouching position?
These are serious design considerations that should be carefully planned and addressed well in advance as they define the feeling of the game. The player will act and react based on what movements are available. It’s the absolute first response to player’s inputs.
Crouching: Metroid Zero Mission vs Axiom Verge.
In both games, you can crouch. But while in Metroid you stay in that position even if you let go of the down key/button, in Axiom Verge you get up as soon as you let go of the key/button.
Also, while in Axiom Verge you can walk while being in the crouching state, you cannot do so in Metroid Zero Mission. Yet if you press the down key again, you morph into a ball.
The mechanics are different and so is the gameplay. Plan carefully what you intend to create and plan it well in advance. If you can, plan it all out even before any test level you might be tempted to sketch.
It will greatly simplify the overall development cycle (i.e. you won’t be rewriting big chunks of core mechanics code again and again, risking to break previous works).