The Shadowed Rune News

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!

First of all, I would like to thank everyone for their support. I am super happy with the reception 'The Shadowed Rune' has received. My commitment now is to develop the best game I can and be completely transparent with the community. That's why I've decided to start a series of development diaries, sharing details about the game, the progress, and explaining why I've made certain decisions. This way, you can learn more about the game, and at the same time, I can hear your opinions, receive your feedback and suggestions, and make the game even better.



The Shadowed Rune was born as a Jam game, created in 2 weeks. After receiving positive feedback in the voting, I decided to prepare a new version, researching lighting and gathering feedback on what worked and what didn't.

The main feedback was the significant difference in mechanics between the tutorial and the "dungeon." I created a very detailed room to teach you the main mechanics. But the next room was a huge level full of enemies, pots to break, and runes to collect. The problem was that it quickly became repetitive, the level was enormous, and it was easy to get lost and find the way to the Boss from the Jam version. I took all this into account in the GDD for the next version.

The 1st decision was to redo the tutorial after creating a solid foundation. Using the Jam base, I rewrote and optimized all the code to prepare it for a larger game without any poorly programmed elements that could limit it. The tutorial was crucial in this game since it has more complex combat mechanics than other games, especially being a family-friendly game that you could play with your child or partner. I wanted to respect the story I was creating but also avoid constant system messages that stopped the action (it was also a hassle to press text 10 times every time I tested something). The solution I found was to create pop-up texts when approaching certain places in each room.



This tiny character was already planned to appear later in the tower as a being who likes mana crystals and trades them for other items. It was the perfect opportunity to help explain basic functions like "push/dodge," rotating runes, or deleting them. Additionally, it would also give hints if someone got stuck.

The 2nd decision was to make the game cooperative from the start. It would be local co-op with an online option via Steam's Remote Play Together. Once I rewrote the control of the first character from scratch to add some improvements, creating a second player was easy, but making everything fit was another story... the game is designed to be played with keyboard and mouse and gamepads, but each player needed to choose their character, have their own key mapping, and this had to be shown in the game. Imagine the mess, especially using Game Maker where nothing is pre-made, and you do everything from scratch... For example, one of the features I had to discard almost immediately was the camera zooming out, because if players separated too much one of other, the lighting system caused a significant drop in performance. It was a shame because it was a very useful effect without resorting to a split screen.



When you control a single player, you have two camera options. If you move the mouse/right stick, you can look in that direction like in 'Nuclear Throne'. But if you don't touch the stick or mouse, the camera centers on the player, and you can play like classic 2D Zelda, even if you don't need to fight, you can control everything with just the keyboard...

In co-op mode, the camera works more simply, centering on a point between the two players and always staying centered. This limits the players' movement (they can't go off-screen or separate much), but in boss fights, it gives a lot of freedom, usually keeping the boss in the center of the room with enough visibility to dodge and attack, just like when there are many enemies.



The main challenge in the last month has been coordinating everything so that the game and story work whether you play solo or co-op. It didn't seem right to start playing in co-op and then tell the second player, "Hey, you have to wait 5 minutes to play." So, when you start playing, we take the opportunity to introduce the second character, Brishen, and how he finds his artifact. In single-player mode, you find Brishen later with his rune artifact already equipped.

The 3rd decision I made after receiving feedback and considering the co-op mode, lighting performance, and the game's concept was to reduce the size of the dungeons. The two levels that make up the current tutorial are proof of this, as they are small, detailed levels.


First view of the tutorial area.

Additionally, not having huge levels helps ensure players don't separate too much or feel the need to. It also allows me to create more detailed levels with puzzles, combats, and treasures. Smaller but with more quality and even better performance.

What I'm planning are levels with between 3 and 6 rooms at most, each with different challenges to overcome. The challenge now is coordinating the creation of hand-made rooms with random elements and then placing those rooms in a dungeon connected randomly but logically. I've already done some tests, and the results are promising... but I'll talk about that in the next development diary. Thanks for reading!