Posted by One of the interesting things I’ve experienced developing a game within the framework of a well established genre (Metroidvania, in my case) is coming up against problems, noticing how the genre has solved them, and trying to find alternative solutions.
Doors were my most recent challenge.
In Metroid, you open doors by shooting them. I started out thinking this was a fine way of doing it and, in fact, I appreciate the simplicity of having a single verb that accomplishes different things based on context. Shooting damages enemies, shooting flips switches, shooting opens doors.
The problem arose when I realized that, first, I must have doors that open upward and downward and, second, my player character can’t shoot down.
Samus can’t shoot down in the original Metroid either but, and I’m a bit shocked I never noticed before, there are no doors in the floors or ceilings in Metroid for the NES. There are doors like that in Super Metroid, but Samus can shoot down in that game.
I said I must have doors in the floors and ceilings, and that is non-negotiable. Each room in my game is a square of the same dimensions and the rooms move and rotate, so doors have to be able to be oriented in any direction to potentially connect, or cut off connection, to other rooms.
There are a few viable solutions to the problem. I could just add shooting down. I’ll admit the driving force behind avoiding this route is that I don’t want to make more animation frames for the player character. But, I also think it adds an interesting dynamic to the game for down to be a unique direction in multiple ways.
Being a platformer means moving down is easier than moving up already (because of gravity) and adding to that an increased exposure to danger by making it impossible to attack in that direction makes for interesting challenges for the player (I hope).
Also, since the rooms not only rotate, but the player will have control over how and when they do, the player can change what is below him in the room. This allows him to change his approach to the obstacles he’s facing and adds further interest to the puzzle of traversal (again, I hope).
Another possible solution to doors, and the one I’m currently going with, is to have them open automatically. A door that currently connects to another room (because it lines up with a corresponding door on the other side) will simply open when you get near it.
This of course has lead to its own challenges, like having to implement raycasting code to detect line of site to the player. More than that though is the specific issue of moving through a door in the ceiling and therefore entering a room directly above a door.
If the door just opens when the player is near by, and he enters a room above a door, he just falls back through the open door in the floor. Very frustrating.
This means writing specific code that checks if a door is in the floor and if the player just entered the room through that door. If both are true, the door should close and stay closed until the player moves away from it.
I suspect this choice will have some radical implications for the overall design of my game. Metroidvanias are largely about “gating” progression, and doors that require a certain kind of key (missiles, power bombs, whatever) is an obvious and effective way to do that. Making all the doors open as long as they go somewhere and you’re near them removes those possibilities. I think it will be for the good, however, because I’m not really making a Metroidvania. I’m making a game within the framework of a Metroidvania. Gating progression based solely on the position and orientation of rooms helps focus my design on the core concept I want to address. But that’s a topic for another dev log.