Jun 19, 2024
The Shadowed Rune - Javifugitivo
Hello again! Over the past few weeks, I've been busy preparing for the Indie Dev Day in Barcelona and promoting the game (I'll have a small stand there).
However, I managed to find time to develop one of the systems I had pending to implement. Although it was planned in the GDD, implementing it in the game can always present challenges.
As I mentioned in the previous development diary, the goal was to work on smaller dungeons, between 4 and 6 rooms (including entrance and exit), so they are relatively short (about 5-10 minutes). The tower where 'The Shadowed Rune' takes place consists of 7 main floors. Each floor is divided into several sections. Each random dungeon will be one of these sections. The last section of each level will be a boss fight. After defeating it, you'll ascend to the next floor of the tower. All sublevels will share the same theme.
The challenge? Making these 'mini-dungeons' interesting. As the game's description states, the key is to combine action levels with puzzle levels that force you to use elements to solve them. Therefore, the room positions must be random and offer enough variety to surprise the player.
Each floor has a theme based on an element, but that doesn't limit the appearance of others. However, it does influence the type of puzzles that will appear.
Another reason for dividing the structure into rooms is to facilitate cooperative play. It's clear that completely disconnected rooms could be created, where you move from one to another without returning to the previous one. But I think we would lose one of the strengths of 'The Shadowed Rune':
Each room (called Chamber in the programming) is designed separately, to test it with semi-random bases of connection between objects - activators - runes - enemies. Others will be more closed puzzles, but I hope to have enough variety to avoid repetition.
The initial idea is that the room can be completed with the elements it provides. This ensures that the player doesn't get stuck because they lack an element or a previous rune. But if they have other equipped runes and other elements available, they could access secret areas, solve puzzles more easily, and get better loot. (The game is filled with small rooms and hidden areas with storerooms and loot that can be accessed with the right runes, without compromising the normal progression of the adventure).
This also allows you to complete the entire level and, before crossing the last door, decide to take a small detour and explore areas that, with a recently obtained rune, might lead to a hidden area.
On the technical side, I can share that each tower floor is laid out as a 4x4 grid (16 cells) (enough to create different types of layouts). When you leave the camp, the character enters the first level of the tower: "The Flooded Basements."
At that moment, the game starts generating, choosing one of those 16 cells as the target and moves, creating a path according to the programmed algorithm until it reaches the fixed limit or completely blocks. In that case, it places the character in the initial room, and the adventure begins.
I am creating this system from scratch, without using third-party code, to ensure I have control over it at all times. The main design challenge was to create a basic layout for the 16 tower positions and ensure that the paths are always connected during creation.
These were the first tests, only with terrain and some objects:
Going deeper for those who might find it useful. Each room is designed in a small, closed level. Once tested, it is saved in files for later reuse. This way, we can have hundreds of rooms without loading them all into memory, as only the necessary ones are loaded, even allowing the combination of “tiles” and “instances” in separate files for even more combinations.
Once everything is initially set up, we design the rooms with basic walls and floors and include collisions adjusted to the Z-axis. Now the code knows which room to place in each space. However, it doesn't know if there are other rooms next to it, leaving many paths open. I tried to solve this by creating small storerooms and dead-end paths, but it didn't convince me. These small storerooms could be part of the already created rooms, without needing so many additional elements.
The appearance created was a bit "strange" since it left remains of rooms that couldn't be played because they were inaccessible, so this first iteration was discarded.
Once again, we returned to the design phase and changed the way rooms are created. In the first version, all open rooms were created based on their position, whether it was a corner, etc., but always with the maximum number of open paths. This created a lot of debris in the form of tiles and inaccessible objects.
For the new version, I segmented the layout creation into three phases:
1st Phase, a zone from the 16 available is chosen, and the starting room is created.
2nd Phase, using a 4-direction system, the dungeon layout is created. At this point, the rooms haven't been created yet, only marked which rooms are activated for the dungeon.
3rd Phase, as the dungeon is already created, we can now sequentially check the relationships between rooms. Each room checks the 4 directions (north, south, east, and west) and chooses its most suitable layout with the necessary connections. This way, each room now has more consistency, and I don't have to find patches to close open paths.
Here are the results after the first tests:
As you can see, the dungeon now "looks like a dungeon," with everything connected. However, the system still needs refinement. I added checks to ensure that when a dungeon doesn't generate with a minimum size, it resets the generation. It should also always create an entrance and an exit door. If it doesn't, the generation resets again. These steps are invisible to the player since the generation occurs during level transitions with a fade to black, making these small delays imperceptible. We'll continue improving the system later, but for now, it's sufficient to move forward in other game areas.
The most interesting part of this is content generation:
Each room, once its layout is chosen, can be filled with whatever we want, as long as it respects the entrances and exits. This means I can create hundreds of small rooms with different layouts, even separating decoration content.
Currently, I am considering variations of different basic layouts:
Large room, rounded, narrow, diamond-shaped, divided into sections, divided corridors, etc.
And each with different content variations adapted to the layout:
Enemies, puzzles, traps, enemy waves, bosses, treasures, shops, and combinations of the above.
The difference between an empty room and one prepared with content (this way, the scale of each room is better seen).
With in-game lighting:
How do you complete each level?
By reaching the room with the closed door. Each level will have a closed door that opens by fulfilling a condition in that room. The player must discover it:
Solve a puzzle in the room.
Defeat all the enemies in the room.
Defeat a mini-boss.
????
Thanks for reading! See you in the next Devlog!
However, I managed to find time to develop one of the systems I had pending to implement. Although it was planned in the GDD, implementing it in the game can always present challenges.
As I mentioned in the previous development diary, the goal was to work on smaller dungeons, between 4 and 6 rooms (including entrance and exit), so they are relatively short (about 5-10 minutes). The tower where 'The Shadowed Rune' takes place consists of 7 main floors. Each floor is divided into several sections. Each random dungeon will be one of these sections. The last section of each level will be a boss fight. After defeating it, you'll ascend to the next floor of the tower. All sublevels will share the same theme.
The challenge? Making these 'mini-dungeons' interesting. As the game's description states, the key is to combine action levels with puzzle levels that force you to use elements to solve them. Therefore, the room positions must be random and offer enough variety to surprise the player.
Each floor has a theme based on an element, but that doesn't limit the appearance of others. However, it does influence the type of puzzles that will appear.
Another reason for dividing the structure into rooms is to facilitate cooperative play. It's clear that completely disconnected rooms could be created, where you move from one to another without returning to the previous one. But I think we would lose one of the strengths of 'The Shadowed Rune':
Each room (called Chamber in the programming) is designed separately, to test it with semi-random bases of connection between objects - activators - runes - enemies. Others will be more closed puzzles, but I hope to have enough variety to avoid repetition.
The initial idea is that the room can be completed with the elements it provides. This ensures that the player doesn't get stuck because they lack an element or a previous rune. But if they have other equipped runes and other elements available, they could access secret areas, solve puzzles more easily, and get better loot. (The game is filled with small rooms and hidden areas with storerooms and loot that can be accessed with the right runes, without compromising the normal progression of the adventure).
This also allows you to complete the entire level and, before crossing the last door, decide to take a small detour and explore areas that, with a recently obtained rune, might lead to a hidden area.
On the technical side, I can share that each tower floor is laid out as a 4x4 grid (16 cells) (enough to create different types of layouts). When you leave the camp, the character enters the first level of the tower: "The Flooded Basements."
At that moment, the game starts generating, choosing one of those 16 cells as the target and moves, creating a path according to the programmed algorithm until it reaches the fixed limit or completely blocks. In that case, it places the character in the initial room, and the adventure begins.
I am creating this system from scratch, without using third-party code, to ensure I have control over it at all times. The main design challenge was to create a basic layout for the 16 tower positions and ensure that the paths are always connected during creation.
These were the first tests, only with terrain and some objects:
Going deeper for those who might find it useful. Each room is designed in a small, closed level. Once tested, it is saved in files for later reuse. This way, we can have hundreds of rooms without loading them all into memory, as only the necessary ones are loaded, even allowing the combination of “tiles” and “instances” in separate files for even more combinations.
Once everything is initially set up, we design the rooms with basic walls and floors and include collisions adjusted to the Z-axis. Now the code knows which room to place in each space. However, it doesn't know if there are other rooms next to it, leaving many paths open. I tried to solve this by creating small storerooms and dead-end paths, but it didn't convince me. These small storerooms could be part of the already created rooms, without needing so many additional elements.
The appearance created was a bit "strange" since it left remains of rooms that couldn't be played because they were inaccessible, so this first iteration was discarded.
Once again, we returned to the design phase and changed the way rooms are created. In the first version, all open rooms were created based on their position, whether it was a corner, etc., but always with the maximum number of open paths. This created a lot of debris in the form of tiles and inaccessible objects.
For the new version, I segmented the layout creation into three phases:
1st Phase, a zone from the 16 available is chosen, and the starting room is created.
2nd Phase, using a 4-direction system, the dungeon layout is created. At this point, the rooms haven't been created yet, only marked which rooms are activated for the dungeon.
3rd Phase, as the dungeon is already created, we can now sequentially check the relationships between rooms. Each room checks the 4 directions (north, south, east, and west) and chooses its most suitable layout with the necessary connections. This way, each room now has more consistency, and I don't have to find patches to close open paths.
Here are the results after the first tests:
As you can see, the dungeon now "looks like a dungeon," with everything connected. However, the system still needs refinement. I added checks to ensure that when a dungeon doesn't generate with a minimum size, it resets the generation. It should also always create an entrance and an exit door. If it doesn't, the generation resets again. These steps are invisible to the player since the generation occurs during level transitions with a fade to black, making these small delays imperceptible. We'll continue improving the system later, but for now, it's sufficient to move forward in other game areas.
The most interesting part of this is content generation:
Each room, once its layout is chosen, can be filled with whatever we want, as long as it respects the entrances and exits. This means I can create hundreds of small rooms with different layouts, even separating decoration content.
Currently, I am considering variations of different basic layouts:
Large room, rounded, narrow, diamond-shaped, divided into sections, divided corridors, etc.
And each with different content variations adapted to the layout:
Enemies, puzzles, traps, enemy waves, bosses, treasures, shops, and combinations of the above.
The difference between an empty room and one prepared with content (this way, the scale of each room is better seen).
With in-game lighting:
How do you complete each level?
By reaching the room with the closed door. Each level will have a closed door that opens by fulfilling a condition in that room. The player must discover it:
Solve a puzzle in the room.
Defeat all the enemies in the room.
Defeat a mini-boss.
????
Thanks for reading! See you in the next Devlog!
Share: 
